-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Geoip processor: dropping logs when IP not found #35047
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Note that I enabled the retry_on_failure parameter of the filelog receiver, that is when I got the error above. Prior to that, I was getting another message, though still same type of geo ip error with dropped logs |
Thank you @rogercoll |
This is a good workaround @grioda01, thanks for describing it. @rogercoll Before we reach conclusion in the discussion on error mode configuration, how about we change the current behavior to not error out when the IP is not found in the geo database? I believe the default behavior should be to not error out anyway. What do you think? |
I completely agree. That is the industry behavior, after all. THat's how other log shipper behave. Besides, it keeps things simpler. |
Sounds good to me, I agree that this should not be an error and output a log (for debugging). I can work on a PR to skip this error for the MaxMind provider. |
@andrzej-stencel @grioda01 I opened this PR to not prevent throwing an error when an IP is not found. Please, let me know what are your thoughts: #35278 |
**Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> If a provider does not found any associated metadata to the given IP, the processor will continue the processing instead of returning the error. Nonetheless, the error will be logged when debug telemetry level is enabled. **Link to tracking Issue:** <Issue number if applicable> #35047 **Testing:** <Describe what testing was performed and which tests were added.> Add a testdata case for IP `1.2.3.5` which is not available in any of the providers (maxmind neither mocked provider) **Documentation:** <Describe the documentation added.>
…etry#35278) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> If a provider does not found any associated metadata to the given IP, the processor will continue the processing instead of returning the error. Nonetheless, the error will be logged when debug telemetry level is enabled. **Link to tracking Issue:** <Issue number if applicable> open-telemetry#35047 **Testing:** <Describe what testing was performed and which tests were added.> Add a testdata case for IP `1.2.3.5` which is not available in any of the providers (maxmind neither mocked provider) **Documentation:** <Describe the documentation added.>
I tested it last week in live prod environment. It worked and it saved the day!!! thanks so much, it was published just in time |
Component(s)
processor/geoip
What happened?
Description
Apparently, when the source.address is present and contains an IP that is not in the database (such as an internal network IP) an error is issued saying that log entry is dropped
Steps to Reproduce
Kubernetes operator installation with collector in daemonset mode, receiver is filelog and processor is Geoip in alpha.
Expected Result
No geo location field should be populated and the log entry should not be dropped
Actual Result
Log entry is dropped and an error is issued in the opentelemetry collector pod log
2024-09-06T08:34:02.523Z error consumerretry/logs.go:87 Max elapsed time expired. Dropping data. {"kind": "receiver", "name": "filelog", "data_type": "logs", "error": "no geo IP metadata found", "dropped_items": 100}
github.com/open-telemetry/opentelemetry-collector-contrib/internal/coreinternal/consumerretry.(*logsConsumer).ConsumeLogs
github.com/open-telemetry/opentelemetry-collector-contrib/internal/coreinternal@v0.108.0/consumerretry/logs.go:87
github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza/adapter.(*receiver).consumerLoop
github.com/open-telemetry/opentelemetry-collector-contrib/pkg/stanza@v0.108.0/adapter/receiver.go:126
Collector version
v0.108.0
Environment information
Environment
OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")
OpenTelemetry Collector configuration
Log output
Additional context
It works well if the IP is found in the maxmindDB. It's almost like the fact that the IP is not found creates a delay so long that the receiver times out and drops logs
The text was updated successfully, but these errors were encountered: