Odoo überwachen: Verfügbarkeit, Logs, Warnungen
Kurz gesagt
Prüfen Sie zuerst die Erreichbarkeit der Anmeldung, die wegen fehlender Worker abgelehnten Anfragen und den Arbeitsspeicher; diese Reihenfolge ist eine Priorität der Redaktion, keine zugesagte Vorwarnung vor einem Ausfall. Auf Odoo Online und Odoo.sh trägt Odoo den Serverbetrieb und zeigt den Plattformzustand auf status.odoo.com; Odoo.sh bietet je Zweig die Ansichten Monitor, Logs und Backups, im Produktionszweig nur für Admins, Odoo Online die Admin-Aktivitätsprotokolle im Datenbank-Manager und über die JSON-2-API. Auf eigener Installation richten Sie alle Prüfungen selbst ein. Feste Schwellen nennt die Dokumentation 20.0 nur stellenweise; die übrigen Werte der Schwellentabelle sind Empfehlung der Redaktion.
Das Wichtigste
- Odoo.sh zeigt je Zweig im Reiter Monitor Arbeitsspeicher, CPU, Speicher, Anfragen, Antwortzeit und Mail-Zahlen.
- Im Produktionszweig von Odoo.sh sehen nur Admins Monitor, Logs und Backups; den Status sehen alle Rollen.
- Als Vorgabe je Worker gelten auf eigener Installation im Mehrprozess-Betrieb 2048 MiB weicher und 2560 MiB harter virtueller Speicher (Dokumentation 20.0); die Speicherkurve im Odoo.sh-Monitor zeigt dagegen den Verbrauch des Containers, nicht je Worker.
- Die Dokumentation hält die CPU-Last im Beispiel mit vier Kernen und acht Workern zwischen 7 und 7,5.
- Für Odoo Online nennt die Dokumentation kein Serverprotokoll; einsehbar sind die Admin-Aktivitätsprotokolle im Datenbank-Manager und über die JSON-2-API.
- Die Cloud-Hosting-SLA nennt 99,9 Prozent monatliche Verfügbarkeit, ausdrücklich ohne rechtlich bindende Zusage.
Verfügbarkeit, Protokolle und Warnungen sind bei Odoo drei getrennte Aufgaben, und wer sie trägt, hängt vom Hostingmodell ab. Auf Odoo Online und Odoo.sh betreibt Odoo die Server, und Sie arbeiten mit den Ansichten der Plattform. Auf einer eigenen Installation richten Sie dieselbe Liste an Kennzahlen in Ihrem Server-Monitoring ein; ohne ein solches Monitoring fällt eine Störung erst auf, wenn sich ein Benutzer meldet. Die Angaben gelten für Odoo 20.0, die Version, die im September 2026 erschienen ist.
Wer welche Kennzahl sieht
| Hostingmodell | Was Sie selbst sehen | Wer den Server betreibt |
|---|---|---|
| Odoo Online (SaaS) | Statusseite status.odoo.com mit getrennten Komponenten; Admin-Aktivitätsprotokolle im Datenbank-Manager, auch über die JSON-2-API abrufbar | Odoo, mit einer monatlichen Verfügbarkeitszusage von 99,9 Prozent ohne geplante Wartung |
| Odoo.sh (PaaS) | je Zweig die Reiter Monitor, Logs (Protokolle) und Backups (Sicherungen); Status für alle Rollen | Odoo für die Server, Ihr Team für den eigenen Code |
| Eigene Installation (On-Premise) | Erreichbarkeit, CPU-Last, Arbeitsspeicher je Worker, Speicherplatz und die Protokolldateien | niemand außer Ihnen |
Die Zusage nennt 99,9 Prozent Verfügbarkeit im Monat ohne geplante Wartung, das entspricht höchstens 45 Minuten ungeplanter Ausfallzeit; sie gilt laut ihren Bedingungen für die Plattform als Ganzes, und einzelne Datenbanken können durch Handlungen des Kunden oder durch Anpassungen ausfallen. Die genannten Ziele sind dort ausdrücklich nicht rechtlich bindend. Geplante Wartungen kündigt Odoo per E-Mail oder über den Feed @OdooStatus an. In Odoo.sh hängt der Zugriff an der Rolle: Im Produktionszweig sind Monitor, Logs, Backups, Shell und Editor der Rolle Admin vorbehalten, den Status sieht jede Rolle. Wie die Zweige aufgebaut sind und welche Aufgaben beim Kunden bleiben, steht unter Leistungsumfang von Odoo.sh.
Diese Kennzahlen und Schwellen
Die folgende Liste ist die kleinste Menge, mit der sich ein Ausfall von einem Engpass unterscheiden lässt. Schwellen mit Quellenangabe stammen aus der Dokumentation 20.0; alle übrigen sind Empfehlungen der Redaktion und ersetzen keine eigene Messung im Normalbetrieb.
| Kennzahl | Wo ablesen | Warnung | Eskalation |
|---|---|---|---|
| Anmeldung und Live-Chat-Verbindung | eigener Prüfer außerhalb von Odoo, alle 1 bis 5 Minuten: die Anmeldung und der Pfad /websocket/ über den öffentlichen Namen, nicht der Port des LiveChat-Workers (im nginx-Beispiel der Dokumentation 127.0.0.1:8072) |
zwei Fehlversuche in Folge | zehn Minuten ohne Antwort: Statusseite prüfen, sonst Dienst und Datenbank auf dem Server |
| Build-Status (Odoo.sh) | Builds-Ansicht, Zelle je Zweig und Build | nahezu erfolgreich (almost successful, gelb): Warnungen, aber keine Fehler | fehlgeschlagen (failed, rot) im Produktionszweig: Odoo.sh lädt weiter die letzte erfolgreiche Revision; Log des fehlgeschlagenen Updates lesen |
| CPU-Last (eigener Server) | Server-Monitoring, Lastmittel über 5 Minuten | über 7,5; die Dokumentation nennt für 4 Kerne und 8 Worker den Zielbereich 7 bis 7,5 | zwei Messintervalle über dem Doppelten der Prozessorkerne bei gleichzeitig steigender Antwortzeit |
| Arbeitsspeicher | Odoo.sh: Speicherkurve im Monitor (Verbrauch des Containers aus Odoo-Workern und Containerprozessen, nicht je Worker); eigene Installation: virtueller Speicher je Odoo-Worker im Mehrprozess-Betrieb | eigene Installation: 2048 MiB virtueller Speicher je Worker, die Vorgabe von limit_memory_soft: der Worker wird am Ende der laufenden Anfrage ersetzt; für Odoo.sh nennt die Dokumentation keine Grenze je Worker | eigene Installation: 2560 MiB virtueller Speicher je Worker, die Vorgabe von limit_memory_hard: der Worker wird sofort beendet |
| Gleichzeitige und abgelehnte Anfragen (Odoo.sh) | Monitor: Concurrent requests (max) und Requests (HTTP rate limited) | die Spitze erreicht die Zahl der Datenbank-Worker; ein Wert über 0 bei HTTP rate limited | anhaltend abgelehnte Anfragen: Worker über den Account Manager zubuchen |
| Antwortzeit (Odoo.sh) | Monitor: Average Response time in Millisekunden | das Dreifache des eigenen Normalwerts, im Beispiel 300 auf 900 Millisekunden (eigene Empfehlung) | bleibt erhöht: langsame Abfragen und offene Anfragen suchen |
| Fehlerhafte Anfragen (Odoo.sh) | Monitor: HTTP errors | steigende Kurve über das Tagesrauschen hinaus | odoo.log auf Tracebacks prüfen und den Fehler 500 eingrenzen |
| Speicherplatz | Odoo.sh: Monitor (Storage) und Einstellungen (Produktionsdatenbank-Größe); eigene Installation: Dateisystem | unter 20 Prozent frei (eigene Empfehlung); Odoo Online kann Konten ab mehr als 100 GB Speicherverbrauch je Konto prüfen | Datenbank und Dateispeicher getrennt untersuchen, bevor der Plan angepasst wird |
| Fehlgeschlagene Anmeldungen | Protokolle der eigenen Installation und von Odoo.sh, Zeile Login failed for db … login … from Adresse | zehn Versuche einer Adresse in 60 Sekunden, das Beispiel der Dokumentation für eine Sperre | Adresse sperren und die Ratenbegrenzung im Proxy prüfen |
| Nicht zugestellte Mails | Odoo.sh: Monitor, Mails (nicht zugestellte Mails, ausgehend und eingehend); bei eigenem Mailversand: Protokoll des Postausgangsservers | jede Zunahme gegenüber dem Vortag | Absenderdomain und Postausgangsserver prüfen, siehe E-Mail-Zustellbarkeit |
| Geplante Aktionen | Odoo.sh: Monitor (CPU cron/mail) und Protokolle; eigene Installation: Zahl und Auslastung der Cron-Worker (max_cron_threads, Vorgabe 2) |
eine Aktion läuft nicht mehr; Odoo.sh führt geplante Aktionen nach besten Kräften aus und garantiert keinen genauen Laufzeitpunkt, und erwarten Sie nicht, dass eine Aktion öfter als alle fünf Minuten läuft | Aktionen in kleine Stapel teilen, nach jedem Stapel festschreiben und idempotent bauen, damit ein Lauf mehr als erwartet keine Nebenwirkungen hat; Zeitüberschreitungen im Protokoll prüfen |
Drei Eigenschaften des Mehrprozess-Betriebs gehören zur Tabelle. Die Dokumentation beschreibt einen Prozesswächter, der die Ressourcennutzung überwacht und fehlerhafte Worker beendet oder neu startet; suchen Sie solche Abbrüche im Protokoll, nicht im Backend. Und die Vorgabewerte der Kommandozeilenhilfe, die einen Worker begrenzen und recyceln (8196 Anfragen bis zum Neustart, 2048 und 2560 MiB virtueller Speicher je Worker, 60 CPU-Sekunden und 120 Sekunden Wanduhrzeit je Anfrage), gehören zum Mehrprozess-Betrieb mit --workers ungleich 0. Die Cron-Optionen stehen daneben: max_cron_threads (Vorgabe 2) gilt in beiden Betriebsarten, weil die Cron-Worker laut derselben Seite Threads im Mehrthread-Betrieb und Prozesse im Mehrprozess-Betrieb sind; im Mehrprozess-Betrieb kommen sie zu den HTTP-Workern hinzu. Das Konfigurationsbeispiel der Dokumentation setzt für diesen Server teils niedrigere, teils höhere Grenzen als die Vorgabewerte. Der Live-Chat gehört ebenfalls dazu: Im Mehrprozess-Betrieb startet Odoo dafür einen eigenen Worker, der auf dem Port der Option --gevent-port lauscht, und die Dokumentation verlangt einen Proxy, der alle Anfragen mit dem Pfad /websocket/ an ihn weiterleitet; prüfen Sie deshalb den öffentlichen Pfad und nicht diesen Port.
Ein Beispiel mit Zahlen
Die Dokumentation rechnet ein Beispiel durch, das sich als Ausgangspunkt für eigene Schwellen eignet: einen Server mit vier Prozessorkernen und 60 gleichzeitigen Nutzern. Die Zahl der Prozesse folgt der Faustregel Prozessorkerne mal zwei plus eins, und ein Worker trägt rund sechs gleichzeitige Nutzer; daraus ergeben sich acht Worker für HTTP plus einer für Cron, also neun Prozesse. Beim Arbeitsspeicher setzt die Seite 80 Prozent leichte Anfragen zu rund 150 MB und 20 Prozent schwere zu rund 1 GB je Worker an, zusammen rund 3 GB. Als Ziel für die CPU-Last nennt sie einen Wert zwischen 7 und 7,5, gemessen mit einem Monitoring-System.
Für denselben Server nennt das Konfigurationsbeispiel 600 MB weich und 1,6 GB hart je Worker und 8192 Anfragen bis zum Neustart, also weniger als die Vorgabewerte der Kommandozeilenhilfe (2048 und 2560 MiB sowie 8196), sowie 600 CPU-Sekunden und 1200 Sekunden Wanduhrzeit je Anfrage, also mehr als deren Vorgaben (60 und 120 Sekunden), und einen Cron-Worker. Messen Sie mit Ihren eigenen Werten und prüfen Sie, ob eine harte Grenze über dem liegt, was ein einzelner Vorgang bei Ihnen braucht; sonst beendet der Prozesswächter den Worker sofort, ohne das Ende der laufenden Anfrage abzuwarten, und die Anfrage bricht ab.
Protokolle: was wo liegt
Auf einem eigenen Server schreiben Sie die Ausgabe mit --logfile in eine Datei statt auf die Standardfehlerausgabe; auf Unix-Systemen darf ein externes Rotationsprogramm die Datei verwalten, weil Odoo sie nach dem Austausch neu öffnet. Die Stufe steuern Sie mit --log-level, einzelne Bereiche mit --log-handler (zum Beispiel odoo.sql_db:DEBUG); --log-db schreibt zusätzlich in das Modell ir.logging der genannten Datenbank, und für --syslog verweist die Seite darauf, ab 20.0 --log-config zu verwenden. Lesen Sie zuerst die Zeilen WARNING und ERROR, dann die Anmeldezeilen. Die Zeile einer fehlgeschlagenen Anmeldung nennt Datenbank, Benutzername und Quelladresse, die einer erfolgreichen Anmeldung dieselben Angaben.
In Odoo.sh öffnen Sie den Reiter Logs je Zweig. Er zeigt unter anderem odoo.log (laufender Server), update.log (Modulaktualisierungen), install.log (Installation), pg_slow_queries.log (auffällig lange SQL-Abfragen), sh_webshell.log und sh_editor.log (Aktionen in Shell und Editor) sowie neutralize.log (Neutralisierung, nur Staging). Neue Zeilen erscheinen automatisch; den Abruf können Sie anhalten, sonst endet er nach fünf Minuten, und die Taste zum Fortsetzen startet ihn erneut. Die Dateien liegen im Container unter ~/logs; in der Shell helfen lnav ~/logs/odoo.log, grep und für den Speicher ncdu. Die Produktions-Shell ist rot gekennzeichnet, weil Änderungen dort die Produktionsdatenbank betreffen. Technische Protokolle stehen in UTC; stellen Sie dasselbe in Ihrem Monitoring-Werkzeug ein, sonst passen Kurve und Zeile zeitlich nicht zusammen.
Für Odoo Online nennt die Dokumentation als einsehbares Protokoll die Admin-Aktivitätsprotokolle: Aktionen von Odoo-Mitarbeitenden und des Datenbank-Administrators, abrufbar im Datenbank-Manager und über die JSON-2-API, dort höchstens einmal alle fünf Minuten. Serverprotokolle sind an dieser Stelle nicht beschrieben.
Warnungen einrichten
Ein Alarm muss einen Weg nehmen, der ohne die überwachte Datenbank funktioniert. Prüfen Sie deshalb von außen und lassen Sie die Meldung über einen Dienst außerhalb von Odoo ausgeben. Für Odoo Online und Odoo.sh kündigt Odoo geplante Wartungen laut den Bedingungen der Verfügbarkeitszusage per E-Mail oder über den Feed @OdooStatus an; nehmen Sie diesen Kanal in Ihre Warnkette auf, damit geplante Wartungen nicht als Störung durchschlagen.
Für fehlgeschlagene Anmeldungen liefert die Dokumentation eine fertige Vorlage: ein Filter auf die Zeile mit der fehlgeschlagenen Anmeldung und eine Sperre, die bei zehn Versuchen einer Adresse innerhalb einer Minute 15 Minuten gilt. Übernehmen Sie solche Werte nicht blind, sondern prüfen Sie die Zeitzone des Protokolls; die Vorlage nennt das ausdrücklich als anzupassenden Punkt.
Typische Fehler
- Nur die Anmeldeseite geprüft. Der Pfad
/websocket/bleibt ungetestet, und der Live-Chat kann ausfallen, während die Prüfung weiter grün meldet. - Alarm aus der Datenbank heraus. Läuft die Warnung als geplante Aktion in Odoo, verstummt sie mit dem Dienst, den sie melden soll.
- Kein Normalwert. Ohne eigene Messung über eine Woche ist nicht zu erkennen, ob eine Antwortzeit von 900 Millisekunden für Ihren Betrieb viel ist.
- Arbeitsspeicher und Protokoll getrennt betrachtet. Wer nur die Speicherkurve ansieht, bemerkt einen Neustart des Workers nicht; den Hinweis dazu liefert das Protokoll.
- Log-Aufbewahrung ungeregelt. Nach einer Störung ist die entscheidende Zeile durch Rotation verschwunden, und die Ursache bleibt offen.
- Rolle nicht bedacht. Wer nur die Rolle Developer hat, sieht im Produktionszweig von Odoo.sh weder Monitor noch Logs.
So gehen Sie vor
- Messen Sie eine Woche lang den Normalbetrieb: Antwortzeit, Spitzen bei den gleichzeitigen Anfragen, Arbeitsspeicher je Worker und Speicherverbrauch. Notieren Sie die Werte mit Datum.
- Richten Sie einen Prüfer außerhalb von Odoo ein, der über den öffentlichen Namen die Anmeldung einschließlich eines angemeldeten Vorgangs und den Pfad
/websocket/testet. - Setzen Sie die Schwellen aus Ihrer Messung und tragen Sie in jede Warnung ein, was zu tun ist: Statusseite prüfen, Protokoll öffnen, Worker zubuchen.
- Bestimmen Sie für jede Warnung eine Person und einen Kanal, der nicht von Odoo abhängt.
- Prüfen Sie den Ablauf nach zwei Wochen: Wie viele Warnungen waren echte Störungen, wie viele Rauschen? Passen Sie die Schwellen entsprechend an und wiederholen Sie die Messung nach jeder größeren Änderung.
Die Verfügbarkeitszusage, der Aufbau der Zweige und die Wiederherstellung hängen zusammen; für die Sicherungsseite siehe Backup-Strategie für Odoo, für Änderungen an Datensätzen Protokolle in Odoo.