Recentemente, David O'Brien fundou sua própria empresa Xirus (https://xirus.com.au), com foco em produtos de nuvem do Microsoft Azure Stack. Eles são projetados para a criação e execução consistente de aplicativos híbridos em data centers, locais de borda, escritórios remotos e na nuvem.
David ensina indivíduos e empresas tudo relacionado ao Microsoft Azure e Azure DevOps (anteriormente VSTS) e ainda atua com consultoria prática e infraestrutura como código. Ele é detentor do prêmio Microsoft MVP (Most Valuable Professional) há 5 anos e recentemente recebeu o prêmio MVP Azure. Como co-organizador do Melbourne Microsoft Cloud e Datacentre Meetup, O'Brien frequentemente fala em conferências internacionais, unindo seu interesse em viajar pelo mundo com a paixão de compartilhar histórias de TI com a comunidade. O blog de David está em , ele também publica seus treinamentos online no Pluralsight.
A apresentação aborda a importância das métricas para entender o que está acontecendo em seu ambiente e como seu aplicativo funciona. O Microsoft Azure possui uma maneira poderosa e simples de exibir métricas para todos os tipos de cargas de trabalho, e a palestra discute como você pode aproveitá-las.
Às 3 da manhã de um domingo, enquanto você dorme, uma mensagem de texto o acorda repentinamente: "o aplicativo crítico novamente não responde". O que está acontecendo? Onde e qual é a causa dos "atrasos"? Nesta apresentação, você aprenderá sobre os serviços que o Microsoft Azure oferece aos clientes para coletar logs e, em particular, métricas de suas cargas de trabalho na nuvem. David explicará quais métricas devem interessá-lo ao trabalhar na plataforma de nuvem e como acessá-las. Você aprenderá sobre ferramentas de código aberto e como construir painéis de monitoramento, adquirindo conhecimento suficiente para criar seus próprios painéis.
E se você for novamente acordado às 3 da manhã por uma mensagem sobre a falha de um aplicativo crítico, poderá rapidamente entender a causa disso.
Bom dia, hoje vamos falar sobre métricas. Meu nome é David O’Brien, sou co-fundador e proprietário de uma pequena empresa de consultoria australiana chamada Xirus. Mais uma vez, obrigado por estarem aqui para passar seu tempo comigo. Então, por que estamos aqui? Para falar sobre métricas; na verdade, eu irei explicar sobre elas, e antes de fazermos qualquer coisa, começaremos com a teoria.
Vou explicar o que são métricas, o que pode ser feito com elas, no que devemos prestar atenção, como coletar e incorporar a coleta de métricas no Azure e o que é a visualização de métricas. Eu irei mostrar como essas coisas aparecem na nuvem da Microsoft e como trabalhar com essa nuvem.
Antes de começar, eu peço que levantem as mãos aqueles que usam o Microsoft Azure. E quem trabalha com AWS? Vejo que poucos. E com Google? ALI Cloud? Uma pessoa! Ótimo. Então, o que são métricas? A definição oficial do Instituto Nacional de Padrões e Tecnologia dos EUA é: "Métrica é um padrão de medição que descreve as condições e regras para a realização da medição de uma propriedade qualquer e serve para compreender os resultados da medição". O que isso significa?
Vamos considerar como exemplo uma métrica para a mudança no espaço livre em disco de uma máquina virtual. Por exemplo, nos é dado o número 90, e esse número representa uma porcentagem, ou seja, o volume de espaço livre em disco é de 90%. Vale ressaltar que não é muito interessante ler a descrição da definição de métricas, que ocupa 40 páginas em formato PDF.
No entanto, a métrica não informa como o resultado da medição foi obtido, apenas mostra esse resultado. O que fazemos com as métricas?
Primeiramente, medimos o valor de algo para então usar o resultado da medição.
Por exemplo, aprendemos sobre a quantidade de espaço livre no disco e agora podemos usá-lo, utilizando essa memória etc. Depois de obtermos o resultado da métrica, precisamos interpretá-lo. Por exemplo, a métrica retornou um resultado de 90. Precisamos saber o que esse número significa: a quantidade de espaço livre ou a quantidade de espaço ocupado no disco em porcentagens ou gigabytes, a latência da rede, que é de 90 ms, e assim por diante. Ou seja, precisamos entender o significado do valor da métrica. Para que as métricas tenham sentido, depois de interpretar um valor de métrica, precisamos garantir a coleta de muitos valores. Isso é muito importante, pois muitas pessoas não percebem a necessidade de coletar métricas. A Microsoft facilitou muito o processo de obtenção de métricas, mas você deve garantir a sua coleta. Essas métricas são armazenadas por apenas 41 dias e no 42º dia desaparecem. Portanto, dependendo das características do seu hardware externo ou interno, você deve se preocupar em como armazenar as métricas por mais de 41 dias — em forma de logs, registros etc. Assim, após a coleta, você deve colocá-los em algum lugar que permita recuperar toda a estatística das alterações nos resultados das métricas, sempre que necessário. Ao colocá-los ali, você poderá começar a trabalhar com eles de maneira eficaz.
Somente após obter os valores das métricas, interpretá-los e coletá-los é que você poderá criar um SLA – Acordo de Nível de Serviço. Esse SLA pode não ter um significado especial para seus clientes, mas é mais importante para seus colegas, gerentes, aqueles que mantêm o funcionamento do sistema e se preocupam com sua funcionalidade. A métrica pode medir o número de tickets — por exemplo, você recebe 5 tickets por dia, e nesse caso ela mostra a velocidade de resposta às solicitações dos usuários e a rapidez na resolução de problemas. A métrica não deve apenas informar que seu site carrega em 20 ms ou que a velocidade de resposta é de 20 ms; a métrica é mais do que apenas um indicador técnico.
Portanto, o objetivo da nossa conversa é apresentar a você um panorama abrangente da essência das métricas. A métrica serve para que, ao olhá-la, você possa obter uma imagem completa do processo.
Assim que recebemos a métrica, podemos garantir 99% de funcionamento do sistema, pois não se trata apenas de olhar para o log que diz que o sistema está funcionando. A garantia de 99% de operação significa que, por exemplo, em 99% das vezes a API responde com uma velocidade normal de 30 ms. Esse é exatamente o ponto que interessa aos seus usuários, colegas e gerentes. Muitos de nossos clientes monitoram os logs dos servidores web e não percebem erros, acreditando que tudo está bem. Por exemplo, eles veem uma taxa de velocidade de rede de 200 mb/s e pensam: "tudo ótimo!". Mas para alcançar esses 200, os usuários precisam de um tempo de resposta de 30 milissegundos, e essa é a métrica que não é medida e não é coletada nos logs. Enquanto isso, os usuários ficam surpresos com a lentidão do site, pois, sem a métrica necessária, não sabem a razão desse comportamento.
Mas como temos um SLA que garante 100% de operação, os clientes começam a ficar insatisfeitos, pois na realidade o site é muito difícil de usar. Portanto, para criar um SLA objetivo, é necessário ter uma visão completa do processo, criada pelas métricas coletadas. Isso é algo que discuto constantemente com alguns provedores, que ao criar um SLA não compreendem o que significa o termo "uptime" e, na maioria das vezes, não explicam aos seus clientes como sua API funciona.
Se você criou um serviço, por exemplo, uma API para terceiros, deve entender o que significa a métrica obtida de 39,5 – uma resposta, resposta bem-sucedida, resposta a uma velocidade de 20 ms ou a uma velocidade de 5 ms. É você quem deve adaptar seu SLA ao seu próprio SLA, às suas próprias métricas.
Depois de descobrir tudo isso, você pode começar a criar um painel de monitoramento incrível. Alguém já usou o aplicativo de visualização interativa Grafana? Excelente! Sou um grande fã desse open source, porque é gratuito e fácil de usar.
Se você ainda não usou o Grafana, vou explicar como trabalhar com ele. Quem nasceu nos anos 80 e 90 provavelmente se lembra dos carinhosos ursinhos CareBears? Não sei quão populares esses ursinhos eram na Rússia, mas em relação às métricas devemos nos comportar como os "ursinhos carinhosos". Como mencionei, você precisa de uma visão abrangente do funcionamento de todo o sistema, e isso não deve se restringir apenas ao seu API, ao seu site ou ao serviço rodando em uma máquina virtual.
Você deve organizar a coleta das métricas que melhor refletem o funcionamento de todo o sistema. A maioria de vocês são desenvolvedores de software, então sua vida está em constante mudança para se adaptar às novas demandas do produto, e assim como você se preocupa com os processos de codificação, deve se preocupar com as métricas. Você precisa entender como cada métrica se relaciona com cada linha de código que você escreveu. Por exemplo, na próxima semana você começará uma nova campanha de marketing e espera que seu site receba um grande número de visitantes. Para analisar esse evento, você precisará de métricas e talvez precise de um painel inteiro para acompanhar a atividade dessas pessoas. As métricas serão necessárias para que você entenda quão bem-sucedida é e como realmente funciona a sua campanha de marketing. Elas podem ajudá-lo, por exemplo, a desenvolver um sistema eficaz de CRM — gerenciamento de relacionamento com o cliente.
Vamos começar com nosso serviço em nuvem Azure. É muito fácil encontrar e organizar a coleta de métricas lá, porque existe o Azure Monitor. Este monitor centraliza o gerenciamento da configuração do seu sistema. Cada um dos elementos do Azure que você deseja aplicar em seu sistema possui várias métricas já habilitadas por padrão. É um aplicativo gratuito que funciona "fora da caixa" e não requer qualquer configuração prévia; você não precisa escrever nada e não precisa "anexar" nada ao seu sistema. Vamos confirmar isso ao assistir à próxima demonstração.
Além disso, é possível enviar essas métricas para aplicativos de terceiros, como o sistema de armazenamento e análise de logs Splunk, o aplicativo de gerenciamento de logs em nuvem SumoLogic, a ferramenta de processamento de logs ELK e o IBM Radar. No entanto, existem pequenas diferenças que dependem dos recursos que você está utilizando – máquinas virtuais, serviços de rede, bancos de dados Azure SQL, ou seja, o uso das métricas varia de acordo com as funcionalidades do seu ambiente de trabalho. Não diria que essas diferenças são significativas, mas, infelizmente, elas estão presentes e devem ser levadas em consideração. A ativação e o envio de métricas podem ser feitos de várias maneiras: através do Portal, CLI/Power Shell ou usando modelos ARM.
Antes de começarmos a primeira demonstração, vou responder às perguntas que vocês têm. Se não houver perguntas, vamos em frente. Na tela, você pode ver como é a página do Azure Monitor. Alguém pode dizer que esse monitor não está funcionando?
Então, agora está tudo certo, vocês veem como os serviços do monitor parecem. Posso dizer que é uma ferramenta excelente e muito simples para o dia a dia. Com ela, é possível monitorar aplicativos, redes e infraestrutura. Recentemente, a interface de monitoramento foi aprimorada, e se antes os serviços estavam em lugares diferentes, agora todas as informações sobre os serviços estão consolidadas na página inicial do monitor.
A tabela de métricas é a aba no caminho HomeMonitorMetrics, onde você pode acessá-la para ver todas as métricas disponíveis e selecionar as necessárias. Mas se você precisar ativar a coleta de métricas, deve usar o caminho do diretório HomeMonitorDiagnostic settings e verificar as caixas de seleção das métricas Ativado/Desativado. Por padrão, praticamente todas as métricas estão ativadas, mas se precisar ativar algo adicional, será necessário alterar o status de diagnóstico de Desativado para Ativado.
Para isso, você deve clicar na linha da métrica selecionada e, na aba que se abrir, ativar o modo de diagnóstico. Se você vai analisar a métrica escolhida, após clicar no link Ativar diagnóstico, é necessário marcar a caixa de seleção Enviar para Log Analytics na janela que aparecer.
Log Analytics é um pouco semelhante ao Splunk, mas custa menos. Este serviço permite coletar todas as suas métricas, logs e tudo o que você precisa, e armazená-los no espaço de trabalho do Log Analytics. O serviço utiliza uma linguagem de consulta chamada KQL – Kusto Query Language, cuja operação iremos explorar na próxima demonstração. Enquanto isso, é importante notar que, com ela, você pode criar consultas relativas a métricas, logs, termos, tendências, padrões, etc., e criar painéis de monitoramento.
Assim, marcamos a caixa de seleção Send to Log Analytics e as caixas de seleção do painel LOG: DataPlaneRequests, MongoRequests e QueryRuntimeStatistics, e, abaixo, no painel METRIC, marcamos a caixa de seleção Requests. Em seguida, atribuímos um nome e salvamos as configurações. No terminal, isso representa duas linhas de código. Aliás, o shell do Azure Cloud nesse sentido é parecido com o Google, que também permite usar o terminal no seu navegador. A AWS não tem nada parecido, então o Azure é muito mais conveniente nesse aspecto.
Por exemplo, posso executar uma demonstração através da interface web, sem usar nenhum código no meu notebook. Para isso, preciso me autenticar com a minha conta do Azure. Depois, posso usar, por exemplo, terrafone, se já o estiver utilizando, esperar pela conexão ao serviço e obter um ambiente Linux que a Microsoft utiliza por padrão.
Em seguida, utilizo o Bash embutido no Azure Cloud Shell. Uma funcionalidade muito útil é o IDE embutido no navegador, uma versão simplificada do VS Code. Depois, posso acessar meu modelo de métrica de erros, alterá-lo e adaptá-lo às minhas necessidades.
Depois de configurar a coleta de métricas nesse modelo, você pode aplicá-lo para criar métricas para toda a sua infraestrutura. Após aplicarmos as métricas, coletá-las e salvá-las, precisaremos visualizá-las.
O Azure Monitor lida apenas com métricas e não fornece uma visão geral do estado do seu sistema. Você pode estar usando uma série de outros aplicativos que estão em execução fora do ambiente Azure. Portanto, se precisar monitorar todos os processos, visualizando todas as métricas coletadas em um só lugar, o Azure Monitor não servirá para isso.
Para resolver essa tarefa, a Microsoft oferece a ferramenta Power BI – um software abrangente para análise de negócios, que inclui visualização de uma variedade de dados. Este é um produto bastante caro, com o preço variando conforme o conjunto de funcionalidades que você precisa. Por padrão, ele oferece 48 tipos de dados processáveis e está integrado aos armazéns de dados SQL Azure, Azure Data Lake Storage, serviços de machine learning do Azure e Azure Databricks. Com a escalabilidade, você pode obter novos dados a cada 30 minutos. Isso pode ser suficiente para suas necessidades ou não, se você precisar de visualização de monitoramento em tempo real. Nesse caso, é recomendável usar aplicativos como o Grafana que mencionei. Além disso, a documentação da Microsoft descreve a possibilidade de enviar métricas, logs e tabelas de eventos com o auxílio de SIEM – ferramentas para sistemas de visualização, como Splunk, SumoLogic, ELK e IBM Radar.
23:40 min
A continuação virá em breve…
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
