https://bugs.openldap.org/show_bug.cgi?id=10293
--- Comment #4 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Apr 09, 2025 at 08:26:06PM +0000, openldap-its@openldap.org wrote:
The current implementation of syncrepl operation logging should be updated to make the logging outut formatted the same as normal operations. Customers using data reduction tools like Splunk and DataDog expect regular and easily processed formats and this implementation is neither. Furthermore the splitting of the name of the verb being sent and the etime makes processing complex in general.
Hi Marty, before I go into specifics, what are you trying to measure/track and what sorts of insights are you trying to gain? Or if you think that's easier, maybe you want to provide an actual situation when it would have been useful? But that's the sort of things we'll need to sort first to get any changes going.
I would prefer we restart with the above and you can stop reading here.
If you do want to keep reading the below, remember that I have to take what you request at face value (and assume that you're talking about consumer logging only). If what you said and what you meant were different, you will certainly disagree with the rest of my response.
Most of syncrepl handling is considered internal for a reason, its internal searches are definitely nothing like a "Search", even modifications/adds/renames rarely correspond to a "Modify"/"Add"/... not least because the target and a large amount of context are different enough from the occasion they are initiated by a client and certainly not in line what one would expect to see at "stats" loglevel. This is the crux of why Nadya's MR!738[0] was not acceptable.
Also when you mention etime and it being "split" from the "verb", it rings similar alarm bells. The etime logged as a result of ITS#9886 is a different beast than a client initiated operation, it is the time to "make progress", that is: completely process a single message we received from the provider. Quite often this corresponds to multiple backend operations, it is not even rare that it corresponds to many "modifications" in the usual sense.
To make things more complicated, each replica only has a local view of the situation so many things are only ever observable by correlating events from across the cluster. Which is why I'm suggesting we pick a model incident and see what we can do to make it more tractable.
[0]. https://git.openldap.org/openldap/openldap/-/merge_requests/738
Regards,