Mender 3.1 introduces a new add-on offering: Mender Monitor. It contains a set of features to help ensure that all your devices and services are healthy.
Real-time monitoring of your device’s resources and state, combined with an anomaly detection engine gives you instant visibility into potential problems with your device fleet, so you can investigate before your customer would even notice. This ensures higher uptime and eliminates lengthy and costly support incidents.
Unlike classic cloud-monitoring solutions, Mender Monitor is built for IoT. This means that it uses edge processing, making it a fully distributed solution: the device creates and responds to alerts locally. When connectivity to the cloud is available, the alerts are synchronized to maintain full visibility. This makes it possible to instantly act on high severity alerts, such as overheating, without waiting for connectivity to be restored.
Sign up for this webcast to see a demo of the newest features live as well as receive the recording straight to your email inbox.
Very interesting (I just got to watch it)…
We may be interested in monitoring custom conditions not handled by dbus/logs/service as demonstrated in the presentation so a custom script solution would be needed.
Is this planned to be implemented and how far away do you think it is?
Hello @bender and thank for your interest in the Mender Monitor add-on.
I have to know more, what is the exact use case? What does the custom script you mentioned return? How do you run it? How do you know that it is in a “ok state” and how that it is in “critical state” (requiring an alert).
We have a script as part of a service that monitors a serial connection for measurements. There is a specific pattern that can be detected that suggests an external system has failed and we need to take action (call someone local).
I understand. Assuming your script monitors the serial persistently, and we are looking for CRITICAL_ERROR pattern in its output, you could try to configure the Mender Monitor add-on check like that:
where /usr/local/serial/bin/monitor stands for the path to your script, and 1h means that if the CRITICAL_ERROR pattern has not appeared for past hour, the alert will be cancelled (device will appear as healthy).
@peter is this form of mender-monitorctl usage documented somewhere? I need to periodically scan for specific log messages is dmesg and this seems like a good usage for this but I can’t find the docs.
