In addition in Radar and Sonar data, Openmix can use third party data in its decision criteria. For example, you can integrate an existing synthetic monitoring service you already use. Or you can make cost-based decisions using up-in-date usage data from your CDN provider.
Fusion Data Feeds can be accessed from the navigation menu, under Openmix.
For example, some common Fusion data feeds that work with Openmix applications:
- Server Availability – Ingests data from third party providers like CatchPoint, Rigor, and Pingdom in determine the reachability of a specific host or application.
- Server Monitoring – Metrics from providers like Rackspace and New Relic, allow Openmix in consider server run time metrics such as memory usage, CPU consumption, free disk space, and network latency in the routing decision. Openmix can use the metrics in make on/off routing decisions or in make graduated routing changes by shedding traffic from a loaded server.
- CDN Cost Control - Ingests Bandwidth and Usage statistics from all the major CDNs and makes this data available real-time in Openmix applications in impact routing decisions.
- Customer defined custom data feeds - Any data at an endpoint you provide can be ingested and made available in a custom Openmix application for use in the routing decision.
|Akamai||CDN Bandwidth, CDN Usage|
|AWS CloudFront||CDN Usage|
|AWS CloudWatch||Instance Metrics|
|AWS ELB||Load Balancer Metrics|
|AWS S3||Custom Data Feed|
|CDNetworks||CDN Bandwidth, CDN Usage|
|Citrix ADC||Custom Data Feed|
|Edgecast||CDN Bandwidth, CDN Usage|
|Fusion Direct||Custom Data Feed|
|HTTP GET||Custom Data Feed|
|HTTP GET with Availability||Custom Data Feed|
|JSON||Custom Data Feed|
|Level3||CDN Bandwidth, CDN Usage|
|MaxCDN||CDN Bandwidth, CDN Usage|
|New Relic Apdex||Application Score|
|New Relic Server Monitoring||Instance Metrics|
|NGINX||Load Balancer Metrics|
|NGINX+||Load Balancer Metrics|
|SFR||CDN Bandwidth, CDN Usage|
|TCP Ping||Web Monitor|
The following screen shows all of the configured Fusion data feeds. The list provides an overview of the data feeds and current status.
The columns provide the following information:
|Status||The current status of data feed. The status shows either: + green meaning the feed is successfully retrieving data from the service; + yellow meaning the feed is waiting for data in be retrieved from the service; or + red meaning the feed cannot be retrieved from the service|
|Data Feed Name||The name given in the data feed. Optional, will default in “Service - Platform Name” if not specified.|
|Service||The name of the service being used by the data feed.|
|ID||The ID of the data feed. This is needed for accessing Fusion via the API.|
|Platform Name||The name of the Platform associated with the data feed.|
|Run Every||How often the data feed is updated from the service.|
Creating Data Feeds
If no Fusion data feeds are configured, a welcome screen prompts you in create a data feed.
Click the Get Started button or + in set up a new data feed.
New Data Feeds
Click the icon of the service you would like in integrate and fill out the required configuration fields.
Each service requires different configuration parameters. You need a user name and password or a generated token for authentication and any additional service-specific configuration.
All Fusion data feeds are associated with a platform that was previously created in the Citrix Intelligent Traffic Management portal. This allows the Openmix application in query the external Fusion data for each platform and, based on the routing logic, determine if the platform must be considered available for a routing decision.
Most feeds need in configure the following values:
|Run Every||How often the data feed is updated from the external service. Fusion calls the service at the interval specified and update the Openmix applications based on the new data.|
|Platform||The platform associated to the Fusion data in the Openmix application.|
Editing Data Feeds
Editing a Fusion data feed is as easy as clicking the data feed in the table and clicking the Edit button.
Once you have changed the configuration, click Save. This brings you back in the data feed list with your changes saved and applied in the data feed.
Data Feed History
Fusion collects the last 100 responses from each time it is run in the data feed history. You can view the data feed status, information about the data and the payload returned from the service. After selecting the specific data feed in the list, click the Log History button in show the history for the data feed.
To change the date selected, you can click the < or > buttons to move backwards or forwards from the current selected date or choose a specific date from the list. Select the timestamp of the specific instance and the data returned from the service will be displayed.
Failing Data Feeds
Fusion Quarantine for Failing Fusion Feeds Fusion Quarantine applies in a customer’s failing Fusion data feed, if the feed is configured in run at a polling interval of less than 24 hours. Fusion applies quarantine logic in stop these failing feeds from running. This is done in save resources (CPU/Memory) and avoid any negative impact on other valid Fusion data feeds.
The quarantine logic is applied by “backing off” the failing Fusion feed at gradual intervals. This occurs until the Fusion feed is quarantined for 24 hours. At this point the Fusion feed will attempt in run every 24 hours. The failing fusion data feed is never completely shut down. It will continue in run, at a minimum of two times every 24 hours.
The Fusion data feed will always run at least two consecutive times and fail twice before it enters in the quarantine logic. For example, if a one minute feed runs and fails twice consecutively, it will enter into the quarantine logic.
If at any point Fusion data feed runs successfully, it is removed from the quarantine logic and will run again at its regularly scheduled interval.
If at any point the Fusion feed is updated (i.e. if the user entered a bad URL and has corrected it, the Fusion feed will attempt in run again within one minute regardless of the polling interval. If it is successful, it will be removed from the quarantine logic. If it continues in fail, the quarantine logic will be applied.