Support OTEL metrics by switching to Aspire OTEL collector and UI

open_telemetry/README.md

@@ -6,33 +6,32 @@ For this sample, the optional `open_telemetry` dependency group must be included
 
     poetry install --with open_telemetry
 
-To run, first see [README.md](../README.md) for prerequisites. Then run the following to start a Jaeger container
-with OTLP collector enabled to collect and view the trace results:
+To run, first see [README.md](../README.md) for prerequisites. Then run the following to start an [Aspire](https://hub.docker.com/r/microsoft/dotnet-aspire-dashboard/) OTEL collector
 
-    docker run -d --name jaeger \
-      -e COLLECTOR_OTLP_ENABLED=true \
-      -p 16686:16686 \
-      -p 4317:4317 \
-      -p 4318:4318 \
-      jaegertracing/all-in-one:latest
+    docker compose up
 
 Now, from this directory, start the worker in its own terminal:
 
     poetry run python worker.py
 
-This will start the worker. Then, in another terminal, run the following to execute the workflow:
+Then, in another terminal, run the following to execute the workflow:
 
     poetry run python starter.py
 
-The workflow should complete with the hello result. The workflow trace can now be viewed in Jaeger at
-http://localhost:16686/. Under service, select `my-service` and "Find Traces". The workflow should appear and when
-clicked, may look something like:
+The workflow should complete with the hello result.
 
-![Jaeger Screenshot](jaeger-screenshot.png)
+Now view the Aspire UI at http://localhost:18888/.
+
+To view metrics sent describing the worker and the workflow that was executed, select `Metrics` on the left and under "Select a resource" select "temporal-core-sdk". It may look like this:
+
+![Aspire metrics screenshot](aspire-metrics-screenshot.png)
+
+
+To view workflow spans, select `Traces` on the left and under "Select a resource" select "temporal-core-sdk". It may look like this:
+
+![Aspire traces screenshot](aspire-traces-screenshot.png)
 
 Note, in-workflow spans do not have a time associated with them. This is by intention since due to replay. In
 OpenTelemetry, only the process that started the span may end it. But in Temporal a span may cross workers/processes.
 Therefore we intentionally start-then-end in-workflow spans immediately. So while the start time and hierarchy is
-accurate, the duration is not.
-
-The metrics should have been dumped out in the terminal where the OpenTelemetry collector container is running.
+accurate, the duration is not.

open_telemetry/docker-compose.yaml

@@ -0,0 +1,8 @@
+services:
+  aspire-dashboard:
+    environment:
+      Dashboard__Frontend__AuthMode: Unsecured
+    image: mcr.microsoft.com/dotnet/aspire-dashboard:8.0
+    ports:
+      - 4317:18889
+      - 18888:18888

open_telemetry/worker.py

@@ -1,7 +1,6 @@
 import asyncio
 from datetime import timedelta
 
-import opentelemetry.context
 from opentelemetry import trace
 from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
 from opentelemetry.sdk.resources import SERVICE_NAME, Resource