Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mqtt support #950

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Mqtt support #950

wants to merge 3 commits into from

Conversation

kadaan
Copy link

@kadaan kadaan commented Dec 31, 2024

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.

2024-12-31 at 10 28 07@2x

2024-12-31 at 10 27 06@2x

2024-12-31 at 10 27 33@2x

@TwiN Can you give me feedback on this PR?

Checklist

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

@zdzichu Here is an implementation of MQTT checking

@zdzichu
Copy link

zdzichu commented Jan 1, 2025

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
Copy link
Author

kadaan commented Jan 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants