Add semantic conventions for Azure Container Apps replica name and revision id#3860
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eaf4a67aca
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| attributes: | ||
| - ref: azure.container_app.instance.id | ||
| role: identifying | ||
| requirement_level: required |
There was a problem hiding this comment.
For Azure Container Apps jobs, this required identity cannot be populated: Microsoft’s built-in environment-variable docs list CONTAINER_APP_REPLICA_NAME only for Apps, while Jobs expose job/execution variables instead. Since the new Azure page is scoped to resources running on Azure Container Apps, which also includes jobs, making this unconditionally required makes job telemetry non-conformant; please scope the entity to app replicas or make the requirement conditional/add job identity attributes.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Clarified that Azure Container Apps Jobs are out of scope in 2063e7b
There was a problem hiding this comment.
nice changes! just a couple of minor things:
-
in model/azure/registry.yaml, should we add stability: development to the new registry.azure.container_apps group too? just to be consistent with other groups like cosmosdb.
-
since replicas scale under a specific revision, did you think about adding azure.container_app.revision (mapped to CONTAINER_APP_REVISION_NAME)? might be useful for tracking version of the app later on
| - id: entity.azure.container_app | ||
| type: entity | ||
| stability: development | ||
| name: azure.container_app |
There was a problem hiding this comment.
Would this be better as
| - id: entity.azure.container_app | |
| type: entity | |
| stability: development | |
| name: azure.container_app | |
| - id: entity.azure.container_app.instance | |
| type: entity | |
| stability: development | |
| name: azure.container_app.instance |
Otherwise the impression is that it is describing the container_app rather than the instance.
| - id: registry.azure.container_apps | ||
| type: attribute_group | ||
| display_name: Azure Container Apps Attributes | ||
| brief: > | ||
| This section defines attributes for Azure Container Apps. Does not apply to Azure Container Apps Jobs. | ||
| attributes: | ||
| - id: azure.container_app.instance.id | ||
| type: string | ||
| stability: development | ||
| brief: > | ||
| The name of the replica of an Azure Container App. | ||
| note: > | ||
| The value should be set to the | ||
| [`CONTAINER_APP_REPLICA_NAME`](https://learn.microsoft.com/azure/container-apps/environment-variables) | ||
| environment variable. | ||
| examples: ["my-containerapp--20mh1s9-86c8c4b497-zx9bq"] |
There was a problem hiding this comment.
I would lean towards not creating a new group but rather just use the general azure group as they won't be kept when switching to v2 and we have the entity.
There was a problem hiding this comment.
Gotcha - used the general azure group in 678259d
This would reside on a seperate entity which is identified using this attribute and the name, just like done with the service entities. |
…nce and fold azure.container_app.instance.id into general azure group
…hat the entity is scoped to an instance
|
@Dipanshusinghh Thank you for the review!
|
|
looks great just a quick heads up yamllint check is failing because changelog note line is >200 chars once u wrap/shorten it pr looks goods |
| - id: entity.azure.container_app.revision | ||
| type: entity | ||
| stability: development | ||
| name: azure.container_app.revision | ||
| brief: > | ||
| Resource used by a revision of an Azure Container App. | ||
| attributes: | ||
| - ref: azure.container_app.revision | ||
| role: identifying | ||
| requirement_level: required |
There was a problem hiding this comment.
We should be able to do
| - id: entity.azure.container_app.revision | |
| type: entity | |
| stability: development | |
| name: azure.container_app.revision | |
| brief: > | |
| Resource used by a revision of an Azure Container App. | |
| attributes: | |
| - ref: azure.container_app.revision | |
| role: identifying | |
| requirement_level: required | |
| - id: entity.azure.container_app | |
| type: entity | |
| stability: development | |
| name: azure.container_app | |
| brief: > | |
| Resource used by a revision of an Azure Container App. | |
| attributes: | |
| - ref: azure.container_app.revision | |
| role: identifying | |
| requirement_level: required |
As it feels off having an attribute describing a property of an object where that object is named the same thing.
There was a problem hiding this comment.
Does that reopen the ambiguity we fixed earlier where the azure.container_app entity reads as the whole Container App app resource, not just the revision? Maybe we could use azure.container_app.revision.id or azure.container_app.revision.name as the identifying attribute of azure.container_app.revision?
- id: entity.azure.container_app.revision
type: entity
stability: development
name: azure.container_app.revision
brief: >
Resource used by a revision of an Azure Container App.
attributes:
- ref: azure.container_app.revision.id
role: identifying
requirement_level: required
There was a problem hiding this comment.
I like to think of it much like service. For instance you might have 1 app with many instances with each app sharing the same revision, when a new version is released the instances will switch to the new one but you still want to know about the old entity.
Hence i think it is ok. however it could be azure.container_app.app.* to be fully unambiguous, with the attributes also renamed. Ideally we could've just used app.id etc but that is harder to get approved.
There was a problem hiding this comment.
Sounds good, I can update to entity.azure.container_app once the PR is reopened. But I'm also wondering if the actual stable identifier for an Azure Container App entity would be its name (CONTAINER_APP_NAME -> service.name)?
There was a problem hiding this comment.
It could be either & i have no strong opinion as never used azure container apps.
My thought would be to go with what is most consistent after checking k8's etc.
There was a problem hiding this comment.
It looks like most objects that have a real platform-issued UID (pod, deployment, node, etc.) mark .name as descriptive (e.g. k8s pods, nodes). Some other entities without a UID use .name as the identifying attribute (namespace, service, gcp.gce.instance_group_manager)
AWS ECS and GCP Cloud Run both don't mark any attribute as role:identifying, and aws.ecs.task.revision is requirement_level: recommended without any role. I think for this PR's scope I'll drop role: identifying and requirement_level: required from azure.container_app.revision on entity.azure.container_app and update the brief to Resource used by Azure Container Apps
Azure Container Apps doesn't expose an UID via env vars - I'd say the closest unique identifier is the resource ID (a composite string similar to AWS ARNs) but that cannot be derived from a single env var (and there are no env vars for resource groups/subscription ids in Azure Container Apps anyway).
There was a problem hiding this comment.
makes total sense to drop the identifying role since there's no platform UID, same as ecs/run hope we can get this reopened via CNCF slack soon, looks ready!
There was a problem hiding this comment.
The reason they don't have a role is because they are legacy in fact any entity stability level other than dev requires a role, hence i would be setting it to name in this pr. We can always refine it as part of stability works later.
There was a problem hiding this comment.
Thinking over it, I think it makes sense for azure.container_app.revision to be the identifying attribute of the Azure Container App entity since the container app name can be derived from the revision name (it doesn't seem like container apps can have consecutive hyphens in their name, so revision names can be parsed as <container-app-name>--<revision-suffix>, and an app name wouldn't add any disambiguating information beyond what revision already encodes.
@trask Would you be able to take a look at this PR? My changes aren't showing up because it's closed. Thank you so much!
github-actions
Bot
added
enhancement
|
👋 Thanks for your contribution! This PR modifies file(s) in area(s) that do not currently have an active SIG/project:
Per the area ownership process, This does not mean your change is unwelcome:
Thanks again for taking the time to contribute! 🙏 |
kathiehuang
changed the title
|
👋 Thanks for your contribution! This PR modifies file(s) in area(s) that do not currently have an active SIG/project:
Per the area ownership process, This does not mean your change is unwelcome:
Thanks again for taking the time to contribute! 🙏 |
|
👋 Thanks for your contribution! This PR modifies file(s) in area(s) that do not currently have an active SIG/project:
Per the area ownership process, This does not mean your change is unwelcome:
Thanks again for taking the time to contribute! 🙏 |
…bute" This reverts commit 184abe6.
jsuereth
moved this from Untriaged
to Awaiting codeowners approval
in Semantic Conventions Triage
There was a problem hiding this comment.
Pull request overview
Note
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Adds semantic conventions to identify Azure Container Apps replicas and revisions via new Azure attribute keys and entity definitions.
Changes:
- Added
azure.container_app.instance.idandazure.container_app.revisionAzure resource attributes. - Introduced
azure.container_app.instanceandazure.container_appentities using those identifying attributes. - Published corresponding generated documentation and linked it from the cloud-provider docs index.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| model/azure/registry.yaml | Defines the two new Azure attribute keys for Container Apps replica + revision identification. |
| model/azure/entities.yaml | Adds two new entities backed by the new identifying attributes. |
| docs/resource/cloud-provider/azure.md | New user-facing resource semantic conventions doc for Azure Container Apps entities. |
| docs/resource/cloud-provider/README.md | Adds an Azure entry pointing to the new Azure Container Apps doc. |
| docs/registry/entities/azure.md | Generated entity reference page for the new Azure entities. |
| docs/registry/entities/README.md | Adds Azure namespace + entity entries to the entities index. |
| docs/registry/attributes/azure.md | Generated attribute reference entries for the new keys (and adjusts footnotes). |
| .chloggen/add-azure-container-app-instance-id.yaml | Changelog entry describing the new entities/attributes. |
| - id: azure.container_app.revision | ||
| type: string | ||
| stability: development | ||
| brief: > | ||
| The name of the revision of an Azure Container App. |
There was a problem hiding this comment.
That makes sense, updated to azure.container_app.revision.name in 1d19c64
| This document defines semantic conventions for resource cloud providers. | ||
|
|
||
| * [AWS](aws/README.md): Semantic Conventions for Amazon Web Services. | ||
| * [Azure](azure.md): Semantic Conventions for Azure. |
There was a problem hiding this comment.
Created an azure/README.md page and linked to it in cloud-provider/README.md 6d57de3. The Azure Container Apps page is now linked in azure/README.md
|
|
||
| # Azure | ||
|
|
||
| ## Azure Container App |
There was a problem hiding this comment.
It looks like the generation title-cases the entity's name field directly
and setting an explicit display name/title doesn't seem to be supported by the generator
Pull request dashboard statusStatus last refreshed: 2026-07-25 14:01:44 UTC.
This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected. |
Fixes #3857
Changes
Adds two resource attributes and two entities for identifying Azure Container Apps resources:
azure.container_app.instance.id- the replica name of an Azure Container Appazure.container_app.instanceentityazure.container_app.revision.name- the revision name of an Azure Container Appazure.container_appentityThere is no semantic convention for the replica name of an Azure Container App. The Azure Container Apps resource detector needs a resource attribute to record this, but
service.instance.idis not suitable: the Go SDK's default resource detector auto-populates service.instance.id with a random UUID, which would conflict with the detector's replica name value for Go users.azure.container_app.instance.idavoids that collision, is more precise, and is consistent with the precedent set by the Node.js SDK's Azure resource detector.The value should map to the
CONTAINER_APP_REPLICA_NAMEenvironment variable that Azure Container Apps injects into every replica.This was raised during review of open-telemetry/opentelemetry-go-contrib#9208, which updates the Go SDK's Azure Container Apps resource detector to use this attribute instead of
service.instance.id.There also lacks a semantic convention for the name of an Azure Container App revision. This would be helpful for tracking Azure Container App versions. This value should map to
CONTAINER_APP_REVISION.Important
Pull request acceptance is subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above may be automatically rejected and closed.
Merge requirement checklist
Footnotes
Yes, I can answer maintainer questions about the content of this PR without using AI. ↩