NR-355081 Sample app for OTEL entity relationship Docker instrumented with NR infra agent #710
Conversation
| @@ -0,0 +1,2 @@ | |||
| FROM newrelic/infrastructure:latest | |||
| ADD newrelic-infra.yml /etc/newrelic-infra.yml | |||
There was a problem hiding this comment.
No need to define a new docker image just for this. Just mount newrleic-infra.yml using a volume mount.
There was a problem hiding this comment.
Following the below docs for Infra agent installation
https://docs.newrelic.com/docs/infrastructure/infrastructure-agent/linux-installation/infra-agent-as-container/
There was a problem hiding this comment.
Ooof that's bad advice we're giving our customers.
Now we're stuck answering the question of whether to prioritize consistency with the nr infra agent docs, or the simpler / idiomatic approach for docker. 😅
Can stick with consistency with the nr infra agent docs for the purpose of this PR.
| # ...omitted for brevity | ||
| # New Relic API key to authenticate the export requests. | ||
| # docs: https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#license-key | ||
| otlp: |
There was a problem hiding this comment.
New Relic recommends the http/protobuf version of OTLP.
| otlp: | |
| otlphttp: |
| # New Relic API key to authenticate the export requests. | ||
| # docs: https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#license-key | ||
| otlp: | ||
| endpoint: otlp.nr-data.net:4318 |
There was a problem hiding this comment.
Other examples configure the OTLP endpoint and API key with env vars to make it easier for NR employees to change which environment they are running the example against. They also defined default values for these env variables in a .env file.
| endpoint: otlp.nr-data.net:4318 | |
| endpoint: ${NEW_RELIC_OTLP_ENDPOINT} |
| ``` | ||
|
|
||
| ```shell | ||
| docker run \ |
There was a problem hiding this comment.
Is this the canonical / recommended way to to run the infra agent? If no, let's make sure we align with it.
Also, let's translate this to an entry in the docker-compose.yml file. No reason to have the user running containers with and without docker compose.
There was a problem hiding this comment.
Yes, I am following the below docs for Infra agent installation
https://docs.newrelic.com/docs/infrastructure/infrastructure-agent/linux-installation/infra-agent-as-container/
There was a problem hiding this comment.
Can you translate all this to a service entry in ./docker-compose.yaml?
There was a problem hiding this comment.
I have already tried it, but below command doesn't support in docker-compose.yaml
--cgroupns=host
so that is the reason I have left it as NR docs recommendation
docker run
-d
--name newrelic-infra
--network=host
--cap-add=SYS_PTRACE
--privileged
--pid=host
--cgroupns=host \ # required on cgroup v2
-v "/:/host:ro"
-v "/var/run/docker.sock:/var/run/docker.sock"
YOUR_IMAGE_NAME
| otlp: | ||
| protocols: | ||
| grpc: | ||
| zipkin: |
There was a problem hiding this comment.
Remove. Apps should send data via OTLP.
| processors: | ||
| [ | ||
| resourcedetection, | ||
| resourcedetection/cloud, | ||
| resourcedetection/system, | ||
| resource, | ||
| batch, | ||
| ] |
There was a problem hiding this comment.
If we're going to use the bracket syntax, let's keep all the entries on one line for readibility. Can also use the array syntax instead:
| processors: | |
| [ | |
| resourcedetection, | |
| resourcedetection/cloud, | |
| resourcedetection/system, | |
| resource, | |
| batch, | |
| ] | |
| processors: | |
| - resourcedetection | |
| - resourcedetection/cloud | |
| - resourcedetection/system | |
| - resource | |
| - batch |
This advice applies to other pipelines as well.
| depends_on: | ||
| - collector | ||
|
|
||
| collector: |
There was a problem hiding this comment.
Why are you running the collector and the infra agent? Is it because you're relying on the collector setting host.id for the entity relationship? If yes, can you configure the APM app to include that attribute directly?
As a principle, we want these examples to be minimalist, with everything removed that isn't critical to the functionality being demonstrated.
| endpoint: 0.0.0.0:9411 | ||
| exporters: | ||
| debug: | ||
| verbosity: detailed |
| @@ -26,7 +26,7 @@ exporters: | |||
| debug: | |||
| verbosity: $LOG_EXPORTER_LOG_VERBOSITY | |||
| otlphttp: | |||
| endpoint: https://otlp.nr-data.net | |||
| endpoint: https://otlp.nr-data.net:4317 | |||
There was a problem hiding this comment.
This is not necessary. Our OTLP endpoint listens on port 443, which is the default when the protocol is https. If port was required, we'd want it to be 4318 instead of 4317.
There was a problem hiding this comment.
Mistakenly updated, reverted the change
| - "4317" | ||
| environment: | ||
| - AD_SERVICE_PORT=8080 | ||
| - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector-container-nr-agent:4318 |
There was a problem hiding this comment.
Is the collector actually required for this example? Looking at otel-config.yaml, I see content which looks like a copy of the collector configuration from the host-monitoring example. But here we're trying to demonstrate monitoring with NR infra agent, so that configuration duplicates data and is a distraction.
If we don't need the collector to do data enrichment to make this relationship work, let's delete it and export directly to New Relic:
- OTEL_EXPORTER_OTLP_ENDPOINT=${NEW_RELIC_OTLP_ENDPOINT}
- OTEL_EXPORTER_OTLP_HEADERS=${NEW_RELIC_API_KEY}
If the collector is in fact needed (I can't tell at a glance), let's get rid of all the configuration which is unrelated.
There was a problem hiding this comment.
The below one worked so I have removed the collector example
- OTEL_EXPORTER_OTLP_ENDPOINT=${NEW_RELIC_OTLP_ENDPOINT}
- OTEL_EXPORTER_OTLP_HEADERS=api-key=${NEW_RELIC_API_KEY}
| - NEW_RELIC_OTLP_ENDPOINT | ||
| container_name: otel-collector-container-nr-agent | ||
|
|
||
| # Optionally, add Jaeger or another service here |
There was a problem hiding this comment.
| # Optionally, add Jaeger or another service here |
This example code created for APM OTEL UI convergence Infra relationships particularly for OTEL entity relationship with docker which is instrumented with NR infra agent.