5.2 Service Detection: Web Services, Background Tasks & Custom Services

Service Detection: Web Services, Background Tasks & Custom Services

Exam Focus: Mastering how Dynatrace automatically discovers services, configuring Custom Services for non-standard or proprietary communication protocols, splitting and merging services using detection rules, and differentiating between fully monitored and Opaque Services is essential for passing the Dynatrace Certified Associate exam.

In Dynatrace, a Service represents a logical endpoint that receives requests and executes business logic. Services are the central operational construct within Dynatrace: they serve as the anchor for PurePath distributed tracing, response-time and error-rate baselining, service-level objectives (SLOs), and architectural dependency mapping.

Unlike traditional Application Performance Monitoring (APM) solutions that require developers to annotate classes, write configuration XMLs, or declare transaction boundaries in advance, Dynatrace OneAgent discovers services automatically through runtime bytecode instrumentation and operating system dynamic library hooking.

---

Principles of Automatic Service Detection

When OneAgent injects its code modules into an application process runtime (Java, .NET, Node.js, Go, PHP, Apache, NGINX, IIS), it monitors the execution boundaries of that process. An automatic service is generated whenever OneAgent detects an incoming request from an external client or another process.

The Three Automatic Service Criteria

Dynatrace delineates and generates an automatic service based on three primary dimensions:

1. Process Group Boundary: The service executes within a defined Process Group.
2. Technology Runtime: The underlying software stack (e.g., Java Servlet engine, Microsoft ASP.NET Core, Node.js HTTP module).
3. Request Protocol & Entry Point: The communication protocol over which requests arrive (e.g., HTTP/HTTPS, SOAP over HTTP, gRPC, JDBC/ODBC, JMS, Kafka).

[ Incoming Request ] 
        │
        ▼
[ Known Web / RPC Protocol? ] ──► YES ──► [ Automatic Service Generated ]
        │                                    (Web Request / Web Service / Messaging)
        ▼ NO
[ Standard DB Driver Call? ]  ──► YES ──► [ Automatic Database Service ]
        │                                    (PostgreSQL, Oracle, MySQL, MongoDB)
        ▼ NO
[ Proprietary / Custom Code? ] ─► YES ──► [ Process Monitored, but NO Service ]
                                             ──► ACTION: Create Custom Service Rule!

---

Built-in Service Classifications

Dynatrace categorizes automatically discovered services into distinct operational classifications based on the protocol, payload type, and technology stack:

1. Web Request Services

Web Request Services process standard HTTP/HTTPS traffic. They are detected by web server sensors (Apache, NGINX, Microsoft IIS) and application server servlet engines (Tomcat, JBoss, WebSphere, ASP.NET Core, Node.js).

• Typical Workloads: Serving static web pages, HTML content, images, CSS, JavaScript files, and dynamic server-side page rendering.
• Default Naming: By default, Dynatrace names web request services based on the Web Application ID or the Context Root of the deployed application within the process group (for example, /orders or /checkout on Tomcat_App_Pool).

2. Web Services (REST, SOAP, gRPC)

When incoming HTTP or RPC requests contain structured API payloads, Dynatrace automatically classifies the endpoint as a Web Service.

• REST Services: Microservice endpoints accepting JSON or XML payloads via standard HTTP methods (GET, POST, PUT, DELETE).
• SOAP Services: Legacy enterprise web services utilizing WSDL contracts and XML SOAP envelopes over HTTP.
• gRPC Services: High-performance microservices communicating via HTTP/2 and Protocol Buffers (Protobuf) serialization.
• Granularity: Web services allow filtering and baselining at the individual endpoint or operation level (for example, /api/v2/payments/{id}).

3. Database Services

Database services are generated automatically whenever an instrumented application process interacts with a relational database or NoSQL datastore via supported client libraries:

• Supported Drivers: Java Database Connectivity (JDBC), Microsoft ADO.NET, Oracle Call Interface (OCI), Python DB-API, Node.js database drivers, MongoDB drivers, Cassandra drivers, and Redis clients.
• Service Modeling: Dynatrace models the database service from the perspective of the application calling it. It captures the target database name, host, listening port, and SQL statement executions (including query duration, fetch count, and execution errors).
• Instrumented vs. Uninstrumented Databases: If OneAgent is also installed on the database host itself (e.g., on the PostgreSQL Linux server), Dynatrace provides full-stack host and process metrics. If the database is a managed cloud service (such as Amazon RDS or Azure SQL) where OneAgent cannot be installed, Dynatrace still monitors the database service accurately from the client-side OneAgent perspective.

4. Messaging and Event-Driven Services

Messaging services capture asynchronous message ingestion across enterprise message brokers and event streaming platforms:

• Supported Systems: Java Message Service (JMS), Apache ActiveMQ, RabbitMQ (AMQP), Apache Kafka, and AWS SQS.
• Operational Model: Unlike synchronous HTTP services where a client waits for a response, messaging services instrument consumer threads processing incoming messages from queues or topics. Dynatrace traces the transaction across the queue boundary, linking the producer's PurePath to the consumer's PurePath.

5. Background Tasks & Batch Jobs

Many enterprise applications execute heavy processing outside incoming web requests—such as scheduled cron tasks, batch ETL jobs, payment reconciliation loops, or asynchronous queue consumers. When these tasks run inside supported frameworks (such as Spring @Scheduled tasks or Quartz schedulers), Dynatrace automatically captures them as Background Task Services.

---

Custom Service Detection: Monitoring Proprietary and Non-Standard Frameworks

While OneAgent automatically detects standard protocols, enterprise architectures frequently contain proprietary communication systems, legacy RPC frameworks, or custom background thread loops that OneAgent does not instrument by default.

In these scenarios, OneAgent monitors the host, process, and operating system metrics, but no services or PurePath transaction traces appear in Dynatrace. To achieve deep code-level tracing, administrators must configure a Custom Service.

When to Configure a Custom Service

• The application communicates over a custom binary TCP socket or proprietary wire protocol (e.g., FIX protocol in trading, ISO 8583 in banking).
• Background processing loops pull tasks directly from memory or custom file buffers rather than standard message queues.
• A legacy internal framework executes business transactions without using supported HTTP or RPC interfaces.

Custom Service Configuration Steps

Custom services are configured under Settings > Server-side service monitoring > Custom service detection:

1. Select Technology Runtime  ──► Java, .NET, Node.js, Go, or PHP
2. Name the Custom Service   ──► e.g., "Financial-Fix-Transaction-Engine"
3. Define Entry Point Class   ──► Fully qualified class name (e.g., com.corp.fix.FixProcessor)
4. Specify Class Matching     ──► Match exact class, implements interface, or extends base class
5. Specify Entry Point Method ──► Method name (e.g., processOrder) and method signature
6. Optional: Capture Payload  ──► Extract method argument or return value for request naming

Class Matching Mechanics

• Class Name (Exact Match): Instruments only the explicitly named class.
• Class Implements Interface: Dynatrace dynamically inspects loaded classes and instruments any class implementing the target interface (e.g., implements com.corp.engine.ITransactionHandler).
• Class Extends Superclass: Instruments any concrete subclass inheriting from a common base class (e.g., extends com.corp.core.AbstractBatchWorker).

Exam Warning on Custom Service Overhead: Never place a custom service rule on a high-frequency internal utility method (such as String.format() or a low-level byte buffer parser) that executes millions of times per second. Doing so introduces significant bytecode instrumentation overhead. Custom service rules must be placed strictly on the entry-point method that initializes a logical transaction.

---

Service Naming Rules, Splitting & Merging

By default, Dynatrace applies standardized heuristics to name and group services. However, complex enterprise environments often require customizing how services are named, separated, or combined.

Service Splitting

In multi-tenant or multi-domain architectures, a single web server or process group often handles requests for multiple distinct business units. By default, Dynatrace groups them into a single monolithic service. Administrators can configure Service Detection Rules to split the service into separate logical entities:

• Splitting by HTTP Host Header: Splits a single web server process into distinct services based on domain names (for example, retail.company.com vs. wholesale.company.com).
• Splitting by URL Path / Context Root: Separates endpoints based on path segments (for example, splitting /api/v1/auth from /api/v1/checkout).
• Splitting by Request Attributes: Splits services based on custom HTTP headers, session cookies, or method argument values (e.g., tenant ID).

Service Merging

Conversely, if an identical microservice is deployed across multiple distinct process groups or Kubernetes deployments, Dynatrace might detect multiple separate services. Administrators can use Service Merging Rules to combine these identical instances into a single unified logical service, aggregating their response times, failure rates, and Davis AI baselines into a consolidated view.

---

Opaque Services vs. Monitored Services

A critical distinction on the Dynatrace Certified Associate exam is the difference between a Monitored Service and an Opaque Service.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ MONITORED SERVICE                                                                       │
│ • OneAgent installed on the host and injected into the runtime process memory space.    │
│ • Full-stack visibility: Client-side metrics + Server-side PurePath + Code method trees.│
│ • Underlying Host, Process Group, and CPU/Memory telemetry fully correlated in Davis.   │
└─────────────────────────────────────────────────────────────────────────────────────────┘
                                            │
                                            ▼ (Outbound HTTP / RPC Call)
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ OPAQUE SERVICE                                                                          │
│ • Target server has NO OneAgent installed (Third-party SaaS API or unmonitored server). │
│ • Client-side visibility ONLY: Request count, failure rate, response latency, payload.  │
│ • NO server-side PurePaths, NO code-level hotspots, NO host CPU/Memory visibility.      │
└─────────────────────────────────────────────────────────────────────────────────────────┘

Characteristics of Opaque Services

• Definition: An external endpoint, third-party API (e.g., Stripe, PayPal, Twilio, SendGrid), or internal legacy server called by an instrumented service, where the receiving host does not have OneAgent installed.
• Telemetry Captured: Because the calling service is instrumented, OneAgent measures the outbound call duration, call frequency, payload sizes, and HTTP response codes (e.g., detecting HTTP 502 Bad Gateway or 504 Gateway Timeout from the vendor).
• Limitations: Dynatrace cannot see what happens inside the opaque service. There are no server-side method execution trees, no database queries executed by the external vendor, and no host infrastructure metrics.

---

Comprehensive Service Type Comparison Matrix