Skip to content
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

Merged

Conversation

FrankSpitulski
Copy link
Contributor

Fixes #1058

Changes

Adds additional optional cassandra tags.

Related issues #

Related instrumentation

Copy link
Member

@arminru arminru left a 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!

semantic_conventions/trace/database.yaml Outdated Show resolved Hide resolved
Comment on lines 266 to 271
- id: table
type: string
tag: call-level-tech-specific
brief: >
The table being queried.
examples: 'mytable'
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

db.sql.table is already mentioned in the rendered table. Having both is confusing:
Uploading image.png…

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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

semantic_conventions/trace/database.yaml Outdated Show resolved Hide resolved
semantic_conventions/trace/database.yaml Outdated Show resolved Hide resolved
semantic_conventions/trace/database.yaml Outdated Show resolved Hide resolved
FrankSpitulski and others added 2 commits November 10, 2020 10:49
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
@FrankSpitulski FrankSpitulski changed the title feat(cassandra): more tags Add more attributes for Cassandra to database semantic conventions Nov 10, 2020
Copy link
Member

@arminru arminru left a 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 🙂

semantic_conventions/trace/database.yaml Outdated Show resolved Hide resolved
| `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 |
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FrankSpitulski and others added 2 commits November 13, 2020 12:09
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Copy link
Member

@arminru arminru left a 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 🙂

@arminru arminru added area:semantic-conventions Related to semantic conventions release:allowed-for-ga Editorial changes that can still be added before GA since they don't require action by SIGs spec:trace Related to the specification/trace directory labels Nov 17, 2020
@SergeyKanzhelev
Copy link
Member

I am still concerned with this: #1217 (comment) two attributes with the similar semantic in the same table:

Attribute Type Description Example Required
db.cassandra.table string The table being queried. mytable No
db.sql.table string The name of the primary table that the operation is acting upon, including the schema name (if applicable). [2] public.users
customers
Conditional
Recommended if available.

@github-actions
Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Nov 26, 2020
@FrankSpitulski
Copy link
Contributor Author

@SergeyKanzhelev It's been moved to a new table

@github-actions github-actions bot removed the Stale label Dec 3, 2020
Copy link
Member

@SergeyKanzhelev SergeyKanzhelev left a 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.

@iNikem
Copy link
Contributor

iNikem commented Dec 9, 2020

@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?

Comment on lines 266 to 271
- id: table
type: string
tag: call-level-tech-specific
brief: >
The table being queried.
examples: 'mytable'
Copy link
Member

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) -->
Copy link
Member

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

Suggested change
<!-- 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.

Comment on lines +184 to +185
Separated for clarity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Separated for clarity.

@Oberon00
Copy link
Member

Oberon00 commented Dec 9, 2020

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.

@SergeyKanzhelev SergeyKanzhelev merged commit f48457c into open-telemetry:master Dec 9, 2020
@FrankSpitulski FrankSpitulski deleted the feat/cassandra/more-tags branch December 10, 2020 03:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions release:allowed-for-ga Editorial changes that can still be added before GA since they don't require action by SIGs spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Additional Cassandra Attributes
7 participants