On Tue, Jan 26, 2016, at 05:24 PM, Hallvard Breien Furuseth wrote:
Maybe it would work to move Statslog( ... ACCEPT ...)
above ldap_pvt_thread_mutex_unlock( &c->c_mutex );
at the end of servers/slapd/connection.c:connection_init().
Holding on to the mutex longer would make slapd a bit
less responsive, though. No idea how much.
That's kinda what I initially expected openldap to do :D
Another variant: Put the cost in the log parser instead.
yep, that's the way I worked around this problem
When you see an ACCEPT, delay processing log lines until
you've seen some more lines, in case they are out of order.
I've got an old tweak to contrib/slapd-tools/statslog
which does that and some other stuff, here:
I was sending my logs through
correlating binds and accepts in logstash (whose filters prevented
me to easily implement delays)
So, considering the rarity of the mixed log entries, I decided to:
1) save both accept and bind entries in elasticsearch
2) keep correlating events in passing through logstash, if possible
3) schedule a script which "correlates uncorrelated" binds and deletes
connections data from elasticsearch
Don't remember why I haven't committed it. Maybe
it isn't quite finished or I hoped to optimize it,
since it does slow the script down. I'd be glad to
hear of any improvements from you:-)
Perl scares me :)
Come to think of it, statslog is quite old. It
might need some tweaks to catch up with whatever has
been done to OpenLDAP logs since it was written.
I suppose it would be nice to have an option to force Openldap to
write ordered logs (obviously with a performance penalty).
Or maybe enabling logging the real operation timestamp (as in:
generated just before the operation itself), enabling a simple filter to