Tickets :: Comment on [#7829] Improve / standarize / clean up log messages

* Your Email Address
* Spam protection	Enter the letters below: __ .___._..__..___ / `[__ \| \| \|[__ \__.\| _\|_\|__\[___
Comment	> Scenario > > -------- > > Most of "my" servers / applications are logging to syslog, and syslog > is sent to central log servers. All logs are then going to be being > parsed / aggregated / archieved / rotated / whatever. This work is > done either by generic or personalized log parsers and log > aggregation daemons. > > > > I'm going to put our beautiful new (D)IMP-based webmail into > production next week, and right now one of my open tasks is adding > Horde/IMP support to our log environment. Doing so I discovered that > this is a "not-so-funny"-task. > > > > Problem description > > ------------------- > > Main problems when trying to parse Horde log lines are: > > - localized / translated log lines > > - log lines completely missing essential information like client ip > and username > > > > Examples > > -------- > > The following are unsorted examples to give you some idea what I'm > trying to talk about: > > - on line 748 of imp/lib/Compose.php: 'Failed to add recipient: ...' > -> no username, no ip > > - on line 195 of imp/lib/IMAP/Cache.php: '[CLOSED] IMAP connection > broken...' -> IDEM > > - on line 67 of imp/login.php: '1.2.3.4 Ihre Webmail-Session ist > abgelaufen...' -> should not be German > > - on line 67 of imp/login.php: '1.2.3.4 Ihre Internetadresse hat sich > geändert...' -> IDEM, and: if logout occurs because of a changed IP, > there should be mentioned 'old ip', 'new ip' and 'username' > > > > Solution > > -------- > > The reason for string translation in login.php is that the "logout > reason" string is going to be passed as an URL parameter for usage as > notification and also log string. Logging should not occur here, it > should happen where the problem got detected, before issueing the > redirect. > > > > I would suggest some "log line format coding standard", all Horde > apps should wherever possible try to follow a common pattern. Some > suggestions for such rules: > > > > - Client IP MUST be logged whenever available > > - Username MUST be logged whenever available > > - Log entries MUST NOT be translated > > - English log lines SHOULD NOT be changed between minor releases > > - Log line components (ip, user, other values, text message) SHALL > always use: your preferred AVP-syntax (for example: key=val[, > key="val ue"]...) > > > > Horde 4 would be a great chance to introduce such changes, as > changing log format in Horde 3.x is probably a not so good idea. > Feedback is welcome! > > > > Best regards, > > Thomas Gelf > > > > NB: As I've been unsure which queue to choose, I've chosen the one > containing most components - please feel free to move this issue > where it fits best in your believes ;-) > >
Attachment
Watch this ticket

Saved Queries