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

bugs at horde.org bugs at horde.org
Wed Jan 7 18:28:30 UTC 2009


Ticket URL: http://bugs.horde.org/ticket/7829
  Ticket             | 7829
  Created By         | thomas at gelf.net
  Summary            | Improve / standarize / clean up log messages
  Queue              | Horde Groupware Webmail Edition
  Version            | 1.2.1
  Type               | Enhancement
  State              | New
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |

thomas at gelf.net (2009-01-07 13:28) wrote:

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  

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

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: ' Ihre Webmail-Session ist  
abgelaufen...' -> should not be German
- on line 67 of imp/login.php: ' 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'

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  

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  

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 ;-)

More information about the bugs mailing list