[Index]
A sysadmin administrator can access the System Monitoring menu (menu model: data/SystemMonitoringConfig) to manage:
Default values are set in an instance called Global.
Alerts
From the Alerts tab on the Configuration menu, the following settings and options can be managed:
Database:
Transactions:
Transaction Queue Size Threshold: Count when alert is enabled. The default count is 500.
Maximum time in 'Queued' state (hours): Time since last transaction update of a queued transaction before an alert is enabled. The default time is 6 hours (maximum:48h, minimum: 1h).
Maximum time in 'Processing' state (hours): Time since last transaction update of a processing transaction before an alert is enabled. The default time is 6 hours (maximum:48h, minimum: 1h).
Transaction Failures to Alert: errors for operations on model types.
The default operation is all Import operations on all data models (data/*)
For the configured alerts, platform-level notifications can be generated upon failure of the transaction in two ways - using the notify command on the platform CLI:
Note
Either or both notification types can be configured.
Refer to the Warnings and Notifications and SNMP Configuration topics in the Platform Guide for notification setup, details and examples of the SNMP traps.
Note
It may take up to 2 hours from the time that a transaction is considered hung/stuck to the time that an alert is created. Thereafter, there will be at least one alert created within every clock hour. The subsequent alerts will not necessarily be fixed 60-minute intervals.
Metrics Collection
The Metric Collection tab shows:
A configurable RIS API data collector interval which is the time interval that the real-time information (RIS) data collector service polls the Unified CM to obtain the latest phone registration status information for phone instances stored in in the VOSS Automate database.
The value is in seconds and the default interval is: 43200 seconds (12 hours) Refer to the Best Practices Guide for further information if this interval needs to be modified.
Note that the Cisco RIS Data Collector service needs to be enabled and running on the Unified CM publisher.
The RIS data collector service updates the current registration status and/or IP address from the Unified CM Registration Status and IP address at the specified interval - for all clusters in the system. The Phones list view show Registration Status and IP Address columns containing this data.
The status of the collector service can be checked with the the platform CLI app status command - seen as voss-risapi_collector in the example console output snippet below:
platform@VOSS:~$ app status selfservice v19.3.2 (2020-04-18 19:27) |-node running voss-deviceapi v19.3.2 (2020-04-18 19:30) |-voss-cnf_collector running |-voss-queue running |-voss-risapi_collector running |-voss-monitoring running |-voss-wsgi running ...
Note
There is also a macro function get_phone_status available to return this Phone data, given as input parameters:
a phone PKID
followed by a comma and then exactly one RIS API field name.
The fields below are for example used in the VOSS Automate Admin Portal list view of Phones:
To see a full list of available fields, run the macro function without RIS API field names or refer to the Cisco RIS API documentation.
For example:
{{fn.get_phone_status 5ca2b90bce894e0014d488fb, status}}
output: "Registered"
The sysadmin user defines a list of Models to Aggregate on the Metric Collection tab of the Configuration menu (menu model: data/SystemMonitoringConfig). By default, the following models are included in the list:
device/cucm/CallPickupGroup device/uccx/Agent device/uccx/Team device/uccx/ContactServiceQueue device/uccx/ResourceGroup data/BaseSiteDAT device/cucm/User device/cucm/Phone device/cucm/HuntPilot data/InternalNumberInventory data/HcsDpE164InventoryDAT device/cucm/Line device/cucm/User device/cucm/DeviceProfile device/cuc/User device/spark/User
For these models, counts are collected daily. Daily, weekly and monthly aggregates at a particular hierarchy: Provider, Customer or Site are then stored as a Grouping. In other words, the counts include all hierarchy nodes below the particular hierarchy.
In the instance details, the Group Number is then the nth day, week or month of the year.
Note
For daily aggregates, only the most recent daily aggregate of the week is stored. Previous daily aggregates are aggregated into this daily aggregate and are then deleted.
A particular daily or weekly Model Counts instance will then show the Average Count of instances as specified in the Models to Aggregate list.
The data is also displayed as usage charts on the Admin Portal.
Stores aggregate metrics for resource counts per Site/Customer hierarchy grouped by week or month.
Title | Description | Details | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Year * |
|
||||||||||||||||||||||||||||||||||||||||||||||||
Grouping * | The period over which the metric aggregation relates to. Valid options are "Month" and "Week". |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Group Number | Unique identifier for a aggregation period. Example: if grouping is by month, a value of 1 implies January. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Group Start Date | The start date for this aggregation group. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Group End Date | The end date for this aggregation group. |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Counts by Model Type | Array of model type counts |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Model Type * | Model Type to be listed for counts |
|
|||||||||||||||||||||||||||||||||||||||||||||||
Average Count | Average number of instances of model types of a given type at this hierarchy and below over the group period. |
|