You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would appear that the default verbosity of logging is higher than desirable under normal operating conditions. In an attempt to lower the sheer volume of container logs in M-Lab GCP accounts, I started doing some investigation into where the logs were coming from. M-Lab definitely has some chatty sidecar services, but what really stood out to me was the volume of logs for some nodes coming from revtr. For example, for M-Lab machine mlab1-lga08 there are nearly 16,500,000 log entries from revtr over the past 7 days. The logs seem to come in bursts. At the highest rates, at least on this machine, revtr can generate in excess of 500,000 log entries per hour.
As a workaround from the M-Lab perspective, we are going to stop pushing revtr logs to GCP. The logs will still exist in kubernetes for some amount of time, but will no longer be pushed to GCP for slightly longer retention times (30d).
It seems like it might be a good idea to at some point implement some sort of leveled/structured logging where what might be generally considered INFO or DEBUG level message are only emitted via some sort of debug flag, and by default only warning or error message logged.
The text was updated successfully, but these errors were encountered:
It would appear that the default verbosity of logging is higher than desirable under normal operating conditions. In an attempt to lower the sheer volume of container logs in M-Lab GCP accounts, I started doing some investigation into where the logs were coming from. M-Lab definitely has some chatty sidecar services, but what really stood out to me was the volume of logs for some nodes coming from revtr. For example, for M-Lab machine mlab1-lga08 there are nearly 16,500,000 log entries from revtr over the past 7 days. The logs seem to come in bursts. At the highest rates, at least on this machine, revtr can generate in excess of 500,000 log entries per hour.
As a workaround from the M-Lab perspective, we are going to stop pushing revtr logs to GCP. The logs will still exist in kubernetes for some amount of time, but will no longer be pushed to GCP for slightly longer retention times (30d).
It seems like it might be a good idea to at some point implement some sort of leveled/structured logging where what might be generally considered INFO or DEBUG level message are only emitted via some sort of debug flag, and by default only warning or error message logged.
The text was updated successfully, but these errors were encountered: