Compartilhar via

Observabilidade de serviços do Kubernetes habilitado para Azure Arc

  • Artigo

A observabilidade é uma característica do aplicativo que se refere ao nível de compreensão do estado ou do status interno de um sistema por meio das saídas externas dele. Medimos os sistemas de computador observando o tempo de CPU, memória, espaço em disco, latência, erros e outras métricas. Quanto mais observável for um sistema, mais fácil será entender o que ele está fazendo quando nós o observarmos.

A observabilidade de um sistema tem um efeito considerável no custo operacional. Os sistemas observáveis produzem dados significativos e acionáveis para os operadores, permitindo que eles obtenham resultados favoráveis e tenham menos tempo de inatividade. Mais informações não são necessariamente convertidas em um sistema mais observável. Na verdade, às vezes, o volume de informações geradas por um sistema pode dificultar a identificação de sinais de integridade importantes do ruído gerado pelo aplicativo.

A observabilidade do serviço é importante porque ajuda você a entender o desempenho e os problemas dos sistemas distribuídos e de nuvem com base em arquiteturas dinâmicas.

A implementação de uma solução para obter a observabilidade dos serviços pode ajudar a:

  • Verificar se os usuários finais podem consumir o aplicativo e se as expectativas de negócios foram atendidas.
  • Entender todo um sistema e como ele funciona em conjunto usando um único painel.
  • Estabelecer uma linha de base para o sistema e entender como diferentes circunstâncias afetam o desempenho do sistema.
  • Gerar itens de ação a partir de cenários e comportamentos inesperados.

O Kubernetes habilitado para Azure Arc fornece duas opções de extensão integrada para ajudar você a obter observabilidade dos serviços: o Open Service Mesh e o gateway de Gerenciamento de API auto-hospedado. Essas opções são discutidas detalhadamente nas seções de consideração de design a seguir.

Arquitetura

O diagrama a seguir ilustra os três pilares da Observabilidade dos Serviços com impacto no volume de dados.

Uma diagrama que descreve os Pilares dos Serviços de Observabilidade.

O diagrama a seguir mostra vários componentes do Open Service Mesh em execução em um cluster do Kubernetes habilitado para Arc. Ele também mostra um aplicativo de exemplo habilitado na malha de serviço, que é configurado automaticamente com um contêiner de sidecar do Envoy.

Um diagrama que descreve o Open Service Mesh em execução no Kubernetes habilitado para Azure Arc.

Considerações sobre o design

Os três pilares de observabilidade são métricas, logs e rastreamentos. Incorpore-os na estratégia de observabilidade para ajudar a tornar o sistema observável.

  • Métricas são valores numéricos que descrevem determinado aspecto de um sistema em um momento específicos e são sempre coletados em intervalos regulares.

A captura de tela a seguir mostra uma visualização de uma métrica de solicitação HTTP de exemplo para um serviço. A métrica neste exemplo é exibida como taxa de solicitação HTTP por minuto, durante um período especificado.

Uma captura de tela mostrando a métrica de solicitação HTTP para um serviço.

  • Os logs podem armazenar vários tipos de dados que têm suas próprias estruturas. Um log contém os detalhes sobre as transações que podem permitir que você obtenha uma história mais completa para determinado evento. Os logs de aplicativo normalmente incluem carimbos de data/hora, níveis de log e todas as informações necessárias para entender o contexto de um evento. Os logs são coletados e enviados para um serviço de log para armazenamento e análise.

  • O rastreamento distribuído é uma técnica de diagnóstico que ajuda os usuários a localizar falhas e problemas de desempenho em aplicativos, especialmente nos distribuídos em vários computadores ou processos. Essa técnica rastreia solicitações por meio de um aplicativo, correlacionando o trabalho feito por diferentes componentes do aplicativo e separando-o de outros trabalhos que o aplicativo possa estar fazendo para solicitações simultâneas.

A captura de tela a seguir mostra uma visualização de uma transação de ponta a ponta usando o Application Insights. Esse visual permite uma compreensão fácil dos tempos de resposta, códigos de resposta e quaisquer exceções que ocorram entre as solicitações em uma cadeia de transações.

Uma captura de tela mostrando o rastreamento de transação de ponta a ponta.

Os três pilares de métricas, logs e rastreamentos distribuídos estão interconectados. As métricas são armazenadas como valores numéricos em um banco de dados de série temporal. Eles também são muito menores do que os logs, o que os torna mais fáceis de avaliar e úteis para alertas quase em tempo real. Os logs capturam e transmitem muito mais informações do que as métricas, o que os torna úteis para depurações mais detalhadas. Os rastreamentos têm o escopo de solicitação e são úteis para obter visibilidade em uma solicitação, à medida que ela percorre vários componentes de um sistema distribuído.

A tabela a seguir mostra o impacto da coleção para os três pilares.

Característica da coleção Métricas Logs Rastreamento Distribuído
Contas para cada transação Sim Yes Não (amostrado)
Imune a problemas de cardinalidade Não Sim Yes
Custo Baixa Alta Baixo

Existem diferentes maneiras de obter observabilidade do serviço. Você pode usar uma malha de serviço para fazer isso na camada da plataforma, onde o aplicativo não tem reconhecimento e fica inalterado. Você também pode instrumentar um aplicativo com uma biblioteca, o que normalmente é feito usando uma ferramenta de APM, como o Application Insights. Os gateways de API fornecem observabilidade do tráfego norte-sul, mas não têm observabilidade da comunicação de pod a pod nem facilidade de configuração em escala.

As seções a seguir explicam como você pode usar uma malha de serviço e o Gateway de API auto-hospedado disponível do Azure Arc para obter observabilidade dos serviços.

Malha de serviço

A malha de serviço fornece funcionalidades como gerenciamento de tráfego, resiliência, imposição de política, segurança de transporte, segurança de identidade e observabilidade para as cargas de trabalho. O aplicativo é dissociado dessas funcionalidades operacionais. A malha de serviço migra essas funcionalidades da camada de aplicativo para a camada de infraestrutura. Isso é feito por meio de um proxy de alto desempenho que media todo o tráfego de entrada e saída para o serviço.

  • O Kubernetes habilitado para Azure Arc dá suporte ao OSM (Open Service Mesh), um projeto do CNCF (Cloud Native Computing Foundation), que é implantado como extensão. O OSM (Open Service Mesh) é uma malha de serviço nativa de nuvem leve e extensível, que permite aos usuários gerenciar, proteger e obter recursos de observação prontos para uso em ambientes de microsserviço altamente dinâmicos.
  • Outras Malhas de Serviço populares que exigem suporte do fornecedor incluem Istio, Consul Connect e Linkerd.
  • Dependendo dos recursos usados ao implementar uma malha de serviço, pode haver uma responsabilidade adicional para os Operadores de Aplicativo, para definir uma configuração para cada serviço (como regras de acesso e serviços de integração). Além disso, os Operadores de Cluster devem gerenciar e ter reconhecimento do controlador de malha de serviço. Devido à maneira como a malha de serviço usa o padrão de sidecar, os logs de acesso do plano de controle da malha de serviço e o sidecar são necessários ao depurar a Saída e a Entrada.

Observabilidade da malha de serviço

A observabilidade é uma funcionalidade importante entre as muitas que as malhas de serviço oferecem. Escolha uma Malha de Serviço que atenda aos requisitos mínimos de observabilidade, para que você reduza a complexidade e os componentes com os quais a malha de serviço pode ser fornecida e exigir configuração. Avalie os seguintes recursos comuns e use os casos de observabilidade fornecidos pelas malhas de serviço:

  • Geração de métricas, incluindo os quatro sinais áureos: latência, tráfego, erros e saturação.
  • O método RED (Rates-calls/sec, Errors, Duration-call latencies), que é um subconjunto dos quatro sinais áureos e é usado para medir os serviços. A malha de serviço deve fornecer uma maneira padronizada de coletar métricas RED, rastreamentos etc.
  • Aumentos na observabilidade, desde o aumento da amplitude de cobertura até todos os serviços que fazem parte da malha de serviço.
  • Recursos que aumentam a adoção da observabilidade, instrumentando automaticamente todos os serviços.
  • Integração completa com os pilares de observabilidade do serviço. A malha de serviço deve extrair as métricas e coletar os logs exibidos na solução de monitoramento. Verifique se a coleção de telemetria da malha de serviço atende às necessidades de negócios e é integrada corretamente à solução de monitoramento existente.

O diagrama a seguir mostra um exemplo da funcionalidade de Proxy da Malha de Serviço da coleta e do encaminhamento de dados.

Uma diagrama que descreve um exemplo de observabilidade com um Proxy de Malha de Serviço.

Gateway auto-hospedado de gerenciamento de API

Com a integração entre o Gerenciamento de API do Azure e o Azure Arc no Kubernetes, você pode implantar o componente do gateway do Gerenciamento de API como uma extensão em um cluster do Kubernetes habilitado para Azure Arc. Isso permite que uma versão conteinerizada do gateway de Gerenciamento de API seja executada no cluster. Todos os gateways auto-hospedados são gerenciados por meio do serviço de Gerenciamento de API com que eles são federados, fornecendo a visibilidade e uma experiência de gerenciamento unificada em todas as APIs internas e externas.

A configuração do gateway auto-hospedado para aceitar o tráfego de entrada, para direcionar para os serviços, exige a criação de políticas. O gerenciamento pode se tornar mais complexo, à medida que a escala de serviço aumenta.

Para obter mais informações, confira a visão geral do gateway auto-hospedado

Observabilidade do gateway auto-hospedado do Gerenciamento de API

O gateway auto-hospedado emite métricas, logs stdout e logs stderr. As métricas emitidas podem ser configuradas por um ConfigMap no cluster. Para obter informações sobre o monitoramento avançado com o Gerenciamento de API, confira Monitoramento avançado.

A observabilidade do gateway auto-hospedado representa o tráfego externo (norte-sul) que entra no cluster, mas não fornece observabilidade do tráfego pod a pod dentro do cluster (leste-oeste).

Métricas e logs de nuvem: as métricas são emitidas para o Azure Monitor por padrão. O Log Analytics permite coletar e exibir os logs de contêiner do gateway auto-hospedado usando o Azure Monitor para contêineres. Para obter mais informações, confira Configurar as métricas e os logs locais para gateway auto-hospedado do Gerenciamento de API do Azure.

Métricas e logs locais: as métricas e os logs do gateway auto-hospedado podem ser integrados às ferramentas de monitoramento local ou emitidos pelo Mapa de Configuração. As métricas podem ser configuradas para publicação nos servidores de métrica. Os logs de gateway são emitidos por padrão para stdout e stderr. Para obter mais informações, confira Configurar as métricas e os logs locais para gateway auto-hospedado do Gerenciamento de API do Azure.

Tabela de comparação de tecnologia

A tabela a seguir mostra as diferenças entre as opções de implementação para ajudar a escolher um método para obter observabilidade dos serviços.

Funcionalidade Malha de serviço Monitoramento do desempenho de aplicativos Gateway de API auto-hospedado
Tráfego leste-oeste com suporte Sim Sim Não
Funcionalidade das Métricas Sim Sim Yes
Funcionalidade dos Logs Sim Yes Implementação personalizada
Funcionalidade dos Rastreamentos Distribuídos Sim Sim Yes
Camada de Implementação Rede Aplicativo Rede
Protocolos compatíveis HTTP(S), TCP, gRPC N/D HTTP(S), websockets
Responsabilidade de Configuração Operadores de Cluster Desenvolvedores de Aplicativo Operadores de aplicativos e operadores de cluster
Complexidade de configuração para observabilidade Baixa Alta Médio

Recomendações sobre design

Implemente o Open Service Mesh para obter observabilidade na integridade e no desempenho dos serviços. O Open Service Mesh usa proxies de sidecar injetados como contêiner separado nos mesmos pods que as cargas de trabalho, para obter dados de telemetria. Esses proxies interceptam todo o tráfego HTTP de entrada e saída para as cargas de trabalho e relatam os dados para o Open Service Mesh. Com esse sistema, os desenvolvedores de serviço não precisam instrumentar o código para coletar dados de telemetria.

Habilite o Open Service Mesh usando a funcionalidade de extensão de cluster do Kubernetes habilitado para Azure Arc, que permite que a Microsoft gerencie o plano de controle por você. Para obter mais informações, confira Implantar o Open Service Mesh habilitado para Azure Arc (Versão prévia).

Para maximizar a disponibilidade e o desempenho dos aplicativos e serviços, habilite o Azure Monitor Container Insights. Ele fornece uma solução abrangente para coleta, análise e ação com base na telemetria nos ambientes de nuvem e locais. O Open Service Mesh habilitado para Azure Arc é completamente integrado ao Azure Monitor, fornecendo um método contínuo de exibição e resposta aos KPIs críticos fornecidos pelas métricas e logs de contêiner de aplicativos do OSM. Você pode habilitar as métricas do OSM seguindo estas etapas. Para rastreamento distribuído, recomendamos o Jaeger, que pode ser integrado ao plano de controle do OSM.

O Open Service Mesh também fornece integrações de observabilidade documentadas para métricas com o Prometheus e o Grafana, rastreamento com o Jaeger e encaminhamento de log com o Fluent Bit. Essas integrações fornecem opções alternativas, se você não estiver usando as soluções de monitoramento do Azure. Você pode usar essas integrações para estender a outras ferramentas de monitoramento internas, conforme necessário.

No mínimo, você deve definir as três métricas RED a seguir e medi-las para todos os serviços:

  • Taxa de Solicitação: o número de solicitações que o serviço está recebendo por segundo.
  • Erros: o número de solicitações com falha ou a taxa de solicitações com falha por segundo.
  • Duração: o tempo necessário para que um serviço lide com uma solicitação.

O Open Service Mesh fornece várias pastas de trabalho de serviço pré-configuradas no Azure Monitor, portanto, você não precisa configurar manualmente os painéis e gráficos. Essa telemetria detalhada permite observar o comportamento do serviço e permite que você solucione, mantenha e otimize os aplicativos. O uso da pasta de trabalho de monitoramento do OSM no Azure Monitor permite que você:

  • Obtenha uma visão geral de todos os serviços na malha e obtenha as métricas críticas de nível de serviço para três dos quatro sinais áureos de monitoramento: latência, solicitações e erros.
  • Defina, examine e configure alertas para os SLOs (objetivos de nível de serviço), que resumem o desempenho visível para o usuário do serviço.
  • Exiba os gráficos de métricas para serviços individuais para que você possa analisá-los minuciosamente, usando filtragem e detalhamentos, fazendo a seleção de dados por código de resposta, protocolo, pod de destino, fonte de tráfego e muito mais.

Use as visualizações da interface do usuário do Jaeger para:

  • Observar uma visualização do grafo de topologia, que mostra quais microsserviços se comunicam entre si, para onde as solicitações vão e quanto tempo levam.
  • Inspecionar as solicitações e respostas específicas, para ver como e quando ocorrem, a fim de monitorar e solucionar problemas de sistemas distribuídos.

A observabilidade dos serviços é apenas uma disciplina da estratégia de monitoramento de nuvem. Para obter mais informações sobre as disciplinas de gerenciamento, examine a Área de design crítico para disciplinas de gerenciamento.

Próximas etapas

Para obter mais informações sobre seu percurso na nuvem híbrida e multinuvem, confira os seguintes artigos: