The following is a guest post by Klaus Baumecker, R&D OpsBridge Specialist
From the BVD (Business Value Dashboard) docs, you might know that the way to connect your data with the widgets is via so-called data channels. Data channels are a kind of pipeline where the data from a specific source is wired to the widget on your dashboard. But how are these pipelines created? Data channels are a concept; nevertheless, they can be seen like real pipelines that are created when they're needed. And that can happen all the time when you send data to BVD.
All data sent to BVD is made of JSON documents. And the good thing is, that there is no given structure you need to obey. But how does BVD know, where to route this data, i.e. in which pipeline/channel to put it? That's by giving hints to BVD. These hints are information pieces given as URL or path parameters when sending data to BVD via HTTP POST. The URL parameters are dimensions and tags. The simple way is using tags like
Here BVD creates a channel with the name mymetric and all data that is coming from this requests will be stuffed in that channel. But what if you have a data sender that is sending not just a single metric, but multiple? Think of a service that consolidates the metrics from multiple sensors. In this case they have to go into separate channels in order to be mapped to different widgets.
In this case dimensions to the trick. But what to specify in the dimensions? Here the sender has to figure out, what identifies the different sensor data from each other? Let's look at an example of three sensor messages:
sensor: 'Sensor A',
sensor: 'Sensor B',
sensor: 'Sensor C',
It seems like they all have a sensor name in the sensor property and carry a value. That means the sensor property can be used to identify the sources and is therefore a good candidate for a dimension. Similar to the above URL you can specify dimensions with the dims URL param
Now instead of a creating a static channel name, BVD looks up the message for all properties that are dimensions and creates a channel from that. Here the channels Sensor A, Sensor B and Sensor C. That all goes automatically when sending data to BVD. The only thing you need to do is giving BVD a few hints on what differentiates the messages from each other.
Note: It is necessary, that a consolidation of different metrics has to follow the same schema, at least they all should contain the same identifying (dims) and value properties
And in case the 3 sensors do not send a single metric but many of different type, then a message would look like this:
sensor: 'Sensor C',
Now sensor alone as dimension is not enough. We need to add another dimension: type:
And in the rare case, where you might have sensors that are replicated onto multiple sites (like in a backup data center) they might send data which is using the same dims and the same values for sensor and type, but actually come from multiple sites. They would send data which ends up in the same channel, which would be bad. Now tags can help you again by adding another static name prefix per each data sender, like so