> ## 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.

# Questions fréquentes sur les alertes

> Réponses aux questions de support les plus fréquentes sur les notifications d'alerte, les uptime monitors, les métriques Kubernetes, les alertes de mémoire de processus et le bruit des alertes.

Ces réponses couvrent les questions de support les plus fréquentes sur les alertes AppSignal. Pour la mise en place, commencez par [Alerting in AppSignal](/alerting). Pour affiner des alertes bruyantes, consultez [Affiner vos alertes](/alerting/tuning) et [Réduire le bruit des alertes](/alerting/reduce-noise).

## Pourquoi reçois-je encore des e-mails d'alerte après avoir résilié mon plan ?

Ces e-mails sont des notifications d'alerte opérationnelles, pas des e-mails marketing. Ils proviennent généralement d'un monitor ou d'un trigger encore configuré pour l'application.

Par exemple, un uptime monitor peut continuer à vérifier une URL et envoyer une alerte chaque fois que celle-ci est inaccessible. Si votre compte est verrouillé ou résilié, l'e-mail peut indiquer qu'AppSignal surveille toujours l'application mais que vous n'avez plus accès aux détails des données.

Pour arrêter les notifications :

1. Si vous avez encore accès à l'application, retirez le notifier du trigger sur la [page Triggers](https://appsignal.com/redirect-to/app?to=triggers), ou du monitor sur la [page Uptime monitoring](https://appsignal.com/redirect-to/app?to=uptime_monitors).
2. Archivez le trigger ou supprimez l'uptime monitor si vous n'en avez plus besoin.
3. Si vous ne pouvez pas accéder à l'application parce que le compte est verrouillé ou résilié, [contactez le support](mailto:support@appsignal.com). Nous pouvons vous aider à identifier et supprimer le monitor ou le trigger qui envoie encore des alertes.

## Comment empêcher un trigger d'envoyer des notifications sans le supprimer ?

Retirez les notifiers du trigger sur la [page Triggers](https://appsignal.com/redirect-to/app?to=triggers). Le trigger reste actif et continue d'enregistrer des alertes, mais il cesse d'envoyer des notifications.

N'archivez le trigger que lorsque vous ne voulez plus qu'AppSignal évalue cette condition. Archiver un trigger ferme également ses alertes ouvertes.

Pour les Anomaly detection triggers, l'acheminement des notifications est contrôlé sur le trigger lui-même. Les réglages de fréquence des notifications d'incident, tels que **Never Notify** ou **Every Nth per Hour**, ne s'appliquent pas aux alertes des Anomaly detection triggers.

## Puis-je alerter lorsque des conteneurs Kubernetes sont en attente ou arrêtés ?

AppSignal for Kubernetes rapporte les métriques de nodes et de pods, et les affiche sur les [pages Cluster Metrics](https://appsignal.com/redirect-to/app?to=cluster). Il ne fournit pas de trigger Kubernetes pour les états de conteneur tels que « pending » ou « stopped ».

Les métriques Kubernetes ne sont pas disponibles actuellement pour les Anomaly detection triggers, et la vue d'ensemble Kubernetes ne crée pas de règles d'alerte.

Si vous avez besoin d'alertes sur les états de conteneurs ou de pods Kubernetes, [contactez le support](mailto:support@appsignal.com). Nous pouvons vous aider à confirmer ce qui est possible pour votre configuration, et recueillir le cas d'usage s'il nécessite un développement produit.

## Quelle métrique alimente le dashboard « Process memory usage » ?

Le dashboard « Process memory usage », l'un des [dashboards](https://appsignal.com/redirect-to/app?to=dashboard) de votre application, utilise la métrique `process_rss`.

Cette métrique porte les tags suivants :

* `hostname`, l'hôte qui a émis la métrique.
* `process_name`, le nom du processus rapporté par le processus de l'application.

Pour créer une alerte sur un processus précis, [créez un Anomaly detection trigger](https://appsignal.com/redirect-to/app?to=triggers) pour `process_rss` et restreignez-le avec des tags. Utilisez par exemple `process_name=sidekiq*`, ou un nom de processus précis si votre application en rapporte un, et utilisez le `hostname` correspondant lorsque vous voulez alerter sur un seul hôte ou dyno.

Pour confirmer la métrique et les tags exacts derrière un graphique de dashboard, ouvrez le menu du graphique et sélectionnez **Edit chart**. Utilisez le nom de la métrique, le champ et les tags de ce graphique comme point de départ pour le trigger.

## Nous recevons des alertes mais ouvrons rarement AppSignal. Est-ce un problème ?

Pas nécessairement. Certaines équipes utilisent AppSignal principalement comme système d'alerting. Cela peut fonctionner si les alertes sont précises, acheminées au bon endroit, et suivies d'action.

Cela devient un problème lorsque les notifications arrivent mais que personne ne les examine. Cela signifie généralement que les alertes sont trop bruyantes, pas assez claires, ou acheminées vers le mauvais canal.

Passez la configuration des alertes en revue :

1. Listez les triggers ayant ouvert des alertes au cours des 90 derniers jours sur la [page Triggers](https://appsignal.com/redirect-to/app?to=triggers).
2. Vérifiez dans la [vue d'ensemble Anomaly detection](https://appsignal.com/redirect-to/app?to=anomalies) si quelqu'un a agi sur chaque alerte.
3. Retirez les notifiers des alertes qui ne devraient notifier personne.
4. Archivez les alertes pour les conditions dont personne n'a plus besoin.
5. Acheminez les alertes urgentes vers un outil d'astreinte, et les alertes moins prioritaires vers le chat ou l'e-mail.
6. Ajoutez un nom de trigger clair, une description et un lien vers un dashboard, afin que la notification explique quoi faire ensuite.

Si votre équipe ne souhaite pas utiliser souvent l'interface AppSignal, utilisez l'[AppSignal CLI](/cli/triggers) ou l'[AppSignal MCP server](/mcp-server) pour passer les triggers en revue et examiner les alertes depuis votre workflow habituel.

## Quelles alertes doivent envoyer un e-mail ?

Utilisez l'e-mail pour les alertes qui doivent continuer à rappeler quelque chose à quelqu'un tant qu'elles restent ouvertes, ou pour les alertes moins urgentes qui ne nécessitent pas de réponse d'astreinte immédiate.

Pour les problèmes de production urgents, utilisez un notifier d'astreinte tel que [PagerDuty](/application/integrations/pagerduty), [Opsgenie](/application/integrations/opsgenie) ou un autre notifier basé sur un webhook. L'e-mail est facile à manquer lorsqu'une équipe reçoit de nombreuses alertes. Connectez les notifiers sur la [page Notifications](https://appsignal.com/redirect-to/app?to=notifiers), puis sélectionnez-les sur chaque trigger.

L'e-mail peut envoyer des rappels tant qu'une alerte d'anomalie reste ouverte. Les autres types de notifiers, dont Slack, PagerDuty, Opsgenie et les webhooks, reçoivent des notifications à l'ouverture et à la résolution de l'alerte.

## À quelle fréquence devons-nous revoir les réglages d'alerte ?

Passez vos triggers en revue environ chaque trimestre, et chaque fois qu'un canal de notification commence à sembler bruyant.

Posez ces questions pour chaque trigger :

* Ce trigger a-t-il ouvert une alerte au cours des 90 derniers jours ?
* Quelqu'un a-t-il agi en conséquence ?
* Un seul incident a-t-il créé de nombreuses alertes ?
* Le notifier est-il toujours le bon ?
* Le nom et la description du trigger expliquent-ils l'action à entreprendre ?
* Le trigger correspond-il encore aux hôtes, tags, files d'attente ou noms de processus actuels ?

Une alerte sur laquelle personne n'agit doit être affinée, réacheminée ou archivée.