name: resource-contention-skill description: Identify per-host resource and load faults — sender or receiver resource contention, sender application delay, web DoS attack. Use when a host shows stress/flood-tool processes, CPU spikes, TCP socket spikes, or slow localhost responses while same-role peers stay clean. metadata: version: "1.0.0"

Resource Contention and DoS

What counts as direct evidence

A stress_tool / http_flood_tool entry means a RUNNING process surfaced by pressure_sweep. Installed binaries without a running process do not count.

One direct probe on the candidate to confirm ownership is enough — do not chain extra investigations once the family is confirmed.

Not host_crash

host_crash means the container was killed/stopped/removed: no response at all, same-role peers clean. An isolated exec_failed/timeout on one web/app server while ICMP still answers is sender_resource_contention, not host_crash. Do not require seeing stress-ng in ps after the container is already too loaded to answer process probes.

Not load_balancer_overload

Stay here only when the pressure signal is on a non-LB backend or client. If the flagged device is the load balancer, use load-balancer-skill.

sender_resource_contention vs sender_application_delay

Both produce a slow backend. sender_resource_contention requires a resource signal (stress_tool, cpu_hot_process, cpu_hot_service_daemon, tcp_estab_spike, or an isolated exec timeout). sender_application_delay fires only when the backend is slow AND no resource signal is present. If any resource flag fires, it is NOT sender_application_delay.

stress_tool vs http_flood_tool

stress_tool consumes local CPU/memory — the faulty device is the host running it. http_flood_tool drives abusive traffic at a victim — the faulty device is the victim, not the attacker.