לוגו זפירנט

מדריך מעשי לניטור וצפייה של התקני IoT

תאריך:

מדריך מעשי לניטור וצפייה של התקני IoT

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

האם עלי לפקח או האם עלי להתבונן?

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

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

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

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

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

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

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

מדדים חיוניים וגישות ניטור

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

האם אנחנו מקבלים את הנתונים?

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

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

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

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

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

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

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

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

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

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

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

אותות אחרים לתחום ספציפי

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

הן עבור היומנים והן עבור העקבות, אתה יכול לסמוך שוב על המערכת האקולוגית של OpenTelemetry. זה מאפשר לך לנתח יומנים ועקבות באמצעות הקצה האחורי המועדף עליך, כגון Grafana Loki/Tempo או מחסנית ה- Elastic Observability, ללא מאמץ נוסף! העברת הודעות היא, לעומת זאת, פונקציונליות הליבה של כל פלטפורמת IoT סבירה. במילים אחרות, גישות אלו צריכות להיות טריוויאליות ליישום ברוב התרחישים.

הפשטות של יומנים

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

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

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

התובנות ההקשריות העמוקות עם עקבות

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

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

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

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

חזרה ליסודות עם הודעות פשוטות

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

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

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

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

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

המנות העיקריות

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

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

המודיעין האחרון

ספוט_ימג