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: implement HostDetector #2921

Merged
merged 7 commits into from
Apr 30, 2022
Merged

Conversation

rauno56
Copy link
Member

@rauno56 rauno56 commented Apr 22, 2022

Which problem is this PR solving?

There's currently no detector for host.* resource attributes.

Short description of the changes

Added a new detector for detecting host attributes which are not cloud-based:

  • host.name and
  • host.arch.

Type of change

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

How Has This Been Tested?

  • Added unit tests

Checklist:

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

@rauno56 rauno56 requested a review from a team April 22, 2022 09:05
@blumamir
Copy link
Member

Thanks @rauno56 , The HostDetector.ts file is currently not committed in this PR.

Do you think it should be hosted in core repo or contrib detectors?

@rauno56
Copy link
Member Author

rauno56 commented Apr 22, 2022

Do you think it should be hosted in core repo or contrib detectors?

If it does, so do ProcessDetector imho. I see that the contrib detectors are vendor specific for now and a similar(ProcessDetector) one was here -> added this here as well.

@blumamir
Copy link
Member

Do you think it should be hosted in core repo or contrib detectors?

If it does, so do ProcessDetector imho. I see that the contrib detectors are vendor specific for now and a similar(ProcessDetector) one was here -> added this here as well.

Sounds reasonable 👍

@codecov
Copy link

codecov bot commented Apr 22, 2022

Codecov Report

Merging #2921 (981c0f1) into main (dc44b86) will decrease coverage by 0.03%.
The diff coverage is 31.57%.

❗ Current head 981c0f1 differs from pull request most recent head 91921be. Consider uploading reports for the commit 91921be to get more accurate results

@@            Coverage Diff             @@
##             main    #2921      +/-   ##
==========================================
- Coverage   91.85%   91.81%   -0.04%     
==========================================
  Files         176       70     -106     
  Lines        5573     2017    -3556     
  Branches     1209      441     -768     
==========================================
- Hits         5119     1852    -3267     
+ Misses        454      165     -289     
Impacted Files Coverage Δ
...ntelemetry-resources/src/detectors/HostDetector.ts 23.52% <23.52%> (ø)
...ges/opentelemetry-resources/src/detectors/index.ts 100.00% <100.00%> (ø)
...s/opentelemetry-core/src/platform/node/sdk-info.ts 0.00% <0.00%> (-100.00%) ⬇️
...opentelemetry-core/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...pentelemetry-core/src/platform/node/performance.ts 0.00% <0.00%> (-100.00%) ⬇️
...emetry-api-metrics/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...lemetry-resources/src/detectors/ProcessDetector.ts 31.81% <0.00%> (-63.64%) ⬇️
...ckages/opentelemetry-exporter-zipkin/src/zipkin.ts 84.48% <0.00%> (-15.52%) ⬇️
...strumentation/src/platform/node/instrumentation.ts
...telemetry-sdk-trace-node/src/NodeTracerProvider.ts
... and 121 more

@rauno56
Copy link
Member Author

rauno56 commented Apr 22, 2022

Another question is whether it needs to be a separate detector in the first place.
Sure, it does map to spec better this way, and as long it's included in a package with ProcessDetector there's no (significant) harm done, but as an user I wouldn't want to install 3 different detectors for process, os, and host attributes for no good reason.

@blumamir
Copy link
Member

Another question is whether it needs to be a separate detector in the first place. Sure, it does map to spec better this way, and as long it's included in a package with ProcessDetector there's no (significant) harm done, but as an user I wouldn't want to install 3 different detectors for process, os, and host attributes for no good reason.

I guess people might not always want all the attributes and separating them into different detectors can help use just the attributes needed.
But I can also see how those 3 detectors collect very similar data and might be more useful as one.
An alternative could be to define a composite detector that invokes those 3 detectors and merges the result into a single resource.

@rauno56
Copy link
Member Author

rauno56 commented Apr 22, 2022

An alternative could be to define a composite detector that invokes those 3 detectors and merges the result into a single resource.

Current SDK uses an utility for that.

I guess people might not always want all the attributes and separating them into different detectors can help use just the attributes needed.

I agree, but that might also happen among attributes detected from a single detector. One might only care about PID from the ProcessDetector but find process.command_line mostly dead weight, ergo we'd likely want to enable users to strip away attributes they don't need anyways. It's currently possible with wrapping the detectors with something like the utility mentioned ☝️

@blumamir
Copy link
Member

I agree, but that might also happen among attributes detected from a single detector. One might only care about PID from the ProcessDetector but find process.command_line mostly dead weight, ergo we'd likely want to enable users to strip away attributes they don't need anyways. It's currently possible with wrapping the detectors with something like the utility mentioned ☝️

Yeah, good points. Might be worth thinking about how to offer such capabilities in the future.
Anyhow, it's not relevant to this PR.
LGTM. Thanks for working on it 💯

@rauno56 rauno56 mentioned this pull request Apr 25, 2022
6 tasks
@rauno56
Copy link
Member Author

rauno56 commented Apr 27, 2022

Hmm... changing changelog manually creates a situation with a lot of conflict resolution.

I now finally understand the benefit of changefiles.

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.

4 participants