במאמר הזה מוסבר איך לצפות במדדים של Apigee hybrid בלוח בקרה של Stackdriver.
מידע על Stackdriver
מידע נוסף על מדדים, מרכזי בקרה ו-Stackdriver זמין במאמרים הבאים:
הפעלת מדדים היברידיים
כדי לשלוח מדדים היברידיים אל Stackdriver, צריך קודם להפעיל את איסוף המדדים. הוראות מפורטות מופיעות במאמר הגדרת איסוף מדדים.
מידע על שמות ותוויות של מדדים היברידיים
אם מפעילים את האפשרות הזו, מדדי Stackdriver מאוכלסים באופן אוטומטי. קידומת שם הדומיין של המדדים שנוצרו על ידי hybrid היא:
apigee.googleapis.com/
לדוגמה, המדד /proxy/request_count מכיל את המספר הכולל של הבקשות שהתקבלו על ידי proxy ל-API. לכן שם המדד ב-Stackdriver הוא:
apigee.googleapis.com/proxy/request_count
ב-Stackdriver אפשר לסנן ולקבץ נתונים של מדדים על סמך תוויות. חלק מהתוויות מוגדרות מראש, ואחרות נוספות באופן מפורש על ידי Hybrid. בקטע Available metrics שבהמשך מפורטים כל המדדים ההיברידיים הזמינים וכל התוויות שנוספו במיוחד למדד שאפשר להשתמש בהן לסינון ולקיבוץ.
הצגת מדדים
בדוגמה הבאה אפשר לראות איך מציגים מדדים ב-Stackdriver:- פותחים את Metrics Explorer של Monitoring בדפדפן. אם אתם כבר במסוף Stackdriver, אתם יכולים גם לבחור באפשרות Metrics explorer.
בקטע Find resource type and metric (חיפוש סוג משאב ומדד), מאתרים את המדד שרוצים לבדוק ובוחרים אותו. בוחרים מדד ספציפי מתוך המדדים הזמינים או מחפשים מדד. לדוגמה, מחפשים את
proxy/latencies:
- בוחרים את המדד הרצוי.
- החלת מסננים. אפשרויות הסינון של כל מדד מפורטות בקטע מדדים זמינים.
לדוגמה, עבור המדד
proxy_latencies, אפשרויות הסינון הן: org=org_name. - בתרשים מוצג המדד שנבחר.
- לוחצים על Save.
יצירת מרכז בקרה
לוחות בקרה הם דרך אחת להצגה ולניתוח של נתוני מדדים שחשובים לכם. Stackdriver מספק מרכזי בקרה מוגדרים מראש למשאבים ולשירותים שבהם אתם משתמשים, ואפשר גם ליצור מרכזי בקרה בהתאמה אישית.
אתם משתמשים בתרשים כדי להציג מדד של Apigee בלוח הבקרה המותאם אישית. בעזרת לוחות בקרה מותאמים אישית, יש לכם שליטה מלאה בתרשימים שמוצגים ובהגדרות שלהם. מידע נוסף על יצירת תרשימים זמין במאמר יצירת תרשימים.
בדוגמה הבאה מוסבר איך ליצור מרכז שליטה ב-Stackdriver ואז להוסיף תרשימים כדי להציג נתוני מדדים:
- פותחים את Metrics Explorer ב-Monitoring בדפדפן ובוחרים באפשרות Dashboards.
- לוחצים על + יצירת מרכז שליטה.
- נותנים שם למרכז הבקרה. לדוגמה: תנועה בבקשות לשרת proxy היברידי
- לוחצים על אישור.
כדי להוסיף תרשים למרכז הבקרה, מבצעים את השלבים הבאים:
- במרכז הבקרה, לוחצים על הוספת תרשים.
- בוחרים את המדד הרצוי כמו שמתואר למעלה בקטע הצגת מדדים.
- משלימים את תיבת הדו-שיח כדי להגדיר את התרשים.
- לוחצים על Save. ב-Stackdriver מוצגים נתונים של המדד שנבחר.
מדדים זמינים
בטבלאות הבאות מפורטים מדדים לניתוח תנועת נתונים דרך שרת proxy.
מדדי תנועה של שרת proxy, יעד ושרת
שירות Prometheus אוסף ומעבד מדדים (כפי שמתואר במאמר בנושא איסוף מדדים) לגבי תנועה של proxy, יעד ושרת.
בטבלה הבאה מתוארים המדדים והתוויות שבהם נעשה שימוש ב-Prometheus. התוויות האלה משמשות לרשומות ביומן המדדים.
| שם המדד | תווית | שימוש |
|---|---|---|
/proxy/request_count |
method |
המספר הכולל של בקשות לשרת proxy של API שהתקבלו. |
/proxy/response_count |
method
response_code |
המספר הכולל של תגובות proxy ל-API שהתקבלו. |
/proxy/latencies |
method |
המספר הכולל של אלפיות השנייה שחלפו עד למענה לשיחה. הזמן הזה כולל את התקורה של פרוקסי ה-API של Apigee ואת הזמן של שרת היעד. |
/target/request_count |
method
|
המספר הכולל של בקשות שנשלחו ליעד של ה-proxy. |
/target/response_count |
method
|
המספר הכולל של התגובות שהתקבלו מיעד ה-proxy. |
/target/latencies |
method
|
המספר הכולל של אלפיות השנייה שחלפו עד למענה לשיחה. הזמן הזה לא כולל את התקורה של proxy ל-API של Apigee. |
/policy/latencies |
policy_name |
המספר הכולל של אלפיות השנייה שנדרשו להפעלת המדיניות הזו שצוין השם שלה. |
/server/fault_count |
source |
המספר הכולל של תקלות באפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/nio |
state |
מספר השקעים הפתוחים. |
/server/num_threads |
מספר השרשורים הפעילים שאינם שרשורים של דמון בשרת. | |
/server/request_count |
method
|
המספר הכולל של בקשות שהתקבלו על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/response_count |
method
|
המספר הכולל של תגובות שנשלחו על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/latencies |
method
|
זמן האחזור הוא זמן האחזור באלפיות השנייה שנוצר על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/upstream/request_count |
method
|
מספר הבקשות שנשלחו מאפליקציית השרת לאפליקציית ה-upstream שלה. לדוגמה, עבור |
/upstream/response_count |
method
|
מספר התגובות שהתקבלו מאפליקציית ה-upstream באפליקציית השרת. לדוגמה, עבור |
/upstream/latencies |
method
|
זמן האחזור שנוצר באפליקציית השרת במעלה הזרם באלפיות השנייה. לדוגמה, עבור |
מדדי UDCA
שירות Prometheus אוסף ומעבד מדדים (כפי שמתואר במאמר בנושא איסוף מדדים) עבור שירות UDCA, בדיוק כמו שהוא עושה עבור שירותים היברידיים אחרים.
בטבלה הבאה מתוארים המדדים והתוויות שבהם נעשה שימוש ב-Prometheus בנתוני המדדים של UDCA. התוויות האלה משמשות לרשומות ביומן המדדים.
| שם המדד | תווית | שימוש |
|---|---|---|
/udca/server/local_file_oldest_ts |
dataset
|
חותמת הזמן, באלפיות השנייה מאז תחילת ראשית זמן יוניקס (Unix epoch), של הקובץ הכי ישן במערך הנתונים. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב בזמן אמת. אם ה-UDCA מעודכן ואין קבצים שממתינים להעלאה בזמן חישוב המדד הזה, הערך יהיה 0. אם הערך הזה ממשיך לגדול, סימן שהקבצים הישנים עדיין נמצאים בדיסק. |
/udca/server/local_file_latest_ts |
dataset
|
חותמת הזמן, באלפיות השנייה מאז תחילת ראשית זמן יוניקס (Unix epoch), של הקובץ האחרון בדיסק לפי מצב. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב בזמן אמת. אם ה-UDCA מעודכן ואין קבצים שממתינים להעלאה בזמן חישוב המדד הזה, הערך יהיה 0. |
/udca/server/local_file_count |
dataset
|
ספירה של מספר הקבצים בדיסק במאגר איסוף הנתונים. הערך צריך להיות קרוב ל-0. ערך גבוה ועקבי מצביע על כך שהקבצים לא מועלים או שהכלי UDCA לא מצליח להעלות אותם מספיק מהר. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב של ה-UDCA בזמן אמת. |
/udca/server/total_latencies |
dataset |
מרווח הזמן בשניות בין יצירת קובץ הנתונים לבין העלאה מוצלחת של קובץ הנתונים. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. היסטוגרמה של זמן האחזור הכולל מזמן יצירת הקובץ ועד לזמן ההעלאה המוצלחת. |
/udca/server/upload_latencies |
dataset |
הזמן הכולל, בשניות, שחלף מאז ש-UDCA התחיל להעלות קובץ נתונים. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. במדדים יוצג היסטוגרמה של זמן האחזור הכולל של ההעלאה, כולל כל השיחות במעלה הזרם. |
/udca/upstream/http_error_count |
service
|
המספר הכולל של שגיאות HTTP שהכלי UDCA נתקל בהן. המדד הזה שימושי כדי לקבוע איזה חלק מהתלות החיצונית של UDCA נכשל ומאיזו סיבה. השגיאות האלה יכולות להתרחש בשירותים שונים (
|
/udca/upstream/http_latencies |
service
|
החביון של שירותים במעלה הזרם, בשניות. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. היסטוגרמה של זמן האחזור משירותים במעלה הזרם. |
/udca/upstream/uploaded_file_sizes |
dataset |
גודל הקובץ שמועלה לשירותי Apigee, בבייטים. הגודל של הדליים יהיה 1KB, 10KB, 100KB, 1MB, 10MB, 100MB ו-1GB. היסטוגרמה של גודל הקובץ לפי מערך נתונים, ארגון וסביבה. |
/udca/upstream/uploaded_file_count |
dataset |
מספר הקבצים שהכלי UDCA העלה לשירותי Apigee.
חשוב לדעת:
|
/udca/disk/used_bytes |
dataset
|
הנפח שתופסים קובצי הנתונים בדיסק של ה-Pod לאיסוף נתונים, בבייט. עלייה בערך הזה לאורך זמן:
|
/udca/server/pruned_file_count |
dataset
|
מספר הקבצים שנמחקו כי אורך החיים שלהם (TTL) חרג מסף שהוגדר.
מערך הנתונים יכול לכלול API, עקבות ועוד, והמצב יכול להיות UPLOADED, FAILED או DISCARDED.
|
/udca/server/retry_cache_size |
dataset |
ספירה של מספר הקבצים, לפי מערך נתונים, שהכלי UDCA מנסה להעלות מחדש. אחרי 3 ניסיונות חוזרים לכל קובץ, UDCA מעביר את הקובץ לספריית המשנה |
מדדים של Cassandra
שירות Prometheus אוסף ומעבד מדדים (כפי שמתואר במאמר בנושא איסוף מדדים) עבור Cassandra, בדיוק כמו שהוא עושה עבור שירותים היברידיים אחרים.
בטבלה הבאה מתוארים המדדים והתוויות שבהם נעשה שימוש ב-Prometheus בנתוני המדדים של Cassandra. התוויות האלה משמשות לרשומות ביומן המדדים.
| שם המדד (לא כולל הדומיין) | תווית | שימוש |
|---|---|---|
/cassandra/process_max_fds |
המספר המקסימלי של מתארי קבצים פתוחים. | |
/cassandra/process_open_fds |
פותחים מתארים של קבצים. | |
/cassandra/jvm_memory_pool_bytes_max |
pool |
השימוש המקסימלי בזיכרון של JVM למאגר. |
/cassandra/jvm_memory_pool_bytes_init |
pol |
השימוש הראשוני בזיכרון של JVM במאגר. |
/cassandra/jvm_memory_bytes_max |
area |
השימוש המקסימלי בזיכרון הערימה של JVM. |
/cassandra/process_cpu_seconds_total |
זמן השימוש במעבד של המשתמש והמערכת בשניות. | |
/cassandra/jvm_memory_bytes_used |
area |
שימוש בזיכרון ערימה (heap) של JVM. |
/cassandra/compaction_pendingtasks |
unit |
דחיסות שלא הושלמו ב-Cassandra sstables. מידע נוסף זמין במאמר בנושא דחיסה. |
/cassandra/jvm_memory_bytes_init |
area |
השימוש הראשוני בזיכרון הערימה (heap) של JVM. |
/cassandra/jvm_memory_pool_bytes_used |
pool |
השימוש בזיכרון של מאגר JVM. |
/cassandra/jvm_memory_pool_bytes_committed |
pool |
השימוש בזיכרון שהוקצה למאגר JVM. |
/cassandra/clientrequest_latency |
scope
|
זמן האחזור של בקשת קריאה בטווח האחוזון ה-75 במיקרו-שניות. |
/cassandra/jvm_memory_bytes_committed |
area |
השימוש בזיכרון ערימה (heap) ב-JVM. |