Steadybit logoResilience Hub
Try SteadybitGitHub icon
Steadybit logoResilience Hub

Create Muting Rule

Attack

Attack

Creates a muting rule in New Relic.
Install now

Create Muting Rule

Creates a muting rule in New Relic.
Attack

Attack

Install now

Create Muting Rule

Attack

Attack

Creates a muting rule in New Relic.
Install now

Create Muting Rule

Creates a muting rule in New Relic.
Attack

Attack

Install now
Go back to list
YouTube content is not loaded by default for privacy reasons.

Introduction

When executing chaos experiments, you may want to mute your alerts not to bother your ops colleagues. You can do this with this action.

To create a muting rule the step can be dragged&dropped into the experiment editor.

Use Cases

  • Avoid false positives in your monitoring system
  • Avoid alerting your ops colleagues during chaos experiments
  • Avoid to distract your baselines during chaos experiments

Parameters

ParameterDescriptionDefault
DurationHow long should the maintenance window exist?30s
Statistics
-Stars
Tags
New Relic
Check
Observability
Monitoring
Homepage
hub.steadybit.com/extension/com.steadybit.extension_newrelic
License
MIT
MaintainerSteadybit
Install now

Useful Templates

See all
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
Crash loop
New Relic
Harden Observability
Kubernetes

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
New Relic
Harden Observability
Kubernetes

Containers

Kubernetes cluster

New Relic Accounts

New Relic Workloads

More New Relic Account Actions

See all
Start Using Steadybit Today

Get started with Steadybit, and you’ll get access to all of our features to discover the full power of Steadybit. Available for SaaS and on-prem!

Are you unsure where to begin?

No worries, our reliability experts are here to help: book a demo with them!

Steadybit logoResilience Hub
Try Steadybit
© 2024 Steadybit GmbH. All rights reserved.
Twitter iconLinkedIn iconGitHub icon