Logs

Les logs sont la moitié Loki de la stack L1. Ils suivent la même forme de plan de données que les métriques : les edges poussent directement vers Loki sur HTTPS, le manager ne fait qu'interroger.

Le plan de données

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 │
                              └───────────────┘

Runtime plugin ADR-015

promtail tourne comme sous-processus sous le runtime de plugins de l'agent edge. L'agent supervise le cycle de vie — redémarrage sur crash, drain au shutdown, log dans le même journal systemd que l'agent. Du point de vue de l'opérateur, c'est un seul service systemd, pas deux.

L'alternative précédente (« vendoriser promtail comme bibliothèque Go liée statiquement ») a été rejetée parce que chaque upgrade du client Loki forcerait une re-release de l'agent edge. Le subprocess les découple.

Configuration

La config promtail par edge est rendue côté serveur par biz/edge/plugin_config.go et poussée sur le tunnel de contrôle au démarrage du plugin. Elle consulte system_settings.loki.url pour qu'un changement d'URL admin propage sans rebuild de l'agent.

Set de tails par défaut :

Source	Labels Loki
`/var/log/syslog`, `/var/log/messages`	`job=node-syslog`, `host=<edge-name>`
journald systemd (toutes unités)	`job=systemd-journal`, `host=<edge-name>`, `unit=<svc>`

Des tails personnalisés sont ajoutés via la page /edges/<id>/logs/sources de la SPA — ils écrivent dans le même namespace system_settings.loki.*.

La séparation du plan de données

ADR-014 : la télémétrie va en direct, le contrôle passe par le tunnel. Pour les logs cela signifie :

✅ POST HTTPS promtail → loki:3100/loki/api/v1/push (direct).
✅ GET HTTPS Loki ← manager /loki/api/v1/query_range (direct).
❌ Les logs NE voyagent PAS par le tunnel de contrôle geminio.

Pourquoi : le tunnel est un multiplexeur in-process ; faire passer des bursts de logs à travers privait les RPCs de contrôle (appels d'outils RCA, I/O WebSSH) quand l'ingest piquait. Séparer le plan de données corrige le problème de voisin bruyant et laisse nginx posséder la surface publique (TLS, rate limiting, auth) pour les deux moitiés uniformément.

Types d'alerte

Deux types de règles pilotés par les logs — tous deux Phase-B, tous deux dans evaluators_phaseB.go.

`log_match`

Part quand count_over_time(<stream_selector> |~ <line_filter> [window]) <op> threshold renvoie au moins une entrée de matrice.

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 est optionnel — quand vide, la règle compte chaque ligne dans le stream. La requête est construite par tick par compileLogMatchRule dans rules.go:733.

`log_volume`

Même moteur que log_match en v1 (count fenêtre courante vs seuil absolu). La sémantique originale « ratio vs fenêtre précédente » de la spec est parquée — elle nécessite deux requêtes LogQL + division côté Go ; la forme absolue couvre déjà le cas d'usage commun « logs ont piqué au-delà de N ».

La colonne spec est ratio_op / ratio_threshold (gardée pour compat avant) ; le compilateur les mappe à operator / threshold.

Outils

`search_logs` / `query_logql`

La recherche de logs présentée au LLM. Deux chemins d'enregistrement pointent vers un exécuteur :

query_logql — passthrough LogQL brut. Utilisé par le worker investigator quand la persona sait exactement quel stream interroger.
search_logs — wrapper plus amical exposé dans les Quick Actions de l'UI de chat, prend une query en texte libre + un nom de service.

Schéma + exécuteur dans query_logql_basetool.go. Client sous-jacent : internal/pkg/logquery.

Les deux honorent l'env global ONGRID_LOG_QUERY_URL (défaut http://loki:3100) et héritent de l'auth de la même couche nginx que les edges utilisent pour pousser.

`host_tail_file`

Sonde de log côté skills — tourne sur l'edge, pas sur le manager. Utilisez ceci quand vous avez besoin du fichier brut (par ex. /var/log/ongrid-edge.log qui n'est pas dans journald) plutôt que de la vue ingérée par Loki. ScopeHost ; nécessite un edge_id. Voir Skills pour le modèle de dispatch.

Voir aussi

Alertes — cycle de vie de log_match / log_volume.
Monitoring — le pipeline parallèle pour Prom.
Installation edge — activer le plugin logs.
Plan de données de télémétrie — trace ADR-014 complète.

Logs ​

Le plan de données ​

Configuration ​

La séparation du plan de données ​

Types d'alerte ​

log_match ​

log_volume ​

Outils ​

search_logs / query_logql ​

host_tail_file ​

Voir aussi ​