metrics: History doesn't include reboots, but should

[garrett]

Page: Metrics

When looking at the system history, it's not clear when a reboot happened.

Story: I had another system crash and would like to see the context of when spikes happened. Did the computer spike up in memory and CPU usage before the crash? Or what that the result of booting up? It's unclear in the UI at the moment. Having a boot marker like the system logs would make it more obvious.

[martinpitt]

Agreed -- it could even appear as an "event", like we have CPU/memory spikes. Chances are very high that a reboot triggers a CPU spike anyway.

[martinpitt]

We can certainly correlate this with reboots from last, and if we have it, we can certainly feed it in as event.

There are other causes of large data gaps, like suspends, rescue mode, or the admin just stopping PCP. Whenever we encounter a nontrivial data gap, should we visually set them apart somehow? i.e. start a new block instead of putting long contiguous empty graphs in between? that might make the page a bit easier to comprehend.

[jelly]

Related on my laptop (which I suspend), the metrics page seems to show empty blocks when my laptops suspends.

[garrett]

Yeah, I'm getting that too. 😞

[dev-DTECH]

Hey @garrett, I would like to work on this issue.

[KKoukiou]

Hey @garrett, I would like to work on this issue.

@dev-DTECH This is not a very easy good first issue actually. You will need to parse information about reboots from journal probably and insert these in the right timestrap in the metrics graph events. The whole code for this is here https://github.com/cockpit-project/cockpit/blob/main/pkg/metrics/metrics.jsx but as said, it's not just a 10 lines PR.

[dev-DTECH]

Hey @garrett, I would like to work on this issue.

@dev-DTECH This is not a very easy good first issue actually. You will need to parse information about reboots from journal probably and insert these in the right timestrap in the metrics graph events. The whole code for this is here https://github.com/cockpit-project/cockpit/blob/main/pkg/metrics/metrics.jsx but as said, it's not just a 10 lines PR.

Yeah I understand that but I am eager to learn and also I am well acquainted with journal. If anyone else is not working on it I can try to resolve this issue.

[dev-DTECH]

Hey @KKoukiou, I searched a bit and figured output that the command 'last -x' shows the timings of crash/reboot/shutdown
So I am trying to use the output of this command to indicate the reboots in the metric history.

Is it the correct way or should I consider another way?

[KKoukiou]

@dev-DTECH is looks fine to start with that.

[dev-DTECH]

Hey @KKoukiou, so I got the reboot times using cockpit.spawn("last -x | grep reboot".split(" "))

Every reboot has a start time and end time

So should I show the whole range of time as the reboot or just the start/end?

[martinpitt]

Note that the reboot range seems to include the whole time between booting and shutting down. E.g. I usually apply OS updates on Saturday mornings, then reboot, and they look like this:

reboot   system boot  6.1.14-200.fc37. Sat Mar  4 07:25 - 09:12 (7+01:46)

I.e. it spans over a week -- I suppose the "7+" means "7 days, one hour, and 46 minutes". TBH I find that output rather hard to interpret.. It gets easier to read with --fulltimes:

reboot   system boot  6.1.14-200.fc37. Sat Mar  4 07:25:49 2023 - Sat Mar 11 09:12:46 2023 (7+01:46)

Plus, there's also shutdowns. But it seems to me that we can only show the time when the computer started, which I believe is the first timestamp. With that, we can also ignore the shutdowns.

Please don't run cockpit.script() with grep, run cockpit.spawn(["last", "--time-format=iso", "reboot"]). That time format is easier to parse, then you can use date-fn's parseISO() to convert it to an useful datetime object.

[dev-DTECH]

Ok that's much better formatted

This is cockpit.spawn(["last", "--time-format=iso", "reboot"]) then the time parsed with parseISO()

Thanks for the help. This will make my task so much easier.

[ashutosh7i]

Hello @martinpitt sir, Do we still need this feature?
can i work on this issue??

[martinpitt]

@ashutosh7i yes, this is still relevant, and fixing would be nice! Note that this is not the easiest task to start with (not hard, but perhaps start with something easier). Please consider #15983 (comment)

[ashutosh7i]

So i have some progress on this,

• sir @martinpitt i have worked accordingly as you mentioned in this comment #15983
  i am parsing data in similar format, To show the reboot event i am considering the second timestamp as the time of reboot.
  for example, in this response-

reboot   system boot  6.1.14-200.fc37. Sat Mar  4 07:25:49 2023 - Sat Mar 11 09:12:46 2023 (7+01:46)
reboot   system boot  kernal version     [timestamp 1]               - [timestamp 2]        (session duration)

i am parsing these using cockpit.spawn, then mapping the timestamps in UI.
i am using timestamp 2 as the time when reboot happened and show the event "Reboot" there.

Sample image-

Now i have some questions-

1. Since reboot is a critical event, should i show it in place of "spikes" or in place of "Load, Disk, Network, I/O" ?
2. What about design? what exact phrase should i use, is "Reboot" fine? @garrett

[garrett]

Looks good. Thanks!

We might even want to consider making it bold, as it's not just an important event, but it is also a "landmark" event (where it is a specific event that shows when one session stopped and another started).

Since reboot is a critical event, should i show it in place of "spikes" or in place of "Load, Disk, Network, I/O" ?

Yes; thanks!

What about design? what exact phrase should i use, is "Reboot" fine?

Yes, that works.

[martinpitt]

Thanks @ashutosh7i ! Can you please send a pull request with your changes, so that we can review and test the implementation there? Cheers!

[ajshrmaofficial]

Hey @garrett @martinpitt ,
I hope you guys are doing well,
I just wanted to ask you guys if this issue is still available, as I do not see any PR attached to it
By the way, I liked this project very much and want to contribute if possible (I'm new to contributions).
Thanks

[martinpitt]

@ajshrmaofficial Yes, it is still outstanding and there's no PR. Thanks for your interest! Please work through https://github.com/cockpit-project/cockpit/blob/main/HACKING.md first to set up a dev environment and learn how to do and test a change first. Have fun!