במאמר הזה מוסבר איך לצפות במדדים של Apigee hybrid בלוח בקרה של Cloud Operations.
מידע על Cloud Operations
מידע נוסף על מדדים, לוחות בקרה ו-Cloud Operations זמין במאמרים הבאים:
הפעלת מדדים היברידיים
כדי לשלוח מדדים היברידיים אל Cloud Operations, צריך קודם להפעיל את איסוף המדדים. הוראות מפורטות מופיעות במאמר הגדרת איסוף מדדים.
מידע על שמות ותוויות של מדדים היברידיים
כשמפעילים את hybrid, המערכת מאכלסת באופן אוטומטי את המדדים של Cloud Operations. קידומת שם הדומיין של המדדים שנוצרו על ידי hybrid היא:
apigee.googleapis.com/
לדוגמה, המדד /proxy/request_count מכיל את המספר הכולל של הבקשות שהתקבלו על ידי proxy ל-API. לכן שם המדד ב-Cloud Operations הוא:
apigee.googleapis.com/proxy/request_count
ב-Cloud Operations אפשר לסנן ולקבץ נתונים של מדדים לפי תוויות. חלק מהתוויות מוגדרות מראש, ואחרות נוספות באופן מפורש על ידי Hybrid. בקטע Available metrics שבהמשך מפורטים כל המדדים ההיברידיים הזמינים וכל התוויות שנוספו במיוחד למדד שאפשר להשתמש בהן לסינון ולקיבוץ.
הצגת מדדים
בדוגמה הבאה אפשר לראות איך צופים במדדים ב-Cloud Operations:- פותחים את Metrics Explorer של Monitoring בדפדפן. לחלופין, אם אתם כבר במסוף Cloud Operations, בוחרים באפשרות Metrics explorer.
בקטע Find resource type and metric (חיפוש סוג משאב ומדד), מאתרים את המדד שרוצים לבדוק ובוחרים אותו. בוחרים מדד ספציפי מתוך המדדים הזמינים או מחפשים מדד.
- בוחרים את המדד הרצוי.
- החלת מסננים. אפשרויות הסינון של כל מדד מפורטות בקטע מדדים זמינים.
- ב-Cloud Operations מוצג התרשים של המדד שנבחר.
- לוחצים על Save.
יצירת מרכז בקרה
לוחות בקרה הם דרך אחת להצגה ולניתוח של נתוני מדדים שחשובים לכם. ב-Cloud Operations יש מרכזי בקרה מוגדרים מראש למשאבים ולשירותים שבהם אתם משתמשים, ואפשר גם ליצור מרכזי בקרה בהתאמה אישית.
אתם משתמשים בתרשים כדי להציג מדד של Apigee בלוח הבקרה המותאם אישית. בעזרת לוחות בקרה מותאמים אישית, יש לכם שליטה מלאה בתרשימים שמוצגים ובהגדרות שלהם. מידע נוסף על יצירת תרשימים זמין במאמר יצירת תרשימים.
בדוגמה הבאה מוצג תהליך יצירת לוח בקרה ב-Cloud Operations והוספת תרשימים להצגת נתוני מדדים:
- פותחים את Metrics Explorer ב-Monitoring בדפדפן ובוחרים באפשרות Dashboards.
- לוחצים על + יצירת מרכז שליטה.
- נותנים שם למרכז הבקרה. לדוגמה: תנועה בבקשות לשרת proxy היברידי
- לוחצים על אישור.
כדי להוסיף תרשים למרכז הבקרה, מבצעים את השלבים הבאים:
- במרכז הבקרה, לוחצים על הוספת תרשים.
- בוחרים את המדד הרצוי כמו שמתואר למעלה בקטע הצגת מדדים.
- משלימים את תיבת הדו-שיח כדי להגדיר את התרשים.
- לוחצים על Save. ב-Cloud Operations מוצגים נתונים לגבי המדד שנבחר.
מדדים זמינים
בטבלאות הבאות מפורטים מדדים לניתוח תנועת נתונים דרך שרת proxy. מידע נוסף על כל מדד של Apigee זמין במאמר מדדים של Google Cloud.
מדדי תנועה של שרת proxy, יעד ושרת
Open Telemetry אוספת ומעבדת מדדים (כפי שמתואר במאמר איסוף מדדים) לגבי תנועת נתונים של שרתי proxy, שרתי יעד ושרתים.
בטבלה הבאה מפורטים המדדים שבהם משתמש Open Telemetry Collector.
| שם המדד | שימוש |
|---|---|
/proxy/request_count |
מספר הבקשות ל-Apigee proxy מאז שהדגימה האחרונה נרשמה. |
/proxy/response_count |
מספר התגובות שנשלחו על ידי proxy ל-API של Apigee. |
/proxy/latencies |
התפלגות של זמני האחזור, שמחושבים מהרגע שבו הבקשה התקבלה ב-Apigee proxy ועד הרגע שבו התגובה נשלחה מ-Apigee proxy ללקוח. |
/proxyv2/request_count |
המספר הכולל של בקשות לשרת proxy של API שהתקבלו. |
/proxyv2/response_count |
המספר הכולל של תגובות proxy ל-API שהתקבלו. |
/proxyv2/latencies_percentile |
אחוזון של כל התגובות למדיניות ה-API לבקשה. |
/target/request_count |
מספר הבקשות שנשלחו ליעד Apigee מאז שהדגימה האחרונה תועדה. |
/target/response_count |
מספר התשובות שהתקבלו מיעד Apigee מאז שהדגימה האחרונה נרשמה. |
/target/latencies |
התפלגות של זמני האחזור, שמחושבים מהרגע שבו הבקשה נשלחה ליעד של Apigee ועד הרגע שבו התגובה התקבלה על ידי שרת ה-proxy של Apigee. הזמן לא כולל את התקורה של proxy ל-API של Apigee. |
/targetv2/request_count |
המספר הכולל של בקשות שנשלחו ליעד של ה-proxy. |
/targetv2/response_count |
המספר הכולל של התגובות שהתקבלו מיעד ה-proxy. |
/server/fault_count |
המספר הכולל של תקלות באפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/nio |
זהו מדד של מדד שניתן לסנן לפי התווית state כדי לאחזר פרטים לגבי תוויות שונות. הערכים
מייצגים פעולות שונות של מערכת וקלט/פלט. תוויות כמו accepted, accepted_total, close_failed,
close_success, conn_pending, connected, connected_total, max_conn ו-timeouts קשורות לפעולות של שקעים וחיבורים. התוויות הנותרות מתייחסות לפעולות אחרות במערכת. |
/server/num_threads |
מספר השרשורים הפעילים שאינם שרשורים של דמון בשרת. |
/server/request_count |
המספר הכולל של בקשות שהתקבלו על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/response_count |
המספר הכולל של תגובות שנשלחו על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/server/latencies |
זמן האחזור הוא זמן האחזור באלפיות השנייה שנוצר על ידי אפליקציית השרת. לדוגמה, שם האפליקציה יכול להיות |
/upstream/request_count |
מספר הבקשות שנשלחו מאפליקציית השרת לאפליקציית ה-upstream שלה. לדוגמה, עבור |
/upstream/response_count |
מספר התגובות שהתקבלו מאפליקציית ה-upstream באפליקציית השרת. לדוגמה, עבור |
/upstream/latencies |
זמן האחזור שנוצר באפליקציית השרת במעלה הזרם באלפיות השנייה. לדוגמה, עבור |
מדדי UDCA
Open Telemetry אוסף ומעבד מדדים (כפי שמתואר במאמר בנושא איסוף מדדים) עבור שירות UDCA, בדיוק כמו שהוא עושה עבור שירותים היברידיים אחרים.
בטבלה הבאה מפורטים המדדים שמשמשים את כלי האיסוף של Open Telemetry בנתוני המדדים של UDCA.
state
state
| שם המדד | שימוש |
|---|---|
/udca/server/local_file_oldest_ts |
חותמת הזמן, באלפיות השנייה מאז תחילת ראשית זמן יוניקס (Unix epoch), של הקובץ הכי ישן במערך הנתונים. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב בזמן אמת. אם ה-UDCA מעודכן ואין קבצים שממתינים להעלאה בזמן חישוב המדד הזה, הערך יהיה 0. אם הערך הזה ממשיך לגדול, סימן שהקבצים הישנים עדיין נמצאים בדיסק. |
/udca/server/local_file_latest_ts |
חותמת הזמן, באלפיות השנייה מאז תחילת ראשית זמן יוניקס (Unix epoch), של הקובץ האחרון בדיסק לפי מצב. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב בזמן אמת. אם ה-UDCA מעודכן ואין קבצים שממתינים להעלאה בזמן חישוב המדד הזה, הערך יהיה 0. |
/udca/server/local_file_count |
ספירה של מספר הקבצים בדיסק במאגר איסוף הנתונים. הערך צריך להיות קרוב ל-0. ערך גבוה ועקבי מצביע על כך שהקבצים לא מועלים או שהכלי UDCA לא מצליח להעלות אותם מספיק מהר. הערך הזה מחושב כל 60 שניות, והוא לא משקף את המצב של ה-UDCA בזמן אמת. |
/udca/server/total_latencies |
מרווח הזמן בשניות בין יצירת קובץ הנתונים לבין העלאה מוצלחת של קובץ הנתונים. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. היסטוגרמה של זמן האחזור הכולל מזמן יצירת הקובץ ועד לזמן ההעלאה המוצלחת. |
/udca/server/upload_latencies |
הזמן הכולל, בשניות, שחלף מאז ש-UDCA התחיל להעלות קובץ נתונים. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. במדדים יוצג היסטוגרמה של זמן האחזור הכולל של ההעלאה, כולל כל השיחות במעלה הזרם. |
/udca/upstream/http_error_count |
המספר הכולל של שגיאות HTTP שהכלי UDCA נתקל בהן. המדד הזה שימושי כדי לקבוע איזה חלק מהתלות החיצונית של UDCA נכשל ומאיזו סיבה. השגיאות האלה יכולות להתרחש בשירותים שונים (
|
/udca/upstream/http_latencies |
החביון של שירותים במעלה הזרם, בשניות. הקטגוריות יהיו 100ms, 250ms, 500ms, 1s, 2s, 4s, 8s, 16s, 32s ו-64s. היסטוגרמה של זמן האחזור משירותים במעלה הזרם. |
/udca/upstream/uploaded_file_sizes |
גודל הקובץ שמועלה לשירותי Apigee, בבייטים. הגודל של הדליים יהיה 1KB, 10KB, 100KB, 1MB, 10MB, 100MB ו-1GB. היסטוגרמה של גודל הקובץ לפי מערך נתונים, ארגון וסביבה. |
/udca/upstream/uploaded_file_count |
מספר הקבצים שהכלי UDCA העלה לשירותי Apigee.
חשוב לדעת:
|
/udca/disk/used_bytes |
הנפח שתופסים קובצי הנתונים בדיסק של ה-Pod לאיסוף נתונים, בבייט. עלייה בערך הזה לאורך זמן:
|
/udca/server/pruned_file_count |
מספר הקבצים שנמחקו כי אורך החיים שלהם (TTL) חרג מסף שהוגדר.
מערך הנתונים יכול לכלול API, עקבות ועוד, והמצב יכול להיות UPLOADED, FAILED או DISCARDED.
|
/udca/server/retry_cache_size |
ספירה של מספר הקבצים, לפי מערך נתונים, שהכלי UDCA מנסה להעלות מחדש. אחרי 3 ניסיונות חוזרים לכל קובץ, UDCA מעביר את הקובץ לספריית המשנה |
מדדים של Cassandra
Open Telemetry אוסף ומעבד מדדים (כפי שמתואר במאמר בנושא איסוף מדדים) עבור Cassandra בדיוק כמו שהוא עושה עבור שירותים היברידיים אחרים.
בטבלה הבאה מפורטים המדדים שמשמשים את כלי האיסוף של Open Telemetry בנתוני המדדים של Cassandra.
| שם המדד (לא כולל הדומיין) | שימוש |
|---|---|
/cassandra/process_max_fds |
המספר המקסימלי של מתארי קבצים פתוחים. |
/cassandra/process_open_fds |
פותחים מתארים של קבצים. |
/cassandra/jvm_memory_pool_bytes_max |
השימוש המקסימלי בזיכרון של JVM למאגר. |
/cassandra/jvm_memory_pool_bytes_init |
השימוש הראשוני בזיכרון של JVM במאגר. |
/cassandra/jvm_memory_bytes_max |
השימוש המקסימלי בזיכרון הערימה של JVM. |
/cassandra/process_cpu_seconds_total |
זמן השימוש במעבד של המשתמש והמערכת בשניות. |
/cassandra/jvm_memory_bytes_used |
שימוש בזיכרון ערימה (heap) של JVM. |
/cassandra/compaction_pendingtasks |
דחיסות שלא הושלמו ב-Cassandra sstables. מידע נוסף זמין במאמר בנושא דחיסה. |
/cassandra/jvm_memory_bytes_init |
השימוש הראשוני בזיכרון הערימה (heap) של JVM. |
/cassandra/jvm_memory_pool_bytes_used |
השימוש בזיכרון של מאגר JVM. |
/cassandra/jvm_memory_pool_bytes_committed |
השימוש בזיכרון שהוקצה למאגר JVM. |
/cassandra/clientrequest_latency |
זמן האחזור של בקשת קריאה בטווח האחוזון ה-75 במיקרו-שניות. |
/cassandra/jvm_memory_bytes_committed |
השימוש בזיכרון ערימה (heap) ב-JVM. |
עבודה עם מדדים של Cassandra
Apigee ממליצה לעקוב אחרי המדדים הבאים, כי הם חשובים למסד הנתונים של Cassandra:
- שיעור הבקשות של Cassandra: אפשר להשתמש במדד הזה כדי לעקוב אחרי שיעור בקשות הקריאה והכתיבה של Cassandra.
מדד: apigee.googleapis.com/cassandra/clientrequest_latencyתוויות משאבים: project_id,location,cluster_name,namespace_name,pod_name,container_nameתוויות מדדים: scope,unitאפשר להשתמש בתוויות האלה כדי לסנן את המשאב הספציפי או כדי לקבץ משאבים.
כדי לעקוב אחרי קצב הבקשות לקריאה של Cassandra, צריך להחיל את המסנן הבא.
מסננים: metric.scope == 'Read'
metric.unit == 'OneMinuteRate'כדי לעקוב אחרי קצב הבקשות לכתיבה ב-Cassandra, צריך להחיל את המסנן הבא.
מסננים: metric.scope == 'Write'
metric.unit == 'OneMinuteRate' - זמן האחזור של בקשות Cassandra: אפשר להשתמש במדד הזה כדי לעקוב אחרי זמן האחזור של בקשות קריאה וכתיבה ב-Cassandra. זהו אותו מדד כמו קצב בקשות,
apigee.googleapis.com/cassandra/clientrequest_latencyעם מסננים שונים.כדי לעקוב אחרי זמן האחזור של בקשות קריאה ב-Cassandra, צריך להחיל את המסנן הבא.
מסננים: metric.scope == 'Read'
metric.unit == '99thPercentile'או'95thPercentile'או'75thPercentile'כדי לעקוב אחרי זמן האחזור של בקשות כתיבה ב-Cassandra, צריך להחיל את המסנן הבא.
מסננים: metric.scope == 'Write'
metric.unit == '99thPercentile'או'95thPercentile'או'75thPercentile' - ניצול של בקשות למעבד של Cassandra pod
מדד: kubernetes.io/container/cpu/request_utilization (GKE on Google Cloud)
מידע נוסף זמין במאמר בנושא מדדים של Kubernetes.
kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)תוויות משאבים: project_id,location,cluster_name,namespace_name,pod_name,container_nameאפשר להשתמש בתוויות האלה כדי לסנן את המשאב הספציפי או כדי לקבץ משאבים.
- ניצול נפח הנתונים של Cassandra
מדד: kubernetes.io/pod/volume/utilization (GKE on Google Cloud)
מידע נוסף זמין במאמר בנושא מדדים של Kubernetes.
kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)תוויות משאבים: project_id,location,cluster_name,namespace_name,pod_nameתוויות מדדים: volume_nameאפשר להשתמש בתוויות האלה כדי לסנן את המשאב הספציפי או כדי לקבץ משאבים.
המלצות להרחבת אשכול Cassandra
ההנחיות הבאות יכולות לשמש כהמלצה לגבי אשכול שמתאים להרחבת אשכול Cassandra. באופן כללי, אם בקשות קריאה או כתיבה מציגות באופן עקבי חביון באחוזון ה-99 או שהחביון נמצא במגמת עלייה מתמשכת, ואתם רואים עליות תואמות בשימוש בבקשת ה-CPU ובשיעורי בקשות הקריאה או הכתיבה, אפשר להסיק שאשכול Cassandra נמצא במצב של עומס. כדאי לשקול להגדיל את גודל האשכול. מידע נוסף זמין במאמר בנושא שינוי גודל של Cassandra
| מדד | סף | משך ההפעלה |
|---|---|---|
kubernetes.io/pod/volume/utilization | 85% | 5 דקות |
kubernetes.io/container/cpu/request_utilization | 85% | 3 דקות |
Read request Latency 99thPercentile | 5 שניות | 3 דקות |
Write request Latency 99thPercentile | 5 שניות | 3 דקות |