Re: [otrs] How is OTRS logging structured?

18 Oct 2012

      log file corruption on simultaneous script execution? Never. But I don't do
millions of transactions per minute, either, and neither does OTRS. I would
assume that the likelihood of this being simultaneous *enough* to cause a
problem would be so infrequent as to to be statistically negligible, and
even then, I would hope and expect file locking during the time required to
append what amounts to 100 bytes (?) would properly be handled. Even more
so, since the logs are handled by the same method that the entire OS uses,
and I'm reasonably certain few people are concerned about simultaneous
clobbering of logging files. At least, it's not high on most people's
priority list because it's just not something that's been often evidenced.
Further, a journalling file system may mitigate this as well, but I'm not
in a place to say it couldn't happen. It's just not the thing I should
spend an entire thread discussing unless it has.

As for job that closes tickets, No, I don't know why it didn't log. It may
not have stored in otrs.log (Maybe?) but it would have been stored in the
ticket's history, for sure.

On Thu, Oct 18, 2012 at 5:24 AM, Bogdan Iosif wrote:
...
Thanks for the previous answers.
Have you experienced otrs.log file corruption or any other weird results
resulting from two Perl processes (one invoked from cron and one apache via
mod_perl) trying to execute simultaneously the script implementing OTRS's
log module for the purpose of logging a message to otrs.log?
I need more hands on experience to determine what will get logged to
apache's / cron's logs. I'm thinking errors arising from syntactically
flawed Perl scripts would get logged there.
As far as Generic Agent jobs go... I can see otrs.log contains entries for
executions of jobs according with Generic Agent jobs' own schedule
(~independent of cron) but there are no entries about what each execution
did (I tried a simple job that closes some tickets, it worked but there was
no mention in the log about the tickets getting closed). Is there any way
to log such details by increasing OTRS's log level or something similar?
/bogdan
P.S: Sorry for not being able to respond quicker, there's a hefty time
difference between us, I think (I'm in Bucharest, Romania, Eastern Europe)
On Wed, Oct 17, 2012 at 6:08 PM, Gerald Young  wrote:
...
Apache errors are apache errors. These could be anything that apache
doesn't understand. OTRS application based logging happens in otrs logs via
the method described. The front end interface to the application has
different things that it checks, and may be out of the scope of what OTRS
knows, and vice versa. It is entirely possible that OTRS can receive and
manage tickets with all other events, filters, and cron jobs executing
without apache running. Whether Agents can interact with tickets is a
different issue, but the provider of the web interface (apache, iis, nginx,
etc) and OTRS may not know anything about the other.
Re: logging from cron: the fact that a job runs or not is logged via the
appropriate logging method of the cron service. This only tells you that it
tried to run it.
Anything that the job does to otrs, if the job uses API and the API logs
something, will be handled via OTRS's syslog facility. As with any other
service, the provider of the service and OTRS itself may be agnostic to
anything the service does. OTRS won't know the cron job has run. It will
report in its syslog facility (see my link) on what it knows in the
application. Timestamps in OTRS's syslog should concur with the cron job
being run, but to OTRS, it is immaterial that the job is being run by cron
or by command line. The cron service has no clue that it is running an OTRS
job, on its own, but may report on errors if such is configured in the
crontab.
On Wed, Oct 17, 2012 at 10:52 AM, Bogdan Iosif wrote:
...
I get the fact that on *nix systems, otrs.log is likely replaced by
syslog.
Apache's error.log, I'm most confused about, especially in relationship
with otrs.log. Will errors commonly appear in both logs in different form
or is my initial (3.2.1) assumption generally true in that an error usually
appears in apache's error log if it's missed by OTRS's code.
Also, I saw references in mailing list entries / forums pointing users
to check OTRS's "console log". I don't know what that usually means.
Apache's error.log, otrs.log/syslog, both or something else?
Logging from jobs invoked via cron[w] are another source of mystery. Do
the jobs coming with OTRS by default perform their logging to
syslog/otrs.log or do they do it by using cron's log? Auditing some kind of
output from Generic Agent's executions is of special interest to me because
I hate running that without being able to see exactly what it did or did
not do.
Thanks,
bogdan
On Wed, Oct 17, 2012 at 5:06 PM, Gerald Young wrote:
...
I want to plug this link ...
http://forums.otterhub.org/viewtopic.php?f=60&t=16826
2 through 4 are application/operating system specific file locations,
but much of what you've described appears to be accurate.
In *general*, the only truly relevant logs are otrs.log/syslog (per the
link above, more information) and apache logs.
On the other hand, application specific logs would troubleshoot
problems with, for instance, email or cron jobs not running. Much of the
time, these issues do not relate to problems with OTRS, but with the
service OTRS calls.
TicketCounter.log is also in var/log/ and is relevant in different ways
to different ticket numbering schemes.
On Wed, Oct 17, 2012 at 9:46 AM, Bogdan Iosif wrote:
...
Hi,
What is the big picture of an OTRS instance's logging subsystem[s]?
Please validate / complete the following statements or maybe paint
your own picture or point me to a doc source (i failed to Google my way to
one):
- (1) files: %OTRS_HOME%\var\logs\*.log
      - (1.1) "otrs.log"
         - (1.1.1) Are these statements correct? : "otrs.log" is the
         main log file where entries are written only via the "Kernel::System::Log"
         core module. Investigation for most non-trivial OTRS errors should start by
         looking in "otrs.log".
      - (1.2) "SchedulerERR*.log" / "SchedulerOUT*.log"
         - (1.2.1) What purpose do these files serve?
      - (1.3) Are there other log files commonly found in this folder?
   - (2) GUI: ADMIN -> "System Log"
      - (2.1) Are these statements correct? : "otrs.log" from (1.1)
      is exposed in this GUI on *nix installations but not on Windows
      http://doc.otrs.org/3.1/en/html/adminarea-system-log.html
   - (3) files: %APACHE_HOME%\logs\*.log
      - (3.1) "access.log"
         - (3.1.1) Are these statements correct? : Not very
         interesting for OTRS error analysis. Documented here
         http://httpd.apache.org/docs/2.2/logs.html#accesslog
      - (3.2) "error.log"
         - (3.2.1) Are these statements correct? : When OTRS crashes
         really bad, this is the log to look at. "Console" log for mod_perl???
         Documented here
         http://httpd.apache.org/docs/2.2/logs.html#errorlog
      - (3.3) Are there other log files commonly found in this folder?
   - (4) files: %CRONW_HOME%\logs\*.log
      - (4.1) "cronw.log"
         - (4.1.1) Are these statements correct? : Specific to
         Windows. Cronw writes to this log, depending on its logging level, when it
         starts up, reloads crontab or executes various entries in crontab
         - (4.1.1) Since Generic Agent jobs are run from cronw, will
         errors encountered by these jobs be written to this log? If not, then
         where? Any relationship to (1.2)? Is it possible to log some kind of output
         from Generic Agent jobs for audit purposes? If so, how?
         - (4.2) Are there other log files commonly found in this
      folder?
Looks like a quiz but I was just trying to make it easy to answer to a
particular question.
Thanks,
Bogdan
P.S: I'm running v3.1.10 on Windows with the configuration deployed by
the Windows installer OTRS package (Apache/StrawberryPerl/mysql)
---------------------------------------------------------------------
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