Em uma service mesh, diferentes serviços podem exigir dados de observabilidade distintos. Isso torna necessário definir regras de coleta específicas para sidecar proxies e gateway pods, além de padronizar essas configurações para oferecer melhor suporte à observabilidade de aplicações cloud-native. A observabilidade é fundamental para aplicações cloud-native, pois permite monitorar a integridade e o desempenho dos serviços em tempo real, detectar e resolver falhas e gargalos e, consequentemente, melhorar a confiabilidade e o desempenho da aplicação. O Alibaba Cloud Service Mesh (ASM) oferece um modelo unificado e padronizado para configurar a geração e a coleta de dados de telemetria, aprimorando a observabilidade das suas aplicações cloud-native. Este tópico aborda os conceitos e recursos de observabilidade.
Observabilidade
À medida que os sistemas de aplicações aumentam em complexidade, garantir a estabilidade de todos os componentes torna-se cada vez mais difícil. Partes de um sistema podem operar em estado degradado devido a problemas subjacentes. Portanto, além de criar aplicações confiáveis e resilientes, utilize ferramentas de observabilidade para compreender o comportamento em tempo de execução dos seus serviços e da infraestrutura. Essa visibilidade permite detectar falhas, depurar problemas inesperados e reduzir o tempo médio de recuperação (MTTR), minimizando o impacto nos negócios.
A observabilidade é uma propriedade do sistema que envolve a coleta de dados em vários níveis, incluindo métricas de aplicação, métricas de rede e telemetria de infraestrutura. Ao correlacionar esse grande volume de dados, você constrói uma visão completa para investigar eventos imprevisíveis. Uma service mesh aprimora significativamente a coleta de métricas de rede no nível da aplicação. Do ponto de vista prático, o objetivo principal é entender a estabilidade do sistema: saber quando ele opera corretamente e quando enfrenta problemas. Isso possibilita identificar erros mais rapidamente e implementar controles automatizados ou manuais para manter a disponibilidade.
Os proxies do plano de dados de uma service mesh residem no caminho de rede entre os serviços. Ao capturar telemetria desses proxies, você obtém visibilidade em tempo de execução sobre o comportamento da rede da sua aplicação e da própria mesh.
Alcançar a observabilidade em uma service mesh envolve configurar a geração e a coleta de dados como logs, métricas e rastreamento distribuído, enviando-os posteriormente para serviços gerenciados na nuvem ou autogerenciados. Também é necessário definir configurações de coleta separadas para sidecar proxies e gateway pods para atender a diferentes cenários. O ASM fornece um modelo de configuração unificado e convergente para geração e coleta de dados, oferecendo melhor suporte à observabilidade de aplicações cloud-native.
Melhores práticas integradas
O Telemetry CRD permite criar múltiplos objetos em diferentes namespaces. No entanto, defini-los arbitrariamente pode causar conflitos e comportamentos inesperados. Siga estas melhores práticas para garantir que suas configurações funcionem conforme o esperado:
Não defina vários objetos Telemetry abrangendo toda a mesh no namespace raiz istio-system; apenas um objeto desse tipo pode existir. O ASM aplica essa melhor prática permitindo somente um único objeto Telemetry chamado default no namespace istio-system.
Cada namespace permite apenas um objeto Telemetry com um seletor de workload vazio, que deve ser nomeado como default.
Utilize um seletor de workload para aplicar um novo objeto Telemetry em um namespace específico, substituindo as configurações da workload alvo.
Se dois objetos Telemetry com o mesmo seletor de workload tiverem como alvo a mesma workload, o comportamento será indefinido.
Se o objeto Telemetry global no namespace raiz istio-system não definir uma configuração de métricas, a geração de métricas ficará desativada por padrão.
Logs
Em uma service mesh, a coleta de logs é uma das principais formas de alcançar a observabilidade. Agregar logs de todos os serviços em um local centralizado simplifica o gerenciamento e a busca. Para isso, grave os logs de cada serviço em stdout ou stderr e colete-os por meio de um agente de logs em um sistema centralizado. O ASM oferece recursos de filtragem e formatação de logs, permitindo filtrar e formatar os dados conforme necessário para facilitar a recuperação e a análise.
Regras de formato de log
Em ambientes reais, os serviços frequentemente apresentam formatos de log diferentes. Defina regras de geração para controlar como os logs são produzidos. O proxy Envoy, implantado no plano de dados (no cluster Kubernetes adicionado à mesh), pode gerar um log de acesso abrangente para todo o tráfego. O ASM permite personalizar o conteúdo desses logs de acesso.
Por meio do Telemetry CRD, o ASM disponibiliza uma interface gráfica (GUI) para simplificar a configuração dos formatos de dados de log. Para obter etapas detalhadas, consulte Customize access logs on the data plane.
A interface gráfica de configuração para regras de formato de log contém três abas de escopo: Global, Namespace e Custom. Na aba Global, após ativar a chave Enable Log Output, selecione as variáveis de log desejadas na tabela de configuração de variáveis. Os tipos de variáveis classificam-se em Envoy Built-in Attributes e Request Attributes.
Veja a seguir a configuração YAML equivalente:
envoyFileAccessLog:
logFormat:
text: '{"bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","downstream_local_address":"%DOWNSTREAM_LOCAL_ADDRESS%","downstream_remote_address":"%DOWNSTREAM_REMOTE_ADDRESS%","duration":"%DURATION%","istio_policy_status":"%DYNAMIC_METADATA(istio.mixer:status)%","method":"%REQ(:METHOD)%","path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","protocol":"%PROTOCOL%","request_id":"%REQ(X-REQUEST-ID)%","requested_server_name":"%REQUESTED_SERVER_NAME%","response_code":"%RESPONSE_CODE%","response_flags":"%RESPONSE_FLAGS%","route_name":"%ROUTE_NAME%","start_time":"%START_TIME%","trace_id":"%REQ(X-B3-TRACEID)%","upstream_cluster":"%UPSTREAM_CLUSTER%","upstream_host":"%UPSTREAM_HOST%","upstream_local_address":"%UPSTREAM_LOCAL_ADDRESS%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_transport_failure_reason":"%UPSTREAM_TRANSPORT_FAILURE_REASON%","user_agent":"%REQ(USER-AGENT)%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","authority_for":"%REQ(:AUTHORITY)%","upstream_response_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","xff":"%REQ(X-FORWARDED-FOR)%","app_service_name":"%UPSTREAM_CLUSTER%"}'
path: /dev/stdoutVeja abaixo um exemplo de condição de filtro:
accessLogging:
- disabled: false
filter:
expression: response.code >= 400
providers:
- name: envoyColeta de logs do plano de dados
Ao coletar logs do plano de dados no Simple Log Service (SLS), configure regras de coleta para controlar como os logs são coletados e retidos. O Container Service for Kubernetes (ACK) integra-se ao SLS, permitindo coletar o log de acesso de clusters no plano de dados. Para obter etapas detalhadas, consulte Use Simple Log Service to collect access logs on the data plane.
A página de configuração contém as seguintes definições:
Log Service Project: Selecione Use Default ou Use Existing.
Gateway Access Log Storage Duration: O valor padrão é 30 dias.
Sidecar Access Log Storage Duration: O valor padrão é 30 dias.
Após concluir as definições, clique em Enable Data Plane Log Collection.
Logs e alertas do plano de controle
O ASM suporta a coleta de logs do plano de controle e a configuração de alertas baseados em logs. Por exemplo, colete logs sobre o envio de configurações do plano de controle do ASM para os sidecar proxies do plano de dados. Uma função primária do plano de controle é entregar configurações de regras da mesh aos sidecar proxies e gateways do plano de dados. Se um conflito de configuração causar falha no envio, o proxy ou gateway não receberá as regras mais recentes. Embora possa continuar operando com a última configuração válida conhecida, uma reinicialização do pod provavelmente causará falha no proxy ou gateway. Configurações incorretas que tornam gateways ou proxies indisponíveis são um problema comum. Ative alertas de log do plano de controle para identificar e resolver esses problemas rapidamente. Para obter instruções detalhadas, consulte Enable control-plane log collection and log-based alerting in an ASM instance of a version earlier than 1.17.2.35 ou Enable control-plane log collection and log-based alerting in an ASM instance of version 1.17.2.35 or later.
Métricas
As métricas representam outra dimensão fundamental da observabilidade em uma service mesh, descrevendo o tratamento de requisições, a comunicação entre serviços, entre outros aspectos. O Istio utiliza o Prometheus para coletar e armazenar métricas. O proxy Envoy de cada service gera um grande volume de métricas. Utilize esses dados para monitoramento em tempo real da integridade e do desempenho dos serviços, bem como para cenários como detecção de anomalias e dimensionamento automático.
Regras de geração de métricas
Ativar métricas do plano de dados da service mesh permite que gateways e sidecar proxies gerem dados relacionados ao seu status operacional. Envie essas métricas para o Managed Service for Prometheus para visualizar painéis de monitoramento diretamente (o que pode gerar custos) ou utilize uma instância autogerenciada do Prometheus para coletar métricas do plano de dados do ASM.
Utilizando o Telemetry CRD, o ASM fornece uma GUI para simplificar a configuração de métricas personalizadas. Para obter etapas detalhadas, consulte Create custom metrics in ASM.
Veja a seguir a configuração YAML equivalente:
Considerações sobre métricas
Ativação inicial: O Managed Service for Prometheus é um service pago. Para evitar custos excessivos, defina cuidadosamente o escopo da geração de métricas com base nas suas necessidades reais. Por exemplo, para monitorar um gateway, ative métricas do lado do cliente. Caso tenha configurado métricas anteriormente, suas definições serão preservadas ao reativá-las.
-
Configurações de Topologia da Mesh: O recurso de Topologia da Mesh depende das métricas relatadas pelo sidecar proxy. Se você ativar a Topologia da Mesh, desativar certas métricas pode prejudicar sua funcionalidade ou torná-la indisponível.
Sem a ativação da métrica do lado do servidor para REQUEST_COUNT, não será possível gerar gráficos de topologia para serviços HTTP ou gRPC.
Sem a ativação da métrica do lado do servidor para TCP_SENT_BYTES, não será possível gerar gráficos de topologia para serviços TCP.
Desativar as métricas do lado do servidor para REQUEST_SIZE e REQUEST_DURATION, ou a métrica do lado do cliente para REQUEST_SIZE, torna algumas informações de monitoramento nos nós de topologia indisponíveis.
Coleta de métricas
Ative a coleta de dados no Prometheus para enviar as métricas coletadas para armazenamento e análise. O ASM integra-se ao Managed Service for Prometheus para habilitar o monitoramento da service mesh. Para obter etapas detalhadas, consulte Integrate Managed Service for Prometheus to monitor ASM instances.
O intervalo de coleta do Prometheus afeta significativamente a sobrecarga da coleta de métricas. Um intervalo maior resulta em menos pontos de dados coletados, reduzindo os custos de processamento, armazenamento e computação. O intervalo padrão é de 15 segundos, o que pode ser muito frequente para ambientes de produção. Ajuste o intervalo no lado do Prometheus conforme suas necessidades. Se estiver usando o Managed Service for Prometheus, faça essa configuração no console ARMS. Para obter etapas detalhadas, consulte Configure data collection rules.
Métricas relacionadas a histogramas, incluindo istio_request_duration_milliseconds_bucket, istio_request_bytes_bucket e istio_response_bytes_bucket, geralmente possuem alta cardinalidade e podem ser custosas. Para evitar cobranças contínuas por essas métricas personalizadas, descarte-as. Se estiver usando o Managed Service for Prometheus, configure isso no console ARMS. Para obter etapas detalhadas, consulte Configure metrics.
O ASM também suporta integração com um Prometheus autogerenciado para monitoramento da mesh. Para obter etapas detalhadas, consulte Monitor ASM instances by using a self-managed Prometheus instance.
Conforme mostrado na figura a seguir, visualize o painel correspondente no Grafana.
Mesclar métricas do Istio e da aplicação
Para serviços de aplicação que já expõem um endpoint de métricas do Prometheus, ative o recurso de mesclagem de métricas para permitir que o sidecar proxy exporte suas métricas de negócio existentes. Quando esse recurso está ativado, o ASM mescla as métricas da aplicação com as métricas do Istio. O ASM adiciona as anotações prometheus.io correspondentes a todos os pods do plano de dados para habilitar a coleta de métricas pelo Prometheus. Se essas anotações já existirem, o ASM as substituirá. O sidecar proxy mescla as métricas da aplicação e do Istio, e o Prometheus pode então coletar as métricas mescladas do endpoint :15020/stats/prometheus. Para obter etapas detalhadas, consulte Merge Istio metrics with application metrics.
Topologia da mesh
A Topologia da Mesh é uma ferramenta de observabilidade para service meshes. Ela fornece uma interface visual para visualizar serviços e configurações relacionados. Conforme mostrado na figura a seguir, o ASM inclui uma Topologia da Mesh integrada. Para obter etapas detalhadas, consulte Enable Mesh Topology to improve observability.
Objetivo de nível de service (SLO)
Um indicador de nível de service (SLI) é uma medida da integridade do service. Um objetivo de nível de service (SLO) é um valor ou intervalo alvo para um ou mais SLIs.
Um objetivo de nível de service (SLO) fornece uma maneira formal de descrever, medir e monitorar o desempenho, a qualidade e a confiabilidade de aplicações de microsserviços. Os SLOs oferecem uma linha de base de qualidade compartilhada para as equipes de desenvolvimento de aplicações, plataforma e operações, servindo como referência para medir a qualidade do nível de service e impulsionar a melhoria contínua. Combinar SLIs para definir um SLO ajuda as equipes a descrever a integridade do service com mais precisão.
Veja a seguir exemplos de SLO:
QPS médio por minuto > 100.000/s
Latência de acesso no percentil 99 < 500 ms
Largura de banda no percentil 99 por minuto > 200 MB/s
O ASM oferece recursos de monitoramento e alerta prontos para uso baseados em objetivos de nível de service (SLOs), permitindo monitorar características como latência e taxas de erro nas chamadas entre serviços de aplicação.
Os seguintes tipos de SLI são suportados no ASM:
Disponibilidade: A proporção de respostas bem-sucedidas que um service retorna. O tipo de plugin SLI correspondente é availability. O código de status HTTP 429 ou 5XX (códigos de status que começam com 5) são tratados como indisponíveis.
Latência: O tempo (em milissegundos) que um service leva para retornar uma resposta. O tipo de plugin SLI correspondente é latency. Personalize o limiar superior de latência. Respostas que excedem o limiar são tratadas como não conformes.
O ASM fornece a UI para definir configurações de SLO.
A página de criação de SLO contém os seguintes itens de configuração:
Informações básicas: Defina Namespace como
defaulte defina Target Service comohttpbin. O campo Name é gerado automaticamente comoasm-slo-default-httpbin. Defina Duration como 30 Days.Regras de SLO: Defina Name como
asm-slo, defina Target Value como99e defina Plugin Type como availability.Regras de alerta: Ative a chave de regra de alerta, defina Alert Rule Name como
asm-alerte ative as regras de alerta de nível Critical e Warning.
Ao usar o ASM para definir um objetivo de nível de service (SLO) no nível da aplicação, o ASM gera automaticamente regras do Prometheus. Após importar essas regras para o Prometheus, ele poderá aplicar o SLO. Na estrutura do Prometheus, o componente Alertmanager é responsável por coletar alertas gerados pelo servidor Prometheus e enviá-los a vários receptores com base na sua configuração. Quando um alerta é acionado, visualize as informações de alerta personalizadas coletadas na página Alertmanager. Para obter mais informações sobre SLOs, consulte SLO management.
O alerta de SLO do ASM acionado chama-se asm-alert e contém dois registros: slo_severity="page" (slo_window="30m") e slo_severity="ticket" (slo_window="2h").
Rastreamento distribuído
O rastreamento distribuído é um componente crítico da observabilidade em uma service mesh. Trata-se de um método para criar perfis e monitorar aplicações, especialmente aquelas construídas com arquitetura de microsserviços. Nessa arquitetura, a comunicação entre serviços ocorre pela rede, o que torna necessária a tecnologia de rastreamento distribuído para acompanhar e monitorar as relações de chamadas entre serviços. No Istio, utilize ferramentas de rastreamento distribuído como Jaeger e Zipkin para alcançar esse objetivo. O rastreamento distribuído envolve dois conceitos principais: trace e span.
Span: A unidade básica do rastreamento distribuído. Representa uma única unidade de trabalho em um sistema distribuído. Cada span pode conter referências a outros spans. Múltiplos spans juntos formam um trace.
Trace: Um registro do caminho completo de execução de uma requisição através de um sistema de microsserviços. Um trace completo consiste em um ou mais spans.
Embora os proxies do Istio possam enviar informações de span automaticamente, a aplicação ainda precisa propagar os cabeçalhos HTTP apropriados. Isso permite que os proxies correlacionem corretamente spans individuais em um único trace completo quando forem enviados. Portanto, sua aplicação deve coletar os seguintes cabeçalhos das requisições recebidas e propagá-los para quaisquer requisições enviadas:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Regras de geração de dados de rastreamento
Com base no Telemetry CRD, o ASM fornece uma GUI para simplificar a configuração de regras para geração de dados de rastreamento distribuído.
Veja a seguir a configuração YAML equivalente:
tracing:
- customTags:
mytag1:
literal:
value: fixedvalue
mytag2:
header:
defaultValue: value1
name: myheader1
mytag3:
environment:
defaultValue: value1
name: myenv1
providers:
- name: zipkin
randomSamplingPercentage: 90Coleta de dados de rastreamento
Para enviar dados coletados para um service gerenciado na nuvem ou um backend autogerenciado, utilize uma das seguintes abordagens:
Service gerenciado: Utilize um service de gerenciamento de aplicações cloud-native para coletar e analisar dados. Para obter etapas detalhadas, consulte Enable distributed tracing in ASM.
Service autogerenciado: Utilize ferramentas de coleta e análise open source, como Zipkin ou Jaeger. Para obter etapas detalhadas, consulte Export ASM tracing data to a self-managed system.