[TYPO3-v4] Harmonizing severity levels

[Ernesto Baschny [cron IT]]

Am 05.11.2010 20:42, schrieb François Suter:

>> We have sysLog!
>> -----------------
>>
>> But try to keep in mind that in TYPO3 core we have sysLog(), which is
>> probably what people are confusing when trying to find the "right set"
>> of severities, comparing with Unix syslog and Log4j:
>>
>> // Severity constants used by t3lib_div::sysLog()
>> const SYSLOG_SEVERITY_INFO = 0;
>> const SYSLOG_SEVERITY_NOTICE = 1;
>> const SYSLOG_SEVERITY_WARNING = 2;
>> const SYSLOG_SEVERITY_ERROR = 3;
>> const SYSLOG_SEVERITY_FATAL = 4;
>>
>> devLog() doesn't need to have this complexity. Its a "developer log"
>> which sounds to me that it is required only during development or for
>> debugging purposes. Its already very confusing for a developer to
>> understand when to use devLog and when sysLog, more confusing because
>> both allow similar severities.

> Yes, we have sysLog, but this can't be compared with devLog. sysLog logs
> to some file, send mails or uses the server's syslog or PHP's error log.
> While this is useful sometimes, it is not easy to browse or search for
> records, compared to what the "devlog" extension offers with its
> database storage. I never use it for debugging.

Yes, that's what I meant by "make devlog extension a syslog" extension, 
because sysLog() allows hooks like devLog() does.

No "newby" knows that there *is* a sysLog which might contain useful 
information, because it is very ugly and non-TYPO3ish to configure (PHP 
error_log?? Unix syslog? which "regular user" knows about those?). But 
lots of Core functions use sysLog() to log very important information.

Syslog should have a nice interface in the backend by default and 
similar features of your "devlog" extension. Which is why I suggested 
having it as a sysext.

> And yes, to reply to your other mail, we also have
> $GLOBALS['BE_USER']->writelog() which writes to the sys_log table.
> This one has several more problems IMO:
>
> 1) it already logs a lot of things. So if you want additional output, it
> may well be lost among all the rest. For example, an entry in sys_log is
> created for every TCEmain manipulation. On many of clients sites I
> import data every night, meaning that I have some 20,000 records in
> sys_log created *every day*. How should I find some extra logging in the
> midst of all this?

You should disable writelog logging in TCEmain before starting a batch 
import: $tce->enableLogging = FALSE;

> 2) devLog serves yet another purpose that sys_log IMO. sys_log for me is
> exactly what its name implies: a log of system activity (TCEmain, login,
> etc.). devLog OTOH is for development.

Exactly. sys_log is what the admin / user needs and uses.

 > As you mention below TYPO3 can
> run in "full debug" mode when TYPO3_DLOG is on. Same goes for
> extensions. As such the devLog may also generate a vast quantity of
> entries, which you generally want to filter in some way (and here I mean
> filter *before* logging and not filter on display). The "devlog"
> extension offers a lot of criteria for such filtering.
> 3) the sys_log BE module totally sucks, whereas the devLog has been
> through many improvement cycles.
> What I find redundant is sysLog and sys_log.

Yes, don't get me wrong, but I find devLog as redundant. Its just that 
is contains more features, but why not bundle all together?

>> An admin / developer enables DLOG in Install Tool only while trying to
>> figure out why something doesn't work or while developing their
>> extension. I usually use devLog as a "nicer way" to "debug()".
>
> It's not just a nicer way to debug(). When you have some asynchronous
> stuff (e.g. Scheduler tasks) that you want to debug or some other kind
> of actions that happen when you're not looking, debug() is useless. You
> need log such output.

Yes, that is what I call "nicer".

>> => If an extension (or some core component) encounters an error, it
>> should not use devLog to report it!!! It should log to sysLog, else only
>> developers will see the error.
>
> Not only. IMO it should also log to sys_log.

See what I mean. :) There is not even an official recommendation on 
where and how to log. TYPO3 should have a logging documentation or get 
rid of that many possibilities.

>> I personally would prefer to have one single "logging" interface:
>> "sysLog":
>>
>> - adding a SYSLOG_SEVERITY_DEBUG = -1
>> - transform the "devlog" extension into a general "syslog" extension
>> - integrate it into core as a sysext.
>>
>> Its a shame that several TYPO3 installations doesn't even know about
>> sysLog because it is not configured by default.

> What I would see is to introduce the structure I'm currently working on
> for the devlog: there's a central logging method which then calls a
> number of "log writers", that may write to various supports (database,
> file, error log, whatever). In a sense this is what t3lib_div::devLog()
> was meant for originally (as it just defines a hook), but my experience
> shows that it's nice to be able to filter log entries using many
> criteria before writing them. And those setting should be valid for all
> log writers, rather than having to be defined again and again for each
> extension that implements the t3lib_div::devLog() hook.
> Furthermore if we have a more consistent structure, maybe we could have
> a single BE module to read all logs (and just switch between log sources).

Yes, a central logging method would be great, and the severities from 
sysLog are fine with that, just adding DEBUG to it (or maybe even TRACE 
for even more detailed stuff), but then have all features in place so 
that every extension uses this central logging instance.

I thought to just use t3lib_div::sysLog, because its there already, it 
is being used, it already interfaces to "file" and "syslog()" by default 
and it is hookeable just like devLog() also is.

>> BTW: I find it silly that our core authentication services activate
>> their devLog calls when DLOG is enabled. Usually these userauth devlogs
>> are only interesting if you are trying to debug some authentication
>> mechanism and there is already a SC_OPTIONS to activate it. See attached
>> patch #1, maybe others have a similar feeling.

> Well, DLOG is supposed to be a general debugging flag. RealURL also logs
> everything if DLOG is on.

Not really, because you need to switch realUrls "enableDevLog" (ext 
manager) ON *and* have DLOG activated before it starts logging. This is 
differnet in the auth-services, because those are logged in any case as 
soon as you activate DLOG.

The constant TYPO3_DLOG was introducted to allow devLog() calls be kept 
in the code without affecting (so much) the performance, by using:

   if (TYPO3_DLOG) t3lib_div::devLog ...

So every extension, every developer and even the core does it differently.

 > In my own extensions I generally have my own
> debug flag, but also react on the DLOG flag.

Another reason to make this more generic and a central logging interface 
which is known to everybody and which could decide which logs from which 
extensions in which severities should go *where* (database, mail, file, 
SMS alert, ...).

And for the "database" part, we could re-use lots of the interface 
"devlog" extension is currently providing.

And if we end up with the nice feature of sys_log which is to provide 
*translations* for log messages, we might even integrate this also in 
this central logging routine.

Cheers,
Ernesto