https://bugs.exim.org/show_bug.cgi?id=2610
Graeme Fowler <graeme@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |graeme@???
--- Comment #6 from Graeme Fowler <graeme@???> ---
Disclosure: I wrote the original patterns and recipes for ingesting Exim logs
into logstash/elasticsearch and then utilising the data in Kibana, and wrote a
couple of blog articles about it (which are trivially searchable).
I haven't maintained it because we moved (at work) to Splunk, in which I have
done something similar.
One repeating issue which makes post-processing Exim's logs difficult
regardless of format is the lack of continual state and the handling of
messages at various phases by different processes. The way Exim is currently
designed, without one single management process, means the logs need to be
processed outside of Exim rather than having Exim keep an ever-growing state
table for a specific message which can be output when message processing
completes.
As an example, a message to multiple recipients could take hours or days (or
longer!) to complete delivery and could have a variety of responses to the
various transports used to send it to remote hosts, local mailboxes, or other
local processes via sockets/pipes etc. Whilst Exim keeps some message state, it
doesn't keep the log entries for everything to do with a message within the
queued message object - yes, there are per-message-logs if you enable that, but
even then the great variety within that makes processing them non-trivial.
It is my opinion that the log format should remain "as-is", because it is well
documented and understood, and that any work to produce some downstream JSON
format is the work of other tools/scripts.
--
You are receiving this mail because:
You are on the CC list for the bug.
