Real-time and consolidated service data with Finder (classic)

How service data is computed

Nexthink begins accumulating information about a service only after you have created it, meaning the service is empty right after its creation. As time passes, Nexthink collects data related to the service and stores the aggregated results in intervals of 10 minutes. The system keeps up to a maximum of six aggregated values that correspond to the last six 10-minute intervals. After one hour, all of the six aggregated values are filled with data. At this point, the system erases the oldest aggregate and reuses it for a new 10-minute interval. By rotating the stored results in this way, the system consistently displays the evolution of the service during the last hour with a granularity of 10 minutes.

Similarly, for longer time intervals, the system stores an hourly aggregated result each time that it crosses an hour boundary. A total of 24 hourly aggregated results per service are stored and rotated, giving a dynamic full-day view of the service.

Finally, the system also stores the daily aggregated results of a service when a day boundary is crossed. For each service, there are up to seven daily results stored to build up a full week of service data; although these latter are visible from the web interface only, not from Finder.

The labels of the two rows that display the metrics in Finder change over time according to the mechanisms for aggregating results described above. Both rows start with the label Last 10 minutes. After ten minutes have passed, both labels successively display Last 20 minutes, Last 30 minutes, etc. until an hour boundary is crossed. At this point, the short-term row still increases every 10 minutes, while the long-term row label displays Last 1 hour, and increases to Last 2 hours, Last 3 hours, etc. after every hour. When all results are available for the last 24 hours, the short-term row label displays Last 60 minutes and the long-term row label displays Last 24 hours. The labels no longer change after that point.

Quantity	Interval
6 results	10 minutes
24 results	1 hour
7 results	1 day

Aggregated results per service

Discrepancies between the real-time view and the consolidated view of services

It is possible that you may find small discrepancies between the real-time values of a service (the Service View in Finder or a service widget in the web interface) and the values that you get when you drill-down from the real-time view or perform an equivalent investigation. For instance, it may happen that the Service View of Finder reckons the number of devices using a service to be 10 devices, for a given service and a particular hour of the day; whereas if you drill-down from the Service View to obtain the detailed list of the devices involved, you may get a list with only 9 devices. These differences arise because of the two separate ways in which Engine collects and organizes service-related events.

On one hand, for the consolidation of events in the long term, Engine processes events to extract their timing information. Since events represent employees' information, an event reaches Engine some time after Collector has generated it in the device of the employee. Nevertheless, Engine can precisely determine the moment in time at which an event really began. This value is the final timestamp of the event.

On the other hand, the real-time views of services require Engine to react immediately. Thus, Engine takes into account every new event that matches the definition of a service as soon as Engine receives the event from Collector. Engine aggregates these events during intervals of 10 minutes, 1 hour and 1 day, according to the explanation given above. The Service View displays the values collected within these intervals.

Because of this difference in treatment, if the interval between the start time of a service-related event and the moment of its reception by Engine crosses a 10-minute interval boundary (Engine time), you may get discrepancies between the real-time view and the consolidated view of the event. Indeed, if an event is generated shortly before the end of a 10-minute interval and Engine receives it once the interval is over, Engine properly consolidates the event according to its real start time, but it cannot aggregate the event to the appropriate 10-minute interval, because that interval is already closed for aggregation. Therefore, Engine has to report the event in the next 10-minute interval.