-
Notifications
You must be signed in to change notification settings - Fork 55
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
Sumo Collector spams NoSuchContainer to logs #96
Comments
@yuting-liu can you take a look as this is suspected to be related to the forked docker-java removal? Thanks |
@cptera the error itself seems to be related to that the container didn't get restarted appropriately. Did you happen to see errors from the container log? It might include more details about the error. |
Hmm, you're right, it looks like the container |
Like we deploy everything in a docker swarm and we designed our containers to restart on certain errors and in this case it restarted on an error it should have. We've been running it this way for several years and we don't make major changes very often. |
With the log4j bug our fix of "just using an older version" is no longer viable |
We deploy the
sumologic/collector:latest
image in our customers production environemt to collect logs for our product (a set of containers running) and have it send logs to our sumologic account. Over the last few months we've noticed a lot of spam logs due to the sumologic collector throwing error likeFrom our investigation this is mostly happening for collector
19.351-4
, but it's also happening for19.361-4
and if I had to guess this may be due to switching from the Forked docker-java dependency to the open source one as listed in the release notes for https://github.com/SumoLogic/sumologic-collector-docker/releases/tag/v19.351-4Our main issue is that this causes a lot of our sumo quota to get used up, log collection seems to be functioning fine.
The text was updated successfully, but these errors were encountered: