ZFS: automatische Warnung, wenn Dateisystem volläuft?

[whiterabbit]

Hallo.
Bei ZFS (copy on write) ist es ja besonders kritisch, wenn das Dateisystem volläuft. Ok, ab 80% wird's langsam -- aber wenn man das nicht mitbekommt und das Dateisystem wirklich komplett bis 100% vollgelaufen ist, hat man ein Problem, oder? Daher die Frage: Gibt es vom Proxmox-Server eine automatische Warnung, wenn dein ZFS-Filesystem sein Limit erreicht hat?
Danke.

 

[LnxBil]

Bis 100% kann es nicht voll laufen. Ich hatte immer bei 93% schon "cannot write".

Im Hypervisor selbst gibt es keine Überwachung, macht ja auch kein Sinn das System vom System aus zu überwachen, dafür verwendet man externes Monitoring. Es gibt hier Software wie Sand am Meer: Nagios, Icinga, CheckMK, Zabbix, etc.

 

[fireon]

Ich darf hier CheckMK empfehlen. Sehr einfach von der Bedienung.

 

[whiterabbit]

checkMK kenne ich ... aber wenn's nur das filesystem ist, kann man doch durchaus auch den hypervisor selbst nachsehen lassen? Was spricht dagegen? Bei anderen Dingen ist schon klar, dass das Monitor-Programm von außen drauf schauen muss ... aber der Füllstand des Dateisystems? Warum sollte das nicht lokal abgefragt werden?

 

[fireon]

Wenns nur um das eine geht... Webin hat auch ne kleine Überwachung dabei, haben wir bei unseren Proxmox Backup und NAS/Storageservern drauf.

 

[LnxBil]

checkMK kenne ich ... aber wenn's nur das filesystem ist, kann man doch durchaus auch den hypervisor selbst nachsehen lassen? Was spricht dagegen? Bei anderen Dingen ist schon klar, dass das Monitor-Programm von außen drauf schauen muss ... aber der Füllstand des Dateisystems? Warum sollte das nicht lokal abgefragt werden?

Naja, man findet immer Dinge, die der Hypervisor ja auch noch machen könnte ...
- Mails verschicken wenn Updates da sind
- Mails verschicken wenn die Last zu hoch ist
- Mails verschicken wenn zu viel geswapped wird (pgin/pgout)
- Mails verschicken wenn die Smart-Werte schlechter werden
- Mails verschicken wenn es draußen regnet :-D
- doch keine Mails verschicken, sondern ein SNMP-Trap .... oder sonstwas
usw.

Wenn man einmal anfängt was einzubauen muss man entweder alles einbauen oder sich Diskussionen stellen wie "warum gibt es das und das nicht?". Das einfachste ist "nichts" einzubauen, sondern es komplett auf extern zu verlagern. Ich kann es verstehen.

 

[whiterabbit]

Das einfachste ist "nichts" einzubauen, sondern es komplett auf extern zu verlagern. I

Ja, hast wahrscheinlich Recht. Ich habe ein check_MK auf einem RasPi laufen -- ja ich weiß: das mag im Enterprise-Umfeld geradezu lächerlich klingen, zieht dafür aber extrem wenig zusätzliche Energie. Und es funktioniert wirklich ganz gut. Da könnte ich den Hypervisor mit aufnehmen und den ZFS-Pool überwachen lassen.... und hätte die ganzen anderen Dinge, die du genannt hast, gleich mit an Bord.

 

[LnxBil]

ja ich weiß: das mag im Enterprise-Umfeld geradezu lächerlich klingen

Mach zwei draus, dann ist es nicht mehr lächerlich, sondern hochverfügbar :-D
Argumente für den Einsatz eines PIs sind nicht von der Hand zu weisen, gerade wegen des Energieverbrauchs.

 

[whiterabbit]

OT: Was mir bei check_MK nicht klar ist: warum schickt der nicht ootb/per default eMails im Fehlerfall? Gilt eMail als nicht zuverlässig genug?

 

[fireon]

OT: Was mir bei check_MK nicht klar ist: warum schickt der nicht ootb/per default eMails im Fehlerfall? Gilt eMail als nicht zuverlässig genug?

Weil dich ein Monitoring schnell vollspamen kann. CheckMK macht seine Checks default alle 60 Sekunden und jedes mal ne da ne Kleinigkeit nicht passt bekommst ein Mail. Da darf man schon als Admin fein einstellen damit es dann auch passt. Wir hier haben es so eingestellt wenn es in 5 Minuten wieder auftritt oder Wiederholung ansteigt, dann schreib mal ein Mail aus. Z.b. starten auf Systemd Sachen durch oder sind kurz weg, da möchtest kein Mail bekommen. Ist auch je nach Service verschieden, "bei Temperatur zu hoch" bekomme ich sofort ein Mail.