Show HN: Realtime, self-hosted monitoring for Node.js inspired by GitHub Status | Hacker News Reader

Show HN: Realtime, self-hosted monitoring for Node.js inspired by GitHub Status

github.com

75 pointsrwilinski19 comments

Off Topic: Your commits are all prefixed with emojis, which is useful when trying to determine (at a glance) which file was changed with which commit. Are you choosing your own emojis, or is it automated with a `commit-msg` git hook?

I pick them randomly, sometimes I try to find something relevant to change but not in this project.

Personally, I hate that [1]. Among many trends on the Internet the excessive use of unnecessary Unicode characters in a log that is supposed to give you an idea of the progress of a project is certainly... Well, as I said, unnecessary. I don't know who came up with this idea (was it GitHub's Atom project?) but every time I find a project on GitHub [2] I immediately start to judge the author(s) decisions and the seriousness of the project.

I understand that everyone is free to manage their project as they please, and the following statement will probably affect my career in the future, but I sincerely hope to never come across a job where my co-workers praise this... I don't even know how to call it... standard?

Very interesting project nonetheless.

[1] https://i.imgur.com/Xek7ZVV.png

[2] Haven't seen this anywhere else.

I don't do that in my professional work, I do that only in my personal projects. It's just my project so I guess I set the rules here ;)

If you just want these to show up on GitHub specifically, you can use the friendly names like `:ring:`, `:art:`, etc. Then there's no Unicode anywhere but GitHub will still show the emoji. That's how `atom` committers do it.

Good idea, didn't know about that.

This is a horrible idea... There isn't a tool that just prefixes the filename that changed for you in a commit log? Why do you need to dirty up the commit messages with all this visual noise? (nice project though)

It might be a silly question, but have you checked if this module affects performances and, if so, by how much?

It all depends on how much data you would like to keep and monitor. If you're going to keep data let's say for last minute, last hour and last 24 hours (100 data points each) you'll be fine. It will extend base memory footprint by about 4MB approx basing on my experiments. When it comes to CPU, these operations are not so expensive and consume up to 0.1% of my Macbook Pro power (on default settings which are 3 series of 60 datapoints)

It would be great for future versions to be modified to support restify and hapi.

https://github.com/ziyasal/hapijs-status-monitor

Each time we make a dashboard, we model it after GitHub's status page.

This looks fantastic, simple to implement, and, heck, could be hidden behind a feature flag or auth :)

Great work!

for hapijs: https://github.com/ziyasal/hapijs-status-monitor

This architecture fails precisely when you need it the most. Any failure that breaks your server's ability to respond to requests in a timely fashion will also break it's ability to render this monitoring page.

Monitoring that can't give you actionable information during an outage is just pretty pictures.

The tone of a comment is inconsistent with the guidelines for Show HN. Clearly, there are many situations where:

1. A monitoring is useful

2. There is no outage.

Nice work.

Turning ON/OFF status, notifications based on some value would be nice addons.

What do you recommend for monitoring the mongoDB?

I don't have much experience in MongoDB Administration but if you're enterprise I think you should checkout Cloud Manager: https://www.mongodb.com/cloud/cloud-manager/

In Wikia we based on ELK + Grafana for everything that needed monitoring so pushing mongostat data to InfluxDB/Logstash should be OK.

Looks good.

Reply on news.ycombinator.com