Create Muting Rule
Other
New Relic Accounts
Create Muting Rule
Other
New Relic Accounts
Go back to list
New Relic should detect a crash looping as problem
Verify that New Relic alerts you that pods are not ready to accept traffic for some time.
Motivation
Kubernetes features a readiness probe to determine whether your pod is ready to accept traffic. If it isn't becoming ready, Kubernetes tries to solve it by restarting the underlying container and hoping to achieve its readiness eventually. If this isn't working, Kubernetes will eventually back off to restart the container, and the Kubernetes resource remains non-functional.
Structure
First, check that New Relic has no critical events for related entities. As soon as one of the containers is crash looping, caused by the Steadybit attack crash loop, New Relic should detect this via an incident to ensure your on-call team is taking action.
Solution Sketch
- Kubernetes liveness, readiness, and startup probes
Kubernetes cluster
Kubernetes pods
New Relic Accounts
New Relic should detect a disrupted workflow when a workload is unavailable
Verify that New Relic alerts you to disruptions in your workflow, such as a critical deployment without pods ready to serve traffic.
Motivation
Kubernetes features a liveness probe to determine whether your pod is healthy and can accept traffic. If Kubernetes cannot probe a pod, it restarts it in the hope that it will eventually be ready. In case it is a critical deployment, New Relic workflow should alert on this disruption
Structure
First, check that the New Relic Workflow is marked as operational As soon as all pods of a workload aren't reachable, caused by the block traffic attack, New Relic should detect this by marking the workflow as disrupted and ensuring your on-call team is taking action.
Solution Sketch
- Kubernetes liveness, readiness, and startup probes
- New Relic Workflow
Containers
Kubernetes cluster
New Relic Accounts
New Relic Workloads
