[✨ Triage] dotnet/aspire#12400 by tjwald - Api Endpoint for consuming Otel data

[MihuBot]

Triage for microsoft/aspire#12400.
Repo filter: area-dashboard issues.
MihuBot version: 87d9df.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/aspire#12400: Api Endpoint for consuming Otel  data by tjwald
[Tool] Searching for OTEL endpoint, OpenTelemetry REST API, consume OpenTelemetry data, MCP telemetry endpoint, custom telemetry ingestion, OpenTelemetry local development, REST endpoint for telemetry, dashboard OpenTelemetry source (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Found 78 issues, 352 comments, 40 returned results (112762 ms)

Here are the most relevant related issues and discussions for issue #12400 "Api Endpoint for consuming Otel data":

---

1. PR #4197 (May 2024) - Add support for HTTP(S) OTLP endpoint

• Summary: This PR added support for HTTP OTLP endpoints to the Aspire Dashboard, allowing it to consume OTLP data over both gRPC and HTTP(S). The implementation reused existing gRPC OTLP models and services, and included integration tests for all endpoints. The endpoints /v1/logs, /v1/traces, and /v1/metrics are now available for POST requests, making it possible to send OpenTelemetry data via REST.
• Discussion: The PR was reviewed for auth policy, memory usage, and naming consistency. There was discussion about protocol-independent service design and configuration. The PR was merged on June 21, 2024.
• Relevance: Directly addresses the request to expose REST endpoints for OpenTelemetry data, as these endpoints are now available in Aspire.

---

2. Issue #3688 (April 2024) - Add support for http OTLP endpoint in the dashboard

• Summary: This issue requested support for HTTP OTLP endpoints in the dashboard, noting that only gRPC was supported previously. The discussion highlighted the need for browser-based telemetry and mentioned that HTTP support would enable scenarios not possible with gRPC (e.g., browser apps).
• Resolution: The issue was closed as completed after PR #4197 was merged. The dashboard now supports OTLP/HTTP with Protobuf payloads, but not JSON payloads (which may be revisited if needed).
• Relevance: Confirms that REST/HTTP endpoints for OTLP are now supported, fulfilling the feature request in #12400.

---

3. Issue #857 (Nov 2023) - Calling the Telemetry collector from a SPA

• Summary: A user tried to send telemetry from a React SPA to the Aspire dashboard but ran into CORS issues and gRPC limitations. The discussion suggested that HTTP OTLP endpoints would solve this problem and considered proxying or adding HTTP support.
• Resolution: At the time, only gRPC was supported, but the discussion anticipated HTTP endpoint support. The issue is now resolved by the changes in PR #4197.
• Relevance: Shows community demand for HTTP endpoints and browser telemetry, which are now supported.

---

4. PR #5177 (Aug 2024) - Add CORS to OTLP HTTP endpoint

• Summary: This PR added CORS support to the OTLP HTTP endpoint, enabling browser-based telemetry ingestion. Configuration was improved to allow comma-separated origins, making it easier to use in local development and browser scenarios.
• Relevance: Ensures that REST/HTTP endpoints for OTLP data are usable from browser and local development environments, addressing part of the workflow described in #12400.

---

5. PR #5212 (Aug 2024) - Enable CORS for OTLP HTTP endpoint and add playground app

• Summary: Built on top of #5177, this PR automatically configures allowed origins for all HTTP endpoints in the Aspire app and added a playground app using opentelemetry-js to send OTLP data to the dashboard.
• Relevance: Demonstrates practical use of the new HTTP endpoints for local development and browser telemetry, as requested in #12400.

---

6. Issue #6329 (Oct 2024) - Feature Request: .WithOtlpExporter() can pass in otel http endpoint for client-side browser apps

• Summary: Requested the ability to inject the OTLP HTTP endpoint into browser apps, as .WithReference() defaulted to gRPC. The discussion suggested overloading .WithOtlpExporter() to support HTTP endpoints.
• Relevance: Addresses configuration flexibility for local development and browser scenarios, which is part of the workflow described in #12400.

---

7. Issue #2897 (Mar 2024) - Asserting OpenTelemetry data when using DistributedApplicationTestingBuilder

• Summary: Requested the ability to host an OTLP endpoint during integration tests to assert against OpenTelemetry data. The discussion included workarounds and ongoing efforts to make telemetry testing easier.
• Relevance: Shows ongoing work to make OTLP endpoints more flexible for local development and testing, which aligns with the goals of #12400.

---

8. Issue #11716 (Sep 2025) - Support exposing dashboard OTLP endpoint via a dev tunnel

• Summary: Requested support for exposing the dashboard OTLP endpoint via a dev tunnel for scenarios like mobile emulators. This is related to making telemetry ingestion more flexible for local development.
• Relevance: Indicates ongoing work to make OTLP endpoints accessible in more local development scenarios.

---

9. Issue #4131 (May 2024) - Container telemetry not shown in AppHost dashboard

• Summary: Discussed issues with containerized services sending telemetry to the dashboard, especially around HTTPS and certificate trust. Workarounds included using HTTP endpoints and disabling security features for local development.
• Relevance: Provides context on configuration challenges and solutions for local development with OTLP endpoints.

---

10. Issue #4393 (June 2024) - Aspire Dashboard (standalone) - adds servicename to the list of replicas, and produces an error when that replica is selected in the UI

• Summary: Discussed issues with resource naming and instance selection in the dashboard, which can affect how telemetry is displayed and filtered.
• Relevance: May be relevant for users building custom dashboards or jobs that process OTEL data.

---

Conclusion

• REST endpoints for OTLP data are now supported in Aspire Dashboard via /v1/logs, /v1/traces, and /v1/metrics (see PR #4197 and related issues).
• CORS support and browser telemetry ingestion are enabled (see PRs #5177 and #5212).
• Configuration for local development and browser apps is being improved, with ongoing work for dev tunnels and flexible endpoint selection.
• Documentation and community feedback indicate these features are actively used and requested.

If you are trying to consume OTEL data via REST endpoints for local development, this is now supported and documented in recent Aspire releases. If you need more advanced configuration (e.g., switching data sources, dev tunnels), there are ongoing improvements and related feature requests.

---

If you need further details on any specific implementation or usage scenario, let me know!