Apache SkyWalking — Distributed APM & Observability Platform

What it is

Apache SkyWalking is an open-source Application Performance Monitoring (APM) platform that unifies distributed tracing, metrics collection, log aggregation, and eBPF-based profiling. It supports auto-instrumentation for Java, Python, Go, Node.js, and other languages. SkyWalking provides topology maps of service dependencies and deep drill-down into individual trace spans.

SkyWalking is designed for platform teams and SREs managing microservice architectures who need end-to-end observability without the cost of commercial APM tools.

How it saves time or tokens

Commercial APM tools (Datadog, New Relic) charge per host or per GB of data. SkyWalking provides equivalent functionality as a self-hosted solution at zero licensing cost. Auto-instrumentation means you add observability to Java, Go, or Node.js services without changing application code. The unified platform replaces separate tools for tracing (Jaeger), metrics (Prometheus), and profiling (pprof) with a single integrated system.

How to use

1. Start SkyWalking OAP server and UI:

docker run --name skywalking-oap -d \
  -p 11800:11800 -p 12800:12800 \
  apache/skywalking-oap-server:latest

docker run --name skywalking-ui -d \
  -p 8080:8080 \
  -e SW_OAP_ADDRESS=http://skywalking-oap:12800 \
  apache/skywalking-ui:latest

1. Instrument a Java application (zero code changes):

java -javaagent:skywalking-agent.jar \
  -Dskywalking.agent.service_name=my-service \
  -Dskywalking.collector.backend_service=localhost:11800 \
  -jar my-app.jar

1. Open http://localhost:8080 to view traces, metrics, and service topology.

Example

SkyWalking auto-detects service dependencies and generates topology maps:

                    ┌─────────┐
                    │ Gateway │
                    └────┬────┘
               ┌─────────┼─────────┐
         ┌─────┴────┐  ┌─┴────┐  ┌─┴──────┐
         │ User Svc │  │Order │  │Payment │
         └─────┬────┘  │ Svc  │  │  Svc   │
               │       └──┬───┘  └────┬───┘
         ┌─────┴────┐     │           │
         │  MySQL   │  ┌──┴───┐  ┌────┴───┐
         └──────────┘  │Redis │  │ Stripe │
                       └──────┘  └────────┘

Click any service or connection to drill down into traces, latency percentiles, and error rates.

Related on TokRepo

• Monitoring tools — Browse observability and APM tools
• DevOps tools — Explore infrastructure monitoring

Common pitfalls

• Not configuring storage for production. The default in-memory storage loses data on restart. Use Elasticsearch, BanyanDB, or PostgreSQL for persistent trace and metric storage.
• Instrumenting too many services at once. Start with the most critical services, verify traces appear correctly, then expand instrumentation to other services.
• Ignoring the sampling rate. In high-traffic systems, tracing every request generates massive data volumes. Configure sampling rates appropriate for your traffic volume.
• Starting with an overly complex configuration instead of defaults. Begin with the minimal setup, verify it works, then customize incrementally. This approach catches configuration errors early and keeps troubleshooting straightforward.