David O'Brien lançou recentemente sua própria empresa, Xirus (https://xirus.com.au), com foco em produtos em nuvem Microsoft Azure Stack. Eles são projetados para construir e executar aplicativos híbridos de forma consistente em data centers, pontos de presença, escritórios remotos e na nuvem.
David treina indivíduos e empresas em tudo relacionado ao Microsoft Azure e Azure DevOps (anteriormente VSTS) e ainda faz consultoria prática e infracodificação. Ele foi vencedor do prêmio Microsoft MVP (Microsoft Most Valuable Professional) por 5 anos e recentemente recebeu o prêmio Azure MVP. Como coorganizador do Melbourne Microsoft Cloud and Datacentre Meetup, O'Brien palestra regularmente em conferências internacionais, combinando seu interesse em viajar pelo mundo com a paixão por compartilhar histórias de TI com a comunidade. O blog de David está localizado em , ele também publica seu treinamento online no Pluralsight.
A palestra fala sobre a importância das métricas para entender o que está acontecendo em seu ambiente e como está o desempenho de sua aplicação. O Microsoft Azure tem uma maneira fácil e poderosa de exibir métricas para todos os tipos de cargas de trabalho, e a palestra explica como você pode usar todas elas.
Às 3 da manhã de um domingo, enquanto você dorme, você é subitamente acordado por uma mensagem de texto: “aplicativo supercrítico não responde novamente”. O que está acontecendo? Onde e qual a razão dos “freios”? Nesta palestra, 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 lhe dirá em quais métricas você deve estar interessado ao trabalhar em uma plataforma de nuvem e como acessá-las. Você aprenderá sobre ferramentas de código aberto e criação de painéis e terá conhecimento suficiente para criar seus próprios painéis.
E se você acordar novamente às 3 da manhã com uma mensagem informando que um aplicativo crítico travou, poderá descobrir rapidamente a causa.
Boa tarde, hoje falaremos sobre métricas. Meu nome é David O'Brien, sou cofundador e proprietário de uma pequena empresa de consultoria australiana, a Xirus. Obrigado novamente por vir aqui para passar seu tempo comigo. Então porque estamos aqui? Para falar de métricas, ou melhor, vou falar sobre elas, e antes de fazer qualquer coisa, vamos começar pela teoria.
Vou te contar o que são métricas, o que você pode fazer com elas, no que você precisa prestar atenção, como coletar e habilitar a coleta de métricas no Azure e o que é visualização de métricas. Mostrarei como são essas coisas na nuvem da Microsoft e como trabalhar com essa nuvem.
Antes de começarmos, pedirei que levantem a mão daqueles que usam o Microsoft Azure. Quem trabalha com AWS? Eu vejo poucos. E o Google? ALI Nuvem? Um homem! Ótimo. Então, o que são métricas? A definição oficial do Instituto Nacional de Padrões e Tecnologia dos EUA é: “Uma métrica é um padrão de medição que descreve as condições e regras para medir uma propriedade e serve para compreender os resultados da medição”. O que isso significa?
Vejamos um exemplo de métrica para alterar o espaço livre em disco de uma máquina virtual. Por exemplo, recebemos o número 90, e esse número significa porcentagem, ou seja, a quantidade de espaço livre em disco é 90%. Observo que não é muito interessante ler a descrição da definição de métricas, que ocupa 40 páginas em formato pdf.
Porém, a métrica não diz como o resultado da medição foi obtido, apenas mostra esse resultado. O que fazemos com métricas?
Primeiro, medimos o valor de algo para depois utilizar o resultado da medição.
Por exemplo, descobrimos a quantidade de espaço livre em disco e agora podemos usá-lo, usar essa memória, etc. Depois de recebermos o resultado da métrica, devemos 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 em disco usado em porcentagem ou gigabytes, latência de rede igual a 90 ms e assim por diante, ou seja , precisamos interpretar o significado do valor da métrica. Para que as métricas sejam significativas, depois de interpretar um único valor de métrica, precisamos garantir que vários valores sejam coletados. Isto é muito importante porque muitas pessoas não estão conscientes da necessidade de coletar métricas. A Microsoft tornou muito fácil a coleta de métricas, mas cabe a você garantir que elas sejam coletadas. Essas métricas são armazenadas por apenas 41 dias e desaparecem no 42º dia. Portanto, dependendo das propriedades do seu equipamento externo ou interno, você deve cuidar de como salvar as métricas por mais de 41 dias - na forma de logs, logs, etc. Assim, após a coleta, você deve colocá-los em algum local que permita extrair todas as estatísticas de alterações nos resultados das métricas, se necessário. Depois de colocá-los lá, você poderá começar a trabalhar com eles de maneira eficaz.
Somente depois de obter as métricas, interpretá-las e coletá-las, você poderá criar um SLA – acordo de nível de serviço. Este SLA pode não ter muita importância para seus clientes; é mais importante para seus colegas, gestores, aqueles que fazem a manutenção do sistema e estão preocupados com sua funcionalidade. A métrica pode medir o número de tickets - por exemplo, você recebe 5 tickets por dia e, neste caso, mostra a velocidade de resposta às solicitações dos usuários e a velocidade de solução de problemas. Uma métrica não deve apenas dizer que seu site carrega em 20ms ou que sua velocidade de resposta é de 20ms, uma métrica é mais do que apenas um indicador técnico.
Portanto, a tarefa da nossa conversa é apresentar a você um quadro detalhado da essência das métricas. A métrica serve para que ao observá-la você consiga ter uma visão completa do processo.
Assim que tivermos a métrica, podemos garantir 99% de que o sistema está funcionando, porque não é apenas olhar um arquivo de log que indica que o sistema está funcionando. Uma garantia de 99% de tempo de atividade significa que, por exemplo, 99% do tempo a API responde a uma velocidade normal de 30 ms. É exatamente isso que interessa aos seus usuários, colegas e gestores. Muitos de nossos clientes monitoram os logs do servidor web, mas não percebem nenhum erro neles e pensam que está tudo bem. Por exemplo, eles veem uma velocidade de rede de 200 Mb/s e pensam: “ok, está tudo ótimo!” Mas para atingir esses 200, os usuários precisam de uma velocidade de resposta de 30 milissegundos, e esse é justamente o indicador que não é medido e nem coletado em arquivos de log. Ao mesmo tempo, os usuários se surpreendem com o carregamento muito lento do site, pois, por não possuir as métricas necessárias, não sabem os motivos desse comportamento.
Mas como temos um SLA de 100% de disponibilidade, os clientes começam a reclamar porque o site é realmente muito difícil de usar. Portanto, para criar um SLA objetivo, é necessário ver o panorama completo do processo criado pelas métricas coletadas. Esse é um problema constante que tenho com alguns provedores que, ao criarem SLAs, não têm ideia do que significa o termo “tempo de atividade” e na maioria dos casos não explicam aos seus clientes como funciona sua API.
Se você criou um serviço, por exemplo, uma API para uma terceira pessoa, você deve entender o que significa a métrica resultante de 39,5 - resposta, resposta bem-sucedida, resposta na velocidade de 20 ms ou na velocidade de 5 ms. Cabe a você adaptar o 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 impressionante. Me diga, alguém já usou o aplicativo de visualização interativa Grafana? Ótimo! Sou um grande fã desse código aberto porque é gratuito e fácil de usar.
Se você ainda não usou o Grafana, direi como trabalhar com ele. Qualquer pessoa nascida nas décadas de 80 e 90 provavelmente se lembra dos CareBears? Não sei quão populares eram esses ursos na Rússia, mas quando se trata de métricas, deveríamos ser os mesmos “ursos carinhosos”. Como eu disse, você precisa de uma visão geral de como todo o sistema funciona, e não deve ser apenas sobre sua API, seu site ou o serviço executado em uma máquina virtual.
Você deve organizar a coleta das métricas que refletem mais plenamente a operação de todo o sistema. A maioria de vocês são desenvolvedores de software, então sua vida está em constante mudança, adaptando-se aos novos requisitos do produto, e assim como vocês estão preocupados com os processos de codificação, vocês deveriam se preocupar com as métricas. Você precisa saber como a métrica se relaciona com cada linha de código que você escreve. Por exemplo, na próxima semana você iniciará uma nova campanha de marketing e espera que um grande número de usuários visite seu site. Para analisar esse evento, você precisará de métricas e poderá precisar de um painel completo para rastrear a atividade dessas pessoas. Você precisará de métricas para entender o quão bem-sucedida é sua campanha de marketing e como ela está realmente funcionando. Eles irão ajudá-lo, por exemplo, a desenvolver um CRM - sistema de gerenciamento de relacionamento com o cliente eficaz.
Então, vamos começar com nosso serviço de nuvem Azure. É muito fácil encontrar e organizar a coleta de métricas porque possui Azure Monitor. Este monitor centraliza o gerenciamento da configuração do seu sistema. Cada um dos elementos Azure que pretende aplicar ao seu sistema tem muitas métricas ativadas por padrão. Este é um aplicativo gratuito que funciona imediatamente e não requer nenhuma configuração preliminar; você não precisa escrever ou “parafusar” nada em seu sistema. Verificaremos isso observando a 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 baseado em nuvem SumoLogic, a ferramenta de processamento de logs ELK e o IBM Radar. É verdade que existem pequenas diferenças que dependem dos recursos que você usa - uma máquina virtual, serviços de rede, bancos de dados SQL do Azure, ou seja, o uso de métricas difere dependendo das funções do seu ambiente de trabalho. Não direi que estas diferenças sejam graves, mas, infelizmente, ainda estão presentes e isso deve ser levado em conta. Habilitar e enviar métricas é possível de diversas maneiras: através do Portal, CLI/Power Shell ou usando modelos ARM.
Antes de começar minha primeira demonstração, responderei a quaisquer perguntas que você possa ter. Se não houver dúvidas, vamos começar. A tela mostra a aparência da página do Azure Monitor. Algum de vocês pode dizer que este monitor não está funcionando?
Então agora está tudo bem, você pode ver como são os serviços do monitor. Posso dizer que se trata de uma ferramenta excelente e muito simples para o trabalho do dia a dia. Pode ser usado para monitorar aplicações, redes e infraestrutura. Recentemente, a interface de monitoramento foi aprimorada, e se antes os serviços estavam localizados em locais diferentes, agora todas as informações dos serviços estão consolidadas na página inicial do monitor.
A tabela de métricas é uma guia ao longo do caminho HomeMonitorMetrics, que você pode acessar para ver todas as métricas disponíveis e selecionar aquelas que você precisa. Mas se precisar habilitar a coleta de métricas, você precisará usar o caminho do diretório de configurações HomeMonitorDiagnostic e marcar as caixas de seleção de métricas Ativadas/Desativadas. Por padrão, quase todas as métricas estão habilitadas, mas se precisar habilitar algo adicional, você precisará alterar o status do diagnóstico de Desativado para Ativado.
Para isso, clique na linha da métrica selecionada e na aba que se abre, habilite o modo de diagnóstico. Se você for analisar a métrica selecionada, depois de clicar no link Ativar diagnóstico, será necessário marcar a caixa de seleção Enviar para Log Analytics na janela que aparece.
Log Analytics é um pouco semelhante ao Splunk, mas custa menos. Este serviço permite coletar todas as suas métricas, logs e tudo o mais que você precisa e colocá-los no espaço de trabalho do Log Analytics. O serviço usa uma linguagem especial de processamento de consultas KQL - Kusto Quarry Language, veremos seu trabalho na próxima demonstração. Por enquanto, observo que com sua ajuda você pode criar consultas sobre métricas, logs, termos, tendências, padrões, etc. e criar painéis.
Assim, marcamos a caixa de seleção Enviar para Log Analytics e as caixas de seleção do painel LOG: DataPlaneRequests, MongoRequests e QueryRuntimeStatistics, e abaixo no painel METRIC – a caixa de seleção Solicitações. Em seguida, atribuímos um nome e salvamos as configurações. Na linha de comando, isso representa duas linhas de código. A propósito, o Azure Cloud Shell nesse sentido se assemelha ao Google, que também permite que você use a linha de comando em seu navegador. A AWS não tem nada parecido, então o Azure é muito mais conveniente nesse sentido.
Por exemplo, posso executar uma demonstração por meio da interface da web sem usar nenhum código no meu laptop. Para fazer isso, preciso me autenticar com minha conta do Azure. Depois você pode usar, por exemplo, o terrafone, se já usa, aguarde a conexão com o serviço e obtenha o ambiente de trabalho Linux que a Microsoft usa por padrão.
Em seguida, uso o Bash, integrado ao Azure Cloud Shell. Uma coisa muito útil é o IDE embutido no navegador, uma versão leve do VS Code. Em seguida, posso acessar meu modelo de métricas de erro, editá-lo e personalizá-lo para atender às minhas necessidades.
Depois de configurar a coleta de métricas neste modelo, você poderá usá-lo para criar métricas para toda a sua infraestrutura. Depois de aplicarmos as métricas, coletá-las e armazená-las, precisaremos visualizá-las.
O Azure Monitor lida apenas com métricas e não fornece uma imagem geral da saúde do seu sistema. Você pode ter vários outros aplicativos em execução fora do ambiente do Azure. Então se você precisa monitorar todos os processos, visualizando todas as métricas coletadas em um só lugar, então o Azure Monitor não é adequado para isso.
Para resolver esse problema, a Microsoft oferece a ferramenta Power BI, um software abrangente de análise de negócios que inclui a visualização de uma ampla variedade de dados. Este é um produto bastante caro, cujo custo depende do conjunto de funções que você precisa. Por padrão, ele oferece 48 tipos de dados para processar e está vinculado ao Azure SQL Data Warehouses, ao Azure Data Lake Storage, ao Azure Machine Learning Services e ao Azure Databricks. Usando escalabilidade, você pode receber novos dados a cada 30 minutos. Isso pode ou não ser suficiente para suas necessidades se você precisar de visualização de monitoramento em tempo real. Neste caso, é recomendável utilizar aplicativos como o Grafana que mencionei. Além disso, a documentação da Microsoft descreve a capacidade de enviar métricas, logs e tabelas de eventos usando ferramentas SIEM para os sistemas de visualização Splunk, SumoLogic, ELK e radar IBM.
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