Apache SkyWalking

Last reviewed Aug 26, 2026 · 810 words

For a homelab of 20 Docker containers, SkyWalking is the wrong tool, and I would rather say so in the first sentence than after you have spent a weekend on it. For a company running 15 or more services, most of them on the JVM, it is one of the cheapest exits from Datadog or New Relic that exists: a Java agent that instruments without code changes, distributed tracing, metrics, logs, a live service topology map and an alerting engine, all Apache-2.0 with Apache Software Foundation governance behind it. The price is a 2 GB memory floor before you add storage, a difficulty rating of Hard that is earned, and a storage backend you must choose and operate.

Three processes, and the third is a decision

SkyWalking (Java, 24,930 stars, around since 2015) runs as an OAP server that receives and analyses telemetry, a UI that queries it, and a storage backend. The OAP listens on 11800 for gRPC from agents and 12800 for its HTTP and GraphQL API; the UI serves on 8080. Storage is where the operational weight lands. BanyanDB is the project's own purpose-built database and the direction the project is heading. Elasticsearch and OpenSearch are the long-standing production choice with the most mileage. PostgreSQL and MySQL work for modest volumes. H2 runs in memory and is for a demo that you will throw away by Friday. A minimal Elasticsearch-backed stack:

services:
  oap:
    image: apache/skywalking-oap-server:latest
    environment:
      SW_STORAGE: elasticsearch
      SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200
      SW_HEALTH_CHECKER: default
    ports: ["11800:11800", "12800:12800"]
    depends_on: [elasticsearch]
  ui:
    image: apache/skywalking-ui:latest
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    ports: ["8080:8080"]

Add an Elasticsearch or OpenSearch service with at least 2 GB of heap, and budget 4 to 6 GB for the whole stack before any traffic arrives. The reason to do this at all is the next section.

The Java agent is why people choose it

Drop the agent jar next to the application and add one JVM flag:

java -javaagent:/skywalking/agent/skywalking-agent.jar \
  -Dskywalking.agent.service_name=orders \
  -Dskywalking.collector.backend_service=oap:11800 \
  -jar orders.jar

That is the entire integration for Spring, Tomcat, JDBC, Kafka clients, Redis clients and a long list of libraries the agent knows how to hook. Within a minute the topology map draws the service, the database it calls and the queue it publishes to, with latency percentiles and error rates per endpoint. No code was touched. Agents exist for Python, Node.js, Go, PHP, Rust and .NET too, with varying depth; the Java one is the mature centre of the project, and if your estate is mostly Go or Node, that changes the recommendation below.

OpenTelemetry in, but not the native path

SkyWalking accepts OTLP metrics and traces from an OpenTelemetry Collector, and it accepts Zipkin traces, so a polyglot shop that has already instrumented with OTel can point the collector at it. Be honest with yourself here: if your telemetry is OTel-native and your services are not Java, SigNoz is built around OTLP as its first language, stores in ClickHouse, and will feel more natural. SkyWalking's own agents produce richer data in its own model than OTel translation does. The eBPF profiler, Rover, and the network-level profiling are genuinely distinctive and worth a look for kernel-level latency questions, but they are a second-month project, not a first-week one.

The learning curve is three small languages

What makes the Hard rating true is not the install. It is that metrics, logs and alerting are defined in SkyWalking's own scripting languages: OAL for metrics derived from traces, MAL for metrics arriving from Prometheus-style sources, LAL for log processing, with alarm rules in YAML on top. The defaults are extensive and most teams never edit them, but the first time you want a custom metric or a smarter alert, you are reading documentation for a domain-specific language nobody on your team has used. The UI has the same character: dense, complete, and organised around SkyWalking's concepts rather than the ones Grafana taught you. Plan for one person to own it.

What I'd do

If the estate is mostly Java and the monthly APM invoice has a comma in it, run SkyWalking on a dedicated 8 GB VM or a small Kubernetes namespace via the Helm chart, back it with OpenSearch you already know how to operate, and start with the Java agent on 2 services to see the topology map earn its keep. If the estate is polyglot and already emits OTLP, pick SigNoz. If this is a homelab, look at the monitoring category for something that idles in 100 MB and answers the question you actually have, which is usually "is it up".