Improve Dashboard page

[brylie]

Story

As an API Manager I want to see data visualizations when I click on the dashboard link So that I understand how my API is being used

Challenge

The Dashboard screen does not display any information. When a user clicks to view the dashboard and sees a blank page, it is somewhat disorienting.

Components

• User Experience
• Presentation

[brylie]

jslate.com is a good example for a dashboard interface where users can create and customise multiple dashboards. I.e. any given user/organization may have the need for multiple dashboards.

[brylie]

The Dashboard project by Open Knowledge Foundation may be useful.

[brylie]

Responsive Dashboard has a clean, responsive interface.

[brylie]

There is a nice collection of Responsive Bootstrap Dashboards

[55]

Dashboards by Keen IO looks really nice. Also, I've found sDasboard, which can be used for a dynamic customization and rearrangement of the dashboard.

[brylie]

What are your thoughts on Kibana, as a potential analytics platform for API Umbrella? How could the ELK components be of benefit to the API Umbrella platform?

[mattmo]

I really like the idea of using Kibana, given that the current analytics system for API umbrella is based on Elasticsearch.

On Mon, Nov 24, 2014 at 4:39 PM, Brylie Christopher Oxley < notifications@github.com> wrote:

What are your thoughts on Kibana http://www.elasticsearch.org/guide/en/kibana/current/rows-and-panels.html, as a potential analytics platform for API Umbrella? How would the Elasticsearch and Logstash components be of any benefit to the API Umbrella platform?

— Reply to this email directly or view it on GitHub https://github.com/NREL/api-umbrella/issues/62#issuecomment-64291487.

[GUI]

Yeah, we've considered Kibana in the past (see https://github.com/NREL/api-umbrella/issues/15 and https://github.com/18F/api.data.gov/issues/136#issuecomment-61127743). I admittedly haven't gotten super deep with Kibana when I've looked at in the past, but I think it's definitely worth another look.

As Matt mentioned, since we already store all our analytics in Elasticsearch, Kibana's something that could provide a lot of functionality out of the box. I have a few general hesitations based on the previous times I've looked into it, but again, I think it's worth a deeper dive. But just to document things, here's what I've seen in the past and what my hesitations have been:

• Inability to prevent overly-complex queries: Since Kibana serves as a pretty direct interface on top of ElasticSearch, it doesn't seem to have a lot of mechanisms in place to prevent complex queries that can kill the ElasticSearch cluster. Admittedly, we're not doing a great job of preventing these types of queries right now either, but it is something we could address with a custom analytics UI, where we're able to better control what types of underlying ElasticSearch queries get executed. Kibana's approach seems more geared towards fully exposing ElasticSearch's capabilities, with the assumption that you're a sysadmin responsible for the underlying ElasticSearch cluster (at least that's been my take). However, it's also worth noting that they do seem to be mitigating some of these underlying issues with ElasticSearch 1.4 and the request circuit breaker which attempts to prevent overly complex queries from killing the system.
• How to integrate with our admin permissions: We recently rolled out updates for our primary stakeholder, api.data.gov, which limits each administrator's view of analytics so each administrator can only view their own organization's analytics (so Agency A admins can only view the analytics for Agency A and not the analytics for Agency B). I'm not exactly sure how we would implement such restrictions in Kibana, since again, it seems like it assumes you should be able to view and query everything (but I might be wrong about that).
• Overall system integration: Related to the above issue, but just the overall issue of how we would integrate Kibana into our stack. With Kibana 3, this actually looked relatively straightforward, since it was just javascript and CSS we could embed anywhere. But with Kibana 4, it looks like they're moving back to a server-side approach, so that would require more investigation with how we could run that server-side component and tie it with the rest of our admin.
• Implementation stability: I've been loosely following Kibana for a while now. When I first looked into it, I think they were making the transition from their first implementation in PHP to a server-side Ruby implementation. Then with Kibana 3, they moved to a purely client-side JS implementation. Now, with Kibana 4, they appear to be moving back to a server-side component using JRuby. Hopefully things will start to settle down with their more formal ownership by the ElasticSearch team, but given this churn, it makes me a little nervous if we had to do a significant amount of work to integrate things like our admin permissions into Kibana.
• Intuitiveness: Okay, this is probably totally ridiculous to bring up, since Kibana offers a lot of functionality and visualizations that we don't currently have. Plus, our own analyytics UI could also certainly be better, but I'll shamelessly nitpick anyway. Basically, every time I've used Kibana, I have to admit to being pretty confused by the UI. It's super powerful, but even for our rather technical audience, I wonder if it's a bit too much. Because Kibana's a pretty raw and generic tool on top of any ElasticSearch instance, I feel like you have to know a lot of the intricacies of ElasticSearch to really put it to effective use. Some of this could obviously be helped by pre-made dashboards, but I still worry about how raw the view of data is, and I'm not sure there are easy ways around it (for example, something as simple as providing friendlier field names and descriptions than what the fields are actually stored as in the database). In my mind, some of these usability issues might be easier addressed with our custom analytics views, where we can simplify things and tailor the visualizations for API usage purposes. On the other hand, we haven't gotten around to a lot of that yet, and I don't want to reinvent what Kibana could be doing for us.

If anyone has more Kibana experience, it would be great to know what you're general experiences with it have been. Or if you have any thoughts on any of the above issues, those would also be great to hear. But I definitely want to give it another gander, and I plan to take a closer look at Kibana 4.

[brylie]

How to integrate with our admin permissions

I am not very familiar with Elasticsearch, but it seems that the access control might be performed using scoped aggregations. I.e. each user query has a server-side scope such as apiOwner: userId or accessList: ['user1', 'groupA', 'organizationX'], so that only authorized API data is returned.

[brylie]

How to integrate with our admin permissions

After a bit more searching, it seems Elasticsearch are creating a new project called Shield, which has role-based access control.

[brylie]

We recently rolled out updates for our primary stakeholder, api.data.gov, which limits each administrator's view of analytics so each administrator can only view their own organization's analytics (so Agency A admins can only view the analytics for Agency A and not the analytics for Agency B).

@GUI, how does API Umbrella restrict access to Organization analytics? Where in the code should we look? We want to align our Apinf project with API Umbrella, where possible, and this is a shared need.

cc: @bajiat @ccsr