Clarify how classification by attribute value and presence works #2348
Conversation
tigrannajaryan
changed the title
tigrannajaryan
force-pushed
the
clarify-attr-presence
branch
from
a1a6bba
to
80af1d4
Compare
This topic was discussed verbally multiple times (particularly when we were considering whether the "component" attribute should be borrowed from OpenTracing semantic conventions). This PR captures previous discussions that are not explicitly written anywhere in the spec.
tigrannajaryan
force-pushed
the
clarify-attr-presence
branch
from
80af1d4
to
d88d717
Compare
arminru
added
area:api
| for PostgreSQL. If _there was such a need_, for example if we also needed to | ||
| record the PostgreSQL version number then instead we would choose to record the | ||
| fact that the database is a PostgreSQL by presence of for example attribute | ||
| `db.postgres.version` (in which case we no longer need to store "postgresql" in |
There was a problem hiding this comment.
I think that it's important that a sub-type of something can act as a member of that type. Postgres is a great example- if a user builds a database dashboard that shows the health of all databases in a system, she shouldn't need to sniff out each database individually. A Postgres-specific dashboard can rely on all sorts of Postgres attributes, but that should be in addition to rather than instead of. Similarly Greenplum or TimescaleDB can provide all of the Postgres attributes plus whatever attributes make sense for their specialized use case.
There was a problem hiding this comment.
A Postgres-specific dashboard can rely on all sorts of Postgres attributes, but that should be in addition to rather than instead of
+1 to this one.
There was a problem hiding this comment.
@zenmoto you have a good point. I need to think about I can rewrite the recommendations to take this into account.
|
Thanks for documenting this (much discussed, never written down, as you mentioned) topic :) |
| classification by value (it records 2 facts: that the entity is a database and | ||
| the fact that the database type is PostgreSQL). |
There was a problem hiding this comment.
it records 2 facts: that the entity is a database
I'm interpreting "entity" to mean the thing producing telemetry. If this is what you mean, then I think this statement could lead to confusion because, in practice, telemetry that includes a db.system attribute is not necessarily a database - it might just be a web server interacting with a DB.
My sense is that most of the semantic conventions defined so far have not been successful in classifying the type of entity producing telemetry but rather the conventions classify the context in which telemetry was produced (e.g., "I'm an operation against a DB system" or "I'm a span that was generated by a service running on a VM in AWS").
|
I am converting this to a draft since I don't think it is ready yet, I see gaps that need to be addressed first. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
This topic was discussed verbally multiple times (particularly when we were
considering whether the "component" attribute should be borrowed from
OpenTracing semantic conventions).
This PR captures previous discussions that are not explicitly written anywhere in the spec.