Metrics exemplars #1306
Labels
Comments
dyladan
added
feature-request
up-for-grabs
|
I would like to claim this issue please. |
mayurkale22
removed
the
up-for-grabs
|
Unassigned because internship ended. If I'm wrong about that, please let me know. |
|
Howdy! Is anyone making any progress on this one? |
|
@pragmaticivan Our current metrics API/SDK is well behind the specification so this isn't something to work on the short term i believe |
legendecas
added
the
signal:metrics
|
Closing in favor of #2594. |
pichlermarc
pushed a commit
to dynatrace-oss-contrib/opentelemetry-js
that referenced
this issue
Dec 15, 2023
* refactor(pg): more defensive, DRYer implementation The prior code had three different utility functions for constructing the span to use to trace the query: handleTextQuery, handleConfigQuery, and handleParameterizedQuery. These functions contained a lot of duplicated logic, and that duplication was gonna make it harder to introduce new features (see next commit) and was already leading to bugs/inconsistencies. For example, `handleConfigQuery` would verify that the parameter `values` provided with the query were provided as an array before attaching them to the span, whereas `handleParameterizedQuery` would do so without this validation. This commit instead normalizes the arguments to `client.query` first, so that only function is needed to create the span. In the process of normalizing the arguments, the new code also performs a bit more validation on them, to make sure that the instrumentation will not throw at runtime. For example, the prior code would've thrown on `client.query(null)`, as it was checking `typeof args[0] === 'object'` without excluding null. The prior code also assumed, if an object was passed, that the `text` and `name` keys held a string; this is now verified before attaching that data to the span. Finally, the prior code had two different code paths for invoking the original `client.query` method; one that went through `handleInvalidQuery` and one directly in `_getClientQueryPatch`. The former wrapped the call in a try-catch, while the latter did not. Now, there's only one call to the original client.query, and it's always in a try-catch, which ensures that other cases of invalid args passed to client.query (which might lead it to throw synchronously) won't be an issue. * refactor(pg): dry up attribute generation * fix(pg): spec-compliant span naming BREAKING CHANGE. This improves the way that OTEL span names are generated in two different ways. First, if the query is a prepared statement with a `name`, the `name` is put into the span name as-is. Before, the `name` was transformed first, as though it were a full SQL query string (i.e., it was split on spaces and only the first 'word' was used). Second, when we do only have a full query string, and we take the first word to form the span name, the code now calls `toUpperCase()` on that string, so that a `select * from x` and a `SELECT * from x` query both end up with a span name like `pg.query:SELECT`. * test(pg): more error handling tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
open-telemetry/oteps#113
Still waiting on spec, but this OTEP merged. Creating this tracking issue.
The text was updated successfully, but these errors were encountered: