Checkmk schickt mir Alarme aus dem Homelab schon länger per Telegram aufs Handy. Wenn unterwegs eine Warnung reinkommt, sehe ich zwar den betroffenen Host und den Check-Namen, musste für einen Blick in die Logs oder den Dienststatus bisher aber jedes Mal eine SSH-Verbindung zum Admin-Container öffnen. Deshalb habe ich im Oktober 2026 einen zweiten Telegram-Bot entworfen, der mit dem Checkmk-Bot in derselben Gruppe sitzt, Meldungen auf Zuruf einordnet und das System direkt lesend abfragt.
Warum zwei Bots in einer Gruppe aneinander vorbeireden
Die erste Hürde tauchte schon bei der Planung am 16. Oktober 2026 auf. Mein ursprünglicher Gedanke war simpel: Der Checkmk-Bot postet seine Meldung wie gewohnt in die gemeinsame Telegram-Gruppe, und der neue Assistenten-Bot liest dort einfach mit. In der Telegram Bot API funktioniert das so aber nicht, weil Bots in Gruppen die Nachrichten anderer Bots nicht sehen. Ob eine neuere Telegram-Funktion das inzwischen erlaubt, war vor dem Bau noch zu prüfen; ein zweiter Weg war sicherer.
Dazu kommt der Privacy-Modus von Telegram. Ist er eingeschaltet, bekommt ein Bot in einer Gruppe ohnehin nur Befehle mit Schrägstrich, direkte Erwähnungen per @Bot und Antworten auf seine eigenen Nachrichten zugestellt. Diesen Privacy-Modus will ich in meinen Gruppen ausdrücklich eingeschaltet lassen, damit der Dienst nur dann anspringt, wenn ich ihn direkt anspreche.
Gelöst habe ich das über einen zweiten Meldeweg im lokalen Netz. Wenn Checkmk auf dem Monitoring-Server einen Alarm auslöst, schickt das Benachrichtigungsskript die Nachricht wie bisher an die Telegram-API und sendet gleichzeitig eine Kopie samt Nachrichten-ID per HTTP im LAN an den neuen Bot-Dienst auf dem Admin-Container. Antwortest du später in Telegram auf eine Checkmk-Meldung (oder sprichst den Bot an), ordnet der Dienst deine Frage über diese Nachrichten-ID dem gespeicherten Alarmtext zu.
Für diesen zusätzlichen HTTP-Aufruf im Benachrichtigungsskript gilt eine strikte Vorgabe: Der eigentliche Alarmweg von Checkmk darf niemals vom Assistenten-Dienst abhängen. Das Skript arbeitet deshalb mit einem sehr kurzen Zeitlimit und verwirft Verbindungsfehler zum Admin-Container kommentarlos, damit jede Checkmk-Warnung auch dann auf dem Handy ankommt, wenn der Bot-Dienst gerade steht.
Der Dienst auf dem Admin-Container und spontane Gruppen
Auf dem Admin-Container (4 vCPU, 4 GB RAM) läuft bereits Claude Code 2.1.289 als Kommandozeilenwerkzeug mit Zugriff auf die Infrastruktur per SSH, WinRM und REST-API. Für die Telegram-Anbindung setze ich keinen schweren Framework-Bau davor, sondern einen kleinen systemd-Dienst unter dem bestehenden Benutzer des Admin-Containers. Er holt neue Nachrichten per Long Polling bei Telegram ab und ruft im Hintergrund claude -p auf.
Weil ein Chat-Zugang mit Systemrechten eine harte Grenze braucht, prüft der Dienst bei jeder eingehenden Nachricht zuerst die numerische Telegram-Benutzer-ID des Absenders. Nur meine feste ID wird durchgelassen. Alle anderen Absender weist der Dienst sofort ab; sie landen lediglich im systemd-Journal des Dienstes, ein eigenes Anfrageprotokoll führe ich dafür nicht.
Neben einem direkten Privatchat mit dem Bot und der festen Monitoring-Gruppe wollte ich die Möglichkeit haben, unterwegs spontan neue Arbeitsgruppen in Telegram anzulegen – etwa für ein einzelnes Netzwerkthema. Der Dienst unterscheidet die Gespräche anhand der chat_id (beziehungsweise der message_thread_id, falls in einer Gruppe die Foren-Themen aktiv sind) und führt jeden Faden über claude -p --resume als eigene Sitzung weiter:
# Aufrufschema des systemd-Dienstes je Gesprächsfaden
claude -p --resume "<sitzungs-id-des-fadens>" "<nachricht-aus-telegram>"Wenn ich in Telegram eine neue Gruppe erstelle und den Bot hinzufüge, nimmt der Dienst sie automatisch in seine Chat-Liste auf. Fügt ihn dagegen irgendein fremder Account zu einer Gruppe hinzu, verlässt der Dienst den Chat sofort per API-Aufruf leaveChat. Um die 4 vCPU und 4 GB RAM des Containers sowie das Nutzungskontingent zu schonen, sind folgende Grenzen fest eingeplant:
- Es laufen höchstens drei Anfragen gleichzeitig; kommt eine vierte dazu, gibt der Bot kurz Bescheid und reiht sie in die Warteschlange ein.
- Standardmäßig antwortet das kleinere Modell Sonnet, während Opus nur bei Bedarf über den Befehl
/tiefgenutzt wird. - Je Anfrage gilt eine feste Höchstzahl an Arbeitsschritten sowie ein Tageslimit für die Gesamtzahl der Anfragen.
- Checkmk-Meldungen laufen weiterhin ausschließlich in die Hauptgruppe für das Monitoring ein, damit Nebenchats übersichtlich bleiben.
Rechteprofil, Freigabe per Knopf und das Backup-Fenster
Wenn der Bot eine Meldung untersucht, darf er das System auf Zuruf live prüfen. Er liest Dienstzustände, Logdateien, Daten aus der Checkmk-REST-API sowie die Homelab-Dokumentation und führt lesende SSH-Abfragen aus, ohne dass ich dafür etwas freigeben muss. Sobald es ums Ändern oder Beheben geht, greifen exakt dieselben Regeln wie bei meiner Arbeit im Terminal.
| Stufe | Was darunter fällt | Ablauf im Telegram-Chat | Ausführende Instanz |
|---|---|---|---|
| Lesende Prüfung | Dienststatus, Logs, Checkmk-REST, Doku, lesendes SSH | Direkt auf Zuruf (@Bot, Befehl oder Antwort) | Assistent über den Bot-Dienst |
| Standard- & Notfalländerung | Dokumentierte Routineeingriffe innerhalb der Freigabegrenzen | Ohne Rückfrage, mit Sperre und Eintrag im Änderungslog | Assistent über den Bot-Dienst |
| Normale Änderung | Eingriffe außerhalb der Standardliste | Vorschlag mit Befehl, Ziel und Rückfall; Knöpfe „Ja“ / „Nein“ | Assistent nach Knopfdruck |
| Vom Schutzmechanismus abgelehnt | Neustarts, Updates oder gesperrte Schritte | Vorschau per --zeigen; Knopf „Skript ausführen“ | Bot-Dienst selbst (ohne KI) |
Bei einer normalen Änderung schickt der Bot seinen Vorschlag in den Chat, nennt den genauen Befehl, das Zielsystem und den Rückfallweg und blendet darunter die Inline-Knöpfe „Ja“ und „Nein“ ein. Noch strenger ist der Ablauf, wenn der lokale Schutzmechanismus auf dem Container einen Schritt im automatischen Lauf ablehnt: Dann legt der Assistent wie im Terminal ein vorbereitetes Skript im Ordner für manuelle Eingriffe ab. Der Bot postet den Skriptkopf samt der Vorschau-Ausgabe (--zeigen) in den Chat und zeigt darunter den Knopf „Skript ausführen“.
Drücke ich diesen Knopf, startet der Dienst des Bots das Skript direkt auf dem System – der KI-Assistent ist an der Ausführung selbst nicht mehr beteiligt. Der Dienst führt nur zuvor geprüfte Skripte aus, der Knopf verfällt nach kurzer Zeit und gilt nur für mich. Zwischen 02:00 und 04:00 Uhr (dem nächtlichen Backup-Fenster) sowie während eingetragener Wartungen im Betriebskalender sperrt der Dienst den Knopf komplett. Nach dem Lauf schickt der Dienst die letzte Statuszeile (ERGEBNIS: …) zurück in den Chat und schreibt einen Vermerk mit dem Chat-Namen ins zentrale Änderungslog.
Weil ich gleichzeitig am Terminal und in mehreren Telegram-Gruppen arbeiten kann, müssen sich parallele Sitzungen sauber gegeneinander sperren. Jede Sperre in der internen Verwaltungsdatenbank bekommt dafür ein Herkunftsfeld, das den auslösenden Ort nennt – etwa Terminal, Telegram: Privatchat oder den Namen der jeweiligen Telegram-Gruppe. Will ich in einer zweiten Gruppe denselben Arbeitsbereich anfassen, bricht der Lauf mit Exit-Code 3 ab und nennt mir direkt den Chat, der die Sperre gerade hält.
Notschalter, unverschlüsselter Chat und offene Punkte vor dem Start
Normale Telegram-Chats und Bot-Unterhaltungen sind nicht Ende-zu-Ende-verschlüsselt. Token, private Schlüssel, Wiederherstellungscodes und vollständige Konfigurationsdateien mit Zugangsdaten haben im Chat deshalb nichts verloren und werden vor der Ausgabe herausgefiltert. Für normale Kennwörter aus dem Passwort-Tresor habe ich am 21. Oktober 2026 eine pragmatische Ausnahmeregel festgelegt: Sie dürfen nur nach einer ausdrücklichen Einzelfreigabe im Chat angezeigt werden, und unmittelbar danach legt das System automatisch eine Aufgabe zur Rotation dieses Kennworts an.
Falls sich ein Lauf festfrisst oder ich den Schreibzugriff unterwegs sofort kappen will, gibt es einen zweistufigen Notschalter. Sende ich im Chat den Befehl /stopp oder lege auf dem Admin-Container eine bestimmte Schalterdatei an, fällt der Bot augenblicklich in den reinen Lesemodus zurück. Er erklärt dann weiter Alarme und liest Logs, verweigert aber jede Änderung und jedes Skript. Den Bot-Dienst selbst nimmt Checkmk als eigenen Check in die Überwachung auf, selbstverständlich getrennt vom eigentlichen Alarmversand.
Ich habe mich dagegen entschieden, den Bot nicht erst in einer reinen Lesephase mitlaufen zu lassen; er geht nach dem Gesamttest aller neun Ausbauschritte komplett in Betrieb. Vor dem Bau des Dienst-Grundgerüsts ist nur noch ein Punkt aus meinem Fragenkatalog endgültig festzuzurren: ob jede Antwortkette und jedes Foren-Thema innerhalb einer Gruppe dauerhaft eine eigene Sitzung behält oder ob eine Gruppe sich standardmäßig einen gemeinsamen Kontext teilt. Bis zur Entscheidung gilt die Empfehlung: eine Sitzung je Thema.
Schreibe einen Kommentar