Your sensors continuously test your networks and applications from an end-user perspective and report the results to the UXI dashboard. Many users have requested an automated way to output the data in order to:
Create custom reports and summarize the test results over a time-range that the user can specify and control
Build custom dashboards in external platforms to visualize the test results along with that of other network and application monitoring systems
Perform ad-hoc analysis and look at the data in different ways, so as to troubleshoot issues in more detail
Using the Data Push Destinations feature allows you to configure your UXI dashboard to send test result and issue data to a destination that you manage. The current options are AWS S3, Google BigQuery, Elasticsearch, Splunk (Beta) or a you can setup a generic HTTP endpoint for data to be sent by our UXI cloud.
Before you begin:
Please be aware that it is not uncommon for delays in our data pipeline. UXI does not have any SLAs, although we try and resolve issues as fast as possible. When resolved, the data pipeline will resume where it left off on a best-effort basis and attempt to retain seven days of data while in an error state. Any mechanism you use to consume the data sent by our cloud service should have the ability to backfill the data. In addition, the UXI data push will attempt “at least once delivery”, you may occasionally get duplicate messages.
We currently support sending data to the following destinations.
If you have any specific destination requests, you can enter these feature requests in Aruba Innovation Zone.
Types of Data
We currently support sending test result data, issue data and incident data.
Test result data is the largest set of data as it includes sensor test results when a test is successful. For example DNS lookup time was 35ms or a ping to google.com had 50ms latency, 10ms jitter and 0% packet loss. Here is the full test result schema.
Issue data is the set of issues detected by a sensor. For example DNS resolution failed or an application was unreachable. Issue data will contain the first confirmed message and resolved message of an issue as well as issue updates if the issue is added to an incident (only if you are using the Incident Detection feature). The issue data includes all issues, regardless of whether Incident Detection is enabled or whether mutes are applied. If you are only interested in being notified of incidents, you can enable the webhooks, email notifications or the incident data below. Here is the full issue schema.
Incident data is available if you are using the Incident Detection feature. Using the Incident data, you will receive a message when an Incident is detected (ONGOING) and another when the incident ends (RESOLVED). Here is the incident schema.
The amount of test results depends on how many sensors you have and tests you have configured. Each test result is approximately 1 KB when stored in S3. Using that as a reference, the below table provides a high-level guide so you can plan accordingly.
The issue data is less, an estimate will be provided shortly.
Allow UXI IP Addresses
You may want to restrict communication to only allow connections from the UXI cloud. The following UXI IP addresses should be allowed to communicate with the destination.
Delete a Data Push Destination
To delete a data push destination, go to Settings > Integrations. In the Data Push Destinations table, identify the integration you want to delete and select the pencil icon to edit.
On the resulting Edit modal, choose the bin icon in the lower left corner of the modal to delete the integration. You will be asked to confirm this action.
If you reconfigure the same destination, the data will begin from when you reconfigure the data push destination.
Check the Status and Restart a Data Push Destination
You can view the current status of the data push destination under Settings > Integrations > Data Push Destinations. If the status is “Error”, you can click the + icon and expand to see a stack trace of the error. This helps debug invalid credentials, misconfiguration, reachability, or availability issues with your destination.
If the data push destination goes into a failed state, it will periodically attempt to restart. To restart a failed data push destination manually, you must change some aspect of the configuration, such as the URL, bucket name, or credentials. If the integration goes form a working state into an error state, the integration will attempt to retain up to the last seven days of data. Once restarted, the integration will attempt to resume where it left off on a best effort basis.
What can I do with Data Push Destinations?
Here are some examples of using the Data Push Destinations feature:
We will be updating this section of the help article with some examples soon, check back for more!