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 #34

Open
duylong opened this issue Mar 28, 2022 · 3 comments
Open

MQTT support #34

duylong opened this issue Mar 28, 2022 · 3 comments

Comments

@duylong
Copy link

duylong commented Mar 28, 2022

Hi,

Would it be possible to add MQTT support?

MQTT is widely used in the world of home automation. I am currently using Mosquitto (as a broker), it is very lightweight and great for states. I centralized a lot of solutions in MQTT and it would be perfect to be able to have it in StatusEngine.

Client example: https://github.com/php-mqtt/client

@nook24
Copy link
Member

nook24 commented Mar 30, 2022

The real pain would be to implement this into the broker module: https://github.com/statusengine/broker. So, this isn't something I plan to do. But if you want to send over a pull request which adds MQTT support, I would be more than happy.

What are the benefits from supporting MQTT?
A quick Google search came up with the RabbitMQ MQTT plugin. Sounds like this could forward the messages to your MQTT broker
https://www.rabbitmq.com/mqtt.html

@duylong
Copy link
Author

duylong commented Mar 31, 2022

The MQTT plugin allows RabbitMQ to be an MQTT broker, it does not become a client. A proxy would have to be implemented, which adds an extra layer.

There is already a broker for Nagios 3.x so you don't start from scratch: https://github.com/DE-IBH/nag2mqtt

MQTT protocol is very lightweight and works with low bandwidth, no complex message routing, no support message queues, no implementation effort, works only in pub/sub mode. It supports LVQ (Last-Value-Queues) which allows a consumer to ignore the last messages. I find it well suited for monitoring and you can simplify queries because instead of going through a MySQL database to retrieve a current state, you just need to retrieve it from the MQTT broker.

In addition, it runs smoothly on a Raspberry PI. Moreover, Facebook uses some notions of MQTT in Messenger.

@nook24
Copy link
Member

nook24 commented May 25, 2022

Thanks for your patience.
as mentioned:

The real pain would be to implement this into the broker module: https://github.com/statusengine/broker. So, this isn't something I plan to do.

The broker module is capable of replacing the underlying queueing engine. Gearman and RabbitMQ for now. I have no use case for MQTT, therefore i will not implement any MQTT support. How ever, i would be more than happy to see a pull request for this :)

I find it well suited for monitoring and you can simplify queries because instead of going through a MySQL database to retrieve a current state, you just need to retrieve it from the MQTT broker.

This would also require to add MQTT support to the Statusengine interface. The whole point of Statusengine is, to store check results into a database. Without a database it is impossible to get lists of hosts and services, filter by state or have any history records.
So in my optionion, MQTT would only make sense, to send the check results to some external systems.

If you plan to transfer check results to an external system, you can use the OCHP and OCSP option of the broker module. It will write all check results into a second queue, you can develop your own consumer for. So you can add a proxy which forwards all messages to your MQTT broker.
https://statusengine.org/broker/#command-ocsp-and-ochp

In addition, it runs smoothly on a Raspberry PI

MySQL is running fine on a Raspberry Pi since the first Pi. How ever, the Statusengine Worker can also operate only In-Memory: https://statusengine.org/worker/#in-memory
So no database is required. But due to the limited filtering and sorting options, this is not supported by the Statusengine interface. This feature is not used in the field and therefore not optimized at all. (At least that I aware of)

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

No branches or pull requests

2 participants