ayaFlow

ayaFlow ist ein Netzwerkverkehrsanalysator in Rust + eBPF, erstellt mit Aya. Es führt einen Agenten pro Linux-Knoten aus, bindet einen TC-Klassifikator am Eingang und Ausgang und stellt Live-Verkehrsdaten, historische, SQLite-gestützte Verläufe und Prometheus-Metriken zur Verfügung.

Was es tut

• Erfasst IPv4-, IPv6-, TCP- und UDP-Verkehr mit einem eBPF-TC-Klassifikator.
• Hält Live-Verbindungsstatistiken im Speicher und historische Aufzeichnungen in SQLite.
• Reichert optional Verkehr mit Reverse-DNS, DNS-Abfragedomänen und TLS-SNI an.
• Stellt eine REST-API, einen WebSocket-Stream und einen Prometheus-/metrics-Endpunkt bereit.
• Wird mit Beispielen für Docker, Kubernetes, Prometheus und Grafana ausgeliefert.

Unterstützter Entwicklungsablauf

Die Paketerfassungslaufzeit von ayaFlow ist nur unter Linux verfügbar. Die Arbeitsabläufe für Mitwirkende sind bewusst aufgeteilt:

• Host-sichere Prüfungen auf macOS oder Linux:
  • cargo test -p ayaflow-common
  • cargo test -p ayaflow
  • cargo xtask build-user
  • cargo xtask check-host
• Nur-Linux-Build und -Laufzeit:
  • cargo xtask build-ebpf
  • cargo xtask build
  • cargo xtask run -- --deep-inspect

Wenn Sie auf macOS sind, verwenden Sie Docker oder eine Linux-VM für den vollständigen eBPF-Workflow. Siehe HOW_TO_USE_LOCAL.md für beide Pfade.

Schnellstart

1. Host-Unterstützung prüfen

cargo xtask check-host

2. Unter Linux bauen

cargo xtask build

3. Unter Linux ausführen

sudo ./target/debug/ayaflow --db-path /tmp/traffic.db

Wenn --interface weggelassen wird, erkennt ayaFlow die Standard-Routenschnittstelle aus /proc/net/route automatisch und fällt nur dann auf eth0 zurück, wenn die Erkennung fehlschlägt.

4. Überprüfen

curl http://localhost:3000/api/health
curl http://localhost:3000/api/stats
curl "http://localhost:3000/api/history?limit=5&row_type=raw"
curl http://localhost:3000/metrics

CLI-Optionen

API-Referenz

/api/history unterstützt:

• limit, offset
• start_time, end_time
• protocol
• ip, src_ip, dst_ip
• port, src_port, dst_port
• direction
• domain
• row_type=raw|aggregated

Beispiel:

curl "http://localhost:3000/api/history?limit=20&protocol=TCP&dst_port=443&row_type=raw"

Projektstruktur

ayaflow/           Benutzerraum-Laufzeit, API, Speicher und host-sichere Tests
ayaflow-common/    Gemeinsame Paket-/Ereignistypen, die von Benutzerraum und eBPF verwendet werden
ayaflow-ebpf/      TC-Klassifikator und Nutzlast-Erfassungsprogramm
xtask/             Build- und Workflow-Helfer
k8s/               Kubernetes-Manifeste
monitoring/        Prometheus- und Grafana-Assets

Der doppelte src/-Baum auf Stammebene ist veraltet und nicht Teil des unterstützten Build-Pfads. Verwenden Sie die ayaflow/-Crate und die oben genannten cargo xtask-Befehle.

Bereitstellungsanleitungen

• Lokale Linux- und macOS+VM-Workflows: HOW_TO_USE_LOCAL.md
• Docker: HOW_TO_USE_DOCKER.md
• Kubernetes: HOW_TO_USE_K8S.md

Technische Dokumentation

• Architektur: ARCHITECTURE.md
• Speicher- und Leistungshinweise: PERFORMANCE.md

Hier getestet

Der host-sichere Workflow besteht nun auf diesem macOS-Entwicklungsrechner mit:

• cargo test -p ayaflow-common
• cargo test -p ayaflow
• cargo xtask check-host

Die Nur-Linux-Laufzeitvalidierung muss noch auf einem Linux-Host oder CI-Runner mit installierter eBPF-Toolchain durchgeführt werden.

Lizenz

Dieses Projekt verwendet je nach Komponente drei verschiedene Lizenzen:

Benutzerraum-Komponenten

Der Benutzerraum-Agent und die gemeinsamen Bibliotheken (ayaflow und ayaflow-common) sind unter einer der folgenden Lizenzen dual-lizenziert:

• Apache License, Version 2.0
• MIT License

nach Ihrer Wahl.

Kernel-Komponenten

Die eBPF-Kernel-Komponenten (ayaflow-ebpf) sind streng unter der GNU General Public License v2.0 (GPL) lizenziert, um die Kompatibilität mit dem Linux-Kernel-Verifier zu gewährleisten.