-
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
[pkg/ottl]: Support coercing too-new timestamps #26507
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
It would be more appropriate to have it as part of OTTL and the transform processor instead of something inside the Loki exporter. |
I agree. How do I go about making this a feature request for OTTL, then? |
I changed the labels for this, so that it's now about OTTL instead of Loki exporter. The code owners should be pinged shortly. |
Pinging code owners for pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
We are doing a lot of work to improve time manipulation in OTTL (and it is almost done), and you're right that we need a |
Certainly! I can take a crack at it. The only other OTTL func I could see that is similar in only producing an output without an input is UUID. Is that along the lines of what you're looking for? A |
Ya it would be similar to UUID(). It should take nothing and return the value of time.Now(). |
@wbh1 are you still interested in contributing the function? I'd like to get this capability in before the next release. Let me know if that is feasible for you. If not, I can take over. |
Hey @TylerHelmuth, yes I am! I actually picked it up today and should be able to get a PR up |
Implement a new OTTL function that takes no inputs and returns the current time. **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.--> Adds a simple OTTL function that returns the current system time. **Link to tracking Issue:** Closes #26507 **Testing:** Added tests to confirm that function returns no errors and returns a time that is consistent. **Documentation:** Updated OTTL Functions README.
For future internet explorers, a solution to fix Loki rejecting logs from otelcol for having a timestamp that is too new is to apply a transform/timestamps:
error_mode: ignore
log_statements:
- context: log
statements:
# If the timestamp attached to the log is from the future, set it to the time that the otelgw received it
# to avoid having the log rejected from Loki
- set(time, Now()) where time > Now() |
Implement a new OTTL function that takes no inputs and returns the current time. **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.--> Adds a simple OTTL function that returns the current system time. **Link to tracking Issue:** Closes open-telemetry#26507 **Testing:** Added tests to confirm that function returns no errors and returns a time that is consistent. **Documentation:** Updated OTTL Functions README.
Component(s)
exporter/loki
Is your feature request related to a problem? Please describe.
Loki will refuse to receive logs that have a timestamp newer than the time on the Loki ingester process.
Example output:
Sep 7 12:47:22 otelgw-3 otelcol-contrib[1305727]: 2023-09-07T12:47:22.483Z#011error#011exporterhelper/queued_retry.go:401#011Exporting failed. The error is not retryable. Dropping data.#011{"kind": "exporter", "data_type": "logs", "name": "loki/prod", "error": "Permanent error: HTTP 400 \"Bad Request\": entry for stream '{component=\"hosts\", datacenter=\"shg1\", environment=\"production\", exporter=\"OTLP\", instance=\"REDACTED\", path=\"/var/log/auth.log\"}' has timestamp too new: 2023-09-07T13:23:01Z", "dropped_items": 68}
This happens sometimes in our environment when NTP gets messed up on a server and its time is actually ahead of the real time. Then, we're alerted to an increase in exporter failures.
Describe the solution you'd like
Ideally, it'd be nice to have an optional feature to coerce timestamps before exporting to Loki (maybe here)?
Logic would look like:
Describe alternatives you've considered
We've tried using OTTL to transform the timestamp/observed timestamp fields, but there doesn't seem to be a way to get the current system time.
Additional context
No response
The text was updated successfully, but these errors were encountered: