→ English Version

Eine der innovativsten Techniken die wir in check_netapp_pro eingebaut haben ist meiner Meinung nach die Option –rm_ack. Löst die damit gesteuerte Logik doch das Problem, dass bei einem bestätigten Overall-Check nachfolgende Fehler nicht mehr aktiv alarmiert und damit leicht übersehen werden könnten. Dieser Schalter steht nun aber möglicherweise zur Disposition und könnte durch ein anderes, erweitertes Verfahren ersetzt werden.

Was ist ein Ursachenwechsel und warum Ursachenwechsel ein Problem darstellen

Bei einem Overall-Check, also einem Check der mehrere Instanzen wie beispielsweise Volumes in einem Durchlauf prüft, kann es leicht passieren, dass zunächst einmal ein vielleicht nicht so bedeutendes Volume als “bald voll” alarmiert wird. Dieser Alarm wird dann im Monitoringsystem bestätigt, so dass keine weiteren Alarmmeldungen mehr versendet werden. Bis zur Behebung durch z.B. das Nachbestellen weiterer Festplatten kann es jedoch passieren, dass ein weiteres, bedeutsameres Volume des gleichen Checks voll läuft. Der Servicecheck ist jedoch bereits CRITICAL und bestätigt und das Monitoringsystem kann nicht erkennen, dass der Grund für den CRITICAL Status inzwischen ein anderer ist. Solche Ursachenwechsel stellen also dann ein Problem dar, wenn Service-Acknowldements verwendet werden und können natürlich auch nur dann auftreten, wenn mit einem Service-Check mehrere Instanzen geprüft werden. Letzteres ist aber bei der großen Anzahl an Volumes oder Disken in einem Storagesystem nahezu unvermeidlich.

Tabelle Ablauf Nagios Checks für NetApp

Tabellarische Darstellung wie es zu einem Ursachenwechsel kommt und wie die in den Plugins eingebaute rm_ack Logik derzeit darauf reagiert.

Status quo

Vergegenwärtigen wir uns zunächst einmal wie die aktuell durch –rm_ack implementierte Logik funktioniert und werfen wir dazu einen Blick in die Hilfe:

--rm_ack

    Under what circumstances a service-acknowledgement (problem acknowledgement for a particular service) should be removed. Can be either 'always', 'never', or 'reason-change'. Defaults to 'reason-change'. The value 'reason-change' means, remove a service-acknowledgement only if the reason for the non-ok state has changed (something got worse or an additional instance got into a non-ok state).

Die Option –rm_ack ist werksseitig also auf reason-change gesetzt und weist somit das Plugin an, im Falle eines Ursachenwechsels das service-acknowledgement für den das Plugin aufrufenden service-check zu entfernen. Dazu muss das Plugin allerdings wissen, welcher service-check für welchen host (beides wird über die cfg-Datei des Monitoringsystems konfiguriert) das Plugin aufgerufen hat. Diese Information kann das Plugin Umgebungsvariablen entnehmen, die damals, als ich diese Technik entwickelt habe, vom Nagios-Daemon standardmäßig gesetzt wurden.

Allerdings sind diese Variablen in aktuellen Versionen nicht mehr immer zu finden, da die aktuellen Daemons diese aus Performancegründen nur noch dann exportieren, wenn dies ausdrücklich konfiguriert wurde. Weiters ist es so, dass von diesem Problem des Ursachenwechsels nicht nur die von uns entwickelten NetApp-Plugins betroffen sind, sondern auch andere Plugins, die dafür keine Lösung bieten. In manchen Umgebungen werden Service-Acknowledgemnts daher gar nicht eingesetzt und deren Funktionalität übergeordnet von zum Beispiel einem Ticketing-System übernommen.

Was sich ändern könnte

Die oben beschriebenen Veränderungen seit der erstmaligen Implementierung von –rm_ack legen meiner Meinung nach nahe, den Umgang mit einem Ursachenwechsel grundlegend zu überdenken. Dass das Plugin über eine Pipe das Monitoring-System anweist ein Service-Acknowldegement zu löschen, war streng genommen schon immer nicht ganz unproblematisch – erinnert das doch stark an “Schwanz wackelt mit dem Hund”.

Eine meiner Meinung nach flexiblere Lösung wäre die Option –rm_ack zu entfernen und durch eine neue Option –reason_change=ignore | signal | remove_ack zu ersetzen.

Die neue Option –reason_change würde folgende Logik steuern:

  • Im Falle von ignore hätte eine Ursachenänderung keinerlei Reaktion von Seiten des Plugins zur Folge.
  • Bei signal würde in der Nachricht an das Monitoringsystem (stdout, LONGSERVICEOUTPUT) durch einen leicht erkennbaren String ein allfälliger Ursachenwechsel eindeutig signalisiert. Dieser String kann von einem Operator im GUI erkannt werden. Aber auch ein möglicherweise nachgeschaltetes (Ticketing-)System kann diesen String in der Nachricht zur Unterscheidung heran ziehen, ob ein neues Ticket erstellt oder ein vorhandenes nur aktualisiert werden soll.
    ./check_netapp_pro Usage -H filer -o volume ‑‑reason_change=signal
    
    NETAPP_USAGE CRITICAL - 102 volumes checked, 2 critical, 1 warning
    REASON-CHANGE: 2 reason-changes since last check.
    vol0 93% (CRITICAL)
    vol1 95% (CRITICAL)
    vol5 85% (WARNING)
    vol4 43%
    ...
  • remove_ack erweitert  signal noch zusätzlich um das Kommando an das Monitoring-System ein eventuell gesetztes service-acknowldegment zu entfernen. Diese Option entspräche also dem bisherigen ‑‑rm_ack=reason-change – damit würde dann wie gehabt der Schwanz wieder mit dem Hund wackeln.