Implementation of Service Chain Monitoring and End-to-End Process Monitoring

Service Chain Monitoring Implementation

Service‑chain monitoring (a form of Application Performance Management) tracks the complete call chain of a request across multiple services, helping to locate faults, analyse performance, and optimise dependencies. Open‑source tools like Zipkin or SkyWalking require JVM agents, whereas the presented approach uses a custom protocol that follows the same principles.

Basic concepts and scenarios – APM belongs to IT operations management and monitors key business‑critical applications to improve reliability and reduce total cost of ownership. In distributed environments a single request often traverses many services written in different languages and deployed in different data centres, so tracing tools are essential.

The fundamental model consists of Spans (the smallest work unit, identified by a UUID‑like ID) and Traces (a tree of spans representing a full call chain).

Typical challenges include rapid problem discovery, impact‑range assessment, dependency analysis, and capacity planning. Service‑chain monitoring addresses these by providing traceability, visual timing breakdowns, dependency optimisation, and behavioural analytics.

Business scenario verification – The article walks through an expense‑report submission workflow, detailing four steps: data validation, budget check, document saving, and workflow initiation.

Usage guidelines

Inject a TRACE_ID field into every service interface call.

TRACE_ID format: UUID.SPANID.SPANID... where each SPANID is a two‑digit incremental code (01, 02, …).

Example TRACE_ID: 550e8400-e29b-41d4-a716-446655440000.01.01.02

Reference pseudocode

public String ApplySubmit() {
    // generate UUID
    String uuid = utils.generateUUID();
    // data validation service
    Boolean r1 = this.DataValidateSrv(params, uuid + ".01");
    // budget validation service
    Boolean r2 = this.BudgetValidateSrv(params, uuid + ".02");
    // bill save service
    Boolean r3 = this.BillSaveSrv(params, uuid + ".03");
    // start workflow service
    Boolean r4 = this.StartWorkFlow(params, uuid + ".04");
    String result;
    return result;
}

Sub‑service implementation follows the same pattern:

public String DataValidateSrv(params, TraceID) {
    // call vendor validation
    this.VendorValidateSrv(params, TraceID + ".01");
    // call bank account validation
    this.BankAccountValidateSrv(params, TraceID + ".02");
    String result;
    return result;
}

Logging – Both ESB bus services and internal services must record logs containing service ID, name, TRACE_ID, input/output, and timing information. Example logging pseudocode is provided to capture start/end timestamps and persist them via a logging service.

Visualization – Collected TRACE_ID data can be correlated to build a tree view of the service chain, typically displayed as an expandable table/tree structure.

End‑to‑End Process Monitoring

End‑to‑end monitoring focuses on cross‑system business processes that span multiple platforms (e.g., e‑commerce, CRM, logistics, ERP, payment). By tracking a core business key such as an order number, the system can determine which stage the process has reached.

Modeling involves defining interface interactions as nodes in a process diagram, registering them on an ESB bus, and using Solr to index and search log data by business keys. The workflow is:

Locate the process template and its involved services.

Identify XPath extraction rules for each service.

Construct Solr queries from extracted values.

Map retrieved log entries to the corresponding diagram nodes.

Render the instantiated process diagram, colour‑coding nodes by status (executed, failed, pending).

Clicking a link in the diagram reveals detailed log information for that service call.

The combined use of Solr indexing and ESB‑based service tracing enables fast (≈10 ms) retrieval of logs and real‑time visualisation of cross‑system workflows, completing a practical end‑to‑end monitoring solution.