Integrate with existing metrics code

[avillela]

Fixes #72

Changes

• Clean up requirements.txt
  • Use opentelemetry-distro to install relevant OpenTelemetry packages
  • Since we are installing psutil, opentelemetry-bootstrap will also install opentelemetry-instrumentation-system-metrics
• Update recommendationservice's Dockerfile to:
  • Install specific version of grpcio-tools to avoid compatibility issues with protobuf library versions.
  • Install opentelemetry-bootstrap to install auto-instrumentation libraries
• Clean up metrics and tracing init
• Move metrics definitions to metrics.py

The following metrics are available through auto-instrumentation, courtesy of the opentelemetry-instrumentation-system-metrics, which is installed as part of opentelemetry-bootstrap on building the recommendationservice Docker image:

• runtime.cpython.cpu_time

• runtime.cpython.memory

• runtime.cpython.gc_count

• Appropriate CHANGELOG.md updated for non-trivial changes

[cartersocha]

Please update the metric features doc under the docs folder to reflect the added feature too 😃

[cartersocha]

I'm getting an odd error. Cursory google searching doesn't show a clear answer.

#0 13.82 × Encountered error while trying to install package.
#0 13.82 ╰─> psutil

I installed the package but still getting an error. Any special dependency requirements?

[julianocosta89]

I'm still not a heavy user of metrics so I'm not sure how it would be better to handle the naming.
I see here that we have cpu_usage, ram_usage.
Should we add an identifier to those metrics?

Just wondering how that will grow whenever we have 10 services with the same metric name.

[mviitane]

I think traces are not working with this PR without adding:
OTEL_TRACES_EXPORTER to docker-compose.yml

[fatsheep9146]

I'm a little confused that why not using python instrumentation library to get the system metric such as cpu usage.

I'm not quite familiar about python, maybe my confusion is wrong, you can correct me. But what I really want to say is, when it come's to add new metrics or traces, we should first consider using the instrumentation library instead of manually creating one.

[reyang]

But what I really want to say is, when it come's to add new metrics or traces, we should first consider using the instrumentation library instead of manually creating one.

💯

[avillela]

I'm a little confused that why not using python instrumentation library to get the system metric such as cpu usage.

I'm not quite familiar about python, maybe my confusion is wrong, you can correct me. But what I really want to say is, when it come's to add new metrics or traces, we should first consider using the instrumentation library instead of manually creating one.

That was me just messing around with metrics and trying to understand them, and I forgot to remove the unnecessary stuff.

[avillela]

I think traces are not working with this PR without adding:
OTEL_TRACES_EXPORTER to docker-compose.yml

I was able to send traces without issue...

[avillela]

I'm still not a heavy user of metrics so I'm not sure how it would be better to handle the naming. I see here that we have cpu_usage, ram_usage. Should we add an identifier to those metrics?

Just wondering how that will grow whenever we have 10 services with the same metric name.

That waste messing around with learning metrics. I'd forgotten to remove these.

[julianocosta89]

Great one!

[mviitane]

I think traces are not working with this PR without adding:
OTEL_TRACES_EXPORTER to docker-compose.yml

I was able to send traces without issue...

OK, then it was something in my environment. It seems otlp is the default.

I actually think it makes sense to set both of these env variables or then none of them (just for consistency, I believe the end result will be the same):

OTEL_TRACES_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp

[avillela]

I think traces are not working with this PR without adding:
OTEL_TRACES_EXPORTER to docker-compose.yml

I was able to send traces without issue...

OK, then it was something in my environment. It seems otlp is the default.

I actually think it makes sense to set both of these env variables or then none of them (just for consistency, I believe the end result will be the same):

OTEL_TRACES_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp

Yes, good point. That was kinda bugging me too. :) Updated.

[mviitane]

LGTM

[fatsheep9146]

https://github.com/open-telemetry/opentelemetry-demo/blob/main/docs/metric_service_features.md

I think this file can also be updated, since Recommendation service auto instrumentation is done.

[avillela]

https://github.com/open-telemetry/opentelemetry-demo/blob/main/docs/metric_service_features.md

I think this file can also be updated, since Recommendation service auto instrumentation is done.

Added @fatsheep9146

[austinlparker]

is the requested change actually blocking anything? this needs to merge today to get into 0.6