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

execution.crash

A crash of a binary

user, device, binary

time, binary_path

cardinality

session.login

A user login on a device

user, device

time, session_uid

time_until_desktop_ready, time_until_desktop_visible

device_performance.boot

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

session.events

Sample indicating when a device is reporting to Nexthink

user, device

protocol, session_ID, …

RTT, latency, interaction_time, …

execution.events

Executions of a process with resources consumed

user, device, binary

CPU_time, outgoing_traffic, memory_used, …

device_performance.events

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

binary.name

outgoing_traffic

connection_establishment_time.avg

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

start_time

end_time

binary.name

outgoing_traffic

connection_establishment_time.avg

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:

execution.events during past 15min
| where binary.name == "chrome.exe"
| list start_time, end_time , outgoing_traffic, connection_establishment_time.avg 
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

cpu_usage

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

start_time

end_time

cpu_usage.avg

08:00

08:15

82% (80 + 55 + 75 + ... + 90 + 95) / 30

It can be queried with NQL in the following way:

device_performance.events during past 15min
| list start_time, end_time, cpu_usage.avg 
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.

device_performance.boots
| summarize average_boot_duration_per_state = duration.avg() by context.location.country, context.location.state 
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. 

devices during past 7d
| list device.name, device.cpus
CODE