|Service alert|2024-06-27 00:00:09|SERVICE ALERT|proxmox.home|Systemd Service Summary|HARD (CRITICAL)|Total: 151, Disabled: 5, Failed: 1, 1 service reloading (pveproxy)CRIT|
Habe schon versucht mittels Service-Monitoring-Regel für den Host zu unterbinden:
Systemd services summary
|Tolerance period for ‘activating’ state: |Do not impose levels, always be OK
|Tolderance period for ‘reloading’ state: |Do not impose levels, always be OK
allerdings meldet er weiterhin jede Nacht, insbesondere nervig da ich notifications via Telegram aktiv habe und das natürlich in der Nacht nur bei wichtigen Sachen haben will
Entweder ich habe die richtige Regel noch nicht gefunden oder ich hab n Brett vorm Kopf und finde meinen eigenen Fehler nicht
Wäre um jede Hilfe bzw. Unterstützung dankbar, da ich noch nicht so tief drin stecke.
Ich würde immer erst gucken, ob CheckMK nicht genau seinen Dienst verrichtet und dich auf ein Problem hinweist. Die Devise ist: Ursachenfindung und nicht Symptombekämpfung!
Gruß
Simon
EDIT: Meine Vermutung: Du hast vielleicht mal versucht Letsencrypt Zertifikate einzurichten und PVE probiert alle 24 Stunden sich ein Zertifikat zu besorgen, was aber fehlschlägt
es stimmt, es liegt an den Zertifikaten, da diese jede nacht mit einer erneuten Zuweisung den pveproxy neustarten lassen:
Jun 27 21:10:43 proxmox systemd[1]: Reloaded pveproxy.service - PVE API Proxy Server.
Jun 27 21:10:43 proxmox pveproxy[1213]: Using ‘/etc/pve/local/pveproxy-ssl.pem’ as certificate for the web in>
Jun 27 21:10:43 proxmox pveproxy[1213]: restarting server
Die Zertifikate sind auch immer gültig, aber laut Proxmox ist das Verhalten des Neustarts vom pveproxy bei eigenen Zertifikaten normal.
Aus dem Grund wollte ich auch nur die Meldung des reloads unterdrücken, da selbst kein Fehler am Service vorliegt.
Hatte jetzt zusätzlich noch eine redundante notofication rule gefunden, die ich mal eingerichtet hatte, habe, welche sich genau in der Zeit “aktiviert”, vielleicht ist das Thema damit ja auch durch.
Du kannst mit der Regel " Notification period for services" definieren in welchem Zeitraum Notifications für einen Service verschickt werden. In der Anzeige wird das trotzdem Critical, aber es werden halt keine EMails/SMS verschickt.
Ich habe mal bei mir geschaut und bekomme das reload tatsächlich auch zu sehen, allerdings dank Softstate alarmiert da noch nichts, sondern erst nach 3 Versuchen (check attempts) und das ganze dauert ja nur ein paar Sekunden
habs jetzt mal für den gesamten Service eingerichtet, aber generell sollte ich mich mal mehr mit den Regeln tiefer einarbeiten, da hab ich bisher wohl doch nur an der Oberfläche gekratzt
Wenn du noch gar keine Regel in die Richtung hast, dann ist meine Empfehlung bei Conditions einfach gar nichts einzutragen und auch beim Ordner “Main” zu wählen. Somit gilt das für sämtliche überwachte Services und bewahrt dich vor jede Menge Fehlalarmen, solltest du später mal mit Notifications arbeiten.
Neustart kam wieder, aber kein Servicealarm diesmal.
Es kam zwar auch schon ab und an mal vor das 1-2 Tage ruhe waren, aber diesmal glaub ich eher an die Anpassung der Schwellwerte
In Sachen was Du an solchen Stelle als Service einträgst: Das muss immer der Name des Service sein um den es geht. In diesem Fall also “Systemd Service Summary”. Es gibt ja keinen Serivce mit dem Namen pveproxy. Das steht ja nur in den Details von Systemd.
Bei den Notifications gibt es auch noch eine andere gut geeignete Regel statt die Soft States zu verwenden: “Delay service notifications” bzw. “Delay host notifications”. Damit kannst Du Notfications verzögern. Wenn der Service/Host in der Zwischenzeit wieder OK wird, wird die Notification nicht gesendet. Das habe ich per Default mit 5 Min für alles eingerichtet und für Dienste diese lange Restarts benötigen auch mal länger. Nachteil davon (wie auch von den Soft States): Es ist nicht Uhrzeit basiert, was man ja vielleicht haben möchte.
