Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column
width50%
Panel
borderColor#CCCCCC
bgColor#FFFFFF
titleBGColor#F0F0F0
borderStylesolid
titleOn the page:

Table of Contents

 

Column

 

General information

The

To view the system status data, you need to:

...

web interface of the self-diagnostics service is available for monitoring the system statuses and analyzing its performance.

Access to the self-diagnostics service

To go to the monitoring interface, do the following:

  1. Open the web browser.
  2. In the address line, enter: http://127.0.0.1:20040/
  3. .
    Image Removed
  4. .
  5. Click the Enter button.

Interface and queries execution

The service interface allows viewing metrics as a table or graphs. To run a query, do the following:

  1. Select the

  2. required
  3. metric

  4. in
  5. from the drop-down list

  6. (
  7. 1

  8. )
  9. or enter the query manually in the Expression field.

  10. Expandtitle Description of useful metrics
  11. You can:

    1. Use several metrics at a time. The system has the following available metrics:

      Metric

      Description

      ALERTS_FOR_STATE

  12. Troubleshooting by self-diagnostics service
    1. Found and fixed malfunctions. Contains the alertname parameter with the problem type.

      Code Block
      languagego
      titleExample
      ALERTS_FOR_STATE{alertname="ipint_is_not_activated",ep_name="hosts/Server1/DeviceIpint.99",instance="127.0.0.1:20108",job="ngp_
  13. export
    1. exporter",ngp_alert="true"}
  14. Possible values of the alert name parameter
    1. Decryption of the alertname values (see General information about the self-diagnostics service) for the ALERTS_FOR_STATE metric:

      • low_os_memory
  15. − out
      • —out of RAM
  16. ;
      • .
      • ipint_is_not_activated
  17. − camera
      • —camera is connected
  18. but does not send data;
      • , but there is no data from it.
      • no_samples_in_detector
  19. − no
      • —no events from
  20. a detection tool;
      • the detector.
      • restart_services_when_archive_source_not_activated
  21. − the archive is not working;
      • —the archive recording isn't working.
      • restart_services_when_no_samples_in_archive
  22. − recording
      • —recording to archive with 0
  23. FPS;
      • fps.
      • restart_services_when_no_ping_from_detector_to_
  24. archive − no footage is recorded on detection;
      • archive—no recording to the archive at the event from the detector.
      • logs_disk_space_is_low / db_disk_space_is_low
  25. − out
      • —out of system disk space.

      ngp_archive_channel_fps

      The frame rate of all

  26. video
    1. cameras when recording to

  27. archive.
    1. the archive

      ngp_archive_volume_size

      The current total size of the archive (in bytes)

      ngp_cpu_total_usage

      The

  28. percentage of
    1. CPU load

  29. on a Server.
    1. of the server

      ngp_fps

      The frame rate of all

  30. Server video
    1. server cameras,

  31. all detection tools
    1. detectors and

  32. their decoders.

    The request allows for:

  33. Using multiple metrics.

  34. Using expressions to find issues. For example, a query like ngp_fps <17 will return all metrics where fps was less than 17
    1. decoders

      ngp_people_count

      The last captured number of people in the frame by the Crowd estimation VA detector

      ngp_errors

      Number of errors in the detectors' operation:

      ngp_skipped_pp

      Number of missed frames by the Crowd estimation VA detector due to the lack of resources for processing

    2. Apply logic and arithmetic operators for anomaly searching. The full list of
  35. logical
    1. logic and arithmetic operators is
  36. listed
    1. specified in
  37. the Filtering by any of the parameters. For example, a query like
    1. the official Prometheus documentation
  38. .  
    1. .
      Code Block
      languagego
      titleExample. All metrics where fps is less than 17
      ngp_fps < 17
    2. Faltering by metrics parameters using curly brackets.
      Code Block
      languagego
      titleExample. Fps values only for the specified source
    1. ngp_fps{ep_name=~"hosts/
  39. V-BELYAKOV
    1. TEST/DeviceIpint.2/SourceEndpoint.video:0:0"}
  40. will return fps values only for the specified source
    1. Image Added
  41. If necessary, set the time range for the data.
  42. Click the Execute

  43.  (2).
  44. button.

Viewing results:

  • The Console tab

...

  • displays the current metrics values in the table format.
    Image Modified
    When you

...

  • specify the date and time in

...

  • the calendar, the data

...

  • is updated.
    Image Modified

...

  • On the Graph tab you can create the graph of selected metrics at the specified period.

      ...

        • The 1 field—sets the graph time interval.
        • The 2 field—specifies the end graph point.
        • The 3 field—sets

      ...

        • the interval between data points.
        • The 4 checkbox—enables the display mode with accumulation (filling the areas under the graph).
          Image Added

      Examples of useful queries for Windows OS

      1. The CPU loading graph (analog of the System monitor):
        Code Block
        languagego
        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. RAM usage by the AppHost processes and a total memory space:
        Code Block
        languagego
        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:
        Code Block
        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 total RAM usage by the AppHost processes:
        Code Block
        languagego
        sum by (groupname) (namedprocess_namegroup_memory_bytes{memtype="resident"})
      2. The percentage of RAM usage:
        Code Block
        languagego
        100 - node_memory_MemAvailable_bytes * 100 / node_memory_MemTotal_bytes
      3. The CPU load by the AppHost processes as a percentage:
        Code Block
        sum by (object_id) (rate(namedprocess_namegroup_cpu_seconds_total{groupname="AppHost"}[1m])) * 100
      4. The total CPU load as a percentage:
        Code Block
        languagego
        100 * avg without (cpu) (1 - rate(node_cpu_seconds_total{mode="idle"}[1m]))
      5. RAM usage by the AppHost processes to detect the memory leak:
        Code Block
        languagego
        namedprocess_namegroup_memory_bytes{object_id=~"APP_HOST.*",memtype="proportionalResident"}
      6. To fill the chart, select the stacked (4) checkbox.