Relax restrictions on stat hierarchies in StatsLog (and remove collectd writer support)

[gavin-norman-sociomantic]

As mentioned in its documentation, StatsLog is designed to be able to write stats directly to collectd, via a socket. As far as I know, no application has actually used this facility. Questions:

• Is there still any plan to write stats to the collectd socket?
• If not, what's the alternative plan?
• If we don't need this facility of StatsLog, should we remove it? (This would allow us to relax some of its limitations, which would be really helpful, for example with https://github.com/sociomantic-tsunami/swarm/issues/61.)

[gavin-norman-sociomantic]

@federico-cuello-sociomantic you might have some comments on the above, from the infrastructure point of view. (I also wanted to tag Mateusz, but can't for some reason.)

[nemanja-boric-sociomantic]

Actually, we had single application using this facility (by @ben-palmer-sociomantic ), but the flexibility wrt types.db made it not very flexible. Btw, @ben-palmer-sociomantic 's reason for trying this out is the blocking write in case of disk access - something I'll hopefully solve this week via writing in the separate thread (stay tuned :tm:).

[federico-cuello-sociomantic]

reason for trying this out is the blocking write in case of disk access

also solved using syslog() :-)

[gavin-norman-sociomantic]

also solved using syslog() :)

So would you propose writing application stats to syslog as well?

[nemanja-boric-sociomantic]

Yeah, this is about stats, not general log messages. Is syslog suitable for the former issue @federico-cuello-sociomantic ?

[federico-cuello-sociomantic]

So would you propose writing application stats to syslog as well?

Yes, I did that already the last time we discussed this. :) (NO NOSE @nemanja-boric-sociomantic I'm watching you)

[gavin-norman-sociomantic]

Ok cool, here isn't really the place to discuss is, but if you have a plan for that, great. So it sounds like the "Consider" in the title of this issue should be removed.

[gavin-norman-sociomantic]

As it seems there's a plan for parsing stats from syslog, I've updated the title of this issue to something more definitive and placed it in the next ocean milestone.

@federico-cuello-sociomantic, Mateusz: need there be any restrictions on depth of stats hierarchy, from your perspective? We currently have a limit of 3 levels of hierarchy (<category>/<instance>/<member name>:<member value>., see https://github.com/sociomantic-tsunami/ocean/blob/cfd360d8219621915f8a635f299d950e7d4258c0/src/ocean/util/log/Stats.d#L415-L430). We have use cases for at least one more level (<category><channel><action><counter>:<value>, see https://github.com/sociomantic-tsunami/swarm/issues/61).