At enterprise scale, companies that invest in monitoring must also find a way to set up that monitoring to ensure consistency and coverage across the entire organization. To enable this, monitoring vendors must support development tools like APIs and domain-specific programming languages in order to support strategies like “monitoring as code”: provisioning and configuring monitoring with the same software tools you use to provision infrastructure.
Enterprise-scale organizations often employ a central observability team to implement these organization-wide monitoring initiatives. Even so, individual developers throughout these companies still need to monitor their own services. These users know what they want to visualize, but don’t necessarily know (or want to learn) the programming language. For these users, a powerful and intuitive graphical UI is the most efficient way to create the charts they want.
SignalFx has always had a great visual experience for service owners. Over time, we’ve added an increasing number of API-driven capabilities to enable monitoring-as-code, but the experience of charts created in our clickable UI looked very different from charts created through our APIs. Until now, we’ve been serving both of these audiences, but addressing them separately.
We’re excited to unveil a feature in SignalFx that allows users to easily view and edit charts using both the SignalFlow query language and our graphical UI.
Translating Charts to SignalFlow and Back
In the Chart Builder, you’ll see a new control that says “View SignalFlow”.
When you click it, you’ll see a fully-featured SignalFlow editor for your chart. After you’re finished making edits, click “View Builder” to turn it back into the graphical builder you’re used to.
This simple-looking control represents a major effort on our part to standardize SignalFx charts on a new query language, then upgrade all existing charts to that new version. We’ll dive into the detailed engineering perspective in a follow-up to this post.
The seamless transition between our SignalFlow language and our plot-builder interface allows you to:
Create Charts in the UI, Then Store the Signalflow Definition in Your Monitoring-As-Code System.
Create and maintain your charts using whatever tool suits the occasion: through the API for initial creation or large-scale updates, or with the UI for point edits and customization.
Create Charts Programmatically, and Let End-Users Edit Them in the UI.
If your company uses tools like Yelp’s SignalForm or Nike’s signal analog to create charts along with new infrastructure or services, the charts you create programmatically can now deliver exactly the same experience as charts that were created through the SignalFx UI. This means if someone builds a chart by writing SignalFlow, the viewers of that chart don’t need to know SignalFlow in order to understand how it works.
Use Advanced SignalFlow Features for Charts, While Maintaining a Great Visual UI Experience.
Some neat tricks that you can do in SignalFlow, like defining your own functions, are too complex to represent in a point-and-click interface. But even if we can’t represent your chart in the graphical plot-builder, you still get a great UI experience for editing SignalFlow and seeing immediate results.
Learn About SignalFlow Using Graphical Building Blocks.
Quickly and easily view the SignalFlow behind a chart as a learning aid. You can edit the query and see immediately how your changes affect the chart presentation — then switch back to the plot-builder to understand how your change maps to operations you’re already familiar with.
Get Started Today With SignalFx
We’ve published guidelines for writing SignalFlow that can be represented graphically in our UI. To get started, just open the Chart Builder and click “View SignalFlow”. The SignalFlow docs are right over here. Happy charting!
In Part II, we’ll describe the theoretical differences and tradeoffs between driving visualization through UIs and domain-specific languages like SignalFlow. We’ll talk about why we decided to support both, and how adherence to sound software principles made it a simple choice — though not easy to build.
This post features contributions from Rebecca Tortell and Aaron Sun.