Centralización de registros

1) Por qué centralizar los registros

• acelerar la búsqueda de las raíces de los incidentes (correlación por id-request/trace-id);
• permiten construir alertas de señalización sobre los síntomas (errores, anomalías);
• dan la auditoría-pista (quién/cuándo/qué hizo);
• reducen el costo al unificar la retención y el almacenamiento.

2) Principios básicos

1. Sólo registros estructurados (JSON/RFC5424) - sin «texto libre» sin claves.
2. Esquema único de claves: 'ts, level, service, env, region, tenant, trace_id, span_id, request_id, user_id (masked), msg, kv...'.
3. Correlación predeterminada: dirija la trace_id de gateway a los backends y a los registros.
4. Mínimo ruido: niveles correctos, sampling, deduplicación de repeticiones.
5. Seguridad por diseño: enmascaramiento PII, RBAC/ABAC, inmutabilidad.
6. Economía: hot/warm/cold, compresión, agregaciones, TTL y rehydration.

3) Arquitecturas típicas

EFK/ELK: (Fluent Bit/Fluentd/Filebeat) → (Kafka — опц.) → (Elasticsearch/OpenSearch) → (Kibana/OpenSearch Dashboards). Búsqueda y agregaciones universales.
Loki-like (indexación de logs por etiquetas): Promtail/Fluent Bit → Loki → Grafana. Más barato para grandes volúmenes, potente filtro de etiquetas + visualización lineal.
Nubes: CloudWatch/Cloud Logging/Log Analytics + exportación a almacenamiento en frío (S3/GCS/ADLS) y/o a SIEM.
Enfoque del lago de datos: efervescentes → almacenamiento de objetos (parquet/iceberg) → consultas analíticas baratas (Athena/BigQuery/Spark) + capa en línea (OpenSearch/Loki) para los últimos días N.

Recomendación: para el pro-oncol mantener la capa en línea (7-14 días hot) y el archivo (meses/años) en el lago con la capacidad de rehydrate.

4) Esquema y formato de registro (recomendación)

json
{
"ts":"2025-11-01T13:45:12.345Z",
"level":"ERROR",
"service":"payments-api",
"env":"prod",
"region":"eu-central",
"tenant":"tr",
"trace_id":"0af7651916cd43dd8448eb211c80319c",
"span_id":"b7ad6b7169203331",
"request_id":"r-7f2c",
"user_id":"",        // masked
"route":"/v1/payments/charge",
"code":"PSP_TIMEOUT",
"latency_ms":1200,
"msg":"upstream PSP timeout",
"kv":{"provider":"psp-a","attempt":2,"timeout_ms":800}
}

Estándares: RFC3339 para el tiempo, nivel del conjunto 'TRACE/DEBUG/INFO/WARN/ERROR/FATAL', claves en snake_case.

5) Niveles de lógica y sampling

DEBUG: sólo en dev/stage; en prod por bandera y con TTL.
INFO: ciclo de vida de consultas/eventos.
WARN - Situaciones sospechosas sin afectar a SLO.
ERROR/FATAL - Impacto en la consulta/usuario.

• rate-limit para errores recurrentes (por ejemplo, 1/sec/clave).
• tail-sampling tracks (dejar registros/tracks completos sólo para consultas «malas»).
• dinámico: en una tormenta de errores, reducir el detalle, guardar resumen.

6) Entrega de registros (agentes y efervescentes)

En el nodo: Fluent Bit/Filebeat/Promtail recogen stdout archivos/journales, hacen parking, enmascaramiento, búfering.
Colas de red: Kafka/NATS para suavizar picos, retraídas y ordenar.
Fiabilidad: backpressure, búferes de disco, confirmaciones de envío (at-least-once), índices idempotentes (clave-hash).
Filtrado en el borde: descarta los «charlatanes» y secretos antes de entrar en la red.

7) Indización y almacenamiento

Partición por tiempo (daily/weekly) + por 'env/region/tenant' (a través de plantillas de índice o etiquetas).

• Hot (SSD, 3-14 días): búsqueda rápida y alertas.
• Warm (HDD/congelador, 30-90 días): a veces buscamos.
• Cold/Archivo (objeto, meses/años): cumplimiento y raras investigaciones.
• Compresión y rotación: ILM/ISM (políticas de ciclo de vida), gzip/zstd, downsampling (tablas de agregación).
• Rehydration: carga temporal de lotes de archivo en un clúster «caliente» para la investigación.

8) Búsqueda y análisis: consultas típicas

Incidente: filtro de tiempo × 'service =...' × 'level> = ERROR' × 'trace _ id '/' request _ id'.
Proveedores: 'code: PSP _' y 'kv. provider: psp-a 'con agrupación por región.
Anomalías: aumento de la frecuencia de los mensajes o cambio de las distribuciones de los campos (detectores ML, rule-based).
Auditoría: 'categoría: audit' + 'actor '/' resource' + resultado.

9) Correlación con métricas y trazados

Los mismos identificadores son: 'trace _ id/span _ id' en las tres señales (métricas, logs, tracks).
Enlaces de gráficos: haga clic en la transición del panel p99 a los logs por 'trace _ id'.
Anotaciones de lanzamiento: versiones/canarios en métricas y logs para un enlace rápido.

10) Seguridad, PII y cumplimiento

Clasificación de campos: PII/secretos/finanzas - enmascarar o eliminar en la entrada (filtros Fluent Bit/Lua, Re2).
RBAC/ABAC: acceso a índices/etiquetas por roles, row/field-level-security.
Inmutabilidad (WORM/append-only) para auditorías y requisitos reguladores.
Retén y «derecho al olvido»: TTL/eliminación por clave, tokenización 'user _ id'.
Firmas/hashes: integridad de registros críticos (acciones administrativas, pagos).

11) SLO y métricas de registros de paipline

Entrega: 99. 9% de los eventos en la capa caliente ≤ 30-60 segundos.
Pérdidas: <0. 01% en el tramo de 24 h (por marcas de control).
Disponibilidad de búsqueda: ≥ 99. 9% en 28 días.
Latencia de las consultas: p95 ≤ 2-5 segundos en los filtros típicos.
Costo: $/1M eventos y $/almacenamiento/GB en el corte de capas.

12) Dashboards (mínimo)

Salud de la paipeline: entrada/salida de los espigones, retraídas, relleno de los búferes, lag Kafka.
Errores en los servicios/códigos: top N, tendencias, percentili 'latency _ ms'.
Actividad de auditoría: acciones de administración, errores de proveedor, accesos.
Economía: volumen/día, índice-ganancia, costo por capa, consultas «caras».

13) Operaciones y playbucks

Tormenta de registros: habilite el sampling/rate-limit agresivo en el agente, levante los búferes, transfiera temporalmente parte del flujo a warm.
Deriva del esquema: alerta a la aparición de nuevas claves/tipos, iniciando la negociación de esquemas (schema-catalog).
Búsqueda lenta: recomposición de índices, aumento de réplicas, análisis de consultas «pesadas», archiving de lotes antiguos.
Incidente de seguridad: activación inmediata de la inmutabilidad, descarga de artefactos, restricción de acceso por roles, RCA.

14) FinOps: cómo no arruinar en los logs

Quite la verbosidad: convierta la stacktrace de varias líneas en un campo 'stack' y muestree las repeticiones.
Habilitar TTL: diferente para 'env '/' level '/' category'.
Utilice Loki/Archive + rehydrate on-demand para obtener acceso raro.
Lotes y compresión: los lotes más grandes son más baratos, pero sigue la búsqueda SLA.
Materialice informes analíticos frecuentes (agregados diarios).

15) Ejemplos instrumentales

Bit Fluent (enmascarar y enviar a OpenSearch)

ini
[INPUT]
Name       tail
Path       /var/log/app/.log
Parser      json
Mem_Buf_Limit   256MB

[FILTER]
Name       modify
Match
Remove_key    credit_card, password

[OUTPUT]
Name       es
Host       opensearch.svc
Port       9200
Index       logs-${tag}-${date}
Logstash_Format  On
Suppress_Type_Name On

Nginx access log в JSON с trace_id

nginx log_format json escape=json '{ "ts":"$time_iso8601","remote":"$remote_addr",'
'"method":"$request_method","path":"$uri","status":$status,'
'"bytes":$body_bytes_sent,"ua":"$http_user_agent","trace_id":"$http_trace_id"}';
access_log /var/log/nginx/access.json json;

Política OpenSearch ILM (hot→warm→delete)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"delete":{ "min_age": "90d", "actions": { "delete": {} } }
}
}
}

16) Lista de verificación de implementación

• Se ha adoptado un esquema de campos y niveles de registro; la correlación trace/request-id está habilitada.
• Agentes configurados (Bit/Promtail Fluent) con enmascaramiento y buffers.
• Se ha seleccionado una capa en línea (OpenSearch/Loki/Cloud) y un archivo (S3/GCS + parquet).
• Políticas de retención ILM/ISM + hot/warm/cold, proceso rehydrate.
• RBAC/ABAC, inmutabilidad para auditoría, registro de acceso.
• Pipeline Dashboards, alertas de pérdida/valor/amortiguadores de discos.
• Playbucks: tormenta de registros, diagrama de deriva, búsqueda lenta, incidente de seguridad.
• Límites financieros: eventos $/1M, cuotas para solicitudes «caras».

17) Anti-patrones

Los registros de texto sin estructura → la imposibilidad de filtrar y agregar.
Una gigantesca estaca en INFO → una explosión de volumen.
La falta de correlación → el «aleteo» en todos los servicios.
El almacenamiento de «todo para siempre» → la factura de la nube como un avión.
Secretos/PII en los logs → riesgos de cumplimiento.
Edición manual de índices en venta → deriva y tiempo de inactividad prolongado de la búsqueda.

18) Resultado

La centralización de los registros es un sistema, no sólo una pila. El esquema estandarizado, la correlación, los efervescentes seguros, el almacenamiento en capas y las estrictas políticas de acceso convierten los registros en una poderosa herramienta para los ERE, la seguridad y el producto. Retenciones correctas y FinOps mantienen el presupuesto, y SLO de pipeline y playbooks hacen que las investigaciones sean rápidas y reproducibles.