Do you know what listening to customers means for product managers? Job security! 😃 (Just kidding!)

Listening to customers can be humbling and exhilarating at the same time. Last year, between Summit, Synergy, and ServTech (US), I listened to nearly 200 Citrix users and partners describe their frustrations at not being able to run health checks on their environments. But they didn’t just vent; they also gave me several great ideas. These meetings helped us conceptualize and deliver Smart Check — a simple and elegant solution for proactive health checks of on-prem and cloud-based Citrix environments.

Launched in January 2017, this service currently supports XenApp and XenDesktop 7.x only and is in tech preview. To get started with Smart Check, read these great blog posts by CTPs Bas Van Kaam and Theresa Miller.

Despite being in tech preview, adoption of Smart Check has far surpassed our expectations. We currently have over 500 XenApp and XenDesktop sites under management, representing over 400 customers. All the customers I have spoken to, so far, have onboarded their production sites, a sign of trust that Citrix takes very seriously.

Smart Check was always meant to be a highly resilient and extensible platform. My grand vision is to enable partners and Citrix administrators to develop custom checks and deliver them through Smart Check. To get there though, we all need to understand how Smart Check works. In this blog series, I plan to unveil the inner workings of Smart Check with the hopes of engaging with potential tool developers who intend to build custom checks and alerts.

How Smart Check Works

Under the hood, Smart Check is surprisingly simple. It consists of four building blocks: Checks, Collectors, Analyzer, and Alerts. When a check is invoked, one or more collectors are run on the target machine(s). The output of the collector(s) is uploaded to the analyzer which then processes the output and raises or lowers alerts. All raised alerts are displayed in the UI and lowered alerts are hidden. That’s it! Let’s look at this in more detail.

smart_check_architecture

Here’s a step-by-step description of how Smart Check works.

  1. Citrix admin runs check (s) OR Citrix admin schedules check (s) for a Site
  2. Request sent to Smart Check backend which deploys the appropriate Smart Tools blueprint to the primary Delivery Controller of the Site
  3. Smart Tools agent, on the Delivery Controller, runs the collector defined in the blueprint. The agent also sends periodic updates, on the status of the collector, to the backend.
  4. The collector generates output and uploads it to the analyzer.
 Output format can vary with every collector
. The output is usually a JSON or XML file.
  5. The analyzer processes the output and raises/lowers appropriate alerts.
 The Smart Check backend obtains analysis results from the analyzer.
  6. Smart Check backend displays the alerts in the UI:
    1. Alerts that were raised are displayed
    2. Alerts that were lowered are hidden

The Building Blocks

Now that you’ve seen how Smart Check works, let’s understand the building blocks in more detail.

Checks

A check is a UI “label” that indicates what component is being checked or the benefit of the check itself. For example, Site Health Check indicates that the check evaluates the health of a XenDesktop site. In reality, it checks for over 100 conditions and flags them all separately. The Update Check on the other hand looks for missing updates and hotfixes. Currently, Smart Check provides four checks and all four checks are delivered through the UI. There are no publicly available APIs or back-doors to run these checks. Here’s a link to the docs on these checks and the conditions that are checked for.

Collector

A collector is a script or tool that is run on a target machine (delivery controller, VDA, etc.) when a check is invoked. Currently, all collectors are deployed through Blueprints and executed by the Smart Tools agent.

The output of the collector is used to trigger alerts. The output can range from simple Yes/No responses encoded in JSON or XML to complex bundles consisting of logs, traces, and dumps. If you are planning to build a custom check, you need to start by building a custom collector. More on that in future blog post.

The critical thing to remember is that a check can invoke one or more collectors and a collector can be invoked by one or more checks. Therefore, when developing a collector, focus on collecting data points and leave the analysis to the analyzer. Most Smart Check collectors are implemented in PowerShell.

Tips for Tool Developers

So let’s say you have this fantastic PowerShell script that can run a complex health check sequence and generate a beautiful HTML report.

  • In Smart Check speak, your script is a collector.
  • We currently do not have a way to display your report in the UI. We are working on it.
  • We only support XA/XD 7.x. So if this script is for older versions of XA/XD, you will not be able to run it from Smart Check.
  • We only support delivery controllers, machine catalogs, and delivery groups. We don’t support other components like StoreFront and PVS or other Citrix products.
  • Your script will also need some tweaking. More details in a future blog post.

Analyzer

Citrix Insight Services (CIS) is the analyzer, or the brains, of Smart Check. It performs three critical tasks:

  • Receives and processes a collector’s output
  • Changes the state of the appropriate alerts based on the collector output
  • Notifies the Smart Check backend when alerts have been raised or lowered

The Smart Check backend queries the analyzer for the changed alerts and then displays the alerts that were raised. As the analyzer handles all the data processing and alerts management, tool developers can write relatively light collectors. This ensures that the collectors don’t have an adverse impact on the performance or stability of the target machine.

Alerts

An alert is the smallest unit of actionable information and appears in the Smart Check UI. All alerts are stateful entities and are displayed when their state is set to “raised” by the analyzer. An alert consists of a title, description, and fix recommendation. All alerts are stored in a master database in the Smart Check backend and have unique IDs. We try to include links to docs and KB articles, step-by-step fixes, and other useful information in the alerts. Multiple alerts can be combined into a single health report – another exciting topic that I will cover in a future blog post.

An alert can be triggered by multiple collectors and a collector can trigger multiple alerts. This is because every alert represents a unique condition on a target machine. For example, the fact that your site database has not been backed up in 7 days is a unique condition and is represented by a unique alert. That condition, however, can be detected by a wide variety of collectors.

One more thing. We’ve published a list of all the alerts in Smart Check. Sometime in the future, we hope to enable tool developers to raise custom alerts or alerts that are already in Smart Check. For example, let’s say you develop a comprehensive database health check tool. You could raise custom alerts AND some of the database-specific alerts already in Smart Check.

Our vision is to evolve Smart Check into comprehensive diagnostics and troubleshooting platform for the Citrix stack. We hope to enable expert administrators and partners to build and deploy tools and scripts on Smart Check, in a secure manner. Smart Check has been architected to be highly resilient and extensible. We currently have a small group of Citrix experts (employees and partners) trying advanced features like building custom checks and alerts, and giving us valuable feedback. Though we are not ready for a full-blown beta program yet, I will have some updates for you by Synergy.

syn17-d-banner-blogfooter-729x90