Monitoring

Ongrid trae un pipeline de monitoring funcional de fábrica y está diseñado para doblarse hacia el tuyo existente cuando lo tienes.

El data plane

edge:
  hostmetrics, procmetrics, node-exporter  ─┐
                                            │  remote_write (HTTPS direct)
                                            ▼
                                       ┌─────────┐
                                       │  Prom   │  (default: bundled)
                                       └────┬────┘
                                            │ query_range / instant
                                            ▼
                                  ┌──────────────────────┐
                                  │  manager:            │
                                  │   - alert evaluator  │
                                  │   - query_promql     │
                                  │   - /api/grafana     │
                                  └──────────────────────┘

El default es Prometheus integrado corriendo en el docker-compose en prometheus:9090. Los edges empujan directo a él sobre HTTPS — sin scrape, sin node discovery. Esta es la división data-plane / control-plane de ADR-014: el túnel geminio lleva control, la telemetría va directo.

Por qué directo, no vía el túnel

A cardinalidad ≥ 5 k series/sec en una instalación de 50 hosts, multiplexar remote_write a través del túnel de control geminio se ahogaba. El remote_write directo saca al manager del hot path y deja que el propio write-ahead-log de Prom maneje el buffering de ingestión. El trade-off es un endpoint HTTPS más que exponer; ver Instalación del servidor para el snippet de reverse-proxy de nginx.

Prom integrado vs externo

Ambos modos son first-class.

Integrado (default)

docker compose up trae prometheus:v2.55 con --web.enable-remote-write-receiver. El storage es un volumen named ongrid_prom_data. La retención default es 15d — afínala vía PROMETHEUS_RETENTION en .env.

El manager le habla en http://prometheus:9090 vía la env ONGRID_PROM_QUERY_URL. No se necesita más configuración.

Externo

Apunta ONGRID_PROM_QUERY_URL a tu propio endpoint de query Prom / VictoriaMetrics / Thanos. Los edges siguen haciendo remote_write — apúntalos a tu URL de ingest seteando el remote_write_url por-edge en la config de plugin del Edge (internal/manager/biz/edge/plugin_config.go).

El Prom cloud-bundled puede seguir corriendo como Prom de "self-observability" que solo scrapea al propio manager (las métricas de self-obs de ADR-026 viven ahí). Las alertas que necesiten ambas mitades se pueden definir dos veces con distintos match_scope_types.

La ruta de query

Dos consumidores, un cliente.

Evaluator de alertas

PipelineEvaluator.evaluatePromQuery corre el Expr de cada regla metric_raw habilitada en cada tick. Los propios operadores de comparación de PromQL (up == 0, cpu_pct > 90) SON el predicado — Prom elimina las series que no matchean de la respuesta, así que el evaluator simplemente dispara un incidente por cada entrada de vector devuelta y reaprovecha el resto en el sweep de recovery del siguiente tick.

// pipeline.go:269
res, err := e.prom.Query(ctx, rule.Expr, now)
// ...
for _, ent := range entries {
    dedupeKey := fmt.Sprintf("pipeline:%s:%s", rule.RuleKey, labelSetKey(ent.Metric))
    // ... RecordFiring + notify
}

El tool query_promql

El LLM obtiene un BaseTool llamado query_promql que toma una query instant o range y devuelve el vector / matrix JSON. La persona investigator lo usa como su probe principal de métrica; el chat del coordinator lo usa cuando preguntas "¿cuál es la cpu en edge-prod-04 ahora mismo?".

El schema vive en query_promql_basetool.go; el motor subyacente es internal/pkg/promquery.

Grafana embebido

El compose trae Grafana en grafana:3000. El manager lo proxiya bajo /api/grafana/* (auth verificada en el proxy) para que el MonitorPanel.tsx de la SPA pueda embeber iframes con un clic — sin login de Grafana separado.

De fábrica, el manager espeja las definiciones internas de monitor panel a Grafana vía biz/grafana/Service en un tick de sync. Los operadores editan paneles en Grafana (el editor rich), el manager los recoge. La página MonitorEditor en la SPA es un read-then-redirect delgado que abre el editor de panel de Grafana pre-rellenado con la serie relevante.

Credenciales de Grafana

El Grafana bundled viene con admin / admin. Cámbialo antes de exponer. Ver Checklist de primer arranque.

Self-observability

ADR-026 cableó /metrics en el manager + 6 alertas baseline (spike de token LLM, stall del evaluator de alertas, tormenta de disconnect del túnel, lag del audit log, backlog del investigator, latencia p99 de RCA). Estas se siembran al primer boot en las tablas de rules + dashboard y se re-afirman en cada upgrade.

El Prom bundled scrapea /metrics del manager. El modo de Prom externo necesita que añadas un scrape target en manager:9100 (default ONGRID_METRICS_ADDR).

Ver también

• Alertas — los rule kinds que consultan Prom.
• Trazas — el generador de spanmetrics que alimenta las series traces_spanmetrics_* de vuelta al mismo Prom.
• Logs — el pipeline paralelo para Loki.
• Variables de entorno — cada perilla ONGRID_PROM_* y PROMETHEUS_*.