Durante o quinto módulo do programa de capacitação DevOps da B3 em parceria com a Ada Tech, desenvolvemos algumas atividades de Observability. Nesse diretório, organizei em pastas os arquivos de cada atividade e abaixo deixei uma breve explicação sobre o tema.
Capacitação DevOps
O que é Observabilidade?
Observabilidade é a capacidade de entender o comportamento interno de um sistema com base em suas saídas, garantindo a tomada de decisões com confiança e possibilitando construir arquiteturas mais distribuídas, resilientes e tolerante a falhas.
Para iniciar, devemos seguir três etapas.
1. Avalie onde você está na curva de maturidade da observabilidade da aplicação
2. Colete os dados
Uma avaliação de como cada componente da aplicação depende de outros componentes, aplicações e recursos de TI.
Monitoramento é a prática de observar um sistema para garantir que ele esteja funcionando corretamente. Isso pode incluir a verificação de métricas, logs e rastreamentos para garantir que o sistema esteja funcionando corretamente.
Rastreamento é a prática de observar o comportamento de um sistema ao longo do tempo. Um registro de ponta a ponta, mostrando cada solicitação de usuário, conforme as transações passam de um serviço para outro.
Logs são registros de eventos que ocorrem em um sistema, com carimbo de data/hora, completos e imutáveis de eventos de aplicações em seu sistema.
Pesquisas periódicas de serviços específicos. Se uma verificação de integridade falhar, ela se transformará em um problema.
Notificações acionadas quando limites específicos predeterminados são ultrapassados.
Perspectivas de aplicações que fornecem apresentações visuais, interativas e compreensíveis sobre métricas específicas e predeterminadas.
Métricas são medidas quantitativas que podem ser usadas para avaliar numericamente o desempenho da aplicação, da utilização de recursos e da saúde geral do sistema em um determinado período de tempo.
3. Implemente práticas e princípios essenciais
Será necessário um otimização sistemática, a observabilidade mapeia e contextualiza as interações entre todos os recursos existentes na arquitetura. Disso, é de fundamental importância a contextualização completa, toda unidade de dados deve ser fornecida com um contexto completo, entrando em cena grandes ferramentas.
Ferramentas de Observabilidade
- Elastic Stack;
- Splunk;
- Graylog.
- Grafana;
- Zabbix;
- Nagios;
- Prometheus.
- New Relic;
- Data Dog;
- App Dynamics;
- Elastic APM.
Nesse diretório abordaremos apenas o Prometheus, o Grafana, o Elastic Stack e o Graylog.
Prometheus e Grafana
Prometheus é um sistema de monitoramento e alerta de código aberto. Ele coleta métricas de alvos configurados por meio de um modelo de coleta e armazenamento de séries temporais com um poderoso mecanismo de consulta.
Usados para medir incidência, como o número de solicitações recebidas por um servidor ou o número de erros que ocorrem em um sistema.
Representam a distribuição de valores em um conjunto de dados. Ele divide os dados em intervalos ou "bins" e mostra quantas observações estão em cada intervalo.
Também chamado de estatística resumida, é uma forma de resumir os principais aspectos de um conjunto de dados de uma forma concisa e informativa.Geralmente, inclui estatísticas descritivas, como média, mediana, moda, mínimo, máximo e desvio padrão.
Mostra a mudança do valor ao longo do tempo, identifica padrões sazonais, flutuações de curto e longo prazo, e outros comportamentos temporais significativos.
Os hosts são monitorados para garantir que estejam operando corretamente, medindo métricas como CPU, memória, disco, rede e outros recursos.
Sua verificação envolve acompanha o tempo que as consultas levam para serem processadas, identificando consultas lentas que podem impactar negativamente o desempenho, monitora bloqueios de transações e deadlocks, assim como, o tempo de atividade e indisponibilidade.
Métricas como tempo de resposta, tempo de carregamento da página, erros HTTP, transações por segundo, entre outras, são monitoradas para garantir uma boa experiência do usuário.
Os serviços representam processos ou conjuntos de processos que trabalham juntos para fornecer uma funcionalidade específica.Eles podem incluir serviços web, bancos de dados, servidores de arquivos, etc.
Alertas de limiar são alertas que são acionados quando uma métrica ultrapassa um determinado limite.
Alertas de anomalia são alertas que são acionados quando uma métrica se desvia significativamente de seu comportamento normal.
Alertas de tendência são alertas que são acionados quando uma métrica mostra uma tendência significativa ao longo do tempo.
Alertas de correlação são alertas que são acionados quando duas ou mais métricas mostram um comportamento correlacionado.
São usadas para realizar cálculos sobre conjuntos de dados, como soma, média, mínimo, máximo, contagem, entre outros. Exemplo: calcular a receita total de vendas em um período de tempo específico.
Consultas de filtro são consultas que são usadas para filtrar um conjunto de dados com base em um critério específico. Exemplo: recuperar todos os pedidos feitos por um cliente específico.
Consultas de projeção são consultas que são usadas para selecionar um subconjunto de colunas de um conjunto de dados. Exemplo: selecionar apenas os nomes e emails dos clientes de uma tabela de clientes.
Consultas de transformação são consultas que são usadas para transformar um conjunto de dados em um formato diferente. Exemplo: converter todas as letras em maiúsculas em uma coluna de nomes de clientes.
Enquanto o Prometheus é uma ferramenta de monitoramento de código aberto projetada principalmente para sistemas baseados em métricas, o Grafana é uma plataforma de visualização e análise de dados que pode ser integrada com várias fontes de dados, incluindo o Prometheus.
Em resumo, o Grafana é uma ferramenta poderosa e versátil, oferecendo uma ampla gama de recursos e integrações para atender às necessidades de monitoramento e observabilidade em diferentes domínios e ambientes. Sua flexibilidade, facilidade de uso e extensibilidade o tornam uma escolha popular entre profissionais de TI, desenvolvedores e analistas de dados.
Elastic Stack e o Graylog
A plataforma de análise distribuída consiste em várias ferramentas interconectadas desenvolvidas pela Elastic.
- Elasticsearch: Um motor de busca distribuído e escalável que armazena, indexa e permite pesquisar dados de forma eficiente.
- Logstash: Um pipeline de ingestão de dados que coleta, processa e envia logs e outros dados para o Elasticsearch.
- Kibana: Uma interface de usuário para visualizar e explorar dados indexados no Elasticsearch, oferecendo recursos avançados de análise e visualização.
- Beats: Conjunto de agentes de coleta de dados leves que enviam dados de logs e métricas diretamente para o Elasticsearch ou para o Logstash.
- Monitoramento de infraestrutura e aplicativos.
- Análise de logs de segurança.
- Análise de logs de servidores e aplicações.
- Monitoramento de métricas de desempenho.
Graylog é uma plataforma de gerenciamento de logs de código aberto que facilita a coleta, processamento e análise em tempo real.
- Graylog Server: O núcleo da plataforma, responsável pela ingestão, processamento e indexação de logs.
- MongoDB: Um banco de dados NoSQL usado para armazenar metadados e configurações do Graylog.
- Graylog Web Interface: Uma interface web para pesquisar, visualizar e analisar logs, além de configurar alertas e dashboards.
- Graylog Collector Sidecar: Uma ferramenta para coletar logs de servidores e dispositivos e enviá-los para o Graylog Server.
- Elastic Stack geralmente utiliza Elasticsearch como mecanismo de armazenamento e busca.
- Graylog utiliza Elasticsearch para armazenamento e busca de dados, mas também requer MongoDB para armazenamento de metadados e configurações.
Em resumo, tanto Elastic Stack quanto Graylog são excelentes soluções para gerenciamento de logs. A escolha entre eles geralmente depende das necessidades específicas da organização, das preferências de arquitetura e das habilidades da equipe técnica.
Desafio
Criar um dashboard de observabilidade com base nas melhores práticas, usando métricas do Prometheus, para monitorar um sistema composto por uma API Rest em Python, um Worker em Node.js, um Frontend em Node.js, um banco de dados PostgreSQL e um Redis pode ser dividido em várias etapas.- Identificar os principais componentes do sistema a serem monitorados (API, Worker, Frontend, PostgreSQL, Redis).
- Definir os KPIs e as métricas essenciais para monitorar o desempenho e a saúde do sistema.
- Especificar os painéis e visualizações necessárias para cada contexto (API, Worker, Frontend, Bancos de Dados, Cache).
- Configurar o Prometheus para coletar métricas dos componentes do sistema. Isso pode envolver a definição de alvos de coleta, regras de alerta e configuração de retenção de dados.
- Usar etiquetas (labels) para adicionar metadados às métricas, permitindo uma segmentação eficaz dos dados.
- Criar um dashboard principal com base nos quatro sinais dourados da observabilidade: latência, tráfego, erros e saturação.
- Para cada contexto do sistema (API, Worker, Frontend, Banco de Dados, Redis), criar painéis individuais com métricas específicas e relevantes para aquele componente.
- Personalizar os painéis com gráficos, tabelas, alertas e outros elementos visuais para representar as métricas de forma clara e informativa.
- Definir regras de alerta com base nos limiares definidos para cada métrica.
- Configurar notificações para alertar a equipe responsável em caso de problemas ou degradação do sistema.
- Garantir que os alertas sejam claros, acionáveis e escalonáveis.
- Realizar testes para garantir que todas as métricas estejam sendo coletadas corretamente e que os painéis de visualização estejam funcionando conforme o esperado.
- Implementar monitoramento contínuo para garantir que o dashboard esteja sempre atualizado e refletindo com precisão o estado do sistema.
- Revisar e iterar sobre o dashboard conforme necessário para incluir novas métricas ou ajustar limiares de alerta com base no feedback e na evolução do sistema.
KPIs (Key Performance Indicators) são indicadores-chave que medem o desempenho e o sucesso de um sistema ou processo em alcançar seus objetivos. Para monitorar o desempenho e a saúde do sistema composto por uma API Rest em Python, um Worker em Node.js, um Frontend em Node.js, um banco de dados PostgreSQL e um Redis, podemos considerar os seguintes KPIs e métricas essenciais:
-
Latência da API:
- Métricas: Tempo médio de resposta das solicitações, tempo máximo de resposta, distribuição de tempo de resposta por intervalo.
- KPI: Tempo médio de resposta das solicitações deve ser mantido abaixo de um limite definido.
-
Taxa de Erros da API:
- Métricas: Número total de erros, distribuição de tipos de erros (por exemplo, erros 4xx, 5xx), taxa de erros por solicitação.
- KPI: A taxa de erros por solicitação deve ser mantida abaixo de um limite definido.
-
Utilização do Worker e do Frontend:
- Métricas: Utilização da CPU, utilização da memória.
- KPI: Utilização da CPU e da memória deve ser mantida dentro de limites aceitáveis para evitar sobrecarga.
-
Desempenho do Banco de Dados:
- Métricas: Tempo de resposta das consultas, número de consultas por segundo, tamanho do cache de consultas.
- KPI: Tempo médio de resposta das consultas deve ser mantido abaixo de um limite definido.
-
Desempenho do Redis:
- Métricas: Taxa de hits e misses no cache, utilização da memória.
- KPI: Taxa de hits no cache deve ser mantida alta para garantir uma boa taxa de cache.
-
Latência: Gráfico de linhas mostrando a latência média da API ao longo do tempo, com alertas configurados para disparar se a latência exceder um limite definido.
-
Tráfego: Gráfico de barras exibindo o número de solicitações HTTP recebidas pela API, separadas por código de status (200 OK, 4xx, 5xx), para entender a carga de tráfego e identificar possíveis problemas de roteamento ou sobrecarga.
-
Erros: Gráfico de pizza mostrando a distribuição de tipos de erros (por exemplo, erros de servidor, erros de validação) gerados pela API, com alertas configurados para acionar se o número de erros aumentar repentinamente.
-
Saturação: Gráfico de área exibindo a utilização de CPU e memória do Worker e do Frontend, com linhas de tendência para identificar padrões de uso e alertas configurados para disparar se a utilização atingir níveis críticos.
Para cada contexto do sistema (API, Worker, Frontend, Bancos de Dados, Cache), podemos especificar os seguintes painéis e visualizações:
-
API:
- Gráfico de linhas para acompanhar a latência ao longo do tempo.
- Gráfico de barras para monitorar o número de solicitações e erros.
- Tabela com detalhes de erros recentes.
-
Worker e Frontend:
- Gráfico de área para visualizar a utilização da CPU e memória.
- Gráfico de pizza para mostrar a distribuição de recursos por processo ou tarefa.
-
Bancos de Dados:
- Gráfico de linha para mostrar o tempo de resposta das consultas.
- Gráfico de barras para monitorar o número de consultas por segundo.
- Gráfico de área para exibir o tamanho do cache de consultas.
-
Cache (Redis):
- Gráfico de área para mostrar a taxa de hits e misses no cache.
- Gráfico de linha para visualizar a utilização da memória.
- O roteiro acima é uma orientação geral e pode ser adaptado de acordo com as necessidades que você achar necessário.
- É importante manter o dashboard e as configurações de alerta atualizadas à medida que o sistema evolui e novas métricas se tornam relevantes.
Documentação do Grafana
https://grafana.com/docs/grafana/latest/getting-started/build-first-dashboard/
https://grafana.com/docs/grafana/latest/alerting/
Curso de Observabilidade Adatech
https://comunidade.ada.tech/cursos/1eebae37-f785-6880-157f-4e35fb7219d4
