למרות שאולי נראה שאין חובה להגדיר מעקב אחרי אפליקציות ב-Looker, חשוב מאוד להגדיר אותו במופעים באירוח בצד הלקוח. במקרים נדירים שבהם משהו משתבש בשרת, לרוב קשה יותר או בלתי אפשרי ל-Looker לעזור לכם לתקן את הבעיה, אלא אם תוכלו לספק מידע מתאים מניטור השרת מהזמן שבו התרחש האירוע.
מעקב אחרי אפליקציות
כתובת URL
יש שתי דרכים פשוטות לוודא שהמופע של Looker פועל.
מוסיפים את המחרוזת
/aliveלכתובת ה-URL של מופע Looker באופן הבא:https://instance_name.looker.com/aliveאם המופע שלכם יכול להגיב לבקשה לאחזור מהרשת, תקבלו קוד סטטוס של HTTP 200 OK.
מוסיפים את המחרוזת
/availabilityלכתובת ה-URL של מופע Looker באופן הבא:https://instance_name.looker.com/availabilityכתובת ה-URL הזו מבצעת בדיקה מקיפה יותר של כמה מערכות משנה בסיסיות, ותחזיר גם היא קוד סטטוס של HTTP 200 OK אם הכול תקין.
JMX
אפשר לעקוב אחרי מכונת Java הווירטואלית שמריצה את Looker באמצעות JMX.
אפליקציות ניטור רבות, כמו Zabbix ו-Nagios, תומכות ב-JMX. מידע נוסף זמין במאמרי העזרה של אפליקציית המעקב.
עריכת סקריפט ההפעלה של Looker
כדי להפעיל את המעקב של JMX, צריך לערוך את סקריפט לטעינה בזמן ההפעלה של Looker. כברירת מחדל, השם שלו הוא:
/home/looker/looker/looker
מחפשים את פרמטרי ההפעלה של Java:
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
החל מ-Looker 6.18, קובץ ה-JAR של Looker פוצל לשני קובצי JAR נפרדים: קובץ ה-JAR של ליבת Looker וקובץ ה-JAR של התלויות של Looker. כשמפעילים את קובץ ה-JAR של הליבה, קובץ ה-JAR של התלות מופעל באופן אוטומטי. שני קובצי ה-JAR צריכים להיות באותה ספרייה כדי שקובץ ה-JAR הראשי יוכל למצוא ולהפעיל את קובץ ה-JAR של התלות.
כברירת מחדל, אפשרות ההפעלה --no-daemonise אינה מוגדרת. אם לא הגדרת את האפשרות --no-daemonise, הוסף מקטע אחרי השורה שמתחילה ב--Xms$JAVAMEM:
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.port=9910 \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.ssl=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.local.only=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.authenticate=true \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
אם הגדרת את אפשרות ההפעלה --no-daemonise , הוסף מקטע אחרי השורה שמתחילה ב--Xms$JAVAMEM:
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9910 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
יצירת ספריית .lookerjmx
לאחר מכן, יוצרים את הספרייה .lookerjmx בספריית הבית של משתמש Looker ומגדירים הרשאות:
sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx
יצירת קובצי ה-JMX
בעזרת כלי לעריכת טקסט שאתם אוהבים, יוצרים קובץ בתיקייה החדשה בשם jmxremote.access עם התוכן הבא (אפשר להתאים אישית לסביבה שלכם):
monitorRole readonly
controlRole readwrite \
create javax.management.monitor.*,javax.management.timer.* \
unregister
לאחר מכן יוצרים באותה תיקייה קובץ בשם jmxremote.password עם התוכן הבא, ומשתמשים בסיסמאות מאובטחות משלכם:
monitorRole some_password_here
controlRole some_password_here
הגדרת ההרשאות
צריך לוודא ש-Java (ולכן Looker) לא יופעל אם הרשאות הקובץ מאפשרות לכל אחד חוץ ממשתמש Looker לקרוא את קובץ הסיסמה.
chmod 400 jmxremote.*
הפעלה מחדש של Looker
צריך להפעיל מחדש את Looker כדי להפעיל את JMX. חשוב להריץ את הפקודה הזו *כמשתמש Looker ולא כמשתמש root*:
cd ~/looker
./looker restart
מכונת Looker שלכם מוגדרת עכשיו לניטור JMX מרחוק ביציאה 9910, באמצעות הסיסמה שסיפקתם. יכול להיות שתצטרכו לשנות את הגדרות חומת האש או את רשימות בקרת הגישה (ACL) ברשת כדי לאפשר לשרת המעקב שלכם לקבל גישה לרשת ביציאה הזו.
מעקב אחר מארחים
לכל מארח שמריץ את אפליקציית Looker, מומלץ לאסוף את מדדי הביצועים הבאים לפחות, ליצור מהם גרפים ולהגדיר התראות לגביהם:
- ניצול יחידת העיבוד המרכזית (CPU): עומס ואחוז ניצול יחידת העיבוד המרכזית
- ניצול הזיכרון: סך הזיכרון שבו נעשה שימוש וסך שטח ההחלפה שבו נעשה שימוש
- Disk Usage
סף התראות
כדי להגדיר סף טוב להפעלת התראות, צריך קודם ליצור בסיס להשוואה. איסוף נתוני ביצועים כשהמופע של Looker פועל בעומס רגיל. כדאי לעיין בגרפי הביצועים ולראות את נקודות השיא. משך הזמן שיידרש לכם כדי ליצור את קווי הבסיס תלוי בעסק שלכם ובדפוסי השימוש שלכם ב-Looker. חלק מהחברות משתמשות ב-Looker בדפוס יציב וחוזר על עצמו מדי שבוע במהלך שעות הפעילות. יכול להיות שאחרים ישתמשו ב-Looker יותר בשעות מסוימות (למשל בסוף כל חודש).
באופן כללי, צריך לשלוח התראות רק על אירועים שניתן לבצע לגביהם פעולה. שליחת התראות כשאין פעולה שצריך לבצע מסתירה את החשיבות של התראות קריטיות.
הסף הבא יכול לשמש כנקודת התחלה להגדרת התראות. אם הערכים הבאים חורגים מהמגבלה למשך 15 דקות או יותר, יכול להיות שתידרש התערבות ידנית.
| מדד | אזהרה | קריטית | תגובות |
|---|---|---|---|
| עומס על המעבד | 2 | 4 | בדרך כלל, העומס צריך להיות 1 או פחות במערכת עם ליבה אחת. עומס גבוה מתמשך מוביל לביצועים נמוכים. |
| אחוז השימוש ב-CPU | 80 | 90 | שימוש גבוה במעבד מוביל לביצועים נמוכים. |
| אחוז הזיכרון בשימוש | 60 | 70 | שימוש גבוה בזיכרון יכול להצביע על כך שהוקצה יותר מדי זיכרון ל-Java. |
| אחוז השימוש בדיסק | 80 | 90 | מוודאים שהדיסק לא מלא. |
הערות נוספות:
- מערכות עם יותר מליבה אחת יכולות להתמודד עם עומסים גבוהים על המעבד בלי לפגוע בביצועים. כלל האצבע הוא שהעומס המתמשך לא צריך להיות גדול ממספר ליבות המעבד.
- אחוז הזמן הכולל של השימוש במעבד לפני שחלה ירידה בביצועים של המערכת, ביחס למספר ליבות המעבד במערכת. במילים אחרות, יכול להיות שבמערכת עם ליבה אחת הביצועים יהיו נמוכים כשהמעבד מגיע ל-80% שימוש, בעוד שבמארח עם 16 ליבות עדיין אפשר יהיה להשתמש במערכת כשהמעבד מגיע ל-95% שימוש.
- כדי לפתור בעיה של ניצול גבוה ומתמשך של יחידת העיבוד המרכזית (CPU), אפשר לעדכן את חומרת המארח או לשדרג למכונה גדולה יותר. לפעמים אפשר לצמצם מספרים גדולים של תצוגות Look מתוזמנות או של טבלאות נגזרות עם שאילתות ארוכות, או לייעל אותם כדי לשפר את הביצועים.
השלבים הבאים
אחרי שמגדירים את המעקב, אפשר להגדיר גיבויים של Looker.