Full Discloser: While reading this blog post, please put yourself in my shoes. You’ve been looking around for a simple monitoring solution, you found some. None of the some are working because you use an Operating System that is used by Apple, WhatsApp, Netflix and many more, but developers think that everyone, everywhere, runs either macOS or Linux. And they all use Docker.
A while back Rubenerd wrote that he’s not sure that UNIX won and how Linux created a monoculture of assuming everything is supposed to run on Linux.
For me, this was not much of a problem, I can run Linux binaries on FreeBSD, I even watch Netflix using Linuxulator.
But now things are on another level, WAY another level.
I have a simple monitoring setup using cron, Grafana, InfluxDB and ping. It basically pings my servers and sends me a telegram message if they are down.
I set that up years ago, but now I have more public facing infrastructure that other people use as well, such as an Armenian Lobsters instance, Jabber.am, a WriteFreely instance and more.
As a self-respecting Ops, I wanted to make a simple dashboard for my users to see the uptime status of these services as well. First, they won’t bug me asking if something is not working; they will SEE, that, SSL/TLS certificate is expired, or the network is an issue, or that the server is down.
<rant>
So I started hunting on the internet for some software that do just that.
The first one that came to my mind was Gatus. I’ve used Gatus before for one of my clients, I like it a lot. It’s simple, it does what it’s supposed to do.
As a sane person, I fetched the code from GitHub using fetch, extracted the tarball and ran make. Nothing happens. Let’s see the Makefile, shall we?
Oh boy, if only, only, I had Docker, all my problems would be solved. First of all, let’s talk about the fact that this Makefile is used as a… script. There’s no dependencies in the targets!
Okay, let’s read that Dockerfile. Executing the scripts inside it should help out, aye?
# Build the go application into a binary
FROM golang:alpine as builder
RUN apk --update add ca-certificates
WORKDIR /app
COPY . ./
RUN CGO_ENABLED=0 GOOS=linux go build -mod vendor -a -installsuffix cgo -o gatus .
# Run Tests inside docker image if you don't have a configured go environment
#RUN apk update && apk add --virtual build-dependencies build-base gcc
#RUN go test ./... -mod vendor
# Run the binary on an empty container
FROM scratch
COPY --from=builder /app/gatus .
COPY --from=builder /app/config.yaml ./config/config.yaml
COPY --from=builder /app/web/static ./web/static
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
ENV PORT=8080
EXPOSE ${PORT}
There are multiple things wrong in me this.
First, please stop putting your binaries in /app, please, pretty-please? We have /usr/local/bin/ for that.
Second, I thought that running go build without GOOS=linux would solve all of my problems. I was wrong, very wrong.
root@mon:~/gatus/gatus-2.8.1 # env CGO_ENABLED=0 go build -mod vendor -a -installsuffix cgo -o gatus .
package github.com/TwinProduction/gatus
imports github.com/TwinProduction/gatus/config
imports github.com/TwinProduction/gatus/storage
imports github.com/TwinProduction/gatus/storage/store
imports github.com/TwinProduction/gatus/storage/store/sqlite
imports modernc.org/sqlite
imports modernc.org/libc
imports modernc.org/libc/errno: build constraints exclude all Go files in /root/gatus/gatus-2.8.1/vendor/modernc.org/libc/errno
Okay, check this out, the package is called modernc.org/sqlite and it says:
Package sqlite is a CGo-free port of SQLite.
SQLite is an in-process implementation of a self-contained, serverless, zero-configuration, transactional SQL database engine.
Of course it is. Looks like I have to port all of this to FreeBSD. Which, don’t get me wrong, I’m okay with doing that, but I thought that we have POSIX for a reason. notsomuch.
Okay, I’m an open-source guy, I’ll spend some time this weekend to port this to FreeBSD. Let’s look for another solution!
Here’s another one, it’s called statping, also written in Go, the readme is so promising.
No Requirements
Statping is built in Go Language so all you need is the precompile binary based on your operating system. You won’t need to install anything extra once you have the Statping binary installed. You can even run Statping on a Raspberry Pi.
Sounds good! Let’s try it out.
Again, I fetch the tarball, I extract and I bake make.
Of course it requires apt! Because not only we all run Linux, be we all run a specific distribution of Linux with a specific package manager.
While tweeting with anger, Daniel pointed out that I should tell them kindly and it’ll work out. I’m sure it will. Let’s hope I can make it work first. I don’t like just opening issues. I’d rather send a patch directly.
</rant>
Overall, now I understand why most *BSD folks use, what’s the word here? ah, yes, old-school software on their systems, like Nagios and the rest.
The developers of the New World Order will assume, always, you are running Linux, as Ubuntu, and you always have Docker.
Hopefully this weekend I will be able to port these software to FreeBSD, otherwise I will just use the Linux layer.
Like Rubenerd said, I am thankful that the mainstream-ness of Linux helped other Unix systems as well, but monocultures are destroying what people have spent years to improve.
Hopefully, next week, I will write a blog post on how to fix these issues and how I got all of those up and running.
That’s all folks…