ClickStack inclut la prise en charge native des alertes, ce qui permet aux équipes de détecter les problèmes et d’y répondre en temps réel dans les logs, les metrics et les traces.
Les alertes peuvent être créées directement dans l’interface HyperDX et s’intègrent à des systèmes de notification courants comme Slack et PagerDuty.
Les alertes fonctionnent de manière fluide sur l’ensemble de vos données ClickStack, pour vous aider à suivre l’état de santé du système, à détecter les régressions de performance et à surveiller les événements métier clés.
ClickStack prend en charge deux façons complémentaires de créer des alertes : alertes de recherche et Dashboard chart alerts. Une fois l’alerte créée, elle est associée soit à la recherche, soit au graphique.
Les alertes de recherche vous permettent de déclencher des notifications en fonction des résultats d’une recherche enregistrée. Elles vous aident à détecter lorsque des événements ou des schémas spécifiques se produisent plus (ou moins) fréquemment que prévu.
Une alerte est déclenchée lorsque le nombre de résultats correspondants, dans une fenêtre de temps définie, dépasse ou passe sous un seuil spécifié.
Pour créer une alerte de recherche :
Pour qu’une alerte puisse être créée pour une recherche, celle-ci doit être enregistrée. Vous pouvez soit créer l’alerte pour une recherche enregistrée existante, soit enregistrer la recherche pendant le processus de création de l’alerte. Dans l’exemple ci-dessous, nous partons du principe que la recherche n’est pas enregistrée.
Ouvrir la boîte de dialogue de création d’alerte
Commencez par saisir une recherche, puis cliquez sur le bouton Alerts dans l’angle supérieur droit de la page Search.Créer l’alerte
Depuis le panneau de création d’alerte, vous pouvez :
- Attribuer un nom à la recherche enregistrée associée à l’alerte.
- Définir un seuil et préciser combien de fois il doit être atteint sur une période donnée. Les seuils peuvent également servir de bornes supérieures ou inférieures. La période détermine également la fréquence de déclenchement de l’alerte.
- Spécifier une valeur
grouped by. Cela permet de soumettre la recherche à une agrégation, par exemple ServiceName, et donc de déclencher plusieurs alertes à partir de la même recherche.
- Choisir une destination webhook pour les notifications. Vous pouvez ajouter un nouveau webhook directement depuis cette vue. Voir Ajouter un webhook pour plus de détails.
Avant d’enregistrer, ClickStack visualise la condition de seuil afin que vous puissiez vérifier qu’elle se comportera comme prévu.2. Alertes de graphiques sur tableau de bord
Pour qu’une alerte puisse être créée pour une visualisation sur un tableau de bord, le tableau de bord doit être enregistré.
Ouvrir la boîte de dialogue de modification du graphique
Ouvrez le menu de configuration du graphique et sélectionnez le bouton d’alerte. La boîte de dialogue de modification du graphique s’affiche.Ajouter l’alerte
Sélectionnez Add Alert.Définir les conditions de l’alerte
Définissez la condition (>=, >, <=, <, =, !=, <= x >=, > or <), le seuil, la durée et le webhook. La durée détermine également la fréquence de déclenchement de l’alerte.Vous pouvez ajouter un nouveau webhook directement depuis cette vue. Voir Ajouter un webhook pour plus de détails.Add New Webhook.
Cela ouvre la boîte de dialogue de création du webhook, dans laquelle vous pouvez créer un nouveau webhook :
Un nom de webhook est requis, tandis que la description est facultative. Les autres paramètres à renseigner dépendent du type de service.
Notez que les types de service disponibles diffèrent entre ClickStack Open Source et ClickStack Cloud. Voir Service type integrations.
Intégrations par type de service
- Slack : envoyez des notifications directement vers un canal via un webhook ou l’API.
- PagerDuty : acheminez les incidents vers les équipes d’astreinte via l’API PagerDuty.
- Webhook : connectez les alertes à n’importe quel système ou workflow personnalisé via un webhook générique.
Intégrations disponibles uniquement dans ClickHouse CloudLes intégrations Slack API et PagerDuty ne sont prises en charge que dans ClickHouse Cloud.
- URL du webhook. Par exemple :
https://hooks.slack.com/services/<unique_path>. Consultez la documentation Slack pour plus de détails.
Slack (API)
API PagerDuty
Générique
- URL du webhook
- En-têtes du webhook (facultatif)
- Corps du webhook (facultatif). Le corps prend actuellement en charge les variables de modèle
{{title}}, {{body}} et {{link}}.
Les alertes peuvent être gérées de façon centralisée depuis le panneau des alertes, sur la gauche de HyperDX.
Depuis cette vue, vous pouvez voir toutes les alertes qui ont été créées et qui sont actuellement actives dans ClickStack.
Cette vue affiche également l’historique d’évaluation des alertes. Les alertes sont évaluées à intervalles réguliers (définis par la période/durée configurée lors de la création de l’alerte). À chaque évaluation, HyperDX interroge vos données pour vérifier si la condition de l’alerte est remplie :
- Barre rouge : la condition de seuil a été remplie lors de cette évaluation et l’alerte s’est déclenchée (notification envoyée)
- Barre verte : l’alerte a été évaluée, mais la condition de seuil n’a pas été remplie (aucune notification envoyée)
Chaque évaluation est indépendante : l’alerte vérifie les données pour cette fenêtre temporelle et ne se déclenche que si la condition est vraie à ce moment-là.
Dans l’exemple ci-dessus, la première alerte s’est déclenchée à chaque évaluation, ce qui indique un problème persistant. La deuxième alerte montre un problème résolu : elle s’est déclenchée deux fois au départ (barres rouges), puis, lors des évaluations suivantes, la condition de seuil n’était plus remplie (barres vertes).
En cliquant sur une alerte, vous accédez au graphique ou à la recherche auquel elle est associée.
Pour supprimer une alerte, ouvrez la boîte de dialogue de modification du Search ou du graphique associé, puis sélectionnez Supprimer l’alerte.
Dans l’exemple ci-dessous, le bouton Remove Alert supprimera l’alerte du graphique.
Alertes de graphiques basées sur SQL
Types de graphiques pris en charge
| Type de graphique | Comportement |
|---|
| Line | Alerte de série temporelle. La requête doit produire des lignes regroupées par intervalle de temps. Chaque intervalle est évalué indépendamment par rapport au seuil. |
| Stacked Bar | Alerte de série temporelle. Même comportement que Line. |
| Number | Alerte à valeur unique. La requête renvoie un seul résultat numérique, comparé au seuil une fois par évaluation. |
Créer ou ouvrir un graphique SQL sur un tableau de bord
À partir d’un tableau de bord enregistré, créez un nouveau graphique avec le mode SQL ou ouvrez un graphique SQL existant pour le modifier.Choisissez Line, Stacked Bar ou Number comme type d’affichage.Ajouter l’alerte
Sélectionnez Add Alert dans la section des alertes de l’éditeur de graphique. Configurez :
- Threshold type :
>= (supérieur ou égal à), > (supérieur à), <= (inférieur ou égal à), < (inférieur à), = (égal à), != (différent de), <= x >= (entre) ou > or < (en dehors de)
- Threshold value : la valeur numérique de comparaison
- Interval : la fréquence d’évaluation de l’alerte (1m, 5m, 15m, 30m, 1h, 6h, 12h ou 1d). Cela définit également l’intervalle de temps de chaque évaluation.
- Webhook : le canal de notification à utiliser lorsque l’alerte se déclenche. Voir Ajouter un webhook.
Alert Time RangeEn règle générale, les requêtes d’alerte sont exécutées une fois par intervalle. Cependant, si un ou plusieurs intervalles sont sautés en raison d’erreurs ou de requêtes lentes, l’exécution suivante utilisera un intervalle de temps qui inclut les intervalles manqués. Dans ce cas, les paramètres d’intervalle de la requête resteraient définis sur la période configurée pour l’alerte, tandis que les paramètres d’intervalle de temps refléteraient cette plage plus longue.
Enregistrer le tableau de bord
Enregistrez le tableau de bord pour activer l’alerte. L’alerte commencera à être évaluée selon l’intervalle configuré.
- Colonne de valeur : la dernière colonne numérique de votre clause
SELECT est utilisée comme valeur d’alerte. Si votre requête renvoie plusieurs colonnes numériques (par ex., count, avg_latency, p99_latency), seule la dernière (p99_latency) est comparée au seuil.
- Colonne d’horodatage : pour les graphiques de séries temporelles (Line et Stacked Bar), le système identifie la colonne Date/DateTime dans vos résultats comme l’intervalle de temps (c.-à-d. l’axe des x d’un graphique de séries temporelles). La colonne de valeur de chaque intervalle de temps est évaluée indépendamment par rapport au seuil, et si la valeur de l’un de ces intervalles dépasse le seuil configuré, l’alerte se déclenche.
- Colonnes de groupe : toutes les colonnes qui ne sont ni numériques ni des colonnes d’horodatage (par ex.,
ServiceName, Environment) sont traitées comme des dimensions de regroupement. Lorsque des groupes sont présents, chaque combinaison unique de valeurs de groupe est suivie et fait l’objet d’une alerte distincte. ClickStack enverra une alerte pour chaque groupe dont la valeur dépasse le seuil configuré. Les groupes sont disponibles uniquement pour les graphiques de séries temporelles.
Paramètres de requête et macros
Paramètres requis et recommandés
{intervalSeconds:Int64}, {intervalMilliseconds:Int64}, $__timeInterval(col) ou $__timeInterval_ms(col)). Lors de l’exécution de l’alerte, ce paramètre sera remplacé par la période configurée de l’alerte.
Les requêtes utilisées pour les alertes devraient inclure un filtre d’intervalle de temps ({startDateMilliseconds:Int64} et {endDateMilliseconds:Int64}, ou $__timeFilter(col), etc.). Qu’un filtre d’intervalle de temps soit présent ou non dans la requête, la requête d’alerte s’exécutera sur la période configurée de l’alerte. S’il n’y a pas de filtre d’intervalle de temps, la requête lira alors l’intégralité de l’intervalle de temps disponible dans la table source à chaque exécution.
Intervalle de temps de l’alerteEn général, les requêtes d’alerte sont exécutées une fois par intervalle. Cependant, si un ou plusieurs intervalles sont ignorés en raison d’erreurs ou de requêtes lentes, l’exécution suivante utilisera un intervalle de temps incluant les intervalles manqués. Dans ce cas, les paramètres d’intervalle de la requête resteront définis sur la période configurée de l’alerte, mais les paramètres d’intervalle de temps refléteront cet intervalle de temps plus long.
Exemples de requêtes d’alerte
Taux d’erreur par service (série temporelle)
WITH error_rates AS (
SELECT
$__timeInterval(Timestamp) as ts,
ServiceName,
countIf (SpanKind = 'Server') as request_count,
countIf (
SpanKind = 'Server'
and StatusCode = 'Error'
) as error_count,
error_count / request_count * 100 AS error_percent
FROM $__sourceTable
WHERE $__timeFilter(Timestamp)
GROUP BY ts, ServiceName
)
SELECT ts, ServiceName, error_percent
FROM error_rates
WHERE request_count > 10
>= 5 (se déclenche lorsque le taux d’erreur atteint 5 %)
Dans cette requête, ServiceName est une colonne qui n’est ni numérique ni de type horodatage ; chaque service est donc suivi dans un groupe d’alertes distinct. L’alerte se déclenche indépendamment pour chaque service.
Détection d’anomalies avec moyenne décalée (séries temporelles)
WITH buckets AS (
SELECT
$__timeInterval(Timestamp) AS ts,
count() AS bucket_count
FROM $__sourceTable
WHERE TimestampTime >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
- toIntervalSecond($__interval_s * 30) -- Fetch 30 intervals back
AND TimestampTime < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
AND SeverityText = 'error'
GROUP BY ts
ORDER BY ts
WITH FILL
FROM toDateTime(fromUnixTimestamp64Milli({startDateMilliseconds:Int64}))
TO toDateTime(fromUnixTimestamp64Milli({endDateMilliseconds:Int64}))
STEP toIntervalSecond($__interval_s)
),
anomaly_detection AS (
SELECT
ts,
bucket_count,
avg(bucket_count) OVER (
ORDER BY ts ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING
) AS previous_30_avg,
stddevPop(bucket_count) OVER (
ORDER BY ts ROWS BETWEEN 30 PRECEDING AND 1 PRECEDING
) AS previous_30_stddev,
greatest(
bucket_count - (previous_30_avg + 2 * previous_30_stddev), 0
) AS excess_error_count
FROM buckets
)
SELECT ts, excess_error_count
FROM anomaly_detection
WHERE ts >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
AND ts < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
> 0 (se déclenche lorsqu’un excès d’erreurs au-dessus de la baseline glissante est détecté)
Notez que la requête récupère 30 intervalles avant le début de la plage de dates afin d’initialiser les calculs de fenêtre glissante, puis filtre le résultat final pour ne conserver que la fenêtre d’évaluation.
Scénarios d’alerte courants
All Error Events et HTTP Status >= 400 afin d’être averti en cas de
nombre excessif d’erreurs.
Opérations lentes : Vous pouvez également configurer une recherche pour les opérations lentes (par exemple,
duration:>5000), puis déclencher une alerte lorsqu’un trop grand nombre d’opérations lentes
surviennent.
Événements utilisateur : Vous pouvez aussi configurer des alertes pour que les équipes en contact avec les clients soient
averties lorsque de nouveaux utilisateurs s’inscrivent ou lorsqu’une action utilisateur critique est effectuée. 
