Logging Format should include date-information

[stefanCCS]

trafficstars

Hi, I put this issue here, because I guess it is a "core" feature. If not, please feel free to "move" this to the correct place (or tell me, where to put it).

In the logging output of a process you see something like this: 16:16:01.789 INFO processor.OcropyBinarize ... If the process is running for some days, you cannot see the day, this logging output belongs to. It would be much better to have something like: 2022-07-21 16:16:01.789 INFO processor.OcropyBinarize ...

[kba]

You can adapt the logging with a dedicated logging configuration. For example, copy the bundled example configuration to $HOME/ocrd_logging.conf and adapt the datefmt of the default logger in line 106:

-datefmt=%H:%M:%S
+datefmt=%Y-%m-%d %H:%M:%S

and you get date-stamped log messages.

[stefanCCS]

Oh, nice :-)

[mweidling]

There is also documentation available here. We should also add a section on the website about this in order to make the info more accessible

[stefanCCS]

I have tried out to put ocrd_logging.conf in $(HOME) - see

(venv) ocrdadmin@ocrdtest:~$ tail -3 $HOME/ocrd_logging.conf
[formatter_detailedFormatter]
format=%(asctime)s.%(msecs)03d %(levelname)-8s (%(name)s)[%(filename)s:%(lineno)d] - %(message)s
datefmt=%Y-%m-%d %H:%M:%S

But I still get the output without date: 10:48:25.783 INFO ocrd.workspace.save_mets

Any idea?

[kba]

The formatter_detailedFormatter is configured for the file logging, the one used in console logging is formatter_defaultFormatter.

It should look like this:

tail -12 ~/ocrd_logging.conf    
# default log format conforming to OCR-D (https://ocr-d.de/en/spec/cli#logging)
#
[formatter_defaultFormatter]
format=%(asctime)s.%(msecs)03d %(levelname)s %(name)s - %(message)s
datefmt=%Y-%m-%d %H:%M:%S

#
# store more logging context information
#
[formatter_dtailedFormatter]
format=%(asctime)s.%(msecs)03d %(levelname)-8s (%(name)s)[%(filename)s:%(lineno)d] - %(message)s
datefmt=%Y-%m-%d %H:%M:%S

[stefanCCS]

yes, that's it - many thanks!

@kba: Feel free to close this issue, or keep in open in case you would like to track this documentation topic proposed by @mweidling