Quem configura o quê?
Para evitar confusão, aqui está uma divisão rápida de responsabilidades:
Lado do cliente
Na sua infraestrutura, a configuração principal para observabilidade está no arquivocomponents/infra/grafana/otelcol-config.yaml.
Neste arquivo, você define o comportamento do collector:
- Processors: batching, limites de memória, filtragem, ofuscação, sampling, etc.
- Exporters: por exemplo, roteamento duplo para Prometheus
- Secrets de autenticação de API key
Após editar este arquivo, você deve reiniciar o stack com
make down && make up para que as alterações tenham efeito.Lado da Lerian
Na infraestrutura gerenciada pela Lerian, o stack de observabilidade é configurado e operado centralmente. Isso inclui:- Central Collector
- Prometheus
- Loki
- Tempo
- Grafana
Esses componentes são pré-configurados e mantidos pela Lerian. Você não os edita diretamente.
Como os dados fluem
Os dados de telemetria originam-se na sua aplicação e fluem através de um Client Collector, alimentado pelo OpenTelemetry. Rodando no seu ambiente, este collector enriquece os dados e os encaminha com segurança para um Central Collector gerenciado pela Lerian. De lá, são roteados para três backends especializados:
- Prometheus para métricas
- Loki para logs
- Tempo para traces
Componentes do stack
Juntos, esses componentes formam um pipeline de observabilidade completo: flexível do seu lado, consistente e seguro do lado da Lerian, e totalmente baseado em padrões OpenTelemetry.
Client Collector
O Client Collector é um OpenTelemetry Collector leve que roda próximo à sua aplicação, seja como DaemonSet ou Deployment. Ele enriquece a telemetria com metadados do Kubernetes e seu identificador de tenant (client_id), então roteia os dados para o Central Collector.
É importante porque reduz a carga no pipeline central, permite filtragem na origem e anexa metadados cruciais como k8s.pod.name. A instalação é gerenciada via Helm e Terraform, facilitando a integração na sua infraestrutura.
Central Collector
O Central Collector é um deployment centralizado do OpenTelemetry Collector que recebe telemetria de todos os clientes. Ele realiza processamento global, aplica multi-tenancy e exporta sinais para os backends de armazenamento apropriados.O Central Collector é totalmente gerenciado pela Lerian. Você não o configura ou modifica diretamente.
Prometheus
O Prometheus é otimizado para armazenar e consultar dados numéricos de séries temporais. O Central Collector envia métricas usandoremote_write.
Loki
O Loki armazena logs usando indexação baseada em labels, tornando-o rápido e econômico. Os logs são enviados do Central Collector para o serviçoloki-write.
Tempo
O Tempo armazena traces distribuídos completos e se integra fortemente com Prometheus e Loki através do Grafana.Grafana
O Grafana é seu painel único de visualização. Ele se conecta ao Prometheus, Loki e Tempo, permitindo que você correlacione métricas, logs e traces em um só lugar.Embedded Collector
Você pode habilitar o Client Collector como uma dependência da sua aplicação Midaz com uma única flag de configuração:
Editando o Client Collector
Quando você precisa personalizar o comportamento (ofuscação, filtragem, sampling, etc.), você irá:
-
Editar
components/infra/grafana/otelcol-config.yaml. -
Adicionar ou ajustar os blocos de
processorsouexporters. -
Reiniciar o stack:
Processors do Client Collector
No OpenTelemetry Collector, os processors são o núcleo da manipulação de dados. Eles rodam sequencialmente para enriquecer, filtrar, amostrar e transformar dados de telemetria antes de exportá-los para os backends. Abaixo está a lista de processors configurados no Lerian Client Collector, seu propósito e como configurá-los. 1. batch
- O que é: Agrupa múltiplos sinais de telemetria (métricas, logs ou traces) em lotes antes de enviá-los para a próxima etapa.
- Por que é importante: Melhora a eficiência de compressão, reduz requisições de rede e melhora a performance geral do pipeline.
- Configuração:
- O que é: Monitora o uso de memória do collector e descarta dados se ele se aproximar de um limite definido.
- Por que é importante: Previne que o collector seja OOMKilled pelo Kubernetes.
- Configuração:
- O que é: Gera métricas diretamente dos dados de trace.
- Por que é importante: Produz métricas “RED” (Rate, Errors, Duration) automaticamente.
- Configuração:
- O que é: Remove atributos sensíveis de span usando regex.
- Por que é importante: Mantém identificadores mas remove headers, bodies ou outros dados sensíveis da requisição.
- Configuração:
- O que é: Uma estratégia de sampling aplicada após os spans serem recebidos.
- Por que é importante: Mantém apenas traces de alto valor (erros, clientes específicos) e reduz custos de armazenamento.
- Configuração:
- O que é: Filtra métricas de nível de node.
- Por que é importante: Reduz ruído e foca em telemetria de nível de aplicação.
- Configuração:
- O que é: Mantém apenas métricas de
midazemidaz-plugins. - Por que é importante: Elimina workloads Kubernetes irrelevantes.
- Configuração:
- O que é: Adiciona metadados do Kubernetes à telemetria.
- Por que é importante: Permite contexto mais rico nas consultas do Grafana.
- Configuração:
- O que é: Insere ou atualiza
client.idna telemetria. - Por que é importante: Crítico para multi-tenancy.
- Configuração:
- O que é: Remove o conteúdo do body do log.
- Por que é importante: Previne que dados sensíveis ou PII persistam nos logs.
- Configuração:
- O que é: Ofusca atributos selecionados.
- Por que é importante: Protege valores sensíveis (como
legalDocumentouaccountAlias) antes que os dados deixem seu cluster. - Configuração (
otelcol-config.yaml):
- Personalizando os campos:
- Padrões:
legalDocument,accountAlias - Adicione ou remova campos conforme necessário
- Reinicialização necessária:
make down && make up
- Padrões:
Resumo
| Processor | Tipo de dado | Função | Benefício |
|---|---|---|---|
| batch | Métricas, Logs, Traces | Agrupa telemetria antes de exportar | Melhora compressão e uso de rede |
| memory_limiter | Métricas, Logs, Traces | Descarta dados quando limite de memória está próximo | Previne OOMKilled |
| spanmetrics | Traces → Métricas | Cria métricas RED | Insights imediatos de performance |
| transform/remove_sensitive_attributes | Traces | Remove attrs sensíveis de span | Mantém IDs, remove secrets |
| tail_sampling | Traces | Sampling inteligente de traces | Menor armazenamento, foco em erros |
| filter/drop_node_metrics | Métricas | Exclui dados ruidosos de nível de node | Dataset mais limpo |
| filter/include_midaz_namespaces | Métricas | Mantém apenas namespaces Midaz | Remove métricas irrelevantes |
| k8sattributes | Métricas, Logs, Traces | Adiciona metadados K8s | Contexto mais rico no Grafana |
| resource/add_client_id | Todos os sinais | Marca telemetria com client ID | Habilita multi-tenancy |
| transform/remove_log_body | Logs | Limpa body do log | Evita armazenar PII |
| transform/obfuscate_attributes | Todos os sinais | Mascara campos escolhidos | Garante que dados sensíveis nunca saiam |
Protegendo dados sensíveis
O Midaz trata o Client Collector como um firewall de telemetria. Todas as regras de filtragem, sampling e transformação são definidas no seu arquivo de configuração (
components/infra/grafana/otelcol-config.yaml).

Valores sensíveis como bodies de requisição, documentos legais ou aliases de conta nunca chegam ao Central Collector da Lerian.
- Client Collector (você configura): Roda no seu cluster. Aplique processors como
transform/remove_sensitive_attributes,transform/remove_log_bodyetransform/obfuscate_attributes. - Central Collector (gerenciado pela Lerian): Recebe apenas os streams de telemetria filtrados e sanitizados e os roteia para Prometheus, Loki e Tempo.
Você decide o que é sensível no
otelcol-config.yaml. A Lerian só vê a telemetria sanitizada.Fluxo de telemetria
Aqui está o que acontece quando a telemetria está habilitada:
- A aplicação inicia e detecta a configuração do OpenTelemetry.
- A telemetria é exportada para o Client Collector local.
- O Client Collector enriquece os dados com metadados do Kubernetes e seu
client_id. - Os processors enriquecem, filtram e transformam os dados.
- Os dados são encaminhados para o Central Collector.
- O Central Collector processa e roteia os dados:
- Métricas → Prometheus
- Logs → Loki
- Traces → Tempo
- O Grafana permite que você consulte tudo, correlacionando entre sinais.
Autenticando requisições do collector
Para garantir segurança e integridade dos dados, toda telemetria enviada do seu cluster para a plataforma da Lerian deve ser autenticada usando uma API key segura.
Como configurar
- Crie o Kubernetes Secret para armazenar seu token de API:
- Referencie o secret no seu arquivo de values do Helm para injetá-lo como variável de ambiente:
- A telemetria é enviada com segurança para o endpoint de telemetria da Lerian via HTTPS, com a API key incluída nos headers.
Esta chave deve permanecer privada. Se comprometida, entre em contato com o suporte da Lerian imediatamente para rotacionar o token.
Criptografia de dados em trânsito
Todos os dados de telemetria, incluindo métricas, logs e traces, são transmitidos do seu ambiente para a plataforma de observabilidade da Lerian usando HTTPS com criptografia TLS. Isso significa:
- A comunicação entre o Client Collector e o Central Collector é totalmente criptografada.
- Os dados em trânsito são protegidos contra interceptação, adulteração ou acesso não autorizado.
- Mesmo se o tráfego de rede for inspecionado, o conteúdo permanece ilegível sem as chaves criptográficas adequadas.
Aplicamos transporte criptografado por padrão. Nenhum dado é aceito por canais inseguros.
Roteamento duplo
Precisa manter uma cópia das suas métricas internamente? Você pode configurar o Client Collector para enviar telemetria para múltiplos destinos.
Exemplo
Esta configuração é ideal para monitoramento local sem interromper o fluxo padrão para o stack de observabilidade da Lerian.
Glossário
DaemonSet
DaemonSet
Um tipo de workload Kubernetes que garante que um Pod rode em cada (ou em nodes selecionados) node do cluster. Usado para fazer deploy do Client Collector, para que ele possa coletar dados de nível de node como métricas do Kubelet.
Deployment
Deployment
Um workload Kubernetes que gerencia réplicas de um Pod. Usado para o Central Collector e outros serviços da plataforma.
Exporter
Exporter
Envia dados de telemetria do Collector para um ou mais backends (ex.: Prometheus para métricas, Loki para logs, Tempo para traces).
Grafana
Grafana
Uma camada de visualização open-source. O Grafana se conecta ao Prometheus, Loki e Tempo para fornecer uma interface unificada para consultar e explorar métricas, logs e traces.
Loki
Loki
Nosso backend para logs. O Loki indexa labels de metadados em vez do conteúdo completo do log, tornando-o rápido e econômico para casos de uso de alto volume.
Multi-tenancy
Multi-tenancy
Uma abordagem arquitetural onde uma única plataforma atende múltiplos clientes (tenants). No Midaz, os dados de telemetria são marcados com um
client_id para garantir isolamento e rastreabilidade entre tenants.Observabilidade
Observabilidade
A capacidade de entender o estado interno de um sistema analisando suas saídas externas. Na prática, significa coletar e analisar métricas, logs e traces para monitorar performance e solucionar problemas.
OpenTelemetry (OTel)
OpenTelemetry (OTel)
Um framework open-source com ferramentas, APIs e SDKs para instrumentar, gerar, coletar e exportar dados de telemetria — métricas, logs e traces.
OTel Collector
OTel Collector
Um serviço standalone que recebe, processa e exporta dados de telemetria. Ele atua como uma ponte entre aplicações instrumentadas e backends como Prometheus ou Grafana.
OTLP (OpenTelemetry Protocol)
OTLP (OpenTelemetry Protocol)
O protocolo padrão usado pelo OpenTelemetry para transportar dados de telemetria entre aplicações, collectors e backends via gRPC ou HTTP.
Pipeline
Pipeline
Define como a telemetria flui através do Collector. Um pipeline tipicamente encadeia receivers, processors e exporters para um determinado tipo de sinal (métricas, logs ou traces).
Processor
Processor
Lida com a transformação de dados dentro do Collector, como enriquecer sinais com metadados, filtrar dados indesejados, agrupar mensagens em lotes ou aplicar políticas de sampling.
Prometheus
Prometheus
Nosso backend para armazenar e consultar métricas. Ele suporta consultas poderosas de séries temporais (PromQL) e se integra com o OpenTelemetry Collector via remote write.
Receiver
Receiver
O componente do Collector que ingere dados de telemetria recebidos. Suporta formatos como OTLP, Jaeger, Prometheus e outros.
SDK (Software Development Kit)
SDK (Software Development Kit)
Um conjunto de bibliotecas que você embute no código da sua aplicação para produzir sinais de telemetria como spans, contadores ou logs.
Tempo
Tempo
Nosso backend para traces. Ele armazena traces distribuídos completos e se integra estreitamente com Prometheus e Loki para correlação perfeita no Grafana.
Terraform
Terraform
Uma ferramenta de Infrastructure as Code (IaC) que usamos para provisionar e gerenciar infraestrutura em nuvem, incluindo a instalação de componentes de observabilidade via Helm.

