Cosmos Operations Center — realtime, predictive, AI-driven
El dashboard de DBA que le dice qué arreglar antes que el cliente llame. Charts realtime con detección de anomalía, click en cualquier spike para drill en un walk de root cause AI-narrado, ETAs predictivos que avisan antes de saturación, políticas configurables que disparan automáticamente — y timeline grabable completo para que pueda hacer post-mortem del incidente de ayer en 30 segundos.
Lo que le muestra, en el momento que abre
4 charts realtime (tick de 1s)
RU/s consumido · Eventos de Throttle 429 · Latencia p99 · Conteo de errores. Los cuatro actualizando cada segundo del ring buffer Query Cost. Última hora en memoria.
Puntos rojos = anomalías, clicables
El detector de anomalía flagga throttle storms, saturación RU, spikes de latencia, partition skew en el momento que suceden. Cada anomalía es un punto rojo fijado a su timestamp exacto.
Banner de alertas predictivos
Regresión lineal sobre los últimos 3 min le dice "RU va a saturar en ~14 min si la tendencia continúa" — accionable ANTES de la breach, no después.
Toggle de grabación (history-store)
Un clic y cada snapshot es persistido en la misma instancia MongoDB management que configuró para mongostat/mongotop. Job Manager muestra junto con los otros.
Cada punto rojo abre un Walk de Root Cause AI-narrado
Click en la anomalía → un side drawer desliza con tres stops, cada uno respaldado por contexto determinístico (Query Cost ring buffer + caches cross-scanner) + narración AI opcional en su idioma.
QUÉ pasó
Timestamp exacto, valor de la métrica, severidad, top query shape corriendo en ese minuto, estado de partición del cache del scanner. Determinístico — costo AI cero.
POR QUÉ (causa más probable)
AI mira el contexto estructurado y escribe la única root cause más probable + la evidencia en los datos que soporta. Habla el idioma del DBA. Cached por firma.
CÓMO arreglar
Mitigation rápido (5min) + fix permanente (esta semana), cada uno linkado al pane del scanner que posee el comando apply. Un click y está en el lugar correcto.
El DBA elige el modelo AI por análisis
¿Incidente rutinario de costo? Use gpt-4o-mini ($0.001). ¿Outage de producción alta severidad? Cambie a Claude Sonnet ($0.018) para el mismo incidente. Picker de provider está dentro del drawer — costo mostrado upfront, sin sorpresas.
├ OpenAI gpt-4o-mini ($0.001)
├ Anthropic Claude Sonnet ($0.018) ✓
├ Google Gemini ($0.001)
├ Groq Llama ($0.002)
└ Ollama (local · gratis)
Resultados cached por firma de incidente × provider × locale (TTL de 4h) — mismo incidente clicado dos veces = re-charge cero.
Pronósticos que avisan ANTES de la breach
Regresión lineal sobre los últimos 3 minutos de telemetría — R²-tagged para confianza, severidad-escalada por ETA.
ru-saturation-eta~14 minRU/s creciendo a 8.2/s — va a saturar en ~14 min si la tendencia continúa
throttle-trending-upen progresoEventos de Throttle subiendo — 23 en los últimos 5min, tasa +0.04/s²
partition-skew-growing~3.2 horasShare de la top partition creciendo (ahora 52%) — va a cruzar 70% en ~3.2 horas
storage-saturation-eta12 díasStorage en 78% — extrapolado para llegar a 90% en 12 días con crecimiento actual
Políticas que el DBA define — disparan automáticamente
Cada conexión Cosmos tiene sus propias políticas. Triggers (threshold + duración + pattern de ns) ligados a acciones (notify in-app, webhook Slack, webhook genérico, pre-stage scale-up, pre-stage path exclusion, AI analyze).
Throttle storm — 5/min
Cuando eventos de throttle > 5/min sostenidos por 2min, dispara notificación in-app + pre-stage de scale-up +50% (requiere aprobación DBA).
Saturación RU — 85%
Cuando RU/s cruza 85% del ceiling observado por 5min, notifica con sugerencia de switch a autoscale.
Latencia p99 — 500ms
Cuando p99 excede 500ms por 1min, notifica + dispara análisis AI en el path de la slow query.
Partition skew — top > 50%
Cuando una partición contiene > 50% de los docs, pre-stages un plan de re-partition (aprobación obligatoria).
Cada fire es deduped por (policy × ns × bucket de 5min) — sin fatiga de alerta. Snooze de 1h con un click. Audit log preserva cada fire con el valor de la métrica, la policy que disparó, y qué acción fue encolada.
Post-mortem del incidente de ayer en 30 segundos
Un clic en "Start recording" → cada snapshot persiste a la misma conexión MongoDB management que mongostat/mongotop ya usan. Abra Job Manager → click en cualquier job "Rec Cosmos Ops" → el scrubber Timeline unificado le deja replay el comportamiento del cluster al lado de las grabaciones MongoDB de la misma ventana.
Nadie más correlaciona Cosmos + MongoDB en un único scrubber.
Por qué esto es incopiable por Datadog / Grafana / Azure Monitor
| Capacidad | Operations Center | Datadog | Grafana | Azure Monitor |
|---|---|---|---|---|
| Charts de cluster realtime | ✅ | ✅ | ✅ | ✅ |
| Click en spike → walk de root cause | ✅ | ⚠ solo link | ❌ | ⚠ solo link |
| Narración AI en su idioma | ✅ BYO LLM | ⚠ AI cerrado | ❌ | ⚠ AI cerrado |
| Elija modelo AI por incidente | ✅ | ❌ | ❌ | ❌ |
| Comando Apply pre-staged + Shadow-validated | ✅ | ❌ | ❌ | ❌ |
| Cosmos $indexStats / GetPartitionStats correlacionados | ✅ | ❌ | ❌ | ⚠ |
| Cross-correlate con monitoreo MongoDB | ✅ | ❌ | ⚠ si ambos ingested | ❌ |
| Precio | $99-499/mo | $15+/host/mo | self-host | por GB ingested |
Pare de buscar templates. Abra el Operations Center y vea.
NoSqlStudio para Cosmos DB es gratis para probar — sin tarjeta, sin registro. Abra cualquier conexión Cosmos, haga clic en Operations Center, vea los charts cobrar vida.