-
Notifications
You must be signed in to change notification settings - Fork 534
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
fix(host-metrics): macOS bundling fix #2071
fix(host-metrics): macOS bundling fix #2071
Conversation
|
CI/CD should be fixed now :) (btw; npm install fails with Node 20 due to grpc) |
Hi @Netail Thank you for contributing to OTEL :) We can leverage this PR to help effort the group is doing to update the semantic conventions. Currently we're in a step we need to use the exported strings as you did in this PR and also document which version of the semantic conventions is using. Would you please add a section in the README file with this info. Here is an example of what I'm referring to. |
Hi @david-luna |
Just checked regarding opentelemetry-semantic-conventions package; it fetches the specifications from opentelemetry-specification, but the specifications folder got removed in v1.21.0, so the generator is broken... :( |
Semantic conventions already has these enums but the package is not updated yet so no need to contribute to https://github.com/open-telemetry/opentelemetry-js/tree/main/packages/opentelemetry-semantic-conventions. Actually this package is generated from the models in https://github.com/open-telemetry/semantic-conventions We need to inform which version of semantic conventions model (not package) host metrics is using and list them. In this case the package uses v1.24.0 of the model
You could add a section with this message
|
Shall I pull up a PR which generates the semantic concentions from the new repo? |
Updated the generator here: open-telemetry/opentelemetry-js#4606 |
this is indeed one of the tasks to be done for updating semantic conventions but since it a big leap in versions we expect breaking changes. This was discussed in the JavaScript SIG and planned. The plan is summarised and tracked in open-telemetry/opentelemetry-js#4572 the PR looks good but 1st we need to prepare the packages in contrib to be ready for the change. You can help us with these preparation tasks :) Also you can join the SIG to discuss this topic and others. Here is the doc with the MoMs and also with the info to join https://docs.google.com/document/d/1tCyoQK49WVcE-x8oryZOTTToFm7sIeUhxFPm9g-qL1k/edit |
What kind of preparation do all the packages need? Updated open-telemetry/opentelemetry-js#4606 to include v1.25.0 Semantic Conventions. As all packages within the same repo have a different version specified, we can merge that PR, and create different PRs for the packages who use the semantic-conventions package Added the semantic conventions table to the README |
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.
I guess with the change suggested by @pichlermarc in ./src/stats/si.ts
- import { networkStats } from 'systeminformation/lib/network';
+ import { networkStats } from 'systeminformation';
this file is no needed. I see the .d.ts
file from systeminformation
exporting networkStats
function already
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.
When I use import { networkStats } from 'systeminformation';
, it still tries to import the underlying cpu.js file, thus throwing an error on macOS. :( By targeting the file directly it won't.
The systeminformation/lib/cpu.js file tries to import osx-temperature-sensor
for macOS, which you additionally have to install for macOS temperatures as it's not included in the dependencies, however osx-temp-sensor package breaks something else. But the cpu.js file isn't even used for host-metrics, so installing this package besides systeminformation is unecessary
@Netail please check open-telemetry/opentelemetry-js#4572 for more info on the update plan, thanks :) |
Not completely sure, I believe it runs the instrumentation.ts on every initial page render in development (local) mode. |
systeminformation doesn't want to solve this issue at their side: sebhildebrandt/systeminformation#230, and the module // webpack.config.js
module.exports = {
externals: ['osx-temperature-sensor'],
}; I'd avoid using subpath imports which are not considered as public interface. Additionally, I would suggest splitting the PR for distinct purposes. |
We discussed in the SIG a couple days ago (https://docs.google.com/document/d/1tCyoQK49WVcE-x8oryZOTTToFm7sIeUhxFPm9g-qL1k/edit#heading=h.bxgyx12a4wsc) and decided that if we pinned the systeminformation dep, we'd be okay using the deep import. From memory, my summary of the justification is:
Aside: I'm not sure if bundlers other than Webpack result in a similar error/warning. TODO:
(@Netail I see you recently commited removing the deep import. Sorry for back and forth on this. I should have posted notes from the SIG a couple days ago.) |
Alright! Thanks, sounds good, will pick it up :) I've created a seperate PR for the semconv alignment & documentation; #2240 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2071 +/- ##
==========================================
- Coverage 90.97% 90.40% -0.58%
==========================================
Files 146 149 +3
Lines 7492 7514 +22
Branches 1502 1573 +71
==========================================
- Hits 6816 6793 -23
- Misses 676 721 +45
|
Alright, I've put the deep import back & the semconv alignment PR has been merged in a seperate PR. :) |
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 % nits.
@@ -25,7 +26,7 @@ import { | |||
MetricReader, | |||
} from '@opentelemetry/sdk-metrics'; | |||
import * as assert from 'assert'; | |||
import * as os from 'os'; | |||
import * as os from 'node:os'; |
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.
I'd avoid mixing the style of with and without the prefix node:
. Could you remove unrelated changes?
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.
I will remove them (noticed I forgot to prefix assert), but we do need to add them for the future though incase people use different js runtimes e.g. bun or deno.
And to bypass require cache.
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, for example, we needed to use node:test
-- which is only available with the node:
-prefix -- then yes we'd need to use the prefix.
However, currently we support "engines": { "node": ">=14" }
in most package.json files. That is relatively loose on defining which Node.js v14 versions we support, but at least v14.0.0 didn't support node:
prefixes:
Welcome to Node.js v14.0.0.
Type ".help" for more information.
> require('node:os')
Uncaught Error: Cannot find module 'node:os'
Require stack:
- <repl>
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:1014:15)
at Function.Module._load (internal/modules/cjs/loader.js:884:27)
at Module.require (internal/modules/cjs/loader.js:1074:19)
at require (internal/modules/cjs/helpers.js:72:18) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '<repl>' ]
}
>
Also, there is no rush on the usage with different runtimes. My guess (granted a guess), is that there is a ton of other work that would be required to get many of the OTel packages working reasonably with bun, deno, etc. We'd want to coordinate that in separate PRs.
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.
Oh that's true, do note that 14 and 16 hit their eol. So should we still support it tho?
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.
Thanks for persisting.
fyi; I am not allowed to merge, so when you guys are ready. feel free to merge :) |
Thank you for working on this! |
Which problem is this PR solving?
Short description of the changes