Documentation and usage information do not mention the "lc-admin ping" command

[driskell]

Documentation and usage information do not mention the "lc-admin ping" command

[driskell]

Thanks for the report.

I'll consider what to do here. Ping was intended as an internal only command that lc-admin would automatically send every 15 mins or so when idle to keep a connection open.

Either I'll add it to the help or make it so it cannot be run manually (so it's restricted to protocol).

Jason

[cschug]

Ah, I see, thanks for the explanation.

Some question a little bit beyond the scope of this issue, but are there any plans to incorporate some mechanism, which could be useful to monitor the health of the service, especially also the log-courier plugin side for Logstash? In the most basic form I am thinking of a service check for Nagios or Icinga (https://www.monitoring-plugins.org/doc/guidelines.html#PLUGOUTPUT) which just returns the status whether the service can be reached over the network and responses in time. I don't know if it makes sense to create something from scratch as considerable parts of the implementation already do exists here in the project, e.g. certificate handling, configuration file parsing, wire protocol. What do you think?

[driskell]

Monitoring the logstash side I will leave to logstash itself. The lc-admin utility though is intended to allow monitoring on the client side, such as number of logs and speed. I was planning to set up a munin graph to show this. If logstash shutdown too you'd be able to check the connection status. If logstash hung possibly check the events transmitted is increasing or not.

lc-admin status is also great when I'm debugging harvesting and such as I can see exactly what log-courier is watching and what state its in.

[driskell]

Regarding logstash side though - To be fair I've not seen an instance where checking the log-courier port is working on application layer would throw up an issue. If its not listening, that's easy check for just TCP port, and logstash probably died. For application layer I can't see it throwing anything up, as it would just be a PING. If it's sending an event though and expecting it out into elastic search that would be complex to check. Probably a bit out of scope as you say!