Self hosted uptime robot alternative written in go | Hacker News Reader

Self hosted uptime robot alternative written in go

github.com

57 pointslaptop-man27 comments

It's funny when people post things here that are written in go, they always want to let you know that. Nothing wrong with that, I just don't see it as much with other languages.

When I see "in Go", I infer:

* it's likely easy to build/package, since deep dependency trees don't occur much in practice. Alternatively, there could be a binary available on Github.

* it's going to behave similar to https://12factor.net/

* it's going to be working in 3 years time (since the language and library authors value backwards compatibility)

* I can contribute to it, and not expect it to use some obscure async/web library that makes contributions harder.

They're all important to me. I think Go is a bit uninspiring as a language, but maybe I don't need that.

I wish this kind of thing was more prevalent, actually. I'd probably avoid clicking through most links for projects written as node.js applications.

Haskell, Rust and Go are the big 3 for name dropping at the moment.

Those come after being vegan but before crossfit in 'what I do is a personality' bingo.

Arch Linux is missing from your bingo card.

And Nix

I honestly think Nix has gotten bigger than Arch in that way. "BTW, I use Nix" should be a thing too.

So, when can people say they really use nix? Can you just look in their github repos and call it a day?

Haskell? I feel like I haven't seen it much. Interestingly though I just started to learn it, so I would like to see it more.

I know Rust and Go are at the peak of their hype-cycle here on HN, but I still personally appreciate the language being mentioned in the title - if it's a language I use, I will naturally be more interested.

Same filter works the other way too for the skip operation

op here, I only put the language as when I self host anything I like knowing how to extend the program and be comfortable with the lang

We see it with whatever is trendy, lately it's been Rust. I don't see anything wrong with it, usually people are proud of it because they used the project as a way to learn a new technology, which is why it's in the title (I don't know if that's the case here).

part of the reason could be to emphasize that single binary would be easy to operate

You'd expect it to be easy to deploy if it's written in go. I don't see a problem mentioning it.

How did you filter out cloned in rust or written in rust posts from your feed, teach me senpai.

You see it with both Rust and Go.

Is there a reason you linked to the Actions page instead of to the main repo's description of the project?

https://github.com/TwinProduction/gatus#readme

What always seems to be missing from these things is gRPC monitoring - there's a defined HealthCheck endpoint, even, specifically for this situation. Maybe people just don't run gRPC services as much as the hype would imply?

Why would this be so valuable compared to basic HTTP health check?

If you've got a gRPC API, you don't necessarily have anything serving HTTP that would correlate to that service - I know we don't, for example; the only HTTP is for serving static files, everything else is gRPC, and HTTP checks wouldn't spot any problems.

Don't people usually use gRPC over HTTP?

The core protocol uses HTTP/2 as a transport, yes, but you'd have to convert the conceptual gRPC request to the protobuf-encoded version and somehow pass that to the HTTP/2 endpoint as a binary blob, then decode/match the binary blob you get back - which none of the status pingers really offer either.

(You could use `gRPC-web` to make JSON-encoded requests but you need specific support on the server end for that.)

Repository owner here - seeing my project make the front page of HN, no matter how briefly, warms my heart.

If anybody has any suggestions, please feel free to create an issue on the repository

When you self host uptime tools keep in mind you’re blind to any problems that affect both your uptime monitor and your servers. So if they’re on the same machine, cloud provider, data center... you won’t get alerted to a lot of issues.

You do need a secondary checker on another data center to monitor the checkers mutually.

I still feel monit (even better coupled with m/monit with graphing) is underrated to this day without much mentions but it can do all sorts of checking in easy to understand DSL without any complications.

Reply on news.ycombinator.com