MongoDB
Explica qué métricas, logs y señales observar en MongoDB para detectar saturación, errores, replicación atrasada, bloqueos y degradación de consultas.
Observabilidad permite responder qué está ocurriendo, por qué cambió y qué impacto tiene. En MongoDB combina métricas, logs, profiler, query shapes, eventos de topología y señales de la aplicación.
síntoma del usuario
→ métrica de aplicación
→ pool y red
→ query plan
→ cache, disco y replication
→ cambio o incidente relacionadoUna métrica aislada no es diagnóstico. CPU alta puede ser causa o consecuencia; latencia baja en promedio puede ocultar un p99 crítico.
Mide p50, p95 y p99 por operación, colección y endpoint. Separa:
Observa reads, writes, commands y bytes. Un crecimiento sano de tráfico no debe confundirse con regresión, pero sirve para normalizar otras métricas.
Monitorea conexiones activas, disponibles, creadas y wait queue. Connection storms suelen aparecer en despliegues, serverless mal configurado o clientes creados por request.
Revisa WiredTiger cache, dirty bytes, eviction, pages read y working set. RAM usada por el sistema no significa por sí sola fuga; MongoDB y el OS utilizan memoria como cache.
IOPS, throughput, latency, queue depth, espacio libre y crecimiento. El disco lleno puede detener writes y comprometer recuperación.
Antes de alertar, conoce el comportamiento normal por hora, día y campaña. Conserva baseline de:
Una alerta estática puede generar ruido durante un cierre mensual normal o no detectar una desviación gradual.
Alertas de síntoma:
Alertas de capacidad:
Cada alerta necesita owner, severidad, contexto y runbook. Una notificación sin acción esperada es ruido.
Anota cambios:
17:05 deploy
17:08 aumenta keysExamined
17:10 sube p99
→ investigar nueva query shapeLos logs sirven para errores de red, slow operations, storage, replication y cambios administrativos. Centralízalos y aplica retención.
No registres:
Utiliza operation IDs para correlacionar aplicación y base.
Instrumenta el driver con command monitoring o OpenTelemetry según stack. Registra:
No captures valores completos por defecto.
Ejemplo:
99.9 % de lecturas de órdenes < 250 ms
99.5 % de escrituras < 500 ms
RPO 15 min
RTO 60 minLos SLOs conectan métricas técnicas con experiencia y riesgo. Una CPU de 80 % no es un objetivo de producto; la latencia y disponibilidad sí.
Además observa:
mongos;Un cluster equilibrado en bytes puede estar desbalanceado en tráfico.
Organiza por preguntas:
Evita paneles con cientos de gráficas sin jerarquía.
Proyecta:
Usa tendencias y eventos futuros. Escalar después de llenar el disco es demasiado tarde.
Durante incidente:
No limpies plan cache, reinicies nodos o elimines índices sin hipótesis y rollback.
Observabilidad conecta síntomas de usuario con query plans, pools, memoria, disco y topología. Mide percentiles, establece baselines y alertas accionables, protege datos sensibles y conserva contexto de cambios. El objetivo no es coleccionar métricas, sino diagnosticar y operar con margen.
Profiler y slow queries.