Display last state change on service pane

[steaksauce-]

Is your feature request related to a problem? Please describe.

It would be useful to display the last state change in the service pane in a date format, so that information can quickly be gathered WITHOUT going to the history tab.

Last State Change | 02-21-2020 15:21:50 | (PING - VOICE)
Last Check | 03-05-2020 13:13:49

Describe the solution you'd like

A modification to the code can easily be implemented to display this. I have an example of code that works with the current version, but it should be noted:

• I do not work with PHP
• This code was written by a self-taught "developer" who left a few years ago (I'm honestly shocked the code works in the newest version).
• This code can be used by someone who knows the language and can clean it up.

The code exists at the bottom of /usr/share/icingaweb2/modules/monitoring/application/views/scripts/show/components/output.phtml

<?php
if ($object->type == "service" )
{
?>
<h2><?= $this->translate('Timestamps') ?></h2>
<table>
<tr>
<?php
if (strpos(strtolower($object->service),"ping") !== false  )
{
?>
<td width=150><b><u>Last State Change</u></b></td>
<td><b><u>
<?= date('m-d-Y H:i:s',($object->last_state_change)) ?>
</u></b></td>
<?php
}
else
{
?>
<td width=150>Last State Change</td>
<td>
<?= date('m-d-Y H:i:s',($object->last_state_change)) ?>
</td>
<?php
}
?>
<td>
<?php print "(" . $object->service . ")"; ?>
</td>
</tr>
<tr>
<td>Last Check</td>
<td>
<?= date('m-d-Y H:i:s',($object->last_check)) ?>
</td>
</tr>
</table>
<br>
<?php
}

Describe alternatives you've considered

As an organization, we have considered using the history tab, but with recent weather causing THOUSANDS of service outages in monitoring, our NOC has determined that the extra clicks take too long.

We can keep the custom code in place, but it would prevent us from safely upgrading Icingaweb 2 -- which is why we set up an entirely new Icinga2 instance earlier this year (not just this code, but the old developer had a lot of manual bug fixes in place).

Additional context

[nilmerg]

Hi,

the detail view of a service (and a host's one too) already show both of these informations.

We utilize different time and date formats depending on how much time is left or is remaining. That's why for the last check it's showing a relative format as opposed to a date format for the last state change. Relative formats are easier to read and understand if they're used for short periods of time.

If it's the placement of the last check information you have issues with, take a look at how we show this in Icinga DB Web. It moved more upwards there and is displayed completely different.

I hope you understand that showing plain m-d-Y H:i:s formats instead is not a improvement to that at all.

[steaksauce-]

We aren't interested in the "last check" being displayed here -- only the last status change.

Unlike your screenshot, default Icingaweb2 is not showing "since {date here}" -- is that a configuration option or a different UI?

[nilmerg]

Unlike your screenshot, default Icingaweb2 is not showing "since {date here}" -- is that a configuration option or a different UI?

It sure does, even in your own screenshot :thinking:

[steaksauce-]

Unlike your screenshot, default Icingaweb2 is not showing "since {date here}" -- is that a configuration option or a different UI?

It sure does, even in your own screenshot 🤔

Apologies -_- yours was in a different spot and I haven't had the correct amount of caffeine this morning

[steaksauce-]

So reviewing the new found knowledge, I find that for short periods of time it will say something like "[CRITICAL/WARNING/OK] for X". After a day or so, it will switch to a date "[CRITCAL/WARNING/OK] since X".

When providing this time-in-status information, customers (internal or external) are usually given information "since", not "for". The date format is irrelevant to me as long as it's a date and not time period.

If a service goes into an OK state and we update an internal ticket, we would never say "it's been green for 5 minutes", we would say "it's been green since March 3rd, 2020 @ 10:25 AM" so that if the concerned party doesn't look at the ticket immediately (as is often the case), they do not have outdated information (it's been green for 5 minutes... 4 hours ago).

With that being said, it's still useful for the monitoring user to be able to look at the service and say "it's been green for 4 minutes" or "it's been red for 13 minutes".

I still think that having the "last state change" in some sort of date/time format on the service pane is useful, without changing anything about the since/for time periods on the status. It doesn't have to be in it's own section or anything like the screenshot -- in fact it would make sense to have the information alongside the "Plugin Output":

OK - 8.8.8.8 rta 4ms lost 0%
since Mar 5, 2020 @ 10:34 (or any other date/time format)

The code was easy enough and I can push it in, with any date/time format that would be desired.

[nilmerg]

Sure, externally (where it's not refreshed every x seconds) a full time and date is the better choice. If it's only about having a way to tell the exact date and so on, the since/for <timeperiod> elements have a tooltip which contains exactly that. It's not copyable though, if that's desired.