Iedereen houdt van waarschuwingen.
Het is natuurlijk veel beter om gewaarschuwd te worden als er iets is gebeurd (of opgelost) dan naar grafieken te kijken en naar afwijkingen te zoeken.
En hiervoor zijn veel tools gemaakt. Alertmanager van het Prometheus ecosysteem en vmalert van de VictoriaMetrics productgroep. Zabbix-meldingen en waarschuwingen in Grafana. Zelfgeschreven scripts in bash- en Telegram-bots die periodiek een URL ophalen en je vertellen of er iets mis is. Veel van alles.
Binnen ons bedrijf hebben we ook verschillende oplossingen gebruikt totdat we tegen de complexiteit, of beter gezegd, de onmogelijkheid aanliepen om complexe, samengestelde waarschuwingen te creëren. Wat we wilden en wat we uiteindelijk deden, ligt onder de maat. TLDR: Dit is hoe het open source-project verscheen
Lange tijd hebben we goed kunnen leven met waarschuwingen geconfigureerd in Grafana. Ja, dit is niet de beste manier. Het wordt altijd aanbevolen om enkele gespecialiseerde oplossingen te gebruiken, zoals Alertmanager. En we hebben ook meer dan eens overwogen om te verhuizen. En toen wilden we beetje bij beetje meer.
Stel dat een bepaalde grafiek met XX% is gedaald/gegroeid en daar N minuten heeft gestaan vergeleken met de voorgaande periode van M uur? Het lijkt erop dat je dit kunt proberen te implementeren met Grafana of Alertmanager, maar dat is nog niet zo eenvoudig. (Of misschien is het niet mogelijk, dat zeg ik nu niet)
Het wordt nog ingewikkelder wanneer de waarschuwingsbeslissing moet worden genomen op basis van gegevens uit verschillende bronnen. Live voorbeeld:
We controleren de gegevens uit twee Clickhouse-databases, vergelijken deze vervolgens met enkele gegevens van Postgres en beslissen over een waarschuwing. Signaal of annuleer
We hebben behoorlijk wat soortgelijke verlangens verzameld om over onze beslissing na te denken. En vervolgens hebben we geprobeerd de eerste lijst met vereisten/mogelijkheden van deze dienst samen te stellen, die nog niet is gemaakt.
-
toegang krijgen tot verschillende gegevensbronnen. Bijvoorbeeld Prometheus, Clickhouse, Postgres
-
stuur waarschuwingen naar verschillende kanalen - telegram, slack, enz.
-
tijdens het denkproces werd het duidelijk dat ik geen declaratieve beschrijving wilde, maar de mogelijkheid om scripts te schrijven
-
scripts uitvoeren volgens een schema
-
eenvoudige update van scripts zonder de service opnieuw te starten
-
de mogelijkheid om de functionaliteit op de een of andere manier uit te breiden zonder de service opnieuw op te bouwen vanuit broncodes
Deze lijst is bij benadering en hoogstwaarschijnlijk niet erg nauwkeurig. Sommige punten veranderden, sommige stierven. Alles is zoals gewoonlijk.
Eigenlijk is dit hoe de geschiedenis van Balerter begon.
Ik zal proberen kort te beschrijven wat er uiteindelijk is gebeurd en hoe het werkt. (Ja, dit is natuurlijk niet het einde. Er zijn veel plannen voor productontwikkeling. Ik stop gewoon bij vandaag)
Hoe werkt het?
Je schrijft een script in Lua waarbij je expliciet verzoeken stuurt (naar Prometheus, Clickhouse, etc.). Je ontvangt antwoorden en verwerkt en vergelijkt ze op de een of andere manier. Schakel vervolgens een soort waarschuwing in/uit. De Balerter stuurt zelf een melding naar de kanalen die u hebt geconfigureerd (e-mail, telegram, slack, enz.). Het script wordt met gespecificeerde intervallen uitgevoerd. En... in het algemeen is dat alles)
Het is het beste om met een voorbeeld te laten zien:
-- @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 Wat is hier aan de hand:
-
we geven aan dat dit script elke 10 seconden moet worden uitgevoerd
-
geef de naam van het script aan (voor de API, voor weergave in logs, voor gebruik in tests)
-
sluit de module aan voor het uitvoeren van logs
-
sluit een module aan om toegang te krijgen tot het clickhouse met de naam
ch1(de verbinding zelf wordt geconfigureerd in de configuratie) -
stuur een verzoek naar clickhouse
-
in geval van een fout geven we een bericht weer in het logboek en sluiten we af
-
vergelijk het zoekresultaat met een constante (in een live voorbeeld kunnen we deze waarde bijvoorbeeld verkrijgen uit de Postgres-database)
-
waarschuwing met ID in- of uitschakelen
rps-min-limit -
u ontvangt een melding als de alarmstatus is gewijzigd
Het voorbeeld is vrij eenvoudig en begrijpelijk. In het echte leven kunnen scripts echter behoorlijk lang en complex zijn. Het is gemakkelijk om in de war te raken en fouten te maken.
Daarom is een logische wens volwassen geworden: om tests voor uw scripts te kunnen schrijven. En in versie v0.4.0 verscheen dit.
Scripts testen
Voorbeeldtest voor ons script uit het bovenstaande voorbeeld:
-- @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')De stappen:
-
geef de naam aan van het script waarvoor de test is geschreven
-
testnaam (voor logs)
-
sluit de testmodule aan
-
wij zeggen welk resultaat moet worden teruggestuurd voor een specifiek verzoek naar het clickhouse
ch1 -
we controleren of de waarschuwing (fout) rps-min-limit met het opgegeven bericht is aangeroepen
-
controleer of de waarschuwing rps-min-limit niet is uitgeschakeld (succes)
Wat kan Balerter nog meer doen?
Ik zal proberen de belangrijkste, naar mijn mening, Balerter-vaardigheden aan te pakken. Je kunt alles in detail bekijken op de officiële website
-
gegevens ontvangen van
-
klikhuis
-
postgres
-
mysql
-
Prometheus
-
loki
-
-
stuur meldingen naar kanalen
-
speling
-
telegram
-
syslog
-
notificeren (UI-meldingen op uw computer)
-
email
-
onenigheid
-
-
maak grafieken op basis van uw gegevens, upload de afbeelding naar S3-compatibele opslag en voeg deze toe aan meldingen ()
-
stelt u in staat gegevens uit te wisselen tussen scripts - globale sleutel-/waardeopslag
-
schrijf je eigen bibliotheken in Lua en gebruik ze in scripts (standaard worden lua-bibliotheken meegeleverd voor het werken met json, csv)
-
HTTP-verzoeken verzenden vanuit uw scripts (en uiteraard antwoorden ontvangen)
-
biedt een API (nog niet zo functioneel als we zouden willen)
-
exporteert statistieken in Prometheus-formaat
Wat zou je nog meer willen kunnen doen?
Het is al duidelijk dat gebruikers en wij de mogelijkheid willen hebben om de lancering van scripts te controleren met behulp van de syntaxis cron. Dit zal vóór versie v1.0.0 gebeuren
Ik wil graag meer gegevensbronnen en kanalen voor het leveren van meldingen ondersteunen. Iemand zal MongoDB bijvoorbeeld zeker missen. Elastisch Zoek er een paar. Stuur een sms en/of bel naar uw mobiele telefoon. We willen niet alleen scripts uit bestanden kunnen ontvangen, maar bijvoorbeeld ook uit een database. Uiteindelijk willen we een gebruiksvriendelijkere website en betere documentatie voor het project.
Iemand mist altijd iets) Hier vertrouwen we op het verzoek van de gemeenschap om de juiste prioriteiten te stellen. En aan de hulp van de gemeenschap om alles te realiseren
Concluderend
We gebruiken Ik heb het al een tijdje. Tientallen scripts bewaken onze gemoedsrust. Ik hoop dat dit werk nuttig zal zijn voor iemand anders.
En welkom met uw probleem en PR.
Bron: www.habr.com