http-log-stats

HTTP Access Log Statistics

Answers measurement questions about HTTP traffic: how many of each status code, how the request durations distribute, how many exceeded a threshold.

This is deliberately separate from ingress-debug, which diagnoses why traffic fails (404 / 502 / TLS / no ADDRESS). Here nothing is broken necessarily — the user wants numbers.

Before you run it: identify the layer

A request usually passes through several components that can each return a status code, and the user's word for the one they mean ("router", "gateway", "entry", "网关") rarely maps to exactly one of them. Counting on the wrong layer produces a confident, wrong answer, so establish the path first:

kubectl get ingress,svc,endpoints -n <ns> | grep <service>

• An Ingress in front → the user's "router 503" is almost certainly the ingress controller's access log. Use this skill.
• No Ingress, traffic reaches the Service directly → there is no access log to count; the numbers must come from the application's own logs or metrics, and the format is application-specific.
• Do not grep the application pod's log for the string 503. Application logs contain the digits 503 in request bodies, upstream error text and unrelated fields; that count is not the number of HTTP 503 responses the entry layer returned.

This step costs one command and routinely saves the entire investigation.

Tool

local_script: cluster="<cluster>", skill="http-log-stats",
              script="http-log-stats.sh", args="<args>"

Runs kubectl from the agent's own context — no debug pod, no node access.

Set cluster to the target cluster's credential name (from cluster_list). local_script resolves it to a kubeconfig and exports KUBECONFIG into the script's environment, so the kubectl calls inside the script pick it up automatically. You may omit it only when the agent is bound to exactly one cluster; with several bound, omitting it is an error listing the available names, not a silent default.