בדרך כלל, בהגדרת ייצור, מומלץ להפעיל מנגנוני מעקב בפריסה של Apigee Edge for Private Cloud. טכניקות המעקב האלה מזהירות את מנהלי הרשת (או המפעילים) מפני שגיאה או כשל. כל שגיאה שנוצרת מדווחת כהתראה ב-Apigee Edge. מידע נוסף על התראות זמין במאמר שיטות מומלצות ל-Monitoring.
רכיבי Apigee מסווגים בעיקר לשתי קטגוריות:
- שירותי שרת Java ספציפיים ל-Apigee: אלה כוללים את שרת הניהול, מעבד ההודעות, שרת Qpid ושרת Postgres.
- שירותים של צד שלישי: כולל Nginx Router, Apache Cassandra, Apache ZooKeeper, SymasLDAP, מסד נתונים של PostgreSQL ו-Qpid.
בטבלה הבאה מוצגים פרמטרים שאפשר לעקוב אחריהם בפריסה מקומית של Apigee Edge:
רכיב | בדיקות מערכת | נתונים סטטיסטיים ברמת התהליך | בדיקות ברמת ה-API | בדיקות של זרימת הודעות | ספציפי לרכיב | |
---|---|---|---|---|---|---|
שירותי Java שספציפיים ל-Apigee |
שרת ניהול |
|||||
מעבד בקשות |
||||||
Qpid Server |
||||||
שרת Postgres |
||||||
שירותים של צד שלישי |
Apache Cassandra |
|||||
Apache ZooKeeper |
||||||
SymasLDAP |
||||||
מסד נתונים של PostgreSQL |
||||||
Qpid |
||||||
נתב Nginx |
באופן כללי, אחרי שמתקינים את Apigee Edge, אפשר לבצע את משימות המעקב הבאות כדי לעקוב אחרי הביצועים של התקנת Apigee Edge לענן פרטי.
בדיקות תקינות של המערכת
חשוב מאוד למדוד את הפרמטרים של תקינות המערכת, כמו ניצול המעבד (CPU), ניצול הזיכרון וקישוריות היציאה ברמה גבוהה יותר. כדי לקבל מידע בסיסי על תקינות המערכת, אפשר לעקוב אחרי הפרמטרים הבאים.
- ניצול יחידת העיבוד המרכזית (CPU): מציין את הנתונים הסטטיסטיים הבסיסיים (משתמש/מערכת/המתנה של קלט/פלט/סרק) לגבי ניצול יחידת העיבוד המרכזית. לדוגמה, סה"כ השימוש במעבד על ידי המערכת.
- זיכרון פנוי/בשימוש: מציין את ניצול זיכרון המערכת בבייט. לדוגמה, זיכרון פיזי שבו נעשה שימוש על ידי המערכת.
- ניצול שטח האחסון: פרטי מערכת הקבצים על סמך ניצול שטח האחסון הנוכחי. לדוגמה, שטח הכונן הקשיח שהמערכת משתמשת בו.
- Load Average: מציין את מספר התהליכים שממתינים להפעלה.
- נתונים סטטיסטיים של הרשת: חבילות רשת ו/או בייטים ששודרו והתקבלו, יחד עם שגיאות השידור לגבי רכיב ספציפי.
בדיקות של תהליכים או אפליקציות
ברמת התהליך, אפשר לראות מידע חשוב על כל התהליכים שפועלים. לדוגמה, נתונים סטטיסטיים של שימוש בזיכרון ובמעבד (CPU) שבהם נעשה שימוש בתהליך או באפליקציה. בתהליכים כמו Qpid, Postgres Postmaster, Java וכו', אפשר לעקוב אחרי:
- זיהוי תהליך: זיהוי תהליך ספציפי של Apigee. לדוגמה, אתם יכולים לעקוב אחרי קיומו של תהליך Java של שרת Apigee.
- נתונים סטטיסטיים של השרשור: אפשר לראות את דפוסי השרשור הבסיסיים שבהם נעשה שימוש בתהליך. לדוגמה, אפשר לעקוב אחרי מספר השרשורים בשיא, מספר השרשורים בכל התהליכים.
- ניצול הזיכרון: אפשר לראות את השימוש בזיכרון בכל התהליכים של Apigee. לדוגמה, אפשר לעקוב אחרי פרמטרים כמו השימוש בזיכרון הערימה, השימוש בזיכרון שאינו ערימה שנעשה על ידי תהליך.
בדיקות ברמת ה-API
ברמת ה-API, אפשר לעקוב אחרי הסטטוס של השרת כדי לדעת אם הוא פעיל ופועל, לגבי קריאות ל-API שנעשה בהן שימוש לעיתים קרובות ועוברות דרך Apigee. לדוגמה, אפשר לבצע בדיקת API בשרת הניהול, בנתב ובמעבד ההודעות באמצעות הפקודה הבאה curl
:
curl http://host:port/v1/servers/self/up
כאשר host היא כתובת ה-IP של רכיב Apigee Edge. המספר port ייחודי לכל רכיב Edge. לדוגמה:
שרת הניהול: 8080
- נתב: 8081
- מעבד בקשות: 8082
- וכו'
בקטעים הבאים מפורט מידע על הרצת הפקודה הזו לכל רכיב
הקריאה הזו מחזירה את הערכים true ו-false. כדי לקבל את התוצאות הטובות ביותר, אפשר גם להנפיק קריאות API ישירות בשרת העורפי (שתוכנת Apigee מתקשרת איתו) כדי לקבוע במהירות אם קיימת שגיאה בסביבת תוכנת Apigee או בשרת העורפי.
בדיקות של זרימת הודעות
אתם יכולים לאסוף נתונים מנתבים ומעבדי הודעות לגבי דפוסים או נתונים סטטיסטיים של זרימת הודעות. כך תוכלו לעקוב אחרי:
- מספר הלקוחות הפעילים
- מספר התשובות (10X, 20X, 30X, 40X ו-50X)
- כשלים בחיבור
כך תוכלו לספק לוחות בקרה לזרימת ההודעות של ה-API. מידע נוסף זמין במאמר בנושא איך עוקבים אחרי הניסויים.
בדיקת תקינות של הנתב של מעבד ההודעות
הנתב מטמיע מנגנון לבדיקת תקינות כדי לקבוע אילו ממעבדי ההודעות פועלים כמצופה. אם נתב מזהה שמעבד הודעות לא פעיל או פועל לאט, הוא יכול להוציא אותו מהרוטציה באופן אוטומטי. במקרה כזה, הנתב כותב הודעות מסוג Mark Down לקובץ היומן של הנתב בכתובת /opt/apigee/var/log/edge-router/logs/system.log
.
אפשר לעקוב אחרי ההודעות האלה בקובץ היומן של הנתב. לדוגמה, אם הנתב מוציא מעבד הודעות מהמחזור, הוא כותב את ההודעה ליומן בצורה הבאה:
2014-05-06 15:51:52,159 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now DISCONNECTED. handle = MP_IP at 1399409512159 2014-04-17 12:54:48,512 org: env: nioEventLoopGroup-2-2 INFO HEARTBEAT - HBTracker.gotResponse() : No HeartBeat detected from /MP_IP:PORT Mark Down
כאשר MP_IP:PORT היא כתובת ה-IP ומספר היציאה של מעבד ההודעות.
אם בשלב מאוחר יותר הנתב מבצע בדיקת תקינות וקובע שמעבד ההודעות פועל בצורה תקינה, הנתב מחזיר את מעבד ההודעות לרוטציה באופן אוטומטי. הנתב גם כותב הודעה מסוג Mark Up ליומן בצורה הבאה:
2014-05-06 16:07:29,054 org: env: RPCClientClientProtocolChildGroup-RPC-0 INFO CLUSTER - ServerState.setState() : State of 2a8a0e0c-3619-416f-b037-8a42e7ad4577 is now CONNECTED. handle = IP at 1399410449054 2014-04-17 12:55:06,064 org: env: nioEventLoopGroup-4-1 INFO HEARTBEAT - HBTracker.updateHB() : HeartBeat detected from IP:PORT Mark Up