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 (
). 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.