Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

helm: logging improvements #4343

Merged
merged 10 commits into from
Nov 9, 2018
Merged

Conversation

derekperkins
Copy link
Member

@derekperkins derekperkins commented Nov 6, 2018

This PR adds log rotation via logrotate to the helm chart. By default, it rotates logs at 100M, running on an hourly cron.

This also uses the same debian:stretch-slim to tail the error and slow logs, and adds a vitess user/group.

@sougou - Can you create a new Docker repo for logrotate and logtail and have them auto-build like the others?

group=2000 + user=1000 to match existing helm vttablet deployments

Signed-off-by: Derek Perkins <derek@derekperkins.com>
Signed-off-by: Derek Perkins <derek@derekperkins.com>
Signed-off-by: Derek Perkins <derek@derekperkins.com>
Signed-off-by: Derek Perkins <derek@derekperkins.com>
Copy link
Contributor

@dkhenry dkhenry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@derekperkins
Copy link
Member Author

There are two things still bothering me about logging.

  1. I don't like that the logrotate container is running as root
  2. I don't think that the tailing containers (and maybe the logrotate container) are listening for SIGTERM, meaning that upgrades/restarts wait the entire termination deadline before executing.

Signed-off-by: Derek Perkins <derek@derekperkins.com>
the previous method didn’t listen for SIGTERM and so would block restarting

Signed-off-by: Derek Perkins <derek@derekperkins.com>
this doesn’t require root privileges to run, and also listens for SIGTERM

Signed-off-by: Derek Perkins <derek@derekperkins.com>
Signed-off-by: Derek Perkins <derek@derekperkins.com>
also rename slow.log to slow-query.log to match Vitess defaults

Signed-off-by: Derek Perkins <derek@derekperkins.com>
Signed-off-by: Derek Perkins <derek@derekperkins.com>
@derekperkins
Copy link
Member Author

Ok, I solved those two problems.

  1. I changed the logrotate container to use a simple sleep loop instead of a cron and now it can run as the vitess user. I also trap for signals so logrotate doesn't block the pod from restarting.
  2. I created another logtail container that does the tailing, but inside of a bash script that traps signals, and I can confirm that that solves the issue where the pod takes the full deadline before restarting. I have the logging containers start running mysqladmin ping in a loop after receiving a signal but before exiting. That makes sure that we don't miss any logs - especially error logs in the event that something goes wrong during shutdown.

This has been bugging me for a year and I feel pretty good about these changes. @dkhenry - if you could take another look, I made a lot of changes after your last LGTM.

cc @hmcgonig @leoxlin @acharis @msolters @trevex

@trevex
Copy link
Contributor

trevex commented Nov 7, 2018

I created another logtail container that does the tailing, but inside of a bash script that traps signals, and I can confirm that that solves the issue where the pod takes the full deadline before restarting. I have the logging containers start running mysqladmin ping in a loop after receiving a signal but before exiting. That makes sure that we don't miss any logs - especially error logs in the event that something goes wrong during shutdown.

This is a great quality of life improvement 👍

@derekperkins derekperkins merged commit b06f7c8 into vitessio:master Nov 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants