Why Teams Choose SkyWalking: Lightweight Deployment and Monitoring Tips

In distributed systems and micro‑service architectures, observability is a core capability for service stability. Apache SkyWalking, an open‑source APM tool, offers non‑intrusive, lightweight, and feature‑rich monitoring, making it a popular choice for many backend teams.

Single‑node architecture consists of three core components: the Agent (mounted via -javaagent to collect trace, SQL, JVM metrics, and dependencies), the OAP Server (the "brain" that stores, analyzes, and alerts on data, using BanyanDB by default), and the UI (visualizes processed data such as service overview and trace panels). Data flows as follows: Business app (Agent) → gRPC → OAP Server → UI.

The extracted package contains the following directories: bin/: startup scripts (e.g., oapService.sh, webappService.sh) and environment file setEnv.sh. config/: application.yml for OAP storage, ports, and plugin switches. webapp/: UI resources and webapp.yml for UI port configuration. plugins/: optional Agent plugins such as Spring MVC or MyBatis adapters.

Deployment steps (SkyWalking 9.2.0 example) :

Download apache-skywalking-apm-9.2.0.tar.gz from the official site and extract to /opt/skywalking:

tar -zxvf apache-skywalking-apm-9.2.0.tar.gz -C /opt/skywalking

Adjust JVM parameters in bin/oapService.sh and bin/webappService.sh to avoid default memory limits.

Modify config/application.yml if a different storage (e.g., Elasticsearch 7+) is required.

Start services:

cd /opt/skywalking/bin
./oapService.sh start
./webappService.sh start

Verify startup logs for "Started OAPServer" and "Started WebApplication" messages, then open http://<em>host</em>:8080 to see the UI.

Core feature demonstration with the RuoYi application :

Attach the Agent by adding -javaagent:/path/to/skywalking-agent.jar to the JVM launch command.

After starting RuoYi, the UI shows a Service Overview panel displaying Apdex, success rate, average response time, and request per minute.

The Trace panel (via the "Trace" menu) allows filtering by service name and time range to view full call chains, pinpoint slow SQL (e.g., 500 ms), and view exception stacks.

The Service Topology panel visualizes inter‑service relationships, using green for healthy services and red for abnormal ones.

Typical issues encountered and solutions :

Class redefinition failed in IDE debug mode – Debug mode enables JPDA, which pre‑loads core classes (e.g., logback.LoggingEvent) and locks them, conflicting with the Agent’s bytecode enhancement that also relies on the Instrumentation interface. Solution: run the application without JPDA or disable hot‑swap during debugging.

No data shown on UI panels – The Agent was configured to use HTTP port 12800, while the OAP Server expects gRPC on port 11800 by default. Correct the Agent’s port configuration to match the OAP Server’s gRPC port.

In summary, SkyWalking’s single‑node deployment is lightweight and sufficient for small‑scale applications, provided that Agent plugins are enabled as needed and version consistency is maintained. For production environments, the architecture can be scaled to a cluster with multiple OAP nodes, persistent storage, and alert rules for proactive monitoring.