Real-time and consolidated service data
How service data is computed
Nexthink starts to accumulate information about a service only after you have created it; thus, 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 six last 10 minutes intervals. After one hour, all the six aggregated values are filled with some data. At this point, the system erases the oldest aggregate and reuses it for a new 10 minutes 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.
In a similar way, 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 Portal only, not from the Finder.
The labels of the two rows that display the metrics in the Finder change thus with 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.
Aggregated results per service
| Quantity | Interval |
|---|---|
6 results | 10 minutes |
24 results | 1 hour |
7 results | 1 day |
Discrepancies between the real-time view and the consolidated view of services
In some situations, it is possible that you find small discrepancies between the real-time values of a service (the Service View in the Finder or a service widget in the Portal) 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 the 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 the Engine collects and organizes service-related events.
On one hand, for the consolidation of events in the long-term, the Engine processes events to extract their timing information. Since events represent end-user information, an event reaches the Engine some time after the Collector has generated it in the device of the end-user. Nevertheless, the 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 the Engine to react immediately. Thus, the Engine takes into account every new event that matches the definition of a service as soon as the Engine receives the event from a Collector. The 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 the Engine crosses a 10 minutes 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 short before the end of a 10 minutes interval and the Engine receives it once the interval is over, the Engine properly consolidates the event according to its real start time, but it cannot aggregate the event to the appropriate 10 minutes interval, because that interval is already closed for aggregation. Therefore, the Engine has to report the event in the next 10 minutes interval.
RELATED TASKS
Last updated