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

feat(opentelemetry-resources): add runtime version information #2727

Merged
merged 18 commits into from
Mar 4, 2022

Conversation

cuichenli
Copy link
Contributor

Signed-off-by: Cuichen Li [email protected]

Which problem is this PR solving?

Add runtime version information for node resources detector.

In the original issue, it was proposed to also add runtime.name and runtime.description. I feel it does not make much sense for node. But let me know if we want to add it. Following is one example versions output I retrieved:

> process.versions
{
  node: '14.17.0',
  v8: '8.4.371.23-node.63',
  uv: '1.41.0',
  zlib: '1.2.11',
  brotli: '1.0.9',
  ares: '1.17.1',
  modules: '83',
  nghttp2: '1.42.0',
  napi: '8',
  llhttp: '2.1.3',
  openssl: '1.1.1k',
  cldr: '38.1',
  icu: '68.2',
  tz: '2020d',
  unicode: '13.0'
}

Thinking maybe we can add the v8 info to runtime.description? Please kindly advice. Thanks

Fixes #2562

Short description of the changes

Retrieve version info from process

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Tested locally it can successfully retrieve the runtime version. Also updated the unit test.

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@cuichenli cuichenli requested a review from a team January 21, 2022 03:51
@codecov
Copy link

codecov bot commented Jan 21, 2022

Codecov Report

Merging #2727 (09236f6) into main (ef03d02) will increase coverage by 0.02%.
The diff coverage is 94.73%.

@@            Coverage Diff             @@
##             main    #2727      +/-   ##
==========================================
+ Coverage   93.39%   93.41%   +0.02%     
==========================================
  Files         159      160       +1     
  Lines        5450     5467      +17     
  Branches     1145     1149       +4     
==========================================
+ Hits         5090     5107      +17     
  Misses        360      360              
Impacted Files Coverage Δ
...ry-resources/src/platform/node/detect-resources.ts 21.73% <0.00%> (ø)
...lemetry-resources/src/detectors/BrowserDetector.ts 100.00% <100.00%> (ø)
...lemetry-resources/src/detectors/ProcessDetector.ts 100.00% <100.00%> (ø)
...ges/opentelemetry-resources/src/detectors/index.ts 100.00% <100.00%> (ø)

@dyladan
Copy link
Member

dyladan commented Jan 21, 2022

I believe we need the name in order for the version to be meaningful. The usecase would be many different languages/runtimes sending spans to the backend. How would you know which ones are node (node does not always even appear in the command line)?

I believe we should have:

{
  "process.runtime.name": "nodejs",
  "process.runtime.version": process.versions.node,
  "process.runtime.description": "NodeJS"
}

See also: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/process.md#javascript-runtimes

@vmarchaud vmarchaud added the enhancement New feature or request label Jan 23, 2022
@cuichenli
Copy link
Contributor Author

@dyladan thanks, i have hardcoded the runtime name and description.

cuichenli and others added 3 commits January 25, 2022 22:24
Signed-off-by: Cuichen Li <[email protected]>

Co-authored-by: legendecas <[email protected]>
Signed-off-by: Cuichen Li <[email protected]>

Co-authored-by: legendecas <[email protected]>
Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

LGTM % nits.


describe('browserDetector()', () => {
beforeEach(() => {
global.window = {
Copy link
Member

Choose a reason for hiding this comment

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

sinon.stub should be preferred to create mocks. Also global is not a standard global alias in browser environment, please use globalThis instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated.
tried to

sinon.stub(globalThis, 'window')
....

but got TypeError: Cannot stub non-existent property window

Copy link
Member

Choose a reason for hiding this comment

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

My guess is that these tests are run on the Node.js environment, which is not expected. I'm filed #2739 to fix this. I don't want to block this PR for #2739. So I'm ok with this as is.

@vmarchaud
Copy link
Member

@cuichenli After fixing the build & rebasing the PR should be good to merge !

@cuichenli
Copy link
Contributor Author

@vmarchaud I have fixed the issue, can you please re-trigger the build? thanks

@dyladan
Copy link
Member

dyladan commented Jan 26, 2022

@legendecas is this PR blocked on your spec PR or no?

@legendecas
Copy link
Member

@dyladan yeah, it will be great to see how open-telemetry/opentelemetry-specification#2290 goes after the review. Most likely there aren't many things to change since the spec PR just writes down what we are doing in this PR, except that the spec PR removed process.runtime.description since it adds no additional information.

@legendecas
Copy link
Member

@cuichenli I'm so sorry for this to wait such a long time. I think open-telemetry/opentelemetry-specification#2290 is going to be merged unchanged. But it took a long time already and I'd believe we should get things rolling and this PR should not be blocked. Would you mind resolving the conflicts so that we can get this PR merged? Thank you very much.

@cuichenli
Copy link
Contributor Author

@legendecas thanks! i have updated the branch.

Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

Thank you for your work! I think the PR is almost complete once we resolve these two issues.

@@ -0,0 +1,61 @@
/*
Copy link
Member

Choose a reason for hiding this comment

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

The detectors were moved to the src/detectors folder so that we can have a consistent export on both Node.js and Web environments. And detector.detect will do nothing if the environment is not the expected one, like https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-resources/src/detectors/ProcessDetector.ts#L30.

Could you move the BrowserDetector to src/detectors too so that it can be exported unconditionally?

resources.forEach(resource => {
// Print only populated resources
if (Object.keys(resource.attributes).length > 0) {
const resourceDebugString = util.inspect(resource.attributes, {
Copy link
Member

Choose a reason for hiding this comment

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

util.inspect is not available on the Web, that's why it is located in the src/platform/node so that it won't be bundled in the web applications. Moving this API out of src/platform/node makes it unusable on Web environments. I think this change could be separated into another PR to make detectResource Web compatible.

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 will file an issue for this and work on it in another pr. thanks!

@dyladan
Copy link
Member

dyladan commented Mar 2, 2022

Spec PR merged which means when this is ready it can be merged

@cuichenli
Copy link
Contributor Author

@legendecas have updated based on the comments. please take another look. thanks

describe('browserDetector()', () => {
beforeEach(() => {
(globalThis.window as {}) = {};
sinon.stub(globalThis, 'window').value({
Copy link
Member

@legendecas legendecas Mar 3, 2022

Choose a reason for hiding this comment

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

The test is failing because globalThis.window in the browser environment is not configurable or writable. You may need to stub the property you need instead of stub the whole "window" object.

Copy link
Member

Choose a reason for hiding this comment

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

Test isn't failing...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed. but it took me a while to realize we now have describeNode and describeBrowser 🤦


describe('browserDetector()', () => {
beforeEach(() => {
(globalThis.window as {}) = {};
Copy link
Member

Choose a reason for hiding this comment

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

Since this file will be tested in the Node.js environment only, we don't need to mock the globalThis.window anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

@legendecas legendecas merged commit a901732 into open-telemetry:main Mar 4, 2022
@legendecas
Copy link
Member

Thank you for your work!

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

Successfully merging this pull request may close these issues.

Add support for process.runtime.* attributes for Node resource detector
5 participants