החזר קטנוע חסר, או את הסיפור של ניטור IoT אחד

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

בתחילה, הפרויקט נקרא Road-To-Barcelona, ​​מאוחר יותר הוא הפך ל-Road-To-Berlin (ולכן R2B בצילומי המסך), ובסופו של דבר הוא נקרא xRide.

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

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

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

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

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

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

איך למצוא אותו ולהחזיר אותו?

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

מה ולמה לנטר: קטנועים, תשתיות, עמדות טעינה?

אז מה רצינו לעקוב בפרויקט שלנו?

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

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

קטנועים

מה היו הקורקינטים שלנו ומה רצינו לדעת עליהם?

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

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

כמובן, יש צורך גם לבדוק מה קורה עם רכיבי החומרה שלנו:

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

ולבסוף: בדיקות של התוכנה, החל ממערכת ההפעלה והמעבד, עומס הרשת והדיסק, וכלה בבדיקות של המודולים שלנו הספציפיים יותר לנו (ג'ולוקום, גלימת מפתח).

חומרה

מה היה חלק ה"ברזל" שלנו?

בהתחשב בטווח הזמן הקצר ביותר האפשרי ובצורך ביצירת אב טיפוס מהיר, בחרנו באפשרות הקלה ביותר ליישום ובחירת רכיבים - Raspberry Pi.
בנוסף ל-Rpi עצמו, היה לנו לוח מותאם אישית (שאותו פיתחנו בעצמנו והזמנו מסין כדי לזרז את תהליך ההרכבה של הפתרון הסופי) וסט רכיבים - ממסר (להפעלה/כיבוי של הקטנוע), קורא טעינת סוללה, מודם, אנטנות. כל זה היה ארוז בצורה קומפקטית בקופסת "xRide" מיוחדת.

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

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

דוקר? לינוקס רגילה? ופריסה

נחזור לניטור, אז פטל - מה יש לנו?

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

לרוע המזל, מהר מאוד התברר כי ל-Docker ב-RPi, למרות שהוא עובד, יש הרבה תקורה, במיוחד במונחים של צריכת חשמל.

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

הסיבה השנייה הייתה אחת מספריות השותפים שלנו ב-Node.js (sic!) - הרכיב היחיד של המערכת שלא נכתב ב-Go/C/C++.

מחברי הספרייה לא הספיקו לספק גרסת עבודה באף אחת מהשפות ה"ילידים".

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

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

OS

כתוצאה מכך, שוב, בחרנו באפשרות הפשוטה ביותר כמערכת ההפעלה והשתמשנו ב-Raspbian (Debian build עבור Pi).

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

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

לפרוס

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

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

מכלי עזר פשוטים יחסית, בעיקר עדכון/אתחול כפול כמו swupd/SWUpdate/OSTree לפלטפורמות מלאות כמו Mender ו-Balena.

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

את עצמה בלנה לא נכלל בשל העובדה שהוא משתמש באותו Docker בתוך balenaEngine שלו.

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

לכן, בסופו של דבר הבחירה נפלה על משדר. Mender היא פלטפורמה מלאה להרכבה, אספקה ​​והתקנה של קושחה.

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

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

בלתי אפשרי

הפתרון הפשוט ביותר במצבנו היה להשתמש ב-Ansible. כמה ספרי משחק הספיקו כדי להתחיל.

המהות שלהם הייתה שפשוט התחברנו מהמארח (שרת CI) דרך ssh ל-rasberries שלנו והפצנו להם עדכונים.

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

במשרד היו פשוט תריסר פטל בדיקה המחוברים לאותה רשת, לכל מכשיר הייתה כתובת IP סטטית שצוינה גם ב-Ansible Inventory.

זה היה Ansible שמסר את סוכן הניטור שלנו למכשירי הקצה

3G / LTE

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

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

במציאות, לקטנועים לא יהיה חיבור כלל מלבד 3G/LTE נייד (וגם אז לא כל הזמן).

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

אבל הדבר החשוב ביותר הוא שברשת 3G/LTE אנחנו לא יכולים פשוט להסתמך על IP סטטי שהוקצה לרשת.

זה נפתר חלקית על ידי חלק מספקי כרטיסי ה-SIM; ישנם אפילו כרטיסי סים מיוחדים המיועדים למכשירי IoT עם כתובות IP סטטיות. אבל לא הייתה לנו גישה לכרטיסי סים כאלה ולא יכולנו להשתמש בכתובות IP.

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

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

VPN

כפתרון לבעיה זו, בחרנו ב-VPN - ספציפית מגן.

לקוחות (קטנועים) בתחילת המערכת התחברו לשרת ה-VPN והצליחו להתחבר אליהם. המנהרה הזו שימשה להעברת עדכונים.

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

משאבי ענן

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

נָתוּן

אוף, נראה שסידרנו את התיאור, בוא נעשה רשימה של מה שהיינו צריכים בסופו של דבר:

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

התמונה הסופית נראתה בערך כך

בחירת מחסנית

אז, עמדנו בפני השאלה של בחירת ערימת ניטור.

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

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

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

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

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

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

(ב)ELK?

הפתרון הראשון שנחשב למעשה היה מחסנית ה-ELK הידועה.
למעשה, זה צריך להיקרא BELK, כי הכל מתחיל בביטס - https://www.elastic.co/what-is/elk-stack

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

התכוונו ש-ELK ישמש לאיסוף יומנים וכן אחסון לטווח ארוך של מדדים המתקבלים מפרומתאוס.

להדמיה ניתן להשתמש בגרפן.

למעשה, מחסנית ה-ELK החדשה יכולה לאסוף מדדים באופן עצמאי (metricbeat), וגם Kibana יכולה להציג אותם.

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

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

באופן כללי, המדדים ב-ELK כבדים ועדיין לא נוחים כמו בפתרונות אחרים, מהם יש כיום הרבה יותר מסתם פרומתאוס: TSDB, Victoria Metrics, Cortex וכו' וכו'. כמובן, הייתי מאוד רוצה לקבל פתרון All-in-one מלא מיד, אבל במקרה של metricbeat היו יותר מדי פשרות.

ולמחסנית ELK עצמה יש מספר רגעים קשים:

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

אני חייב לומר שלאחרונה הנקודה האחרונה הפכה טובה יותר ובנוסף פלט ב-X-pack בקוד פתוח (כולל אימות) מודל התמחור עצמו החל להשתנות.

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

לוקי - גרפנה - פרומתאוס

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

לרוע המזל, בזמן התחלת פיילוט המכירות של הפרויקט (ספטמבר-אוקטובר 19), לוקי עדיין הייתה בגרסת בטא 0.3-0.4, ובזמן תחילת הפיתוח לא ניתן היה להתייחס אליה כפתרון ייצור. בכלל.

עדיין אין לי ניסיון בשימוש בפועל של Loki בפרויקטים רציניים, אבל אני יכול לומר ש-Promtail (סוכן לאיסוף בולי עץ) עובד מצוין גם עבור מתכת חשופה וגם עבור תרמילים ב-kubernetes.

תִקתוּק

אולי החלופה הראויה ביותר (היחידה?) המלאה לערימת ה-ELK יכולה להיקרא כעת רק מחסנית TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.

אני אתאר את כל הרכיבים להלן ביתר פירוט, אבל הרעיון הכללי הוא זה:

• טלגרף - סוכן לאיסוף מדדים
• InfluxDB - מסד נתונים של מדדים
• Capacitor - מעבד מדדים בזמן אמת להתראה
• Chronograf - פאנל אינטרנט להדמיה

עבור InfluxDB, Kapacitor ו-Chronograf יש תרשימי הגה רשמיים שבהם השתמשנו כדי לפרוס אותם.

יש לציין כי בגרסה האחרונה של Influx 2.0 (בטא), Capacitor ו-Chronograf הפכו לחלק מ-InfluxDB ואינם קיימים יותר בנפרד

טלגרף

טלגרף הוא סוכן קל מאוד לאיסוף מדדים במכונת מצב.

הוא יכול לפקח על כמות עצומה של הכל, מ nginx до
שרת Minecraft.

יש לו מספר יתרונות מגניבים:

• מהיר וקל משקל (כתוב ב-Go)
  • אוכלת כמות מינימלית של משאבים
• מדדי דחיפה כברירת מחדל
• אוסף את כל המדדים הדרושים
  • מדדי מערכת ללא כל הגדרות
  • מדדי חומרה כגון מידע מחיישנים
  • קל מאוד להוסיף מדדים משלך
• הרבה תוספים מחוץ לקופסה
• אוסף יומנים

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

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

Influx מציעה את החוויה הנוחה ביותר לעבודה עם יומנים אם אתה משתמש syslog.

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

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

InfluxDB

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

גם InfluxDB כתוב ב-Go ונראה שהוא פועל הרבה יותר מהר בהשוואה ל-ELK על האשכול (לא החזק ביותר) שלנו.

אחד היתרונות המגניבים של Influx יכלול גם API נוח ועשיר מאוד לשאילתות נתונים, שבו השתמשנו באופן פעיל מאוד.

חסרונות - $$$ או קנה מידה?

לערימת TICK יש רק חיסרון אחד שגילינו - הוא יקירתי. אפילו יותר.

מה יש לגרסה בתשלום שאין לגרסה החינמית?

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

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

אם אתה רוצה HA מלא, אתה צריך לשלם או להשתמש בקביים. יש כמה פתרונות קהילתיים - למשל influxdb-ha נראה כמו פתרון מוכשר, אבל כתוב שהוא לא מתאים לייצור, כמו גם
זרימה-זרבובית - פתרון פשוט עם שאיבת נתונים דרך NATS (גם זה יצטרך לעבור קנה מידה, אבל זה יכול להיפתר).

חבל, אבל נראה שניהם נטושים - אין התחייבויות טריות, אני מניח שהנושא הוא השחרור הצפוי בקרוב של הגרסה החדשה של Influx 2.0, בה הרבה דברים יהיו שונים (אין מידע על קנה מידה בו עדיין).

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

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

ויקטוריה מדדים?

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

יש הרבה מסדי נתונים של סדרות זמן, אבל המבטיח שבהם הוא Victoria Metrics, יש לו מספר יתרונות:

• מהיר וקל, לפחות לפי התוצאות אמות מידה
• יש גרסת אשכול, שעליה יש אפילו ביקורות טובות עכשיו
  • היא יכולה לרסק
• תומך בפרוטוקול InfluxDB

לא התכוונו לבנות מחסנית מותאמת אישית לחלוטין המבוססת על ויקטוריה והתקווה העיקרית הייתה שנוכל להשתמש בה כתחליף ל-InfluxDB.

למרבה הצער, זה לא אפשרי, למרות העובדה שפרוטוקול InfluxDB נתמך, הוא עובד רק עבור הקלטת מדדים - רק ה-Prometheus API זמין "בחוץ", מה שאומר שלא ניתן יהיה להגדיר עליו Chronograf.

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

ברור, מאותה סיבה, ה-VM אינו יכול לאחסן יומנים כמו Influx.

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

בחירת בסיס

כתוצאה מכך, הוחלט שלפיילוט עדיין נגביל את עצמנו לצומת InfluxDB בודד.

היו מספר סיבות עיקריות לבחירה זו:

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

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

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

החלטנו על הערימה והבסיס - עכשיו לגבי שאר הרכיבים של ערימת ה-TICK.

קבל

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

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

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

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

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

ב-Influx 2.0 Capacitor הפך לחלק מ-DB

כרונוגרף

ראיתי הרבה פתרונות ממשק משתמש שונים לניטור, אבל אני יכול לומר שמבחינת פונקציונליות ו-UX, שום דבר לא משתווה ל-Chronograf.

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

עם זאת, Grafana הוא עדיין מכשיר אוניברסלי לחלוטין, בעוד Chronograf מיועד בעיקר לשימוש עם Influx.

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

אולי הנוחות העיקרית בעבודה עם Chronograf היא שאתה יכול לראות את החלק הפנימי של InfluxDB שלך דרך Explore.

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

ל-Kibana יש יכולות עשירות הרבה יותר ליצירת לוחות מחוונים ובקרות עבורם, אבל ה-UX לפעולות כאלה מורכב מאוד.

תידרש הבנה טובה כדי ליצור לוח מחוונים נוח. ולמרות שהפונקציונליות של לוחות המחוונים Chronograf פחותה, היצירה וההתאמה האישית שלהם הרבה יותר פשוטה.

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

כך נראה חלון השאילתה:

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

וכמובן, Chronograf נוח ככל האפשר לצפייה ביומנים. זה נראה כמו זה:

כברירת מחדל, יומני Influx מותאמים לשימוש ב-syslog ולכן יש להם פרמטר חשוב - חומרה.

הגרף בחלק העליון שימושי במיוחד; עליו ניתן לראות את השגיאות המתרחשות והצבע מראה מיד בבירור אם החומרה גבוהה יותר.

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

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

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

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

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

אימות

ראוי גם להזכיר ש-Chronograf תומך ב-OAuth וב-OIDC כאימות.

זה מאוד נוח, מכיוון שהוא מאפשר לך לצרף אותו בקלות לשרת שלך וליצור SSO מלא.

במקרה שלנו, השרת היה גלימת מפתח - הוא שימש לחיבור לניטור, אבל אותו שרת שימש גם לאימות קטנועים ובקשות לחלק האחורי.

"מנהל"

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

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

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

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

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

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

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

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

ובכלל זה היה יותר כיף ככה. משפטים כמו "חבר'ה, סמית'רס מת!" נשמעו כל הזמן.

מדדי מחרוזת

חשוב ש-InfluxDB יאפשר לך לאחסן לא רק ערכים מספריים, כפי שקורה ב-Victoria Metrics.

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

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

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

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

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

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

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

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

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

זה היה מאוד שימושי עבורנו כשחיפשנו קטנוע (ראה מסקנות בסוף).

ניטור תשתיות

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

ארכיטקטורה כללית מאוד נראתה בערך כך:

אם נדגיש ערימת ניטור טהורה, זה נראה כך:

מה שנרצה לבדוק בענן הוא:

• מאגרי מידע
• גלימת מפתח
• שירותי מיקרו

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

למרבה המזל, Telegraf out of the box יכול לאסוף מספר עצום של מדדים לגבי מצבו של אשכול Kubernetes, ו- Chronograf מציעה מיד לוחות מחוונים יפים לכך.

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

ישנן שתי דרכים לעקוב אחר תרמילים ב-Kubernetes: DaemonSet ו-Sidecar.
שתי השיטות מתוארות בפירוט בפוסט זה בבלוג.

השתמשנו ב-Telegraf Sidecar ובנוסף למדדים, אספנו יומני תרמילים.

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

ניטור מוניטור???

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

למרות ש-Telegraf יכולה לשלוח מדדים משלה או לאסוף מדדים ממסד הנתונים של InfluxDB לשליחה לאותה Influx או למקום אחר.

ממצאים

אילו מסקנות הסקנו מתוצאות הפיילוט?

איך אתה יכול לעשות ניטור?

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

כל הפונקציונליות שהיינו צריכים הייתה קיימת. כל מה שעשינו איתו עבד ללא בעיות.

פרודוקטיביות

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

לא אספנו נתונים/נתונים מדויקים של עומס, אבל אספנו נתונים מכ-30 קטנועים בו זמנית.

כל אחד מהם אסף יותר משלושה תריסר מדדים. במקביל נאספו יומנים מהמכשירים. איסוף ושליחת נתונים התרחשו כל 10 שניות.

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

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

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

במקרים מסוימים, אם צפייה ביומנים עדיין הייתה נחוצה, פשוט התחברנו דרך WireGuard דרך VPN.

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

בסביבת הפיתוח העלינו מופע נפרד של InfluxDB שהמשיך לאסוף נתונים כל 10 שניות ולא נתקלנו בבעיות ביצועים.

TICK - אידיאלי לפרויקטים קטנים עד בינוניים

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

אם אין לך אלפי פודים או מאות מכונות, אפילו מופע אחד של InfluxDB יטפל בעומס מצוין.

במקרים מסוימים, אתה עשוי להיות מרוצה מ-Influx Relay כפתרון פרימיטיבי של High Availability.

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

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

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

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

נכון, אני שוב אסתיג שלוקי/גרפאנה הרבה פחות נוחים (בשל הוורסטיליות הרבה יותר שלהם) מה-TICK המוכן, אבל הם בחינם.

זה חשוב: כל המידע המתואר כאן רלוונטי לגרסה Influx 1.8, כרגע Influx 2.0 עומד לצאת לאור.

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

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

איך לא ליצור פלטפורמות IoT (עכשיו)

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

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

אנו מרוצים לחלוטין מהתוצאה הסופית ומהפלטפורמה המבוססת על Ansible + TICK + WireGuard שהרכבנו בעצמנו. אבל היום, הייתי ממליץ להסתכל מקרוב על Balena לפני שתנסה לבנות פלטפורמת IoT משלך בעצמך.

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

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

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

היי, מה עם הקטנוע החסר?

אז הקטנוע, "ראלף", נעלם ללא עקבות.

רצנו מיד להסתכל על המפה ב"פאנל הניהול" שלנו, עם נתוני מדדי GPS מ-InfluxDB.

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

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

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

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

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

מקור: www.habr.com