Gesamtlaufzeit der Maschine


7

Gibt es eine Möglichkeit, die Gesamtlaufzeit eines Linux-Systems aus dem BIOS oder der CPU zu lesen?

Ich habe BIOS-Informationen nach dmidecode durchsucht. Aber es gibt ein Veröffentlichungsdatum, das für meine Frage nicht angemessen ist.

Dann habe ich ausgecheckt /proc. Es enthält jedoch nur die Betriebszeitwerte vom letzten Neustart. Möglicherweise kann das Schreiben dieser Verfügbarkeitswerte für jeden Start eine Option sein.

Dann habe ich nachgesehen dumpe2fs. Es gibt die Gesamtlaufzeit einer bestimmten Festplatte an. Es ist für mich nutzlos, da die Festplatte geändert werden kann, während meine Anwendung ausgeführt wird.

Wie kann ich mit Ausnahme der oben genannten die Gesamtlaufzeit meines Systems lesen oder berechnen? Wo kann ich lesen?


Gesamtlaufzeit der CPU, der Festplatte (n) oder der Anwendung? Oder andere Komponenten? Wie würden Sie definieren, woher die Identität des "Systems" kommt?
Ilkkachu

Ich habe die Gesamtlaufzeit der CPU gemeint. Natürlich würde ich lieber aus dem BIOS lesen, wenn es einen Weg gibt.
Cumhur Sayan

Antworten:


10

Soweit mir bekannt ist, verfolgt die Firmware dies nicht. Selbst BMCs messen nicht die Gesamtverfügbarkeit.

Dies hilft nicht bei früheren Betriebszeiten von früheren Starts, aber Sie können jetzt mit der Aufzeichnung von Betriebszeiten beginnen, indem Sie ein Tool wie installieren uptimedund es so einrichten LOG_MAXIMUM_ENTRIES, dass niemals Werte verworfen werden ( auf 0 Zoll gesetzt uptimed.conf). Dadurch wird die Betriebszeit des Betriebssystems gemessen, nicht die gesamte CPU-Einschaltzeit, aber sie sollte nahe genug sein ... Sobald Sie ausgeführt haben uptimed, können Sie uprecordsbeispielsweise die Gesamtsummen anzeigen

    up  1492 days, 02:57:18 | since                     Sat Sep  7 00:50:06 2013
  down    61 days, 08:11:24 | since                     Sat Sep  7 00:50:06 2013
   %up               96.051 | since                     Sat Sep  7 00:50:06 2013

Wie von quixotic hervorgehoben , können Sie sich anhand Ihrer Protokolle ein Bild von der historischen Betriebszeit machen. Wenn Sie systemd ausführen, können Sie die mit protokollierten Starts anzeigen journalctl --list-boots. Durch die Protokollrotation wird jedoch wahrscheinlich eine Menge Betriebszeit verpasst.

Wie von JdeBP hervorgehoben , erhalten Sie last rebootmöglicherweise eine längere Liste von Stiefeln mit der damit verbundenen Betriebszeit.


Die historische Betriebszeit (für das Betriebssystem, nicht für die Hardware) kann bei entsprechenden Protokollen geschätzt werden. journaldkönnte hier nützlich sein. Stromausfälle, schwere Abstürze oder andere nicht gekennzeichnete Systemstopps können diese Gewässer trüben.
Quixotic

Danke @quixotic; Mein Kommentar dort war in Bezug auf die Installation uptimed, was nicht klar war. Ich habe meine Antwort aktualisiert.
Stephen Kitt

Auch wenn man ein systemd-Betriebssystem verwendet, last rebootsollte es funktionieren und die Daten, die in den alten Binärprotokollen (die weit weniger scrollen) aufgezeichnet sind , von anzeigen systemd-update-utmp.
JdeBP

@JdeBP Sie würden so denken, aber es scheint stark zu variieren: Einige meiner Systeme zeigen alle Stiefel zurück zu ihrer Installation, andere haben nur den letzten Boot ...
Stephen Kitt

@JdeBP Wenn der Speicher ordnungsgemäß last rebootfunktioniert, werden Systemabstürze nicht gut behandelt. Wenn ein System um 07:00 Uhr gestartet wird und abstürzt oder um 08:00 Uhr abrupt ausgeschaltet wird, aber erst um 10:00 Uhr neu gestartet wird, werden die tatsächliche Nutzung (1 Stunde) und die deklarierte Nutzung (3 Stunden) um zwei Stunden ausgeschaltet . Dies kann sich jedoch geändert haben systemd; Ich habe keinen Server zum Testen zur Hand.
Roaima

0

Wenn Sie keine Probleme haben, diese Informationen vom Betriebssystem abzurufen , können Sie mit tuptime einen vollständigen Bericht über die Gesamtzeit des Linux-Systems anzeigen , einschließlich Systemabstürzen.

Zum Beispiel als Standardausgabe und -wiederaufnahme:

# tuptime

System startups:    8   since   08:32:29 AM 11/24/2016
System shutdowns:   3 ok   -   4 bad
System uptime:      99.99 %   -   1 year, 195 days, 5 hours, 47 minutes and 14 seconds
System downtime:    0.01 %   -   1 hour, 6 minutes and 34 seconds
System life:        1 year, 195 days, 6 hours, 53 minutes and 48 seconds

Largest uptime:     240 days, 7 hours, 38 minutes and 10 seconds   from   08:41:51 AM 02/07/2017
Shortest uptime:    18 hours, 15 minutes and 14 seconds   from   02:26:05 PM 02/06/2017
Average uptime:     70 days, 0 hours, 43 minutes and 24 seconds

Largest downtime:   45 minutes and 15 seconds   from   10:00:01 AM 03/14/2018
Shortest downtime:  5 seconds   from   02:26:00 PM 02/06/2017
Average downtime:   9 minutes and 31 seconds

Current uptime:     85 days, 4 hours, 41 minutes and 1 second   since   10:45:16 AM 03/14/2018

Alternativ ist es möglich, eine Liste mit allen historischen Ereignissen mit dem Listenargument abzurufen, in dem angegeben ist, wie das Abschaltereignis schlecht (ein Absturz) oder in Ordnung (nach dem Herunterfahren) war:

# tuptime -l

Startup:  1  at  08:32:29 AM 11/24/2016
Uptime:   46 days, 16 hours, 52 minutes and 32 seconds
Shutdown: BAD  at  01:25:01 AM 01/10/2017
Downtime: 5 minutes and 10 seconds

Startup:  2  at  01:30:11 AM 01/10/2017
Uptime:   27 days, 12 hours, 55 minutes and 49 seconds
Shutdown: OK  at  02:26:00 PM 02/06/2017
Downtime: 5 seconds

Startup:  3  at  02:26:05 PM 02/06/2017
Uptime:   18 hours, 15 minutes and 14 seconds
Shutdown: OK  at  08:41:19 AM 02/07/2017
Downtime: 32 seconds

Startup:  4  at  08:41:51 AM 02/07/2017
Uptime:   240 days, 7 hours, 38 minutes and 10 seconds
Shutdown: BAD  at  05:20:01 PM 10/05/2017
Downtime: 3 minutes and 17 seconds

Startup:  5  at  05:23:18 PM 10/05/2017
Uptime:   7 days, 14 hours, 56 minutes and 43 seconds
Shutdown: BAD  at  08:20:01 AM 10/13/2017
Downtime: 11 minutes and 35 seconds

Startup:  6  at  08:31:36 AM 10/13/2017
Uptime:   25 days, 1 hour, 7 minutes and 4 seconds
Shutdown: OK  at  08:38:40 AM 11/07/2017
Downtime: 39 seconds

Startup:  7  at  08:39:19 AM 11/07/2017
Uptime:   127 days, 1 hour, 20 minutes and 42 seconds
Shutdown: BAD  at  10:00:01 AM 03/14/2018
Downtime: 45 minutes and 15 seconds

Startup:  8  at  10:45:16 AM 03/14/2018
Uptime:   85 days, 4 hours, 42 minutes and 9 seconds

Berücksichtigen Sie dies last rebootund erhalten Sie journalctl --list-bootsdie Informationen aus den Protokollen, und diese Protokolle haben eine maximale Lebensdauer. tuptimeSpeichert die Informationen stattdessen in einer bestimmten Datenbankdatei, die ihr zugeordnet ist.

Für die Installation, vorausgesetzt, Sie verwenden Linux, ist das Paket im Debian verfügbar und leitet sich ab:

# apt-get install tuptime

Wenn nicht, können Sie das Installationsskript "tuptime-install.sh" aus dem Repository herunterladen: https://github.com/rfrail3/tuptime/

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.