When the directory server cycles it's access log, information about existing connections (like remote IP address and binddn) aren't carried over to the new access log. This makes it difficult to analyze the access logs, since you have to dig through the previous access log(s) to find information about existing connections. For particularly long running connections, the relevant information might even be multiple logs back.
Dumping out the "connections" table under "cn=monitor" doesn't help as that only contains the connection file descriptor, not the "conn=" connection number that's in the log. The only place where the file descriptor is related to the connection number is on the initial connection log message, which, again, will be in some previous log file.
This is an enhancement request to automatically dump out the connection table at the very beginning of a newly cycled access log. Each connection table entry should include the "conn=" connection number, the current binddn and the remote IP address, and anything else that might be useful. This would allow each access log file to be scanned and analyzed independently from previous access log files.
logconv.pl already knows how to "carry over" open connections from one access log to another.
How might we store this information in the access log in such a way as not to break other tools that examine the access logs, like logconv.pl, console, admin express, etc.?
I suppose one way would be to just output a line like this at the beginning of each access log: {{{ [10/Jul/2014:13:55:03 -0600] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [10/Jul/2014:14:17:15 -0600] conn=2 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 .... }}} which gives you the starting time, the conn id, the fd/slot, and IP address. Would this give you sufficient information for analysis?
By the way, what tool are you using to analyze the access log? Is this just for ad hoc visual log inspection?
Toss in the current bind dn and that would be enough, yes. Since a given connection can be bound multiple times, finding the current bind dn in previous logs is actually harder than finding the remote IP.
We are gearing up to ship all our logs to a logstash server for digesting and entering into an elasticsearch backend for analysis with kibana. I'm looking at writing a python program to add the remote IP address and the current bind dn to each log line and to combine each operation with it's corresponding RESULT line before sending it to logstash. That would make each entry sent to logstash independent of any other entry.
ok, so something like this then: {{{ [10/Jul/2014:13:55:03 -0600] conn=1 fd=64 slot=64 connection from 127.0.0.1 to 127.0.0.1 [10/Jul/2014:13:55:03 -0600] conn=1 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [10/Jul/2014:13:55:03 -0600] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [10/Jul/2014:13:55:11 -0600] conn=2 fd=65 slot=65 connection from 127.0.0.1 to 127.0.0.1 [10/Jul/2014:13:55:11 -0600] conn=2 op=0 BIND dn="cn=replrepl,cn=config" method=128 version=3 [10/Jul/2014:13:55:11 -0600] conn=2 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replrepl,cn=config" }}} etc.
That format will be bad for logconv.pl - when it sees that there is a repeated open connection, it assumes that is because of a server restart, since the connection numbers are restarted at server restart. Hmm - will probably have to store this in the access log in some sort of "meta" header.
My other concern is performance - if there are thousands of open connections, this will really hammer the server for some period of time to generate this information, and probably cause rotation to happen more often if the rotation is based on log size. But those things can be tuned appropriately.
Why is it necessary for each access log to contain this information, if you are going to pre-process it anyway? I think the pre-processing could be done by modifying logconv.pl, but I can sympathize if you would rather not touch the perl code.
We ship our access logs to an archive server nightly, we don't keep them on our LDAP servers. Our LDAP servers are fairly busy and they don't have the disk space to store more than a couple of days of access logs. So once we've shipped them off, we delete the local copy. That archive server is also where we would process and send them to logstash, we can crunch through them without impacting the performance of our LDAP servers.
Yes, I can write the code to go digging through previous files when processing an access log file, just like logconv.pl. I was just hoping not to.
Metadata Update from @rmeggins: - Issue set to the milestone: FUTURE
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1185
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.