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

Update database instrumentations to follow semantic conventions #175

Closed

Conversation

srikanthccv
Copy link
Member

Addresses #159

@srikanthccv srikanthccv requested review from a team, toumorokoshi and aabmass and removed request for a team November 10, 2020 14:42
Copy link
Member

@toumorokoshi toumorokoshi left a comment

Choose a reason for hiding this comment

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

code looks good! could you add changelog entries for each the instrumentations? and we should be good to go.

@srikanthccv
Copy link
Member Author

@toumorokoshi I will add the entries. General question for my reference so that I don't miss it in future, What kind of changes require a CHANGELOG entry? Is it all or is it some based on the chage? Thanks !

@toumorokoshi
Copy link
Member

What kind of changes require a CHANGELOG entry?

Pretty much every change that affects user behavior. Something like span attributes changing could be pretty impactful since people author queries and aggregations based on values in specific attributes.

@@ -115,7 +115,7 @@ def wrapper(wrapped, instance, args, kwargs):
@_with_tracer_wrapper
def _wrap_cmd(tracer, cmd, wrapped, instance, args, kwargs):
with tracer.start_as_current_span(
_CMD, kind=SpanKind.INTERNAL, attributes={}
_CMD, kind=SpanKind.CLIENT, attributes={}
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe the span name should be a low-cardinality value representing the executed statement.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would also add db.name as a span attribute to be consistent with the other instrumentations.

Copy link
Member Author

Choose a reason for hiding this comment

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

The span name for all pymemcache commands is memcached.command. Regarding db.name there is db.system which is set to here. Do you think we need db.name set to same as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

The span name for all pymemcache commands is memcached.command

I'm not too familiar in how to use pymemcache, but does that mean there is no "command" or "statement" that is executed?

Do you think we need db.name set to same as well?

Yes, we have db.name in other instrumentations so we should be consistent.

Copy link
Member Author

Choose a reason for hiding this comment

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

It has commands. Yes we should be using them instead of hard-coded memcached.command for span name. I don't think db.name is applicable for memcached.

@@ -73,21 +73,23 @@ def started(self, event: monitoring.CommandStartedEvent):
span = self._tracer.start_span(name, kind=SpanKind.CLIENT)
Copy link
Contributor

Choose a reason for hiding this comment

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

In terms of the name, I think we can remove the "DATABASE_TYPE" portion and just use the command_name.

Copy link
Contributor

Choose a reason for hiding this comment

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

EDIT: We can leave these in until the specs are finalized.

span.set_attribute("db.statement", statement)
if event.connection_id is not None:
span.set_attribute("net.peer.name", event.connection_id[0])
span.set_attribute("net.peer.port", event.connection_id[1])

# pymongo specific, not specified by spec
span.set_attribute("db.mongo.operation_id", event.operation_id)
span.set_attribute("db.mongo.request_id", event.request_id)
span.set_attribute(
Copy link
Contributor

Choose a reason for hiding this comment

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

I would remove these attributes as they are not in the semantic conventions.

Copy link
Member Author

Choose a reason for hiding this comment

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

@toumorokoshi also expressed the same concern on this attrs. I will remove them.

@@ -106,7 +108,7 @@ def succeeded(self, event: monitoring.CommandSucceededEvent):
return
if span.is_recording():
span.set_attribute(
"db.mongo.duration_micros", event.duration_micros
"db.mongodb.duration_micros", event.duration_micros
Copy link
Contributor

Choose a reason for hiding this comment

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

And these should be removed as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

The spec doesn't have these either.

@@ -20,15 +20,14 @@
def _extract_conn_attributes(conn_kwargs):
""" Transform redis conn info into dict """
attributes = {
"db.type": "redis",
Copy link
Contributor

Choose a reason for hiding this comment

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

Span name for redis needs to be fixed too.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is span attribute. The span name for redis is redis.command.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I only highlighted this because Github didn't let point to the above code.

Simiarly to pymemcache for redis, is there not a concept of "statement" or "command"? The string "redis.command" doesn't really tell me much in terms of what logical operation redis is doing.

Copy link
Member Author

Choose a reason for hiding this comment

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

The string "redis.command" doesn't really tell me much in terms of what logical operation redis is doing.

Agree.

@lzchen
Copy link
Contributor

lzchen commented Nov 11, 2020

I think there are a couple of other changes that are missing, from dbapi and asyncpg specifically.
db.system, db.name should be span attributes. The span name should be the command executed. If available provide the attributes related to connections as well.

Copy link
Contributor

@lzchen lzchen left a comment

Choose a reason for hiding this comment

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

Some comments.

@srikanthccv
Copy link
Member Author

db.system, db.name should be span attributes.

Spec has db.system I haven't seen db.name mentioned.

The span name should be the command executed.

I would appreciate some more elaboration on this.

If available provide the attributes related to connections as well.

redis wasn't setting the connection attributes net.peer.name and net.peer.port as mentioned in spec. I have added them in this PR. I only came across redis not doing that I will check others also.

@lzchen
Copy link
Contributor

lzchen commented Nov 12, 2020

@lonewolf3739

Spec has db.system I haven't seen db.name mentioned.

db.name is mentioned under span name in the specs, in which it should be the span name if the "command executed" is not present.

I would appreciate some more elaboration on this.

I expect the name to be the "command executed" on the database. For example, commands for mongobdb.

@srikanthccv
Copy link
Member Author

Hi @lzchen ,

I am thinking of closing this PR in favor of opening multiple small PRs as changes are becoming large. What do you suggest?

@srikanthccv
Copy link
Member Author

This is becoming huge. I will be opening multiple small PRs which will be easier to work and review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants