Suricata

The implementation was a hack and was removed as part of a larger counters redesign.

We do have JSON output of stats now, which can also be pushed to unix socket, syslog, redis, etc. Would that be useful?

As long as I can get JSON stats out of the socket I'm happy. I'd prefer if the output format was the same as dump-counters (as we built our metrics collection module to parse that).

I've tested and documented how to get json stats over unix socket here: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Upgrading_Suricata_20_to_Suricata_30#unix-socket-dump-counters

Hrm... Haven't not tried this yet, it seems like this is going to be a bit of a pain. Now I need to connect to one socket, and do a version check (2 or 3) if v.3 connect to a different socket, and to get stats I cant remain connected to that socket and issue a command like I do now... I'd need to tear down the connection and bring it back up for each metric collection?

Victor, how feasible would it be for the dump-counters command to basically perform the connection to the eve socket connection? In this way the client behavior wouldn't need to change (assuming the json output and names are the same) but you'd still be leveraging (basically) the same code path? It seems unncessary and strange to have two different sockets for querying the engine for data though.

Sorry for missing that question. I think the existing version command in the unix-socket is sufficient. I may just write a new client for 3.0 and manage the two separately. We can deprecate the 2.0 version and throw it away once we're off of it.