Support User-Provided Static Asset Serving Directory about prometheus

[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.