Pila de observación

1) Por qué se necesita una pila de observación

RCA rápida y reducción de MTTR: de síntoma a causa en minutos.
Control de SLO: medición de errores/latencia, alerting por presupuesto erróneo.
Control de lanzamientos: posts canarios, auto-rollback por métricas.
Seguridad y auditoría: vías de acceso, anomalías, Legal Hold.
Transparencia FinOps: costo de almacenamiento/consultas, costo-por-SLO.

Metodologías: Señales de Oro (latency/traffic/errors/saturation), RED, USE.

2) Arquitectura básica de la pila

Componentes por capa

Recolección/agentes: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Almacenamiento: S3/GCS/MinIO de objetos (frío prolongado), SSD (filas calientes).
Consultas/visualización: Grafana (paneles, widgets SLO), Kibana (si ELK).
Gestión: Alertmanager/alertas de grafano, directorio de servicios, RBAC, administrador secreto.

Patrones de implementación

Managed (Grafana Cloud/Cloud Services): rápido y más caro en volúmenes.
Self-hosted en K8s - control total, necesita operación y FinOps.

3) Normas de datos: un único «sistema de observación»

3. 1 Métricas (Prometheus/OpenMetrics)

Etiquetas obligatorias: 'env', 'region', 'cluster', 'namespace', 'service', 'version', 'tenant' (si multi-tenant), 'endpoint'.
Nomenclatura: 'snake _ case', sufijos '_ total', '_ seconds',' _ bytes '.
Histogramas: fijos 'buckets' (orientados a SLO).
Cardinalidad: no incluir 'user _ id', 'request _ id' en las etiquetas.

3. 2 Registros

Formato: JSON; campos obligatorios 'ts',' level ',' servicio ',' env ',' trace _ id ',' span _ id ',' msg '.
PII: enmascaramiento en el agente (PAN, tokens, e-mail, etc.).
Etiquetas loki: sólo baja cardinalidad ('app', 'namespace', 'level', 'tenant').

3. 3 Pistas

OTel semántica: 'servicio. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: las rutas de destino p99 son 'always _ on '/tail-sampling, el resto es' parent/ratio '.
ID incrustado: busque 'trace _ id/span _ id' en los registros y métricas (labels/fields).

4) Correlación M-L-T (Metrics/Logs/Traces)

Desde el gráfico de alerta (métrica) → los registros filtrados por 'trace _ id' → una pista específica.
Desde la pista (lenta span) → la solicitud de métricas de backend específico en el intervalo de span.
Los botones Drilldown de los paneles son: "to logs' y" to tracks "con sustitución de variables ('$ env', '$ service', '$ trace _ id').

5) OpenTelemetry Collector: pipeline de referencia

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Alerting: SLO y multi-burn

Idea: alertim no en el nivel de «CPU> 80%», sino en el consumo de Error Budget.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7) Dashboards: estructura de carpetas

00_Overview - plataforma: SLO, p95, 5xx%, capacity, incidentes activos.
10_Services - por servicios: RPS, p95/p99, errores, lanzamientos (anotaciones).
20_Infra - K8s/nodos/storidge/red, etcd, controladores.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, reglas WAF.
50_Synthetic - aptime y guiones headless.
60_Cost/FinOps - almacenamiento, consultas, caliente/frío, pronóstico.

Cada panel: descripción, unidades, propietario, enlace runbook, drilldown.

8) Logs: Taller LogQL

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Pistas: TraceQL y trucos

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Sintética y aptime

Blackbox-exporter: muestras HTTP/TCP/TLS/DNS de ≥3 regiones/ASN.
Headless: login/deposite scripts programados.
Alertas de Quorum: activación si ≥2 regiones ven una falla.
Status page: apdates automáticos + comentarios manuales.

11) Almacenamiento y retiro

Métricas: caliente 7-30 días (filas rápidas), downsampling/recording rules, frío - almacenamiento de objetos (meses).
Registros: caliente 3-7 días, luego - S3/GCS con índice (Loki chunk store/ELK ILM).
Pistas: 3-7 días 'always _ on' + almacenamiento de larga duración para muestras (tail-sampled/rechace).

• Rollover en tamaño y tiempo; presupuesto para solicitudes (cuotas/límites).
• Directivas individuales para prod/stage y datos de seguridad.

12) Multi-tenencia y accesos

Divida por 'tenant '/' namespace '/Espacios, patrones de índice y resoluciones.
Etiquete los recursos de facturación: 'tenant', 'service', 'team'.
Dashboards/alertas importadas - en espacios de comandos específicos.

13) Seguridad y cumplimiento

TLS/mTLS de agentes a beckends, HMAC para la salud privada.
RBAC para leer/escribir, auditar todas las solicitudes y alertas.
Edición PII en el borde; Prohibición de los secretos en las guaridas; DSAR/Legal Hold.
Aislamiento: clústeres/neymspaces individuales para dominios sensibles.

14) FinOps: coste de la observabilidad

Reducimos la cardinalidad de las etiquetas y la lógica en ingest (no en solicitudes).
Sampling Tracks + destino siempre para rutas críticas.
Downsampling/recording rules para agregaciones pesadas.
Archivando un acceso raro a un objeto frío.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD y pruebas de observabilidad

Linting métricas/registros en CI: prohibición de «explosión» de cardinalidad, verificación de histogramas/unidades.
Pruebas de observabilidad de contrato: métricas/campos de registro obligatorios, 'trace _ id' en middleware.
Canary: anotaciones de lanzamientos en grafos, SLO-auto-rollback.

16) Ejemplos: consultas rápidas

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

De los registros a las pistas (Loki → Tempo): pasa 'trace _ id' como enlace a Tempo UI/dashboard.

17) Calidad de la pila: lista de cheques

• Esquemas armonizados de métricas/logs/trazados y unidades de medida.
• 'trace _ id' en logs y métricas, drilldown desde paneles.
• Alertas SLO sin flapping (quorum/multi-window).
• Downsampling, cuotas de consulta, límites por paso/rango.
• Se han documentado y aplicado clases de retén y almacenamiento.
• La edición RBAC/auditoría/PII está incluida.
• Dashboards: propietario, runbooks, ≤2 -3 pantallas, respuesta rápida.
• FineOps-dashboard (volúmenes, costo, top govoruns).

18) Plan de implementación (3 iteraciones)

1. MVP (2 semanas): Prometheus→Mimir, Loki, Tempo; OTel Collector; dashboards básicos y alertas SLO; blackbox-muestreo.
2. Escala (3-4 semanas): tail-sampling, downsampling, multi-región ingest, RBAC/Spaces, FinOps-dashboards.
3. Pro (4 + semanas): auto-rollback por SLO, headless sintético de rutas clave, Legal Hold, portafolio de SLO y reporting.

19) Anti-patrones

«Gráficos hermosos sin SLO» - no hay acción → no hay beneficio.
Etiquetas de alta cardinalidad ('user _ id', 'request _ id') es una explosión de memoria y costo.
Registros sin JSON y sin 'trace _ id' - no hay correlación.
Alertas por recursos en lugar de síntomas - ruido y burnout on-call.
La ausencia de políticas de retiro es un aumento incontrolable de los costos.

20) Mini preguntas frecuentes

¿Qué elegir: Loki o ELK?
ELK para búsquedas/facetas complejas; Loki es más barato y más rápido para escenarios similares a grep. A menudo se usa un híbrido.

¿Las pistas son necesarias para todos?
Sí, al menos en rutas clave (login, checkout, payments) con tail-sampling - esto acelera drásticamente el RCA.

¿Cómo empezar desde cero?
OTel Collector → Mimir/Loki/Tempo → SLO básicos y muestras de blackbox → luego dashboards y burn-alerts.

Resultado

La pila de observación no es un conjunto de herramientas dispares, sino un sistema coherente: estándares de datos uniformes → correlación de M-L-T → alerting SLO y sintética → seguridad y FinOps. Fije los circuitos, la disciplina de las etiquetas y el retoque, conecte OTel, agregue drilldown y auto-rollback, y obtendrá una fiabilidad manejable con un costo comprensible.