-
Notifications
You must be signed in to change notification settings - Fork 26
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
[Feat][DEVX-364] Record Custom Metric (Response Time) #861
[Feat][DEVX-364] Record Custom Metric (Response Time) #861
Conversation
🦋 Changeset detectedLatest commit: 9d1df0b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
e834325
to
5f7d9bb
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #861 +/- ##
=======================================
Coverage 93.05% 93.05%
=======================================
Files 25 25
Lines 288 288
Branches 14 14
=======================================
Hits 268 268
Misses 20 20
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
b63f0b8
to
8fb70b5
Compare
- record and send custom metrics to respective APMs
- fix tests for old (legacy) apm middleware
- improve typescript types for ts-sdk-apm package - add more custom metric example snippets to example directory - add tests to validate functionality
- add release changeset
- add node-fetch dependency to apm package
6e60c49
to
bcbbc6a
Compare
- rebase and update branch - move test to integration tests directory - update dependencies
bcbbc6a
to
609a0c9
Compare
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.
Good job 👍
return ResponseHandler.successResponse( | ||
res, | ||
data.statusCode || data.body.statusCode, | ||
data.message || data.body.message, | ||
data.body | ||
) | ||
} | ||
|
||
const end = performance.now() | ||
newrelic.recordMetric('Commercetools/Test/Response/Time/Total', end - start) |
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.
You have duplicated code.
btw. should this be recorded inside the ts-apm-sdk? There is a metric Commercetools/Client/Response/Total
already. Why would the user need the second metric here?
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.
Uhmmm not necessarily a duplicate. What I was looking at is how the custom can instrument an individual function in their codebase. As you may have seen, the only thing we recorded in the telemetryMiddleware
was the response time. However with this, they can record any other metric include a status code, execution time of a function etc.
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.
Sorry, I was not clear. By duplicated I mean this part is twice. It could be done before if
once:
const end = performance.now()
newrelic.recordMetric(
'Commercetools/Test/Response/Time/Total',
end - start
)
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.
If you want to show a custom metric created by user, then try to use a different name and don't start with Commercetools
. I'm also not sure if we should provide newrelic in our package. This should be the responsibility of the user's app to use newrelic dependency directly. Instead we could add some more metrics to the telemetryMiddleware
, like count of errors and success requests. WDYT?
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.
That is why we have a separate package for telemetry. I think the newrelic
and dd-trace
dependencies are both absolutely necessary here and should be part of the offering. These dependencies shouldn't be coming from the customer's application.
Also, you cannot totally account for all the possible scenario where or what the customer would want to instrument. I would suggest giving them the freedom to record any metric of their choice, except you want us to limit what they can monitor?
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.
OK, I see your point. I find it a bit weird that we offer also newrelic, datadog etc. when the customer could actually use the original newrelic or datadog packages by themselves.
We do not add anything extra to it, so I'm wondering why would the customer wants to use newrelic from ts-sdk-apm
package if they just want to use newrelic for their custom metrics? Would it be better for them to use directly the package from newrelic directly?
packages/platform-sdk/test/integration-tests/sdk-v3/telemetry.test.ts
Outdated
Show resolved
Hide resolved
- implement PR review feedback
- implement PR review feedback
- implement feedback
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 👍
Summary
Record custom metrics (request-response time)
Completed Tasks
Depends On
#877