[DOCS-14870] Add managed platforms and serverless OTLP ingest docs#37395
[DOCS-14870] Add managed platforms and serverless OTLP ingest docs#37395brett0000FF wants to merge 23 commits into
Conversation
Add two new pages under Direct OTLP Ingest: - Managed Platforms: dedicated OTLP endpoints for 27 platforms - Serverless: traces from AWS, Azure, and GCP environments Update the landing page with a routing table and add cross-reference notes to the logs and metrics pages.
Mark open items inline: Preview framing, GCP endpoint ambiguity, Azure semconv verification, AWS attributes, span-mapping decision, GKE scope, and signal scope. Add GKE to routing table.
Lambda: cloud.provider + faas.id (ARN) required, cloud.platform conditional. ECS Fargate: aws.ecs.task.arn + aws.ecs.launchtype required, cloud.provider/cloud.platform optional.
…Traces Settled decisions from review: - Remove span mapping sections from both pages (eng prefers undocumented) - Remove GKE from serverless page (not serverless, not on Serverless product page) - Retitle serverless page to "Serverless Traces" (traces-only scope) - Add Preview callout to serverless page - Fix Azure resource detection claims (Collector vs SDK distinction) - Soften Container Apps detector claim (varies by language SDK) - Add resource attributes note (applies to all signals, not only traces) - Strengthen routing rule on landing and managed platforms pages - Add faas.id deprecation TODO for eng verification
This comment has been minimized.
This comment has been minimized.
- Restore "Adding a New Platform" CSM escape hatch (from managed platform draft) - Add sampling limitation note to Feature coverage - Add AWS log-correlation attributes to Lambda and Fargate tables - Merge duplicated "This page" sentences in Overview - Smooth Lambda faas.id required/conditional contradiction - Add compute_stats required-vs-optional TODO for eng - Remove names from TODO comments
- GKE → GKE Autopilot throughout (standard GKE is not serverless) - Add note that serverless workloads can also send logs and metrics via the general OTLP endpoints - Link standard GKE users to the general traces endpoint
- Fix _index.md link refs to use canonical paths - Tighten serverless overview (remove redundant clause, deduplicate resource attributes explanation) - Clarify managed platforms dd-otlp-source callout
- azure_app_service → azure.app_service, azure_functions → azure.functions (OTel semconv standard; backend accepts both per eng) - Remove inconsistency callout (all values are now dot-separated) - Move compute_stats=true to required headers (confirmed by outline) - Remove resolved TODOs for Azure values and compute_stats
- compute_stats: explain it's required for platform detection, not just an opt-in for trace metrics - Lambda: clarify manual attributes are for non-ADOT setups
- Managed Platforms → OTLP Intake for Managed Platforms - Serverless Traces → OTLP Intake for Serverless - Add description frontmatter to both pages - Update nav menu labels
egracer
left a comment
There was a problem hiding this comment.
@zarirhamza re: the open task for RDP configuration, my understanding is that we probably can't put list every conceivable configuration setup (any one language could have many OTel SDKs, and we want to remain vendor agnostic). Do I have that right?
| <div class="alert alert-danger">Host metadata sent to this endpoint will not populate the <a href="/infrastructure/list/">Infrastructure Host List</a>.</div> | ||
|
|
||
| You might prefer this option if you're looking for a straightforward setup and want to send telemetry directly to Datadog without using the Datadog Agent or OpenTelemetry Collector. | ||
| <!-- TODO: Add Preview sign-up link once product provides it. --> |
There was a problem hiding this comment.
@asopkin Is someone else handling this or are you looking to me to set up a form for both serverless and managed platforms?
There was a problem hiding this comment.
This should be a link to the OSS pipeline: https://www.datadoghq.com/product-preview/otel-native-instrumentation/
We can frame this as, if you want to send data from an OpenTelemetry Collector we recommend enrolling in our Preview to get the full Collector experience.
There was a problem hiding this comment.
@egracer I don't think we should need new links for managed platform / serverless?
The heading alone scopes the section; users on Standard GKE don't need to be told they're not on Autopilot.
Position direct ingest landing page to lead with the Collector/Agent recommendation for production workloads, and frame direct endpoints as the path for environments where deploying those is not feasible. Remove OpenTelemetry Collector from the routing table row 3 to avoid contradicting the premise of the section.
Rewrite managed platforms limitations to focus on the actual gaps when using direct ingest: no metadata enrichment, limited normalization, and no Collector-level sampling. OTel SDK exporters handle buffering, batching, and retry on their own.
|
|
||
| - `dd-api-key`: Your Datadog API key. | ||
| - `dd-otlp-source`: Set to `serverless`. | ||
| - `compute_stats`: Set to `true`. Required for [trace metrics][2] and serverless platform detection. |
There was a problem hiding this comment.
Do we need compute_stats for serverless platform detection? I don't think so, I think it's just for trace metrics
|
|
||
| The following configuration applies to all platforms. | ||
|
|
||
| **Protocol**: `http/protobuf` only. `grpc` and `http/json` are not supported. |
There was a problem hiding this comment.
@egracer I think we do support http/json because Cloudflare relies on it?
|
|
||
| {{< callout header="false" btn_hidden="true">}} | ||
| The serverless OTLP traces intake endpoint is in Preview. | ||
| <!-- TODO: Insert Preview sign-up form URL from product --> |
There was a problem hiding this comment.
I think we want to specifically link to the endpoint itself. It should be something like
https://otlp/.{DD_SITE}/v1/traces
With dd-otlp-source as serverless for serverless
There was a problem hiding this comment.
@asopkin - Thanks for all your feedback! Could you please clarify what you are looking for here? The endpoint renders in each code block, so I'm not quite sure where you'd like me to put this.
- Remove compute_stats from managed platforms (on by default) - Remove GCP and GAE rows from managed platforms table - Fix compute_stats description on serverless (trace metrics only) - Add OTel Preview sign-up link on landing page - Update trace metrics limitation to reflect default-on behavior
What does this PR do? What is the motivation?
Adds two new pages under Direct OTLP Ingest:
Also adds an environment-first routing table to the landing page and managed platform cross-references to the logs and metrics pages.
Proposed content decisions
Open items: eng
cloud.resource_id: Should it identify the specific function or the function app?host.idfor GKE. Doeshost.idtrigger host-based identification instead of serverless? Can intake distinguish Autopilot from Standard GKE?http/jsonsupport: Confirmed for managed platforms (Cloudflare uses it). Does serverless also supporthttp/json?Open items: product
Sign-up form link for the Preview→ Using https://www.datadoghq.com/product-preview/otel-native-instrumentation/Follow-ups: traces page header fix (including reconciling
dd-otlp-sourcesemantics between traces and serverless pages), Collector sidecar content, compatibility page updates.Merge instructions
Merge readiness: