Mir liegt ein Featurerequest zu SnapMirrorMetrics vor:

Da bei uns des Öfteren Lagtime False Positives auftreten weil der Transfer zwar fertig ist aber am Volume noch finalisiert wird, hätten wir gerne einen Schalter für den SnapMirrorMetrics-Check:‑‑finalizing_relation_is_ok

Derzeit sind dafür zwei Lösungsvarianten in Diskussion:

Die einfache Lösung: --finalizing=OK|WARN

Dieser Schalter würde den Check auch dann mit OK (oder WARNING) beenden, wenn die Lagtime überschritten wurde, vorausgesetzt der Status des betreffenden Transfers ist schon finalizing.

An dieser Stelle sollten wir uns vielleicht vor Augen halten, was finalzing genau meint. Dazu lesen wir im SDK:

‘finalizing’ – SnapMirror transfers are enabled, currently in the post-transfer phase for vault or extended data protection incremental transfers

Die sehr gründliche Lösung:--finalizing_plus=12h

Im Gegensatz zu der oben schon vorgestellten Lösung würde hier der Schwellwert abhängig vom Status des Transfers um bis zu maximal 12 Stunden verlängert werden. Damit würden wir verhindern, dass im Falle eines endlos in einer finalizing-Schleife hängen gebliebenen Transfers, dieser auf ewig OK und damit vom Monitoring unerkannt bleiben würde.

Ein vollständigeres Beispiel zur Erläuterung:

SnapMirrorMetrics ... --what=lag_time -w 1d -c 2d --finalizing_plus=12h

Das obige Beispiel ergäbe dann mit einer lag-time > 36h immerhin ein WARNING und nach 2,5 Tagen einen CRITICAL Alarm, selbst dann wenn der relationship-status ‘finalizing’ ist. In allen anderen relationship-status wird wie bisher nach einem Tag ein WARNING und nach zwei Tagen ein CRITICAL Alarm ausgelöst.

Ihre Meinung?

Mir persönlich sagt die zweite, gründlichere Variante mehr zu. Das Verhindern von false-positives also Fehlalarmen ist sicherlich ein wichtiges Anliegen sollte jedoch keinesfalls dazu führen, dass false-negatives, also unentdeckte Fehler dadurch ermöglicht werden – auch dann wenn diese unwahrscheinlich sind. Letztendlich richten wir uns aber nach den Kundenwünschen. Bei Interesse an einem dieser Schalter kommentieren Sie bitte diesen Artikel oder senden ein E-Mail an developer@netappmonitoring.info.