> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alert-Rauschen reduzieren

> Anleitung für die Produktion, um ein Alerting-Setup auf die Benachrichtigungen zu reduzieren, auf die Ihr Team reagieren kann – geordnet danach, wie viel Rauschen jeder Schritt entfernt.

Eine neue Anwendung kann zu viele Alerts senden. Schwellenwerte werden festgelegt, bevor jemand den normalen Metrikbereich kennt, Trigger beobachten jeden Host und jeden Tag-Wert, und jede Benachrichtigung geht an einen Kanal. Innerhalb weniger Wochen beginnt das Team, diesen Kanal zu ignorieren, und kurz darauf deaktiviert jemand die Benachrichtigungen dafür.

Diese Seite ist der Optimierungsdurchgang, der das behebt. Die Schritte sind danach geordnet, wie viel Rauschen jeder entfernt, sodass ein Vorgehen von oben nach unten den größten Nutzen früh bringt. Die Mechanik der einzelnen Einstellungen finden Sie unter [Alerts optimieren](/alerting/tuning).

Die beiden Schritte, die üblicherweise die meisten Benachrichtigungen entfernen, sind [exakte Tag-Filter statt breiter Wildcards zu verwenden](#use-exact-tag-filters-or-send-a-dedicated-alert-metric) und [Tag-Werte auf eine kleine feste Menge zu begrenzen](#keep-tag-values-to-a-small-fixed-set). Beide verhindern, dass ein Trigger Alerts für Werte öffnet, die Sie nicht überwachen wollten.

## Das Ziel danach wählen, wie schnell jemand handeln muss

Der größte Teil des Benachrichtigungsrauschens entsteht dadurch, dass Alerts an einen Kanal gesendet werden, der mehr Dringlichkeit suggeriert, als sie haben. Wählen Sie das Ziel danach, wie schnell jemand handeln muss.

* **Kunden verlieren heute Nacht Geld oder Zugriff.** On-Call, etwa [PagerDuty](/application/integrations/pagerduty) oder [Opsgenie](/application/integrations/opsgenie).
* **Es wird schlimmer, aber noch ist nichts verloren.** Team-Chat, etwa [Slack](/application/integrations/slack).
* **Morgen ist wirklich in Ordnung.** E-Mail oder ein Chat-Kanal mit wenig Verkehr.
* **Nichts, weil es bereits bekannt ist.** Überhaupt kein notifier.

Jeder Trigger wählt seine eigenen notifier. Ein Trigger ohne notifier zeichnet seine Alerts weiterhin auf, Sie können eine Metrik also überwachen, ohne Benachrichtigungen zu senden.

Geben Sie Staging einen eigenen Kanal oder lassen Sie dessen Trigger ohne notifier. Staging-Alerts, die in einem Produktionskanal eintreffen, sind der schnellste Weg, einem Team beizubringen, diesen Kanal zu ignorieren.

## Jeden Trigger auf die Serie eingrenzen, die Sie tatsächlich meinen

Ein Trigger öffnet nicht einen Alert. Er öffnet einen Alert pro passender Serie. Ein Host-Trigger, der beim Standard-hostname `*` bleibt, erfasst jeden Host, der an die App meldet, sodass 30 Hosts, die gemeinsam einen Schwellenwert überschreiten, 30 Benachrichtigungen für ein Problem erzeugen.

Grenzen Sie den Umfang ein, bis die Benachrichtigung genau sagt, was betroffen ist:

* Ersetzen Sie `*` durch einen bestimmten hostname oder ein Präfix wie `web-*`. Tag-Werte akzeptieren Wildcards, `hostname=frontend*` grenzt einen Trigger also auf eine Maschinenklasse ein.
* Grenzen Sie Trigger für Fehlerrate und Antwortzeit auf einen einzelnen [namespace](/application/namespaces) ein, damit `web`, `background` und `admin` unterschiedliche Schwellenwerte und unterschiedliche Ziele tragen können.
* Fügen Sie ein Tag für die konkrete Ressource hinzu, die Sie interessiert, etwa einen einzelnen mountpoint statt jedes gemounteten Dateisystems.

## Exakte Tag-Filter verwenden oder eine dedizierte Alert-Metrik senden

Diese Einschränkung verursacht viele Support-Anfragen zu störendem Alerting, und es lohnt sich, sie zu verstehen, bevor Sie eine Metrik entwerfen.

Angenommen, Sie senden einen Counter namens `api_request`, versehen mit dem Tag `status`, damit Sie ihn nach `200`, `404` und `500` aufschlüsseln können. Wenn Sie nur an einem exakten Wert interessiert sind, etwa `status=500`, verwenden Sie diesen exakten Wert im Trigger. Das Problem beginnt, wenn Sie eine Gruppe von Werten wollen: alle `5xx`-Antworten, alles außer `200` oder jede fehlgeschlagene Antwort. Ein Tag-Filter kann keine Ausschlüsse oder Bereiche ausdrücken, und `*` passt auf jeden Wert dieses Tags. Ein Trigger mit breitem Wildcard kann Alerts für erfolgreiche Status neben Fehlern öffnen, und das meiste, was eintrifft, beschreibt eine korrekt funktionierende Anwendung.

Die Lösung ist, die Bedingung, bei der Sie alarmieren möchten, an der Stelle, an der Sie sie senden, zu einer eigenen Serie zu machen. Behalten Sie die getaggte Metrik, wenn sie für Charts nützlich ist, und senden Sie eine zweite, engere für das Alerting:

<CodeGroup>
  ```ruby Ruby theme={null}
  status_code = response.code.to_s

  # Useful for charts broken down by status.
  Appsignal.increment_counter("api_request", 1, :status => status_code)

  # Useful for alerting because it only increments for 5xx responses.
  Appsignal.increment_counter("api_request_failed", 1) if status_code.to_i >= 500
  ```

  ```elixir Elixir theme={null}
  status = response.status

  # Useful for charts broken down by status.
  Appsignal.increment_counter("api_request", 1, %{status: status})

  if status >= 500 do
    # Useful for alerting because it only increments for 5xx responses.
    Appsignal.increment_counter("api_request_failed", 1)
  end
  ```
</CodeGroup>

Konfigurieren Sie den Trigger anschließend so, dass er die engere Metrik verwendet:

```sh Shell theme={null}
appsignal-cli triggers create --app "MyApp" --environment production \
  --name "Server errors from the payment API" \
  --metric-name api_request_failed --kind Advanced --field counter \
  --comparison-operator ">" --condition-value 10 \
  --warmup-duration 3 --cooldown-duration 5 \
  --notifier-ids <NOTIFIER_ID>
```

Der Alert öffnet nun nur noch für die Bedingung, die eine Benachrichtigung senden soll. Entscheiden Sie das, während Sie die [benutzerdefinierte Metrik](/metrics/custom) schreiben, denn das ist einfacher, als die Metrik neu zu entwerfen, nachdem Alerts zu öffnen beginnen.

## Tag-Werte auf eine kleine, feste Menge begrenzen

Verwenden Sie niemals einen Wert als Tag-Wert, der pro Ereignis eindeutig ist. Request-IDs, Auftragsnummern, Kunden-IDs und Zeitstempel sehen alle wie nützlicher Kontext aus und verursachen alle dieselben zwei Probleme.

Jeder eindeutige Wert ist eine eigene Serie. Ein Trigger über diese Metrik öffnet einen Alert pro Wert, was eine unbegrenzte Anzahl von Alerts erzeugen kann. Tags mit hoher Kardinalität machen außerdem Metrik-Charts und Alerting schwer handhabbar.

Ein Tag-Wert sollte eine Handvoll Varianten haben, die Sie aus dem Gedächtnis aufzählen könnten. Taggen Sie zum Beispiel nach einer begrenzten Dimension wie `region` und nicht nach einer eindeutigen ID:

<CodeGroup>
  ```ruby Ruby theme={null}
  # A tag with a small set of values is safe to graph and alert on.
  Appsignal.increment_counter("order_processed", 1, :region => order.region)
  ```

  ```elixir Elixir theme={null}
  # A tag with a small set of values is safe to graph and alert on.
  Appsignal.increment_counter("order_processed", 1, %{region: order.region})
  ```
</CodeGroup>

Die Auftrags-ID ist bei einer Untersuchung weiterhin wichtig, legen Sie sie also in eine [Log-Zeile](/logging), wo hohe Kardinalität erwartet wird. Verwenden Sie Metrik-Tags für Dimensionen, nach denen Sie ein Chart gruppieren möchten. Die Referenz zu [benutzerdefinierten Metriken](/metrics/custom#metric-tags) enthält mehr zur Wahl von Tags, einschließlich dazu, überall dieselbe Kombination zu verwenden, wo Sie eine Metrik melden.

## Bei Raten alarmieren, nicht bei Zählwerten

Eine Fehleranzahl überschreitet einen festen Schwellenwert immer dann, wenn der Traffic wächst, und benachrichtigt Sie so an Ihrem geschäftigsten Tag, unabhängig davon, ob etwas nicht stimmt. Die Fehlerrate bleibt um 4 Uhr morgens und in der Spitze gleichermaßen aussagekräftig. Der Wechsel von einem Zählwert zu einer Rate ist oft die einzige Änderung, die aus einem nächtlichen Alert einen nützlichen macht.

Behalten Sie Zählwerte nur dort, wo jedes Auftreten zählt und das Volumen naturgemäß niedrig ist, etwa bei Fehlern in einem Zahlungsablauf.

## warm-up an die Veränderlichkeit der Metrik anpassen

warm-up ist die Zeit, die AppSignal wartet, bevor ein Alert geöffnet wird. Während dieser Wartezeit muss die Metrik – je nach Trigger – über oder unter dem Schwellenwert bleiben. Das filtert einminütige Ausreißer heraus, etwa einen langsamen deploy, eine Garbage-Collection-Pause oder einen neu startenden Host.

Legen Sie warm-up danach fest, wie stark sich die Metrik von Minute zu Minute verändert, und nicht danach, wie schwerwiegend die Metrik ist. Beginnen Sie für die meisten Produktions-Alerts mit null bis zwei Minuten. Verwenden Sie einen längeren warm-up nur dann, wenn eine Metrik häufig ausschlägt und sich schnell erholt. Speicher und Swap verändern sich allmählich, sie brauchen daher oft wenig oder keinen warm-up. Wenn Sie 30 oder 60 Minuten benötigen, um Benachrichtigungen zu reduzieren, prüfen Sie stattdessen Schwellenwert oder Umfang.

## cooldown verwenden, wenn eine Metrik nahe ihrem Schwellenwert bleibt

cooldown verhindert, dass ein Vorfall einen Strom von Öffnungs- und Schließbenachrichtigungen erzeugt, während eine Metrik den Schwellenwert wiederholt überschreitet.

Die meisten Trigger brauchen ihn nie. Die Ausnahme sind sich langsam verändernde Ressourcenmetriken, die einen längeren cooldown brauchen können: eine Festplatte nahe 80 % kann diese Linie mehrmals überschreiten, bevor jemand Platz freigibt, sodass sie ohne langen cooldown jedes Mal erneut alarmieren kann, wenn der Wert sich über und unter den Schwellenwert bewegt. Dreißig bis 60 Minuten verwandeln mehrere Benachrichtigungen in einen Alert, der offen bleibt, bis das Problem behoben ist.

## Den cooldown bei einem uptime monitor nicht erhöhen

Den cooldown zu erhöhen ist die übliche Lösung für einen Trigger, der wiederholt öffnet und schließt, aber hier ist es die falsche Lösung. Wenn ein [uptime monitor](/uptime-monitoring/setup) fehlschlägt, bedeutet das, dass der Endpoint nicht geantwortet hat. Die zweite Benachrichtigung zu unterdrücken macht die erste nicht weniger zutreffend.

Greifen Sie stattdessen zu warm-up. AppSignal prüft Ihren Endpoint jede Minute aus vier Regionen und verfolgt jede Region separat, sodass ein Ausfall bis zu vier Alerts öffnen kann und ein Netzwerkproblem zwischen einer einzelnen Region und Ihrem Endpoint einen Alert öffnet, während Ihre Anwendung gesund ist. Ein warm-up von mindestens einer Minute filtert diesen Fall heraus, ohne einen echten Ausfall zu verbergen.

## Jede Benachrichtigung soll sich selbst erklären

Alert-Müdigkeit hängt nicht nur davon ab, wie viele Benachrichtigungen eintreffen. Sie hängt auch davon ab, wie viel Arbeit es kostet, jede einzelne zu verstehen. Drei Felder liefern diesen Kontext:

**Name.** Sagen Sie, was falsch ist, nicht welche Metrik sich bewegt hat. Ein Trigger für eine benutzerdefinierte Metrik heißt zunächst **Custom metric**, und eine Liste von Triggern, die alle so heißen, lässt sich nicht triagieren.

**Beschreibung.** Behandeln Sie sie als Runbook. Kurz ist in Ordnung, aber das Feld unterstützt mehrere Absätze, Befehle und Links. Die nützlichsten Beschreibungen enthalten die Informationen, die eine reagierende Person sonst rekonstruieren müsste: die relevante Zahl („das Limit des Load Balancers ist 320"), die Gegenmaßnahmen in der richtigen Reihenfolge, einen Diagnoseschritt, wie lange die Behebung dauert und was die Ursache beim letzten Mal war.

**Dashboard.** Verlinken Sie das Dashboard, das die Metrik neben verwandten Metriken zeigt, damit die Benachrichtigung der reagierenden Person einen Ausgangspunkt für die Untersuchung gibt.

## Ihre Trigger planmäßig prüfen

Alert-Konfigurationen veralten. Trigger überleben die Vorfälle, die sie motiviert haben, Schwellenwerte für den Traffic des letzten Jahres passen nicht mehr, und in einem Trigger benannte Hosts werden ersetzt.

Fragen Sie etwa vierteljährlich für jeden Trigger: Hat er in den letzten 90 Tagen geöffnet, hat jemand darauf reagiert, hat er viele Alerts für einen Vorfall geöffnet, und ist sein Ziel noch das richtige? Ein Alert, auf den niemand reagiert, sollte nachjustiert, umgeleitet oder archiviert werden.

Das gesamte Set zu prüfen geht vom Terminal aus schneller als durch das Öffnen jedes einzelnen Triggers:

```sh Shell theme={null}
# Every trigger, as JSON you can diff, grep, or hand to an agent
appsignal-cli --output json triggers list --app "MyApp" --environment production

# Narrow to one metric or one kind when you are hunting duplicates
appsignal-cli triggers list --app "MyApp" --environment production --metric-name response_time
```

Das Nachjustieren ist ein einzelner Befehl, aber Updates benötigen die vollständige Trigger-Definition. Beginnen Sie mit den aktuellen Werten aus `triggers list`, ändern Sie die Felder, die Sie nachjustieren möchten, und geben Sie optionale Werte an, die Sie behalten wollen, etwa notifier-IDs, Tags und den Dashboard-Link:

```sh Shell theme={null}
appsignal-cli triggers update --id <TRIGGER_ID> --app "MyApp" --environment production \
  --name "Slow web requests" \
  --metric-name response_time --kind Advanced --field p95 \
  --comparison-operator ">" --condition-value 750 \
  --warmup-duration 5 --cooldown-duration 5 \
  --notifier-ids <NOTIFIER_ID>
```

Das Ändern von Trigger-Einstellungen kann den aktiven Alert-Zustand beeinflussen, justieren Sie einen Trigger also nicht nach, während Sie einen offenen Alert für die Reaktion auf einen Vorfall nutzen.

Das Archivieren eines Triggers schließt auch dessen Alerts und Incidents, was für einen Trigger nützlich ist, auf den niemand reagiert:

```sh Shell theme={null}
appsignal-cli triggers archive --id <TRIGGER_ID> --app "MyApp" --environment production
```

Der [MCP server](/mcp-server) bietet denselben Lese- und Schreibzugriff auf Trigger, sodass Sie einen Agenten bitten können, jeden Trigger aufzulisten, der in 90 Tagen nicht geöffnet hat, und vorzuschlagen, was archiviert werden soll. Alle Flags finden Sie in der Referenz zur [AppSignal CLI](/cli/triggers).

## Wie AppSignal auf AppSignal alarmiert

Wir betreiben AppSignal auf AppSignal, und unser Operations-Team optimiert dieses Setup seit Jahren. Seine Form ist ein sinnvolles Ziel, das Sie anstreben können:

| Was wir beobachten                                   | Bedingung                | warm-up    | cooldown   | Ziel               |
| ---------------------------------------------------- | ------------------------ | ---------- | ---------- | ------------------ |
| Festplattennutzung auf `/`                           | Über 80 %                | 10 Minuten | 60 Minuten | On-Call            |
| Freier Speicher                                      | Unter 100 MB             | 0          | 0          | On-Call            |
| Swap in Verwendung                                   | Über 50 %                | 0          | 0          | On-Call            |
| Wartende Elemente in einer Queue, getaggt nach Queue | Mehr als 10.000          | 2 Minuten  | 0          | On-Call            |
| Verarbeitungsverzögerung, bei `p95`                  | Über 2.000 ms            | 0          | 0          | On-Call            |
| Verbindungen zu einer Host-Klasse                    | Mehr als 800             | 2 Minuten  | 0          | Nur Team-Chat      |
| throughput in einem background-namespace             | 30.000 req/min oder mehr | 2 Minuten  | 0          | On-Call            |
| Replikationsverzögerung                              | Über 60 Sekunden         | 2 Minuten  | 0          | E-Mail und On-Call |

Fünf Muster in dieser Tabelle sind für Produktions-Alerts nützlich:

1. **warm-ups sind kurz.** Die meisten liegen zwischen null und zwei Minuten. Der einzige lange betrifft die Festplattennutzung, und er ist mit einer Stunde cooldown kombiniert, statt an deren Stelle zu treten.
2. **cooldown wird einmal und bewusst verwendet.** Nur die Festplattennutzung bleibt üblicherweise über dem Schwellenwert, bis jemand handelt, daher braucht nur sie ihn.
3. **Nicht jeder Alert benachrichtigt On-Call.** Die Verbindungsobergrenze geht an den Team-Chat, weil sie ein Kapazitätsproblem vorhersagt und keinen Ausfall beschreibt.
4. **E-Mail wird ergänzt, nicht ersetzt.** Die Replikationsverzögerung erreicht ein On-Call-Tool und E-Mail zugleich, weil E-Mail der einzige Kanal ist, der weiter erinnert, solange ein Alert offen bleibt.
5. **Jeder Trigger trägt eine Beschreibung.** Die nützlichsten nennen das relevante Limit, geben zwei Gegenmaßnahmen in der richtigen Reihenfolge und halten fest, was die Ursache beim letzten Mal war.

Die Trigger, die sich am schwersten prüfen lassen, sind die, die **Custom metric** heißen. Benennen ist eine kleine Aufgabe, hat aber große Wirkung auf Prüfung und Triage.

## Nächste Schritte

* Arbeiten Sie die Einstellungen im Detail mit [Alerts optimieren](/alerting/tuning) durch.
* Prüfen Sie mit [Alerting in der Produktion](/alerting/production), dass nichts Wichtiges unbeobachtet bleibt.
* Finden Sie eine Startkonfiguration für einen bestimmten Alert in den [Vorlagen für Alerts](/alerting/recipes).
* Formen Sie eine Metrik beim Senden für das Alerting, mit [benutzerdefinierten Metriken](/metrics/custom).