Apache SkyWalking: an APM backend for microservices, and how to run it

The gap SkyWalking fills: one backend across many runtimes

Most teams end up with tracing in one place, metrics in another, and logs in a third. SkyWalking's pitch is that all three land in one system, and that the system understands services, deployments and APIs as first-class objects rather than as tags on spans. The README describes it as an APM system "especially designed for microservices, cloud native and container-based architectures", and the feature list backs that framing: service topology analysis, service-centric observability, and API dashboards.

The second half of the pitch is breadth of instrumentation. The README lists agents for Java, .Net Core, PHP, NodeJS, Golang, LUA, Rust, C++, client JavaScript and Python. That matters more than it sounds. If you have a Java service calling a Go service calling a Node service, a single-vendor agent strategy usually leaves a hole somewhere. SkyWalking's answer is to own the agent for each runtime rather than asking you to standardise on one.

Who this is for: platform teams running a service mesh or a large Kubernetes estate, who are willing to run a dedicated backend and a database for it. Who it is not for: a single application that needs a trace view, where an agent plus a hosted backend is a smaller commitment.

How the pieces fit: agents, OAP, and BanyanDB

The repository layout tells you the architecture before the docs do. oap-server/ is the backend (OAP, the Observability Analysis Platform). apm-protocol/ holds the wire definitions that agents and receivers speak. apm-dist/ and dist-material/ produce the distribution archives. docker/ holds the images. tools/ and test/ sit alongside them, and benchmarks/ exists as its own top-level entry.

Data flow is therefore: an agent or a receiver (Zipkin, OpenTelemetry, Prometheus, Zabbix, Fluentd are named in the README) sends telemetry to OAP; OAP runs it through a script pipeline; the result is stored and queried. The README is explicit that native SkyWalking meter formats and widely known formats such as OpenTelemetry, Telegraf and Zabbix "are processed through the same script pipeline". That is the design bet: one processing path, many ingestion formats, so a metric from a Telegraf agent and a metric from a SkyWalking agent are handled by the same machinery rather than by two separate subsystems.

Storage is where SkyWalking differs from most tracing tools. BanyanDB is described in the README as "an observability database, created in 2022", which ingests, analyses and stores telemetry data. Running your own storage engine is a real operational cost, and it is also why release notes for v10.3.0 talk about a new trace model in BanyanDB: the storage format is still moving.

The eBPF story is separate from the agent story. The Rover agent, described as an "eBPF early adoption", works as a monitor and profiler for Kubernetes deployments, aimed at CPU and network diagnosis. The README itself calls it early adoption, which is a fair signal about where to place it in your rollout order.

Installing SkyWalking from the release archive and sending a first trace

The README does not walk through installation. It points at the releases page for downloads and at docs/en/guides/How-to-build.md for compiling from source, so the fastest path for a first look is the released distribution rather than a source build. The build guide is the right reference if you need a custom distribution.

If you do build from source, the Makefile at the repository root is the entry point. It wraps the Maven wrapper, and it initialises git submodules first, which the build needs:

make init
make build.all

build.all runs ./mvnw --batch-mode clean package with the test skip controlled by the SKIP_TEST variable, which defaults to false. There is also a backend-only target, make build.backend, which adds the backend and dist Maven profiles and produces a smaller artefact set. For a container image, the Makefile chains the three steps:

make docker

That target runs init, then build.all, then the docker targets. The image name, tag and archive are all variables: HUB defaults to skywalking, OAP_NAME to oap, DATA_GENERATOR_NAME to data-generator, TAG to latest, and DIST to apache-skywalking-apm-bin.tar.gz. The Docker build context defaults to the dist directory under the repository root.

Once OAP is running, instrumenting an application means attaching the agent for that runtime and pointing it at the OAP endpoint. The README lists the agents but does not print their configuration keys, so take the agent options from the official documentation rather than from this page. The first thing to look at after a service reports in is the service topology and the service-centric dashboard, because those are the views the README names as the core of the product.

Where SkyWalking is the wrong tool

The clearest limitation is operational weight. SkyWalking is not a library you add and forget. You run OAP, you run storage, and you keep both healthy. The README's own scaling claim, that "100+ billion telemetry data could be collected and analyzed from one SkyWalking cluster", describes a system that is expected to be a cluster, not a sidecar. If your team has no one who wants to own a stateful backend, this is the wrong choice regardless of features.

The second limitation is version skew between the backend and the agents. SkyWalking ships agents for ten runtimes. Those agents are separate artefacts with their own release cadence, and the backend has its own protocol version. The README does not document a compatibility matrix, and the release notes show the backend moving quickly: v10.3.0 changed the trace model in BanyanDB, v10.4.0 is titled around a Groovy-free runtime and Grafana Tempo compatibility, and v11.0.0 advertises runtime rule hot-update and a live DSL debugger. Frequent backend releases are good for capability and bad for anyone who wants to pin and forget.

The third is scope. If you need only distributed traces and you already run a collector, SkyWalking adds a full analysis layer you may not use. The README's feature list is long, and long feature lists are a cost when you adopt three of them.

SkyWalking compared with Jaeger and Prometheus

The comparison people actually search for is SkyWalking against Jaeger and against Prometheus, and the difference is architectural rather than a matter of feature counts.

Jaeger is a tracing system. Its job is to receive spans, store them, and let you query them. SkyWalking's job, as the README frames it, is APM: tracing plus service topology plus service-centric dashboards plus metrics plus a log pipeline plus alerting. If you already have metrics and logs solved and only need trace storage, Jaeger is the smaller thing to run. If you want one backend where a trace, the metric baseline for the same service, and the related log line are all reachable, that is the problem SkyWalking is built for.

Prometheus is a metrics system with a pull model and its own query language. SkyWalking is not a replacement for it in the sense of scraping: the README lists Prometheus among the ecosystems whose metrics it supports, and lists Telegraf and Zabbix the same way. The interesting detail is the shared script pipeline, which processes SkyWalking native meter formats and these external formats through the same path. That is a different design from running a separate bridge per source.

One more difference worth naming: storage. SkyWalking has BanyanDB, and the README describes it as created in 2022 for ingesting, analysing and storing telemetry data. Choosing SkyWalking means choosing to evaluate that engine, not just the agent.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-20, one day before this writing. Releases are frequent: v10.3.0 in November 2025, v10.4.0 in April 2026, v11.0.0 in August 2026. Cadence like that cuts both ways. Security fixes and new capabilities arrive quickly; so do changes to storage models and runtime internals, which is what an upgrade plan has to absorb.

The upgrade surface is wider than a single binary because SkyWalking has three independently versioned things: the OAP server, the storage engine, and each language agent. The v10.3.0 note about a new trace model in BanyanDB is the kind of change that makes a storage migration a planning item rather than a routine restart. The v10.4.0 title mentions a Groovy-free runtime, which implies that rules written against the older runtime may need review. There is a changes/ directory at the repository root, and that is where release-to-release detail lives; the README itself says nothing about upgrade procedures.

Licensing is straightforward to state and worth stating precisely: SkyWalking is Apache-2.0, and the LICENSE and NOTICE files are at the repository root. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes a patent grant. It also carries attribution obligations, which is why the NOTICE file exists. That is a description of the licence text, not legal advice; if you redistribute SkyWalking inside a product, have your own counsel read the NOTICE requirements rather than relying on a summary.

Editorial conclusion

Adopt SkyWalking if you run many services across several languages and want tracing, metrics, logs and alerting in one backend with its own storage engine. Do not adopt it if you only need trace storage for one or two services, or if you will not operate a separate OAP cluster and database. Before committing, verify two things yourself: which storage implementation you will run (the README names BanyanDB as the native APM database, and the docs cover the alternatives), and which agent version matches each runtime you deploy, because the agent list spans Java, .NET Core, PHP, NodeJS, Golang, LUA, Rust, C++, client JavaScript and Python and those agents are released on their own schedule.

Frequently asked questions

Official sources

1. apache/skywalking on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases