1. What is a service? #
The logical level of requests.
Definition #
For Dynatrace, a service is an entry point that receives requests: a web application, an API, a message consumer, a database seen from the application. It sits above processes: one process group can expose several services, and a service can run in many instances.
Services are linked by distributed traces (PurePaths) and appear in the Smartscape topology: this is what lets Davis follow how a problem spreads.
2. Automatically detected types #
Depending on the technology.
Main types #
| Type | What creates it | Examples |
|---|---|---|
| Web requests | instrumented HTTP entry point | Spring, ASP.NET Core, Express REST APIs |
| Web services | contract-described services (SOAP, WCF) | SOAP, WCF |
| Database | calls to a database from the application | PostgreSQL, Oracle, MongoDB, Redis |
| Messaging | message consumption | Kafka, JMS, RabbitMQ |
| Remote calls | RPC protocols | gRPC, RMI |
| Unified services | OpenTelemetry traces or span data | OTel-instrumented services |
| External (opaque) services | outgoing calls to an unmonitored system | partner API, SaaS |
Good to know: A cache such as Redis or a queue such as Kafka is not a separate “service type”: seen from the application, Redis appears as a database, and Kafka message consumption as a messaging service. Containers are infrastructure entities, not services.
Depending on the version: Unified services and span-based service detection come with the new platform; exact type names may vary depending on the environment version.
3. Custom services and rules #
When automatic detection is not enough.
Custom services #
Processing without a standard entry point (Java batch, scheduled task, home-made listener) does not appear as a service. A custom service declares an entry method (class and method): each call then becomes a service request, with its timings and errors.
Detection and naming rules #
Detection rules let you merge identical services (same application on several ports) or split them (one application serving several customers). Naming rules replace technical names with meaningful ones.
Good practice: Name services after the business function and environment (for example payment-api [prod]): alerts, SLOs and dashboards become readable by everyone.Commands to know #
Select services with an entity selector (API v2, configuration):
type(SERVICE),serviceType(DATABASE_SERVICE)
type(SERVICE),tag("env:prod"),entityName.startsWith("paiement")
type(SERVICE),fromRelationships.runsOnProcessGroupInstance(type(PROCESS_GROUP_INSTANCE),tag("team:shop"))curl -H "Authorization: Api-Token $DT_TOKEN" \
"$DT_URL/api/v2/entities?entitySelector=type(SERVICE),serviceType(DATABASE_SERVICE)&fields=properties.serviceType"Full syntax: Mastering entity selectors.
