poc: custom scripts

[jcsaaddupuy]

Hi,

Using a custom script in a endpoint would allow anyone to support any custom target.

This MR is a poc to execute a custom script, and be able to check in conditions the exit code, the script stdout/stderr.

Example configuration :

  - name: custom script
    script:
      command: "echo -n HELLO"
    interval: 10s
    conditions:
      - "[EXIT_CODE] == 0"
      - "[STDOUT] == HELLO"

I did not implement tests yet, and the MR may not be clean.
Let me know what you think !

[TwiN]

Gatus' Docker image doesn't have bash installed though, nor does it have curl, wget, echo, etc.

[jcsaaddupuy]

Indeed.
It's a good thing to keep the default image as light as possible.

But isn't it only a runtime issue?

As a gatus user, it's totally possible to either extend the base image, or build a docker image with a more complex setup and install gatus in it.
This feature can stay totally optional.

Supporting custom script would be a simple way to let end-users implement usecases that are not covered out of the box by gatus.

For example, in my case, I need to check the correct execution of some pipelines persisting data in a bigquery database.
With this feature, I'm able to implement a SQL check based on a python script, delegating all the setup/authentication mechanism outside of gatus.

That could be extended to others cases (for ex: having checks based on complex api calls, proprietary systems/...) while keeping the impact on gatus codebase low - we just check for the exit code after all :)

[jcsaaddupuy]

To add more material on this proposal, one could build a custom image but still using gatus from the last official image :

FROM busybox # or any other base image, for ex python

COPY --from=twinproduction/gatus /gatus /gatus

COPY ./config /config # inject custom local config defining scripts endpoints
# also should copy custom scripts in PATH

ENV PORT=8080
EXPOSE ${PORT}
ENTRYPOINT ["/gatus"]

I see at least one or two issues (in addition to my own usecase) this would allow to easily support :

• SQL Server monitoring support #554
• Support service agents #437

Let me know if you find interest in this feature, I can make a proper PR with unittests / clean a little the code.

[TwiN]

I'm conflicted, because this feature may cause people to be unhappy if it doesn't work out of the box, which it won't unless people create their own Docker image -- something not everybody knows how to do or is willing to spend the time doing.

Instead, I feel like the new external endpoint feature may be sufficient to achieve the same goal.

[kadaan]

The external endpoint feature is nice, but it does require developing additional services to support those custom checks. If, for example, I want to support MQTT checks I need to write a service and host it in kubernetes so that it call call Gatus. This is much more complex than extending the Gatus image with the tooling necessary to run the additional check you want to support.

[kadaan]

Another advantage is that the community could author non-core checks (i.e. GPRC) that would be able to be used without integrating into the core of Gatus. This is beneficial because there will always be cases where people want support for specific systems that will not have enough adoption to justify the support cost of adding them to Gatus.

[kadaan]

@jcsaaddupuy Another use case would be MQTT support.

[kadaan]

@TwiN I know that this is retired, but something like this would get us custom check support but allow it to be external: https://github.com/kubernetes-retired/contrib/blob/master/exec-healthz/cmd/exechealthz/exechealthz.go