Apache Software Foundation APM and observability analysis platform for distributed systems, microservices, cloud-native, and service mesh environments.
Apache SkyWalking is a mature, enterprise-grade observability platform designed for distributed system, microservice, and cloud-native architectures. Governed by the Apache Software Foundation (ASF), it provides APM, distributed tracing, metrics, logging, event analysis, and topology visualization. Its architecture is highly pluggable, with BanyanDB as its native purpose-built observability database.
What is the production-ready BanyanDB cluster sizing guidance for 100B+ data points? — No published sizing guide at 100B+ scale yet. The official benchmark (BanyanDB v0.6.1) tested with 3 Data Nodes (8 CPU, 4 GB RAM, 50 GB storage each), 3 ETCD/Meta Nodes (2 CPU, 4 GB), and 2 Liaison Nodes (4 CPU, 4 GB), showing ~50% less CPU, ~50% less memory, and ~40% less disk vs Elasticsearch at similar scale. BanyanDB is still recommended for "medium-scale deployments" until v1.0. For 100B+ data points, expect to scale Data Nodes horizontally and increase storage significantly; consult the SkyWalking dev mailing list for community guidance.
How does BanyanDB handle cross-datacenter replication? — Cross-datacenter replication is not currently supported. BanyanDB v0.8.0 added data file snapshotting for backups and periodic metadata sync from etcd to local cache, but active-active or cross-DC replication is not in the current feature set. Multi-region deployments would require operating independent BanyanDB clusters per datacenter. Check the BanyanDB roadmap on GitHub for future plans.
What is the GraalVM Distro coverage for all OAP modules? — GraalVM support is limited and separated into the standalone skywalking-graalvm-distro project (see Issue 11518). Due to the complexity of the GraalVM ecosystem and native-image constraints (reflection, class loading, dynamic agents), only a subset of OAP modules are supported — primarily core storage (BanyanDB) and basic receiver functionality. Many modules that rely on JVM-specific features (Java agent instrumentations, dynamic classloading) are excluded. Coverage is expanding incrementally.
How does the v10.4.0 LAL breaking change (slowSql {} removal) affect existing deployments? — The slowSql LAL filter was removed as part of LAL engine refactoring in the 10.x line. Existing deployments using slowSql {} in their LAL scripts will fail to parse on upgrade. Migration requires replacing slowSql() calls with generic LAL primitives: use json() or regex() for SQL extraction from logs, and tag() for setting relevant tags. Alternatively, use SkyWalking's native database slow SQL monitoring which now captures slow statements automatically without LAL parsing. The built-in LAL files (mysql-slowsql, pgsql-slowsql, redis-slowsql) were updated to use the new syntax. Resolved in observability/skywalking/operations#v10.4.0 Migration Notes.
What is the practical throughput ceiling for Rover eBPF agent vs Coroot's node-agent? — No direct benchmark comparison exists. SkyWalking Rover uses eBPF for CPU profiling (on-cpu/off-cpu) and network profiling (TCP/HTTP traffic), with default 10-minute monitoring windows and 20-minute cooldown periods to limit overhead. It targets diagnostic/triggered profiling rather than continuous high-throughput collection. Coroot's node-agent also uses eBPF but focuses on continuous metrics collection. A direct throughput comparison has not been published by either project. Benchmark comparison remains TBD.
What storage backend should I use? → BanyanDB (recommended), uses 5x less RAM and 30% less disk than Elasticsearch. See observability/skywalking/architecture.