Mqtt support

[kadaan]

Summary

#803 - Add support for MQTT testing

MQTT Endpoints are similar to DNS Endpoints in that they are recognized by the presence of an mqtt config block. This enables the endpoint to be configured with the required topic and the optional username/password. The check will subscribe to the topic and wait for a message to come in that contains a payload that matches the BODY. While the check is waiting for incoming messages it will public a message containing the BODY as the payload. If the subscription gets the message containing the body= before the timeout publish, CONNECTED will be set to true. Otherwise, it will be false. The body can also be a text/template with support for a uuidv4 function. This enables the body to be specified like gatus check - {{ uuidv4 }} and ensures that the subscription is getting the message that was just published.

@TwiN Can you give me feedback on this PR?

Checklist

• [X] Tested and/or added tests to validate that the changes work as intended, if applicable.
• [X] Updated documentation in README.md, if applicable.

@zdzichu Here is an implementation of MQTT checking

[zdzichu]

Hey, thanks for implementing this! I gave it a spin, and while basic functionality seems to work, I have some questions.

First:

[CONNECTED] resolves to true if the MQTT message was published and the same message was consumed, false otherwise`

It sounds like this is like "ping" service, checking if MQTT broker responds? Or possibly expecting a known value on configured topic? That would monitor the broker functionality itself, not the values published by other clients.

Second, I'm not sure how to configure for alerting for usecases mentioned in the original issue:

• alert when no message was published to given topic for 5 minutes
• alert when value published to given topic is larger than 10

Could you guide me?

[kadaan]

Yeah, what I implemented is a ping to ensure that the basic MQTT infrastructure is up and running. You are correct that it will not monitor the values published by other clients. Given that, I don't think those kind of alerts can be created.

The cases you mention seem to be quite different from how Gatus does other checks. They would require a persistent checker that would be subscribing from MQTT and exposing a metric. This is more in line with how a Prometheus exporter works. I believe that external endpoints or #596 would be a better fit for those checks.

[kadaan]

@TwiN Can you review?