[dovecot] Logging suggestions?
Any suggestions how user login/logouts should look like in log files? I was thinking:
(connected to imaps port) Login: username [IP 1.2.3.4, imaps, compressed] Logout: username [IP 1.2.3.4, imaps, compressed] [1000/100000 bytes (50%), 00:00:12]
Bytes being upload/download and the 50% meaning compression ratio for downloaded bytes, probably not worth it for upload. Or if uncompressed, it'd show the extra space used by SSL/TLS protocol:
(using STARTTLS) Login: username [IP 1.2.3.4, TLS] Logout: username [IP 1.2.3.4, TLS] [2020/202000 bytes (101%), 00:00:12]
(no SSL) Login: username [IP 1.2.3.4] Logout: username [IP 1.2.3.4] [2000/200000 bytes, 00:00:12]
I think the only configuration needed would be if to log login, logout or both.
On Wed, 2003-01-08 at 12:47, Timo Sirainen wrote:
Bytes being upload/download and the 50% meaning compression ratio for downloaded bytes, probably not worth it for upload. Or if uncompressed, it'd show the extra space used by SSL/TLS protocol:
Or not. I remembered the SSL code worked a bit differently, so I don't think there is any simple way to find out the compression ratio or SSL overhead.
- On 2003.01.08, in <1042022871.28651.93.camel@hurina>,
- "Timo Sirainen" <tss@iki.fi> wrote:
Any suggestions how user login/logouts should look like in log files? I was thinking:
(connected to imaps port) Login: username [IP 1.2.3.4, imaps, compressed] Logout: username [IP 1.2.3.4, imaps, compressed] [1000/100000 bytes (50%), 00:00:12]
I like things that are easy to parse with shell and awk scripts. E.g.:
Login: username 1.2.3.4:1025 5.6.7.8:143 imaps,compressed Logout: username 1.2.3.4:1025 5.6.7.8:143 imaps,compressed in:1000 out:1000000 [whatever SSL summary data is available]
I like seeing both the source and destination sockaddrs. (Why not run two instances on different interfaces?) In fact, I like seeing both hostname and ip address, and an indicator if a reverse map doesn't match, but that's probably just me.
In this example, flags occupy one space-delimited field, and are separated by commas. It's useful for performance analysis to tally bytes transferred; this is what "in:" and "out:" are for. It would also be nice for perf. anal. to know how much I/O to storage (disk) was performed by the imap process, but I don't imagine those figures are presently available anyway.
That's just an illustration; it doesn't matter to me whether it's like that particularly. I just want to show what I mean by ease of parsing -- whitespace-separated fields, well-known field values, related flags and such compounded within fields. The whole line structure should be well-known and not require perl or sscanf()s or such; scripts should be able to extract a lot of data from these quickly.
(We're watching dovecot for possible use on a system that supports about 300,000 logins per day, and we want to be able to produce stats on that.)
I think the only configuration needed would be if to log login, logout or both.
That's generous. :) I'd always want both, and can't imagine not wanting both, but I suppose some might prefer less.
I actually wouldn't mind seeing more optional logs -- for example, logout-like summaries for folder accesses (when users change folders). This can help in balancing storage devices when folders can reside on multiple devices.
In an ideal world, everything would be loggable, but not everything would be logged.
-- -D. dgc@uchicago.edu NSIT University of Chicago We're the colon in ://
On Wed, Jan 08, 2003 at 11:50:06AM -0600, David Champion wrote:
- On 2003.01.08, in <1042022871.28651.93.camel@hurina>,
- "Timo Sirainen" <tss@iki.fi> wrote:
Any suggestions how user login/logouts should look like in log files? I was thinking:
[snip]
I think the only configuration needed would be if to log login, logout or both.
That's generous. :) I'd always want both, and can't imagine not wanting both, but I suppose some might prefer less.
I'd like to see at least the option of showing failed logins, for security monitoring. In some ways, I want to see this more than I want to see successful logins.
I actually wouldn't mind seeing more optional logs -- for example, logout-like summaries for folder accesses (when users change folders). This can help in balancing storage devices when folders can reside on multiple devices.
+1
Might think about what can be logged per-module. That is, imap-login knows about connection attempts; imap-auth about who and how (auth mechanism); imap about folders accessed, bytes transferred. Might think about a set of keywords for each, then, like this:
imap_login_logging: connection login logout starttls imap_auth_logging: user auth success failure imap_logging: folders num_messages num_bytes per_folder
Amy!
Amelia A. Lewis amyzing {at} talsever.com Better to have thirty minutes of wonderful than a lifetime of nothing special.
Amelia A Lewis wrote:
Might think about what can be logged per-module. That is, imap-login knows about connection attempts; imap-auth about who and how (auth mechanism); imap about folders accessed, bytes transferred. Might think about a set of keywords for each, then, like this:
imap_login_logging: connection login logout starttls imap_auth_logging: user auth success failure imap_logging: folders num_messages num_bytes per_folder
I have to second this idea, as well. I also like David Champion's idea of easily-parsable logs.
-- Jesse Peterson / jesse@pixeltechs.com
On Wed, 2003-01-08 at 20:11, Amelia A Lewis wrote:
I'd like to see at least the option of showing failed logins, for security monitoring. In some ways, I want to see this more than I want to see successful logins.
Currently it just says "Aborted login". I was planning on adding "n failed login attempts" before that or actual login.
Might think about what can be logged per-module. That is, imap-login knows about connection attempts; imap-auth about who and how (auth mechanism); imap about folders accessed, bytes transferred. Might think about a set of keywords for each, then, like this:
imap_login_logging: connection login logout starttls imap_auth_logging: user auth success failure imap_logging: folders num_messages num_bytes per_folder
Something like that, yes. I'd like to avoid adding too many (mostly) useless options though.
On Wed, 2003-01-08 at 19:50, David Champion wrote:
I like things that are easy to parse with shell and awk scripts. E.g.:
Login: username 1.2.3.4:1025 5.6.7.8:143 imaps,compressed Logout: username 1.2.3.4:1025 5.6.7.8:143 imaps,compressed in:1000 out:1000000 [whatever SSL summary data is available]
I like seeing both the source and destination sockaddrs. (Why not run two instances on different interfaces?) In fact, I like seeing both hostname and ip address, and an indicator if a reverse map doesn't match, but that's probably just me.
Hmm. I'm not sure about the destination address. Destination port would be useful, but I don't personally care about seeing the address. Probably not worth doing it optionally either. Guess I'd add it then.
DNS lookups then .. Not by default, and rather not with having to distribute some DNS library. I don't see any simple way to do that. Also only IPv6 capable async DNS library I know of is patched libadns.
It would also be nice for perf. anal. to know how much I/O to storage (disk) was performed by the imap process, but I don't imagine those figures are presently available anyway.
Not very easily, especially about the indexes since they're just mmap()ed and accessed randomly. Reading the mailbox files is more possible, but probably not worth the trouble. Maybe that could be done in OS-level by some existing patch?
That's just an illustration; it doesn't matter to me whether it's like that particularly. I just want to show what I mean by ease of parsing -- whitespace-separated fields, well-known field values, related flags and such compounded within fields. The whole line structure should be well-known and not require perl or sscanf()s or such; scripts should be able to extract a lot of data from these quickly.
Yes, agreed. I just tend to forget this :)
I think the only configuration needed would be if to log login, logout or both.
That's generous. :) I'd always want both, and can't imagine not wanting both, but I suppose some might prefer less.
I don't care about the I/O or time used in those small systems that I use. Login might not be very useful to others who only wish to see the stats, not who has most recently logged in. Of course disabling logins could hide some of them if the process crashes.
I actually wouldn't mind seeing more optional logs -- for example, logout-like summaries for folder accesses (when users change folders). This can help in balancing storage devices when folders can reside on multiple devices.
In an ideal world, everything would be loggable, but not everything would be logged.
Want to give a larger list that you'd think would be useful to log? I can't think of many user actions that'd be worth logging. There's already rawlog for logging _everything_ :)
participants (4)
-
Amelia A Lewis
-
David Champion
-
Jesse Peterson
-
Timo Sirainen