Partilhar via

Observabilidade de serviços para Kubernetes habilitados para Azure Arc

  • Artigo

A observabilidade é uma característica da aplicação que se refere a quão bem o estado ou status interno de um sistema pode ser compreendido a partir de suas saídas externas. Medimos sistemas de computador observando o tempo da CPU, memória, espaço em disco, latência, erros e outras métricas. Quanto mais observável é um sistema, mais fácil é para nós entendermos o que ele está fazendo assistindo-o.

A observabilidade de um sistema tem um efeito significativo no seu custo operacional. Sistemas observáveis produzem dados significativos e acionáveis para seus operadores, permitindo que eles alcancem resultados favoráveis e tenham menos tempo de inatividade. Mais informação não se traduz necessariamente num sistema mais observável. De facto, por vezes, a quantidade de informação gerada por um sistema pode dificultar a identificação de sinais de saúde valiosos a partir do ruído gerado pela aplicação.

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

A implementação de uma solução para alcançar a observabilidade dos serviços pode ajudá-lo a:

  • Certifique-se de que os usuários finais possam consumir seu aplicativo e que suas expectativas de negócios sejam atendidas.
  • Entenda um sistema inteiro e como ele funciona em conjunto usando um único painel de vidro.
  • Estabeleça uma linha de base para o seu sistema e compreenda como diferentes circunstâncias afetam o desempenho do seu sistema.
  • Gere 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 integradas para ajudá-lo a alcançar a observabilidade de serviços: Open Service Mesh e gateway de Gerenciamento de API auto-hospedado. Essas opções são discutidas em detalhes nas seções de consideração de design a seguir.

Arquitetura

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

Um diagrama representando os Pilares da Observabilidade dos Serviços.

O diagrama a seguir mostra vários componentes do Open Service Mesh em execução em um cluster 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 carro lateral Envoy.

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

Considerações de design

Os três pilares da observabilidade são métricas, logs e traços. Incorpore-os em sua estratégia de observabilidade para ajudar a tornar seu sistema observável.

  • As métricas são valores numéricos que descrevem algum aspeto de um sistema em um determinado ponto no tempo, e eles são sempre coletados em intervalos regulares.

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

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

  • Os logs podem armazenar vários tipos de dados que têm suas próprias estruturas. Um log contém detalhes sobre transações que podem permitir que você obtenha uma história mais completa para um determinado evento. Os logs de aplicativos geralmente 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 aqueles que são distribuídos em várias máquinas 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 outro trabalho que o aplicativo pode 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 fácil compreensão dos tempos de resposta, códigos de resposta e quaisquer exceções que ocorram entre 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 rastreamento distribuído estão interligados. As métricas são armazenadas como valores numéricos em um banco de dados de séries temporais. 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 métricas, o que os torna úteis para depurações mais profundas. Os rastreamentos têm escopo de solicitação e são úteis para obter visibilidade de uma solicitação à medida que ela atravessa vários componentes de um sistema distribuído.

A tabela a seguir mostra o impacto da coleta para os três pilares.

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

Existem diferentes maneiras de alcançar a observabilidade do serviço. Você pode usar uma malha de serviço para fazê-lo na camada de plataforma, onde seu aplicativo não está ciente e inalterado. Você também pode instrumentar um aplicativo com uma biblioteca, o que geralmente é feito usando uma ferramenta de monitoramento de desempenho de aplicativo (APM), como o Application Insights. Os gateways de API fornecem observabilidade no tráfego norte-sul, mas não têm observabilidade na comunicação pod to pod e 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 para o Azure Arc para obter observabilidade de serviços.

Malha de serviço

Uma malha de serviços fornece recursos como gerenciamento de tráfego, resiliência, imposição de políticas, segurança de transporte, segurança de identidade e observabilidade para suas cargas de trabalho. Seu aplicativo é dissociado desses recursos operacionais; A malha de serviço os move para fora da camada de aplicativo e para baixo na camada de infraestrutura. Isso é feito por meio de um proxy de alto desempenho que medeia todo o tráfego de entrada e saída para o seu serviço.

  • O Kubernetes habilitado para Azure Arc dá suporte ao Open Service Mesh (OSM), um projeto CNCF (Cloud Native Computing Foundation), que é implantado como uma extensão. O Open Service Mesh é uma malha de serviço nativa da nuvem leve, extensível e que permite aos usuários gerenciar, proteger e obter recursos de observabilidade prontos para uso em ambientes de microsserviços altamente dinâmicos.
  • Outras malhas de serviço populares que exigem suporte do fornecedor incluem Istio, Consul Connect e Linkerd.
  • Dependendo dos recursos que você usa ao implementar uma malha de serviço, uma responsabilidade extra pode ser colocada sobre os operadores de aplicativos 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 estar cientes do controlador de malha de serviço. Devido à maneira como a malha de serviço usa o padrão de carro lateral, os logs de acesso do plano de controle de malha de serviço e do sidecar são necessários ao depurar Egress e Ingress.

Observabilidade da malha de serviço

A observabilidade é uma funcionalidade importante entre as muitas que as malhas de serviço fornecem. Escolha uma malha de serviço que atenda aos seus requisitos mínimos de observabilidade para reduzir a quantidade de complexidade e componentes que a malha de serviço pode vir com e requer ser configurada. Avalie os seguintes recursos comuns e casos de uso de observabilidade que as malhas de serviço fornecem:

  • Geração de métricas, incluindo os quatro sinais dourados: 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 dourados e é usado para medir serviços. Sua malha de serviço deve fornecer uma maneira padronizada de coletar métricas RED, rastreamentos, etc.
  • A observabilidade aumenta, desde o aumento da amplitude da cobertura até todos os serviços que fazem parte da sua malha de serviços.
  • Recursos que aumentam a adoção da observabilidade através da auto-instrumentação de todos os serviços.
  • Forte integração com os pilares de observabilidade do serviço. Sua malha de serviço deve ser capaz de raspar métricas e coletar logs que são exibidos em sua solução de monitoramento. Certifique-se de que a coleção de telemetria da sua malha de serviço atenda às suas necessidades de negócios e se integre bem à sua solução de monitoramento existente.

O diagrama a seguir mostra um exemplo da funcionalidade Service Mesh Proxy de coleta e encaminhamento de dados.

Um diagrama representando um exemplo de observabilidade com um Service Mesh Proxy.

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 de gateway de Gerenciamento de API como uma extensão em seu cluster Kubernetes habilitado para Azure Arc. Isso permite que uma versão em contêiner do gateway de Gerenciamento de API seja executada em seu cluster. Todos os gateways auto-hospedados são gerenciados a partir do serviço de Gerenciamento de API com o qual são federados, fornecendo visibilidade e uma experiência de gerenciamento unificada em todas as APIs internas e externas.

Configurar o gateway auto-hospedado para aceitar tráfego de entrada para direcionar aos seus serviços requer a criação de políticas. A sua gestão pode tornar-se mais complexa à medida que a sua escala de serviço aumenta.

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

Gerenciamento de API Observabilidade do gateway auto-hospedado

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

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

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

Métricas e logs locais: Métricas e logs do seu gateway auto-hospedado podem ser integrados com suas ferramentas de monitoramento local ou emitidos pelo Config Map. As métricas podem ser configuradas para publicação em servidores de métricas. Os logs de gateway são emitidos por padrão para stdout e stderr. Para obter mais informações, consulte Configurar métricas e logs locais para o gateway auto-hospedado do Azure API Management.

Tabela de comparação de tecnologia

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

Funcionalidade Malha de serviço Monitorização do Desempenho das Aplicações Gateway de API auto-hospedado
Tráfego Leste-Oeste suportado Sim Sim No
Capacidade de métricas Sim Sim Sim
Capacidade de registo Sim Sim Implementação personalizada
Capacidade de rastreamentos distribuídos Sim Sim Sim
Camada de implementação Rede Aplicação Rede
Protocolos suportados HTTP(S), TCP, gRPC N/A HTTP(S), websockets
Responsabilidade pela configuração Operadores de cluster Programadores de Aplicações Operadores de aplicativos & operadores de cluster
Complexidade de configuração para observabilidade Baixa Alto Médio

Recomendações de design

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

Habilite o Open Service Mesh usando o recurso de extensão de cluster Kubernetes habilitado para Azure Arc, que permite que a Microsoft gerencie o plano de controle para você. Para obter mais informações, consulte Implantar o Open Service Mesh (Visualização) habilitado para Azure Arc.

Para maximizar a disponibilidade e o desempenho de seus aplicativos e serviços, habilite o Azure Monitor Container Insights. Ele fornece uma solução abrangente para coletar, analisar e agir em telemetria de seus ambientes locais e na nuvem. O Open Service Mesh habilitado para Azure Arc integra-se profundamente ao Azure Monitor, oferecendo um método perfeito de exibir e responder a KPIs críticos fornecidos por métricas OSM e logs de contêiner de aplicativos. Você pode habilitar as métricas do OSM seguindo estas etapas. Para rastreamento distribuído, recomendamos o Jaeger, que pode se integrar ao seu plano de controle OSM.

O Open Service Mesh também fornece integrações de observabilidade documentadas para métricas com Prometheus e Grafana, rastreamento com Jaeger e encaminhamento de logs com Fluent Bit. Essas integrações fornecem opções alternativas se você não estiver usando 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: a quantidade de tempo que um serviço leva para lidar com uma solicitação.

O Open Service Mesh fornece várias pastas de trabalho de serviço pré-configuradas no Azure Monitor para que você não precise configurar manualmente painéis e gráficos. Essa telemetria detalhada permite observar o comportamento do serviço e permite solucionar problemas, manter e otimizar seus aplicativos. Usar a pasta de trabalho de monitoramento OSM no Azure Monitor permite:

  • Obtenha uma visão geral de todos os serviços em sua malha e obtenha métricas críticas de nível de serviço para três dos quatro sinais dourados de monitoramento: latência, solicitações e erros.
  • Defina, analise e defina alertas em relação aos SLOs (Service Level Objetives, objetivos de nível de serviço), que resumem o desempenho visível do serviço para o usuário.
  • Visualize gráficos de métricas para serviços individuais para que você possa analisá-los profundamente usando filtragem e detalhamentos, peneirando dados por código de resposta, protocolo, pod de destino, origem de tráfego e muito mais.

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

  • Observe uma visualização de gráfico de topologia que mostra quais microsserviços se comunicam entre si, para onde as solicitações vão e quanto tempo elas demoram.
  • Inspecione solicitações e respostas específicas para ver como e quando elas acontecem para monitorar e solucionar problemas de sistemas distribuídos.

A observabilidade de serviços é apenas uma disciplina da sua estratégia de monitoramento de nuvem. Para obter mais informações sobre disciplinas de gestão, consulte a área de design crítico das disciplinas de gestão.

Próximos passos

Para obter mais informações sobre sua jornada de nuvem híbrida e multicloud, consulte os seguintes artigos: