-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
remove syslog dependency #3563
Comments
@alainjobart What do you think about just deleting the syslogger plugin? To be honest, the syslogger plugin was only added as an example of "what you could do with the event package". I don't think anyone really wants this info piped to syslog. Internally we had a plugin that piped these events to a remote "global event logging" service. Ideally we should make an example plugin for something more analogous like fluentd. |
I'd be fine removing it, it no one uses it. For a sample one, we could just log into the regular logs with a prefix. And enable that by default, instead of syslog. Well if we do that, we could keep the syslog one, just disabled by default... |
If you still want to make sure there's at least one example plugin, I'm fine leaving it disabled by default. |
I would want to export those logs by default in kubernetes for an audit trail |
As running Vitess in k8s has been become more common, we are still logging this type of error for all events generated, since k8s pods almost never run syslog:
Which just makes it hard to read. Can we just convert all events to normal log.* messages if the syslogger cannot be contacted? That way we only log a syslog-related error once (on startup), and that is it. |
…s if the syslog daemon cannot be contacted. Signed-off-by: Jacques Grove <[email protected]>
Should be addressed by #6511 |
…r: remove unused topology watchers (vitessio#3578) * backport of 3563 * fix conflicts Signed-off-by: deepthi <[email protected]> --------- Signed-off-by: deepthi <[email protected]> Co-authored-by: deepthi <[email protected]>
When not mounting the syslog as discussed with @enisoc, I see errors like these, but it appears that we're getting the information that needed to hit the syslog anyways, so I think we're ok.
The text was updated successfully, but these errors were encountered: