Kmesh observability current archtecture for workload mod
kmesh need to implement in both go-controller and kmesh ebpf code to achieve the observability feature
the Kmesh eBPF submit metrics to go-controller throuth generated logs and stored in bpf maps. And current metrics includes:
connection_opens // The total number of TCP connections opened
connection_closes // The total number of TCP connections closed
received_bytes // The size of total bytes received during request in case of a TCP connection
sent_bytes // The size of total bytes sent during response in case of a TCP connection
duration // The duration of a request being processed
destination // The destination ip address
source // The source ip address
2. Expected archtecture for ADS mod
In ADS mod, we might need to expose L7 Metrics (refer to Envoy L7 metrics):
source_service // source service name: e.g. productpage.default.svc.cluster.local
destination_service // destination service name: e.g. reviews.default.svc.cluster.local
request_protocol // http request protocol: e.g. http 1.1
http_request_path // e.g. /reviews
http_request_header // e.g. "Content-Type: application/json"
http_response_code // http response code: e.g. 200
Why is this needed:
We are going to land Kmesh ADS mod into production, and the observability feature is a hard requirement, so we need to get this done as soon as possible.
What would you like to be added:
kmesh need to implement in both go-controller and kmesh ebpf code to achieve the observability feature
the Kmesh eBPF submit metrics to go-controller throuth generated logs and stored in bpf maps. And current metrics includes:
2. Expected archtecture for ADS mod
In ADS mod, we might need to expose L7 Metrics (refer to Envoy L7 metrics):
Why is this needed:
We are going to land Kmesh ADS mod into production, and the observability feature is a hard requirement, so we need to get this done as soon as possible.