Logs

Los logs son la mitad Loki del stack L1. Siguen la misma forma de data plane que las métricas: los edges empujan directo a Loki sobre HTTPS, el manager solo consulta.

El data plane

text

edge:
  ongrid-edge agent
    └─ plugin: promtail (subprocess)
        ├─ tails /var/log/syslog, /var/log/messages, journald
        └─ remote write HTTPS → loki:3100
                                     │
                                     ▼ /loki/api/v1/query_range
                              ┌───────────────┐
                              │  manager:     │
                              │   - alert     │
                              │   - LLM tools │
                              └───────────────┘

ADR-015 plugin runtime

promtail corre como un sub-proceso bajo el runtime de plugin del agente de edge. El agente supervisa el ciclo de vida — restart en crash, drain en shutdown, log al mismo journal de systemd que el agente. Desde la perspectiva del operador es un servicio systemd, no dos.

La alternativa anterior ("vendor promtail como librería Go statically- linked") se rechazó porque cada upgrade del cliente Loki forzaría un re-release del agente edge. El subproceso los desacopla.

Configuración

La config por-edge de promtail la renderiza del lado del servidor biz/edge/plugin_config.go y se empuja por el túnel de control al arranque del plugin. Consulta system_settings.loki.url para que un cambio de URL por admin se propague sin recompilar el agente.

Tail set default:

Fuente	Labels de Loki
`/var/log/syslog`, `/var/log/messages`	`job=node-syslog`, `host=<edge-name>`
journald de systemd (todas las units)	`job=systemd-journal`, `host=<edge-name>`, `unit=<svc>`

Los tails custom se añaden vía la página /edges/<id>/logs/sources de la SPA — escriben en el mismo namespace system_settings.loki.*.

La separación del data plane

ADR-014: la telemetría va directo, el control va por el túnel. Para logs esto significa:

✅ promtail HTTPS POST → loki:3100/loki/api/v1/push (directo).
✅ Loki HTTPS GET ← manager /loki/api/v1/query_range (directo).
❌ Los logs NO viajan por el túnel de control geminio.

Por qué: el túnel es un multiplexer in-process; pipear bursts de log a través de él hambreaba a los RPCs de control (llamadas de tool RCA, I/O de WebSSH) cuando el ingest disparaba. Separar el data plane arregla el problema de noisy-neighbour y deja que nginx posea la superficie pública (TLS, rate limiting, auth) para ambas mitades uniformemente.

Kinds de alerta

Dos kinds de regla manejados por logs — ambos Phase-B, ambos en evaluators_phaseB.go.

`log_match`

Dispara cuando count_over_time(<stream_selector> |~ <line_filter> [window]) <op> threshold devuelve al menos una entrada de matriz.

json

{
  "kind": "log_match",
  "scope_type": "global",
  "conditions_json": {
    "stream_selector": "{job=\"systemd-journal\",unit=\"nginx.service\"}",
    "line_filter": "(?i)5\\d{2}",
    "window": "5m",
    "operator": ">=",
    "threshold": 50
  }
}

line_filter es opcional — cuando está vacío, la regla cuenta cada línea en el stream. La query la construye por-tick compileLogMatchRule en rules.go:733.

`log_volume`

Mismo motor que log_match en v1 (conteo de ventana actual vs threshold absoluto). La semántica original del spec "ratio vs ventana previa" está parqueada — necesita dos queries LogQL + división del lado Go; la forma absoluta ya cubre el caso de uso común "logs disparados pasando N".

La columna spec es ratio_op / ratio_threshold (mantenida para forward compat); el compilador las mapea a operator / threshold.

Tools

`search_logs` / `query_logql`

La búsqueda de logs cara al LLM. Dos rutas de registro apuntan a un ejecutor:

query_logql — passthrough de LogQL crudo. Usado por el worker investigator cuando la persona sabe exactamente qué stream consultar.
search_logs — wrapper más amigable expuesto en las Quick Actions de la UI de chat, toma una query free-text + un nombre de servicio.

Schema + ejecutor en query_logql_basetool.go. Cliente subyacente: internal/pkg/logquery.

Ambos honran la env global ONGRID_LOG_QUERY_URL (default http://loki:3100) y heredan auth de la misma capa nginx que los edges usan para empujar.

`host_tail_file`

Probe de log del lado skills — corre en el edge, no en el manager. Usa esto cuando necesites el archivo crudo (p. ej. /var/log/ongrid-edge.log que no está en journald) en lugar de la vista Loki-ingestada. ScopeHost; requiere un edge_id. Ver Skills para el modelo de dispatch.

Ver también

Alertas — ciclo de vida de log_match / log_volume.
Monitoring — el pipeline paralelo para Prom.
Instalación de edge — encendiendo el plugin logs.
Data plane de telemetría — el trace completo de ADR-014.

Logs ​

El data plane ​

Configuración ​

La separación del data plane ​

Kinds de alerta ​

log_match ​

log_volume ​

Tools ​

search_logs / query_logql ​

host_tail_file ​

Ver también ​