Eu iria falar sobre Prometheus uma ferramenta de monitoramento e alertas de código aberto, voltada para métricas de séries temporais. Ele coleta, armazena, consulta e exibe métricas. Muito usado com Kubernetes, servidores, aplicações web, bancos de dados. Mas essa ferramenta tem alguns componentes interessantes em sua arquitetura como TSDB

Vou abordar arquitetura interna do Time Series Database (TSDB) utilizado pelo Prometheus, detalhando os componentes principais e o fluxo de dados desde a coleta até a persistência e indexação. O objetivo é fornecer uma visão geral de como o TSDB armazena e gerencia dados de séries temporais, destacando a importância de cada componente para o desempenho e a confiabilidade do sistema.

A arquitetura interna do TSDB pode ser resumida no seguinte fluxo de dados:

Componentes Principais e Fluxo de Dados

1. Exporters / Targets

Os Exporters e Targets são os pontos de extremidade (endpoints) HTTP que expõem as métricas. Eles são responsáveis por fornecer os dados que o Prometheus irá coletar. Esses exporters podem ser aplicações instrumentadas para expor suas próprias métricas, ou serviços dedicados que coletam métricas de outros sistemas (como o node_exporter para métricas do sistema operacional).

2. Scrape (Coleta)

O processo de "scrape" (coleta) é a ação peiódica realizada pelo Prometheus para obter as métricas dos Exporters/Targets. O Prometheus configura um loop de coleta (Scrape Loop) que, em intervalos regulares, consulta os endpoints configurados e armazena os dados recebidos. A frequência de coleta é configurável e pode variar dependendo da importância e da volatilidade das métricas.

3. Head (Memória)

A "Head" é o componente que mantém os dados mais recentes em memória. Ela armazena os dados em "chunks", que são blocos de dados de séries temporais. Cada amostra de dado é representada como um par [ts: int64, val: float64], onde ts é o timestamp (inteiro de 64 bits) e val é o valor da métrica (ponto flutuante de 64 bits). A Head é otimizada para escritas rápidas e consultas recentes, servindo como o cache primário para os dados mais atuais.

4. Write-Ahead Log (WAL)

O Write-Ahead Log (WAL) é um registro de escrita, essencial para a recuperação de dados em caso de falha. Antes de qualquer dado ser gravado na Head, ele é primeiro escrito no WAL. Isso garante que, mesmo que o Prometheus falhe inesperadamente, os dados que ainda não foram persistidos em disco possam ser recuperados a partir do WAL. O WAL atua como um "journal", registrando todas as operações de escrita em sequência.

5. Blocos Persistentes (Compaction)

Os dados na Head são eventualmente compactados e gravados em disco em intervalos regulares (por padrão, a cada 2 horas). Esse processo é chamado de "compaction". A compactação envolve a criação de blocos persistentes, que são arquivos otimizados para leitura e armazenamento de longo prazo. A compactação também inclui a agregação e a otimização dos dados, como a remoção de dados duplicados e a criação de índices para acelerar as consultas.

6. Arquivos de Índice

Os arquivos de índice são cruciais para acelerar as consultas. Eles mapeiam labels (rótulos) para séries temporais, permitindo que o Prometheus encontre rapidamente os dados relevantes para uma determinada consulta. Sem os índices, o Prometheus teria que escanear todos os blocos de dados para encontrar as séries correspondentes, o que seria extremamente ineficiente. Os índices são construídos durante o processo de compactação e atualizados à medida que novos blocos são criados.

Detalhes Adicionais

• Histograms e Summaries: O Prometheus suporta tipos de métricas especiais, como histogramas e summaries, que permitem coletar informações sobre a distribuição dos dados. Esses tipos de métricas são armazenados e processados de forma diferente das métricas simples, mas seguem o mesmo fluxo geral de dados.
• Lifecycle de uma Amostra: O ciclo de vida de uma amostra no TSDB envolve a coleta, o armazenamento na Head, a escrita no WAL, a compactação em blocos persistentes e a indexação. Cada etapa é otimizada para garantir o desempenho e a confiabilidade do sistema.
• Considerações de Desempenho: O desempenho do TSDB depende de vários fatores, incluindo a frequência de coleta, o tamanho da Head, a velocidade do disco e a complexidade das consultas. A otimização desses fatores é essencial para garantir que o Prometheus possa lidar com grandes volumes de dados.

E porque isso importa para um SRE?

 Entender o TSDB ajuda a:

• Otimizar o uso de métricas (evitar cardinalidade alta)
• Escrever alertas mais performáticos
• Prever o impacto de retenção de dados e compactações
• Diagnosticar consumo de disco e memória

Referências

Prometheus TSDB Internals: https://prometheus.io/docs/prometheus/latest/storage/

Lifecycle of a Sample in TSDB – FOSSASIA: https://www.youtube.com/watch?v=35TAaAESLcc

Histograms and Summaries: https://prometheus.io/docs/practices/histograms/

Selecting Data in PromQL : https://promlabs.com/blog/2020/07/02/selecting-data-in-promql/