feat: introduce new service.criticality attribute (#2986)

[bachgarash]

Fixes #2986

This PR introduces a new attribute - service.criticality

Relevant discussion has been made during Service and Deployment Semconv SIG meet

Meet notes https://docs.google.com/document/d/1Fy6yXfZqrwN_oHw95Bdfg_0hzUgzlk3VO5wA1invgkI/edit?tab=t.0

Recording can be found https://docs.google.com/spreadsheets/d/1SYKfjYhZdm2Wh2Cl6KVQalKg_m4NhTPZqq-8SzEVO6s/edit?gid=0#gid=0 (6th of November)

Changes

This PR introduces a new semantic convention attribute service.criticality to enable classification of services based on their operational importance. This attribute will allow observability platforms to implement criticality-aware tracing, and sampling strategies.

[!IMPORTANT] Pull requests acceptance are 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

• [x] CONTRIBUTING.md guidelines followed.
• [x] Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• [ ] Links to the prototypes or existing instrumentations (when adding or changing conventions)

[bachgarash]

Links to the prototypes or existing instrumentations (when adding or changing conventions)

I need help with guidance on how to provide prototype for a newly introduced semantic convention attribute. Please, feel free drop your idea. Thanks in advance!

[jsuereth]

Note: The build is failing - My approval is for the proposed change, but please clean up the build and get all tests to pass. I believe this needs a make table-generation registry-generation pass at a minimum, and possibly other cleanups .

[thompson-tomo]

@bachgarash can you regenerate the docs to take on the changes to the documentation templates?

[bachgarash]

Hi there. I have added a basic prototype into Otel-demo as requested

https://github.com/open-telemetry/opentelemetry-demo/pull/2770

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: bachgarash / name: Bəxtiyar (08b5c9691fd4a9c603977a9765287364b9854a7b, 8a2324b9a1b1fbbb2e44d617406a0f6c1758f6f6, ea2fa7eebe19ed02a3537524860a5a44e3fb4408)

[thompson-tomo]

Would service.instance.criticality be a better option given it is describing the criticality of the instance shown by being on the service.instance entity?

[joaopgrassi]

Would service.instance.criticality be a better option given it is describing the criticality of the instance shown by being on the service.instance entity?

@thompson-tomo No, see: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/service.md

The criticality is a characteristic of the logical service, thus, implicitly applied to all its instances.

[thompson-tomo]

@joaopgrassi that is what I had been thinking however the new attribute has been added to the service.instance entity as a descriptive attribute https://github.com/open-telemetry/semantic-conventions/blob/08b5c9691fd4a9c603977a9765287364b9854a7b/docs/registry/entities/service.md?plain=1#L36 rather than the being a descriptive attribute on the service entity. Hence the question.

[joaopgrassi]

@joaopgrassi that is what I had been thinking however the new attribute has been added to the service.instance entity as a descriptive attribute

https://github.com/open-telemetry/semantic-conventions/blob/08b5c9691fd4a9c603977a9765287364b9854a7b/docs/registry/entities/service.md?plain=1#L36 rather than the being a descriptive attribute on the service entity. Hence the question.

@thompson-tomo I don't get it then. Your comment mentions it being in the instance namespace, not on the service.

Would service.instance.criticality be a better option given it is describing the criticality of the instance shown by being on the service.instance entity?

[thompson-tomo]

The current proposal is to add a descriptive attribute service.criticalityon the service.instance entity.

I originally suggested renaming the attribute to be in the service.instance namespace

Would service.instance.criticality be a better option given it is describing the criticality of the instance shown by being on the service.instance entity?

This was so that it was clear that the criticality is of the instance of the service as the attribute usage suggests.

That was based on the understanding that the entity assignment was correct.

You then mentioned that

The criticality is a characteristic of the logical service, thus, implicitly applied to all its instances.

That for me is contradicted by which entity it is assigned to. If it implicitly applies to all instances then it should belong to the service entity.

[joaopgrassi]

Where the attribute is actually defined is not what I'm after. My point is that I believe the attribute should be set on the service entity, not on the service.instance one. Like I said, the criticality is the same for all instances, so it makes more sense to apply it to the logical service entity.

[Ayushi-12]

Sharing a scoping and analysis of current use cases of Criticality semantics in some major observability platforms and Cloud providers for reference - Criticality Semantics POC document @bachgarash you can consider adding it to the description as supporting arguments for the criticality semantics.