მარტივი მუშაობა რთული გაფრთხილებებით. ან ბალერტერის ისტორია

ყველას უყვარს გაფრთხილებები.

რა თქმა უნდა, ბევრად უკეთესია შეტყობინებები, როდესაც რაღაც მოხდა (ან გამოსწორდა), ვიდრე იჯდე და უყურო გრაფიკებს და მოძებნო ანომალიები.

და ამისთვის შეიქმნა მრავალი ინსტრუმენტი. Alertmanager პრომეთეს ეკოსისტემიდან და vmalert VictoriaMetrics პროდუქციის ჯგუფიდან. Zabbix შეტყობინებები და გაფრთხილებები Grafana-ში. საკუთარი ხელით დაწერილი სკრიპტები bash-ში და Telegram-ის ბოტებში, რომლებიც პერიოდულად იღებენ URL-ებს და გეტყვიან, თუ რამე არასწორია. ბევრი ყველაფერი.

ჩვენ, ჩვენს კომპანიაში, ასევე ვიყენებდით სხვადასხვა გადაწყვეტილებებს, სანამ არ შეგვექმნა სირთულე, უფრო სწორად, რთული, კომპოზიტური სიგნალების შექმნის შეუძლებლობა. რა გვინდოდა და რისი გაკეთებაც დავასრულეთ, ქვემოთაა. TLDR: ასე გამოჩნდა ღია კოდის პროექტი ბალერიტერი

საკმაოდ დიდი ხნის განმავლობაში ჩვენ კარგად ვცხოვრობდით გრაფანაში კონფიგურირებული გაფრთხილებებით. დიახ, ეს არ არის საუკეთესო გზა. ყოველთვის რეკომენდებულია სპეციალიზებული გადაწყვეტილებების გამოყენება, როგორიცაა Alertmanager. ჩვენ ასევე გადავხედეთ გადაადგილებას არაერთხელ. შემდეგ კი, ნელ-ნელა, მეტი გვინდოდა.

თქვით, როდესაც გარკვეული დიაგრამა დაეცა/გაიზარდა XX%-ით და იყო იქ N წუთის განმავლობაში M საათის წინა პერიოდთან შედარებით? როგორც ჩანს, შეგიძლიათ სცადოთ ამის განხორციელება Grafana-სთან ან Alertmanager-თან, მაგრამ ეს არც ისე ადვილია. (ან შეიძლება ეს შეუძლებელია, ახლა არ ვიტყვი)

საქმე კიდევ უფრო რთულდება, როდესაც გაფრთხილების გადაწყვეტილება უნდა იქნას მიღებული სხვადასხვა წყაროს მონაცემებზე დაყრდნობით. ცოცხალი მაგალითი:

ჩვენ ვამოწმებთ მონაცემებს ორი Clickhouse მონაცემთა ბაზიდან, შემდეგ ვადარებთ მას Postgres-ის ზოგიერთ მონაცემს და ვწყვეტთ გაფრთხილებას. სიგნალი ან გაუქმება

საკმაოდ ბევრი მსგავსი სურვილი დაგვიგროვდა, რომ ჩვენს გადაწყვეტილებაზე ვიფიქროთ. შემდეგ კი შევეცადეთ შეგვედგინა ამ სერვისის მოთხოვნები/შესაძლებლობების პირველი სია, რომელიც ჯერ არ არის შექმნილი.

• წვდომა სხვადასხვა მონაცემთა წყაროებზე. მაგალითად, პრომეთე, Clickhouse, Postgres

• გაგზავნეთ შეტყობინებები სხვადასხვა არხებზე - ტელეგრამა, slack და ა.შ.

• ფიქრის პროცესში გაირკვა, რომ მე არ მინდოდა დეკლარაციული აღწერა, არამედ სკრიპტების დაწერის უნარი

• სკრიპტების გაშვება გრაფიკით

• სკრიპტების მარტივი განახლება სერვისის გადატვირთვის გარეშე

• შესაძლებლობა როგორმე გაფართოვდეს ფუნქციონირება წყაროს კოდებიდან სერვისის აღდგენის გარეშე

ეს სია არის მიახლოებითი და დიდი ალბათობით არც ისე ზუსტი. ზოგიერთი პუნქტი შეიცვალა, ზოგი გარდაიცვალა. ყველაფერი როგორც ყოველთვის.

სინამდვილეში, ასე დაიწყო ბალერტერის ისტორია.

შევეცდები მოკლედ აღვწერო რა მოხდა ბოლოს და როგორ მუშაობს. (დიახ, რა თქმა უნდა, ეს არ არის დასასრული. პროდუქტის განვითარების მრავალი გეგმა არსებობს. მე მხოლოდ დღეს შევჩერდები)

როგორ მუშაობს იგი?

თქვენ წერთ სკრიპტს ლუაში, სადაც პირდაპირ აგზავნით მოთხოვნებს (პრომეთეს, კლიკჰაუსს და ა.შ.). თქვენ იღებთ პასუხებს და როგორღაც ამუშავებთ და ადარებთ მათ. შემდეგ ჩართეთ/გამორთეთ რაიმე სახის გაფრთხილება. თავად ბალერტერი გაუგზავნის შეტყობინებას თქვენ მიერ დაკონფიგურირებულ არხებზე (ელფოსტა, ტელეგრამა, სლაკ და ა.შ.). სკრიპტი შესრულებულია მითითებულ ინტერვალებში. და... ზოგადად, სულ ესაა)

უმჯობესია აჩვენოთ მაგალითი:

-- @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 

Რა ხდება აქ:

• ჩვენ აღვნიშნავთ, რომ ეს სკრიპტი უნდა შესრულდეს ყოველ 10 წამში

• მიუთითეთ სკრიპტის სახელი (API-სთვის, ჟურნალებში გამოსატანად, ტესტებში გამოსაყენებლად)

• დააკავშირეთ მოდული ჟურნალების გამოსატანად

• დააკავშირეთ მოდული სახელით clickhouse-ზე წვდომისთვის ch1 (თავად კავშირი კონფიგურირებულია კონფიგურაციაში)

• გაგზავნეთ მოთხოვნა clickhouse-ზე

• შეცდომის შემთხვევაში ვაჩვენებთ შეტყობინებას ჟურნალში და გამოვდივართ

• შეადარეთ შეკითხვის შედეგი მუდმივთან (ცოცხალ მაგალითში, ჩვენ შეგვიძლია მივიღოთ ეს მნიშვნელობა, მაგალითად, Postgres მონაცემთა ბაზიდან)

• გაფრთხილების ჩართვა ან გამორთვა ID-ით rps-min-limit

• თქვენ მიიღებთ შეტყობინებას, თუ განგაშის სტატუსი შეიცვალა

მაგალითი საკმაოდ მარტივი და გასაგებია. თუმცა, რა თქმა უნდა, რეალურ ცხოვრებაში სკრიპტები შეიძლება იყოს საკმაოდ გრძელი და რთული. ადვილია დაბნეულობა და შეცდომების დაშვება.

ამიტომ მომწიფდა ლოგიკური სურვილი – შეგეძლოთ დაწეროთ ტესტები თქვენი სკრიპტებისთვის. და v0.4.0 ვერსიაში ეს გამოჩნდა.

სკრიპტების ტესტირება

ჩვენი სკრიპტის ტესტის მაგალითი ზემოთ მოცემული მაგალითიდან:

-- @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')

ნაბიჯებში:

• მიუთითეთ სცენარის დასახელება, რომელზედაც დაწერილია ტესტი

• ტესტის სახელი (ლოგისთვის)

• დააკავშირეთ ტესტირების მოდული

• ჩვენ ვამბობთ, რა შედეგი უნდა დაბრუნდეს კონკრეტული მოთხოვნისთვის clickhouse-ში ch1

• ჩვენ ვამოწმებთ, რომ გამოძახებული იყო გაფრთხილება (შეცდომა) rps-min-limit მითითებული გზავნილით

• შეამოწმეთ, რომ rps-min-limit გაფრთხილება არ იყო გამორთული (წარმატებული)

კიდევ რა შეუძლია ბალერტერს?

შევეცდები შევეხო ყველაზე მნიშვნელოვან, ჩემი აზრით, ბალერტერის უნარებს. ყველაფერი დეტალურად შეგიძლიათ ნახოთ ოფიციალურ ვებგვერდზე https://balerter.com

• მონაცემების მიღება

  • clickhouse

  • პოსტგრამა

  • mysql

  • პრომეთე

  • loki

• გაგზავნეთ შეტყობინებები არხებზე

  • slack

  • დეპეშა

  • syslog

  • შეტყობინება (UI შეტყობინებები თქვენს კომპიუტერზე)

  • ელფოსტაზე

  • უთანხმოება

• შექმენით გრაფიკები თქვენს მონაცემებზე დაყრდნობით, ატვირთეთ სურათი S3 თავსებად საცავში და მიამაგრეთ შეტყობინებებს (მაგალითი სურათებით)

• საშუალებას გაძლევთ გაცვალოთ მონაცემები სკრიპტებს შორის - გლობალური Key/Value საცავი

• დაწერეთ თქვენი საკუთარი ბიბლიოთეკები Lua-ში და გამოიყენეთ ისინი სკრიპტებში (ნაგულისხმევად, lua ბიბლიოთეკები მოწოდებულია json, csv-თან მუშაობისთვის)

• გაგზავნეთ HTTP მოთხოვნები თქვენი სკრიპტებიდან (და მიიღეთ პასუხები, რა თქმა უნდა)

• უზრუნველყოფს API-ს (ჯერ არ არის ისეთი ფუნქციონალური, როგორც ჩვენ გვსურს)

• მეტრიკის ექსპორტს პრომეთეს ფორმატში

კიდევ რისი გაკეთება გსურთ?

უკვე ნათელია, რომ მომხმარებლებს და ჩვენ გვინდა სკრიპტების გაშვების კონტროლი სინტაქსის გამოყენებით cron. ეს გაკეთდება v1.0.0 ვერსიამდე

მე მსურს მეტი მონაცემთა წყაროების და შეტყობინებების მიწოდების არხების მხარდაჭერა. მაგალითად, ვინმეს აუცილებლად გამოტოვებს MongoDB. ელასტიური ძებნა ზოგიერთისთვის. გაგზავნეთ SMS და/ან დარეკეთ თქვენს მობილურ ტელეფონზე. ჩვენ გვინდა შევძლოთ სკრიპტების მიღება არა მხოლოდ ფაილებიდან, არამედ, მაგალითად, მონაცემთა ბაზიდან. საბოლოო ჯამში, ჩვენ გვინდა უფრო მოსახერხებელი ვებსაიტი და უკეთესი დოკუმენტაცია პროექტისთვის.

ვიღაცას ყოველთვის რაღაც აკლია) აქ ჩვენ ვეყრდნობით საზოგადოების მოთხოვნას, რათა სწორად დავადგინოთ პრიორიტეტები. და საზოგადოების დახმარებას ყველაფრის რეალიზებაში

დასასრულს

ჩვენ ვიყენებთ ბალერიტერი უკვე საკმაოდ დიდი ხანია მაქვს. ათობით სცენარი იცავს ჩვენს სიმშვიდეს. ვიმედოვნებ, რომ ეს ნამუშევარი სხვისთვის გამოდგება.

და მივესალმები თქვენს საკითხს და PR-ს.

წყარო: www.habr.com