Skip to content
This repository has been archived by the owner on Jul 16, 2019. It is now read-only.

Support log rotation on Windows Server #35

Open
jjcollinge opened this issue Apr 9, 2018 · 2 comments
Open

Support log rotation on Windows Server #35

jjcollinge opened this issue Apr 9, 2018 · 2 comments
Labels
enhancement issues relating to enhancements size/medium medium tasks tooling

Comments

@jjcollinge
Copy link
Owner

If configured to log to file, Traefik will continue to log to disk until... well, no more disk is available. It relies on external tools to rotate the logs. This works well on Linux where you can rotate the file whilst Traefik is writing to it - unfortunately, Windows locks a file handle and thus you cannot rotate the logs without restarting Traefik.

Current options include:

  • You could use something like https://github.com/plecos/logrotatewin with the configuration copytruncate but there is a chance logs written during the 'copy and truncate' operation will be lost.

  • You could also look at configuring Traefik to use a Logrus Hook - https://github.com/Sirupsen/logrus and not write logs to disk. These will forward your logs off box but you may not have logs in the event of a network failure. We have provided a Application Insights hook here Ship logs to Application Insights #28

  • You could mount an elastic volume to each node and write logs to that but you'll have costing and performance implications.

  • Lastly, you could orchestrate a task to execute against each Traefik process 1 at a time, rolling through the update domains that does something like:

  1. kill the process
  2. rotate logs
  3. start the process

Going forward, we need to investigate what the 'recommended' approach is for users.

@jjcollinge jjcollinge added enhancement issues relating to enhancements size/medium medium tasks labels Apr 9, 2018
@lawrencegripper
Copy link
Collaborator

Tagging related: #28

@eladiw
Copy link
Contributor

eladiw commented Apr 26, 2018

Two thoughts regarding this issue:
a) If using AppInsights or similar service with guranteed SLA, not sure that logging to disk is a must.
probably it will be an overhead and not that useful
b) If it is needed, we can possibily add a file size check from within the provider, and then let the provider open a new file with a suffix (incremental number).
this option is both easy to implement and will not cause and data loss

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement issues relating to enhancements size/medium medium tasks tooling
Projects
None yet
Development

No branches or pull requests

3 participants