wish: timestamps for log outputs

[andreas-wittig]

• Yet Another Cron version: yacron-0.18.0-x86_64-unknown-linux-gnu
• Python version: --
• Operating System: Kubernetes/Linux

Description

This wish is similiar to #33
A typical yacron log looks (resp console output) like:

INFO:yacron:Job job_myjob exit code 0; has stdout: false, has stderr: true; fail_reason: None
INFO:yacron:Cron job job_myjob: reporting success
INFO:yacron:Shutting down (after currently running jobs finish)...

This is rather odd for a scheduler: the datetime the events did occur are missing hardly for production environments (where logs are captured in a logfile). The wish is to have a timestamp in the log (which is commaon practice for logfiles), eg:

2023-03-07 01:05:00, INFO:yacron:Job job_myjob exit code 0; has stdout: false, has stderr: true; fail_reason: None
2023-03-07 01:05:02, INFO:yacron:Cron job job_myjob: reporting success
2023-03-07 01:05:04, INFO:yacron:Shutting down (after currently running jobs finish)...

[gjcarneiro]

Fine, we can add the option. But yacron was primarily designed to run inside docker/kubernetes. Inside docker, usually there is a logging framework already that captures the stdout and stderr of the container and ships the logs somewhere, while automatically adding timestamps. In this scenario, it is confusing and ugly to have timestamps, as they will appear in duplicate in the end.

…

On Tue, 7 Mar 2023 at 20:03, andreas-wittig ***@***.***> wrote: - Yet Another Cron version: yacron-0.18.0-x86_64-unknown-linux-gnu - Python version: -- - Operating System: Kubernetes/Linux Description This wish is similiar to #33 <#33> A typical yacron log looks (resp console output) like: INFO:yacron:Job job_myjob exit code 0; has stdout: false, has stderr: true; fail_reason: None INFO:yacron:Cron job job_myjob: reporting success INFO:yacron:Shutting down (after currently running jobs finish)... This is rather odd for a scheduler: the datetime the events did occur are missing hardly for production environments (where logs are captured in a logfile). The wish is to have a timestamp in the log (which is commaon practice for logfiles), eg: 2023-03-07 01:05:00, INFO:yacron:Job job_myjob exit code 0; has stdout: false, has stderr: true; fail_reason: None 2023-03-07 01:05:00, INFO:yacron:Cron job job_myjob: reporting success 2023-03-07 01:05:00, INFO:yacron:Shutting down (after currently running jobs finish)... — Reply to this email directly, view it on GitHub <#82>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQYM2GFIME2EOUQ7RNNUW3W26H7JANCNFSM6AAAAAAVS5KBZU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert

[andreas-wittig]

Hi gjcarneiro, yes I understand your feedback.

• But with this argument all logs in general has to be without timestamps :-| That makes obiously no sense.
• Anyway applications still with Kubernetes have console output where timestamps makes sense - especially for a scheduler! :-)

[gjcarneiro]

If you ship logs with fluentd or whatever, and visualize them in kibana or whatever, then the timestamp is its own field, and is formatted/displayed by the logs UI. Having another timestamp embedded in the message is ugly noise.

In Kubernetes, console output, you can trivially ask for timestamps to be added: kubectl logs podname --timetamps.

[andreas-wittig]

we live in customers cluster. we cannot add resources at wish.
Our delivery to the customer is an Docker-Image; our debug ressource are based on the toolset inside our running container.
It's just an idea that would help. From my point of view timestamps originated by a SCHEDULER are no noise.

[gjcarneiro]

Fixed in 0.19