Monitoring String through Socket

[ktoy]

There is a function to monitor the contents of the file, but if there is also a function to monitor the string coming into the socket, it seems that it can receive and process a string from another external program through the socket.

In my current work, I am using it by leaving the output result of filebeat as a file and monitoring the file in monit.
Processing with a socket rather than a file seems to enable more efficient monitoring processing because there is no need for logic to manage intermediate generated files.

[Tildeslash]

You can use Monit to connect (TCP/UDP) and read and test data sent by a server. You can however not have Monit listening on incoming socket connections and parse data that way. I.e. you can test data sent over a socket, but Monit has to initiate the connection.

[ktoy]

I'd like a feature added to monit that receives data, parses that data, and sends a notification when a specified string comes in.

[Tildeslash]

Interesting request. I can see some security issues with this, but maybe I’m overly cautious. A more secure and usual way is that the server or service you want to monitor provides some network API which Monit can utilize and monitor. Does filebeat not provide such an API or function?

[ktoy]

Thank you for your interest.

Monitoring filebeat with monit is not the goal. The reason for using filebeat is to transmit event strings generated by tailing multiple log files to monit. Logfile tailing is possible in monit, but the reason why filebeat was used is that monit does not support wildcard when tailing multiple files, so only one specific file can be tailed. And filebeat also has the convenience of providing several options for logfile tailing. In other words, I wish there was a function to send filebeat's output string to monit and fire it as a notification.

[Tildeslash]

Aha, this is a great idea. It is definitely possible to add this to Monit, it just haven’t come up. I’ve added it to our TODO list. I think it could look something like this:

CHECK FILES {name} PATH(S)? [{dir|glob}*] [ORDER BY {name|ctime|atime|mtime}] AND WITH [DEPTH=*]
<File Tests from CHECK FILE can be used and apply to the current file>

Example of monitoring a directory recursively, order by is done per directory level and

CHECK FILES var PATH /var/ ORDER BY name AND WITH DEPTH=*

Example of monitoring a directory without sub-dirs. Default DEPTH is 1 and default order by is name

CHECK FILES tmp PATH /tmp/

Example of monitoring a list of arbitrary files

CHECK FILES var PATHS [/tmp/, /var/log/, /var/db/*.sqlite] ORDER BY mtime