O Istio é uma malha de serviços open source que pode ser usada por desenvolvedores e operadores para controlar, proteger e conectar serviços com sucesso no mundo dos microsserviços distribuídos. Embora o Istio seja uma ferramenta poderosa para equipes, também é importante que os administradores tenham total visibilidade de sua integridade. Neste post do blog, veremos o monitoramento do Istio e seus microsserviços com o Elastic Observability.
Conforme consta na documentação do Istio:
O Istio facilita a criação de uma rede de serviços implantados com balanceamento de carga, autenticação serviço a serviço, monitoramento e muito mais, com pouca ou nenhuma alteração no código do serviço. Você adiciona o suporte para o Istio aos serviços implantando um proxy secundário especial em todo o seu ambiente que intercepta toda a comunicação de rede entre os microsserviços e, em seguida, configura e gerencia o Istio usando sua funcionalidade de plano de controle, que inclui:
- Balanceamento de carga automático para tráfego HTTP, gRPC, WebSocket e TCP.
- Controle refinado do comportamento do tráfego com ricas regras de roteamento, novas tentativas, failovers e injeção de falhas.
- Uma camada de política conectável e uma API de configuração que dão suporte a controles de acesso, limites de taxa e cotas.
- Métricas, logs e traces automáticos de todo o tráfego em um cluster, incluindo entrada e saída do cluster.
- Comunicação segura de serviço a serviço em um cluster com forte autenticação e autorização baseadas em identidade.
Antes da versão 1.5, o Istio era desenvolvido com uma arquitetura de microsserviços, e seu plano de controle e componentes de gerenciamento consistiam em vários microsserviços: Pilot, Mixer, Galley e Citadel.
O Metricbeat tinha suporte para monitorar esses microsserviços, mas na versão 1.5 o Istio mudou sua arquitetura para uma abordagem monolítica, e agora o plano de controle vem com uma única aplicação chamada istiod. O Pilot, o Galley e o Citadel agora fazem parte do istiod, enquanto a funcionalidade do Mixer, que era responsável por coletar métricas de tráfego dos proxies Envoy, agora é fornecida diretamente pelos proxies do Istio. A arquitetura atual do Istio é assim:
Elaboração de uma solução de monitoramento com a Elastic
Embora as versões anteriores à 1.5 já fossem compatíveis com os vários conjuntos de métricas do módulo Metricbeat do Istio, neste post vamos nos concentrar mais no suporte para as versões mais recentes do Istio em execução no Kubernetes.
Métricas do plano de controle
Conforme mostrado na ilustração da arquitetura do Istio acima, temos apenas um recurso do qual podemos coletar as métricas do plano de controle. O Istiod fornece um exportador do Prometheus a partir do qual podemos coletar as métricas do Prometheus.
Para consumir métricas do endpoint do Prometheus, precisamos de um conjunto de métricas para coletar essas métricas corretamente, filtrá-las e armazená-las apropriadamente. Isso pode ser facilmente alcançado com a criação de um conjunto de métricas lightweight baseado no módulo Prometheus, aproveitando opções poderosas como filtragem de métrica e usando histogramas e tipos.
Vejamos a definição desse novo conjunto de métricas lightweight:
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /metrics
metrics_filters:
include: ["citadel_*", "galley_*", "pilot_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
Isso define o caminho a partir do qual o conjunto de métricas do coletor extrairá as métricas e filtrará aquelas de que não precisamos, além de habilitar taxas e tipos para que os dados sejam armazenados corretamente no Elasticsearch, permitindo-nos tirar o máximo proveito deles.
A maneira de configurar esse conjunto de métricas ao implantar o Metricbeat em um cluster do Kubernetes é assim:
- module: istio metricsets: ['istiod'] period: 10s hosts: ['istiod.istio-system:15014']
Onde istiod é o nome do serviço do Kubernetes que expõe o Pod Istiod, e istio-system é o espaço de nome onde ele é implantado.
E é isso! Já temos o conjunto de métricas do istiod para coletar as métricas do istiod, que também vem com um dashboard pré-criado para fornecer uma visão geral do plano de controle da malha de serviços, completo com diversas visualizações que você pode usar em seus próprios dashboards customizados:
Métricas do plano de dados
Agora que estamos coletando métricas do plano de controle com o conjunto de métricas do istiod, podemos estender nosso monitoramento coletando métricas do plano de dados. Isso nos dará uma poderosa visão geral do tráfego entre os serviços gerenciados pelo Istio.
Conforme mencionamos anteriormente, o Mixer era o microsserviço responsável por coletar e fornecer essas métricas do plano de dados. Porém, após a versão 1.5, essas métricas passaram a ser coletadas e expostas diretamente dos proxies do Istio usando um exportador do Prometheus.
Tudo o que precisamos fazer é especificar outro conjunto de métricas lightweight, semelhante ao que fizemos para o istiod, para coletar essas métricas adicionais:
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /stats/prometheus
metrics_filters:
include: ["istio_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
Da mesma forma que antes, definimos metrics_path, mantemos apenas as métricas que queremos e as armazenamos usando tipos.
No entanto, está faltando uma peça: não sabemos como alcançar esses containers do proxy, pois não sabemos seus endereços IP. Mesmo se soubéssemos os IPs desses containers antes de implantar o Metricbeat, não poderíamos coletar dados de serviços que seriam implantados após o Metricbeat ser iniciado. Precisamos de uma maneira de identificar automaticamente esses containers e começar a coletar métricas assim que eles começarem — ou seja, o trabalho perfeito para o recurso de descoberta automática do Metricbeat. Isso significa que definimos uma condição de descoberta automática para identificar esses containers e, sempre que um novo container secundário do Istio-proxy for localizado, o Metricbeat habilitará automaticamente o conjunto de métricas do proxy e começará a coletar dados dele.
Aqui está um exemplo dessa configuração de descoberta automática:
metricbeat.autodiscover:
providers:
- type: kubernetes
node: ${NODE_NAME}
templates:
- condition:
contains:
kubernetes.annotations.prometheus.io/path: "/stats/prometheus"
config:
- module: istio
metricsets: ["proxy"]
hosts: "${data.host}:15090"
E pronto! Estamos coletando métricas de todos os containers secundários do Istio em execução no cluster e poderemos identificar qualquer um deles que for novo imediatamente. Este é o conjunto de métricas do proxy do módulo Istio, que também vem com um dashboard pré-criado:
Além disso, podemos aproveitar a análise de dados gráficos no Kibana para explorar as correlações entre nossos dados e os serviços. Por exemplo, com o gráfico abaixo, podemos ter uma visão geral de como nossos serviços estão conectados uns aos outros e o quanto eles estão relacionados com os códigos de status http. Um serviço com uma relação forte com um código de status 500 indicaria um problema que devemos investigar.
Monitoramento do Istio hoje
Se você quer começar a monitorar a sua malha de serviços do Istio, baixe o Metricbeat 7.11 e comece a explorar suas métricas de forma eficiente com o Elasticsearch e o Kibana. A maneira mais rápida de implantar seu cluster é iniciar uma avaliação gratuita do Elasticsearch Service. Se tiver alguma dúvida, lembre-se de que estamos prontos para ajudar nos fóruns do Discuss.