עבודה קלה עם התראות מורכבות. או ההיסטוריה של באלרטר

כולם אוהבים התראות.

כמובן שהרבה יותר טוב לקבל הודעה כשמשהו קרה (או תוקן) מאשר לשבת ולהסתכל על גרפים ולחפש חריגות.

וכלים רבים נוצרו לכך. Alertmanager מהמערכת האקולוגית של Prometheus ו-vmalert מקבוצת המוצרים VictoriaMetrics. התראות והתראות Zabbix בגרפאנה. סקריפטים שנכתבו בעצמם ב-bash ובבוטים של Telegram שמרימים מעת לעת כתובת URL כלשהי ואומרים לך אם משהו לא בסדר. הרבה מהכל.

גם אנחנו, בחברה שלנו, השתמשנו בפתרונות שונים עד שנתקלנו במורכבות, או ליתר דיוק, בחוסר האפשרות ליצור התראות מורכבות ומורכבות. מה שרצינו ומה שעשינו בסופו של דבר זה מתחת לגזרה. TLDR: כך הופיע פרויקט הקוד הפתוח Balerter

במשך די הרבה זמן חיינו טוב עם התראות שהוגדרו בגרפאנה. כן, זו לא הדרך הטובה ביותר. תמיד מומלץ להשתמש בכמה פתרונות מיוחדים, כגון Alertmanager. וגם הסתכלנו לעבר תנועה יותר מפעם אחת. ואז, לאט לאט, רצינו יותר.

נגיד מתי תרשים מסוים ירד/עלה ב-XX% והיה שם N דקות בהשוואה לתקופה הקודמת של M שעות? נראה שאתה יכול לנסות ליישם את זה עם Grafana או Alertmanager, אבל זה לא ממש קל. (או שאולי זה לא אפשרי, אני לא אגיד עכשיו)

הדברים מסתבכים עוד יותר כאשר החלטת ההתראה חייבת להיעשות על סמך נתונים ממקורות שונים. דוגמה חיה:

אנחנו בודקים את הנתונים משני מסדי נתונים של Clickhouse, ואז משווים אותם לכמה נתונים מ-Postgres ומחליטים על התראה. סימן או בטל

צברנו די הרבה רצונות דומים כדי שנחשוב על ההחלטה שלנו. ואז ניסינו להרכיב את הרשימה הראשונה של דרישות/יכולות של השירות הזה, שעדיין לא נוצרה.

• לגשת למקורות נתונים שונים. לדוגמה, Prometheus, Clickhouse, Postgres

• לשלוח התראות לערוצים שונים - טלגרם, slack וכו'.

• בתהליך החשיבה התברר שאני לא רוצה תיאור הצהרתי, אלא יכולת לכתוב תסריטים

• הפעלת סקריפטים לפי לוח זמנים

• עדכון קל של סקריפטים מבלי להפעיל מחדש את השירות

• היכולת להרחיב איכשהו את הפונקציונליות מבלי לבנות מחדש את השירות מקודי מקור

רשימה זו היא משוערת וסביר להניח שאינה מדויקת במיוחד. חלק מהנקודות השתנו, חלק מתו. הכל כרגיל.

למעשה, כך התחיל הסיפור של בלטר.

אנסה לתאר בקצרה מה קרה בסופו של דבר ואיך זה עובד. (כן, כמובן, זה לא הסוף. יש הרבה תוכניות לפיתוח מוצר. אעצור רק היום)

איך זה עובד?

אתה כותב תסריט ב-Lua שבו אתה שולח בקשות (לפרומתאוס, קליקהאוס וכו'). אתה מקבל תשובות ואיכשהו מעבד ומשווה אותן. לאחר מכן הפעל/כבה התראה כלשהי. Balerter עצמה תשלח הודעה לערוצים שהגדרתם (מייל, מברק, 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, להצגה ביומנים, לשימוש בבדיקות)

• חבר את המודול להוצאת יומנים

• חבר מודול כדי לגשת אל בית הקליק עם השם ch1 (החיבור עצמו מוגדר בתצורה)

• שלח בקשה לקליקהאוס

• במקרה של שגיאה, אנו מציגים הודעה ביומן ויוצאים

• השווה את תוצאת השאילתה עם קבוע (בדוגמה חיה, נוכל לקבל ערך זה, למשל, ממסד הנתונים של Postgres)

• הפעל או השבת התראה עם מזהה 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')

בשלבים הבאים:

• ציינו את שם התסריט שעבורו נכתב המבחן

• שם בדיקה (עבור יומנים)

• חבר את מודול הבדיקה

• אנו אומרים איזו תוצאה יש להחזיר עבור בקשה ספציפית לבית הקליק ch1

• אנו בודקים שההתראה (שגיאה) rps-min-limit עם ההודעה שצוינה נקראה

• בדוק שהתראת rps-min-limit לא הושבתה (הצלחה)

מה עוד יכול באלטר לעשות?

אנסה לגעת בכישורי הבאלר החשובים ביותר לדעתי. אתה יכול לראות הכל בפירוט באתר הרשמי https://balerter.com

• לקבל נתונים מ

  • בית קליק

  • postgres

  • MySQL

  • פרומתאוס

  • לוקי

• לשלוח הודעות לערוצים

  • רָפוּי

  • מברק

  • syslog

  • התראה (הודעות ממשק משתמש במחשב שלך)

  • אמייל

  • מחלוקת

• בנה גרפים על סמך הנתונים שלך, העלה את התמונה לאחסון תואם S3 וצרף אותה להתראות (דוגמה עם תמונות)

• מאפשר לך להחליף נתונים בין סקריפטים - אחסון מפתח/ערך גלובלי

• כתוב ספריות משלך ב-Lua והשתמש בהן בסקריפטים (כברירת מחדל, ספריות lua מסופקות לעבודה עם json, csv)

• שלח בקשות HTTP מהסקריפטים שלך (וקבל תגובות, כמובן)

• מספק API (עדיין לא פונקציונלי כפי שהיינו רוצים)

• מייצא מדדים בפורמט פרומתאוס

מה עוד היית רוצה להיות מסוגל לעשות?

כבר ברור שמשתמשים ואנחנו רוצים את היכולת לשלוט בהשקת סקריפטים באמצעות התחביר cron. זה ייעשה לפני גרסה v1.0.0

אני רוצה לתמוך במקורות נתונים נוספים ובערוצי מסירת הודעות. לדוגמה, מישהו בהחלט יתגעגע ל-MongoDB. חיפוש אלסטי עבור כמה. שלח SMS ו/או בצע שיחות לטלפון הנייד שלך. אנחנו רוצים להיות מסוגלים לקבל סקריפטים לא רק מקבצים, אלא גם, למשל, ממסד נתונים. בסופו של דבר, אנחנו רוצים אתר ידידותי יותר למשתמש ותיעוד טוב יותר עבור הפרויקט.

מישהו תמיד מפספס משהו) כאן אנו מסתמכים על בקשת הקהילה על מנת לקבוע סדר עדיפויות נכון. ולעזרת הקהילה לממש הכל

לסיכום

אנו משתמשים Balerter יש לי את זה די הרבה זמן עכשיו. עשרות תסריטים שומרים על שלוות הנפש שלנו. אני מקווה שהעבודה הזו תהיה שימושית למישהו אחר.

וברוך הבא עם הנושא ויחסי הציבור שלך.

מקור: www.habr.com