-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Elastic Exporter: "400 Bad Request" exception #1269
Comments
cc @axw |
This is coming from the span name, and so far we've been using the span name as-is. We should at least be truncating the name to avoid this error, but ideally the name wouldn't be that long in the first place. The Elastic APM agents create a summary of SQL queries. In this particular case I think we would just call it "SELECT". We could do the same when translating OTel database spans, when the span name is either the same as the statement or otherwise appears to be a complete SQL statement, and hasn't already been summarised by the instrumentation library. |
Understood, I didn't have in mind that the OpenTelemetry Maybe truncating the span name could help. I'm wondering if we could also raise the point to the otel-java-instrumentation project as reusing the entire SQL request in the span.name does not sound aligned with the specification statement:
Note that I found this specification clarification https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#span
|
Ensure span names are no longer than 1024 runes, per the Elastic APM protocol's requirements. Span names longer than this will be truncated to 1024 runes. There will be usability issues with such long span names. Ideally the span name would be shortened, e.g. by having the instrumentation summarise the database statement (as done in Elastic APM agents), or something more specific such as having instrumentation aware of the Postgres JDBC driver's `PgDatabaseMetaData#getTables` method, naming the span after that rather than the SQL that ensues. **Link to tracking Issue:** Fixes #1269 **Testing:** Unit test added.
…orter (#1269) * Export non monotonic counters as gauge values from the prometheus exporter * Add a test to ensure the pre-existing LastValue pathway on the collector exports the last value * Add a TODO around refactoring the prometheus test to verify metadata as well Co-authored-by: Anthony Mirabella <a9@aneurysm9.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Fix #1269 Signed-off-by: Maureen <amaka013@gmail.com> Signed-off-by: Maureen <amaka013@gmail.com>
Fix open-telemetry#1269 Signed-off-by: Maureen <amaka013@gmail.com> Signed-off-by: Maureen <amaka013@gmail.com>
Describe the bug
On OpenTelemetry Collector Contrib 0.12.0
Some messages sent by the OpenTelemetry Collector Elastic Exporter to Elastic APM Server are rejected with a "400 Bad Request" exception : the
transaction.name
length must be <= 1024, but got 1300".This message seems has been received by the collector from a Java application instrumented with otel-java-agent 0.8.0.
This unexpected SQL request has been emitted by the PostgreSQL JDBC driver on the invocation of
PgDatabaseMetaData#getTables
(here).This SQL request should have been reported by the otel java agent as a
db.statement
attribute according to OpenTelemetry Semantic Conventions / Databases.Is it desired that it is reported as a
transaction.name
to Elastic APM?Steps to reproduce
Monitor a Java Hibernate application that uses Hibernate with PostgreSQL
What did you expect to see?
No exception message in the Otel Collector logs.
What did you see instead?
The exception message shared above in the otel collector logs.
What version did you use?
Version: OpenTelemetry Collector Contrib 0.12.0 + Otel Java Agent 0.8.0
What config did you use?
Environment
OS: MacOS 0.15.7
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: