• O que é o OpenTelemetry?
• Quais os componentes do OpenTelemetry?
  • Receivers
  • Processors
    • Batch
    • Span
    • Memory Limiter
    • Resource
    • Attributes
    • Filters
  • Exporters
  • Connectors
  • Extensions e Services
• Tail Sampling Processor
  • Funções e parâmetros importantes
  • Policies mais utilizadas
• Segurança e dados sensíveis (PII não é opcional)
  • PII – Personally Identifiable Information
  • Hash
  • Regex
  • Delete
• Certificados, Keycloak e OpenID
• OpenTelemetry Collector Builder (OCB) e Load Balancing Exporter
  • OpenTelemetry Collector Builder (OCB)
  • Load Balancing Exporter
• Cardinalidade: Os 10 mandamentos para quem começa
• Dica de ouro

Ao final da escrita me dei conta que fiz um tcc, por isso o sumário hahaha

O mundo da telemetria te oferece muitas possibilidades de coleta e transformação de dados. Antes de usar e listar pré-requisitos para começar a brincar nas instrumentações é importante saber a estrutura e objetivo do framework. Já deixo aqui meu profundo agradecimento ao Juraci Paixão Kröhling, Danilo Háwila e Marilya Gutierrez. São minhas referências de aprendizado contínuo com telemetria e indico totalmente para quem está começando.

Outra sugestão, caso se interessem é o livro Learning OpenTelemetry - Setting Up and Operating a Modern Observability System, foi escrito pelos co-fundadores Ted Young e Austin Parker do opentelemetry e tem uma linguagem muito bacana para explicar como os desafios foram pensados para que entenda como utilizar em aplicações modernas. Inclusive, irei apresentar insights referenciando-o nesse artigo.

1. O que é o Opentelemetry?

Trata-se de um framework de observabilidade, explicando for dummies, um esqueleto de código personalizável que irá receber telemetria, modificar, e enviar de forma segura para uma central de recebimento (backends como Grafana, Datadog, Dynatrace, Splunk, Jaeger…etc), que normalmente armazenam em um storage (s3, minIO, RustFs…) e possuem um frontend para tu criar alertas, dashboards, calcular sli, slo de forma correlacionada a fim de compreender o comportamento dos eventos gerados da sua aplicação. Utiliza o modo event-driven (envio por eventos) e seus dados são enviados em tempo real.

Uma analogia criada por Marilya Gutierrez para melhor fixação é o Cabo C, ele é universal para carregar diversos tipos de celulares (enviando telemetria para diversos tipos de backends) e possui o USB que seria sua aplicação enviando a telemtria. Isso revela o diferencial do OpenTelemetry, ser agnóstico. Ele é compatível com os backends de observabilidade tirando o lock-in, que é a venda de produtos com agents proprietários pagos. Caso queira mudar a solução, basta editar o apontamento e não fazer o retrabalho de tirar o agent e instrumentar novamente. Assunto sensível em aplicações críticas.

Para começar a diversão, segundo as definições de Ted Young e Austin Parker em 2024 na obra citad acima, temos os 3 pilares de observabilidade:métricas, logs e traces e cada um deles é composto pelas etapas abaixo, e dessa forma o opentelemetry se comporta:

Fonte: Young, T., & Parker, A. (2024). Learning OpenTelemetry: Setting Up and Operating a Modern Observability System. O’Reilly Media. ISBN: 978‑1‑098‑14718‑1.

1.2 Quais os componentes do Opentelemetry?

1.2.1 Receivers

Os receptores ou Receivers como é chamado no bloco de código portão de entrada para recerber a telemetria. Quando for configurar o seu, olhe os modelos já prontos que a comunidade criou para facilitar seu processo https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver

Se o collector for local, define a porta e mantem o ip zerado

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

OTLP (OpenTelemetry Protocol) - Nativo

O OTLP é o padrão recomendado e nativo, projetado para interoperabilidade e eficiência.

Os formatos aceitos pelo coletor opentelemetry são:

• gRPC: Geralmente usa a porta 4317. É preferencial para alto desempenho.

• HTTP/Protobuf: Usa a porta 4318. Dados codificados em Protocol Buffers sobre HTTP.

• HTTP/JSON: JSON sobre HTTP, facilitando a depuração, mas com maior overhead que Protobuf.

1.2.2 Processors

Eles são responsáveis por modificar ou transformar os dados antes de exportar para os backends.

1.2.2.1 Batch

O batch processor agrupa dados de telemetria (spans, métricas ou logs) antes de enviá-los aos exporters, reduzindo overhead e melhorando desempenho.

      batch:
        send_batch_size: 1000
        timeout: 5s

Você pode definir o tamanho e o timeout.

• send_batch_size: Quantidade de itens no lote, atinge esse número ele envia imediatamente
• timeout: Tempo máximo de espera, mesmo que o batch não esteja cheio, ele envia

1.2.2.2 Span

O bloco span permite modificar, renomear, filtrar ou excluir spans antes que eles sejam exportados.

Lembrete: A configuração funciona apenas para traces.

Abaixo deixo 4 exemplos de como trabalhar:

# Exclusão de spans irrelevantes
span:
        exclude:
          match_type: strict
          span_names: ["Transaction.commit"]
        name:
          from_attributes: ["resource.service.name"]

# Renomear spans
span:
        - 'attributes["container.name"] == "app_container_1"'
        - 'resource.attributes["host.name"] == "localhost"'
        - 'name == "app_3"'

# Expressão de filtro OTTL = Aplique essa regra apenas se o span for gRPC E se o nome do span indicar que é gRPC.
spanevent:
        - 'attributes["grpc"] == true'
        - 'IsMatch(name, ".*grpc.*")'

# Extrair parte do nome do span e jogar em atributos
  span:
    name:
      to_attributes:
        rules:
          - ^\/api\/v1\/document\/(?P<documentId>.*)\/update$
      from_attributes: [db.svc, operation]
      separator: '::'

1.2.2.3 Memory_limiter

O memory_limiter controla o uso de memória do Collector, limitando quanto de telemetria pode ser processada ao mesmo tempo para evitar OOMKill e instabilidade.

# A cada 5 segundos o Collector verifica o uso real de memória do processo.

 memory_limiter:
        check_interval: 5s
# Limite máximo de memória permitido para o Collector: ~2 GB
        limit_mib: 2024 
# Tolerância para picos rápidos de memória: ~1.5 GB
        spike_limit_mib: 1500

Acima tem alguns parâmetros que pode definir, e vale salientar que nos casos de ter um collector por aplicação você poderá aplicar a regra de negócio.

1.2.2.4 Resource

Um dos blocos mais subestimados, mas ele revela sobre quem aquele evento está falando. Não só revela como utiliza de actions para proteger seus dados como hashs e deleta atributos irrelevantes.

Quando o trace te entrega um evento ruim na aplicação, ele responde as seguintes perguntas:

• Quem gerou?

• Em qual ambiente?

• Em qual cluster?

Esse é um modelo que pode ser usado:

resource:
        attributes:
        # Cria o atributo hostname copiando o valor de host.name
          - action: insert
            key: hostname
            from_attribute: host.name

        # Cria o atributo container_name a partir de k8s.container.name
          - action: insert
            key: container_name
            from_attribute: k8s.container.name

        # Cria o atributo service_name copiando o valor de service.name
          - action: insert
            key: service_name
            from_attribute: service.name

Um exemplo de como ficaria:

service.name=payment
deployment.environment=prod
k8s.cluster.name=eks-prod

Se faz importante alertar que é uma boa prática evitar colocar user.id, order.id, ou usar resource diferente para o mesmo serviço. Lembre-se que em larga escala manter um padrão fará diferença, pois precisará concatenar dados e usar regex no frontend da stack que irá trabalhar.(a maioria já faz insights automáticos)

Resource bem definido reduz cardinalidade sem perder contexto.

E falando em facilidades no frontend, eles são fundamentais para: agregação de métricas, definição de SLOs, filtros em traces e logs e custo (labels estáveis)

Cuidado ao colocar dado dinâmico em resource! Pode bagunçar sua visualização.

1.2.2.5 Attributes

São eles que contam a história certa! E os 3 pilares podem ser trabalhados com eles, logs, métricas e traces.

Span/traces

Dando contexto para um evento, por exemplo:

http.method = POST
http.route = /checkout
http.status_code = 500
db.system = postgres

Logs

Dando contexto ao log

level = error
user.role = admin
component = auth

Métricas

Dimensões de agregação

method = GET
status = 200
route = /checkout

Com eles você pode adicionar, remover, modificar, padronizar ou proteger dados sensíveis.

Através das funções de ação:

• insert
• delete
• update
• upsert
• hash

attributes:
    actions:
     # Insere o atributo resource.labels com o valor especificado, se ele ainda não existir.
        key: resource.labels
        value: hostname, container_name
        action: insert

     # Adiciona o atributo environment=production se ele ainda não existir.
      - key: environment
        value: production
        action: insert

     # Remove completamente o atributo db.statement do span/log/métrica.
      - key: db.statement
        action: delete
        
     # Aplica um hash irreversível no valor do atributo email.(O dado continua existindo, mas não pode ser revertido para o valor original, usado para ofuscar valor irreversivelmente)
      - key: email
        action: hash

1.2.2.6 Filters

Outra chave poderosa do processor que decide quais dados continuam no pipeline e quais são descartados, com base em expressões OTTL. No modo for dummies ele corta dados na origem para reduzir ruído, custo e risco.

Destrinchando um exemplo:

# Data sources: metrics, metrics, logs
  filter:
  # Se uma expressão falhar, o Collector ignora o erro e segue o fluxo
    error_mode: ignore
  # Descartar spans que correspondam a qualquer uma dessas condições
    traces:
      span:
      # Remove spans gerados por esse container específico
        - 'attributes["container.name"] == "app_container_1"'
      # Remove spans vindos de execução local (dev/test)
        - 'resource.attributes["host.name"] == "localhost"'
      # Remove spans com nome exato "app_3"
        - 'name == "app_3"'
    # Remove eventos de span (span events) relacionados a gRPC
      spanevent:
        - 'attributes["grpc"] == true'
        - 'IsMatch(name, ".*grpc.*")'

    # Essas regras filtram a métrica inteira
    metrics:
      metric:
        - 'name == "my.metric" and resource.attributes["my_label"] == "abc123"'
        - 'type == METRIC_DATA_TYPE_HISTOGRAM'
    # Remove apenas pontos de dados específicos, não a métrica inteira
      datapoint:
        - 'metric.type == METRIC_DATA_TYPE_SUMMARY'
        - 'resource.attributes["service.name"] == "my_service_name"'

    logs:
      log_record:
      # Remove logs que contenham a palavra password.
        - 'IsMatch(body, ".*password.*")'
      # Remove logs de nível:DEBUG e INFO
        - 'severity_number < SEVERITY_NUMBER_WARN'

1.2.3 Exporters

O ponto agnóstico do nosso cabo C. É aqui que você poderá definir quem irá receber sua telemetria.

exporters:
# Imprime a telemetria no log do Collector, excelente para debug de pipeline, validação de processors, testes locais
debug:
    verbosity: detailed

otlp:
# Envia telemetria via protocolo OTLP para outro Collector ou backend compatível
    endpoint: otelcol2:4317
    # Habilita comunicação segura (mTLS).
    tls:
      cert_file: cert.pem
      key_file: cert-key.pem

# Envio de métricas
prometheus:
    endpoint: 0.0.0.0:8889
    namespace: default

# Envio de traces 
 zipkin:
    endpoint: http://zipkin.example.com:9411/api/v2/spans
  
# Envio de logs
otlphttp/logs:
        endpoint: LOGS_URL
        tls:
          insecure: true

Eu sei que você viu sobre o tls, mas falaremos disso já já.

1.2.4 Connectors

São componentes que consomem um tipo de sinal e produzem outro tipo de sinal, conectando pipelines diferentes. Pode consumir dados como exportador no final de um pipeline e emite dados como receptor no início de outro pipeline.

Ficou confuso? segue exemplo:

connectors:
  count:
  # Aqui eu concateno a contagem do meu atributo
    spanevents:
      my.prod.event.count:
        description: Contagem de spans que tem no meu ambiente de prod.
        conditions:
          - 'attributes["env"] == "prod"'
          - 'name == "prodevent"'

Com eles você pode dar profundidade ao seu evento, mas lembre que o básico bem feito entrega valor e aqui uma conexão de span mal tratado só irá amplificar o problema. Pois aqui os traces viram métricas.

1.2.5 Extensions e Services

Enquanto em services tu irá listar quais recursos seu coletor vai usar, seria como um resumo, mas se habiitar a função e não colocar nele, nada feito.

 service:
      extensions: [health_check]
      pipelines:
        traces:
          receivers: [otlp]
          processors: [span,batch]
          exporters: [otlp]
        logs:
          receivers: [otlp]
          processors: [resource, attributes, memory_limiter]
          exporters: [otlphttp/logs]
        metrics:
          receivers: [otlp,prometheus]
          processors: [batch]
          exporters: [prometheusremotewrite]

Nas extensions, você irá utilizar “plugins” numa linguagem mais informal para interagir com seu collector.

O que as extensions fazem na prática?

• Observam o próprio Collector: health check, status, diagnóstico

• Controlam acesso: autenticação, autorização, segurança de endpoints

basicauth:
    client_auth:
      username: user
      password: pass

• Ajudam no debug: profiling, métricas internas,ZPages

• Integram com o ambiente: kubernetes, cloud, certificados, configuração dinâmica

extensions:
  # Exponde endpoint /health, indica se o Collector está vivo
  health_check:
    endpoint: 0.0.0.0:13133
  # Debug de performance, diagnóstico de vazamento de memória
  pprof:
    endpoint: 0.0.0.0:1777
  # Entender gargalos no Collector, troubleshooting em tempo real
  zpages:
    endpoint: 0.0.0.0:55679

1.3 Tail Sampling Processor

O tema mais polêmico e que faz total diferença financeira e qualitativa dos seus dados de telemetria. O Tail Sampling Processor decide se um trace inteiro será mantido ou descartado somente depois que ele termina.

Ele observa o trace inteiro e toma decisões como: “Esse trace teve erro?”, “Esse trace foi lento?”, “Esse trace passou por uma rota crítica?”, “Esse trace veio de um serviço importante?”

Se sim, ele mantém.Se não, ele pode descartar.

1.4 Funções

Você pode conferir elas aqui: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md

Parâmetros que são ponto de atenção no arquivo de configuração:

# Tempo máximo que o Collector espera para decidir.
decision_wait: 30s
# Quantidade máxima de traces mantidos em memória para decisão.
num_traces: 50000

Como ele funciona por policies(Políticas utilizadas para tomar uma decisão de amostragem), vão aqui alguns exemplos:

1.4.1 Policies: As que mais gosto

1. drop: Excluir (não amostrar) com base em várias políticas, cria uma política DROP

# Quando houver valores com health no url.path deverão ser excluídas
{
            name: drop-policy-example-1,
            type: drop,
            drop: {
              drop_sub_policy:
              [
                {
                    name: test-drop-policy-1,
                    type: string_attribute,
                    string_attribute: {key: url.path, values: [\/health], enabled_regex_matching: true}
                }
              ]
            }
         }

1. status_code: baseado no status code (OK, ERROR or UNSET)

# Mostra todos com erro
{
                  name: statuscode-policy-01,
                  type: status_code,
                  status_code: { status_codes: [ERROR] }

1. latency: Seleciona os traces lentos com latência predefinida pelo threshold_ms.

# Guardar apenas quando os traces tiverem dentro desse intervalo de latência
{
            name: latency-policy,
            type: latency,
            latency: {threshold_ms: 8000, upper_threshold_ms: 10000}
          }

1. probabilistic: Entrega uma amostragem dos dados

# Mostra 5% dos traces saudáveis
- name: probabilistic
  type: probabilistic
  probabilistic:
    sampling_percentage: 5

1. filter by rout

# Filtragem pela rota de checkout e pagamentos, finalização de um pedido quando falamos de ecommerce.

  name: critical_routes
  type: string_attribute
  string_attribute:
    key: http.route
    values: ["/checkout", "/payment"]

Logo, o sampling mantém traces realmente úteis e reduz o tráfego irrelevante que sobe no backend.

1.5 Segurança e dados sensíveis (PII não é opcional)

Se você não trata segurança na origem, você está criando um data lake de risco.

1.5.1 PII (Personally Identifiable Information)

O PII são informações que identificam uma pessoa, logo todos os dados sensíveis que aparecem na telemetria precisam ser tratados a fim de LGPD para garantir a segurança das informações. Podem aparecer nas métricas, logs e traces.

Alguns exemplos:e-mail, CPF / documento, IP do usuário final, user_id, session_id, tokens de autenticação, dados de saúde, dados financeiros.

1.5.2 Hash

A função hash transforma um valor sensível em um identificador irreversível.

Exemplo de como fazer:

processors:
  attributes/hash_pii:
    actions:
      - key: email
        action: hash

Como ficaria:

email = lara@empresa.com
↓
email = a94a8fe5ccb19ba61c4c0873d391e987

1.5.3 Regex

Usa de expressões regulares para identificar e tratar padrões sensíveis.

Exemplo de como fazer:

processors:
  filter/logs_pii:
    logs:
      log_record:
        - 'IsMatch(body, ".*password.*")'
        - 'IsMatch(body, ".*token.*")'

.*password.*
.*token.*
.*authorization.*

1.5.4 Delete

Remove completamente o dado sensível.

- key: db.statement
  action: delete

Removendo headers sensíveis:

processors:
  attributes/delete_headers:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: http.request.header.cookie
        action: delete

1.6 Certificados

Aproveitando o gancho de segurança, é possível usar certificados TLS nos receivers e exporters para assegurar seus dados. E também Keycloak + OpenID / OAuth2 para casos de ambientes multi-tenant (segregação de quem pode ver os dados de telemetria baseados em grupos de autenticação com usuário, senha e 2FA). Trarei isso em um outro artigo com passo a passo, mas tem bastante conteúdo sobre.

1.7 OpenTelemetry Collector Builder (OCB) e Load Balancing Exporter

1.7.1 OpenTelemetry Collector Builder (OCB)

O OCB permite criar uma versão customizada do Collector, contendo apenas os componentes que você precisa, ou seja, você pode criar o seu próprio binário. Ele é excelente para padronização e essa dica eu vi com o Juraci!

Normalmente, o Collector oficial vem com: dezenas de receivers, dezenas de processors,dezenas de exporters. E isso acaba gerando um binário maior, superfície de ataque maior, mais dependências e consequentemente mais overhead.

Com ele você tem algo padronizado, enxuto com superfície de ataque menor! Se você não usa um componente, ele não deveria estar no seu binário. E, caso tenha ficado dúvida sobre qual usar, o Core, Builder ou Contrib…tem esquema de comparação:

Contrib é para experimentar, Core é para aprender, OCB é para operar.

1.7.2 Load Balancing Exporter

O load balancing exporter distribui traces entre múltiplos destinos, garantindo que todos os spans de um mesmo trace cheguem ao mesmo backend.

Link do projeto: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/loadbalancingexporter

Se torna crítico para traces distribuídos,tail sampling, backends como Tempo / Jaeger porque traces não são dados independentes. São conjuntos de spans que precisam se encontrar no mesmo lugar.

As opções para routing_key são: service, traceID, metric(nome da métrica), resource, streamID

Ele calcula hash do trace_id, escolhe um backend consistente e garante afinidade do trace.

Load balancing em observabilidade não é sobre distribuir carga, é sobre preservar contexto ao decidir para qual backend um trace completo deve ir.

1.8 Cardinalidade: o erro mais comum de quem está começando

Como já tivemos muita informação até aqui, criei os 10 mandamentos da cardinalidade para ajudar a memorização!

1. Não criarás labels infinitos

Se o valor pode crescer sem limite, ele não é um label. user_id, order_id, session_id não pertencem a métricas.

2.Não confundirás detalhe com valor

Mais informação não é mais observabilidade. Detalhe demais = ruído.Ruído demais = cegueira.

3. Honrarás o resource, pois ele é estável

Identidade vem de resource, não de atributo dinâmico. Se muda a cada requisição, não é identidade.

4. Santificarás as rotas

URL dinâmica não é rota, é armadilha. /order/983742 é um ataque silencioso à sua stack. Normalize ou pague a conta.

5.Eliminarás o que não investigas

Se você nunca usa esse campo para investigar um incidente, ele não deveria existir. Observabilidade não é arqueologia.

6.Protegerás PII como se fosse produção (porque é)

Telemetria também é dado sensível. Se vazar, o problema é seu, não da ferramenta.

7.Hashearás antes de indexar

Correlação sem exposição é maturidade. Se precisa identificar, hasheie.Se não precisa, delete.

8.Não sacrificarás o backend

Métricas ruins derrubam sistemas bons. Prometheus, Mimir, Tempo e Loki não quebram sozinhos.Eles quebram porque alguém colocou order_id como label.

9.Tratarás cardinalidade antes de escalar

Escalar uma stack sem controlar cardinalidade só aumenta o prejuízo. HA não resolve erro conceitual.

10. Lembrarás: observabilidade é decisão

Cada atributo é uma escolha. E toda escolha tem custo, impacto e responsabilidade.

1.9 Dica de ouro

Falando em cortar custos e dados que não servem, já pensou em cortar esses logs de health e validações da sua telemetria? Corte parte do volume de logs que chegam no seu colector para ter uma visão mais limpa e menos ingest.

Esse artigo aqui é ouro: https://opentelemetry.io/blog/2026/log-deduplication-processor/

Era pra ser os primeiros passos, mas imagino que já dá pra fazer uma boa caminhada! hahaha

Porque todo mundo está falando de opentelemetry agora? É importante que você entenda que um não irá substituir o outro, mas a medida que as infraestruturas avançam, tecnologias nascem e morrem para facilitar as coletas e enriquecê-las. Zabbix nasceu para monitorar infraestrutura. OpenTelemetry nasceu para entender sistemas distribuídos.

Quando falamos de Zabbix, temos uma estrutura de server, proxy, agent e banco de dados com coletas baseadas em polling criando itens (informações), triggers (regras de alerta) que fazem parte de templates prontos ou customizáveis (modelos prontos de organização dos dados coletados). Baseado em um modelo mental de perguntar constantemente se algo está bem ou mal. Logo, de forma bruta ele acaba sendo fundamental para estado, capacidade e infraestrutura.

Quando o usuário do Zabbix começa a sentir dor?

Dificuldade para:

• Tracing distribuído

• Entender jornada de uma requisição

• Relacionar erro com impacto no usuário

• Muitas métricas ≠ entendimento real do problema

• Correlação manual (dashboards + experiência do operador)

*O alerta dispara, mas o porquê não está claro. Isso vai necessitar de uma maturidade do operador de compreender o sistema como um todo e observar possíveis pontos monitorados.*

É nessas dores que o opentelemetry entra, ele é um framework de código aberto que coleta as métricas, logs e traces de forma agnóstica a ferramentas. Como diz Marilya Gutierrez, o Cabo tipo C da telemetria. Com ele é possível correlacionar essas informações. Achei mais interessante fazer tabelas comparativas sobre o foco de cada um, como se complementam e um breve glossário nos próximos capítulos, espero que ajude.

Diferencial do formato de coleta entre Zabbix e OTel

Métricas, Logs e Traces

Foco dos domínios em cada uma

Quem responde o quê?

Glossário do Zabbix e Opentelemetry

Quando usar Zabbix ou Opentelemetry? Podem ser juntas?

Nesse caso, eles podem ser complementares. Uma não anula a outra e no mundo de observabilidade dificilmente conseguirá trabalhar apenas com uma ferramenta, porque as necessidades vão surgindo ao longo do tempo e os custos também hehehe, mas isso é papo pra outro artigo.

E aí, curtiu? Se tiver algo a complementar, fala comigo que add e te menciono!

Sua criação estratégica também precisa de um storytelling de dados, que apesar de não ser um mandamento direto e todos conseguirem criar um, nem todos conseguem interpretar da mesma forma. Quando isso se soma a uma questão de acessibilidade visual, as coisas pioram muito. É importante que você saiba contar uma história com cores, pois na correria do dia a constatação de que o ser humano é visual prevalesce. Não entendeu?

A neurociência é um estudo científico multidisciplinar do sistema nervoso (cérebro, medula espinhal e nervos periféricos), abrangendo sua estrutura, função, desenvolvimento e patologias e constata que o cérebro humano é predominantemente visual, tem uma taxa média de retenção de até 65% em 3 dias. Nosso cérebro não pensa em textos, pensa em imagens e padrões pois elas criam atalhos cognitivos, eduzem esforço mental e aceleram a recuperação da informação.

O FinOps da coisa é que quando trabalhamos isso em um dia cheio de telas e informações o tempo inteiro conseguimos ter uma economia de esforço cerebral. E se quiser ativar seu modo HA (Alta disponibilidade) combine imagem e palavra, assim criamos dois caminhos de memória: verbal e visual. Se um falhar, o outro recupera a informação!

Storytelling de dados: Componentes

Para contar uma história aqui também não é diferente, preciso ter:

• Personagem: campos de dados analisados
• Enredo: o insight que surge da narrativa
• Narrativa: estilo usado para comunicar o insight

Deve-se ter um controle para transmitir o ponto de vista de forma conclusiva.

Dicas mais comuns:

• Reduza a saturação das cores para não tirar o foco do público diante da informação ou gerar confusão.
• Cores muito brilhantes podem competir e causar distração, use pelo menos 75~90%
• Redução de brilho acaba reduzindo também a carga cognitiva que seu público precisa lidar. Você pode destacar uma informação e manter as outras em escala de cinza, por exemplo.
• Tenha cuidado com associação de cores

Exemplos de visualizações:

• Mudanças ao longo do tempo;
• Determinando frequência;
• Determinando relacionamentos;

imagem do espectro de cores e emoções

Combinações

A combinação de vermelho e verde tão famosa e usada por nós é um exemplo a ser levado a diante, cores distintas para trazer sensações de alívio ou preocupação.

Cinza normalmente dá sensação de uniformidade e calma podendo ser usada como complementar para outras informações e focar ainda mais no que não é cinza.

Consistência de cores

Para repetir a ideia com mais de um gráfico ajudando o público a distinguir,se ocorrer mudança significará alteração de ideia.

A importância de escolher a de escolher a cor certa, se deve a estudos comprovarem que mais de 50% dsa pessoas que optam sair de um site nunca mais retornam devido as escolhas de cores de design.

Conheça seu público

Cores podem significar cores diferentes em culturas distintas, considere associações de cores por setor, cores da marca. Se ela for laranja e verde..faça o jogo de cores.

Existem 3 razões para as cores da sua marca não funcionarem também na visualização.

• contraste
• quantidade de cores dispersas
• adequações dos dados

Paleta de cores

- Faça harmonia análoga: Cores vizinhas se complementam e ninguém sobressai (Trace a linha no circulo cromático)

• Use complementares com conotação positiva/negativa (evite a cor da marca como negativo)
• Use quase complementares para destacar, por exemplo, duas séries onde uma é o foco principal. Chamam também de regra 33%
• Evite fundos coloridos demais;
• Conheça seus dispositivos para dar contexto de utilização
• Utilize gradientes (!!!!) para quando tiver dificuldade para comparar e contrastar dados. Evite para dados categóricos pois pode causar confusão.

Acessibilidade e Daltonismo

Daltonismo é a deficiência de visão cromática de uma forma mais bruta.

Aproximadamente 1 em cada 12 homens e 1 em cada 200 mulheres apresentam alguma forma de deficiência de visão cromática. A maioria das pessoas ainda percebem as cores, mas são transmitidas com codificação diferente.

Como identificar a real?

Apps que podem te auxiliar

1. Ferramenta Coblis Color Blindness Simulator
2. Color Oracle

ATENÇÃO

Combinações a evitar

• vermelho, verde e marrom: podem ser indistinguíveis (tons de marrom e amarelo escuro também)
• Rosa, turquesa e cinza: todos parecem cinza para quem tem daltonismo com vermelho
• Roxo e azul: pode parecer só azul.

Melhores práticas

• Azul e Laranja são um ótimo ponto de partida.
• Preto e branco é uma combinação que não tem erro. Faça um versão em preto e branco para ver se a visualização e distinção faz sentido como prova dos 9.
• Luminosidade da cor ajuda.
• Combine elementos como linhas, formas, simbolos.

Armadilhas comuns do uso de cores no storytelling

• Adcionar informações irrelevantes ou em excesso (Regra dos 3 a 5 categorias de cores)

• Usar cores não monotônicas para valores de dados A diferença de cores deve refletir a diferença de valores nos dados

• Criar codficações de dados que não levam em consideração pessoas com deficiência cromática.

• Não criar associação com cores Crie um padrão ou legenda para seu seu público leia o seu trabalho

• Não usar cores contrastantes para contrastar informações cores e número tem semelhança.

• Não destacar informações importantes Seu trabalho não é ser imparcial

• Usar muitas cores: O cérebro sofre para processar tanta informação. Pesquisas apontam que 7 é o número máximo de itens que o cérebro pode armazenar por vez. Razão pelo qual a maioria dos números de telefone tem 7 digitos hahaha nada é por acaso.

• Não usar mapa de calor

Sim, como boa pesquisadora de neurociências eu vou ter boas referências. hahaha

Teoria do Duplo Código (base do visual + verbal)

• PAIVIO, Allan. Imagery and verbal processes. New York: Holt, Rinehart and Winston, 1971.

• PAIVIO, Allan. Mental representations: a dual coding approach. New York: Oxford University Press, 1986.

Superioridade da Imagem (Picture Superiority Effect)

• STANDING, Lionel. Learning 10,000 pictures. Quarterly Journal of Experimental Psychology, London, v. 25, n. 2, p. 207–222, 1973. DOI: 10.1080/14640747308400340.

Aprendizagem multimídia e retenção visual

• MAYER, Richard E. Multimedia learning. 2. ed. New York: Cambridge University Press, 2009.

• MAYER, Richard E. Applying the science of learning to medical education. Medical Education, v. 44, n. 6, p. 543–549, 2010.

Neurociência, memória e processamento visual

• MEDINA, John. Brain rules: 12 principles for surviving and thriving at work, home, and school. Seattle: Pear Press, 2008.

• KOSSLYN, Stephen M.; GANIS, Giorgio; THOMPSON, William L. Neural foundations of imagery. Nature Reviews Neuroscience, London, v. 2, n. 9, p. 635–642, 2001.

Processamento visual e eficiência cognitiva

• WARE, Colin. Information visualization: perception for design. 3. ed. Waltham: Morgan Kaufmann, 2013. LIDWELL, William; HOLDEN, Kritina; BUTLER, Jill. Universal principles of design. Beverly: Rockport Publishers, 2010.

A cor dos dados

• STRACHNYI, Kate. Color-wise: a data storyteller’s guide to the intentional use of color. Hoboken: Wiley, 2020.

É comum ainda encontrar cenários em que equipes focam exclusivamente em análises técnicas, enquanto a jornada até perguntas estratégicas ainda é longa. Questões como impacto no negócio, experiência do usuário e correlação com receita muitas vezes ficam em segundo plano.

Passos iniciais

Passo 01

Passo 02

Exemplo prático — aplicando os 5 porquês

1. Por que o sistema de autenticação está lento e falhando?

2. Por que o servidor está sobrecarregado?

3. Por que houve esse aumento inesperado nas requisições?

4. Por que a equipe de infraestrutura não ajustou a capacidade do servidor?

5. Por que não houve essa comunicação clara?

Da análise à prática

Impacto do problema

Regras de negócio

Sugestão de alertas

Alerta 01: Latência média do serviço de autenticação acima de 200 ms por mais de 5 minutos.

Alerta 02: Taxa de erros no serviço de autenticação acima de 1% em 5 minutos consecutivos.

Alerta 03: Aumento súbito no volume de requisições (+30% em 10 minutos) sem ajuste na capacidade.

Sugestão de painel

• Gráfico de latência média do serviço de autenticação ao longo do tempo
• Monitoramento da taxa de erros em percentual
• Volume de requisições por minuto
• Indicadores de capacidade do servidor (CPU, memória, conexões ativas)
• Eventos recentes, como lançamentos de funcionalidades e mudanças na infraestrutura

Tudo é processo: foco no impacto e na regra de negócio

Por isso, o caminho sempre é:

Métrica técnica → Regra de negócio → Impacto, dashboard e alerta!

Caso 01: Recursos ( FinOps ama! )

Caso 02: Datas comemorativas

Você sabia que existem documentos explicando a funcionalidade de cada parte de um dashboard para que todos aprendam o processo?

Aqui está uma visão de equipe operacional e gerencial.

USE x RED x 4 Sinais DE OURO: Você sabe qual usar para responder sua pergunta?

O USE é composto por Utilização, Saturação e Erros. Esses indicadores aparecem no escopo da solicitação e têm seu foco em recursos (hardware e infraestrutura), sendo utilizados para identificar gargalos.

Exemplo: Uso de CPU, Fila de processos, Erro de leitura no disco.

Já o RED composto por Taxa, Erros e Duração também aparece no escopo, mas são voltados para serviços e APIs para garantir a qualidade do serviço.

Exemplo: Requisições HTTP, Requisições retorando HTTP 5xx, latência média p99 de 1,2 segundos.

Os 4 sinais de ouro são vistos na saída da solicitação.

Indicadores fundamentais

• Latência: Tempo de resposta para atender a uma requisição.
• Erros: Taxa de falhas ou respostas inválidas nas requisições.
• Tráfego: Volume de requisições recebidas ou dados processados.
• Saturação: Nível de utilização dos recursos, afetando o impacto próximo do sistema está de sua capacidade máxima.

Ao partir de análises técnicas e de direção estruturadas, como os 5 motivos, conseguimos não apenas detectar falhas, mas entender seu impacto real e construir regras de negócios eficazes para alertas e visualizações.

Compreender frameworks como USE, RED e os Quatro Sinais de Ouro permite que equipes técnicas e de produto falem a mesma língua: a do impacto no cliente e no faturamento. Isso transforma painéis em ferramentas de decisão, não apenas em painéis de monitoramento.

O caminho que propus — da identificação dos problemas, passando pela demonstração com o negócio, até a criação de alertas e dashboards direcionados — é uma prática base para sair da observabilidade puramente técnica e caminhar rumo à observabilidade orientada ao valor.

Agora que você viu exemplos, frameworks e boas práticas, fica o convite: revise seus indicadores atuais.

Eles estão ajudando você a responder às perguntas certas?

A boa notícia: a AWS já fornece uma camada pronta, chamada ADOT Lambda Layer , que simplifica a instrumentação.

**A justificativa para atingir o objetivo dessa integração é justamente enviar dados para a stack OSS e economizar com cloudwatch. Segredo nosso.**

Pré-requisitos

Os pré-requisitos para fazer essa integração utilizados foram:

• Função Lambda rodando em Java 21

• Acesso ao Console da AWS.

• Grafana configurado com Loki (logs), Tempo (traces) e Mimir (métricas).

Passo a passo de configuração

1. Instrumentar sua Função com ADOT Lambda Layer
2. No Console da AWS, abra sua função Lambda.
3. Vá em Camadas → Adicionar uma camada → Especificar ARN .
4. Insira o ARN do ADOT Layer correspondente à sua região (veja documentação oficial).
5. Configure a variável de ambiente:

AWS_LAMBDA_EXEC_WRAPPER=/opt/manipulador-otel

Isso instrui o runtime a usar o wrapper do OpenTelemetry.

Configurar o Coletor OpenTelemetry (Exemplo com Loki para Logs)

A camada ADOT traz embutido um collector. Por padrão, ele exporta para o AWS X-Ray, mas podemos personalizar para Loki/Tempo/Mimir.

Crie um arquivo chamado collector.yaml na raiz do projeto:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  loki:
    endpoint: "http://<LOKI_ENDPOINT>:3100/loki/api/v1/push"
    # headers:
    #   Authorization: "<TOKEN> básico"
    # labels:
    #   service.name: "lambda-java-app"

service:
  pipelines:
    logs:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ loki ]

Empacotar e apontar o collector

• Inclua o collector.yaml no pacote da função (ZIP/JAR).

• Configure mais uma variável de ambiente:

OPENTELEMETRY_COLLECTOR_CONFIG_FILE =/var/task/collector.yaml

Ative exportação de logs

Adicione:

OTEL_LOGS_EXPORTER =otlp

Validar no Grafana

• Chame sua função Lambda.

• Os logs devem aparecer no Grafana Loki.

• Configure exportadores equivalentes no collector.yaml para enviar também traces ao Tempo e métricas ao Mimir.

Pontos de atenção

Autenticação: se seu Loki exigir credenciais, configure no bloco headers.

Labels: aproveite para enriquecer logs com service.name, job, etc.

Deu certo? Me conta!

Não basta saber coletar dados , é preciso transformar séries temporais em informações úteis. Para isso, o PromQL oferece funções que permitem calcular taxas de crescimento, detectar picos, fazer agregações, prever tendências e até calcular percentis de latência a partir de histogramas.

Neste artigo, apresento um guia prático (cheat sheet) das funções PromQL mais usadas no dia a dia de SREs, DevOps e engenheiros de observabilidade.

Cada função vem acompanhada de:

• O que faz.
• Um exemplo de query.
• Quando usar no contexto de monitoramento.

Se você já se perguntou se deveria usar rate ou irate, ou como calcular o p95 de latência, este guia é para você.

1. Funções de Taxa e Crescimento

Essas são as mais usadas para métricas de contadores (counters), que só aumentam.

rate(vetor[intervalo])

Calcula a taxa média por segundo no período.

Exemplo: quantas requisições por segundo em média nos últimos 5 minutos.

rate(http_requests_total[5m])

irate(vetor[intervalo])

Taxa instantânea (derivada do último par de pontos). Detecta pico instantâneo, bom para detectar spikes.

irate(http_requests_total[1m])

increase(vetor[intervalo])

Quanto o contador aumentou no período.

increase(http_requests_total[1h])

total de requisições na última hora.

2. Funções de Agregação

Usadas para somar, contar, agrupar séries.

sum

Soma valores.

sum(rate(cpu_usage_seconds_total[5m])) by (instance)

avg

Média.

avg(rate(node_network_receive_bytes_total[1m])) by (device)

max / min

Valor máximo/mínimo.

max(memory_usage_bytes) by (pod)

count

Número de séries retornadas.

count(up{job="node"})

3. Funções de Manipulação de Séries

Mexem nas séries de tempo em si.

rate + sum + by()

Para agrupar séries por rótulos.

sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace)

topk(N, métrica)

Retorna o top N.

topk(5, rate(http_requests_total[5m]))

os 5 endpoints mais acessados.

bottomk(N, métrica)

O inverso: os menores valores.

4. Funções de Previsão e Mudança

predict_linear(vetor[intervalo], tempo)

Projeta valores futuros.

predict_linear(node_filesystem_free_bytes[1h], 4 * 3600)

prevê espaço livre em 4h, ótimo para alertas de disco.

changes(vetor[intervalo])

Quantas vezes o valor mudou.

changes(up[1h])

quantas vezes o serviço caiu/subiu na última hora.

resets(vetor[intervalo])

Quantas vezes um contador foi resetado.

5. Funções Matemáticas

abs: valor absoluto.

ceil / floor: arredondar.

clamp_min / clamp_max: limitar valores.

round(vetor, precisão)

round(cpu_temp_celsius, 0.5)

6. Funções de Histogramas

histogram_quantile(φ, sum(rate(…)))

Usada para métricas de latência.

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

calcula o p95 do tempo de resposta HTTP.

Boas práticas no uso de funções PromQL

Escolha bem a janela de tempo ([5m], [1h]):

• Janela muito curta = dados ruidosos (spikes falsos)

• Janela muito longa = suaviza demais e esconde problemas.

Regra prática: use [$__rate_interval] no Grafana para adaptar dinamicamente.

Counters ≠ Gauges:

• Use rate, irate, increase apenas para counters (métricas que só crescem, como requisições, bytes transmitidos).

• Para gauges (CPU, memória), use avg_over_time, max_over_time, etc.

Use by() conscientemente:

sum(rate(http_requests_total[5m])) = soma tudo junto.

sum(rate(http_requests_total[5m])) by (job) = mostra por job.

Prefira rate a irate em alertas:

irate é útil para visualizar spikes, mas em alertas pode gerar falsos positivos.

Para latência, sempre histogram_quantile:

Percentis de tempo de resposta só fazem sentido em histogramas. Média de latência isolada pode enganar.

Combine funções: PromQL brilha quando você compõe funções. Exemplo:

topk(5, rate(http_requests_total[5m])) by route)

mostra os 5 endpoints mais acessados no período.

Dúvidas comuns

Quando usar rate vs increase?

rate → “velocidade” (quantos por segundo).

increase → “quanto acumulou” (total em X tempo).

Por que meu gráfico fica serrilhado com irate? Porque ele usa só os dois últimos pontos. Útil para spikes, mas não para visão estável.

Posso usar rate em métricas de memória ou CPU? Não. Essas métricas são gauges (valores atuais). Use avg_over_time, max_over_time, etc.

O que significa offset? É um deslocamento no tempo. rate(http_requests_total[5m]) offset 1d compara hoje com ontem.

Por que meu sum não bate com o total? Provavelmente faltou usar by() corretamente ou algum label está duplicando séries.

E no Grafana, isso vai muito além de clicar em “Last 1h” ou “Last 24h”.

Existe todo um arsenal de formas de manipular o tempo…algumas conhecidas, outras escondidas nas configurações de painel ou dentro das queries.

Esse artigo é quase um modo discovery do que dá para fazer com tempo no Grafana.

1°) Time Range Global

O clássico: no topo do dashboard você escolhe quanto tempo quer ver.

Valores prontos: Last 5m, Last 7d, Last 30d.

Absoluto: marcar data/hora específica.

Atalho: “Zoom out” e “Zoom in” no gráfico. Isso controla o contexto geral do dashboard inteiro.

2°) Relative Time (por painel)

Às vezes, você não quer que todos os gráficos sigam o mesmo range. O dashboard pode estar em 7 dias, mas um painel mostra só as últimas 2h.

Exemplo:Um dashboard de disponibilidade mostra 7 dias, mas você cria um painel só para “última hora de CPU” .

3°) Time Shift

Aqui o Grafana brinca de viagem no tempo. Serve para comparar períodos diferentes.

Exemplo: 1d → compara essa semana com o dia anterior.

Caso prático: Tráfego da aplicação de hoje vs. tráfego de ontem, lado a lado no mesmo gráfico.

4°) Intervalos por Query (Overrides de Tempo)

Max data points e Interval override permitem controlar granularidade das series via query.

Relative time por query → $__interval, $__rate_interval

$__timeFilter() → limita dados ao range escolhido.

$__interval → ajusta a granularidade (5s, 1m, 1h).

$__rate_interval → usado em métricas de Prometheus para cálculos de taxa.

Exemplo com Prometheus:

increase(http_requests_total[$__rate_interval])

Assim a query se adapta sozinha, sem você ter que adivinhar se vai ser 1m, 5m ou 1h.5°)

Como venho atuando com mais frequência com a stack OSS, estão aqui alguns que mais utilizo.

Prometheus / Loki / Tempo

time(): retorna o timestamp atual.

offset: desloca séries no tempo (metric offset 5m).

$__timeFilter(column): macro SQL-like (em datasources SQL).

$__timeFrom() / $__timeTo(): limites inferior/superior do range.

$__interval e $__rate_interval: granularidade dinâmica.

6°) QL Datasources (Postgres, MySQL, etc.)

Ao plugar bancos de dados como datasource, você também pode acrescentar variáveis que funcionem em sua query. Teste com período no banco e depois substitua no frontend do Grafana.

WHERE $__timeFilter(datetime_column)

GROUP BY $__interval(datetime_column)

date_trunc('hour', $__timeGroup(datetime_column,'1h'))

Esses macros viram filtros de tempo reais na query, otimizando o que vem do banco.

Insights e boas práticas…

Auto-refresh: 5s, 30s, 1m… perfeito para dashboards de NOC.

Variáveis de tempo: usar now-1h como variável de query.

Templating de intervalos: deixar o usuário escolher granularidade (ex.: 5m, 15m, 1h).

- Não use ranges gigantes com granularidade de segundos: você vai matar o banco e não ganhar insight. - Relative time é para detalhe, time shift é para comparação. - Sempre adicione contexto com annotations — olhar métricas sem saber que rolou um deploy é perda de tempo.

1. Grafana em alta disponibilidade (HA)

Para garantir resiliência e continuidade de serviço, a implantação foi realizada com:

• Instâncias Grafana em load balancer (modo stateless);
• Banco de dados MySQL externo compartilhado para estado e sessão;
• Diretório de plugins compartilhados via NFS;
• Monitoramento do próprio Grafana via dashboards internos.

Desenho de implantação:

[Usuário] → Load Balancer → [Instância Grafana A/B] → MySQL + NFS Plugins

2. Autenticação LDAP para estabelecimentos

O Grafana foi configurado para autenticação contra Active Directory (LDAP), com regras que direcionam o usuário automaticamente para a organização correta baseada no grupo do AD:

[[servidores]]

host = “ad.corp.local”

bind_dn = “CN=ldap_reader,OU=Serviços,DC=local”

bind_password = “senha”

…

[[servers.group_mappings]]

group_dn = “CN=estabelecimento1,OU=Estabelecimentos,DC=dnslocal”

org_id = 1

org_role = “Visualizador”

Cada estabelecimento possui seu grupo de usuários e organização dedicada.

3. Automação para criação de estabelecimentos, fontes de dados e plugins utilizando scripts python e comandos SQL diretamente no banco do Grafana, foi realizado:

Criação de organizações em lote (INSERT INTO estabelecimento);

Associação de datasources por estabelecimento (Zabbix + TestData) com UID fixo padronizado:

• uid_zabbix_estabelecimentoXXX

• Ativação do plugin Zabbix App via plugin_setting com enabled=1.

4. Provisionamento de dashboards via API com UID e grupo padronizados para manter consistência visual e funcional:

Os dashboards foram exportados e tratados com substituições em lote de:

• Grupo variável com regex padronizado /123.*/;

• Fontes de dados definidas por UID fixo, conforme organização;

• Scripts Python autenticam por login/senha, alternam organização e realizam POST no endpoint /api/dashboards/db para cada JSON.

Com esse modelo:

• A escalabilidade é garantida pela separação de organizações;

• O gerenciamento de acesso é automático e seguro via LDAP;

• Dashboards padronizados facilitam suporte e onboarding;

• A alta disponibilidade assegura robustez para ambiente crítico.

Esse tipo de estrutura é ideal para grandes redes, varejo ou ambientes distribuídos. Se quiser um exemplo funcional ou clonar esse modelo, entre em contato.

O Porteiro, o Zelador e o Depósito: Entendendo o Fluxo dos Logs

Imagina só a vida de um log dentro do seu sistema. Ele não aparece do nada e se materializa num dashboard bonito, certo?

Existe um fluxo, um caminho que ele percorre, e o Loki tem componentes que simulam perfeitamente essa jornada.

Primeiro, temos o nosso…Porteiro! — o Distributor.

Pensa bem: quando uma encomenda (um log, nesse caso) chega no condomínio, o porteiro não guarda nada, ele só olha o endereço e direciona para o bloco e apartamento certos. No Loki, o Distributor faz exatamente isso: ele recebe os logs e os distribui para os “inquilinos” corretos, que chamamos de Ingesters. Ele é o primeiro ponto de contato, garantindo que cada log vá para o seu devido lugar.

Em seguida, entra em cena o: Zelador, nosso querido Ingester.

O Seu Pedro Zelador, que guarda as caixas na salinha do condomínio por um tempinho? Se a Dona Maria não está em casa, ele segura a entrega até alguém buscar ou até levar para o depósito maior. O Ingester no Loki age de forma similar, segurando temporariamente os logs na memória antes de enviá-los para o armazenamento definitivo. Ele é crucial para garantir que nenhum log se perca no caminho antes de chegar ao seu destino final.

E qual é esse destino final? O Depósito.

Nosso **Object Storage.** É como aquele depósito no subsolo do condomínio, onde só o zelador e a administração têm acesso, e onde ficam guardados os registros antigos, tipo caixas, papéis e documentos. No mundo do Loki, o Object Storage é o responsável pelo armazenamento durável dos logs, guardando os dados antigos de forma segura e acessível. Pense nele como a sua biblioteca histórica de eventos do sistema.

Os Fofoqueiros e a Administração: Acessando e Gerenciando Informações

Agora que os logs estão guardados, como fazemos para encontrá-los e tirar proveito deles? É aí que entram os próximos personagens da nossa história.

Conhece aquele…

**Vizinho Fofoqueiro?** Aquele que sempre quer saber “quem recebeu aquela pizza ontem às 23h?” ou “quem deixou a luz do hall acesa?”. Ele faz as perguntas e quer respostas rápidas.

Esse é o nosso **Querier.** No Loki, o Querier é o responsável por executar as queries, ou seja, as suas perguntas, para buscar os logs que você precisa. Ele é o motor por trás da sua busca por informações.

Mas para as coisas não virarem uma bagunça de fofocas soltas, precisamos de uma boa organização. E quem faz isso?

**A Administradora, a Querier**:Frontend. Pensa na Lanay, que recebe todas as reclamações, dúvidas e pedidos, e organiza tudo: “isso vai para o síndico, isso o zelador responde, isso eu já sei e te respondo agora”. A Querier = Frontend gerencia as queries e trabalha para melhorar a performance do sistema. Ela garante que suas buscas sejam eficientes e que você obtenha as respostas rapidamente.

### O Livro da Portaria e o Síndico: A Otimização por Trás das Cenas

Para que tudo funcione de forma fluida, há componentes essenciais que trabalham nos bastidores.

Um dos mais importantes é o Livro da Portaria, o Index Gateway.

Sabe o livro de registros que anota tudo: “Dia 01: pizza para o ap. 302. Dia 02: caixa da Net para o 704.”? Ele não guarda os objetos em si, mas diz onde eles estão. No Loki, o Index é exatamente isso: ele aponta onde os dados estão, como um índice de um livro gigante, permitindo que o sistema saiba rapidamente onde encontrar a informação que você está procurando. Ele é a chave para a agilidade nas suas buscas.

E por último, mas não menos importante, temos o Síndico, o Compactor.

O Seu Walter, o síndico, de tempos em tempos manda jogar fora o que não precisa mais e junta o que vale a pena guardar numa pasta só. O Compactor do Loki faz um trabalho similar: ele junta logs antigos e os organiza para ocupar menos espaço. Ele é o cara da otimização, garantindo que o seu armazenamento de logs seja eficiente e que você não gaste mais do que o necessário com infraestrutura.

Boas Práticas para um Condomínio Loki Feliz! (hahaha)

Agora que entendemos a função de cada “personagem” do nosso condomínio Loki, vamos a algumas boas práticas para garantir que seu sistema de logs seja eficiente e útil:

1. Monitore seus “Porteiros” e “Zeladores”: Fique de olho na saúde dos seus Distributors e Ingesters. Eles são a linha de frente da ingestão de logs, e qualquer gargalo ali pode comprometer todo o seu sistema de observabilidade.

2. Otimize suas “Fofocas”: Ao usar o Querier, seja específico nas suas queries. Quanto mais detalhada for sua pergunta, mais rápido o sistema encontrará a resposta. Evite buscar por períodos muito longos sem filtros.

3. Cuide do seu “Depósito”: Monitore o espaço ocupado pelo seu Object Storage. Embora seja durável, o armazenamento tem custos. O 3Compactor ajuda, mas é sempre bom ter uma política de retenção de logs clara.

4. Mantenha seu “Livro da Portaria” em ordem: Um Index bem projetado é crucial para a performance das suas consultas. Pense bem nas labels que você usa para indexar seus logs, pois elas serão suas chaves de busca.

5. Use as “Regras do Condomínio” a seu favor: O Loki permite configurar regras de alerta e extração de métricas a partir dos logs. Utilize essas funcionalidades para transformar seus dados brutos em inteligência acionável.

Se restou alguma dúvida, sinta-se à vontade de me contactar!

E, se tua pergunta é…Quando e porquê devo usar essa turma(?), o próximo post é sobre isso! Até mais!

O que é SRE?

SRE (Site Reliability Engineering) é uma abordagem que aplica princípios de engenharia de software para resolver problemas operacionais de infraestrutura. Criado pelo Google, o SRE busca equilibrar a velocidade de entrega de novas funcionalidades com a estabilidade dos sistemas em produção.

Entendendo SLA, SLO e SLI

Esses três termos são comumente confundidos, mas possuem significados diferentes e complementares:

SLA (Service Level Agreement) é o contrato firmado com os clientes, geralmente externo, e define como garantias formais de disponibilidade ou desempenho. SLO (Objetivo de Nível de Serviço) é um objetivo interno mensurável, previsto para garantir que os serviços mantenham a confiabilidade desejada. SLI (Service Level Indicator) são as métricas reais que medem a qualidade do serviço (como latência, taxa de erros, disponibilidade).

O SRE utiliza esses conceitos para construir sistemas mais resilientes, com monitoramento adequado e tolerância a falhas.

Como criar SLAs e SLOs?

Diferença Chave: SLA (Acordo com o Cliente) : Exemplo: “Disponibilidade de 99,5% ao mês ou lucro financeiro.”

SLO (Objetivo Interno) : Exemplo: “Disponibilidade de 99,9% para evitar riscos ao SLA.”

5 Passos para Definir SLOs Eficientes

Observe o Comportamento Real do Sistema : Ex.: Se 95% das requisições têm latência < 200ms, esse é um bom candidato a SLO.

1. Alinhe com a Experiência do Usuário : Ex.: Um e-commerce define SLO de latência com base no abandono de carrinho .

2. Considere Custos e Complexidade : Manter 99,99% de disponibilidade pode ser 10x mais caro que 99,9%.

3. Garanta que o SLO Seja Mais Rigoroso que o SLA : Se o SLA for 97,5%, o SLO deve ser 99% para criar uma zona de segurança .

4. Revisar regularmente : os SLOs devem evoluir com as mudanças no produto e na infraestrutura.

Exemplo Prático de Cálculo :

Para um serviço com SLA de 99,9% em um mês (43.200 minutos):

• Tempo de Inatividade Aceitável : 43,2 minutos.
• SLO Interno : 99,95% (21,6 minutos de margem).

Caso Prático: Alerta à Solução

O processo de definição de SLIs e SLOs geralmente segue um fluxo estruturado. Tudo começa com a identificação de um problema, seguida por uma triagem e análise detalhada — muitas vezes utilizando ferramentas específicas e a técnica dos “5 porquês” para investigar a causa raiz. A partir desse diagnóstico, é possível entender os fatores e processos que desenvolvem para a falha e, com isso, propor testes e tratamentos preventivos, caso o problema volte a ocorrer. Em seguida, a solução é documentada, e são criados alertas e dashboards para monitoramento contínuo. Nesse estágio, os SLOs e SLAs se tornam fundamentais, pois orientam a priorização das investigações e ajudam a evitar decisões contratuais, especialmente em serviços considerados críticos.

Caso 01 para ilustrar a explicação:

1. O Problema

O horário de monitoramento notificou que um servidor de aplicação estava reiniciando intermitentemente.

2. A Triagem e Análise

O SRE analisou:

• Logs do sistema operacional : Picos de consumo de memória antes de cada reinício.
• Métricas de aplicação : Aumento contínuo no uso de RAM sem liberação (possível vazamento).
• Logs de aplicação : Conexões HTTP não fechadas corretamente.

3. O Diagnóstico

Identificou-se que:

*“Um vazamento de memória ocorria devido a conexões HTTP persistentes não finalizadas, fazendo o sistema operacional matar o processo (OOM Killer).”*

4. A Solução

• Ajuste no coletor de lixo da aplicação.
• Correção do código para fechar conexões HTTP.
• Implementação de alertas proativos para consumo anormal de memória.

**Lição:** Monitorar apenas “CPU alta” não basta. É preciso correlacionar logs, análises e rastreamentos para entender a causa raiz.

Caso 02 com sugestões de SLO

1. O Problema

Imagine que você está usando um aplicativo, mas ele está lento . Algumas páginas demoram para carregar. Isso irrita, né? Pois é, outros usuários também reclamaram disso.

2. Triagem e Análise

Um técnico chamado SRE (Site Reliability Engineering) , que é responsável por garantir que o sistema funcione bem, iniciou uma investigação. Eles fizeram isso em etapas:

Verifiquei alertas : Notaram que muitas requisições estavam demorando demais e até travando (timeout). Olharam os gráficos do sistema : Perceberam que o banco de dados (onde ficam guardados as informações) estava sendo muito usado e com lentidão.

Analisaram as consultas : Descobriram que os comandos usados ​​para buscar dados (as consultas SQL) estavam demorando muito. Viram outros possíveis problemas : Como outras partes do sistema que estavam sobrecarregadas ou falhando.

3. Diagnóstico e Solução

Depois de entender o problema, o tempo fez algumas coisas para resolver:

• Melhoraram o banco de dados : Colocaram índices para deixar as buscas mais rápidas.

• Evitaram buscas repetidas : Usaram uma técnica chamada caching que guarda os dados mais usados ​​para não ter que buscar no banco toda hora.

• Criaram alertas inteligentes : Para avisar se a lentidão acontecer de novo no futuro.

4. Como criar indicadores a partir disso?

SLIs: São as métricas que medem a qualidade do serviço. Na imagem, temos como SLI:

• Tempo de resposta de requisições HTTP

• Percentual de requisições atendidas em menos de 200ms

• Uso de CPU e memória do banco de dados

• Latência de consultas no banco de dados

• Taxa de erros (timeouts, falhas de cache, falhas de dependências externas, etc.)

SLOs:

São os alvos ou metas internacionais que queremos atingir com base nos SLIs. Os SLOs definidos na imagem incluem:

• 99% das requisições devem ser atendidas em menos de 200ms

• O tempo médio de resposta do banco de dados deve estar abaixo do limite X (implícito) — usado para verificar se o SLO está quebrado

• 95% das requisições devem ser respondidas em menos de 200 ms , caso o SLA permita menos desconforto

• Erros ou lentidão que ultrapassem a margem de erro do SLO precisam ser tratados imediatamente

SLA:

• Tempo de atividade mínimo de 99,95%

• Se o serviço ficar fora do ar mais de 3h36min no mês, há violação contratual e possível retorno financeiro

Hora da dica: Entendendo a Relação entre Métricas

Um ponto interessante discutido nos capítulos do livro é um esclarecimento entre detalhes . Nem sempre dois eventos correlacionados indicam causalidade, mas entender essas relações ajudam na construção de alertas mais identificados e na identificação de anomalias reais.

Por exemplo, um aumento na latência pode estar correlacionado a um pico de tráfego. Entretanto, uma experiência SRE sabe que não há significado significativo, e por isso investigue os dados com cuidado antes de tirar conclusões.

Como o SRE Usa Esses Conceitos na Prática

O engenheiro de confiabilidade utiliza SLIs para medir o comportamento dos serviços e comparar esses indicadores com os SLOs definidos. Quando um SLO estiver próximo de ser violado, o tempo poderá pausar novas implementações para evitar riscos de confiabilidade.

Além disso, o erro orçamentário é uma ferramenta poderosa do SRE. Ele define quanto de “erro” é aceitável dentro de um determinado período. Esse orçamento de erro permite inovar com segurança, sabendo quanto o sistema pode falhar sem comprometer o SLA.

Seu tempo já teve um problema ‘técnico’ que virou um problema financeiro?