Tout le monde aime les alertes.
Bien sûr, il est beaucoup mieux de recevoir une notification quand quelque chose s'est produit (ou a été réparé) que de rester assis, à regarder des graphiques et à chercher des anomalies.
Et il existe de nombreux outils pour cela. Alertmanager de l'écosystÚme Prometheus et vmalert du groupe de produits VictoriaMetrics. Notifications Zabbix et alertes dans Grafana. Des scripts faits maison en bash et des bots Telegram qui vérifient réguliÚrement une URL et signalent s'il y a un problÚme. Beaucoup de choses.
Nous, dans notre entreprise, avons Ă©galement utilisĂ© diffĂ©rentes solutions jusqu'Ă ce que nous rencontrions la complexitĂ©, ou plutĂŽt, l'impossibilitĂ© de crĂ©er des alertes complexes et composĂ©es. Ce que nous voulions et ce que nous avons finalement rĂ©alisĂ© â sous le spoiler. TLDR : Ainsi est nĂ© le projet open source
Nous avons assez bien vécu avec les alertes configurées dans Grafana pendant un long moment. 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 aussi envisagé plusieurs fois de déménager. Puis, petit à petit, nous avons voulu plus.
Dire qu'un certain graphique a chutĂ©/augmentĂ© de XX% et reste lĂ depuis N minutes par rapport Ă la pĂ©riode prĂ©cĂ©dente de M heures ? Cela semble rĂ©alisable avec Grafana ou Alertmanager, mais ce n'est pas trĂšs simple. (Ou peut-ĂȘtre que ce n'est pas possible, je ne peux pas le dire maintenant)
Tout devient encore plus compliquĂ© lorsque la dĂ©cision d'alerte doit ĂȘtre prise sur la base de donnĂ©es provenant de diffĂ©rentes sources. Un exemple concret :
Nous vérifions les données provenant de deux bases Clickhouse, puis nous les comparons avec certaines données issues de Postgres, et prenons une décision d'alerte. Signaler ou annuler.
Nous avons accumulé suffisamment de demandes de ce type pour envisager notre propre solution. Nous avons alors essayé de dresser une premiÚre liste des exigences/possibilités de ce service qui n'était pas encore créé.
Accéder à différentes sources de données. Par exemple, Prometheus, Clickhouse, Postgres.
Envoyer des alertes vers diffĂ©rents canaux â telegram, slack, etc.
En réfléchissant, il est devenu clair que nous voulions non pas une description déclarative, mais la possibilité d'écrire des scripts.
Lancer des scripts selon un calendrier.
Mise à jour facile des scripts sans redémarrage du service.
Possibilité d'étendre la fonctionnalité sans reconstruire le service à partir du code source.
C'est une liste approximative et, probablement, pas trÚs exacte. Certains points ont évolué, d'autres ont disparu. Comme d'habitude.
C'est ainsi que l'histoire de Balerter a réellement commencé.
Je vais essayer de décrire briÚvement ce que nous avons accompli et comment cela fonctionne. (Oui, bien sûr, ce n'est pas la fin. Beaucoup de projets de développement pour le produit. Je vais simplement me concentrer sur le jour d'aujourd'hui)
Comment cela fonctionne ?
Vous Ă©crivez un script en Lua, oĂč vous envoyez clairement des requĂȘtes (vers Prometheus, Clickhouse, etc.). Vous obtenez des rĂ©ponses et les traitez et les comparez d'une certaine maniĂšre. Ensuite, vous activez/dĂ©sactivez une alerte. Balerter enverra lui-mĂȘme des notifications dans les canaux que vous avez configurĂ©s (Email, telegram, slack, etc.). Le script s'exĂ©cute Ă intervalles prĂ©dĂ©finis. Et⊠c'est Ă peu prĂšs tout)
Le mieux est de montrer par 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("erreur de requĂȘte clickhouse 'ch1' : " .. err)
return
end
local resultRPS = res[1].rps
if resultRPS < minRequestsRPS then
alert.error("rps-min-limit", "Les RPS de demandes sont trĂšs faibles : " .. tostring(resultRPS))
else
alert.success("rps-min-limit", "RPS de demandes corrects")
end Que se passe-t-il ici :
nous spécifions que ce script doit s'exécuter toutes les 10 secondes
nous spécifions le nom du script (pour l'API, pour l'affichage dans les journaux, pour une utilisation dans les tests)
nous connectons le module pour afficher les journaux
nous connectons le module pour accéder à Clickhouse nommé
ch1(la connexion elle-mĂȘme est configurĂ©e dans le fichier de configuration)nous envoyons une requĂȘte Ă Clickhouse
en cas d'erreur, nous affichons un message dans le journal et sortons
nous comparons le rĂ©sultat de la requĂȘte avec une constante (dans un exemple rĂ©el, nous pourrions obtenir cette valeur, par exemple, Ă partir d'une base de donnĂ©es Postgres)
nous activons ou désactivons l'alerte avec l'ID
rps-min-limitvous recevrez une notification si le statut de l'alerte change
L'exemple est assez simple et comprĂ©hensible. Cependant, il va sans dire que dans la rĂ©alitĂ©, les scripts peuvent ĂȘtre assez volumineux et complexes. Il est facile de s'y perdre et de commettre des erreurs.
C'est pourquoi une envie logique est nĂ©e â avoir la possibilitĂ© d'Ă©crire des tests pour ses scripts. Et dans la version v0.4.0, cela est apparu.
Tests de scripts
Exemple de test pour notre script de l'exemple précédent :
-- @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', 'Les RPS de demandes sont trĂšs faibles : 10')
test.alert().assertNotCalled('success', 'rps-min-limit', 'RPS de demandes corrects')Par Ă©tapes :
nous spécifions le nom du script pour lequel le test est écrit
le nom du test (pour les journaux)
nous connectons le module de test
nous discutons du rĂ©sultat Ă retourner pour une certaine requĂȘte vers ClickHouse
ch1nous vérifions qu'une alerte (erreur) rps-min-limit a bien été appelée avec le message spécifié
nous vérifions que l'alerte rps-min-limit n'a pas été désactivée (succÚs)
Quelles sont les autres capacités de Balerter ?
Je vais essayer d'aborder les compétences les plus importantes de Balerter selon moi. Vous pouvez voir tous les détails sur le site officiel
obtenir des données de
clickhouse
postgres
mysql
prometheus
loki
envoyer des notifications vers des canaux
slack
telegram
syslog
notiify (notifications UI sur votre ordinateur)
email
discord
construire des graphiques à partir de vos données, télécharger des images dans un stockage compatible S3 et les joindre aux notifications ()
permet d'Ă©changer des donnĂ©es entre des scripts â un stockage Key/Value global
écrire vos propres bibliothÚques en Lua et les utiliser dans des scripts (des bibliothÚques Lua pour travailler avec json, csv sont fournies par défaut)
envoyer des requĂȘtes HTTP depuis vos scripts (et bien sĂ»r recevoir des rĂ©ponses)
fournit une API (pas encore aussi fonctionnelle que souhaité)
exporte les métriques au format Prometheus
Quels autres souhaits aimerions-nous ?
Il est déjà clair que les utilisateurs et nous voulons la possibilité de gérer le lancement des scripts avec une syntaxe cron. Cela sera fait avant la version v1.0.0
Nous aimerions prendre en charge plus de sources de données et de canaux de livraison de notifications. Par exemple, certains manqueront sûrement MongoDB. D'autres Elastic Search. Envoyer des SMS et/ou passer des appels sur des mobiles. Nous souhaitons pouvoir obtenir des scripts non seulement à partir de fichiers, mais aussi, par exemple, à partir d'une base de données. En fin de compte, nous voulons un site plus convivial pour le projet et une meilleure documentation.
Il y a toujours quelque chose qui manque à quelqu'un) Ici, nous espérons compter sur les demandes de la communauté pour établir correctement les priorités. Et sur l'aide de la communauté pour tout réaliser
En conclusion
Nous utilisons nous l'avons déjà utilisé depuis un bon moment. Des dizaines de scripts veillent sur notre tranquillité. J'espÚre que ce travail sera utile à d'autres.
Et bienvenue avec vos problĂšmes et vos PR.
Source : habr.com
