graphite.wikimedia.org requires a WMF account, while grafana.wikimedia.org is completely open and exposes the exact same set of metrics.

As far as i know this is not the case and the set of metrics is not the exact same. Instead grafana was supposed to show just a subset of things accessible with graphite, excluding non-public things.

I don't know which sets exactly these are though.

I talked with ori about this, after checking the puppet manifests. I could not see either where grafana passes creds nor where it is lmited in the data it gets.

So here's the story: grafana uses the graphite rendering api which needs no creds; the rendering api has access to all the data; so we need to decide whether to lock down grafana pending security review on the data (never happened for graphite apparently, hence still locked down) or... to just shrug and open up access on graphite :-D

also: T93710

see T56713#610707 for the reasoning

graphite.wikimedia.org requires a WMF account, while grafana.wikimedia.org is completely open and exposes the exact same set of metrics.

graphite.wikimedia.org only requires a WMF account for its graphical user interface. It's API has always been open for unauthenticated access and used in https://gdash.wikimedia.org/ for example.

I guess an issue with grafana however is that the currently access policy means that anyone can write...

see this now:

https://gerrit.wikimedia.org/r/#/c/237448/

heh, well, its now behind LDAP so I guess this can be closed for now?

A few clarifications are in order:

• We do want our Graphite data and our dashboards to be open. It's part of our transparency efforts.
• Graphite is not actually behind auth, the original task description is incorrect. / is but the /render/ URLs are not behind auth and we have other (also open) sites pointing to them (e.g. gdash). Only the web dashboard designer is and that's due to some extra paranoia around discoverability purposes and possible security or performance issues. That part isn't all that useful anyway (and forks such as graphite-api have ditched it entirely).
• All that said, protecting our dashboards from vandals or accidental mistakes would be nice; we've already had at least one incident of vandalism already. We could put only the modification part of Grafana behind auth but that won't allow anyone outside of staff/NDA to contribute to our dashboards, which sucks. Plus we get no "reverts" or history for our own mistakes. Ideally, I'd prefer a system that allows us to have our dashboards under revision control (in puppet for simplicity or elsewhere for allowing wider permissions, I don't particularly mind) instead of just plainly edited in a web interface and stored in ElasticSearch. The same applies to all of our potential frontends (e.g. Tessera?).
• Grafana is now behind auth due to a semi-related security vulnerability that is going to be tracked separately. This is hopefully temporary though and while this indirectly tackles this task, this task should remain open for when we revert back to having it publicly accessible.

Also note T93710 which is similar in nature and could be potentially merged here.

Only the web dashboard designer is and that's due to some extra paranoia around discoverability purposes and possible security or performance issues.

Grafana also provides discoverability via its query editor (maybe more unwieldy but it does give you the same data). IMO disoverability is a necessary part of true transparency anyway?

All that said, protecting our dashboards from vandals or accidental mistakes would be nice; we've already had at least one incident of vandalism already.

Why don't we just switch to Grafana 2 then? It uses a DB backend with proper user and permission management (and OAuth support). You can cluster dashboards into organizations, and you can limit write (or even read) access to an organization to specific users. So team dashboards would be protected but still possible to update via the UI, without the need to submit puppet patches (that might be only moderately inconvenient for ops but terrible for everyone else), and there could be a public area where anyone could create dashboards without having to request authorization.
(Grafana 2 announcement and blog post.)

Ideally, I'd prefer a system that allows us to have our dashboards under revision control

That would be nice but most mistakes could be caught just by having DB backups (which is something that would happen anyway, I suppose).
The relevent Grafana issue is #1504.

Can we open grafana up to all WMF employees for now then? Analytics team members that are used to using it are now restricted.

Oh sorry, apparently it is. I was being asked by some analytics folks, and I think there was just a misunderstanding. Carry on!

In T108546#1627937, @Tgr wrote:

Why don't we just switch to Grafana 2 then?

Already being tracked in T104738.

Is T56713 just a duplicate of this?

Graphite's read-only API for metric values and meta views (https://graphite.wikimedia.org/render/ and https://graphite.wikimedia.org/metrics/) are both open. And Grafana has a read-only version at https://grafana.wikimedia.org. Both are open and require no authentication.

Grafana's admin mode is behind LDAP. And Graphite's web interface is also behind LDAP (has a concept of stored profiles that can be edited, and storing user queries - does anyone use those?).

This seems consistent, so maybe this task is resolved?

The only confusing part was that Graphite does not have a read-only version of its interface (as far as I know), which means there is nothing we can show at the root of that domain.

The non-admin web interface would work without LDAP, and did in the past; if you are not authenticated, it's effectively a read-only interface. That's the inconsistent part, IMO.

AFAICT graphite's web interface has been behind ldap auth since 2011 (e88fdf13 in puppet.git) but /render has always been open. Also nowadays you can't really edit/explore metrics in grafana unless you are logged in (i.e. same as graphite). From a "metrics exploration" perspective grafana and graphite seem consistent to me? (i.e. no login == no metrics exploration in the interface)

As for the _reason_ graphite's interface is behind LDAP I seem to remember some security concerns but it is a vague recollection, HTH.