SkyWalking connects traces, metrics, and logs across many runtimes
Apache SkyWalking is an observability backend for distributed applications. Its README names actively maintained agents for Java, .NET, PHP, Node.js, Go, Lua, Rust, C++, browser JavaScript, and Python. The OAP server also accepts OpenTelemetry, Prometheus, Zipkin, Zabbix, Fluentd, and other telemetry formats. That breadth suits a platform shared by several teams, especially when one request crosses languages and infrastructure boundaries.
The system does more than store spans. It builds service topology, aggregates metrics, processes logs, runs alert rules, and exposes query APIs used by dashboards. Rover adds eBPF-based monitoring and profiling for Kubernetes workloads. BanyanDB is the project's purpose-built storage option, while Elasticsearch, OpenSearch, MySQL, and PostgreSQL are documented alternatives. Each added signal can help an investigation, but each receiver and data path also becomes another item to size and maintain.
Version 11 moves the web UI and changes the operating boundary
Release v11.0.0 arrived on 2026-08-28 and removes the bundled web application from the OAP distribution. Horizon UI now lives in apache/skywalking-horizon-ui, releases on its own schedule, and talks to both the public query surface and the admin host. There is no one-to-one version mapping between OAP and Horizon UI, so operators must pin compatible images and plan the two upgrades separately.
The same release moves status and debugging routes to the admin host and adds runtime rule updates plus a live DSL debugger. Those tools can inspect or change sensitive operational state. OAP exposes public agent gRPC on port 11800 and queries on 12800, while admin HTTP defaults to 17128 and peer admin gRPC to 17129. Network policy now carries more responsibility than it did when one bundled UI sat beside the backend.
What happened when we ran it
Our run cloned commit 4fe83aa into an unprivileged Java 21 container with 3 CPUs and 10 GB of RAM. Installation succeeded in 93 seconds. The build then completed in 446 seconds, followed by a successful 375-second test step. Maven Surefire counted 44 passed and 0 failed out of 44, with no failed stage hidden behind a partial summary.
The checkout contained 3,032 files and about 60,865 lines of source in 13.6 MB. Our signal scan found 5 CI workflow files, no Dockerfile, and a tests directory. These results cover repository installation, compilation, and the invoked test set. They do not measure telemetry ingestion, query latency, storage growth, agent overhead, or cluster recovery, so capacity claims from another deployment should not be transferred to yours.
A 446-second successful build fits the build guide's warning that SkyWalking has many Maven modules. GitHub source builds also require initialized submodules, which is why the project advises against compiling the automatically generated source archives on the GitHub release page. The supported build route uses Maven 3.6 or newer and JDK 11, 17, 21, or 25; official Apache source archives include the needed source without Git submodule setup.
Port 17128 needs an authenticating gateway before deployment
SkyWalking 11 enables admin-server by default and binds its HTTP host to 0.0.0.0:17128. The admin documentation says this port has no built-in authentication. Anyone who reaches it may access status, inspect data, manage UI templates, change runtime rules when enabled, or run debugging features that can capture raw log bodies. The prescribed controls are a private bind address, an IP allow-list, an authenticating reverse proxy, and audited proxy access.
Operators also need a private network for the 17129 gRPC bus between OAP nodes. Public telemetry belongs on 11800, and GraphQL or other public queries use 12800. Those separations are sensible, but a default container exposed with broad port mappings can defeat them. Teams should decide which admin modules are needed, disable the rest, and test that the public ingress cannot route to either admin port.
Storage choice determines what the team must operate
The backend guide recommends preparing a database before OAP starts and prefers BanyanDB. Docker Compose profiles cover BanyanDB and Elasticsearch for evaluation. SQL options are also supported, though the storage guide warns that MySQL and PostgreSQL can be slower for traces and logs and do not scale out linearly for that workload. An existing database standard therefore may matter more than the convenience of one selector in application.yml.
Configuration is modular: core, cluster, storage, query, receivers, and fetchers each select providers. Agents and probes point at the OAP address rather than appearing automatically. Retention, sampling, timezone, alarm rules, credentials, and database compatibility all need deliberate values. Open issue 14058 adds a current reason for regression coverage: its reporter found a latency-sorted trace query on version 11.0 and BanyanDB 0.11.0 returning spans outside a requested 30-minute window.
A September push and 42 open items indicate active maintenance
GitHub recorded 24,945 stars, 42 combined issues and pull requests, and a push on 2026-09-09. That date is 12 days after v11.0.0, and issue activity on the same day includes the backend and BanyanDB. The open count includes proposed work and pull requests, so it should not be read as 42 defects. The release notes themselves document breaking changes, security boundaries, migrations, and dependency updates in unusual detail.
SkyWalking is a credible choice for an organization that wants one self-hosted view across many service types and has an observability team to own it. Jaeger is easier to justify for tracing alone. OpenTelemetry Collector Contrib is better when the collection layer must stay separate from storage and analysis, while SigNoz offers another integrated OpenTelemetry-centered route. Our passing 44-test result removes one source-build worry; it does not reduce the operating scope of OAP, storage, agents, UI, and protected admin networks.