Data organization

Data organization layers

The Nexthink data model follows a hierarchical organization with tables comprising namespaces. These tables, in turn, store information in fields.

Namespace

A namespace groups information around a particular functionality or category, e.g., devices, campaigns, remote actions and sessions, ensuring consistency and clarity of data.

Table

Namespaces include tables, which are sets of objects or events and their characteristics stored in fields.

Field

A field is a property or a metric attached to an object or event. Fields are stored independently in a table or grouped by topics within the table.

A field can refer to:

• Property: describes characteristics such as the name, size or time.

• Metric: numerical value such as cpu_time, memory usage, or traffic related to a running process. Only fields from the event tables can be metrics. Refer to the Data we collect and store page for information about how the system aggregates metrics.

Fields have the following attributes:

• Name: name as it appears in the NQL query in snake_case.

• Label: natural language version of the name.

• Description: longer explanation of the value and how it is computed.

• Data type: attribute of the value stored in a field. This dictates what type of data a field can store. Refer to the NQL data types documentation for more information regarding data types.

Example

Refer to the visual representation of the device namespace below. It contains one table named devices, which lists objects referred to as devices. Some device properties do not belong to any grouping, such as name, local_admins, firewalls. Other properties that belong together are captured in groupings such as Collector, hardware, operating_system, public_ip and virtualization.

The hierarchy is reflected in the NQL queries. For example, you can query devices with NQL to get a list of CPUs and operating system names for each device. At the root of these NQL queries, devices is an alias for device.devices. The namespace is implicit. The structure applies to other tables.

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

In the query results below, table columns represent the fields.

Refer to the NQL data model page for a complete overview of namespaces, tables and fields.

Table associations

Tables are associated, allowing you to combine the data from one table with another to gather meaningful information and conclusions about your IT environment and employee digital experience. With the NQL data model, create queries that include fields from both the table you query and the associated table.

Table association guidelines

• Events tables are associated with one or more inventory objects they relate to, e.g., the device_performance.events table is associated with the devices table.

Exception: The execution_summary table from the remote_action namespace is not associated with any inventory objects

• Configuration objects are associated with events from the same namespace, e.g., the monitors configuration objects table is associated with the alerts events table.

• Events tables from the execution, software_metering and web namespaces are associated with related tables from the applications namespace, e.g., the web.errors table is associated with application.applications, and the web.page_views is associated with application.pages.

• Inventory object tables from the device namespaces are associated with the devices table, e.g., antiviruses, cpus or disks are associated with devices.

Context

The context of an event contains some properties of the associated objects at the time the event happened.

To illustrate, here is a breakdown of the average boot times per state to discover location-based slowness.

device_performance.boots | summarize average_boot_duration_per_state = duration.avg() by context.location.country, context.location.state

Location Country	Location State	Average boot duration per state
Canada	Alberta	26s 634ms
Canada	Ontario	29s 518ms
Canada	Quebec	43s 672ms