Instana traces and analyzes every request. Services and endpoints are automatically discovered, and relationships between services, endpoints, and your infrastructure are autocorrelated and stored in our dynamic graph.

Based on the data we collect from traces and our sensors, KPIs are calculated for calls, latency, and erroneous calls. This helps you discover the health of every individual service, and, subsequently, the health of your entire infrastructure.

Services are an integral part of application monitoring and provide a logical view of your system. Services are derived from infrastructure components such as hosts, containers, and processes. The act of assigning specific components to one or more services, is referred to as service mapping.

Instana automatically maps all services based on an extensive set of predefined rules. Based on these rules, calls and infrastructure data are examined before a service is created. To create your own custom rules, see customize service mapping.

Predefined Rules

The following rules are considered in the order top to bottom. When a rule matches, the respective service is created.

Rule Tags
Custom service rule Tags defined by the user (see custom service mapping)
User defined service name from environment variable INSTANA_SERVICE_NAME on process {}
User defined service name via HTTP Header X-Instana-Service {call.http.header.x-instana-service}
User defined service name in sdk span data (set service tag) {call.tag.service}
OpenTelemetry defined service name {call.tag.otel.service}
Jaeger defined service name {call.tag.jaeger.service}
Zipkin defined service name {call.tag.zipkin.service}
Consul cluster name [email protected]{}
Cassandra cluster name {}
ElasticSearch cluster name {}
Couchbase cluster name {}
MongoDB replica set name {mongo.replicaSetName}
Kafka cluster name {}
ClickHouse cluster name [email protected]{}
GCP Cloud Run Service {}
AWS ECS container name {}
AWS ECS task family {}
Kubernetes container name {}
Cloud Foundry Application name {}
Docker Swarm service name {}
Marathon application id (parsed) {}
Nomad task name {}
Rancher 1 project service name {}
Container image name (parsed) {}
Application Container (JBoss / Tomcat) deployment name with file extension (parsed) {}
Application Container (JBoss / Tomcat) deployment name with no file extensions (parsed) {}
Dropwizard name {}
Spring Boot name {}
JBoss name {} {}
WebSphere name {}
WebLogic name {}
Redis port [email protected]{redis.port} on {}
Aerospike port [email protected]{aerospike.port} on {}
Neo4j port [email protected]{neo4j.port} on {}
Memcached port [email protected]{memcached.port} on {}
Varnish port [email protected]{varnish.port} on {}
Clickhouse port [email protected]{clickhouse.httpPort} on {}
MongoDB database name [email protected]{mongo.port} on {}
Zookeeper port [email protected]{zookeeper.clientPort} on {}
Solr version Solr-{solr.version} on {}
Solr Solr on {}
Solr Zookeeper Solr Zookeeper-{solr.zk_host}
PostgreSQL port [email protected]{postgresql.port} on {}
CockroachDB port [email protected]{cockroachdb.port} on {}
MySQL port [email protected]{mysql.port} on {}
OracleDB port [email protected]{oracledb.port} on {}
MSSQL database SID [email protected]{mssql.instance}
MariaDB port [email protected]{mariadb.port} on {}
Kafka version Kafka-{kafka.version} on {}
ActiveMQ broker name {}
RabbitMQ version RabbitMQ-{rabbitmq.version} on {}
JVM name from jar file {}
JVM name {}
Node.js application with host environment {}
Python snapshot name {}
Ruby name {}
Go name {}
PHP using host-header when available (parsed) {}
PHP for PHP-FPM worker-pool PHP
CLR name {}
.Net Core name {}
Haskell name {}
Crystal name {}
Google Cloud Storage Google Cloud Storage
Shell span Spawned processes
RPC service span using object (parsed, with WSDL namespaces) {call.rpc.object-1}
RPC service span using object {call.rpc.object}
Database FTP span {call.database.connection}
Database cache-type span with connection (parsed) {call.database.type} @ {call.database.connection-1}
Database cache-type span {call.database.type}
MongoDB database span (parsed) {call.database.schema-1}
ElasticSearch database span (parsed) {call.database.connection-1}
Couchbase / Redis database span (parsed) {call.database.connection-1}
DynamoDB database span dynamodb
CosmosDB database span (parsed) {call.database.schema-1}
Generic database span {call.database.schema}
Generic database span, using schema from connection (parsed) {call.database.connection-1}
Generic database span, using host from connection (parsed) {call.database.connection-1}
Generic database span, fallback type {call.database.type}
Messaging span, for temporary queues {call.messaging.type}
JMS span using address (parsed) {call.messaging.address-1}
Messaging span using address (full) {call.messaging.address}
Messaging span, no address {call.messaging.type}
HTTP span with host (parsed) {}
HTTP span with URL (parsed) {call.http.url-1}
Function as a Service span with functionname {faas.functionname}
Function as a Service span with identifier {}
PHP script span (such as CLI) {}
SDK span SDK
RPC (RMI) span, no object RMI
GraphQL Subscriber span GraphQL Subscribers
Event Trigger {call.event.trigger}
Cloud Metadata Service Cloud Metadata Service

A service can be seen as a logical component that provides a public API to the rest of the system, in which the API is made up of its endpoints. A service is being monitored and makes and receives calls. A request to a service results in a single call to a particular endpoint.

Services can be considered in isolation or through the lens of an application perspective. Services often map to one 'unit of deployment', such as a package or container. If multiple instances of this e.g. container operate at the same time, they will all map to the same logical service.

Service types are assigned automatically through inheritance from endpoints. For example, if a service has both HTTP and BATCH endpoints, then it is assigned both HTTP and BATCH types. KPIs (Calls, Errors, Latency) for services display an aggregate of all calls, regardless of type.

Customize service mapping

There are four methods for customizing the default service mapping:

  1. Create a custom service rule. Even if services are configured, for example, with the INSTANA_SERVICE_NAME environment variable, this rule still precedes all other rules in priority.
  2. Apply the tag.
  3. Specify the INSTANA_SERVICE_NAME environment variable.
  4. Specify the HTTP header X-Instana-Service.

Create a custom service rule

  1. From the sidebar, click Applications and select the Services tab.
  2. Click Configure Services
  3. Click Add Custom Service Rule
  4. From the drop-down list, select the tags.

One reason for using a custom service rule is to leverage existing meta information of your infrastructure components. For example, if you label your Docker containers with domain specific information, such as com.acme.service-name:myservice, to map services from this label select the docker.label and com.acme.service-name tags. All calls that pass a container with the label com.acme.service-name are associated with a service which is named by that value, e.g. myservice. There are multiple tags available to create custom service mapping.

You can also add multiple keys for service mapping. Multiple tags will be concatenated and separated with a dash. Note that all keys need to match. E.g., if you want to separate your staging services based on the host zone you could add two keys: + docker.label:com.acme.service-name. Your services would then be named with a concatenation of the values for the host zone followed by the docker label. That way you would separate out the two services e.g. prod-myservice and dev-myservice.

By using a special tag service.default_name, a custom service rule can also be used to extend service default rules with additional tags. For example, to split the automatically created services by host zones, create the custom service rule using the tags service.default_name and

Service Configuration Dialog

Apply the call tag

To associate specific calls, annotate calls with service which enables tailored mappings within your code. For searching and analyzing calls, the service annotation is turned into the tag.

To add call annotations, the following options are available:

For more information about the Java Trace SDK and the naming of services, see the Conversion and Naming section.

Specify the INSTANA_SERVICE_NAME environment variable

By setting the INSTANA_SERVICE_NAME environment variable on a process, the value of the environment variable is used as the service name for all calls that have as destination that process.

For more information on environment variables recognized by Instana, see our general reference docs.

Specify the X-Instana-Service HTTP header

By setting the X-Instana-Service HTTP header on a call, the destination (the service receiving the HTTP request) is tagged with the value provided in the header.

Note: The X-Instana-Service HTTP header is not automatically collected. For it to work, the Instana agent must be configured accordingly, see "Capturing custom HTTP headers".


Why am I not seeing any services listed?

The reason no services are listed is due to either the agent not running in APM mode, having no agent installed; therefore, no traces were collected, or if you have an agent installed, traces were not collected during your selected timeframe.

To check whether an agent is installed and running, click Infrastructure to view any hosts on the infrastructure map that may have an agent, or click MoreAgents to see a list of installed agents. If there are no agents listed, see the documentation on how to install an agent or create an application perspective.