Grafana: Postgres Data Source | Hacker News Reader

Grafana: Postgres Data Source

github.com

128 pointsscrollaway21 comments

Great timing. I was considering building a monitoring setup based on Influx and hookung up Grafana to it. Now, I can play with timescaledb and Grafana instead. Don’t know the technical advantages/disadvantages of timescaledb over influxdb. If any of you had any experiences with them, pls share.

I haven't tried timescaledb yet because it's not available on RDS (see https://github.com/timescale/timescaledb/issues/65 if you want it on RDS btw). But I really can't wait to try it. My understanding is that it's resource-hungrier than Influx but to be really honest, influx has been super unreliable for me with metrics disappearing, very hard to do maintenance on it (eg. how do I find out where my disk space usage lies? etc)

Postgres' maturity is something I miss every single day I deal with influx. I trust postgres' data integrity and tooling every day of the week and I don't have that with Influx.

I have a very similar experience. Also the lack of support for any query more complicated than a freshman’s SQL is often bothering me.

Hey, thanks for the shout out :)

In terms of resource-hungry-ness, while we haven't done extensive benchmarking on memory & CPU against InfluxDB, we should compare fine on those resources. The one area we do fall behind is disk usage, but with ZFS or the like we can close the gap.

Thanks for the support! Hopefully we can get it on RDS soon.

It's in 4.6.0-beta1; I've been playing with it a bunch, it's really nice for single stat and when you have time series tables.

Also worth bringing up: http://www.timescale.com

Anyone using Grafana in production? I would like to hear some opinions and experiences. I found it a bit disappointing as in; at first impression it really looks amazing, and the charts are stunning. However once you go into the knitty gritty and find lacking user/role/permissions management it was disappointing.

Grafana is incredible and 4.6 fixes my two major issues with it (no cloudwatch alerting and no postgres support).

It does take some training to get good at writing dashboards however. But it's free to try by either self-hosting it or with the personal plan on https://grafana.com. Highly recommended either way.

Why would permissions matter so much?

We use it, good experiences so far.

Giving different teams and outside partners (i.e. less trusted) access to a variety of dashboards, not just due to security but also to make it less confusing to these users.

Grafana supports LDAP out of the box.

Did they ever make it suitable for exposing to the public Internet? I've been wanting to embed Grafana charts in a public page [1] for a while now because they're just so much better than the other charting options out there.

[1] https://mhkweather.com

AFAIK, you can expose read only versions of graphs for embedding into pages these days

As arianvanp has pointed out, you can indeed create public read-only snapshots to share.

You can either create local link to a read-only version of what you're looking at right now. Whoever wants to access it, must be able to access the grafana host. Alternatively, you can upload the snapshot to the raintank site. I have just exported a snapshot of a panel on one of our dashboards, with only one of the panels' data, see https://snapshot.raintank.io/dashboard/snapshot/II7NYMU3v9vT... for an example. You can zoom in, but not further out.

You can also generate an iframe embed code (for a single panel), but if you want to share that in real-time publicly, you'd need to expose grafana to the public internet.

You can embed from a shared snapshot at raintank, as well. See the one above, if you click the title, you can 'Share' that and then embed it.

I use Grafana for everything. At work a part of every feature I do is a Grafana graph to monitor when the feature goes to production. At home I graph my blood glucose having information such as A1c always available for me real time.

Such a useful tool.

Yes, we usa grafana in our team, but only isolated on internal network and with access only to 12 team members, so no real need for roles etc. We use zabbix, elasticsearch and graphite data sources. Works like a charm in our case, also embedded graphs are not ideal, but useful for internal dashboards and etc. So very positive experience so far. Before grafana integration we had kibana + graphite + zabbix as a 3 separate things.

I use it every day against a (multi-tenant) Prometheus back-end. You have to put in quite a lot of effort to design the right queries and charts, but after that it works great for my needs.

We prefer to have dashboards under source control so generate them using grafanalib - see https://www.weave.works/blog/grafana-dashboards-as-code/

I think this approach shifts the need for roles and permissions as we never save dashboards from the UI.

I've found the opposite to be true, once you get into the knotty gritty there's so much that can be customized to different use cases. You can have different organisations and 4 levels of user roles. Lots of ways to handle authentication, a great API so everything is scriptable and lots more. It may not quite fit your needs but there's been a lot of effort put into the details. I'd been interested to know the specifics of what you couldn’t achieve with it?

Also, from what I've gathered the frontend can execute whatever query it wants on the backend without any kind of checks.

I first came to know about Grafana via the Wikipedia’s webpage performance management page: https://twitter.com/mediawiki/status/630865572654264320

Interesting talk from the Wikipedia folks here: https://www.youtube.com/watch?v=UlL6UoRUQAM

That is an unacceptably big change set for a proper review process.

Seems to be a collection of many commits squashed into one. Probably during review, each commit was addresed.

Reply on news.ycombinator.com