Dashboard snapshots

[aalpern]

trafficstars

Riffing on a comment from @bitprophet in the #metrics channel. Useful dashboard snapshotting doesn't have to mean attempting to render a static version of the dashboard to paste into a ticket system or anything like that. In fact, we can be much more useful than that.

A snapshot should just be a record of:

• the dashboard definition
• absolute time boundaries
• a text field for a description (in Markdown, natch)
• and for bonus we can store the actual data series as well

The definition and data series are both JSON blobs. Storing the data ensures that the snapshot will remain valid after the data ages out of our Graphite storage. Likewise, the definition is needed in case the dashboard changes in the future.

Pretty straightforward to render -- the existing query map just gets the string targets replaced with the ds.models.data.Query instances, serialized to JSON. load() just looks to see if it already has data, and fires the DATA_AVAILABLE event immediately, instead of calling out to graphite. :boom:

Needs 1 new database model object/table (DashboardSnapshot), a set of API endpoints to manage snapshots (/api/dashboard/<id>/snapshot), and a new front end template page (dashboard-snapshot.html) that removes some of the interactive elements of dashboard.html (i.e. range selector, auto refresh menu, etc...)

Oh, and obviously a little UI chrome to take a snapshot, edit the description, and access them from the dashboard listing.

[aalpern]

Tagging

Allow tags on snapshots, so multiple snapshots can be associated via tags. Possible API endpoints around snapshots:

/api/snapshot [GET] List all snapshots for all dashboards /api/snapshot/<id> [GET, PUT, DELETE] Retrieve, update, or delete a single snapshot /api/snapshot/tagged/<tag> [GET] Get all snapshots tagged with /api/dashboard/<id>/snapshot [GET] List all snapshots for dashboard /api/dashboard/<id>/snapshot [POST] Create a new snapshot for dashboard , passing the full dashboard + definition + data + snapshot metadata as initial state

[aalpern]

API Representation

{
  "id" : "37",
  "href" : "/api/snapshot/37",
  "item_type" : "dashboard_snapshot",
  "dashboard_href" : "/api/dashboard/12",
  "view_href" : "/snapshots/37",
  "from" : "<iso timestamp>",
  "until" : "<iso timestamp>",
  "description" : "Markdown formatted text",
  "tags" : [ "api", "OPS-6572", "production-incident" ],
  "dashboard" : {
    /* ... */
  },
  "definition" : {
    /* ... */
  },
  "data" : {
    "query_name_1" : [
      { "key" : "series-1",
        "datapoints" : [ /* etc... */ ] }
    ]
  }
}

[aalpern]

Snapshot viewer mockup:

[aalpern]

If the dashboard is templatized, the snapshot should save the template variables as well (but save expanded definition)

[aalpern]

Another suggestion from @rcoder - render a snapshot out to a self-contained HTML file. For static rendering we could encode all the PNGs as data URLs, or we could embed all the query data as JSON in a <script> tag.

[obfuscurity]

Love the idea of graph snapshots. This is very similar to a feature I started (but never quite finished) in Descartes.

https://github.com/obfuscurity/descartes/blob/master/lib/descartes/migrations/004_AddGists.rb https://github.com/obfuscurity/descartes/blob/master/lib/descartes/models/gists.rb https://github.com/obfuscurity/descartes/blob/master/lib/descartes/routes/gists.rb

[aalpern]

@obfuscurity Thanks for the links! That's some good food for thought.

[obfuscurity]

Sure thing. I'm not sure how much of it applies since it sounds like you're mostly talking about dashboard snapshots, but you never know.

[aalpern]

https://github.com/codebox/moment-precise-range is a good addition for the "Showing X hours of data" display.