I recommend you ignore Windows Event Log and use a logging framework that handles file logging at the same capability level as log4j. Reasons are below.
Most applications writing to Windows' Event Log do so in a non-chatty manner, for special events. You will at least have to comply with this modus operandi when writing to the Application log. I'm assuming you would create a dedicate OTRS Windows Event Log to handle all output currently going into the otrs.log file. In this case, the following problems will arise: 1. The Event Log is not primarily designed for high frequency logging and thus it will be less efficient than writing to a file. My fresh OTRS installation writes about 80 MB / month to its log. That's about 500.000 lines and I haven't changed anything from the default logging settings (imagine those numbers if I would have to enable debugging for a couple of days). I don't know of any application that writes so much to the Windows Event Log. SQL Server / IIS both still use file logging and for good reason. 2. The toolset used to analyze logging info will be fragmented leading to much more difficult administration / debugging. Currently, admins must only use a single tool that is (very) good at searching in large-ish files in order to extract info from logs written by apache, otrs, mysql and, possibly, cronw. When you introduce Windows Event Log into the picture you'll throw a wrench in this workflow. To make it worse, take into consideration the (very) different capabilities of the Event Log across Windows 2003, 2008 and 2012. In my opinion, application specific logging is best kept towards dedicated files. The only problem is to use a logging framework that is advanced enough to make it easy for admins when deciding what goes into the file and how size is managed. Look at log4j as a model. I see there's a version for Perl also ( http://mschilli.github.com/log4perl/ ). If it's good enough and it has followed the log4j mantra (as expected from any log4* project) then it is the perfect tool for the job. On Tue, Mar 26, 2013 at 3:40 PM, Michiel Beijen <michiel.bei...@otrs.com>wrote: > It's a core module of perl (and in 'corelist') but beware: it is not > installed by default if you're on Windows. > You can add it afterwards using cpan, but not if your perl is in a path > containing spaces (such as when you installed using the OTRS installer in > C:\Program Files\OTRS) > > In newer releases of the OTRS Windows installer I made sure Sys::Syslog is > installed, so you can use it if you want. Also I'd like to switch to using > the Windows event log by default in the 'future', meaning probably for OTRS > 3.3. > -- > Mike > On Tue, Mar 26, 2013 at 2:28 PM, Gerald Young <cryth...@gmail.com> wrote: > >> Sys::Syslog is a core module of perl. Changing the method to Syslog >> $Self->{LogModule} = 'Kernel::System::Log::SysLog'; >> $Self->{'LogModule::SysLog::LogSock'} = 'eventlog'; >> Theoretically, you should be able to see if this works quite quickly. >> >> >> On Tue, Mar 26, 2013 at 9:03 AM, Bogdan Iosif <bogdan.io...@gmail.com>wrote: >> >>> I'm running on Windows so I can't use neither SysLog or logrotate (I >>> think). >>> >>> Do you know if OTRS holds a file lock on "otrs.log"? >>> >>> Worst case I could write something that periodically checks this file's >>> size and when a threshold is reached it just moves it to some storage / >>> archive. I was hoping OTRS's code uses a logging framework - like log4* - >>> that can be configured to handle all these log file management options but >>> it looks like that's not the case. >>> >>> >>> >>> On Tue, Mar 26, 2013 at 2:43 PM, Gerald Young <cryth...@gmail.com>wrote: >>> >>>> You don't have to use LogFile. You can use SysLog and handle that way, >>>> even sending to Windows Event Viewer. >>>> http://forums.otterhub.org/viewtopic.php?f=60&t=16826 >>>> >>>> Or just use logrotate. >>>> >>>> >>>> >>>> >>>> On Tue, Mar 26, 2013 at 5:59 AM, Bogdan Iosif >>>> <bogdan.io...@gmail.com>wrote: >>>> >>>>> Hi list, >>>>> >>>>> I'm trying to keep the size of LogModule::LogFile in check in a better >>>>> way than allowed by configuring LogModule::LogFile::Date, which gives me >>>>> rollover to a new file every month. >>>>> >>>>> A config that allows limiting the log file size (with overwrite when >>>>> threshold is reached or rolling over to a new file) is what I'm looking >>>>> for. >>>>> >>>>> Does OTRS have something like that? >>>>> >>>>> /bogdan >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>>>> Archive: http://lists.otrs.org/pipermail/otrs >>>>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>>> Archive: http://lists.otrs.org/pipermail/otrs >>>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>>> >>> >>> >>> --------------------------------------------------------------------- >>> OTRS mailing list: otrs - Webpage: http://otrs.org/ >>> Archive: http://lists.otrs.org/pipermail/otrs >>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >>> >> >> >> --------------------------------------------------------------------- >> OTRS mailing list: otrs - Webpage: http://otrs.org/ >> Archive: http://lists.otrs.org/pipermail/otrs >> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >> > > > --------------------------------------------------------------------- > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
