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.
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).
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.
* 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.
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?
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.
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.)
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.
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.
27 comments
[ 0.98 ms ] story [ 110 ms ] threadThose come after being vegan but before crossfit in 'what I do is a personality' bingo.
* 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.
(You could use `gRPC-web` to make JSON-encoded requests but you need specific support on the server end for that.)
https://github.com/TwinProduction/gatus#readme
If anybody has any suggestions, please feel free to create an issue on the repository