Monitoramento multi-tenant em todas as contas e regiões usando o Amazon Managed Service for Prometheus

A State Street opera em um ambiente complexo da AWS, que inclui vários tenants, regiões e contas, o que torna observabilidade em um desafio.

Nesta postagem, abordaremos como a State Street usou os serviços de observabilidade da AWS para agregar seus dados em um single pane of glass, utilizando o AWS Distro for OpenTelemetry (ADOT) e o Amazon Managed Service for Prometheus.

Visão geral da solução

Ao avaliar diferentes soluções de observabilidade, a State Street queria um serviço que tivesse pouca sobrecarga de gerenciamento e que não precisasse de um grande investimento inicial. Eles estavam procurando uma opção que minimizasse a carga de gerenciamento e os custos iniciais.

A arquitetura em alto nível da solução é ilustrada na Figura 1.

A State Street usou o Amazon Elastic Container Service (ECS) para executar tarefas de processamento de forma escalável usando o AWS Distro for OpenTelemetry (ADOT). O Amazon Managed Prometheus (AMP) forneceu persistência de dados por meio de dashboards do Grafana, permitindo a visualização e análise de dados. Os principais componentes foram: ECS para processamento de tarefas, ADOT para escalabilidade, AMP para armazenamento de dados e Grafana para visualização.

Figura 1 — Arquitetura em alto nível da solução

A State Street coletou métricas de desempenho dos recursos em seus ambientes monitorados, incluindo seus datacenters locais e várias contas da AWS em diferentes regiões. Eles agregaram esses dados de monitoramento, canalizando-os para uma conta central. Centralizar os dados dessa forma melhorou a confiabilidade e a segurança, além de simplificar a análise nos diferentes ambientes monitorados.

Os detalhes desse fluxo de trabalho estão divididos nas seguintes seções: Coleta de métricas, agregação e apresentação.

Coleta de Métricas
State Street utilizou uma combinação de soluções de métricas nativas da AWS e instrumentação de código para gerar as métricas. O cenário pode ser dividido em três categorias principais:

1. Métricas de serviços nativos da AWS:

— Coletado do Amazon CloudWatch usando o YACE (Yet-Another-CloudWatch-Exporter)

— O YACE expõe um endpoint compatível com ADOT que consulta e armazena em cache métricas da API da AWS

2. Métricas do Amazon EC2 e do Amazon ECS:

—  Exportadores de código aberto como node_exporter e cAdvisor

— Fornece maior frequência de envio e métricas adicionais

3. Métricas ad-hoc:

— Métricas específicas de linguagem, como JMX e python via opentelemetry-exporter-otlp;

— Também inclui métricas orientadas aos negócio, definidas a nível do aplicativo

Essas informações precisam ser coletadas e processadas, o que é feito pelos serviços do ECS que executam o ADOT configurado como scrapers. Cada scraper consulta periodicamente um subconjunto de recursos existentes, enriquecendo-os com metadados de identificação e encaminhando essas métricas para a Conta Central de observabilidade.

O diagrama de arquitetura que mostra essa fase é ilustrado na Figura 2.

Figure 2 – Diagram of scrapers in a monitored account

Figura 2 — Diagrama dos scrapers em uma conta monitorada

Para otimizar esse processo, a equipe implantou os scrapers nas mesmas zonas de disponibilidade dos recursos que eles monitoram. Isso reduziu a latência e os custos de transferência de dados. Para ambientes grandes, a tarefa ê dividida em vários scrapers, cada um responsável por consultar recursos específicos dentro do intervalo configurado. Eles são configurados para alta disponibilidade, com cada serviço do Amazon ECS configurado para executar várias cópias de cada scrapers. Isso garante a observabilidade durante as atividades de manutenção e em interrupções. Também foi implementado as funcionalidades de circuit breaker do Amazon ECS, para fornecer estabilidade durante as atualizações do serviço.

Agregação
A conta central recebe métricas de vários ambientes por meio de um conjunto de serviços ECS dedicados que executam o ADOT. Esses serviços são configurados para receber telemetria via HTTPS e mantê-la nos workspaces do AMP. A State Street chama esses serviços de middleware e, eles permitem uma integração sem atrito com fontes de dados On-Premise, pois oferecem suporte a padrões opensource da indústria.

Essa abordagem também tem vantagens para os ambientes da AWS:

1. Redução de sobrecarga de autenticação: configuração da autenticação básica para garantir que as métricas sejam ingeridas somente de fontes autorizadas
2. Escalável: reduz pressão de ingestão no AMP Workspace por meio do agrupamento de solicitações no middleware
3. Flexível: fornece uma camada de abstração entre os recursos e a análise, permitindo flexibilidade na escolha de soluções para coleta e apresentação de métricas

O diagrama da arquitetura dessa fase é ilustrado na Figura 3.

Figure 3 – Diagram of the middleware on the Central Account

Figura 3 — Diagrama do middleware na conta central

Lidando com cargas dinâmicas

O    volume métrico pode mudar significativamente devido a novas implantações, failovers, e etc. O middleware precisa ser responsivo para evitar a perda de dados durante eventos cruciais de observabilidade.

Para garantir a alta disponibilidade, a State Street utilizou o ECS Service Auto Scaling.

Para esse cenário, o escalonamento tradicional baseado em memória seria inadequado, pois durante a operação normal, os dados fluem tão rapidamente quanto entram, sem a necessidade de armazená-los em buffer/cache os dados. Um aumento no uso da memória indicaria contrapressão, eventualmente levando à falta de memória e à substituição da task.

Em vez disso, a State Street adotou o escalonamento automático com base na contagem de solicitações por destino do balanceador de carga. Foi executado testes de carga para estabelecer quantas solicitações por segundo poderiam processar de forma confiável, pois isso pode variar dependendo dos recursos e da configuração. Um exemplo do escalonamento automático em ação é mostrado na Figura 4, onde o número de solicitações ao longo do tempo é sobreposto aos eventos de escalabilidade. A linha pontilhada representa o limite configurado de solicitações por segundo.

Figura 4 — Escalonamento automático em ação. Ccontagem de solicitações do ALB por tarefa de middleware

Os pontos destacados correspondem a:

1. A. São operações regulares abaixo do limite com apenas 1 tarefa: Middleware 1.
2. Há um aumento nas solicitações, ultrapassando o limite configurado.
3. Uma nova tarefa (Middleware 2) é adicionada, o que reduz a carga por tarefa em níveis gerenciáveis.
4. Quando o número total de solicitações diminui, a tarefa adicional não é mais necessária.

Para melhorar ainda mais a disponibilidade da solução por meio de um aumento extremo nas solicitações, a equipe habilitou o processador limitador de memória disponível no ADOT. O limitador de memória monitora o uso da memória e reduz os pontos de dados de forma pessimista para não sobrecarregar a tarefa em execução quando o uso da memória está próximo do máximo. Isso raramente deve ocorrer, pois eles também configuraram uma margem de segurança no limite de expansão para cobrir o tempo de inicialização de novas tarefas de middleware.

Apresentação
O middleware então persiste os dados no Amazon Managed Service for Prometheus Workspaces, um espaço lógico dedicado ao armazenamento e à consulta das métricas do Prometheus. A State Street usou o Prometheus Remote Write Exporter. As métricas armazenadas no espaço de trabalho são então usadas para painéis e alertas usando o Grafana e os alertas nativos de AMP.

A Figura 5 é um snapshot dessa visualização, mostrando em verde a taxa de ingestão do AMP e em amarelo o número de tarefas do ECS de middleware.

Figura 5 — Visualização de métricas usando o Grafana

Isolamento do Tenant
Como um ambiente multi-tenant, um dos requisitos era controlar o acesso às informações do tenant, incluindo métricas.

Para fornecer graus extras de isolamento, a State Street replicou toda a solução para diferentes grupos de tenants, segregando as métricas no início do processo. Eles dedicaram scrapers, middlewares e workspaces a cada grupo. Ao fazer a coleta, eles filtram as métricas para incluir apenas os recursos aplicáveis para cada grupo de tenants. Em seguida, eles encaminham as métricas separadamente. Além disso, eles concedem apenas a cada grupo de tenants acesso ao seu próprio espaço de trabalho dedicado — nenhum grupo pode acessar métricas para os outros grupos.

Conclusão

Mesmo em configurações simples, alcançar uma observabilidade abrangente pode ser um desafio. A State Street enfrentou esse desafio ao consolidar: sua nuvem da AWS, ambientes locais e várias contas multi-tenant da AWS em todas as regiões em um sistema coeso e robusto.

Para superar isso, utilizou-se o AWS Distro for OpenTelemetry, o Amazon Managed Service for Prometheus e o Amazon Managed Grafana para criar uma estrutura de monitoramento que permite o monitoramento fácil e eficaz dos recursos. Ao utilizar essas ferramentas específicas da AWS para OpenTelemetry e Prometheus, conseguiram criar uma solução unificada de observabilidade que abrange ambientes, contas e regiões. Isso permite que seus usuários monitorem recursos em seu cenário complexo e multifacetado.

Para saber mais sobre os serviços do AWS Observability, confira os recursos abaixo:

— Workshop One Observability

—Guia de melhores práticas de observabilidade da AWS

— Configure a ingestão de métricas do Amazon ECS usando o AWS Distro para OpenTelemetry