Ein Signal, bevor etwas ausfällt.

Site und Regeln definieren

Lege für eine neue Site config/sites/lab/ mit site.yaml, rules.yaml, notifications.yaml und knowledge.md an. Ordnername und id müssen übereinstimmen. Site- und Source-Kennungen erlauben Kleinbuchstaben, Ziffern, _ und -, jeweils bis 64 Zeichen.

id: lab
name: Beispiel-Site
timezone: Europe/Berlin
sources: [node1]
maintenance_states: [planned_maintenance]

rules:
  - id: root_full_warning
    source: node1
    path: host.root_used_percent
    operator: greater_than
    value: 75
    severity: warning
    category: storage
  - id: root_full_critical
    source: node1
    path: host.root_used_percent
    operator: greater_than
    value: 90
    severity: critical
    category: storage

# Beispiel-Site

- node1 ist ein Linux-Host für technische Infrastrukturmeldungen.
- Wartungen werden vorab angekündigt.

Trage in knowledge.md nur zutreffende technische Fakten ein, keine Schlüssel oder personenbezogenen Inhalte. Für eine bestehende Site ergänzt du die Source in deren site.yaml unter sources und passt Regeln bei Bedarf an. Belasse die Liste in der Inline-Form sources: [node1, node2], die das Provisionierungsskript erwartet. Gemeinsame Intervalle und Schwellen stehen in config/common.yaml und gelten Site-übergreifend.

E-Mail-Routen festlegen

In dieser Phase gibt es nur E-Mail. Ersetze die Beispieladresse durch den tatsächlichen Empfänger. Ein Alarm wird nur zugestellt, wenn seine Schwere zu einer Route passt.

channels:
  ops_email:
    type: email
    recipients: [admin@example.invalid]
routes:
  - match: {severity: warning}
    channels: [ops_email]
  - match: {severity: critical}
    channels: [ops_email]

Regelpfade müssen in Petrels Metrik-Allowlist stehen. Fehlt ein Messwert im Bericht, wird seine Regel nicht ausgewertet. greater_than bedeutet strikt größer als der Grenzwert.

Konfiguration prüfen und deployen

Führe die Befehle im Wurzelverzeichnis des Petrel-Repositories aus. Richte .venv bei Bedarf einmalig ein, prüfe die Konfiguration und versioniere die Dateien vor dem Deploy. Das Deployskript braucht den Codex-SSH-Key und den read-only 1Password-Vault AI. Es archiviert den vorherigen Release und erhält vorhandene Source-Schlüssel.

python3 -m venv .venv
.venv/bin/pip install -e 'server[test]'

deploy-manual-rocky.sh aktualisiert nur diese Webseite. Für Sites, Regeln und E-Mail-Routen verwendest du deploy-rocky.sh.

Source provisionieren und API neu laden

Erst nach dem Konfigurations-Deploy kennt Rocky die neue Site und Source. Sichere zuvor die geschützte Runtime-Umgebung außerhalb des Quell- und Release-Archivs. Der zweite Befehl erzeugt ihren eigenen Schlüssel oder verwendet ihn beim erneuten Aufruf wieder. Er druckt keinen Schlüssel aus und erstellt nur die API neu, damit sie die geänderte Umgebung liest.

Das Beispiel setzt WireGuard-Zugriff auf Rocky voraus. Niemals Schlüssel in URLs, Shell-History, Git oder das Handbuch kopieren.

Schlüssel übertragen und Collector installieren

Dieses Beispiel verwendet auf dem Zielhost den SSH-Account ai mit sudo. Ersetze zielhost durch seinen erreichbaren Namen. scp -3 überträgt die geschützte Datei über deinen Admin-Rechner, ohne ihren Inhalt anzuzeigen.

Auf einem neuen Host legst du die Konfiguration vor dem Installer an. Er erkennt die vorhandenen Dateien und fragt den Schlüssel nicht am Terminal ab. Überschreibe so keine bereits bestehende Petrel-Konfiguration.

id petrel >/dev/null 2>&1 || sudo useradd --system --no-create-home --shell /usr/sbin/nologin petrel
sudo install -d -m 0750 -o root -g petrel /etc/petrel
sudo install -m 0400 -o petrel -g petrel /home/ai/petrel-secret /etc/petrel/secret
rm /home/ai/petrel-secret
sudo tee /etc/petrel/config.yaml >/dev/null <<'YAML'
server_url: https://petrel.app.vieten.cloud
site: lab
source: node1
secret_file: /etc/petrel/secret
queue_dir: /var/lib/petrel/queue
zpool: []
ups: []
tcp: []
metrics_files: []
docker: []
smart: []
pve_vms: []
check_updates: false
YAML
sudo chmod 0644 /etc/petrel/config.yaml
wget -qO- https://petrel.app.vieten.cloud/download/install.sh | sudo bash

Für einen Host ohne ai-Account verwende einen eigenen administrativen Account mit sudo und passe den Zielpfad an. Der Collector läuft danach als gesperrter Nutzer petrel.

Ersten Bericht und Timer verifizieren

Der Installer startet einen Heartbeat. Auf dem Zielhost müssen beide Timer aktiv sein. Die lesende Datenbankabfrage zeigt den Zeitpunkt des letzten angenommenen Berichts je Source. Prüfe, ob eine aktuelle Zeile für lab/node1 erscheint; Schlüssel werden dabei nicht ausgegeben.