wu-sheng commented on code in PR #761: URL: https://github.com/apache/skywalking-banyandb/pull/761#discussion_r2332247229
########## docs/ebpf-sidecar-design.md: ########## @@ -0,0 +1,605 @@ +# eBPF Sidecar Design Document + +## 1. Executive Summary + +The eBPF Sidecar Agent is a kernel-level observability component for Apache SkyWalking BanyanDB that primarily monitors **page cache miss rates** - a critical metric for database performance. High cache miss rates indicate that BanyanDB is frequently reading from disk instead of memory, directly impacting query latency and throughput. By tracking these metrics at the kernel level, we can identify performance bottlenecks and optimize storage patterns. + +### Primary Goal +**Monitor and reduce page cache miss rates in BanyanDB** by providing real-time visibility into: +- Page cache hit/miss ratios during database operations +- Correlation between fadvise() hints and actual cache behavior +- Memory pressure impact on cache eviction rates + +### Key Features +- **Page cache miss tracking**: Direct monitoring of cache efficiency +- **fadvise() effectiveness**: Measure if BanyanDB's cache hints work as expected +- **Zero-instrumentation monitoring**: No modifications required to BanyanDB +- **Minimal performance overhead**: Kernel-level data collection with < 1% CPU usage +- **Production-ready**: Memory-efficient design with clear-after-read strategy + +## 2. Architecture Overview + +### 2.1 High-Level Architecture + +``` +┌─────────────────────────────────────────────────────────┐ +│ User Applications │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ BanyanDB │ │ Prometheus │ │ Grafana │ │ +│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ +└─────────┼──────────────────┼──────────────────┼─────────┘ + │ Native Export │ Scrape │ Query + ▼ ▼ ▼ Review Comment: Why does Grafana even get involved? This seems unreasonable. Query from Grafana should go to Prometheus. And if Prometheus needs to scrape metrics from BanyanDB, please do via BanyanDB Prometheus endpoint directly. There is no point to propagate and store metrics in two places. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
