I would like to share some thoughts on this based on experience of being a crusty old enterprise developer. The dashboard problem keeps coming back. I think the time might be finally coming for some dashboard framework to actually succeed.
A dashboard framework has been tried many many times. Here are some old ones just on the top of my head:
* Shindig aka OpenSocial aka Google Gadgets
* J2EE portlets
* OpenUSS
I'm not sure why Shindig aka Google Gadgets failed but one of the complaint we had on a product that I helped build that used Shindig is that business users did not want the complexity of customizing a dashboard. That is hard coded panels were good enough.
I guess just like many tech stuff (slack/irc, wiki) the timing and execution just wasn't right. I think now that might change given the plethora of devops, data driven biz, and generally improvement in tech awareness.
It would be nice if Cyclotron had some sort of spec (particularly language agnostic) but I guess that failed hard for the above.
For my own small company we use Kibana (the old one that doesn't require NodeJS), Grafana, and Jenkins.
Yes we use Jenkins as a dashboard. Jenkins is actually shockingly a good place for a dashboard because every time we build/deploy or kick off some kind of job we see the current status of stuff. I'm not sure why cloudbees hasn't taken advantage of this. I honestly think it is the best place to put devopsy like dashboards.
The other nice thing about Jenkins besides it actually kicking things off is the notification. IMO notification is almost more important and more useful than dashboards. The two should be not be far apart but for some reason in most systems they are.
I totally agree about combining notifications with the dashboard. I built up Godot2 [0] to solve this for myself. It can take any metric, including metadata, and stream to notifications via Slack, email, SMS, as well as the dash.
The incoming events have a spec, like Riemann, and is compatible with Graphite. Godot2 also has it's own mini query lang [1], which allows for easy selection of events for the dash, e.g.
service =~ 'health/machine/disk/%' and status = 'ok'
I work in an industrial manufacturing plant. My Manager is always going on about dashboards almost every week I hear something like "I'd love to see this on a dashboard" (usually referring to something on an existing printed report). He has been saying this for years and no usable dashboards have ever materialized.
I think the biggest issue is no one in our organisation has a clear idea what a 'dashboard' is exactly and how people are supposed to use them.
For some people a dashboard is a static page that gets refreshed periodically. I.E. "Lets show the current line speed in big bold 48pt font size and auto-refresh the webpage every 15 seconds."
For other people a dashboard is something interactive (drill down, selectively trend values, modify trend scales on the fly etc).
So there has always been this tension between the two use cases and we always end up with these halfhearted things (usually built using some BI package like COGNOS) which are the worst of both worlds.
At the same time a dashboard has never really been in high demand. So I think people like my manager have really failed to articulate the value a dashboard would supply.
The most promising thing I have seen recently is "Coresight" by OSISOFT (we use their PI plant historian system pretty extensively). They gave a demo that integrated control system type information (Conveyor status's, Flow meter readings, Tank levels etc) with location derived GIS data to show realtime updating maps etc which I thought was pretty cool.
> For some people a dashboard is a static page that gets refreshed periodically. I.E. "Lets show the current line speed in big bold 48pt font size and auto-refresh the webpage every 15 seconds."
What do most people use for this kind of use case, assuming changing of the values needs to be scriptable?
How do you deal with Grafana having no isolation? Do you deploy a new instance per client? Each user has full access to all datasources from what I've seen.
We use Grafana for our own internal usage (albeit we do have customer viewable analytics but it is proprietary hardcoded panes).
I suppose you are confused because of my mentioning building product based on shindig. That was a previous employment many moons ago. I now am a many hat wearing owner of a SaaS.
While I'm speaking of Grafana I find Kibana for more useful probably because we have a lower level of traffic than big boys but still produce an atrocious amount of logging. Logs are damn useful. In some ways metrics are actually a subset of event aggregation (ie logs) so I think Kibana is more useful at first.
I wasnt entirely clear in my previous comment, grafana allowed clients to issue full queries against all datasources the user has access to. So if you have one datasource with metrics of all your users and want to give them access to dashboards that only display their own data, that is not secure.
A dashboard framework has been tried many many times. Here are some old ones just on the top of my head:
* Shindig aka OpenSocial aka Google Gadgets
* J2EE portlets
* OpenUSS
I'm not sure why Shindig aka Google Gadgets failed but one of the complaint we had on a product that I helped build that used Shindig is that business users did not want the complexity of customizing a dashboard. That is hard coded panels were good enough.
I guess just like many tech stuff (slack/irc, wiki) the timing and execution just wasn't right. I think now that might change given the plethora of devops, data driven biz, and generally improvement in tech awareness.
It would be nice if Cyclotron had some sort of spec (particularly language agnostic) but I guess that failed hard for the above.
For my own small company we use Kibana (the old one that doesn't require NodeJS), Grafana, and Jenkins.
Yes we use Jenkins as a dashboard. Jenkins is actually shockingly a good place for a dashboard because every time we build/deploy or kick off some kind of job we see the current status of stuff. I'm not sure why cloudbees hasn't taken advantage of this. I honestly think it is the best place to put devopsy like dashboards.
The other nice thing about Jenkins besides it actually kicking things off is the notification. IMO notification is almost more important and more useful than dashboards. The two should be not be far apart but for some reason in most systems they are.