Key data platform concepts
Data we collect and store
Nexthink distinguishes between two types of data: objects and events.
Objects
Inventory objects represent physical or virtual items related to the digital environment. Objects contain elements that, once captured, rarely change.
Object | Properties |
---|---|
binary | name, size, version, … |
user | name, username, department, … |
device | name, CPU, OS, … |
… | … |
Configuration objects
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.
Object | Properties |
---|---|
monitors | name, threshold, priority, … |
campaigns | name, status, trigger_method |
remote_actions | name, … |
… | … |
Events
Events represent occurrences of something that happened at a given time within your IT infrastructure (for example, execution.events
, web.errors
).
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
Punctual events reflect occurrences at their exact time. They include crashes, boots or logins.
Event | Description | Associations | Properties | Metrics |
---|---|---|---|---|
| A crash of a binary | user, device, binary | time, binary_path | cardinality |
| A user login on a device | user, device | time, session_uid | time_until_desktop_ready, time_until_desktop_visible |
| A device booting | device | time, type | boot_duration |
… | … | … | … | … |
Sampled events
Sampled events are used to monitor metrics related to continuous and long-lasting activities. They must be sampled and are presented aggregated in time slices (resolution) of 15 minutes or a day. For example, the CPU, memory, and traffic of a process vary all the time and, as such, must be sampled and aggregated.
Event | Description | Associations | Properties | Metrics |
---|---|---|---|---|
| Sample indicating when a device is reporting to Nexthink | user, device | 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 | device | CPU_usage, read_operation_per_second, used_memory, … | |
… | … | … | … | … |
Concepts
Field
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.
Aggregation
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.
To illustrate, 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.
time |
|
|
|
---|---|---|---|
08:00 - 08:12 | chrome.exe | 15 MB | 6ms |
08:05 - 08:12 | chrome.exe | 5 MB | 10ms |
08:10 - 08:14 | chrome.exe | 10 MB | 20ms |
Would be aggregated and stored as a 15 minutes sampled event starting at 08:00 and finishing at 08:15
|
|
|
|
|
---|---|---|---|---|
08:00 | 08:15 | chrome.exe | 30 MB (15 + 5 + 10) | 12ms ( (6 + 10 + 20) / 3 ) |
This can be queried with NQL in the following way:
CODE
|
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.
time |
|
---|---|
08:00:00 | 80% |
08:00:30 | 55% |
08:01:00 | 75% |
.... | .... |
08:14:00 | 90% |
08:14:30 | 95% |
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
|
|
|
---|---|---|
08:00 | 08:15 | 82% (80 + 55 + 75 + ... + 90 + 95) / 30 |
It can be queried with NQL in the following way:
CODE
|
Aggregation is necessary to store relevant data and make them quickly available at query time.
Resolution
Sampled events are aggregated at two resolutions, 15 minutes and 1 day.
Data types
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.
Contexts
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.
CODE
|
Location Country | Location State | Average boot duration per state |
---|---|---|
Canada | Alberta | 26s 634ms |
Canada | Ontario | 29s 518ms |
Canada | Quebec | 43s 672ms |
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.
CODE
|