service.type and service.name

Currently ECS has a service.name and the expected content when for example talking to a MySQL service is that it contains mysql. APM on the other hand uses service.name as the manual set name by the user for the service in which the agent is running and if the service talks to MySQL, service.type is set as mysql. The following proposal is to add service.type and define the usage of both.

A few examples to explain the usage

Metricbeat monitoring MySQL and service foo

Metricbeat monitors with the MySQL module a MySQL host and with the HTTP module a user built service foo. The events collected from these will look as following:

MySQL events:

service.name:
service.type: mysql

Foo events:

service.name:
service.type: foo

It will be up to user to define the field service.type in the HTTP module. We should make it easier on our end.

Questions

• Should be default service.name be filled with service.type if it’s empty?

Metricbeat monitoring 2 MySQL servers

Metricbeat is monitoring two different MySQL servers on the same host. One server stores user data the other one is for tracking. The events will look as following:

User data MySQL instance:

service.name: user-data-mysql
service.type: mysql

Tracking data MySQL instance

service.name: mysql-tracking
service.type: mysql

The user can set a name for each service he is monitoring. This will allow later to differentitate between the two services. We should recommend to prefix the name with the service.type.

Metricbeat monitoring an Elasticsearch cluster

Metricbeat monitors and Elasticsearch cluster across different hosts. The cluster name is baz.

service.name: baz
service.type: elasticsearch

The name of the cluster is put in as service.name. This allows to group together all nodes related to a cluster. Currently elasticsearch.cluster.id or elasticsearch.cluster.name are use for this. One of these fields should be copied to the service.name.

APM agent running in service foo

An apm agent running inside the service foo will report it’s data as following. The service is built on top of node.js:

service.name: foo
service.type: node.js

The service.name is set by the user inside the agent. It could also be foo-prod1 and foo-prod2. In this case these would be two different services.

APM agent running in service foo talking to mysql service

An apm agent running inside the service foo is talking to a MySQL instance.

service.name: mysql
service.type: mysql

The service.type will be set to MySQL as the info is about a connection / query to MySQL. If not name of the service it connects to can be found, it will fill in service.type.

Question

• Is the above correct?
• Is the service.name needed in thsi context?

[ruflin]

@graphaelli I think we could even have an example in the description of service.name as soon as the PR is merged.

For the spans: Got it, didn’t know also there filtering on service.name is happening.

[graphaelli]

@ruflin where would you like those additional examples? service.name is in https://github.com/elastic/ecs/blob/master/use-cases/apm.yml currently.

For the span documents: I’m wondering if you need the service.name entries at all there? Is it required for some queries or is it only to be shown in the UI?

I’m not sure I follow - besides the case @roncohen mentioned where we pull the top SQL queries for a service? ES queries filtering on service.name within spans is very common.