Anyone else have custom dashboard fatigue? I'm pretty tired of seeing custom dashboards written for different pieces of software.
I'd really like to see more effort going in to API's that allow you to pull data from (in this case) PostgreSQL in a meaningful way that are open, extensible and composable. Maybe this is a "big platform" problem, but for me all these once off dashboards just don't scale when you've got so many different parts of your stack.
Eh, people build what they're gonna build. Pay it no mind, if it fatigues you. I do agree with your point about building more APIs btw. Just not necessarily less dashboards.
Here the author. I understand your points, I wrote a bit about my personal motivation behind this project.
http://rachbelaid.com/introducing-pome/
I also wrote within the readme about why wrote the project (context+goals), https://github.com/rach/pome#why-building-pome
This project is not aimed to replace more advanced tool like collectd but to offer a basic all-in-one solution. I'm also not planning to support huge database for the scaling problem that you highlight.
Trying to offer something easy without RDD store constraint for people who right now doesn't monitor their db.
I hope this make the goals behind the project more clear.
And then there is a dozen other databases, and none of them have shared standard API. So your best bet is a generic dashboard, with a plugin system, which you can write to extend the dashboard, to pull metrics from your metric query system or from custom JMX/PG command.
To keep with the simplicity that I was aiming, I wanted a binary. I considered Rust, Haskell or Go (Swift was not opensource yet at the time) but went with Go because the libs that I will need (cron like scheduler, embedding assets, etc).
I had never written something in Go before but if I've known go then maybe I would have pick an other language as I started this project with a learning motivation.
I suppose he's referring to embedding files (usually web resources such as js, css files) into the source code, using a tool such as go-bindata [1]. The assets are then accessed as variables.
From a deployment standpoint, having a tool written in Go is a win for me since it is much simpler to get running than something in python or ruby which almost certainly has a larger dependency tree.
> From a deployment standpoint, having a tool written in Go is a win for me.
Deploying Go apps is not always easy from my experience(cross compiling for Android ARM). You need to cross compile Go source code for the target platform and it's not as simple as you hear from Go's tutorials on the internet. Most of them only demonstrate how to cross compile a small simple Hello World application. For actual app, you have dependencies from third parties and it's not always easy to cross compile with those deps especially when they rely on low level APIs(cgo).
For Java/C#/Ruby/Python/Perl/Javascript etc which constitute huge amount of business related apps development it is new and convenient deployment strategy .
As of the (now quite old) 4.2 release of gcj, static linkking is quite simple (as opposed to before, when it seems like it was possible but somehow frustrating).
Do you hate "written in Go" specifically? 'cause if you search for "written in" you'll find plenty of Rust, JavaScript, Python, and insert-language-here articles.
Looks interesting, but supports fewer metrics than Zalando's PGObserver[1] which I've used and find to be very useful to monitor your PostgreSQL installation(s).
Also Pome only supports PG9.4, whereas PGObserver supports older versions (I used it on 9.3 and 9.1)
Thanks for sharing this. I will look at which metrics that I can include from this project. I can also say that CPU can't happen to keep the project gathering data only through Postgres (except if you know a way)
The goal of Pome was to be very easy to setup for people who put nothing in place, which is why wrote it in Go. But if you have some time there is much better/complete tools like collectd.
Here the author.
Glad and scare that this project reached the 1st page of HN.
This project is at a very early stage but I had to release it at some stage. I wrote some explanation in the Readme [1] and in a blog post [2].
TL;DR: Pome aim to be very simple to deploy, opinionated and battery included tool to have a look at the health of your PG db. It's maybe not the case of anybody here but in my career, I have seen many PG db for which no health status were track (or because people think that RDS is magic). I assumed that if a very simple tool existed then it gives less reason to not track their health status.
At this stage, I don't think that Pome offers enough to be very useful but I hope that you will like the direction taken and where it's going.
Pome isn't aiming to be a tool for humongous Postgres instances which are already in the hands of a DBA who can have the time to setup more advanced monitoring tools. Pome won't be an alternative to a more configurable tool like collectd.
A quick glance at the README.md indicates that you can input the hostname, port, etc. of your db at the command line, so it should work with AWS (your hostname would be something like blah.blah.us-east-1.rds.amazonaws.com).
Yes, it supports RDS and I want to support it as it's the one that I used most often. It's really basic right now but I will add some new metrics this month.
I'd really like to see more effort going in to API's that allow you to pull data from (in this case) PostgreSQL in a meaningful way that are open, extensible and composable. Maybe this is a "big platform" problem, but for me all these once off dashboards just don't scale when you've got so many different parts of your stack.