"ExtendedPromQL" - תמליל הדו"ח של רומן חברוןנקו

אני מציע לקרוא את תמליל הדו"ח של רומן חברוןנקו "ExtendedPromQL"

בקצרה עליי. שמי רומן. אני עובד עבור CloudFlare וגר בלונדון. אבל אני גם מתחזק של VictoriaMetrics.
ואני הסופר Plugin ClickHouse לגרפאנה ו ClickHouse-proxy הוא פרוקסי קטן עבור ClickHouse.

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

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

מה זה נתוני סדרות זמן? פשוטו כמשמעו, אלו שלושה פרמטרים.

זהו:

• על מה אנחנו מסתכלים.
• כשאנחנו מסתכלים על זה.
• ואיזה ערך זה מראה.

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

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

עכשיו בואו "נשבור" (נהפוך) אותם למודל נתונים אחר בצורה של טבלה. כאן יש לנו גם את מה שאנחנו מסתכלים עליו. כאן הוספתי עוד קצת נתונים, שנקרא להם meta-data, כלומר לא אני עברתי, אלא שני אנשים, למשל, ג'יי ובוב השקט. זה מה שאנחנו מסתכלים עליו; מה זה מראה ומתי זה מראה את הערך הזה.

עכשיו בואו ננסה לאחסן את כל הנתונים האלה במסד הנתונים. לדוגמה, לקחתי את תחביר ClickHouse. והנה אנחנו יוצרים טבלה אחת שנקראת "צעדים", כלומר מה שאנחנו מסתכלים עליו. יש כאן זמן שבו אנו מסתכלים על זה; מה זה מראה וכמה מטא נתונים שבהם נאחסן מי זה: ג'יי ובוב השקט.

וכדי לנסות לדמיין את הכל, נשתמש בגראפנה, כי ראשית, היא יפה.

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

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

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

וכתוצאה מכך, אנו מקבלים את הגרף הזה. מי יודע למה הוא כל כך מוזר?

נכון, צריך למיין לפי זמן.

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

לכן, עלינו לבחור אדם ספציפי. אנחנו בוחרים בג'יי.

ותצייר שוב. עכשיו הגרף נראה כמו האמת. עכשיו זה לוח זמנים רגיל והכל עובד כמו שצריך.

וכנראה שאתה יודע לעשות בערך את אותו הדבר, אבל ב-Prometheus דרך PromQL. בערך ככה. קצת יותר קל. ובואו נפרק את הכל. נקטנו בצעדים. וסנן לפי ג'יי. אנחנו לא מציינים כאן שצריך לקבל ערך ולא בוחרים זמן.

כעת ננסה לחשב את מהירות התנועה של ג'יי או בוב השקט. ב-ClickHouse, נצטרך לעשות runningDifference, כלומר, לחשב את ההפרש בין זוגות נקודות ולחלק אותם בזמן כדי לקבל את המהירות המדויקת. הבקשה תיראה בערך כך.

והוא יראה בערך את הערכים האלה, כלומר בערך 1,8 צעדים לשנייה עושה בוב השקט או ג'יי.

ובפרומתאוס גם אתה יודע איך לעשות את זה. הרבה יותר קל מבעבר.

וכדי שיהיה קל לעשות את זה גם בגרפאנה, הוספתי עטיפה כזו שנראית מאוד דומה ל-PromQL. זה נקרא Rate Macros, או איך שלא תרצו לקרוא לזה. בגרפאנה פשוט כותבים "שיעור", אבל איפשהו עמוק בפנים זה הופך לבקשה כל כך גדולה. ואתה אפילו לא צריך להסתכל על זה, זה שם איפשהו, אבל אתה חוסך הרבה זמן, כי כתיבת שאילתות SQL ענקיות כאלה היא תמיד יקרה. אתה יכול בקלות לטעות ואז לא להבין מה קורה במשך זמן רב.

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

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

בדקנו ונראה ש-PromQL הכל כל כך מגניב, אבל יש לו, כמובן, מגבלות.

זהו:

• SELECT מוגבל.
• Edge JOINs.
• אין תמיכה.

ואם עבדתם עם זה הרבה זמן, אז אתם יודעים שלפעמים מאוד קשה לעשות משהו ב-PromQL, וב-SQL אפשר לעשות כמעט הכל, כי את כל האפשרויות האלה שדיברנו עליהן אפשר לעשות ב-SQL . אבל האם זה יהיה נוח להשתמש בו? וזה גורם לי לחשוב שלא תמיד השפה החזקה ביותר יכולה להיות הנוחה ביותר.

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

והחלק הבא הוא הרחבת PromQL.

שוב על VictoriaMetrics. מה זה VictoriaMetrics? זהו מסד נתונים של סדרות זמן, הוא נמצא ב-OpenSource, אנו מפיצים את גרסאות היחידות והאשכולות שלו. לפי המדדים שלנו, הוא המהיר ביותר שיש בשוק כעת והוא דומה מבחינת דחיסה, כלומר אנשים חיים מדווחים על דחיסה של כ-0,4 בתים לנקודה, כאשר ל-Prometheus יש 1,2-1,4.

אנחנו תומכים לא רק בפרומתאוס. אנו תומכים ב-InfluxDB, Graphite, OpenTSDB.

אתה יכול "לכתוב" בנו, כלומר, אתה יכול להעביר נתונים ישנים.

ואנחנו גם עובדים בצורה מושלמת עם Prometheus ו-Grafana, כלומר אנחנו תומכים במנוע PromQL. ובגרפאנה, אתה יכול פשוט לשנות את נקודת הקצה של Prometheus ל-VictoriaMetrics וכל לוחות המחוונים שלך יעבדו כפי שהם פעלו.

אבל אתה יכול גם להשתמש בצ'יפים נוספים שמסופקים על ידי VictoriaMetrics.

נעבור במהירות על התכונות שהוספנו.

השמט פרמטר מרווח - ניתן לדלג על מרווח פרמטרים בגרפאנה. כאשר אתה לא רוצה לקבל גרפים מוזרים בעת זום-אין/אאוט בפאנל, מומלץ להשתמש במשתנה $__interval. זהו שינוי גרפאנה פנימי והוא בוחר את טווח הנתונים בעצמו. ו-VictoriaMetrics יכולה להבין בעצמה מה הטווח הזה צריך להיות. ואתה לא צריך לעדכן את כל הבקשות שלך. זה יהיה הרבה יותר קל.

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

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

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

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

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

Scrape_interval - מראה באיזו תדירות Prometheus אוסף נתונים על המדד שלך, באיזו תדירות. כאן תוכלו לראות את המעבר, למשל.

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

לכן, למה לא להפוך אותם לפשוטים יותר? כלומר, חלקו אותו לפונקציות קטנות עם תחביר ברור.

ועכשיו הכי מעניין. למה אנחנו חושבים שזה PromQL מורחב? מכיוון שאנו תומכים בביטויי טבלה נפוצים. אתה יכול לעקוב אחר קוד ה-QR (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), ראה קישורים עם דוגמאות, ממגרש המשחקים, שבו אתה יכול להריץ שאילתות ישירות ב-VictoriaMetrics מבלי להתקין אותו רק בדפדפן.

ומה זה? בקשה זו מלמעלה היא בקשה פופולרית למדי. אני חושב שבכל לוח מחוונים בחברות רבות אתה משתמש באותו פילטר לכל דבר. בדרך כלל כך. אבל כאשר אתה צריך להוסיף איזה מסנן חדש, אתה צריך לעדכן כל פאנל, או להוריד את לוח המחוונים, לפתוח אותו ב-JSON, לבצע חיפוש החלפה, וזה גם לוקח זמן. למה לא לאחסן את הערך הזה במשתנה ולהשתמש בו מחדש? זה נראה, לדעתי, הרבה יותר פשוט וברור.

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

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

וכך עשיתי אופציה שמאפשרת לך לעשות זאת. ואם אתה מעוניין או רוצה תכונה כזו, אז תמכו או לא תאהבו אם הרעיון הזה לא מוצא חן בעיניכם. https://github.com/grafana/grafana/pull/16694

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

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

Например, вот так, выделив значимые вещи или части в переменные. И потом произвести свою базовую математику. Это уже более похоже на программирование, это то, что я бы и хотел видеть в будущем в Grafana.

הנה דוגמה שנייה לאופן שבו נוכל להקל עוד יותר אם כבר הייתה לנו פונקציית ru זו, והיא כבר קיימת ישירות ב-VictoriaMetrics. ואז אתה פשוט מעביר את הערך השמור שהצהרת ב-CTE.

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

נניח שאין לך אפילו רק מהנדסי מערכת, אולי אפילו יש לך מומחים, מומחים או SREs. אולי יש לך מומחים שיודעים מה זה ניטור, יודעים מה זה גרפנה, כלומר הם עובדים עם זה שנים והם יודעים בדיוק איך לעשות את זה נכון. וכבר כתבו את זה 100 פעם והסבירו את זה לכולם, אבל משום מה אף אחד לא מקשיב.

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

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

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

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

קצת על VictoriaMetrics. אנחנו עושים הרבה דברים מעניינים. קרא את המאמרים שלנו על דחיסה, על התחרות שלנו עם יישומי נתונים אחרים של סדרות זמן, ההסבר שלנו על איך לעבוד עם PromQL, כי יש הרבה יותר מתחילים בזה, כמו גם על מדרגיות אנכית ועל עימות עם Thanos.

שאלות:

אתחיל את השאלה שלי בסיפור חיים פשוט. כשהתחלתי להשתמש בגראפאנה, כתבתי שאילתה מאוד משכנעת בת 5 שורות. התוצאה הסופית היא תרשים מאוד משכנע. הגרף הזה כמעט נכנס לייצור. אבל בבדיקה מעמיקה יותר, התברר שהתרשים הזה מראה שטויות מוחלטות שאין לה שום קשר למציאות, למרות שהמספרים נופלים בטווח שציפינו לראות. והשאלה שלי. יש לנו ספריות, יש לנו פונקציות, אבל איך כותבים מבחנים לגרפאנה? כתבת שאילתה מורכבת שמשפיעה על ההחלטה העסקית – להזמין קונטיינר אמיתי של שרתים או לא להזמין. וכידוע, הפונקציה הזו שמציירת גרף דומה לאמת. תודה.

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

כיצד לבדוק?

איך לבדוק? כנראה שלא.

כמבחן בגרפאנה.

ומה עם גרפנה? Grafana מתרגם בקשה זו ישירות ל-DataSource.

על ידי הוספת קצת לפרמטרים.

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

תודה על הדיווח! תודה על הדחיסה! נזכרת לגבי מיפוי משתנה בגרף, שבגרפאנה אתה לא יכול להשתמש במשתנה במשתנה. האם אתה מבין למה אני מתכוון?

כן.

זה היה בהתחלה כאב ראש כשרציתי להודיע ​​בגרפאנה. ושם אתה צריך לעשות התראה עבור כל מארח בנפרד. הנה הדבר הזה שעשית, האם זה עובד להתראות בגרפאנה?

אם Grafana לא ניגש למשתנים בדרך אחרת, אז כן, זה יעבוד. אבל העצה שלי היא בכלל לא להשתמש בהתראה בגראפנה, כדאי להשתמש ב-alertmanager.

כן, אני משתמש בזה, אבל זה פשוט נראה קל יותר להגדיר בגרפאנה, אבל תודה על הטיפ!

מקור: www.habr.com