David O'Brien lançou recentemente sua própria empresa, a Xirus (https://xirus.com.au), focada em produtos de nuvem do Microsoft Azure Stack. Esses produtos são projetados para criar e executar aplicações híbridas de forma integrada em data centers, locais de borda, escritórios remotos e na nuvem.
David oferece treinamento para indivíduos e empresas em todos os aspectos do Microsoft Azure e Azure DevOps (anteriormente VSTS) e continua atuando como consultor prático e desenvolvedor de infraestrutura. Ele é um Microsoft MVP (Most Valuable Professional) há cinco anos e recebeu recentemente o prêmio Azure MVP. Como coorganizador do Melbourne Microsoft Cloud and Datacenter Meetup, O'Brien participa regularmente de conferências internacionais, combinando seu interesse em viajar pelo mundo com sua paixão por compartilhar histórias de TI com a comunidade. O blog de David está localizado em [inserir URL aqui]. Ele também publica seus treinamentos online na Pluralsight.
Esta palestra explora a importância das métricas para entender o que está acontecendo em seu ambiente e como seu aplicativo está performando. O Microsoft Azure oferece uma maneira poderosa e fácil de usar para exibir métricas para todos os tipos de cargas de trabalho, e a palestra aborda como utilizá-las.
Às 3 da manhã de um domingo, você é repentinamente acordado por uma mensagem de texto: "Um aplicativo crítico está apresentando problemas novamente." O que está acontecendo? Onde está a lentidão e o que a está causando? Nesta palestra, você aprenderá sobre os serviços que o Microsoft Azure oferece aos clientes para coletar logs e, em particular, métricas para suas cargas de trabalho na nuvem. David explicará quais métricas são relevantes para você ao trabalhar na plataforma de nuvem e como acessá-las. Você aprenderá sobre ferramentas de código aberto e criação de dashboards e, por fim, adquirirá o conhecimento necessário para criar seus próprios dashboards.
E se você for acordado às 3 da manhã novamente por uma mensagem sobre uma falha crítica de um aplicativo, poderá descobrir rapidamente a causa.
Boa tarde, hoje vamos falar sobre métricas. Meu nome é David O'Brien e sou cofundador e proprietário da Xirus, uma pequena empresa de consultoria australiana. Agradeço novamente por estarem aqui e dedicarem seu tempo a mim. Então, por que estamos aqui? Para falar sobre métricas, ou melhor, para explicar o que são métricas. Antes de começarmos, vamos abordar um pouco de teoria.
Vou explicar o que são métricas, o que você pode fazer com elas, a que você precisa prestar atenção, como coletar e habilitar métricas no Azure e o que é visualização de métricas. Vou mostrar como essas coisas se parecem na nuvem da Microsoft e como trabalhar com ela.
Antes de começar, gostaria de pedir que levantem a mão aqueles que usam o Microsoft Azure. Quem usa a AWS? Vejo que não muitos. E o Google? Ali Cloud? Uma pessoa! Excelente. Então, o que são métricas? A definição oficial do Instituto Nacional de Padrões e Tecnologia (NIST) é: "Uma métrica é um padrão de medição que descreve as condições e regras para realizar a medição de uma propriedade e serve para entender os resultados da medição." O que isso significa?
Vamos usar como exemplo uma métrica para a variação do espaço livre em disco de uma máquina virtual. Digamos que obtemos o número 90, que representa uma porcentagem, significando que o espaço livre no disco é de 90%. Vale ressaltar que a descrição da definição da métrica, que ocupa 40 páginas em formato PDF, não é particularmente interessante de ler.
No entanto, uma métrica não nos diz como o resultado da medição foi obtido; ela apenas mostra esse resultado. Então, o que fazemos com as métricas?
Primeiro, medimos o valor de algo para depois usar o resultado dessa medição.
Por exemplo, sabemos a quantidade de espaço livre em disco que podemos usar, a quantidade de memória disponível, etc. Após recebermos o resultado de uma métrica, precisamos interpretá-lo. Por exemplo, se uma métrica retornou o valor 90, precisamos saber o que esse número significa: a quantidade de espaço livre ou a quantidade de espaço em disco usado em porcentagem ou gigabytes, uma latência de rede de 90 ms, e assim por diante. Em outras palavras, precisamos interpretar o significado do valor da métrica. Para que as métricas sejam realmente úteis, após interpretar o valor de uma métrica, precisamos garantir que vários valores sejam coletados. Isso é muito importante, pois muitas pessoas não percebem a necessidade de coletar métricas. A Microsoft facilitou bastante a obtenção de métricas, mas você precisa garantir que elas sejam coletadas por conta própria. Essas métricas são armazenadas por apenas 41 dias e desaparecem no 42º dia. Portanto, dependendo das características do seu hardware externo ou interno, você deve considerar como armazenar métricas por mais de 41 dias — na forma de logs, registros, etc. Após coletá-las, você deve armazená-las em um local que permita recuperar todas as estatísticas sobre as alterações nos resultados das métricas, se necessário. Uma vez armazenadas, você poderá começar a trabalhar com elas de forma eficaz.
Somente após coletar, interpretar e agregar os valores das métricas é que você pode criar um SLA – um acordo de nível de serviço. Esse SLA pode não ser particularmente significativo para seus clientes; ele é mais importante para seus colegas, gerentes e para aqueles que mantêm o sistema e se preocupam com sua funcionalidade. Uma métrica pode medir o número de chamados – por exemplo, se você recebe cinco chamados por dia, isso indicaria a velocidade de resposta às solicitações dos usuários e a velocidade de resolução de problemas. Uma métrica não deve simplesmente relatar que seu site carrega em 20 ms ou que o tempo de resposta é de 20 ms; uma métrica é mais do que apenas um indicador técnico isolado.
Portanto, o objetivo da nossa conversa é proporcionar a você uma compreensão abrangente da essência das métricas. Uma métrica é projetada para ajudá-lo a obter uma visão completa de um processo simplesmente observando-o.
Assim que recebermos a métrica, podemos garantir 99% de tempo de atividade do sistema, pois não se trata apenas de um arquivo de log indicando que o sistema está funcionando. Uma garantia de 99% de tempo de atividade significa, por exemplo, que em 99% das vezes a API responde em um tempo normal de 30 ms. Isso é exatamente o que seus usuários, colegas e gerentes desejam. Muitos de nossos clientes monitoram os logs do servidor web, mas não percebem nenhum erro e presumem que tudo está bem. Por exemplo, eles veem uma velocidade de rede de 200 Mbps e pensam: "Ótimo, tudo perfeito!". Mas para atingir 200 Mbps, os usuários exigem um tempo de resposta de 30 milissegundos, e essa é justamente a métrica que não é medida ou coletada nos arquivos de log. Os usuários ficam surpresos com a lentidão no carregamento do site porque, sem as métricas necessárias, não sabem o motivo desse comportamento.
Mas, como temos um SLA que garante 100% de disponibilidade, os clientes estão começando a reclamar porque o site é, na verdade, muito difícil de usar. Portanto, para criar um SLA objetivo, é necessário ter uma visão completa do processo, conforme capturada pelas métricas coletadas. Este é um ponto constante de discórdia com alguns provedores que, ao criarem seus SLAs, não entendem o termo "disponibilidade" e, na maioria dos casos, 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 resultante de 39,5 — uma resposta, uma resposta bem-sucedida, uma resposta em 20 ms ou uma resposta em 5 ms. Cabe a você adaptar o SLA deles ao seu próprio SLA e às suas próprias métricas.
Depois de entender tudo isso, você pode começar a criar um painel incrível. Alguém já usou o aplicativo de visualização interativa Grafana? Ótimo! Sou fã dessa ferramenta de código aberto porque é gratuita e fácil de usar.
Se você ainda não usou o Grafana, vou te explicar como trabalhar com ele. Quem nasceu nas décadas de 80 e 90 provavelmente se lembra dos Ursinhos Carinhosos. Não sei o quão populares esses ursinhos eram na Rússia, mas quando se trata de métricas, devemos ser como os Ursinhos Carinhosos. Como eu disse, você precisa de uma visão abrangente de todo o sistema, e ela não deve se concentrar apenas na sua API, no seu site ou em um serviço rodando em uma máquina virtual.
Você deve organizar a coleção de métricas que melhor reflita o desempenho de todo o sistema. A maioria de vocês são desenvolvedores de software, então suas vidas estão em constante mudança, adaptando-se a novos requisitos de produto, e assim como vocês se importam com o processo de codificação, devem se importar com as métricas. Vocês devem saber como uma métrica afeta cada linha de código que escrevem. Por exemplo, vocês estão lançando uma nova campanha de marketing na próxima semana e esperam um grande número de usuários visitando seu site. Para analisar esse evento, vocês precisarão de métricas e talvez até mesmo de um painel completo para acompanhar a atividade desses usuários. Vocês precisarão de métricas para entender o sucesso da sua campanha de marketing e como ela está performando na prática. Elas ajudarão vocês, por exemplo, a desenvolver um sistema de CRM (gestão de relacionamento com o cliente) eficaz.
Então, vamos começar com o nosso serviço de nuvem Azure. É muito fácil encontrar e organizar a coleta de métricas, pois ele inclui o Azure Monitor. Este monitor centraliza o gerenciamento de configuração do seu sistema. Cada elemento do Azure que você deseja usar em seu sistema tem uma variedade de métricas habilitadas por padrão. Este aplicativo gratuito funciona imediatamente e não requer nenhuma configuração prévia; você não precisa escrever ou configurar nada. Veremos isso na demonstração a seguir.
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 algumas pequenas diferenças dependendo dos recursos que você está usando — máquinas virtuais, serviços de rede e bancos de dados SQL do Azure — o que significa que o uso de métricas varia de acordo com os recursos do seu ambiente de produção. Embora essas diferenças não sejam significativas, infelizmente elas ainda existem e devem ser levadas em consideração. Habilitar e encaminhar métricas pode ser feito de várias maneiras: via Portal, CLI/PowerShell ou usando modelos ARM.
Antes de começarmos nossa primeira demonstração, gostaria de responder a quaisquer perguntas que vocês possam ter. Se não tiverem nenhuma, vamos começar. Esta tela mostra a aparência da página do Azure Monitor. Alguém pode me dizer se este monitor não está funcionando?
Então, agora que tudo está em ordem, você pode ver como os serviços de monitoramento se apresentam. Posso afirmar que esta é uma ferramenta excelente e muito simples para o trabalho diário. Ela pode ser usada para monitorar aplicações, a rede e a infraestrutura. A interface de monitoramento foi recentemente aprimorada e, enquanto antes os serviços estavam localizados em diferentes lugares, agora todas as informações de serviço estão consolidadas na página inicial do monitor.
A tabela de métricas é uma aba localizada no caminho HomeMonitorMetrics. Você pode abri-la para visualizar todas as métricas disponíveis e selecionar as que precisa. No entanto, se precisar habilitar a coleta de métricas, use o caminho do diretório de configurações HomeMonitorDiagnostic e marque as caixas de seleção Métricas Ativadas/Desativadas. Por padrão, quase todas as métricas estão ativadas, mas se precisar ativar métricas adicionais, você precisará alterar o status de diagnóstico de Desativado para Ativado.
Para isso, clique na linha da métrica selecionada e ative o modo de diagnóstico na guia que se abre. Se você pretende analisar a métrica selecionada, após clicar no link "Ativar diagnóstico", marque a caixa de seleção "Enviar para o Log Analytics" na janela que aparece.
O Log Analytics é um tanto semelhante ao Splunk, mas com um custo menor. Este serviço permite coletar todas as suas métricas, logs e qualquer outra informação necessária, armazenando-as no espaço de trabalho do Log Analytics. O serviço utiliza uma linguagem de consulta especial, o KQL (Kusto Quarry Language), que exploraremos na próxima demonstração. Por ora, basta mencionar que ele permite criar consultas para métricas, logs, termos, tendências, padrões etc., além de criar dashboards.
Então, marcamos a caixa de seleção "Enviar para o Log Analytics" e as caixas de seleção do painel LOG: DataPlaneRequests, MongoRequests e QueryRuntimeStatistics e, abaixo disso, no painel MÉTRICAS, marcamos a caixa de seleção "Solicitações". Em seguida, atribuímos um nome e salvamos as configurações. Na linha de comando, isso se resume a apenas duas linhas de código. Aliás, o Azure Cloud Shell é semelhante ao do Google nesse aspecto, permitindo também o uso da linha de comando no navegador. A AWS não possui nada similar, portanto o Azure é muito mais conveniente nesse sentido.
Por exemplo, posso executar uma demonstração pela interface web sem escrever nenhum código no meu laptop. Para isso, preciso me autenticar com minha conta do Azure. Depois, se você já usa o Terrafone, pode usá-lo, aguardar a conexão com o serviço e obter um ambiente de trabalho. Linux, que a Microsoft usa por padrão.
Em seguida, utilizo o Bash, integrado ao Azure Cloud Shell. O IDE integrado ao navegador, uma versão simplificada do VS Code, é muito útil. Depois, posso acessar meu modelo de métricas de erro, editá-lo e personalizá-lo de acordo com minhas necessidades.
Ao configurar a coleta de métricas neste modelo, você pode usá-lo para gerar métricas para toda a sua infraestrutura. Depois de aplicar, coletar e salvar as métricas, precisaremos visualizá-las.
O Azure Monitor monitora apenas métricas e não fornece uma visão completa do estado do seu sistema. Você pode ter vários outros aplicativos em execução fora do ambiente do Azure. Portanto, se você precisa monitorar todos os processos e visualizar todas as métricas coletadas em um só lugar, o Azure Monitor não é a solução ideal.
Para solucionar esse problema, a Microsoft oferece o Power BI — um software abrangente de análise de negócios que inclui visualização para uma ampla variedade de dados. É um produto relativamente caro, com preços que variam de acordo com os recursos necessários. Por padrão, oferece 48 tipos de dados processados e está integrado ao Azure SQL Data Warehouse, Azure Data Lake Storage, Azure Machine Learning Services e Azure Databricks. Com a escalabilidade, é possível receber novos dados a cada 30 minutos. Isso pode ser suficiente para suas necessidades, mas pode não ser se você precisar de visualização de monitoramento em tempo real. Nesse caso, recomenda-se o uso de aplicativos como o Grafana, que mencionei. A documentação da Microsoft também descreve a capacidade de enviar métricas, logs e tabelas de eventos usando ferramentas SIEM para sistemas de visualização como Splunk, SumoLogic, ELK e IBM Radar.
23:40 min
Continuará muito em breve...
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com
