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
|`db.mongodb.server_connection_id`|`int64`| Server connection id | Required if available |
218
216
|`db.mongodb.driver_connection_id`|`int64`| Local connection id | Required if available |
219
217
|`db.query.text`|`string`| Database command that was sent to the server. Content should be equivalent to the `document` field of the CommandStartedEvent of the command monitoring. | Conditional |
220
218
|`db.mongodb.cursor_id`|`int64`| If a cursor is created or used in the operation | Required if available |
219
+
|`db.mongodb.lsid`|`string`| Logical session id | Required is available |
220
+
|`db.mongodb.txn_number`|`int64`| Transaction number | Required is available |
221
221
222
222
Besides the attributes listed in the table above, drivers MAY add other attributes from the
223
223
[Semantic Conventions for Databases](https://opentelemetry.io/docs/specs/semconv/registry/attributes/db/) that are
@@ -292,20 +292,20 @@ A common complaint from our support team is that they don't know how to easily g
292
292
Some drivers provide debug logging, but others do not. For drivers that do provide it, the log messages produced and the
293
293
mechanisms for enabling debug logging are inconsistent.
294
294
295
-
Although users can implement their own debug logging support via existing driver events (SDAM, APM, etc), this requires
296
-
code changes. It is often difficult to quickly implement and deploy such changes in production at the time they are
297
-
needed, and to remove the changes afterward. Additionally, there are useful scenarios to log that do not correspond to
298
-
existing events. Standardizing on debug log messages that drivers produce and how to enable/configure logging will
299
-
provide TSEs, CEs, and MongoDB users an easier way to get debugging information out of our drivers, facilitate support
300
-
of drivers for our internal teams, and improve our documentation around troubleshooting.
295
+
OpenTelemetry is currently the industry standard for instrumenting, generating, and collecting telemetry data (metrics,
296
+
logs, and traces). By instrumenting our drivers natively, we allow our end users to collect traces in a
297
+
batteries-included way, with the additional benefits that the tracing is developed and maintained in-house, and conforms
298
+
to the open-source standard for tracing. This also ensures that traces generated on the client-side on driver operations
299
+
can tie into other traces, thus giving our end users a broader picture of the network hops that a single request might
300
+
take.
301
301
302
302
## Test Plan
303
303
304
304
See [OpenTelemetry Tests](tests/README.md) for the test plan.
305
305
306
306
## Covered operations
307
307
308
-
The OpenTelemetry specification covers the following operations:
308
+
The OpenTelemetry specification covers all driver operations including but not limited to the following operations:
0 commit comments