Uptime automatisch aufzeichnen mit Uptimed
uprecords
Eine Aufzeichnung der Uptime, ohne auf diese Aufzeichnungen zugreifen zu können, wäre witzlos. Daher kommt im Uptimed-Paket das Programm uprecords mit. uprecords -h zeigt die verfügbaren Optionen an. Es erübrigt sich, diese näher zu erläutern, da sie selbsterklärend sind und leicht ausprobiert werden können. Als Beispiel sei hier die Ausgabe auf meinem NAS-System gezeigt, das nicht mit der Hersteller-Software, sondern einem ganz normalen Debian 8 läuft.
ubinas# uprecords
# Uptime | System Boot up
----------------------------+---------------------------------------------------
1 902 days, 04:07:44 | Linux 2.6.38.8 Sun Jul 10 13:37:35 2011
-> 2 562 days, 15:32:31 | Linux 3.16.0-4-686-pae Wed Aug 9 09:34:39 2017
3 562 days, 15:31:56 | Linux 3.16.0-4-686-pae Wed Aug 9 09:11:51 2017
4 444 days, 09:41:23 | Linux 3.2.0-4-686-pae Mon May 19 19:28:32 2014
5 284 days, 11:27:01 | Linux 3.2.0-4-686-pae Mon Feb 8 05:44:12 2016
6 230 days, 23:49:29 | Linux 3.16.0-4-686-pae Sat Dec 17 23:58:23 2016
7 184 days, 20:01:26 | Linux 3.2.0-4-686-pae Fri Aug 7 08:44:44 2015
8 38 days, 03:55:45 | Linux 3.2.0-4-686-pae Fri Apr 11 15:20:14 2014
9 25 days, 11:58:50 | Linux 3.2.0-4-686-pae Wed Jan 1 11:14:16 2014
10 24 days, 13:35:32 | Linux 3.2.0-4-686-pae Wed Nov 23 09:46:49 2016
----------------------------+---------------------------------------------------
no1 in 339 days, 12:35:14 | at Tue Jan 28 12:42:22 2020
up 3364 days, 06:41:4 | since Sun Jul 10 13:37:35 2011
down -579 days, -19:-12 | since Sun Jul 10 13:37:35 2011
%up 120.823 | since Sun Jul 10 13:37:35 2011
Wie man sieht, ist das NAS noch weit davon entfernt, seinen Uptime-Rekord zu brechen (und wenn ich Pech habe, gibt es vorher den Geist auf, immerhin ist es nun knapp 12 Jahre alt). Genau dauert es noch 339 Tage bis zum Uptime-Rekord, wie man weiter unten an der Zeile no1 in 339 days sieht. Warum die Aufzeichnung im Jahr 2011 beginnt und nicht 2007, ist mir unklar, vielleicht habe ich Uptimed tatsächlich erst 2011 installiert. Was noch ins Auge sticht, ist, dass die Ausgabe offensichtlich fehlerhaft ist. Die Summe der Downtimes ist negativ und die Verfügbarkeit (%up), die offensichtlich unterhalb von 100 Prozent liegen müsste, über 120 Prozent. Der Fehler liegt nicht bei uprecords, sondern bei der Aufzeichnung durch Uptimed.
Der Fehler mag in neuen Versionen von Uptimed korrigiert sein, daher sollte man möglichst die neueste Version einsetzen, sonst könnten immer weitere Falscheinträge hinzukommen. Jedenfalls wird die Aufzeichnung wird nicht automatisch korrigiert. Hier muss man selbst Hand anlegen und die Datei /var/spool/uptimed/records editieren. Damit man weiß, wo man suchen muss, führt man am besten uprecords -m 999 -d aus. Dies liefert
...
10 24 days, 13:35:32 | -24 days, -12:-40: Wed Nov 23 09:46:49 2016
11 24 days, 12:41:07 | 0 days, 00:11:09 Wed Nov 23 09:46:21 2016
...
was wohl bedeutet, dass Zeile 10 oder 11 der Datei falsch ist. Bevor man nun anfängt, die Datei zu ändern, muss man Uptimed stoppen:
systemctl stop uptimed
In Zeile 10 steht die längere Laufzeit, daher entschied ich mich, Zeile 11 zu löschen. Im Anschluss muss man /var/spool/uptimed/records nach /var/spool/uptimed/records.old kopieren, sonst liest uprecords aus letzterer und die Ausgabe bleibt falsch. Also
cp -a /var/spool/uptimed/records /var/spool/uptimed/records.old systemctl start uptimed uprecords
Nun sieht es etwas besser aus, aber wie man schon vorher vermuten konnte, liegt noch ein zweiter Fehler vor:
ubinas# uprecords
# Uptime | System Boot up
----------------------------+---------------------------------------------------
1 902 days, 04:07:44 | Linux 2.6.38.8 Sun Jul 10 13:37:35 2011
-> 2 564 days, 11:29:46 | Linux 3.16.0-4-686-pae Wed Aug 9 09:35:02 2017
3 564 days, 11:19:30 | Linux 3.16.0-4-686-pae Wed Aug 9 09:11:51 2017
4 444 days, 09:41:23 | Linux 3.2.0-4-686-pae Mon May 19 19:28:32 2014
5 284 days, 11:27:01 | Linux 3.2.0-4-686-pae Mon Feb 8 05:44:12 2016
6 230 days, 23:49:29 | Linux 3.16.0-4-686-pae Sat Dec 17 23:58:23 2016
7 184 days, 20:01:26 | Linux 3.2.0-4-686-pae Fri Aug 7 08:44:44 2015
8 38 days, 03:55:45 | Linux 3.2.0-4-686-pae Fri Apr 11 15:20:14 2014
9 25 days, 11:58:50 | Linux 3.2.0-4-686-pae Wed Jan 1 11:14:16 2014
10 24 days, 13:35:32 | Linux 3.2.0-4-686-pae Wed Nov 23 09:46:49 2016
----------------------------+---------------------------------------------------
no1 in 337 days, 16:37:59 | at Tue Jan 28 12:42:46 2020
up 3343 days, 09:45:2 | since Sun Jul 10 13:37:35 2011
down -557 days, -02:-18 | since Sun Jul 10 13:37:35 2011
%up 119.994 | since Sun Jul 10 13:37:35 2011
Dieses Mal muss der Fehler in Zeile 2 oder 3 sein:
...
-> 2 564 days, 11:32:04 | -564 days, -10:-56 Wed Aug 9 09:35:02 2017
3 564 days, 11:19:30 | 0 days, 10:20:04 Wed Aug 9 09:11:51 2017
...
Nach Entfernen der Zeile 3 ist das Resultat konsistent:
ubinas# uprecords
# Uptime | System Boot up
----------------------------+---------------------------------------------------
1 902 days, 04:07:44 | Linux 2.6.38.8 Sun Jul 10 13:37:35 2011
-> 2 564 days, 11:33:14 | Linux 3.16.0-4-686-pae Wed Aug 9 09:35:02 2017
3 444 days, 09:41:23 | Linux 3.2.0-4-686-pae Mon May 19 19:28:32 2014
4 284 days, 11:27:01 | Linux 3.2.0-4-686-pae Mon Feb 8 05:44:12 2016
5 230 days, 23:49:29 | Linux 3.16.0-4-686-pae Sat Dec 17 23:58:23 2016
6 184 days, 20:01:26 | Linux 3.2.0-4-686-pae Fri Aug 7 08:44:44 2015
7 38 days, 03:55:45 | Linux 3.2.0-4-686-pae Fri Apr 11 15:20:14 2014
8 25 days, 11:58:50 | Linux 3.2.0-4-686-pae Wed Jan 1 11:14:16 2014
9 24 days, 13:35:32 | Linux 3.2.0-4-686-pae Wed Nov 23 09:46:49 2016
10 22 days, 05:49:54 | Linux 3.2.0-4-686-pae Fri Feb 21 17:24:42 2014
----------------------------+---------------------------------------------------
no1 in 337 days, 16:34:31 | at Tue Jan 28 12:42:46 2020
up 2778 days, 22:29:2 | since Sun Jul 10 13:37:35 2011
down 7 days, 09:01:15 | since Sun Jul 10 13:37:35 2011
%up 99.735 | since Sun Jul 10 13:37:35 2011
Wie man sieht, ist das System ein ganzes Stück davon entfernt, eine Verfügbarkeit von 99,99% (die oft zitierten »Vier Neunen«) zu erreichen. Die Downtime resultierte im Wesentlichen aber aus zwei Ereignissen mit einer Dauer von je drei Tagen, einmal von 28. Dezember 2013 bis 1. Januar 2014 und einmal von 6. bis 9. August 2017. Ersteres dürfte die Vergrößerung des Arrays und Umstrukturierung zu einem RAID 6 gewesen sein, die sich nur offline durchführen ließ oder die ich aus Sicherheitsgründen lieber offline vornahm. Die zweite Ausfallzeit könnte etwas ganz Dämliches gewesen sein, vorausgesetzt meine Erinnerung ist noch korrekt, denn ich habe es nicht notiert. Jedenfalls hat es mir einen gehörigen Schreck eingejagt, und ich dachte zuerst, das NAS ist defekt und muss ersetzt werden. Es stellte sich dann heraus, dass ich das Stromkabel nicht richtig eingesteckt hatte und dadurch irgendwann der Kontakt verlorenging. Es dauerte drei Tage, bis ich bemerkte, dass das NAS nicht mehr lief, ansonsten wäre die Downtime nur kurz gewesen.
Doch das nur nebenbei. Die wesentlichen Dinge sind, dass man mit Uptimed die Uptime seiner Rechner aufzeichnen kann. Wenn man eine Inkonsistenz in den Daten bemerkt, lässt sich das recht leicht von Hand korrigieren. Neben dem Client uprecords existiert auch die Möglichkeit, sich die Uptimes im Webbrowser anzeigen zu lassen - Beispiel-CGI-Skripte sind im Paket enthalten. Das einfache Dateiformat von /var/spool/uptimed/records ist sicher kein Hindernis, sich einen eigenen Client zu schreiben - für erweiterte Statistiken etwa oder was auch immer man damit noch anfangen kann.
