Bug #1695

Unix Socket missing dump-counters mode

Added by Duane Howard over 3 years ago. Updated about 3 years ago.

Target version:
Affected Versions:


I'm testing out 3.0 STABLE, and seem to be unable to get 'dump-counters' to work through the command socket. When I revert to 2.0.11 this works again. Is there something that changed that I'm missing? We're building our own package, so if build flags or something changed that could be part of it? Anyway, this seems like odd behavior to me.

me@somebox:~$ suricatasc
Command list: shutdown, command-list, help, version, uptime, running-mode, capture-mode, conf-get, dump-counters, reload-rules, register-tenant-handler, unregister-tenant-handler, register-tenant, reload-tenant, unregister-tenant, iface-stat, iface-list, quit








"not implemented"

FWIW this is a complete blocker for us rolling 3.0 out to our fleet as we've built our monitoring pipeline around data collection from the socket.



Updated by Victor Julien over 3 years ago

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?


Updated by Duane Howard over 3 years ago

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).


Updated by Duane Howard over 3 years ago

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?


Updated by Duane Howard over 3 years ago

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.


Updated by Victor Julien over 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Victor Julien
  • Target version set to Soon

What I'm hacking together right now is to have a working dump-counters again, except that the output will pretty much be a eve.stats record. I had to look up the old format, and it's just to crappy to restore.

What I can do, is add a version field or something so that your client can test for this and distinguish between 2.x and 3.x. Thoughts?


Updated by Duane Howard about 3 years ago

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.


Updated by Victor Julien about 3 years ago

  • Status changed from Assigned to Closed
  • Target version changed from Soon to 3.0.1RC1

Also available in: Atom PDF