Data we collect and store
Nexthink distinguishes between two types of data: objects and events.
Inventory objects represent physical or virtual items related to the digital environment. Objects contain elements that, once captured, rarely change.
name, size, version, …
name, username, department, …
name, CPU, OS, …
Objects are not limited to what is collected by our agent or injected through APIs but include configuration objects too. Configuration objects refer to all objects that are configured by users, such as alerts, applications, campaigns and remote actions.
name, threshold, priority, …
name, status, trigger_method
Events represent occurrences of something that happened at a given time within your IT infrastructure (for example,
There are two types of events: punctual and sampled.
The main characteristics of an event are:
Association with objects (such as users or devices)
Properties describing characteristics such as the name and size of a running process
Metrics which are numerical values such as cpu_time, memory usage, or traffic related to a running process. Metrics can be aggregated.
Punctual events reflect occurrences at their exact time. They include crashes, boots or logins.
A crash of a binary
user, device, binary
A user login on a device
A device booting
Sampled events refer to a data collection method essential for monitoring dynamic metrics associated with continuous and long-term activities. This is particularly important for metrics such as CPU utilization, memory usage, and process traffic, which constantly fluctuate and require regular sampling and aggregation to accurately represent data.
The Collector sampling process occurs frequently, every 20-30 seconds, resulting in high-resolution data. This data is then structured into aggregated time slices, which can either be 5 minutes or 15 minutes long, depending on the specific requirements of the data collection. These time slices make it easier to analyze the data.
Sample indicating when a device is reporting to Nexthink
protocol, session_ID, …
RTT, latency, interaction_time, …
Executions of a process with resources consumed
user, device, binary
CPU_time, outgoing_traffic, memory_used, …
Resources consumed by a device
CPU_usage, read_operation_per_second, used_memory, …
A field is either a property or a metric attached to an object or event. It has a name, a label, a description and a value. The name is the way it appears in the query in
snake_case. The label is the natural language version of the name and the description offers a longer explanation of the value and how it is computed.
During aggregation, similar events are merged together, and their metrics are combined using different functions depending on the type of data (sum, average, percentile, etc.). Nexthink picks the most meaningful aggregate function to keep the value of the data point intact.
outgoing_traffic is summed while
connection_etablishment_time is averaged.
Example 1 - Multiple processes
chrome.exe running on the same device with the same users but with 3 processes.
08:00 - 08:12
08:05 - 08:12
08:10 - 08:14
Would be aggregated and stored as a 15 minutes sampled event starting at 08:00 and finishing at 08:15
30 MB (15 + 5 + 10)
12ms ( (6 + 10 + 20) / 3 )
This can be queried with NQL in the following way:
Example 2 - Device CPU
To store the
cpu_usage of a particular device, Nexthink Collector takes samples of the CPU load of all running processes every 30 seconds.
For a device running from 08:00 till 08:15, 30 samples are generated and sent to the Nexthink instance that aggregates it into a new value
82% (80 + 55 + 75 + ... + 90 + 95) / 30
It can be queried with NQL in the following way:
Aggregation is necessary to store relevant data and make them quickly available at query time.
Sampled events are aggregated at two resolutions, 15 minutes and 1 day.
The data type is an attribute of the value stored in a field. It dictates what type of data a field can store. Our data types are explained in the documentation.
The context of an event contains some properties of the associated objects at a specific time.
To illustrate, here is a breakdown of the average boot times per state to discover any location-based slowness.
Average boot duration per state
Namespaces, tables, groupings and fields
A namespace regroups one or more tables together for consistency and clarity. A table groups objects or events of the same kind together. Inside a table, there are fields that are sometimes in groups. Take the visual representation of the device namespace as an example.
In that example, the namespace is device, it contains a table named devices. As we'll see below when in the NQL example, that table contains objects which are referred to as device. Collector, hardware, operating_system, public_ip and virtualization are groupings each containing fields that belong together.
For example, we can query devices with NQL to get a list of CPUs for each device. At the root of NQL queries,
devices is an alias for
device.devices. The namespace is implicit. The same mechanism applies to other tables.