בחברות קטנות עם מעט שרתים ותחנות עבודה, מנהלי מערכות בדרך כלל יכולים לזהות במהירות כל בעיה שמתרחשת ללא כלים מיוחדים. ככל שחברה גדלה, כך גם מספר השרתים והתקני הרשת האחרים. ואם משהו הולך לא נכון, מנהל המערכת עדיין חייב להיות מסוגל לזהות את הבעיה במהירות כדי למנוע בעיות רציניות.
חיפוש ידני אחר בעיה בתשתית בינונית או גדולה יכול להיות מורכב ולקחת זמן רב. למרבה המזל, ניטור אוטומטי של תשתית IT זמין כיום ברחבי העולם כדי לעזור למנהלים לזהות את סוג הבעיות ומקורן במהירות האפשרית. כלים אלו גם עוזרים למנהלים למנוע מראש בעיות ועומסים לפני שהם מתרחשים על ידי ניטור הקצאת משאבים וצריכה בזמן אמת.
פוסט זה בבלוג מסביר מהו ניטור תשתית IT, למה להשתמש בכלים לניטור שרתים והתקני רשת אחרים, ואילו מתודולוגיות מומלצות לעקוב אחריהן.
מהו ניטור תשתית IT?
ניטור תשתית הוא התהליך של מעקב אחר מדדים של חומרה ותוכנה בסביבה פיזית או וירטואלית כדי לשפר את היעילות ולמטב את התהליכים. זה נעשה על ידי איסוף וניתוח הנתונים על הזמינות, הביצועים, ושימוש במשאבים של חומרה ויישומים קריטיים.
תשתית IT היא המסגרת הבסיסית שמאפשרת לעסקים לספק שירותים, לבצע עסקאות, לספק מידע, להתקשר עם לקוחות וכו'. תשתית זו מורכבת ממרכזי נתונים, יישומים ותוכנה, רשתות, וחומרה כמו שרתים, נתבים וכו'.
סוגי ושיטות ניטור IT
בואו נבחן את שני הגישות העיקריות לניטור מבנה ה-IT.
- ניטור מבוסס סוכן ניתן לבצע באמצעות תוכנה של לקוח-שרת על ידי התקנת סוכנים על כל מכונית הנמדדת. סוג זה של כלי ניטור IT דורש התקנת רכיב השרת של תוכנת ניטור המערכת על שרת או מחשב וירטואלי. תוכנת השרת מקלטת את הנתונים האוספים במסד נתונים ומספקת ממשק אינטרנט למנהלים ולמשתמשים להגדרת תוכנת ניטור המערכת וניטור מבנה ה-IT.סוכן הוא הרכיב של תוכנת ניטור IT שמותקן על המכונה המרכזית ממנה יש לאסוף נתונים. הסוכן משתף פעולה עם השרת דרך הרשת ושולח את הנתונים האוספים לשרת הניטור. הסוכן צריך לתמיכה במערכות הפעלה רבות כדי לכסות טוב יותר את מבנה ה-IT.
- ניטור ללא סוכן ניתן לבצע באמצעות תוכנה של צד שרת ופרוטוקולי רשת מתמצאים מבלי להתקין תוכנת ניטור סוכנים על כל מכונית הנמדדת. זה יכול לשמש לפלטפורמות שונות, מה שמאוד שימושי אם אי אפשר להתקין את הסוכן הניטור (למשל, על ממסר או ראוטר).
תוכנת ניטור IT יכולה לבדוק את זמינות השירותים על מארח רחוק באמצעות פרוטוקולי ICMP, SSH, FTP, HTTP ו-DNS מבלי שיהיה סוכן ניטור מותקן על המארח הרחוק. תוכנת ניטור השרת מנסה לגשת למארח היעד דרך הפרוטוקול המוגדר, ותלוי בתגובת השרת, מגלה את מצב השירות הנחוץ.
שני הפרוטוקולים המשמשים הם:
- פרוטוקול ניהול רשת פשוט (SNMP)פותח במיוחד למשימות מעקב בלי להתקין סוכני מעקב על מארחים רחוקים. המארח הרחוק חייב להפעיל את השירות המתאים של SNMP כדי לתמוך באיסוף נתונים דרך SNMP מהמארח שמועקב. SNMP פועל על שכבת היישום של מודל OSI, והגרסה האחרונה היא SNMPv3. פרוטוקול SNMP נתמך בדרך כלל במתגים, נתיבים, נקודות גישה, חומות אש, מדפסות רשת ומכשירים אחרים המחוברים לרשת. כל מזהה אובייקט משוייך לפרמטר המתאים, כגון בתי המידע המקבלים, בתי המידע השולחים, טמפרטורת המעבד, רמת הטונר בקסטת המדפסת, וכו '. מזהי אובייקט מוספרים באמצעות מבנה הייררכי (דמוי עץ). לדוג' , 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16 הוא המזהה עבור חיישן הטמפרטורה של חומרת אינטל.
שימו לב כי סוכן SNMP אינו זהה לסוכן מעקב של תוכנות מעקב מערכת.
- WMI (Windows Management Instrumentation) הוא פרוטוקול רשת פטנט של מיקרוסופט שפותח למעקב אחר מערכות המבוססות על Windows בלי להתקין סוכנים. הכלי למעקב שולח שאילתת WMI למארח שמועקב ואז קורא את הנתונים שהוחזרו.
מעקב IT עבור מערכות מהולכות בווירטואליות
מעקב אחר מכונות ומיכלים יש להן תכונות משלהן שצריך לקחת בחשבון כדי להשיג את התוצאות הרצויות.
ניטור של מכונות וירטואליות. למכונות וירטואליות, יש להשתמש בתוכנות יישום לניטור ללא סוכן באמצעות API של VMware למעקב אחר ביצועים ויעילות של מארחי ESXi, שרתי vCenter ומכונות וירטואליות. מדדים לניטור כוללים שימוש במעבד, זיכרון, אחסון ורשת. גישה זו מאפשרת לך להימנע מעומסים בהשוואה לשיטה בה מותקנים סוכני ניטור על מכונות וירטואליות.
ניטור של תוכניות הוא מסובך בהשוואה לניטור של שרתים מסורתיים ומכונות וירטואליות. זה בגלל שתוכניות מתקנות/מורידות מהיר והן משתפות משאבים, מה שהופך קשה למדוד את המשאבים שנצרכים על ידי מארח. פיצוץ של N סוכנים ב-N תוכניות אינו רציונלי. דומה למכונות וירטואליות, תוכניות ניתן לנטור באמצעות API מיוחדים.
API ניטור סטטיסטיקות ספק עם תוכניות דוקר כדי לנטור אותן. הרעיון המרכזי של ניטור תוכניות הוא לנטור את היישומים של ארכיטקטורת השירותים המיקרו שרצים בתוכניות.
ניטור של תשתיות מחשוב: מרכיבים
בואו נבחן מרכיבים שונים שניתן לעקוב אחריהם באמצעות ניטור של תשתיות מחשוב כדי ללמוד עוד. סיווג זה של מרכיבים שנמצאים בניטור הוא תנאי משום שהם יכולים לחצות אחד עם השני.
- מעקב אחר החומרה עבור טמפרטורת המעבד, טמפרטורת הדיסק הקשיח, מצב ה-S.M.A.R.T. של הדיסק, נתוני חיי הסוללה, מתח ועוד. זיכרון פנוי, מקום פנוי בדיסק, פעילות בדיסק ושימוש בקובץ תצובה.
- מעקב אחר הרשת לשערוך יחסי תעבורה בממשקי הרשת השונים, מספר המשתמשים המחוברים (שימושי בחיבורי VPN), חיבורי הרשת, חומות אש, חיבורי TCP ו-UDP (לזיהוי תוכנות זדוניות) ועוד. זה יכול לעזור לך לזהות העמסת רשת, מהירות תעבורת נתונים נמוכה וניסיונות בלתי מורשים לגשת לרשת.
- מעקב אחרי היישום לבדיקת יומני היישום, כולל יומני מערכת הפעלה, זיהוי קודי שגיאה והצגת מידע מצטבר בממשק האינטרנט או שליחת התראות למנהלים. מעקב אחרי היישום יכול לכלול צריכת מעבד וזיכרון על ידי היישום.
- מעקב אחר הביטחון לזיהוי בעיות אבטחה וטיפול בפגיעות תוכנה, פתיחת יציאות, ורשיונות לא רצויים, שיכולים לשמש להתקפות בסביבתך.
- מעקב אחרי פעילות חיונית לזיהוי ניסיונות כניסה בלתי מורשים למערכת, שינויים בקבצים וכו '. מעקב אחרי קבצים ותיקיות יכול לעזור לך לזהות פעילויות לא רגילות שנגרמות על ידי תוכנות כולית ולהגיב במהירות כדי למנוע אובדן נתונים.
- מעקב אחר זמן פעילות לזיהוי האם מארח כבוי גם אם לא הייתה הבחנה (לדוגמה, שרת הופעל מחדש בלילה בשעות לא עובדות לאחר התקנת עדכונים אוטומטיים או לאחר הפסקת חשמל). ככל שהמארח פועל כראוי ללא איתור, המערכת יציבה ואמינה יותר.
שיטות מובילות לניטור תשתיות מערכות מידע
כדי להשיג את מירב היעילות בניטור, יש לעקוב אחרי שיטות הניטור המובילות בתחום. בעזרת הבנה ברורה של איך ליישם ניטור מערכות מידע, ניתן להפחית את סיכוני העצירות ולהגיב לבעיות בצורה יעילה יותר לפני שהמשתמשים מרגישים את ההשפעה השלילית של שירותים ויישומים שנכשלים.
בחירת הפתרון המתאים לניטור
כדי לבחור את הפתרון לניטור המתאים לצרכי הארגון שלך, יש לקבוע אילו רכיבים דורשים ניטור בתשתיות מערכות המידע שלך. לצורך כך, יש לסווג חומרה, מערכות, ויישומים בהתאם לחשיבותם לפעולות העסקיות.
לאחר מכן תוכל להגדיר את אסטרטגיית הניטור שלך ולבחור את התוכנה המתאימה לניטור תשתית המידע. האסטרטגיה שלך תכלול את החומרה והתוכנה שיש לנטור, אילו מדדים לנטור, עומק הניטור, ואיך להגיב כאשר יש בעיות. בהתאם לפרמטרים אלו, יש לבחור את תוכנת הניטור המתאימה לדרישות שלך.
אם יש צורך לנטור מכונות וירטואליות במארחי ESXi, יש לבחור פתרון שמגיע ל-VMs ברמת ההיפרווייזור במקום להתקין אפליקציות במערכת ההפעלה של האורח. תוכנת ניטור עסקית אוניברסלית תשלב אפליקציות לניטור מכונות פיזיות ו-APIs לניטור מארחי ההיפרווייזור ול-VMs. תוכנת ניטור כזו יכולה להשתמש בפרוטוקולים כמו SNMP לניטור של מכשירי רשת וציוד נוסף ולהשתמש ב-APIs מיוחדים לניטור פריטים בעננים של AWS ו-Azure.
איסוף מדדים רלוונטיים
שיטות הניטור המובילות ממליצות על גישות לקבלת מידע רלוונטי בכל עת:
- הגדר אילו מדדים יש לך למעקב אחרי עבור מכונות פיזיות, מכונות וירטואליות, יישומים, רשתות והתקנים שונים.
- בדוק באופן קבוע את מדדי הביצועים שלך והלוגים שמפוקחים.
- עבור על פרק זמן קבוע את מדדי המעקב שלך ובצע שינויים במעקב התשתית הממונה אם יש צורך.
קבע גישה ללוחות המחוונים הנכונים.
תוכנת מעקב לטכנולוגיות המידע בדרך כלל אוספת מידע ומציגה את המידע בתצוגה מתוקנת בממשק האינטרנט. ממשק אינטרנט בדרך כלל מכיל לוחות מחוונים עם מידע מוצג. מנהל מערכת ומשתמשים מורשים יכולים לפתוח את ממשק האינטרנט ולבדוק את המידע הסיכום, הגרפים, הסטטיסטיקות והמידע האחר לגבי התשתית כולה ושרתים, התקנים ויישומים ספציפיים.
הגדר מי צריך לצפות בנתוני המעקב. אפשר גישה למשתמשים למעקב רק לפי מה שהם זקוקים לו כדי לבצע את האחריות שלהם, בהתאם לעקרון הפריבילגיה הקטנה ביותר. קבע לוחות מחוונים מותאמים אישית לקבוצות שונות של משתמשים, לדוגמה:
- מתכנתים יכולים לעקוב אחרי שרתי מסדי נתונים, שרתי יישומים, שרתי אינטרנט ואשכולות Kubernetes שהם משתמשים בהם.
- בדיקת יכולים לעקוב אחרי שרתים ומכונות וירטואליות המשמשים לבדיקות.
- מנהלי מערכת יכולים לעקוב אחרי כל הפריטים.
- מנהלי מכירות עשויים לצורך לצפות במידע אודות מערכת CRM.
קבע התראות/הודעות אוטומטיות.
המנהלים והמשתמשים יכולים לבדוק את נתוני המעקב לפי דרישה בלוחות המחוונים המסופקים. זו אפשרות שימושית, אך איך ניתן להיות מודעים לבעיה מיידית? המנהלים אינם יכולים לבלות את כל היום במעקב אחר סטטיסטיקות. מכאן, רוב כלי מעקב ה-IT מאפשרים למנהלים להגדיר התראות אוטומטיות הנשלחות דרך דואר אלקטרוני, Skype, SMS וכו'. המנהלים יכולים להגדיר טריגרים בהתבסס על אירועים ספציפיים לשליחת התראות ליעד הנבחר.
ניתן להעדיף התראות: ההתראות הכי בעייתיות צריכות לקבל את ההשהייה המינימלית, בעוד שהתראות אחרות יכולות להישלח עם השהייה של מספר דקות. לדוגמה, אם מארח הולך לאופק, הודעת התראה נשלחת במשך שתי דקות לקבוצת דואר אלקטרוני או לקבוצת Skype אשר חבריהן הם מנהלים, משתמשים מתקדמים וראשי צוות. אם שרת מחובר מחדש, הודעת התראה המתאימה נשלחת לקבוצה. ניתן גם להגדיר התראות לגבי מקום אחסון נמוך, עומס CPU וזיכרון לא מספיק בשרתים. אם למכשיר הרשת יש את הפונקציונליות המתאימה, אפשר גם להגדיר התראות בנוגע לרמת הטונר במחבר במדפסת הרשת. זה יכול להיות שימושי אם המשתמשים מדפיסים תמיד עמודים חשובים, ורוצים למנוע שכחה בבדיקה האם יש קרטונים מלאים במלאי.
מומלץ להגדיר שליחת התראות אוטומטיות רק לפרמטרים הנדרשים. אם תגדיר התראות לשליחה על כל הבעיות, יהיה קשה לטפל במידע שהתקבל.
הגדרת הסף להתראות
הגדר סף על מנת להציג ולשלוח התראות. אם תגדיר לשלוח התראות מיידית, תראה הרבה הודעות אזהרה בקפיצות ביצועי CPU קצרות, תקופות קצרות של רשתות "שאינן נגישות" שנגרמו על ידי עמיסת שרת, וכדומה. הגדרת הסף המתאימה מאפשרת להגיב בזמן ולהפחית את השיטפון של התראות. הגדרה תקינה של הסף מפחיתה את סיכוי הפעלת שלילית שגויה.
כאשר אתה מגדיר תוכנת ניטור של המערכת, כדאי להגדיר מרווחים מתאימים בכדי לאסוף נתונים וליצור דוחות. אם המרווח ליצירת דוח הוא קטן מדי, התהליכים שיוצרים דוחות וגרפים בלוחות מחוונים עשויים להפריע לתהליכים הליביים, ועומס ה-CPU עולה באופן משמעותי. זאת עשויה לגרום לעמיסה ולכשלון של שרת הניטור.
סמן עדיפויות התראה
בלעדי עדיפויות בהתראות, הן מוצגות כשטף לא רלוונטי של נתונים. לפענח את הנתונים החשובים במידע זה מחריד בזמן, אינו נוח ואינו יעיל. הגדרת פתרון ניטור התשתית ה-IT כך שיציג רק את מה שצריך עם העדיפויות המוגדרות הופך את החיים לקלים יותר.
באירועים שונים עשויים להתרחש בתשתית ה-IT. חלקם עשויים להיות קריטיים, אחרים לא.
- דוגמאות לבעיות קריטיות. כישלון של שרת בקרת הדומיין הפעיל, שרת מסד נתונים לייצור, שרת ESXi המפעיל מכונות וירטואליות קריטיות למשימה, מצב S.M.A.R.T. רע של כונן דיסק, מקום פנוי נמוך בכונן, טמפרטורת CPU גבוהה, זיכרון פנוי שאינו מספיק, וכדומה.
- דוגמאות לבעיות בינוניות (עם עדיפות בינונית).כישלון של שרת בדיקה, מכונה וירטואלית בדיקה, מעקב באגים, וכדומה.
- דוגמאות לבעיות קלות (מינוריות). רמה נמוכה של טונר במדפסת, וכו'
העדיפויות עשויות להיות שונות לכל חברה, ועליכם להתאים אותן לפי דרישותיכם. קבעו עדיפות עבור סוגי בעיות שונים אם ניתן להציגם בלוחות מעקב וכאשר משתלחות הודעות אוטומטיות, לדוגמה:
- [קריטי] המארח 192.168.17.2 (DC01) אינו נגיש למשך 5 דקות.
- [קריטי] טמפרטורת המעבד גבוהה מדי (82°C) במארח 192.168.17.89 (Ora12-prod).
- [קריטי] שטח דיסק נמוך ב-C: במארח 10.10.10.6 (FS-06).
- [בינוני] ה-VM 10.10.10.35 (Oracle-test) במארח 192.168.17.22 (ESXi-22) אינו נגיש למשך 5 דקות.
- [מינורי] רמת הטונר נמוכה עבור 192.168.17.8 (מדפסת HP).
הבעיות הקריטיות הן דחופות ומנהלי מערכות צריכים לתקן אותן בהקדם האפשרי. הבעיות המינוריות יכולות להמתין לתגובה.
בדיקת פעילות מערכת המעקב
לאחר קביעת מערכת מעקב לתשתיות מחשוב, עליכם לבדוק כיצד המערכת פועלת והאם הודעות נשלחות כראוי. אל תמתינו למצב חירום אמיתי וקבעו בדיקה לאחר השלמת ההגדרה. לאחר הבדיקה, עשוי להיות צורך בהתאמות נוספות במערכת המעקב שלכם. הבדיקה מאפשרת לכם לוודא כי המעקב פועל כצפוי ולקבוע את ביצועיו.
יצירת תוכנית פעולת מענה
קבע מה לעשות לאחר קבלת הודעות כאשר מתרחשות בעיות. עליך לקבוע פתרון מהיר על מנת להגיב לבעיות קריטיות. עליך להפעיל תוכנית לשחזור במקרה של כשלים או אובדן נתונים כדי להבטיח המשך הפעילות ושחזור במקרי אסונות על מנת לעמוד ב RTOs ו RPOs של הארגון שלך. עליך להקפיד תמיד על קיום גיבויים מוכנים לשחזור מכונות או נתוני אפליקציות מסוימות.
תוכנות מעקב רבות מצויות עם פונקציות מקיפות להגנת נתונים ושחזור אסונות, כמו פתרון המעקב הטכנולוגי של NAKIVO. כשלי שרת ואובדן נתונים עשויים להתרחש בסוגים שונים של סביבות. גיבוי נתונים מאפשר לך להגן על נתוניך, לשחזר נתונים במקרה של כשל, ולשחזר עובדות עם הפעלה רגילה בזמן קצר. NAKIVO Backup & Replication היא פתרון ייחודי להגנת נתונים שתומך בגיבוי של מכונות פיזיות ב Linux ו- Windows, מכונות VMware vSphere VMs, מכונות Microsoft Hyper-V VMs, Amazon EC2, Nutanix AHV, ו-Microsoft 365.
Source:
https://www.nakivo.com/blog/all-you-should-know-about-it-infrastructure-monitoring/