-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
otel: simple OTEL collector/Jaeger/Aspire stack for testing purposes #47733
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
name: moby-otel | ||
|
||
services: | ||
|
||
jaeger: | ||
image: jaegertracing/all-in-one:latest | ||
ports: | ||
- 16686:16686 | ||
|
||
aspire-dashboard: | ||
image: mcr.microsoft.com/dotnet/nightly/aspire-dashboard | ||
ports: | ||
- 18888:18888 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wondering if we should use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, it's generally better to bind |
||
environment: | ||
DOTNET_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS: 'true' | ||
|
||
otelcol: | ||
image: otel/opentelemetry-collector:latest | ||
restart: always | ||
depends_on: | ||
- jaeger | ||
- aspire-dashboard | ||
ports: | ||
- 4318:4318 # default otlp http port | ||
volumes: | ||
# Mount the otelcol.yml config file | ||
- ./otelcol.yaml:/etc/otelcol/config.yaml |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
# Receive signals over gRPC and HTTP | ||
# moby currently uses http | ||
receivers: | ||
otlp: | ||
protocols: | ||
grpc: | ||
http: | ||
|
||
exporters: | ||
otlp/jaeger: | ||
endpoint: jaeger:4317 | ||
tls::insecure: true | ||
otlp/aspire: | ||
endpoint: aspire-dashboard:18889 | ||
tls::insecure: true | ||
|
||
service: | ||
pipelines: | ||
traces: | ||
receivers: [otlp] | ||
exporters: [otlp/jaeger, otlp/aspire] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,28 @@ | ||
# Sample stack for testing OTEL functionality with moby | ||
|
||
To easily test the OTEL functionality present in moby, you can spin up a small demo compose stack that includes: | ||
- an OTEL collector container; | ||
- a Jaeger container to visualize traces; | ||
- an alternative Aspire Dashboard container to visualize traces; | ||
|
||
The OTEL collector is configured to export Traces to both the Jaeger and Aspire containers. | ||
|
||
The `hack/otel` directory contains the compose file with the services configured, along with a basic configuration file for the OTEL collector. | ||
|
||
## How can I use it? | ||
|
||
1) Export the env var used to override the OTLP endpoint: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit; should this be a actual markdown numbered list? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mmh good question, I thought it looked a bit better but I guess it depends on the markdown renderer used. No hard feelings here, if it's "more correct" to do otherwise i'll change this |
||
`export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318` (if running in a devcontainer or in other ways, you might have to change how you pass this env var to the daemon); | ||
2) Start the moby engine you want to get traces from (make sure it gets the env var declared above); | ||
3) Start the otel compose stack by running `docker compose up -d` in the `hack/otel/` directory; | ||
4) Make some calls to the engine using the Docker CLI to send some traces to the endpoint; | ||
5) Browse Jaeger at `http://localhost:16686` or the Aspire Dashboard at `http://localhost:18888/traces`; | ||
6) To see some traces from the engine, select `dockerd` in the top left dropdown | ||
|
||
> **Note**: The precise steps may vary based on how you're working on the codebase (buiding a binary and executing natively, running/debugging in a devcontainer, etc... ) | ||
|
||
## Cleanup? | ||
|
||
Simply run `docker compose down` in the `hack/otel/` directory. | ||
|
||
You can also run `unset OTEL_EXPORTER_OTLP_ENDPOINT` to get rid of the OTLP env var from your environment |
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 it's worth adding
restart: always
to every service.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.
Good idea. Reading the compose spec i see
always: The policy always restarts the container until its removal.
.Maybe using
unless-stopped
might be better in this case? I wouldn't want potential users (even if we kinda only expect devs and power-users to use this) to accidentally have these services running foreverThere 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 thought
unless-stopped
wouldn't be right here because AFAIK if the container is stopped during dockerd shutdown, it won't automatically restart (eg. on a reboot). But I tried it and it seems to work properly, so we can also consider using that restart policy.