Kubernetes em produção: por que observabilidade é a diferença entre prevenção e incidente

Rodar Kubernetes em produção sem observabilidade é como pilotar um avião sem instrumentos. Você pode até decolar, mas quando a turbulência chegar — e ela vai chegar — você não terá ideia do que está acontecendo.

A diferença entre empresas que sofrem incidentes de horas e empresas que resolvem problemas em minutos se resume a uma palavra: observabilidade.

Monitoramento vs. Observabilidade

Monitoramento responde "o sistema está no ar?". Observabilidade responde "por que a experiência do usuário degradou 15% nos últimos 30 minutos?".

A distinção é fundamental:

Em Kubernetes, onde pods nascem e morrem a cada minuto, onde deployments alteram o comportamento do sistema em tempo real, observabilidade não é luxo — é requisito de operação.

Os três pilares na prática

Pilar 1: Métricas com Prometheus

Prometheus é o padrão de facto para métricas em Kubernetes. A stack completa inclui:

```yaml

# values.yaml para kube-prometheus-stack (Helm)

prometheus:

prometheusSpec:

retention: 30d

storageSpec:

volumeClaimTemplate:

spec:

storageClassName: gp3

resources:

requests:

storage: 100Gi

resources:

requests:

cpu: 500m

memory: 2Gi

limits:

cpu: 2000m

memory: 8Gi

alertmanager:

config:

route:

group_by: ['alertname', 'namespace']

group_wait: 30s

group_interval: 5m

repeat_interval: 4h

receiver: 'slack-critical'

receivers:

slack_configs:

channel: '#alerts-critical'

title: '{{ .GroupLabels.alertname }}'

text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

```

Métricas essenciais para todo cluster:

```bash

# Instalar kube-prometheus-stack

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm install monitoring prometheus-community/kube-prometheus-stack \

--namespace monitoring \

--create-namespace \

-f values.yaml

```

Pilar 2: Logs com Loki

Logs são o contexto que métricas não fornecem. Quando uma métrica de erro dispara, os logs dizem exatamente o que aconteceu.

```yaml

# Loki stack deployment

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: loki

namespace: monitoring

spec:

replicas: 1

selector:

matchLabels:

app: loki

template:

metadata:

labels:

app: loki

spec:

containers:

image: grafana/loki:2.9.4

args:

ports:

volumeMounts:

mountPath: /etc/loki

mountPath: /loki

volumes:

configMap:

name: loki-config

volumeClaimTemplates:

name: storage

spec:

accessModes: ["ReadWriteOnce"]

storageClassName: gp3

resources:

requests:

storage: 50Gi

```

Práticas essenciais de logging em K8s:

Pilar 3: Traces com OpenTelemetry

Traces mostram a jornada completa de uma requisição através de todos os microsserviços. Quando o checkout demora 8 segundos, o trace mostra exatamente qual serviço adicionou latência.

```yaml

# OpenTelemetry Collector deployment

apiVersion: opentelemetry.io/v1alpha1

kind: OpenTelemetryCollector

metadata:

name: otel-collector

namespace: monitoring

spec:

mode: deployment

config: |

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch:

timeout: 5s

send_batch_size: 1024

memory_limiter:

check_interval: 1s

limit_mib: 512

exporters:

otlp/tempo:

endpoint: tempo.monitoring.svc:4317

tls:

insecure: true

service:

pipelines:

traces:

receivers: [otlp]

processors: [memory_limiter, batch]

exporters: [otlp/tempo]

```

Grafana: unificando os três pilares

Grafana é o ponto central de visualização. Com Prometheus, Loki e Tempo como data sources, você consegue correlacionar métricas, logs e traces em uma única interface.

```json

{

"dashboard": {

"title": "Service Overview - Production",

"panels": [

{

"title": "Request Rate (RED)",

"type": "timeseries",

"datasource": "Prometheus",

"targets": [

{

"expr": "sum(rate(http_requests_total{namespace='production'}[5m])) by (service)"

}

]

},

{

"title": "Error Rate",

"type": "stat",

"datasource": "Prometheus",

"targets": [

{

"expr": "sum(rate(http_requests_total{status=~'5..'}[5m])) / sum(rate(http_requests_total[5m])) * 100"

}

],

"fieldConfig": {

"defaults": {

"thresholds": {

"steps": [

{"color": "green", "value": 0},

{"color": "yellow", "value": 1},

{"color": "red", "value": 5}

]

}

}

}

}

]

}

}

```

SLOs e SLIs: observabilidade com propósito

Métricas sem contexto de negócio são ruído. SLIs (Service Level Indicators) e SLOs (Service Level Objectives) conectam observabilidade a experiência do usuário.

```yaml

# Exemplo de PrometheusRule para SLO

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

name: api-slo

namespace: monitoring

spec:

groups:

rules:

expr: |

1 - (

sum(rate(http_requests_total{job="api", status=~"5.."}[30d]))

/

sum(rate(http_requests_total{job="api"}[30d]))

)

expr: slo:api_availability:ratio < 0.999

for: 5m

labels:

severity: critical

annotations:

summary: "API SLO budget queimando - disponibilidade abaixo de 99.9%"

description: "Disponibilidade atual: {{ $value | humanizePercentage }}"

```

Definir SLOs antes de implementar alertas é o que separa equipes reativas de equipes proativas. Um SLO de 99.9% de disponibilidade significa um budget de 43 minutos de downtime por mês. Quando o budget está sendo consumido rápido demais, o alerta dispara antes do incidente virar crise.

Alerting: menos é mais

O maior erro em observabilidade é alert fatigue. Centenas de alertas que ninguém lê são piores que nenhum alerta.

Regras de ouro para alerting:

War story: o incidente que custou R$ 200.000

Um cliente operava um e-commerce em Kubernetes sem observabilidade adequada. Na Black Friday, a latência do checkout subiu de 200ms para 12 segundos. Sem traces, a equipe gastou 4 horas testando hipóteses — banco, rede, DNS, cache.

O problema real: um sidecar de logging consumia 90% da CPU dos pods do serviço de pagamento. Com OpenTelemetry configurado, o trace teria mostrado o bottleneck em 30 segundos.

Resultado: 4 horas de checkout degradado na Black Friday = R$ 200.000 em vendas perdidas.

Precisa de ajuda?

Agende uma call gratuita com nossa equipe e descubra como podemos implementar observabilidade de verdade no seu cluster Kubernetes. [Fale com um especialista →](/contato)

Nossa equipe de SRE já ajudou dezenas de empresas a reduzir MTTR de horas para minutos com Prometheus, Grafana e OpenTelemetry. Marque uma reunião sem compromisso e veja na prática o que podemos fazer pelo seu ambiente.