Tout le monde aime les alertes.
Bien sûr, il est préférable d'être averti lorsque quelque chose s'est produit (ou a été corrigé) plutôt que de s'asseoir et de regarder des graphiques et de rechercher des anomalies.
Et de nombreux outils ont été créés pour cela. Alertmanager de l'écosystème Prometheus et vmalert du groupe de produits VictoriaMetrics. Notifications et alertes Zabbix dans Grafana. Scripts auto-écrits dans les robots bash et Telegram qui extraient périodiquement une URL et vous indiquent si quelque chose ne va pas. Beaucoup de tout.
Dans notre entreprise, nous avons également utilisé différentes solutions jusqu'à ce que nous nous heurtions à la complexité, ou plutôt à l'impossibilité de créer des alertes complexes et composites. Ce que nous voulions et ce que nous avons fini par faire est en dessous du seuil. TLDR : Voici comment est apparu le projet open source
Pendant assez longtemps, nous avons bien vécu avec les alertes configurées dans Grafana. Oui, ce n'est pas la meilleure façon. Il est toujours recommandé d'utiliser certaines solutions spécialisées, comme Alertmanager. Et nous avons également envisagé de déménager plus d’une fois. Et puis, petit à petit, on en a voulu plus.
Dites quand un certain graphique a diminué/augmenté de XX % et est resté là pendant N minutes par rapport à la période précédente de M heures ? Il semble que vous puissiez essayer de mettre en œuvre cela avec Grafana ou Alertmanager, mais ce n'est pas très simple. (Ou peut-être que ce n'est pas possible, je ne le dirai pas maintenant)
Les choses deviennent encore plus compliquées lorsque la décision d’alerte doit être prise sur la base de données provenant de différentes sources. Exemple en direct :
Nous vérifions les données de deux bases de données Clickhouse, puis les comparons avec certaines données de Postgres et décidons d'une alerte. Signaler ou annuler
Nous avons accumulé pas mal de désirs similaires pour que nous réfléchissions à notre décision. Et puis nous avons essayé de dresser la première liste d’exigences/capacités de ce service, qui n’a pas encore été créée.
-
accéder à différentes sources de données. Par exemple, Prometheus, Clickhouse, Postgres
-
envoyer des alertes sur différents canaux - télégramme, slack, etc.
-
au cours de la réflexion, il est devenu clair que je ne voulais pas une description déclarative, mais la capacité d'écrire des scripts
-
exécuter des scripts selon un calendrier
-
mise à jour facile des scripts sans redémarrer le service
-
la possibilité d'étendre d'une manière ou d'une autre les fonctionnalités sans reconstruire le service à partir des codes sources
Cette liste est approximative et probablement peu précise. Certains points ont changé, d'autres sont morts. Tout est comme d'habitude.
En fait, c’est ainsi que commença l’histoire de Balerter.
Je vais essayer de décrire brièvement ce qui s’est finalement passé et comment cela fonctionne. (Oui, bien sûr, ce n’est pas la fin. Il existe de nombreux projets de développement de produits. Je vais m’arrêter là aujourd’hui)
Comment ça marche?
Vous écrivez un script dans Lua dans lequel vous envoyez explicitement des requêtes (à Prometheus, Clickhouse, etc.). Vous recevez des réponses et, d’une manière ou d’une autre, vous les traitez et les comparez. Ensuite, activez/désactivez une sorte d'alerte. Balerter enverra lui-même une notification aux canaux que vous avez configurés (E-mail, télégramme, slack, etc.). Le script est exécuté à des intervalles spécifiés. Et... en général, c'est tout)
Il est préférable de montrer avec un exemple :
-- @interval 10s
-- @name script1
local minRequestsRPS = 100
local log = require("log")
local ch1 = require("datasource.clickhouse.ch1")
local res, err = ch1.query("SELECT sum(requests) AS rps FROM some_table WHERE date = now()")
if err ~= nil then
log.error("clickhouse 'ch1' query error: " .. err)
return
end
local resultRPS = res[1].rps
if resultRPS < minResultRPS then
alert.error("rps-min-limit", "Requests RPS are very small: " .. tostring(resultRPS))
else
alert.success("rps-min-limit", "Requests RPS ok")
end Que se passe t-il ici:
-
nous indiquons que ce script doit être exécuté toutes les 10 secondes
-
indiquer le nom du script (pour l'API, pour affichage dans les logs, pour utilisation dans les tests)
-
connecter le module pour la sortie des journaux
-
connectez un module pour accéder au clickhouse avec le nom
ch1(la connexion elle-même est configurée dans la config) -
envoyer une demande à clickhouse
-
en cas d'erreur, nous affichons un message dans le log et sortons
-
comparer le résultat de la requête avec une constante (dans un exemple réel, nous pourrions obtenir cette valeur, par exemple, à partir de la base de données Postgres)
-
activer ou désactiver l'alerte avec ID
rps-min-limit -
vous recevrez une notification si l'état de l'alerte a changé
L'exemple est assez simple et compréhensible. Cependant, bien entendu, dans la vie réelle, les scénarios peuvent être assez longs et complexes. Il est facile de se perdre et de faire des erreurs.
Par conséquent, un désir logique a mûri : pouvoir écrire des tests pour vos scripts. Et dans la version v0.4.0, cela est apparu.
Test des scripts
Exemple de test pour notre script à partir de l'exemple ci-dessus :
-- @test script1
-- @name script1-test
test = require('test')
local resp = {
{
rps = 10
}
}
test.datasource('clickhouse.ch1').on('query', 'SELECT sum(requests) AS rps FROM some_table WHERE date = now()').response(resp)
test.alert().assertCalled('error', 'rps-min-limit', 'Requests RPS are very small: 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'Requests RPS ok')Par étapes:
-
indiquer le nom du script pour lequel le test est écrit
-
nom du test (pour les journaux)
-
connecter le module de test
-
nous disons quel résultat doit être renvoyé pour une demande spécifique au clickhouse
ch1 -
nous vérifions que l'alerte (erreur) rps-min-limit avec le message spécifié a été appelée
-
vérifier que l'alerte rps-min-limit n'a pas été désactivée (succès)
Que peut faire d’autre Balerter ?
Je vais essayer d'aborder les compétences les plus importantes, à mon avis, de Balerter. Vous pouvez tout voir en détail sur le site officiel
-
recevoir des données de
-
click house
-
postgres
-
mysql
-
Prométhée
-
Loki
-
-
envoyer des notifications aux chaînes
-
mou
-
télégramme
-
syslog
-
notifier (notifications de l'interface utilisateur sur votre ordinateur)
-
email
-
discorde
-
-
créez des graphiques basés sur vos données, téléchargez l'image sur un stockage compatible S3 et joignez-la aux notifications ()
-
vous permet d'échanger des données entre scripts - stockage global clé/valeur
-
écrivez vos propres bibliothèques dans Lua et utilisez-les dans des scripts (par défaut, les bibliothèques Lua sont fournies pour travailler avec json, csv)
-
envoyez des requêtes HTTP à partir de vos scripts (et recevez des réponses, bien sûr)
-
fournit une API (pas encore aussi fonctionnelle que nous le souhaiterions)
-
exporte les métriques au format Prometheus
Qu’aimeriez-vous faire d’autre ?
Il est déjà clair que les utilisateurs et nous souhaitons pouvoir contrôler le lancement des scripts en utilisant la syntaxe cron. Cela sera fait avant la version v1.0.0
J'aimerais prendre en charge davantage de sources de données et de canaux de livraison de notifications. Par exemple, MongoDB manquera certainement à quelqu'un. Elastic Search pour certains. Envoyez des SMS et/ou passez des appels sur votre téléphone mobile. Nous voulons pouvoir recevoir des scripts non seulement à partir de fichiers, mais aussi, par exemple, d'une base de données. En fin de compte, nous souhaitons un site Web plus convivial et une meilleure documentation pour le projet.
Il manque toujours quelque chose à quelqu’un.) Ici, nous nous appuyons sur la demande de la communauté pour fixer correctement les priorités. Et à l'aide de la communauté pour tout réaliser
En conclusion
Nous utilisons Je l'ai depuis pas mal de temps maintenant. Des dizaines de scripts veillent à notre tranquillité d'esprit. J'espère que ce travail sera utile à quelqu'un d'autre.
Et bienvenue avec votre problème et vos relations publiques.
Source: habr.com