Login
Newsletter
Werbung

Do, 28. Februar 2019, 15:00

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.

  • Das Werk darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, Abwandlungen und Bearbeitungen des Werkes müssen unter den gleichen Bedingungen weitergegeben werden. Der Name des Autors/Rechteinhabers muss in der von ihm festgelegten Weise genannt werden.

    - Weitere Informationen
Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung