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

Adding metric collection as part of instrumentations - Django #1230

Merged
merged 17 commits into from
Oct 16, 2020

Conversation

lzchen
Copy link
Contributor

@lzchen lzchen commented Oct 12, 2020

Similar to #1116.

Adding the ability to collect duration metrics from Django instrumentation.

Semantic conventions for metrics can be found here

Currently django only supports SERVER type (since we don't have database tracking yet). The HTTPMetricRecorder is also being passed via settings from the DjangoInstrumentor to the middleware.

Also included in this PR:

  • a few changes to MetricMixin in the instrumentation package: Support both SERVER and CLIENT types, add a function to calculate duration without the use of context manager

@lzchen lzchen requested a review from a team October 12, 2020 19:40
Copy link
Contributor

@owais owais left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@ocelotl ocelotl left a comment

Choose a reason for hiding this comment

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

Please take a look at the comments, if you consider the current state of the code to be ok, let me know and I'll approve. 👍

def _get_metric_labels_from_attributes(attributes):
labels = {}
labels["http.method"] = attributes.get("http.method", "")
for attrs in _ATTRIBUTES_BY_PREFERENCE:
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe just declare the _ATTRIBUTES_BY_PREFERENCE here since it is only used once?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Defined once on module level so it doesn't have to be defined everytime a request is called.

if all(labels_from_attributes.values()):
labels.update(labels_from_attributes)
break
if attributes.get("http.flavor"):
Copy link
Contributor

Choose a reason for hiding this comment

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

This may have the same problem.

Suggested change
if attributes.get("http.flavor"):
if attributes.get("http.flavor") is not None:

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't believe we want to set the label if value is an empty string.

Copy link
Contributor

@ocelotl ocelotl Oct 15, 2020

Choose a reason for hiding this comment

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

Nevertheless, we may end up setting the label when the value is an empty string here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think http.method should always be populated. That was just for sanity.

@lzchen lzchen requested a review from ocelotl October 14, 2020 17:46
Copy link
Contributor

@ocelotl ocelotl left a comment

Choose a reason for hiding this comment

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

Approved since most of my comments have been marked as resolved, only leaving a question for @lzchen just in case.

if all(labels_from_attributes.values()):
labels.update(labels_from_attributes)
break
if attributes.get("http.flavor"):
Copy link
Contributor

@ocelotl ocelotl Oct 15, 2020

Choose a reason for hiding this comment

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

Nevertheless, we may end up setting the label when the value is an empty string here?

@lzchen lzchen merged commit beccc3b into open-telemetry:master Oct 16, 2020
@lzchen lzchen deleted the django branch October 16, 2020 00:24
srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
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