search

gjcarneiro / yacron

A modern Cron replacement that is Docker-friendly
MIT License
449 stars 38 forks source link

wish: timestamps for log outputs #82

Closed andreas-wittig closed 1 year ago

andreas-wittig commented 1 year ago

Description

This wish is similiar to https://github.com/gjcarneiro/yacron/issues/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 commented 1 year ago

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 https://github.com/gjcarneiro/yacron/issues/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 https://github.com/gjcarneiro/yacron/issues/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 commented 1 year ago

Hi gjcarneiro, yes I understand your feedback.

gjcarneiro commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Fixed in 0.19