-
Notifications
You must be signed in to change notification settings - Fork 889
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more attributes for Cassandra to database semantic conventions #1217
Add more attributes for Cassandra to database semantic conventions #1217
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @FrankSpitulski!
While some SIGs use PR titles as the one here, this is not common in the spec repo. Apart from that, please use the correct term "attribute" or people might get confused. What about "Add more attributes for Cassandra to database semantic conventions"?
Also please add an entry in CHANGELOG.md
.
Thanks!
- id: table | ||
type: string | ||
tag: call-level-tech-specific | ||
brief: > | ||
The table being queried. | ||
examples: 'mytable' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could consider using db.sql.table
instead which has the same meaning and a more elaborate definition. CQL is close to SQL after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having a separate attribute here for cassandra is fine. Otherwise we might want to rename db.sql.table
to db.table
after all and describe to which technologies it applies. But I think I prefer the separate attribute a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 I agree that should either be separate or use a top level db attribute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There isn't much more to say @SergeyKanzhelev unless you have a new suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bumping, will get to this eventually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Oberon00, I just had a closer look. It seems it already is a different convention group that extends the generic db.
groups:
- id: db ...
- id: db.mssql ...
- id: db.cassandra
prefix: db.cassandra
extends: db
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, then it should be possible to just edit the magic HTML comments in the markdown to generate that in a separate table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think we have to remove it from the db.tech
group below, then we can put it in a separate table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Oberon00 it's been split
Co-authored-by: Armin Ruech <[email protected]>
Co-authored-by: Armin Ruech <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
It would be great if someone more familiar with Cassandra than me could take a look as well 🙂
| `db.cassandra.page_size` | number | The page size of the query. | `5000` | No | | ||
| `db.cassandra.consistency_level` | string enum | The consistency level of the query. Based on consistency values from [cql](https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/dml/dmlConfigConsistency.html). | `ALL` | No | | ||
| `db.cassandra.table` | string | The table being queried. | `mytable` | No | | ||
| `db.cassandra.idempotence` | boolean | Whether or not the query is idempotent. | | No | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who can determine whether a query is idempotent? This does not sound like Cassandra specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every query is marked as idempotent or not. https://docs.datastax.com/en/devapp/doc/devapp/driversQueryIdempotence.html
Co-authored-by: Armin Ruech <[email protected]>
Co-authored-by: Armin Ruech <[email protected]>
Co-authored-by: Armin Ruech <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
It would be great if someone more familiar with Cassandra than me could take a look as well 🙂
I am still concerned with this: #1217 (comment) two attributes with the similar semantic in the same table:
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
@SergeyKanzhelev It's been moved to a new table |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but if somebody with the experience of running Cassandra can comment - would be great.
@open-telemetry/technical-committee does anything prevent this from merging? Either we don't have "somebody with the experience of running Cassandra" or they do not object. Either way there is no point in waiting forever, is it? |
- id: table | ||
type: string | ||
tag: call-level-tech-specific | ||
brief: > | ||
The table being queried. | ||
examples: 'mytable' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think we have to remove it from the db.tech
group below, then we can put it in a separate table.
|
||
Separated for clarity. | ||
|
||
<!-- semconv db.tech(tag=call-level-tech-specific-cassandra) --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be cleaner if you used
<!-- semconv db.tech(tag=call-level-tech-specific-cassandra) --> | |
<!-- semconv db.cassandra --> |
here. Then you could remove the tag: call-level-tech-specific-cassandra
line everywhere.
Also, you can remove the include:
for cassandra from db.tech
.
Separated for clarity. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separated for clarity. |
IMHO: Let's merge it, and address my YAML nitpicks later. We can't make the review periods arbitrarily long and still expect contributors to respond. |
…pen-telemetry#1217) * feat(cassandra): more tags * Update semantic_conventions/trace/database.yaml Co-authored-by: Armin Ruech <[email protected]> * Update semantic_conventions/trace/database.yaml Co-authored-by: Armin Ruech <[email protected]> * Update semantic_conventions/trace/database.yaml Co-authored-by: Armin Ruech <[email protected]> * incorporate changes * Update semantic_conventions/trace/database.yaml Co-authored-by: Armin Ruech <[email protected]> * incorporate feedback * additional feedback * revert unchanged file * Update semantic_conventions/trace/database.yaml Co-authored-by: Armin Ruech <[email protected]> * Update specification/trace/semantic_conventions/database.md Co-authored-by: Armin Ruech <[email protected]> * split cassandra to separate table * Update specification/trace/semantic_conventions/database.md Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Sergey Kanzhelev <[email protected]>
Fixes #1058
Changes
Adds additional optional cassandra tags.
Related issues #
Related instrumentation