Viewing metrics

To view the system status data, do the following:

1. Go to the web interface of the self-diagnostics service: http://127.0.0.1:20040/.
   

2. Select the required metric in the list (1) or enter the query in the Expression field.
   

   Metric	Description
   ALERTS_FOR_STATE	Troubleshooting by the self-diagnostics service. ALERTS_FOR_STATE{alertname="ipint_is_not_activated",ep_name="hosts/Server1/DeviceIpint.99",instance="127.0.0.1:20108",job="ngp_exporter",ngp_alert="true"} Possible values of the alertname parameter (see General information about the self-diagnostics service): low_os_memory—out of RAM; ipint_is_not_activated—camera is connected, but does not send data; no_samples_in_detector—no events from a detection tool; restart_services_when_archive_source_not_activated—the archive is not working; restart_services_when_no_samples_in_archive—recording to archive with 0 FPS; restart_services_when_no_ping_from_detector_to_archive—no recording to the archive of an event from a detection tool; logs_disk_space_is_low/db_disk_space_is_low—out of system disk space.
   ngp_archive_channel_fps	The frame rate of all video cameras recording to archive
   ngp_archive_volume_size	The current size of the archive volume in bytes
   ngp_cpu_total_usage	The percentage of CPU load on a Server
   ngp_fps	The frame rate of all Server cameras, all detection tools and their decoders

   The request allows for:

   1. Using multiple metrics.

   2. Using expressions to find problems. For example, a query like ngp_fps <17 will return all metrics, where FPS is less than 17. For a complete list of logical and arithmetic operators, see the official Prometheus documentation.  

   3. Filtering by any of the parameters. For example, this query will return FPS values only for the specified source:

      ngp_fps{ep_name=~"hosts/TEST/DeviceIpint.2/SourceEndpoint.video:0:0"}

3. Click on the Execute button (2).

The Console tab displays all possible values of all elements at the time the query is completed.

When you set a date and time in your calendar, the data is updated.

To build a graph, go to the Graph tab. In the field 1, set the time interval of the graph. In the field 2, set its end point. In the filed 3, set the interval between the data points. To fill the chart, set the stacked (4) checkbox.

Examples of useful queries for Windows OS

1. The CPU loading graph similar to the Windows System monitor:
   

   sum by (process_id) (100 / scalar(wmi_cs_logical_processors) * (irate(wmi_process_cpu_time_total{process="AppHost"}[10m]))) or ngp_cpu_total_usage

2. The graph of RAM usage by the AppHost processes and a total memory space:
   

   sum by (process_id) (avg_over_time(wmi_process_working_set{process="AppHost"}[5m])) / 1024 or avg_over_time(wmi_os_virtual_memory_bytes[5m]) / 1024

3. The percentage of RAM usage:
   

   100.0 - 100 * avg_over_time(wmi_os_virtual_memory_free_bytes[5m]) / avg_over_time(wmi_os_virtual_memory_bytes[5m])

Examples of useful queries for Linux OS

1. The graph of total RAM usage by the AppHost processes:
   

   sum by (groupname) (namedprocess_namegroup_memory_bytes{memtype="resident"})

2. The percentage of RAM usage:
   

   100 - node_memory_MemAvailable_bytes * 100 / node_memory_MemTotal_bytes

3. The graph of the CPU load by the AppHost processes as a percentage:
   

   sum by (object_id) (rate(namedprocess_namegroup_cpu_seconds_total{groupname="AppHost"}[1m])) * 100

4. The graph of the CPU load as a percentage:
   

   100 * avg without (cpu) (1 - rate(node_cpu_seconds_total{mode="idle"}[1m]))

5. The graph of RAM usage by the AppHost processes to determine the memory leak:
   

   namedprocess_namegroup_memory_bytes{object_id=~"APP_HOST.*",memtype="proportionalResident"}