-
Notifications
You must be signed in to change notification settings - Fork 625
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
ext/system-metrics: adding instrumentation to collect system metrics #652
ext/system-metrics: adding instrumentation to collect system metrics #652
Conversation
Adding an extension to provide users an easy mechanism to collect metrics for their system. As part of this change, I also added an InMemoryMetricsExporter. I ended up adding meter_provider and memory_metrics_exporter to TestBase
f255ede
to
e99705e
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.
Looks pretty good. Minor comments. I didn't review the pieces ported to #653.
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Show resolved
Hide resolved
…tem_metrics/__init__.py Co-authored-by: Mauricio Vásquez <[email protected]>
I am hoping this becomes a general function of the SDK, through the Views API you should be able to disable or configure any instrument. Each plugin shouldn't expose a way to configure the instruments, ideally. |
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.
Looking good! Comments are non-blocking but worth taking a look 👍
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-system-metrics/tests/test_system_metrics.py
Outdated
Show resolved
Hide resolved
Co-authored-by: Diego Hurtado <[email protected]>
description="System memory", | ||
unit="bytes", | ||
value_type=int, | ||
label_keys=self._labels.keys(), |
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 don't think you need to supply label_keys
. Originally, these were served as "recommended keys", in which if the metric is recorded with labels that are not in label_keys
, they would be dropped. Since you are adding the "type" label in each of the observes, they would theoretically be dropped. However, this functionality is going to be done in views
(so label_keys
here doesn't actually do anything). As well, from the specs we are most likely going to be getting rid of this field anyways.
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.
Removed
observer: the observer to update | ||
""" | ||
system_memory = psutil.virtual_memory() | ||
_metrics = [ |
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 would define these outside of the callback. We don't want to keep instantiating these.
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 think we should add an API to modify the _metrics
for each system metric. This way, users that use this library will be able to customize the types of metrics for each system metric they export.
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 agree, I've updated the constructor to support a config
parameter to allow for other metrics to be configured. I think it can be improved, but maybe its enough to get started?
"used", | ||
"free", | ||
] | ||
for metric in _metrics: |
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 would use "type" instead of "metrics".
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.
updated
ext/opentelemetry-ext-system-metrics/src/opentelemetry/ext/system_metrics/__init__.py
Show resolved
Hide resolved
@lzchen addressed your comments if you get a chance to review |
self.controller = PushController( | ||
meter=self.meter, exporter=exporter, interval=interval | ||
) | ||
if config is None: |
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.
Is there somewhere that we can let the user know that passing in their own config is possible? Maybe an example file?
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. Just one comment about an example file.
…lemetry#652) * feat: port mongodb-core plugin to mongodb open-telemetry#622 * chore: address PR comments
Adding an extension to provide users an easy mechanism to collect metrics for their system. Some thoughts around this PR:
The PR includes changes which I pulled out into this separate PR #653. I'll resolve if that one gets merged first.