Observabilidade em Service Mesh

As aplicações desenvolvidas em um ambiente de microsserviços em nuvem podem ser bastante complexas devido à interação entre seus componentes. Portanto, requisitos de observabilidade e auditoria se fazem imprescindíveis para a implantação e manutenção de uma solução. Entretanto, coletar uma grande quantidade de dados pode se tornar

inviável devido a limites de rede ou armazenamento ou levar a problemas no desempenho do sistema, além da possibilidade de estar coletando informações desnecessariamente. Um sistema de monitoramento deve ser o mais simples e preciso possível, a fim de evitar que a observabilidade do sistema possa ser reduzida em vez de aumentada (PICORETI et al., 2018). Sendo assim, é importante que a camada de service mesh forneça mecanismos globais para controlar e medir todo o tráfego de solicitações entre microsserviços. No nível do plano de dados, isso é implementado fornecendo um proxy leve para cada instância de serviço, capaz de coletar os dados principais de monitoramento em sistemas de software, ou seja, métricas, logs e rastreamentos. Isso permite que desenvolvedores e administradores minimizem o esforço de implementar ou construir pipelines para coleta de dados e possam focar em sua análise (LI et al.,2019).

Por meio do proxy Envoy, o Istio é capaz de capturar sinais importantes relacionados ao manuseio de solicitações e à interação do serviço, como número de solicitações por segundo, quanto tempo as solicitações estão demorando (divididas em percentis), quantas solicitações com falha estão sendo experimentadas e assim por diante. O Istio também pode ajudar a adicionar dinamicamente novos sinais de rastreamento ao sistema para capturar novas informações. Um aspecto da compreensão de um sistema distribuído é rastrear solicitações através da aplicação para entender quais serviços e componentes estão envolvidos em um fluxo de solicitações e quanto tempo cada nó desse gráfico está demorando para processar a solicitação. O Istio também pode implementar esse tipo de esforço de rastreamento distribuído com o suporte do OpenTracing. Por fim, ele também pode adicionar algumas integrações prontas para uso com ferramentas como Prometheus, Grafana e Kiali, como será discutido a seguir, que auxiliam na visualização e exploração do estado do service mesh e os serviços que a malha conhece (POSTA, 2019).

Já no nível de plano de controle, no caso do Istio, fornece um modelo flexível em um service mesh, através do componente nomeado Mixer, mostrado anteriormente na arquitetura do Istio na Figura 6. Como explicado, este componente é responsável por fornecer controle de políticas e coletar telemetria e foi projetado com um backend para fornecer a funcionalidade de suporte a outros sistemas como controle de acesso, sistemas de captura de telemetria, sistema de imposição de cotas, sistemas de faturamento, etc., sendo um componente altamente modular e extensível. Os plugins individuais são conhecidos como adaptadores e permitem que o Mixer faça a interface com diferentes backends que fornecem funcionalidades de observabilidade como criação de logs, monitoramento, rastreamento e muito mais. O conjunto de adaptadores usados é determinado pela configuração do administrador e pode facilmente ser estendido para incluir novos sistemas de infraestrutura (ISTIO, 2019h). A arquitetura específica deste componente é ilustrada na Figura8.

Existem diferentes ferramentas que podem ser usadas para implementar observabi- lidade em service mesh. Cada uma apresenta um conjunto de funcionalidades e níveis de

Figura 8 – Arquitetura do Mixer. Fonte: (ISTIO,2019h)

maturidade diferentes. Em (PICORETI et al.,2018) é apresentado um survey que inclui uma coleção de ferramentas open source escolhidas pelo seu alto nível de maturidade e porque já vêm sendo utilizadas em sistemas de diferentes tamanhos e complexidades, tanto em ambientes de desenvolvimento quanto em produção. São estas:

• Fluentd16 _{e Logstash}17 _{são ferramentas de coleta de logs que permitem unificar a}

visualização e o consumo de dados. Ambas possuem uma arquitetura conectável e são capazes de coletar, processar e persistir logs de várias origens e destinos;

• Prometheus18 _{é uma ferramenta amplamente adotada de monitoramento e alertas,}

de código aberto e linguagem de consulta flexível. Tais consultas também podem ser utilizadas para alimentar as métricas que preenchem os painéis das ferramentas de visibilidade por meio de gráficos. Uma consulta no Prometheus pode ser visualizada na Figura 9;

16 _{https://www.fluentd.org}

17 _{https://www.elastic.co/pt/products/logstash} 18 _{https://prometheus.io/}

Figura 9 – Resultado de uma consulta no Prometheus. Fonte: (ISTIO, 2019i)

• Zipkin19 _{e Jaeger}20 _{são sistemas de rastreamento distribuído que, além de reunir}

dados de tempo necessários para solucionar problemas de latência em arquiteturas de microsserviços, ainda permitem que os dados de rastreamento sejam visualizados por meio de uma interface web, como ilustrado nas Figuras 10e 11;

• Grafana21 e Kibana22são ferramentas que permitem a análise e criação de dashboards

para visualização de métricas e logs em tempo real, criando gráficos, tabelas, etc, como os mostrados na Figura 12;

• Kiali23 _{é um projeto de User Interface capaz de disponibilizar aspectos de observabi-}

lidade como topologia, telemetria, rastreio, logs e eventos com o objetivo de tornar o service mesh compreensível, permitindo a visualização do roteamento efetivo em vigor, garantindo que a malha de microsserviços seja saudável ou que o administrador identifique rapidamente as áreas problemáticas. Um exemplo de uma de suas telas pode ser visto na Figura 13. O Kiali extrai muitas métricas do Prometheus e da plataforma subjacente (como o Kubernetes) e estabelece um gráfico de tempo de execução dos componentes no service mesh para fornecer uma visão geral visual de quais serviços estão se comunicando com os outros. Também é possível interagir com o gráfico e explorar áreas que podem ser problemas para saber mais sobre o que está acontecendo (POSTA, 2019). 19 _{https://zipkin.io/} 20 _{https://www.jaegertracing.io/} 21 _{https://grafana.com/} 22 _{https://www.elastic.co/pt/products/kibana} 23 _{https://www.kiali.io/}

Figura 10 – Dashboard web de rastreamento com Zipkin. Fonte: (ISTIO,2019p)

Figura 11 – Visualização detalhada de rastreamento com Jaeger. Fonte: (ISTIO,2019c)

Tendo em conta essas ferramentas como opções para a composição da solução proposta neste trabalho, na seção a seguir é apresentada uma visão geral da aplicação alvo trabalhada, a plataforma SigSaúde.

Figura 12 – Dashboard de métricas de serviços utilizando Grafana. Fonte: (ISTIO, 2019m)