Description

Telemetry Monitoring is a subsystem of the agent that periodically collects CPU, storage/disk, memory, and network metrics of the system on which the agent is running. The primary purpose of Telemetry Monitoring is to enable an administrator to monitor system metrics of interest appropriate actions can be taken depending on the values of the metrics.

...

In this document, the Telemetry CPU page will be described, but the other pages behave similarly.

...

Creating and Editing a Telemetry Monitor Configuration

...

When ‘Add' or 'Modify’ are selected as shown in Figure 2, the configuration editor form will be displayed as seen in Figure 3. Then the user can select the desired fields that control the telemetry data to be collected. The following procedure describes the available configuration settings that are available and how to configure them:

1. Schedule Configuration: This selects the frequency at which telemetry metrics are collected from the system. A user can use the drop-down selector at the top of the form in Figure 3 to configure the collection frequency. The available options are Minutely, Hourly, Midnight, or Custom. If custom is selected, the user will be prompted with an additional textbox where a cron format time must be provided. An example may be as follows:
   

   

   In this example, */15 * * * * was selected which schedules collection to be performed when the system time is a multiple of 15 minutes (00:00, 00:15, 00:30, …). Other examples may be:
   0 */6 * * * defines a schedule that runs when the time is a multiple of 6 hours (00:00, 06:00, 12:00, 18:00)
   0 0 1 * * defines a schedule that runs every month at midnight (1st Jan 00:00, 1st Feb 00:00, …)

2. Metric Configuration: Users are provided checkbox options that select the metrics to be collected. For the example shown in Figure 3, there are 4 available CPU metrics that can be configured. If multiple are selected, then multiple events will be generated; there will be an event generated for each metric selected. Additionally, CPU, Disk, and Network have an associated 'InstanceName' which refers to the interface name of the component. Note that there may be multiple instances for a given telemetry type. For example, there may be a single policy for Disks as in Figure 4 below.
   

   

   
   This results in the collection of events from each of the instances of Disk - one for storage interface on the system as is seen in the following screenshot:

   

   
   The available metrics for each telemetry type are as follows:

   1. CPU:

      • % Idle Time

      • % Privileged Time

      • % Processor Time

      • % User Time

   2. Disk:

      • % Free Space

      • Free Megabytes

      • Disk Write Bytes/sec

      • Disk Read Bytes/sec

   3. Memory:

      • Available MBytes

      • Committed Bytes

      • % Committed Bytes In Use

   4. Network:

      • Bytes Received/sec

      • Bytes Sent/sec

      • % Bytes Total/sec

      • Packets Outbound Errors

      • % Packets Received Errors

3. Severity Configuration: A severity level may be assigned to designate events based on the level of importance for quick identification for each destination format type ie., Snare, Syslog, CEF, LEEF using the drop down lists.

   • Snare - Critical, Priority, Warning, Information, Clear

   • Syslog - Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug

   • CEF - 0 - 10, 0 is least severe and 10 is most severe

   • LEEF - 1 - 10, 1 is least severe and 10 is most severe

Saving and Applying Telemetry Monitor Configuration

To save and set the changes to the above settings, and to ensure the registry has received the new configuration perform the following:

...