You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The influxdb-2.4 instrumentation records db.operation.name for writes, but it never records db.operation.batch.size, even though a write through InfluxDB.write(BatchPoints) sends a whole batch of points in a single request.
db.operation.batch.size is a stable database semantic-convention attribute, and the point count is readily available on the BatchPoints object the instrumentation already has in hand (BatchPoints.getPoints()). As a result a batch write of, say, 500 points looks identical on the span to a write of a single point, so there is no way to tell how much data a write span actually moved.
Other database instrumentations already capture this. For example, HBase records the batch size for its multi-action operations:
Instrumentation
Batch operation
db.operation.batch.size captured?
hbase-client
HTable.batch(List<Row>)
Yes (HbaseRequest.getOperationBatchSize())
influxdb-2.4
InfluxDB.write(BatchPoints)
No
The information is dropped even though the client hands it straight to the advice:
flowchart LR
A["influxDb.write(batchPoints)<br/>batchPoints has N points"] --> B["InfluxDbModifyAdvice.onEnter<br/>arg0 = BatchPoints"]
B --> C["InfluxDbOperation.create(host, port, database, "write")<br/>point count is dropped here"]
C --> D["InfluxDbAttributesGetter"]
D -->|"db.operation.name = write"| E["write span"]
D -. "getDbOperationBatchSize() not overridden, returns null" .-> E
E --> F["db.operation.batch.size is never set"]
Loading
Describe the solution you'd like
Capture the number of points of a BatchPoints write and expose it as db.operation.batch.size, following the pattern already used by HBase.
Concretely, in instrumentation/influxdb-2.4:
Add a nullable batchSize field to InfluxDbOperation (the @AutoValue request object).
In InfluxDbImplInstrumentation.InfluxDbModifyAdvice#onEnter, when arg0 instanceof BatchPoints, read ((BatchPoints) arg0).getPoints().size() and pass it into InfluxDbOperation.create(...). It stays null for the UDP/createDatabase/deleteDatabase paths, where there is no batch.
Override getDbOperationBatchSize in InfluxDbAttributesGetter to return that value.
No new configuration is needed. The shared DbClientAttributesExtractor already emits db.operation.batch.size under stable semconv and treats a size of 1 as a non-batch operation, so single-point writes are unaffected and only multi-point writes gain the attribute:
flowchart TB
subgraph before["write span today"]
B1["db.system.name = influxdb"]
B2["db.namespace = mydb"]
B3["db.operation.name = write"]
end
subgraph after["write span after the change"]
A1["db.system.name = influxdb"]
A2["db.namespace = mydb"]
A3["db.operation.name = write"]
A4["db.operation.batch.size = 2 (new)"]
end
before --> after
Loading
Expected result for the existing two-point write in InfluxDbClientTest#testQueryAndModifyWithOneArgument (which writes point1 and point2 in one BatchPoints): the write span gains db.operation.batch.size = 2.
Describe alternatives you've considered
Leave it as is. Writes remain indistinguishable regardless of how many points they carry, which loses useful signal that the client already exposes.
Emit the count as an experimental span attribute (e.g. influxdb.points.count) instead of the semconv attribute. This would duplicate an existing stable convention for no benefit, so the standard db.operation.batch.size is preferred.
Record every point as db.query.text. Rejected: point data is user data (line protocol values) and is not a query, so it should not be captured. Only the count is proposed here.
Reference implementation for batch size in another database client: instrumentation/hbase/hbase-client-common-1.4/javaagent/.../HbaseAttributesGetter.java and HbaseRequest.java.
Is your feature request related to a problem? Please describe.
The
influxdb-2.4instrumentation recordsdb.operation.namefor writes, but it never recordsdb.operation.batch.size, even though a write throughInfluxDB.write(BatchPoints)sends a whole batch of points in a single request.db.operation.batch.sizeis a stable database semantic-convention attribute, and the point count is readily available on theBatchPointsobject the instrumentation already has in hand (BatchPoints.getPoints()). As a result a batch write of, say, 500 points looks identical on the span to a write of a single point, so there is no way to tell how much data a write span actually moved.Other database instrumentations already capture this. For example, HBase records the batch size for its multi-action operations:
db.operation.batch.sizecaptured?hbase-clientHTable.batch(List<Row>)HbaseRequest.getOperationBatchSize())influxdb-2.4InfluxDB.write(BatchPoints)The information is dropped even though the client hands it straight to the advice:
Describe the solution you'd like
Capture the number of points of a
BatchPointswrite and expose it asdb.operation.batch.size, following the pattern already used by HBase.Concretely, in
instrumentation/influxdb-2.4:batchSizefield toInfluxDbOperation(the@AutoValuerequest object).InfluxDbImplInstrumentation.InfluxDbModifyAdvice#onEnter, whenarg0 instanceof BatchPoints, read((BatchPoints) arg0).getPoints().size()and pass it intoInfluxDbOperation.create(...). It staysnullfor the UDP/createDatabase/deleteDatabasepaths, where there is no batch.getDbOperationBatchSizeinInfluxDbAttributesGetterto return that value.No new configuration is needed. The shared
DbClientAttributesExtractoralready emitsdb.operation.batch.sizeunder stable semconv and treats a size of1as a non-batch operation, so single-point writes are unaffected and only multi-point writes gain the attribute:flowchart TB subgraph before["write span today"] B1["db.system.name = influxdb"] B2["db.namespace = mydb"] B3["db.operation.name = write"] end subgraph after["write span after the change"] A1["db.system.name = influxdb"] A2["db.namespace = mydb"] A3["db.operation.name = write"] A4["db.operation.batch.size = 2 (new)"] end before --> afterExpected result for the existing two-point write in
InfluxDbClientTest#testQueryAndModifyWithOneArgument(which writespoint1andpoint2in oneBatchPoints): thewritespan gainsdb.operation.batch.size = 2.Describe alternatives you've considered
influxdb.points.count) instead of the semconv attribute. This would duplicate an existing stable convention for no benefit, so the standarddb.operation.batch.sizeis preferred.db.query.text. Rejected: point data is user data (line protocol values) and is not a query, so it should not be captured. Only the count is proposed here.Additional context
Relevant files:
instrumentation/influxdb-2.4/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/influxdb/v2_4/InfluxDbAttributesGetter.javainstrumentation/influxdb-2.4/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/influxdb/v2_4/InfluxDbOperation.javainstrumentation/influxdb-2.4/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/influxdb/v2_4/InfluxDbImplInstrumentation.javainstrumentation/influxdb-2.4/javaagent/src/test/java/io/opentelemetry/javaagent/instrumentation/influxdb/v2_4/InfluxDbClientTest.javaReference implementation for batch size in another database client:
instrumentation/hbase/hbase-client-common-1.4/javaagent/.../HbaseAttributesGetter.javaandHbaseRequest.java.I would like to work on this.