Closed cyrille-leclerc closed 3 years ago
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 span.name
could have reused the sql statement.
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:
The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans, rather than individual Span instances while still being human-readable.
Note that I found this specification clarification https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#span
The span name concisely identifies the work represented by the Span, for example, an RPC method name, a function name, or the name of a subtask or stage within a larger computation. The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans, rather than individual Span instances while still being human-readable. That is, "get_user" is a reasonable name, while "get_user/314159", where "314159" is a user ID, is not a good name due to its high cardinality. Generality SHOULD be prioritized over human-readability.
For example, here are potential span names for an endpoint that gets a hypothetical account information:
Span Name Guidance get
Too general get_account/42
Too specific get_account
Good, and account_id=42 would make a nice Span attribute get_account/{accountId}
Also good (using the "HTTP route") >
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.