Howdy, ECS developers and ontology fans, I have some thoughts and questions:
In the service.* field set I feel there are two distinct “naming” purposes I want to achieve.
- I want a unique identifier I can use to collate logs, or to reference between logs and other systems like a service registry, cost accounting system, or metrics dashboard.
- I want a human-readable, colloquial name or title for the service. Engineers may know this service as the “PII Filtering Processor” or “Test API”. This information should tolerate not being unique.
For the unique identifier, service.id does the job. I believe this is what this field was meant for.
For the colloquial title, what you might expect an engineer to refer to their service as in conversation, I think service.name might be the right field.
But I have questions given the description.
This allows for distributed services that run on multiple hosts to correlate the related instances based on the name.
This usage confuses me since I don’t expect service.name to necessarily be unique, and the fact that service.id exists and is ideal for this usage.
Are we saying that maybe you could correlate distributed instance logs for a service using service.name iff it happens to be unique? And aren’t implying that it should be unique?