From ccb6db6f3dbc6fdb4c2ec16b0ed8fccd1e783e4b Mon Sep 17 00:00:00 2001 From: Steve Rao Date: Tue, 9 Apr 2024 10:54:58 +0800 Subject: [PATCH] Update missing modification from `db.operation` to `db.operation.name` (#912) --- docs/database/database-spans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/database/database-spans.md b/docs/database/database-spans.md index 3a758bf22..d43277f9d 100644 --- a/docs/database/database-spans.md +++ b/docs/database/database-spans.md @@ -55,7 +55,7 @@ The **span name** SHOULD be set to a low cardinality value representing the stat It MAY be a stored procedure name (without arguments), DB statement without variable arguments, operation name, etc. Since SQL statements may have very high cardinality even without arguments, SQL spans SHOULD be named the following way, unless the statement is known to be of low cardinality: -` .`, provided that `db.operation` and `db.collection.name` are available. +` .`, provided that `db.operation.name` and `db.collection.name` are available. If `db.collection.name` is not available due to its semantics, the span SHOULD be named ` `. It is not recommended to attempt any client-side parsing of `db.statement` just to get these properties, they should only be used if the library being instrumented already provides them.