David O'Brien lanzou recentemente a súa propia empresa, Xirus (https://xirus.com.au), centrada en produtos na nube de Microsoft Azure Stack. Estes produtos están deseñados para crear e executar sen problemas aplicacións híbridas en centros de datos, localizacións perimetrais, oficinas remotas e na nube.
David forma a particulares e empresas en todo o relacionado con Microsoft Azure e Azure DevOps (anteriormente VSTS) e continúa a dedicarse á consultoría práctica e á infracodificación. Foi MVP (Profesional Máis Valioso) de Microsoft durante cinco anos e recentemente recibiu o premio Azure MVP. Como coorganizador do Melbourne Microsoft Cloud and Datacentre Meetup, O'Brien participa regularmente en conferencias internacionais, combinando o seu interese por viaxar polo mundo coa súa paixón por compartir historias de TI coa comunidade. O blog de David está situado en Tamén publica as súas formacións en liña en Pluralsight.
Esta charla explora a importancia das métricas para comprender o que está a suceder no teu entorno e o rendemento da túa aplicación. Microsoft Azure ten unha forma potente e doada de usar de mostrar métricas para todo tipo de cargas de traballo, e a charla abrangue como usalas todas.
Ás 3 da mañá dun domingo, espertas de súpeto unha mensaxe de texto: "Unha aplicación crítica volve deixar de responder". Que está a suceder? Onde está a desaceleración e cal é a causa? Nesta charla, aprenderás sobre os servizos que Microsoft Azure ofrece aos seus clientes para recompilar rexistros e, en particular, métricas para as túas cargas de traballo na nube. David explicarache que métricas deberían interesarte ao traballar na plataforma da nube e como acceder a elas. Aprenderás sobre ferramentas de código aberto e creación de paneis e, en definitiva, adquirirás os coñecementos para crear os teus propios paneis.
E se te esperta ás 3 da mañá de novo por unha mensaxe sobre un fallo crítico da aplicación, podes descubrir rapidamente a causa.
Boas tardes, hoxe imos falar de métricas. Chámome David O'Brien e son o cofundador e propietario de Xirus, unha pequena empresa de consultoría australiana. Grazas de novo por vir aquí para dedicar o seu tempo comigo. Entón, por que estamos aquí? Para falar de métricas, ou mellor dito, para falarvos delas. Antes de nada, imos comezar con algo de teoría.
Explicarei que son as métricas, que podes facer con elas, a que debes prestar atención, como recompilar e activar métricas en Azure e que é a visualización de métricas. Mostrarei como son estas cousas na nube de Microsoft e como traballar con ela.
Antes de comezar, gustaríame pedirlles que alcen a man aos que usan Microsoft Azure. Quen usa AWS? Vexo que non moitos. E Google? ALI Cloud? Unha soa persoa! Excelente. Entón, que son as métricas? A definición oficial do Instituto Nacional de Estándares e Tecnoloxía é: "Unha métrica é un estándar de medición que describe as condicións e regras para realizar unha medición dunha propiedade e serve para comprender os resultados da medición". Que significa iso?
Tomemos como exemplo unha métrica para cambiar o espazo libre en disco dunha máquina virtual. Digamos que obtemos o número 90, que representa unha porcentaxe, o que significa que o espazo libre en disco é do 90 %. Cómpre sinalar que a descrición da definición da métrica, que ocupa 40 páxinas en formato PDF, non é particularmente interesante de ler.
Non obstante, unha métrica non nos di como se obtivo o resultado da medición; só mostra ese resultado. Entón, que facemos coas métricas?
Primeiro, medimos o valor de algo para despois usar o resultado da medición.
Por exemplo, sabemos a cantidade de espazo libre en disco e agora podemos usalo, usar esta memoria, etc. Despois de recibir o resultado dunha métrica, necesitamos interpretalo. Por exemplo, se unha métrica devolveu un resultado de 90, necesitamos saber o que significa este número: a cantidade de espazo libre ou a cantidade de espazo en disco usado en porcentaxe ou gigabytes, unha latencia de rede de 90 ms, etc. Noutras palabras, necesitamos interpretar o significado do valor da métrica. Para que as métricas teñan sentido, despois de interpretar un valor de métrica, necesitamos asegurarnos de que se recollan varios valores. Isto é moi importante, xa que moita xente non se decata da necesidade de recoller métricas. Microsoft facilitou moito a obtención de métricas, pero debes asegurarte de que se recollan ti mesmo. Estas métricas almacénanse só durante 41 días e desaparecen no día 42. Polo tanto, dependendo das propiedades do teu hardware externo ou interno, debes considerar como almacenar as métricas durante máis de 41 días, en forma de rexistros, diarios, etc. Polo tanto, despois de recompilalas, debes colocalas nalgún lugar que che permita recuperar todas as estatísticas sobre os cambios nos resultados das métricas se é necesario. Unha vez que as coloques alí, podes comezar a traballar con elas de forma eficaz.
Só despois de recompilar, interpretar e agregar os valores das métricas, podes crear un SLA (acordo de nivel de servizo). Este SLA pode non ser particularmente significativo para os teus clientes; é máis importante para os teus compañeiros, xestores e aqueles que manteñen o sistema e se preocupan pola súa funcionalidade. Unha métrica pode medir o número de tickets; por exemplo, se recibes cinco tickets ao día, nese caso indicaría a velocidade de resposta ás solicitudes dos usuarios e a velocidade de resolución de problemas. Unha métrica non debería simplemente informar de que o teu sitio se carga en 20 ms ou que o tempo de resposta é de 20 ms; unha métrica é máis que un simple indicador técnico.
Polo tanto, o obxectivo da nosa conversa é proporcionarche unha comprensión integral da esencia das métricas. Unha métrica está deseñada para axudarche a obter unha imaxe completa dun proceso simplemente mirándoo.
Unha vez que recibimos a métrica, podemos garantir un tempo de actividade do sistema do 99 % porque non se trata só dun ficheiro de rexistro que indica que o sistema está en funcionamento. Unha garantía de tempo de actividade do 99 % significa, por exemplo, que o 99 % das veces a API responde a uns 30 ms normais. Isto é exactamente o que lles importa aos teus usuarios, compañeiros e xestores. Moitos dos nosos clientes monitorizan os rexistros do servidor web, pero non detectan ningún erro e supoñen que todo está ben. Por exemplo, ven unha velocidade de rede de 200 Mbps e pensan: «De acordo, todo está ben!». Pero para alcanzar os 200 Mbps, os usuarios requiren un tempo de resposta de 30 milisegundos, e esta é precisamente a métrica que non se mide nin se recolle nos ficheiros de rexistro. Os usuarios sorpréndense de que o sitio se cargue tan lentamente porque, sen as métricas necesarias, descoñecen o motivo deste comportamento.
Pero como temos un SLA que garante un tempo de funcionamento do 100 %, os clientes comezan a queixarse porque o sitio web é en realidade moi difícil de usar. Polo tanto, para crear un SLA obxectivo, é necesario ver a imaxe completa do proceso, tal e como se recolle nas métricas que se recollen. Este é un punto de controversia constante con algúns provedores que, ao crear os seus SLA, non entenden o termo "tempo de funcionamento" e, na maioría dos casos, non lles explican aos seus clientes como funciona a súa API.
Se creaches un servizo, por exemplo, unha API para un terceiro, debes entender o que significa a métrica resultante de 39,5: unha resposta, unha resposta correcta, unha resposta en 20 ms ou unha resposta en 5 ms. Depende de ti adaptar o seu SLA ao teu propio SLA e ás túas propias métricas.
Unha vez que teñas todo isto claro, podes comezar a crear un panel xenial. Alguén usou xa a aplicación de visualización interactiva Grafana? Xenial! Son un gran fan desta ferramenta de código aberto porque é gratuíta e fácil de usar.
Se aínda non usaches Grafana, vouche dicir como traballar con ela. Calquera persoa nacida nos anos 80 e 90 probablemente lembre os CareBears. Non sei o populares que eran estes osos en Rusia, pero no que respecta ás métricas, deberiamos ser coma os CareBears. Como dixen, necesitas unha imaxe completa de todo o sistema e non debería centrarse só na túa API, no teu sitio web ou nun servizo que se executa nunha máquina virtual.
Deberías organizar o conxunto de métricas que reflictan mellor o rendemento de todo o sistema. A maioría de vós sodes desenvolvedores de software, polo que a vosa vida está en constante cambio, adaptándose aos novos requisitos do produto, e do mesmo xeito que vos preocupa o proceso de codificación, deberíades preocuparvos polas métricas. Deberíades saber como unha métrica afecta a cada liña de código que escribides. Por exemplo, imaxinade que lanzades unha nova campaña de mercadotecnia a próxima semana e esperades que un gran número de usuarios visiten o voso sitio web. Para analizar este evento, necesitaredes métricas e quizais incluso un panel completo para rastrexar a actividade destes usuarios. Necesitaredes métricas para comprender o éxito da vosa campaña de mercadotecnia e o seu rendemento real. Axudarante, por exemplo, a desenvolver un sistema CRM (xestión de relacións cos clientes) eficaz.
Entón, imos comezar co noso servizo na nube de Azure. É moi doado atopar e organizar a colección de métricas porque inclúe Azure Monitor. Este monitor centraliza a xestión da configuración do teu sistema. Cada elemento de Azure que queiras usar no teu sistema ten unha variedade de métricas activadas por defecto. Esta aplicación gratuíta funciona de inmediato e non require configuración previa; non necesitas escribir nin configurar nada. Verémolo por nós mesmos na seguinte demostración.
Ademais, é posible enviar estas métricas a aplicacións de terceiros, como o sistema de almacenamento e análise de rexistros Splunk, a aplicación de xestión de rexistros na nube SumoLogic, a ferramenta de procesamento de rexistros ELK e IBM Radar. Non obstante, existen algunhas pequenas diferenzas dependendo dos recursos que se estean a usar (máquinas virtuais, servizos de rede e bases de datos SQL de Azure), o que significa que o uso de métricas varía segundo as características do ambiente de produción. Aínda que estas diferenzas non son significativas, por desgraza seguen presentes e deben terse en conta. A activación e o reenvío de métricas é posible de varias maneiras: a través do Portal, CLI/Power Shell ou mediante modelos ARM.
Antes de comezar a nosa primeira demostración, gustaríame responder a calquera pregunta que poidas ter. Se non tes ningunha, imos comezar. Esta pantalla mostra o aspecto da páxina de Azure Monitor. Pode alguén dicirme se este monitor non funciona?
Entón, agora todo está en orde; podes ver como son os servizos do monitor. Podo dicir que esta é unha ferramenta excelente e moi sinxela para o traballo diario. Pódese usar para monitorizar aplicacións, a rede e a infraestrutura. A interface de monitorización mellorouse recentemente e, mentres que antes os servizos estaban situados en diferentes lugares, agora toda a información do servizo está consolidada na páxina de inicio do monitor.
A táboa de métricas é unha lapela na ruta HomeMonitorMetrics. Podes abrila para ver todas as métricas dispoñibles e seleccionar as que precises. Non obstante, se necesitas activar a recollida de métricas, usa a ruta do directorio de configuración de HomeMonitorDiagnostic e marca as caixas de verificación Métricas activadas/desactivadas. Por defecto, case todas as métricas están activadas, pero se necesitas activar métricas adicionais, terás que cambiar o estado do diagnóstico de Desactivado a Activado.
Para iso, fai clic na fila da métrica seleccionada e activa o modo de diagnóstico na lapela que se abre. Se queres analizar a métrica seleccionada, despois de facer clic na ligazón "Activar diagnóstico", marca a caixa de verificación "Enviar a Log Analytics" na xanela que aparece.
Log Analytics é algo semellante a Splunk, pero a un custo menor. Este servizo permíteche recompilar todas as túas métricas, rexistros e calquera outra cousa que necesites e almacenalos no espazo de traballo de Log Analytics. O servizo usa unha linguaxe de consulta especial, KQL (Kusto Quarry Language), que exploraremos na seguinte demostración. Por agora, só mencionarei que che permite crear consultas para métricas, rexistros, termos, tendencias, patróns, etc., e crear paneis.
Entón, marcamos a caixa de verificación "Enviar a Log Analytics" e as caixas de verificación do panel LOG: DataPlaneRequests, MongoRequests e QueryRuntimeStatistics, e debaixo diso, no panel METRIC, marcamos a caixa de verificación "Solicitudes". Despois asignamos un nome e gardamos a configuración. Na liña de comandos, son só dúas liñas de código. Por certo, o shell de Azure Cloud é similar ao de Google neste aspecto, o que tamén che permite usar a liña de comandos no teu navegador web. AWS non ten nada semellante, polo que Azure é moito máis cómodo neste sentido.
Например, я могу запустить демо через веб-интерфейс, не используя для этого никакого кода на своем ноутбуке. Для этого я должен пройти аутентификацию с помощью своего аккаунта Azure. Далее можно использовать, например, terrafone, если вы им уже пользуетесь, дождаться подключения к сервису и получить рабочую среду Linux, которую Microsoft использует по умолчанию.
A continuación, uso Bash, integrado en Azure Cloud Shell. O IDE integrado no navegador, unha versión lixeira de VS Code, é moi útil. Despois, podo ir ao meu modelo de métricas de erros, editalo e personalizalo para que se adapte ás miñas necesidades.
Ao configurar a recollida de métricas neste modelo, podes usalo para xerar métricas para toda a túa infraestrutura. Unha vez que apliquemos, recompilemos e gardemos as métricas, teremos que visualizalas.
Azure Monitor só supervisa as métricas e non ofrece unha imaxe completa do estado do sistema. É posible que teñas outras aplicacións executándose fóra do entorno de Azure. Polo tanto, se necesitas supervisar todos os procesos e visualizar todas as métricas recollidas nun só lugar, Azure Monitor non é a solución axeitada.
Para abordar este problema, Microsoft ofrece Power BI, un software completo de análise empresarial que inclúe a visualización dunha ampla variedade de datos. É un produto bastante caro, cuxo prezo depende das funcionalidades que precises. Por defecto, ofrece 48 tipos de datos procesados e está vinculado a Azure SQL Data Warehouse, Azure Data Lake Storage, Azure Machine Learning Services e Azure Databricks. Mediante a escalabilidade, podes recibir novos datos cada 30 minutos. Isto pode ser suficiente para as túas necesidades, pero pode non ser suficiente se necesitas visualización de monitorización en tempo real. Neste caso, recoméndanse aplicacións como Grafana, que mencionei. A documentación de Microsoft tamén describe a capacidade de enviar métricas, rexistros e táboas de eventos mediante ferramentas SIEM a sistemas de visualización como Splunk, SumoLogic, ELK e IBM Radar.
23:40 min
Para continuar moi pronto...
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com
