Support User-Provided Static Asset Serving Directory

[matttproud]

What we have right now for dashboard generation is good for ad hoc sharing but does not support good long-term persistent dashboard uses cases where additional visual elements or metadata may be required.

Thusly, I would like to envision a world where …

1. A precompiled Prometheus binary could be offered to teams, possibly packaged as a self-contained archive file with all external dependencies: the binary, the compiled-in blob assets, required shared libraries and such. We're basically here with the new build system.
2. A team can take one of these packages mentioned above and vendor it to include a set of static assets that they would like served with their Prometheus. For instance, a custom dashboard with associated templates, HTML, CSS, JS, you-name-it.

./prometheus --userAssets=/path/to/asset/root

/path/to/asset/root may contain

1. index.html or index.html.tmpl, which is used as the root handler for http://prometheus.host/user.
2. Go template files, which Go will evaluate and interpolate into rendered content for a list of publicly-defined (via contract) variables.

/CC: @discordianfish and @juliusv

[bernerdschaefer]

I like how elasticsearch does "site plugins" -- you drop some static assets in plugins/<name>/_site and ES serves it from /_plugin/<name>. You then consume the REST API from your plugin to build whatever it is that you need.

So maybe something like:

./prometheus --plugins="dashboard=/path/to/dashboard/plugin,foo=/path/to/foo"

And prometheus then serves /plugins/dashboard and /plugins/foo from the paths provided.

[matttproud]

Additionally, I would like to know what the fitness of embedding multiple of these current Javascript graphs into one page would be. I imagine that this could bog down a user's browser immensely. Maybe this could become an impetus to support server-side rastering of images for large dashboards.

Either way, we would want to offer some simple Javascript entrypoint to access graphs for a given expression and then set some parameters around scale behavior (e.g., fixed or dynamic, or logarithmic base or decimal, or automatic scientific notation/humanization of values), axis labeling, size, etc.

Just imagine a Java server that has a dashboard page like this—for the sake for argument:

Java Virtual Machine Fitness

N.B. — We would almost always use generational managed memory settings for all systems aside from things in the batch/map reduce category.

Collection Information by Memory Generation

1. New Generation: Collection Frequency and Per Collection Duration
2. Old Generation: Collection Frequency and Per Collection Duration
3. Perm. Generation: Collection Frequency and Per Collection Duration
4. Anomalies: Promotion Failure and Concurrent Mode Failure Frequencies (Two Separate Y-Axes)

Utilization

1. New Generation: Utilization v. Reservation/Committed
2. Survivor Space: Utilization v. Reservation/Committed
3. Survivor Space: Histogram by Collection Cycle
4. Old Generation: Utilization v. Reservation/Committed
5. Perm. Generation: Utilization v. Reservation/Committed

It's quite possible that you may look at this list and wonder what these mean, which is fine. But, one thing it does tell you: Axis sizing, labeling, and titling would help explain a lot of what this is.

[bernerdschaefer]

Let's talk this through in person -- it seems like more than a user-supplied static asset directory, we want 1) a dashboard builder (à la graphite) or 2) a JS graph API for building one's own dashboard.

I've already spent some time building 2, so maybe it would be of interest to build that out.

[matttproud]

Having a dashboard builder a la Graphite is fine, but I would still say that even Graphite's is sub-par. The key thing I am looking for with the static asset storage is being able to customize chrome and add useful descriptions, documentation, annotations, groupings, even playbook information for alerts, on the actual alerting system itself.

For instance, if you look at this Java stuff above, you would definitely want to provide users with some optionally-displayable documentation about "what does this mean?". If you have a graph that talks about garbage collection events per minute, someone may say, sure I get that I am seeing the rate of activities for something, but "what does the data actually tell me, and how should I interpret it?"

[bernerdschaefer]

As we discussed in person, we want two things for this:

1. Simple static asset hosting within prometheus
2. A client-side javascript library for building graphs from the prometheus API (#202)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.