A Comprehensive Guide to Using Apache SkyWalking for Distributed Tracing, Logging, and Performance Analysis

What is SkyWalking?

SkyWalking is a high‑performance, open‑source APM framework originally created by a Huawei developer in 2015, entered the Apache incubator in 2017, and quickly graduated to a top‑level project. It supports Dubbo, Spring Cloud, Spring Boot, offers non‑intrusive bytecode instrumentation, uses gRPC for communication, and provides rich UI dashboards.

SkyWalking vs. Spring Cloud Sleuth+ZipKin

Compared with ZipKin, SkyWalking has the following advantages:

Non‑intrusive bytecode enhancement versus higher code intrusion of ZipKin.

Richer reporting UI and more user‑friendly charts.

Recommendation: For new architectures, prefer SkyWalking.

SkyWalking Architecture

SkyWalking follows a client‑server model similar to ZipKin. The server collects trace data and renders it in the UI.

The architecture consists of four main components:

Agent : collects logs and sends them to the OAP server.

OAP : receives trace and metric data, performs analysis, stores data, and provides query services.

UI : web console for visualizing traces, metrics, and topology.

Storage : pluggable backend (e.g., MySQL, Elasticsearch).

Server Setup

Download the binary package (e.g., version V8.7.0) from the official site and unzip it.

Key directories:

agent : contains the Java agent JAR.

bin : startup scripts (oapService.bat/.sh, webappService.bat/.sh).

config : configuration files.

logs : OAP logs.

oap‑libs : dependency JARs.

webapp : UI service files.

Modify /config/application.yml to use Nacos as the registry and adjust Nacos connection details if needed.

Change the UI port in webapp/webapp.yml from the default 8080 to 8888 to avoid conflicts.

Start both services via the scripts in /bin or simply run startup.bat (or startup.sh) to launch OAP and UI simultaneously.

Client Setup

For each microservice (e.g., product, order, gateway) add the SkyWalking agent via JVM arguments:

-javaagent:E:\springcloud\apache-skywalking-apm-es7-8.7.0\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=skywalking-product-service
-Dskywalking.collector.backend_service=127.0.0.1:11800

The arguments specify the agent JAR path, the service name (usually the Spring application name), and the OAP address.

Ensure the agent JAR path contains no Chinese characters or spaces.

Data Persistence

By default SkyWalking stores data in memory, which is lost after a restart. To persist data, switch the storage backend to MySQL (or Elasticsearch) by editing config/application.yml and adding the MySQL JDBC driver JAR to oap‑libs.

Log Monitoring

SkyWalking can collect logs from applications. Using Logback as an example, add the dependency:

<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>${project.release.version}</version>
</dependency>

Create logback-spring.xml in resources with the configuration from the official documentation.

Performance Profiling

Create an endpoint (e.g., /order/list) that sleeps for 2 seconds. Use SkyWalking’s profiling module to create a task, select the service and endpoint, and view the stack trace that pinpoints the Thread.sleep(2000) call.

Alerting

SkyWalking provides built‑in alert rules (e.g., average response time > 1 s, success rate < 80%). Custom rules can be added in config/alarm-settings.yml. Webhook integration allows sending alerts to email, WeChat, or DingTalk.

To configure a custom webhook, define a new alarm module (e.g., skywalking-alarm1004) and add the hook details to the alarm settings file.

Summary

This article covered SkyWalking as a distributed tracing solution, detailing server and client deployment, data persistence, log collection, performance analysis, and alert configuration, providing a practical end‑to‑end guide for observability in cloud‑native Java applications.