Check-list du premier démarrage

Juste après que install.sh finit et que vous vous êtes connecté en admin bootstrap, parcourez cette liste. Rien n'est requis pour « commencer à voir des choses » — le Quickstart fonctionne sans tout cela — mais chaque item ferme un trou avant que vous ne passiez le système à une équipe.

1. Mettre ONGRID_PUBLIC_URL correctement

Probablement l'item le plus important. Cette URL est ce que vos edges utilisent pour le plan de données — les logs poussent vers <url>/loki/api/v1/push, les traces vers <url>/v1/traces.

Vérifiez ce qu'install.sh a rempli :

sudo grep '^ONGRID_PUBLIC_URL=' /opt/ongrid/.env

Si vous avez accepté une adresse interne mais que vos edges vivent sur l'internet public, les logs et traces échoueront silencieusement — le tunnel marche encore (il a son propre port), donc l'edge paraît sain.

Pour corriger :

# Edit
sudo sed -i 's|^ONGRID_PUBLIC_URL=.*|ONGRID_PUBLIC_URL=https://ops.example.com|' /opt/ongrid/.env

# Restart the affected services
sudo docker compose -f /opt/ongrid/docker-compose.yml --env-file /opt/ongrid/.env up -d ongrid nginx

Vous n'avez pas besoin de redéployer les edges ; l'agent relit l'endpoint du plan de données depuis le manager périodiquement.

Voir ONGRID_PUBLIC_URL.

2. Configurer un provider LLM par défaut

Out of the box, aucun provider n'est configuré. L'agent refusera de penser.

1. Settings → Models. Choisissez l'un de :
   • OpenAI (gpt-5.4 par défaut)
   • Anthropic (claude-opus-4-7 par défaut)
   • Zhipu (glm-4.7 par défaut)
   • DeepSeek (deepseek-v4-flash par défaut)
   • Gemini (gemini-2.5-pro par défaut)
   • Kimi (kimi-k2.6 par défaut)
   • Custom compatible OpenAI (vLLM, Ollama, OpenRouter, relais corporate…)
2. Collez la clé API. Optionnel : surchargez le modèle par défaut dans « Advanced ».
3. Save. La pré-enregistrement est à chaud — pas de redémarrage.
4. Sur la même page, mettez Default provider à celui que vous venez de câbler.

Ne mélangez pas default_provider et modèles par route

Le « default » pilote les appels LLM back-end (investigation d'alerte, translate, summarize). Le picker de modèle dans l'en-tête du chat est une surcharge par thread — utile pour « essayer Opus sur cette question » mais le défaut du site est ce qui tourne pour les cron jobs et incidents.

Voir les entrées Routing & default et Budget & limits sous Modèles dans la sidebar.

3. Configurer un canal de notification

Même si vous n'avez pas encore de règles d'alerte, câblez un canal pour que les futurs incidents aient un endroit où atterrir.

La paire de démarrage recommandée :

• Canal Webhook vers un collecteur de webhook entrant générique (vous pouvez toujours le retirer plus tard) — prouve que le chemin de notification marche.
• Un canal IM — Telegram est le plus facile parce que vous n'avez besoin que d'un token de bot et d'un chat ID ; Slack/Lark/DingTalk/WeCom prennent plus de setup.

Voir aperçu des canaux.

4. Régler le fuseau horaire du manager

Les timestamps dans les timelines d'incident et les événements d'alerte suivent le fuseau horaire du manager. Le défaut est UTC à l'intérieur du conteneur ; pour une UI qui matche votre équipe :

# Set TZ in compose env. Edit /opt/ongrid/docker-compose.yml or drop a
# /opt/ongrid/docker-compose.override.yml with:
services:
  ongrid:
    environment:
      TZ: Asia/Shanghai

sudo docker compose -f /opt/ongrid/docker-compose.yml --env-file /opt/ongrid/.env up -d ongrid

Pour la locale de sortie IA (le LLM répond-il en English ou en chinois), réglez ONGRID_DEFAULT_LOCALE. Défaut en ; les valeurs valides matchent vos traductions UI (en, zh-CN, ja, …). Les canaux peuvent surcharger par canal ; les requêtes UI manuelles suivent Accept-Language.

5. Décider de la rétention Prometheus

Le compose retombe sur 90 jours / plafond 20 Go. Pour changer :

# /opt/ongrid/docker-compose.override.yml
services:
  prometheus:
    command:
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=30d
      - --storage.tsdb.retention.size=10GB
      - --web.enable-remote-write-receiver
      - --web.enable-lifecycle
      - --web.external-url=/prometheus/
      - --web.route-prefix=/prometheus/
      - --config.file=/etc/prometheus/prometheus.yml

sudo docker compose -f /opt/ongrid/docker-compose.yml --env-file /opt/ongrid/.env up -d prometheus

Pour la rétention Loki, éditez /opt/ongrid/loki-config.yaml et redémarrez le conteneur loki. Pour Tempo, éditez /opt/ongrid/tempo-config.yaml.

6. Décider de garder les Loki / Tempo intégrés

Si vous exécutez déjà des backends de logs/traces managés (Grafana Cloud, Honeycomb, Splunk, votre propre VictoriaLogs / VictoriaTraces…), vous pouvez :

• Garder les embarqués comme sink de données que l'agent interroge à travers (chemin le moins cher, pas d'infra en plus).
• Les remplacer en pointant l'agent vers l'URL managée via ONGRID_LOG_QUERY_URL / ONGRID_TRACE_QUERY_URL, et en reconfigurant le promtail / otelcol de chaque edge pour pousser là directement.

Pour un setup hybride (les edges poussent vers les deux), déposez un promtail.yaml / otelcol.yaml personnalisé dans /etc/ongrid-edge/ sur chaque edge et l'agent le récupérera.

Voir capacité logs et capacité traces.

7. Remplacer le cert TLS auto-signé

Pour un essai c'est OK. Pour la prod, le cert est dans /opt/ongrid/certs/ :

sudo cp fullchain.pem /opt/ongrid/certs/tls.crt
sudo cp privkey.pem   /opt/ongrid/certs/tls.key
sudo chmod 600        /opt/ongrid/certs/tls.key
sudo chmod 644        /opt/ongrid/certs/tls.crt
sudo docker compose -f /opt/ongrid/docker-compose.yml restart nginx

install.sh et upgrade.sh n'écrasent jamais les certs opérateur.

8. Sauvegarder /var/lib/ongrid et /opt/ongrid/.env

Tout ce qui est à état vit sous ces deux chemins :

• /opt/ongrid/.env — secrets (JWT, MySQL, mot de passe admin, clés d'embed).
• /var/lib/ongrid/mysql/ — tout l'état opérationnel. Tout ce que vous ne pouvez pas perdre vit ici : edges, règles d'alerte, incidents, configs de canaux, log d'audit, skills personnalisés, métadonnées de connaissances.
• /var/lib/ongrid/qdrant/ — embeddings vectoriels (reconstructibles depuis les docs sources, mais cher).
• /var/lib/ongrid/prometheus/, loki/, tempo/ — télémétrie ; sauvegardez seulement si vous avez besoin d'une longue rétention.

Un simple cron + rsync (ou restic) de ces deux racines vous donne la reprise après sinistre. Restaurer = arrêter la stack, remplacer les dirs, démarrer la stack.

9. Mettre en place un vrai compte admin

L'email de l'admin bootstrap est ce que vous (ou install.sh) avez mis dans ONGRID_ADMIN_EMAIL. Pour une vraie équipe :

1. Settings → Identity → Users → Invite user pour chaque opérateur réel.
2. Assignez à chacun un rôle : admin, user, ou viewer (RBAC ADR-022).
   • admin — contrôle complet.
   • user — peut chatter avec l'agent, voir les incidents, muter les alertes. Sac d'outils filtré à ClassSafe.
   • viewer — chat lecture seule (pas de skills write), incidents lecture seule.
3. Rétrogradez l'admin bootstrap si vous voulez, ou arrêtez juste de l'utiliser.

10. Déclencher le premier incident (test de fumée)

Forcez une des règles intégrées à partir. Le plus simple : arrêtez l'un de vos edges.

sudo systemctl stop ongrid-edge

En ONGRID_ALERT_EDGE_OFFLINE_THRESHOLD (défaut 90s) plus l'intervalle d'evaluator (défaut 5m), la règle edge_offline part. L'UI :

• Alerts — nouvel événement.
• Incidents — nouveau regroupement d'incident regroupant cet événement.
• Channels — votre canal câblé reçoit une carte.

Si vous avez monté un canal IM, répondez au bot avec « investigate this ». L'incident investigator tourne end-to-end et poste un rapport en retour.

Redémarrez l'edge :

sudo systemctl start ongrid-edge

L'incident passe automatiquement à mitigated quand la règle arrête de partir ; vous le marquez resolved depuis l'UI.

Et après

• Aperçu des canaux — câblez vos vrais canaux d'on-call.
• Capacité alertes — créez des règles personnalisées au-delà des 6 intégrées.
• Upgrade — quand v0.7.X+1 sort.
• Référence / env — chaque ajustable ONGRID_*.