The Daily Vyopta System Report

Purpose of this Document

This document explains the intent of the daily Vyopta System Report, and how to use the information that it contains


The Report

The report contains a snapshot of the data collection health for your organisation, and is designed to provide early warning for data collection issues that, if left unaddressed, may result in data loss. 

Where possible, the report contains links to assist with the verification of your configuration and the diagnosis of problems. Additional information is provided where appropriate flagged with the **INFO** marker.

Since the report is intended to flag potential data collection issues, it is generated daily in order to allow the timely correction of any issues. 


What the Report Contains

The report contains three sections

  1. A description of the collector(s) detected in your environment, whether the version running is currently supported and whether any patches have been applied. For details regarding the supported versions, please see The Vyopta Data Collector Support Lifecycle 
  2. A table containing information for each of your enabled devices. This table contains
    • The device type and name
    • The Real Time collection status and condition
    • Information regarding historical data (configuration, call detail records (CDR), call quality records etc). The status of these items is dependant on when your collector last received data, and will flag as a warning if the data has not been recently (normally 24 hours) and proceed to an error after 36 or 48 hours (depending on system type) if data is still not received.
    • The data that the last data item (above) was received.
    • Notes and recommendations - these are obtained by examining both the logs for the device and the results of validating the device within Vyopta.
  3.  A section detailing the disabled devices in your environment. If any have been recently disabled due to authentication issues then this will also be identified


How to Read The Report

It is important to understand that this report is intended to provide early warning of potential issues - the detection of issues is therefore quite 'sensitive.'

By way of examples, here are sections from the report produced for the Vyopta Lab

The Collector Report


This shows two collectors running, each of which is currently in support. The second collector has been patched to provide a resolution to an issue or additional functionality. 

In the event of the collector being out of support, the it will appear as below, with a link to the relevant Vyopta documentation:



Enabled Infrastructure

The first example here is a CUCM from the Vyopta lab:


When reading this section, attention should be first directed to the Real Time collection columns - if the status shows an error then the configuration should immediately be checked in the Vyopta Admin Portal - the Notes column on the right will contain a link to the relevant documentation.

The above represents a system for which we can identify good data collection.  


For systems that do not have good collection, let us look at the examples below:


Here the credentials used by the Vyopta Data Collector to gather information from CMS 1 have expired - the relevant documentation links are provided in the Notes field. 

  • CMS 2 cannot be reached by the data collector, although it is able to send call data. Note that the CMS itself sends the call data to the collector rather than it being polled - the date stamp for the call data will be set as soon as the collector receives the data.
  • CMS 3 has no real-time connection issue, and configuration data is being successfully retrieved. However neither call data nor quality data are being seen from this device. 
    • In this case, the timestamps for the last seen files should be used to determine if there has been a problem - if it is known that calls were processed since the last time stamp then this should be investigated. 
    • Vyopta has no way to identify if there are no calls present or a collection issue - therefore, in the event of seeing no data the only safe action is to flag a potential issue. With only the timing of data reception as an indicator it is not possible to provide extra guidance.
  • CMS 4 has good collection with the exception of their being no quality data received. This may be because the calls were too short to generate this data, that there is a configuration issue with the device or a device fault. Again this is flagged to provide early warning in the event of issues. 

Alternatively, the real time data collection may show a status of 'WARNING,' with an indication that the real time data collection has been disabled, as below:


This does not indicate an error condition: in these cases the real time data collection has been intentionally disabled. Reasons for this may include:

  • Data being collected by other means such as as QSS for Zoom
  • A wish to prevent overuse of a rate limited API, such as with that for Pexip
  • Call data is being generated by other means, such as when a device is an endpoint registrar only.
  • No access is available to relevant APIs on the target system 

As long as the historic data is being collected, Tech Insights Analytics data will not be affected, although your data available in Tech Insights Monitoring may be reduced. 


Errors Shown for Configuration Data Collection

If a system's configuration data is showing an error this is most likely a permissions error that is preventing collection. Please review the setup according to the relevant configuration guides in the knowledge base and many any changes required.

If the condition persists after the configuration has. been verified then please contact Vyopta



In summary, when reading the Devices Enabled section of the report, it is necessary to exercise judgement and consider all of the information provided along with knowledge of your environment.


The Disabled Devices section


This section should be reviewed routinely since it is possible that this may contain systems for which we collect data on your behalf but have been disabled due to authentication issues.

In the event of a device having been recently added to this section for such problems it will be highlighted and instructions provided in the Notes column.

For all other devices, this list should be reviewed and any unwanted devices deleted in the Vyopta Administrative Portal (they can be restored at any time, in the event of need). Devices that should not be disabled should be updated and restored to service. 

Was this article helpful?
4 out of 4 found this helpful



Please sign in to leave a comment.