feat: update logs fingerprint

[nityanandagohain]

Have added env and component to the hierarchy.

@raj-k-singh also env's are subhierarchy of service.name, should we keep it this way ? ideally service should be a subhierarchy of env right

[raj-k-singh]

Have added env and component to the hierarchy.

@raj-k-singh also env's are subhierarchy of service.name, should we keep it this way ? ideally service should be a subhierarchy of env right

As per otel semantic conventions, envs are a subset of a service i.e. staging & prod resources for a service still come under the same service in the semantic conventions hierarchy
https://opentelemetry.io/docs/specs/semconv/resource/deployment-environment/#:~:text=This%20implies%20that%20resources%20carrying%20the%20following%20attribute%20combinations%20MUST%20be%20considered%20to%20be%20identifying%20the%20same%20service

[nityanandagohain]

Ahh okay, thanks 👍

[ankitnayan]

Have added env and component to the hierarchy.
@raj-k-singh also env's are subhierarchy of service.name, should we keep it this way ? ideally service should be a subhierarchy of env right

Let's discuss more in the standup. This might not be the ideal user interaction. I do not see service as a superset. User would like to choose an environment and then see the list of health of services rather than the other way round

[raj-k-singh]

Have added env and component to the hierarchy.
@raj-k-singh also env's are subhierarchy of service.name, should we keep it this way ? ideally service should be a subhierarchy of env right

Let's discuss more in the standup. This might not be the ideal user interaction. I do not see service as a superset. User would like to choose an environment and then see the list of health of services rather than the other way round

I am not sure of the exact reasons behind the semantic conventions.
If I had to guess, it is because a service typically exists in a service oriented architecture, and service oriented architectures are ideally about scaling an engg org though teams, where 1 service is run by 1 team. So a typical team would own all environments for a single service and would see the hierarchy as service -> env
I can also understand how "microservices" architectures might end up with many many services per team in which case a typical team/engg would want to look for many services in a particular environment and see the hierarchy as env -> service

From the DB perf perspective, I am guessing both organizations would be performant enough and we can choose whatever we want