Warum erhalte ich nach der Kündigung meines Plans weiterhin Alert-E-Mails?
Diese E-Mails sind operative Alert-Benachrichtigungen, keine Marketing-E-Mails. Sie stammen üblicherweise von einem Monitor oder Trigger, der für die App noch konfiguriert ist. Ein uptime monitor kann zum Beispiel weiterhin eine URL prüfen und jedes Mal einen Alert senden, wenn die URL nicht erreichbar ist. Wenn Ihr Konto gesperrt oder gekündigt ist, kann in der E-Mail stehen, dass AppSignal die App weiterhin überwacht, Sie aber keinen Zugriff mehr auf die Datendetails haben. So stoppen Sie die Benachrichtigungen:- Wenn Sie noch auf die App zugreifen können, entfernen Sie den notifier vom Trigger auf der Triggers-Seite oder vom Monitor auf der Uptime-monitoring-Seite.
- Archivieren Sie den Trigger oder löschen Sie den uptime monitor, wenn Sie ihn nicht mehr benötigen.
- Wenn Sie nicht auf die App zugreifen können, weil das Konto gesperrt oder gekündigt ist, wenden Sie sich an den Support. Wir können helfen, den Monitor oder Trigger zu identifizieren und zu entfernen, der weiterhin Alerts sendet.
Wie verhindere ich, dass ein Trigger Benachrichtigungen sendet, ohne ihn zu löschen?
Entfernen Sie die notifier vom Trigger auf der Triggers-Seite. Der Trigger bleibt aktiv und zeichnet weiterhin Alerts auf, sendet aber keine Benachrichtigungen mehr. Archivieren Sie den Trigger nur dann, wenn AppSignal diese Bedingung nicht mehr auswerten soll. Beim Archivieren eines Triggers werden auch dessen offene Alerts geschlossen. Bei Anomaly-detection-Triggern wird das Routing der Benachrichtigungen am Trigger selbst gesteuert. Einstellungen zur Häufigkeit von Incident-Benachrichtigungen wie Never Notify oder Every Nth per Hour gelten nicht für Alerts von Anomaly-detection-Triggern.Kann ich alarmieren, wenn Kubernetes-Container den Status „pending” oder „stopped” haben?
AppSignal for Kubernetes meldet Node- und Pod-Metriken und zeigt sie auf den Cluster-Metrics-Seiten. Es bietet keinen Kubernetes-Trigger für Container-Zustände wie „pending” oder „stopped”. Kubernetes-Metriken stehen derzeit nicht für Anomaly-detection-Trigger zur Verfügung, und die Kubernetes-Übersicht erstellt keine Alert-Regeln. Wenn Sie Alerts für Container- oder Pod-Zustände in Kubernetes benötigen, wenden Sie sich an den Support. Wir können helfen zu klären, was für Ihr Setup möglich ist, und den Anwendungsfall aufnehmen, falls dafür Produktarbeit erforderlich ist.Welche Metrik speist das Dashboard „Process memory usage”?
Das Dashboard „Process memory usage”, eines der Dashboards Ihrer App, verwendet die Metrikprocess_rss.
Diese Metrik ist mit folgenden Tags versehen:
hostname, der Host, der die Metrik gesendet hat.process_name, der Prozessname, den der App-Prozess meldet.
process_rss und grenzen Sie ihn über Tags ein. Verwenden Sie zum Beispiel process_name=sidekiq* oder einen konkreten Prozessnamen, falls Ihre App einen meldet, und verwenden Sie den passenden hostname, wenn Sie für einen einzelnen Host oder Dyno alarmieren möchten.
Um die genaue Metrik und die Tags hinter einem Dashboard-Chart zu bestätigen, öffnen Sie das Chart-Menü und wählen Sie Edit chart. Verwenden Sie Metrikname, Feld und Tags aus diesem Chart als Ausgangspunkt für den Trigger.
Wir erhalten Alerts, öffnen AppSignal aber selten. Ist das ein Problem?
Nicht zwangsläufig. Manche Teams nutzen AppSignal überwiegend als Alerting-System. Das kann funktionieren, wenn die Alerts spezifisch sind, an die richtige Stelle weitergeleitet werden und bearbeitet werden. Zum Problem wird es, wenn Benachrichtigungen eintreffen, aber niemand ihnen nachgeht. Das bedeutet meist, dass die Alerts zu störend sind, nicht klar genug oder an den falschen Kanal weitergeleitet werden. Prüfen Sie das Alert-Setup:- Listen Sie auf der Triggers-Seite die Trigger auf, die in den letzten 90 Tagen Alerts geöffnet haben.
- Prüfen Sie in der Anomaly-detection-Übersicht, ob jemand auf die einzelnen Alerts reagiert hat.
- Entfernen Sie notifier von Alerts, die niemanden benachrichtigen sollen.
- Archivieren Sie Alerts für Bedingungen, die niemand mehr benötigt.
- Leiten Sie dringende Alerts an ein On-Call-Tool und Alerts mit niedrigerer Priorität an Chat oder E-Mail.
- Ergänzen Sie einen klaren Trigger-Namen, eine Beschreibung und einen Dashboard-Link, damit die Benachrichtigung erklärt, was als Nächstes zu tun ist.
Welche Alerts sollten E-Mails senden?
Verwenden Sie E-Mail für Alerts, die jemanden weiterhin erinnern sollen, solange sie offen bleiben, oder für weniger dringende Alerts, die keine sofortige On-Call-Reaktion erfordern. Verwenden Sie für dringende Produktionsprobleme einen On-Call-notifier wie PagerDuty, Opsgenie oder einen anderen Webhook-basierten notifier. E-Mails werden leicht übersehen, wenn ein Team viele Alerts erhält. Verbinden Sie notifier auf der Notifications-Seite und wählen Sie sie anschließend an jedem Trigger aus. E-Mail kann Erinnerungen senden, solange ein Anomaly-Alert offen bleibt. Andere notifier-Typen, darunter Slack, PagerDuty, Opsgenie und Webhooks, erhalten Benachrichtigungen, wenn der Alert geöffnet und wenn er geschlossen wird.Wie oft sollten wir die Alert-Einstellungen überprüfen?
Prüfen Sie Trigger etwa vierteljährlich und immer dann, wenn ein Benachrichtigungskanal störend wirkt. Stellen Sie für jeden Trigger diese Fragen:- Hat dieser Trigger in den letzten 90 Tagen einen Alert geöffnet?
- Hat jemand darauf reagiert?
- Hat ein einzelner Vorfall viele Alerts erzeugt?
- Ist der notifier noch der richtige?
- Erklären Name und Beschreibung des Triggers, welche Handlung erforderlich ist?
- Passt der Trigger noch zu den aktuellen Hosts, Tags, Queues oder Prozessnamen?