ייצוא מדדים מ-Cloud Monitoring

Last reviewed 2024-08-14 UTC

במאמר הזה מתואר פתרון לייצוא מדדים של Cloud Monitoring לצורך ניתוח לטווח ארוך. ‫Cloud Monitoring מספק פתרון מעקב ל-Google Cloud. מערכת Cloud Monitoring שומרת את המדדים למשך שישה שבועות, כי הערך של מדדי המעקב תלוי בדרך כלל בפרק זמן מסוים. לכן, הערך של מדדים היסטוריים יורד עם הזמן. אחרי חלון ששת השבועות, יכול להיות שהמדדים המצטברים עדיין יהיו שימושיים לניתוח ארוך טווח של מגמות שאולי לא יהיו ברורות בניתוח לטווח קצר.

הפתרון הזה כולל מדריך להבנת פרטי המדדים לייצוא והטמעה לדוגמה של ייצוא מדדים ל-BigQuery בלי שרת (serverless).

בדוחות של State of DevOps מפורטות יכולות שמשפרות את הכנת התוכנות להפצה. הפתרון הזה יעזור לכם להשתמש ביכולות הבאות:

תרחישי שימוש בייצוא מדדים

‫Cloud Monitoring אוסף מדדים ומטא-נתונים מ Google Cloud ומאינסטרומנטציה של אפליקציות. מדדי Monitoring מספקים נראות מעמיקה של הביצועים, זמן הפעולה התקינה והתקינות הכללית של אפליקציות בענן באמצעות API, מרכזי בקרה וכלי לבדיקת מדדים. הכלים האלה מאפשרים לכם לבדוק את ערכי המדדים ב-6 השבועות האחרונים לצורך ניתוח. אם יש לכם דרישות לניתוח מדדים לטווח ארוך, אתם יכולים להשתמש ב-Cloud Monitoring API כדי לייצא את המדדים לאחסון לטווח ארוך.

ב-Cloud Monitoring נשמרים המדדים מ-6 השבועות האחרונים. הוא משמש לעיתים קרובות למטרות תפעוליות כמו מעקב אחרי תשתית של מכונות וירטואליות (מעבד, זיכרון, מדדי רשת) ומדדי ביצועים של אפליקציות (זמן אחזור של בקשות או תגובות). אם המדדים האלה חורגים מספי ערכים שנקבעו מראש, מופעל תהליך תפעולי באמצעות התראות.

יכול להיות שהמדדים שתועדו יהיו שימושיים גם לניתוח לטווח ארוך. לדוגמה, יכול להיות שתרצו להשוות בין מדדי ביצועי האפליקציה מיום שני הסייבר או מאירועים אחרים עם נפח תנועה גבוה לבין מדדים מהשנה הקודמת, כדי לתכנן את האירוע הבא עם נפח תנועה גבוה. תרחיש שימוש נוסף הוא בדיקת השימוש בשירות מסוים במהלך רבעון או שנה, כדי לשפר את תחזית העלויות. Google Cloud יכול להיות שתרצו לראות מדדי ביצועים של אפליקציות לאורך חודשים או שנים.

בדוגמאות האלה, צריך לשמור על המדדים לצורך ניתוח לאורך זמן. ייצוא המדדים האלה ל-BigQuery מספק את יכולות הניתוח הנדרשות כדי לטפל בדוגמאות האלה.

דרישות

כדי לבצע ניתוח לטווח ארוך של נתוני מדדים של מעקב, יש 3 דרישות עיקריות:

ייצוא הנתונים מ-Cloud Monitoring. צריך לייצא את נתוני המדדים של Cloud Monitoring כערך מדד מצטבר. צריך לבצע צבירה של מדדים כי אחסון של נקודות נתונים גולמיות של timeseries, למרות שהוא אפשרי מבחינה טכנית, לא מוסיף ערך. רוב הניתוחים לטווח ארוך מתבצעים ברמת הצבירה לאורך פרק זמן ארוך יותר. רמת הגרנולריות של הצבירה היא ייחודית לתרחיש השימוש שלכם, אבל מומלץ להגדיר צבירה של שעה לפחות.
העברת הנתונים לניתוח. כדי לנתח את מדדי Cloud Monitoring, צריך לייבא אותם למנוע לניתוח נתונים.
כתיבת שאילתות ובניית מרכזי בקרה על סמך הנתונים. כדי להריץ שאילתות, לנתח את הנתונים ולהציג אותם בצורה ויזואלית, צריך לוחות בקרה וגישה ל-SQL סטנדרטי.

שלבים פונקציונליים

יוצרים רשימה של מדדים שרוצים לכלול בייצוא.
קריאת מדדים מ-Monitoring API.
ממפים את המדדים מתוך פלט ה-JSON המיוצא מ-Monitoring API לפורמט הטבלה ב-BigQuery.
כותבים את המדדים ל-BigQuery.
יוצרים לוח זמנים פרוגרמטי לייצוא קבוע של המדדים.

ארכיטקטורה

הארכיטקטורה הזו מבוססת על שירותים מנוהלים כדי לפשט את התפעול והניהול, להפחית עלויות ולאפשר לכם להרחיב את הפעילות לפי הצורך.

ארכיטקטורה לייצוא מדדים של Cloud Monitoring לצורך ניתוח לטווח ארוך

התרשים מציג את הטמעת הארכיטקטורה הבאה:

בניית רשימת מדדים: מייצאים נתוני מדדים מ-Cloud Monitoring API ובוחרים את המדדים באמצעות השיטה project.metricsDescriptors.list(). החרגת רשימת מדדים באמצעות הגדרות. מתזמנים את המשימה להפעלה במועדים קבועים (למשל, פעם בשעה).
Get timeseries: משתמשים בשיטה project.timeseries.list() כדי לחלץ כל מדד מ-Monitoring API. צבירה לרמה של שעה אחת באמצעות צבירה של API.
אחסון מדדים: App Engine כותב כל מדד ל-BigQuery.
מדדים נצברים: אפשר להריץ שאילתה על המדדים הנצברים באמצעות BigQuery.
מדדי דוחות: כדאי להשתמש ב-Looker Studio לניתוח לטווח ארוך.

הטכנולוגיות הבאות נמצאות בשימוש בארכיטקטורה:

‫App Engine – פתרון פלטפורמה כשירות (PaaS) שניתן להרחבה, שמשמש לקריאה ל-Monitoring API ולכתיבה ל-BigQuery.
‫BigQuery – מנוע לניתוח נתונים מנוהל שמשמש להטמעה ולניתוח של נתוני timeseries.
‫Pub/Sub – שירות מנוהל להעברת הודעות בזמן אמת, שמשמש לעיבוד אסינכרוני שניתן להתאמה לעומס.
‫Cloud Storage – אחסון אובייקטים מאוחד למפתחים ולחברות, שמשמש לאחסון המטא-נתונים לגבי מצב הייצוא.
‫Cloud Scheduler – מתזמן בסגנון cron שמשמש להפעלת תהליך הייצוא.

הסבר על פרטי המדדים ב-Cloud Monitoring

כדי להבין איך לייצא מדדים מ-Cloud Monitoring בצורה הכי טובה, חשוב להבין איך המדדים מאוחסנים.

סוגים של מדדים

יש 4 סוגים עיקריים של מדדים ב-Cloud Monitoring שאפשר לייצא.

Google Cloud רשימת המדדים הם מדדים משירותי Google Cloud , כמו Compute Engine ו-BigQuery.
רשימת מדדים של סוכנים הם מדדים ממכונות וירטואליות שמופעלים בהן סוכני Cloud Monitoring.
מדדים ממקורות חיצוניים הם מדדים מאפליקציות של צד שלישי ומדדים שהוגדרו על ידי המשתמש, כולל מדדים מותאמים אישית.

לכל אחד מסוגי המדדים האלה יש מתאר מדד, שכולל את סוג המדד וגם מטא-נתונים אחרים של המדד. המדד הבא הוא דוגמה לרשימה של מתארי מדדים מהשיטה projects.metricDescriptors.list של Monitoring API.

{
  "metricDescriptors": [
    {
      "name": "projects/sage-facet-201016/metricDescriptors/pubsub.googleapis.com/subscription/push_request_count",
      "labels": [
        {
          "key": "response_class",
          "description": "A classification group for the response code. It can be one of ['ack', 'deadline_exceeded', 'internal', 'invalid', 'remote_server_4xx', 'remote_server_5xx', 'unreachable']."
        },
        {
          "key": "response_code",
          "description": "Operation response code string, derived as a string representation of a status code (e.g., 'success', 'not_found', 'unavailable')."
        },
        {
          "key": "delivery_type",
          "description": "Push delivery mechanism."
        }
      ],
      "metricKind": "DELTA",
      "valueType": "INT64",
      "unit": "1",
      "description": "Cumulative count of push attempts, grouped by result. Unlike pulls, the push server implementation does not batch user messages. So each request only contains one user message. The push server retries on errors, so a given user message can appear multiple times.",
      "displayName": "Push requests",
      "type": "pubsub.googleapis.com/subscription/push_request_count",
      "metadata": {
        "launchStage": "GA",
        "samplePeriod": "60s",
        "ingestDelay": "120s"
      }
    }
  ]
}

השדות החשובים שצריך להבין בתיאור המדד הם type,‏ valueType ו-metricKind. השדות האלה מזהים את המדד ומשפיעים על הצבירה שאפשר לבצע עבור מתאר מדד.

סוגי מדדים

לכל מדד יש סוג מדד וסוג ערך. מידע נוסף זמין במאמר סוגי ערכים וסוגי מדדים. סוג המדד וסוג הערך שמשויך אליו חשובים כי השילוב ביניהם משפיע על האופן שבו המדדים מצטברים.

בדוגמה שלמעלה, סוג המדד pubsub.googleapis.com/subscription/push_request_count metric הוא DELTA וסוג הערך הוא INT64.

בקשת Push

ב-Cloud Monitoring, סוג המדד וסוגי הערכים מאוחסנים ב-metricsDescriptors, שזמינים ב-Monitoring API.

סדרות זמן

timeseries הם מדידות רגילות של כל סוג מדד שנשמרות לאורך זמן, ומכילות את סוג המדד, המטא-נתונים, התוויות ונקודות הנתונים הנמדדות. מדדים שנאספים באופן אוטומטי על ידי Monitoring, כמוGoogle Cloud metrics, נאספים באופן קבוע. לדוגמה, המדד appengine.googleapis.com/http/server/response_latencies נאסף כל 60 שניות.

קבוצה של נקודות שנאספו עבור timeseries מסוים עשויה לגדול לאורך זמן, בהתאם לתדירות הדיווח על הנתונים ולתוויות שמשויכות לסוג המדד. אם מייצאים את נקודות הנתונים הגולמיות של timeseries, יכול להיות שהייצוא יהיה גדול. כדי לצמצם את מספר נקודות הנתונים שמוחזרות, אפשר לצבור את המדדים על פני תקופת יישור נתונה.timeseries לדוגמה, באמצעות צבירה אפשר להחזיר נקודה על הגרף אחת לשעה עבור מדד נתון timeseries שיש לו נקודה על הגרף אחת לדקה. כך מצמצמים את מספר נקודות הנתונים שמיוצאות ואת העיבוד האנליטי שנדרש במנוע לניתוח נתונים. במאמר הזה, הערך timeseries מוחזר לכל סוג מדד שנבחר.

צבירת מדדים

אפשר להשתמש בצבירה כדי לשלב נתונים מכמה timeseries לתוך timeseries אחד. ‫Monitoring API מספק פונקציות עוצמתיות של יישור וצבירה, כך שלא צריך לבצע את הצבירה בעצמכם. כדי לעשות זאת, מעבירים את פרמטרי היישור והצבירה לקריאה ל-API. למידע נוסף על אופן צבירת הנתונים ב-Monitoring API, אפשר לקרוא את המאמר בנושא סינון וצבירת נתונים ואת הפוסט הזה בבלוג.

ממפים את metric type ל-aggregation type כדי לוודא שהמדדים תואמים ושהערך של timeseries מצטמצם בהתאם לצרכים האנליטיים שלכם. יש רשימות של פונקציות לצירוף נתונים ושל פונקציות לצמצום נתונים שאפשר להשתמש בהן כדי לצבור את timeseries. לפונקציות של יישור והפחתה יש קבוצה של מדדים שבהם אפשר להשתמש כדי ליישר או להפחית על סמך סוגי המדדים וסוגי הערכים. לדוגמה, אם מבצעים צבירה על פני שעה, התוצאה של הצבירה היא נקודה אחת שמוחזרת לשעה עבור timeseries.

דרך נוספת לכוונן את הצבירה היא באמצעות הפונקציה Group By, שמאפשרת לקבץ את הערכים המצטברים לרשימות של timeseries מצטברים. לדוגמה, אפשר לבחור לקבץ מדדים של App Engine על סמך מודול App Engine. קיבוץ לפי מודול App Engine בשילוב עם פונקציות ההתאמה והצמצום שמצטברות לשעה אחת, יוצר נקודה על הגרף אחת לכל מודול App Engine לכל שעה.

צבירת מדדים מאזנת בין העלות הגבוהה יותר של רישום נקודות נתונים בודדות לבין הצורך לשמור מספיק נתונים לניתוח מפורט לטווח ארוך.

פרטי הטמעה לדוגמה

ההטמעה לדוגמה מכילה את אותם רכיבים שמתוארים בתרשים עיצוב הארכיטקטורה. בקטעים הבאים מפורטים פרטי ההטמעה הרלוונטיים והפונקציונליים בכל שלב.

יצירת רשימת מדדים

ב-Cloud Monitoring מוגדרים יותר מאלף סוגי מדדים שיעזרו לכם לעקוב אחרי Google Cloud תוכנות של צד שלישי. ב-Monitoring API יש את השיטה projects.metricDescriptors.list שמחזירה רשימה של מדדים שזמינים לפרויקט Google Cloud. ממשק Monitoring API מספק מנגנון סינון שמאפשר לסנן את רשימת המדדים שרוצים לייצא לאחסון ולניתוח לטווח ארוך.

ההטמעה לדוגמה ב-GitHub משתמשת באפליקציית Python App Engine כדי לקבל רשימה של מדדים, ואז כותבת כל הודעה בנושא Pub/Sub בנפרד. הייצוא מופעל על ידי Cloud Scheduler שיוצר התראה ב-Pub/Sub כדי להפעיל את האפליקציה.

יש הרבה דרכים לקרוא ל-Monitoring API, ובמקרה הזה, הקריאה ל-Cloud Monitoring API ול-Pub/Sub API מתבצעת באמצעות ספריית הלקוח של Google API ל-Python, בגלל הגישה הגמישה שלה ל-Google APIs.

קבלת נתוני סדרות זמן

אתם מחלצים את timeseries של המדד ואז כותבים כל timeseries ל-Pub/Sub. באמצעות Monitoring API אפשר לצבור את ערכי המדדים לאורך תקופת יישור נתונה באמצעות השיטה project.timeseries.list. צבירת נתונים מפחיתה את עומס העיבוד, את דרישות האחסון, את זמני השאילתות ואת עלויות הניתוח. צבירת נתונים היא שיטה מומלצת לביצוע יעיל של ניתוח מדדים לטווח ארוך.

ההטמעה לדוגמה ב-GitHub משתמשת באפליקציית Python App Engine כדי להירשם לנושא, כשכל מדד לייצוא נשלח כהודעה נפרדת. לכל הודעה שמתקבלת, Pub/Sub דוחף את ההודעה לאפליקציית App Engine. האפליקציה מקבלת את timeseries של מדד מסוים שמצטבר על סמך הגדרת הקלט. במקרה הזה, הקריאות ל-Cloud Monitoring API ול-Pub/Sub API מתבצעות באמצעות ספריית הלקוח של Google API.

כל מדד יכול להחזיר ערך אחד או יותר של timeseries. כל מדד נשלח בהודעת Pub/Sub נפרדת להוספה ל-BigQuery. המיפוי של המדד type-to-aligner והמדד type-to-reducer מוטמע בהטמעה לדוגמה. בטבלה הבאה מפורט המיפוי שבו נעשה שימוש בהטמעה לדוגמה, על סמך הסיווגים של סוגי המדדים וסוגי הערכים שנתמכים על ידי כלי ההתאמה והצמצום.

סוג הערך	`GAUGE`	מיישר	הפחתה	`DELTA`	מיישר	הפחתה	`CUMULATIVE2`	מיישר	הפחתה
`BOOL`	כן	`ALIGN_FRACTION_TRUE`	ללא	לא	לא רלוונטי	לא רלוונטי	לא	לא רלוונטי	לא רלוונטי
`INT64`	כן	`ALIGN_SUM`	ללא	כן	`ALIGN_SUM`	ללא	כן	ללא	ללא
`DOUBLE`	כן	`ALIGN_SUM`	ללא	כן	`ALIGN_SUM`	ללא	כן	ללא	ללא
`STRING`	כן	לא כלול	לא כלול	לא	לא רלוונטי	לא רלוונטי	לא	לא רלוונטי	לא רלוונטי
`DISTRIBUTION`	כן	`ALIGN_SUM`	ללא	כן	`ALIGN_SUM`	ללא	כן	ללא	ללא
`MONEY`	לא	לא רלוונטי	לא רלוונטי	לא	לא רלוונטי	לא רלוונטי	לא	לא רלוונטי	לא רלוונטי

חשוב להביא בחשבון את המיפוי של valueType ל-aligners ול-reducers, כי צבירה אפשרית רק עבור valueTypes ו-metricKinds ספציפיים לכל aligner ולכל reducer.

לדוגמה, נניח את סוג pubsub.googleapis.com/subscription/push_request_count metric. בהתאם לסוג המדד DELTA ולסוג הערך INT64, אחת הדרכים לצבירת המדד היא:

תקופת ההתאמה – 3,600 שניות (שעה)
‫Aligner = ALIGN_SUM – נקודת הנתונים שמתקבלת בתקופת ההתאמה היא סכום כל נקודות הנתונים בתקופת ההתאמה.
‫Reducer = REDUCE_SUM – הפחתה על ידי חישוב הסכום של a timeseries לכל תקופת התאמה.

בנוסף לערכים של תקופת ההתאמה, הכלי להתאמה והפונקציה לצמצום, השיטה project.timeseries.list דורשת עוד כמה קלטים:

‫filter – בוחרים את המדד שיוחזר.
‫startTime – בוחרים את נקודת ההתחלה בזמן שממנה רוצים לקבל את הנתונים timeseries.
‫endTime – בוחרים את נקודת הזמן האחרונה שרוצים לחזור אליה.timeseries
‫groupBy - מזינים את השדות שלפיהם רוצים לקבץ את התשובה של timeseries.
‫alignmentPeriod – מזינים את תקופות הזמן שרוצים להתאים את המדדים אליהן.
‫perSeriesAligner – יישור הנקודות במרווחי זמן שווים שמוגדרים על ידי alignmentPeriod.
‫crossSeriesReducer – שילוב של כמה נקודות עם ערכי תוויות שונים לנקודה אחת בכל מרווח זמן.

בקשת ה-GET ל-API כוללת את כל הפרמטרים שמתוארים ברשימה הקודמת.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=START_TIME_VALUE&
interval.endTime=END_TIME_VALUE&
aggregation.alignmentPeriod=ALIGNMENT_VALUE&
aggregation.perSeriesAligner=ALIGNER_VALUE&
aggregation.crossSeriesReducer=REDUCER_VALUE&
filter=FILTER_VALUE&
aggregation.groupByFields=GROUP_BY_VALUE

בדוגמה הבאה של HTTP GET מוצגת קריאה ל-method של projects.timeseries.list API באמצעות פרמטרי הקלט:

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z&
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
aggregation.crossSeriesReducer=REDUCE_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+&
aggregation.groupByFields=metric.labels.key

הקריאה ל-Monitoring API שמוצגת למעלה כוללת את crossSeriesReducer=REDUCE_SUM, כלומר המדדים מכווצים ומצומצמים לסכום יחיד, כמו בדוגמה הבאה.

{
  "timeSeries": [
    {
      "metric": {
        "type": "pubsub.googleapis.com/subscription/push_request_count"
      },
      "resource": {
        "type": "pubsub_subscription",
        "labels": {
          "project_id": "sage-facet-201016"
        }
      },
      "metricKind": "DELTA",
      "valueType": "INT64",
      "points": [
        {
          "interval": {
            "startTime": "2019-02-08T14:00:00.311635Z",
            "endTime": "2019-02-08T15:00:00.311635Z"
          },
          "value": {
            "int64Value": "788"
          }
        }
      ]
    }
  ]
}

ברמת צבירת הנתונים הזו, הנתונים נצברים לנקודה על הגרף אחת, ולכן זהו מדד אידיאלי לפרויקט הכולל שלכם. Google Cloud עם זאת, אי אפשר לראות אילו משאבים תרמו למדד. בדוגמה שלמעלה, אי אפשר לדעת איזו מינוי Pub/Sub תרם הכי הרבה למספר הבקשות.

אם רוצים לבדוק את הפרטים של הרכיבים הבודדים שמייצרים את הערך timeseries, אפשר להסיר את הפרמטר crossSeriesReducer. בלי crossSeriesReducer, ‏Monitoring API לא משלב את timeseries השונים כדי ליצור ערך יחיד.

בדוגמה הבאה HTTP GET מוצגת קריאה ל-method ‏projects.timeseries.list של API באמצעות פרמטרי הקלט. התכונה crossSeriesReducer לא כלולה.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+

בתגובת ה-JSON הבאה, הערכים של metric.labels.keys זהים בשתי התוצאות כי timeseries מקובץ. מוחזרים נקודות נפרדות לכל אחד מ-resource.labels.subscription_ids הערכים. בודקים את הערכים של metric_export_init_pub ו-metrics_list ב-JSON הבא. מומלץ להשתמש ברמת הצבירה הזו כי היא מאפשרת לכם להשתמש בGoogle Cloud מוצרים, שכלולים כתוויות משאבים, בשאילתות BigQuery.

{
    "timeSeries": [
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "1"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metric_export_init_pub"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        },
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "803"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metrics_list"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        }
    ]
}

כל מדד בפלט JSON של קריאה ל-API‏ projects.timeseries.list נכתב ישירות ל-Pub/Sub כהודעה נפרדת. יכול להיות שיהיה פיצול (fan-out) שבו מדד קלט אחד יוצר מדד אחד או יותר של timeseries. ‫Pub/Sub מאפשר לטפל ב-fan-out פוטנציאלי גדול בלי לחרוג מהזמן הקצוב לתפוגה.

תקופת ההתאמה שצוינה כקלט פירושה שהערכים במהלך פרק הזמן הזה מצטברים לערך יחיד, כמו שמוצג בתגובה לדוגמה הקודמת. תקופת ההתאמה מגדירה גם את התדירות שבה יופעל הייצוא. לדוגמה, אם תקופת ההתאמה שלכם היא 3,600 שניות, או שעה אחת, הייצוא יפעל כל שעה כדי לייצא באופן קבוע את timeseries.

מדדים של חנויות

ההטמעה לדוגמה ב-GitHub משתמשת באפליקציית Python App Engine כדי לקרוא כל timeseries ואז להוסיף את הרשומות לטבלה ב-BigQuery. לכל הודעה שמתקבלת, Pub/Sub דוחף את ההודעה לאפליקציית App Engine. ההודעה ב-Pub/Sub מכילה נתונים של מדדים שמיוצאים מ-Monitoring API בפורמט JSON, וצריך למפות אותה למבנה של טבלה ב-BigQuery. במקרה הזה, מתבצעות קריאות ל-BigQuery APIs באמצעות ספריית הלקוח של Google API.

הסכימה של BigQuery מתוכננת כך שתהיה מיפוי קרוב ל-JSON שמיוצא מ-Monitoring API. כשיוצרים את סכימת הטבלה ב-BigQuery, צריך לקחת בחשבון את גודל הנתונים, כי הוא גדל עם הזמן.

ב-BigQuery, מומלץ לחלק את הטבלה למחיצות על סמך שדה תאריך, כי כך אפשר להריץ שאילתות בצורה יעילה יותר על ידי בחירת טווחי תאריכים בלי לבצע סריקה מלאה של הטבלה. אם אתם מתכננים להפעיל את הייצוא באופן קבוע, אתם יכולים להשתמש בבטחה בחלוקה לפי מחיצות שמוגדרת כברירת מחדל על סמך תאריך ההוספה.

צילום מסך של חלוקה למחיצות ב-BigQuery

אם אתם מתכננים להעלות מדדים בכמות גדולה או לא להפעיל את הייצוא באופן תקופתי, צריך לבצע חלוקה למחיצות לפי end_time,, מה שמחייב שינויים בסכימת BigQuery. אפשר להעביר את end_time לשדה ברמה העליונה בסכימה, שבו אפשר להשתמש בו לחלוקה למחיצות, או להוסיף שדה חדש לסכימה. חובה להעביר את השדה end_time כי הוא כלול ברשומה ב-BigQuery, והחלוקה למחיצות חייבת להתבצע בשדה ברמה העליונה. מידע נוסף זמין במאמר בנושא חלוקה למחיצות ב-BigQuery.

ב-BigQuery אפשר גם להגדיר תפוגה למערכי נתונים, לטבלאות ולמחיצות של טבלאות אחרי פרק זמן מסוים.

צילום מסך של הגדרת תפוגת הנתונים ב-BigQuery

השימוש בתכונה הזו הוא דרך יעילה למחוק נתונים ישנים כשאין בהם יותר צורך. לדוגמה, אם הניתוח שלכם מתייחס לתקופה של 3 שנים, אתם יכולים להוסיף מדיניות למחיקת נתונים בני יותר מ-3 שנים.

תזמון ייצוא

‫Cloud Scheduler הוא מתזמן משימות cron מנוהל. ‫Cloud Scheduler מאפשר להשתמש בפורמט התזמון הרגיל של cron כדי להפעיל אפליקציית App Engine, לשלוח הודעה באמצעות Pub/Sub או לשלוח הודעה לנקודת קצה שרירותית של HTTP.

בהטמעה לדוגמה ב-GitHub, ‏ Cloud Scheduler מפעיל את אפליקציית list-metrics App Engine כל שעה על ידי שליחת הודעת Pub/Sub עם טוקן שתואם להגדרה של App Engine. תקופת הצבירה שמוגדרת כברירת מחדל בהגדרת האפליקציה היא 3,600 שניות, או שעה אחת, שמתאימה לתדירות שבה מופעלת האפליקציה. מומלץ להשתמש בצבירה של שעה לפחות, כי היא מאפשרת לצמצם את נפחי הנתונים ועדיין לשמור על נתונים מדויקים. אם אתם משתמשים בתקופת התאמה שונה, אתם צריכים לשנות את תדירות הייצוא כך שתתאים לתקופת ההתאמה. ההטמעה לדוגמה שומרת את הערך האחרון של end_time ב-Cloud Storage ומשתמשת בו כערך הבא של start_time, אלא אם הערך של start_time מועבר כפרמטר.

בצילום המסך הבא מ-Cloud Scheduler אפשר לראות איך משתמשים במסוף Google Cloud כדי להגדיר את Cloud Scheduler להפעלת אפליקציית App Engine‏ list-metrics בכל שעה.

הגדרת Cloud Scheduler

בשדה תדירות נעשה שימוש בתחביר בסגנון cron כדי לציין ל-Cloud Scheduler באיזו תדירות להפעיל את האפליקציה. בשדה יעד מצוינת הודעת Pub/Sub שנוצרת, ובשדה מטען ייעודי מופיעים הנתונים שכלולים בהודעת Pub/Sub.

שימוש במדדים המיוצאים

אחרי ייצוא הנתונים ל-BigQuery, אפשר להשתמש ב-SQL סטנדרטי כדי להריץ שאילתות על הנתונים או ליצור לוחות בקרה כדי להציג מגמות במדדים לאורך זמן.

דוגמה לשאילתה: זמני האחזור של App Engine

השאילתה הבאה מוצאת את הערכים המינימליים, המקסימליים והממוצעים של מדד חביון הממוצע עבור אפליקציית App Engine. התג metric.type מזהה את מדד App Engine, והתוויות מזהות את אפליקציית App Engine על סמך ערך התווית project_id. המדד הזה הוא ערך DISTRIBUTION ב-Monitoring API, שממופה לאובייקט השדה distribution_value ב-BigQuery, ולכן משתמשים ב-point.value.distribution_value.mean. השדהend_time מתייחס לערכים של 30 הימים האחרונים.

SELECT
  metric.type AS metric_type,
  EXTRACT(DATE  FROM point.INTERVAL.start_time) AS extract_date,
  MAX(point.value.distribution_value.mean) AS max_mean,
  MIN(point.value.distribution_value.mean) AS min_mean,
  AVG(point.value.distribution_value.mean) AS avg_mean
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'appengine.googleapis.com/http/server/response_latencies'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
GROUP BY
  metric_type,
  extract_date
ORDER BY
  extract_date

שאילתה לדוגמה: ספירת שאילתות ב-BigQuery

השאילתה הבאה מחזירה את מספר השאילתות ב-BigQuery ביום בפרויקט. השדה int64_value משמש כי המדד הזה הוא ערך INT64 ב-Monitoring API, שממופה לשדה int64_value ב-BigQuery. הערך metric.typeמזהה את המדד ב-BigQuery, והתוויות מזהות את הפרויקט על סמך ערך התווית project_id. הערכים בשדה end_time מתייחסים ל-30 הימים האחרונים.

SELECT
  EXTRACT(DATE  FROM point.interval.end_time) AS extract_date,
  sum(point.value.int64_value) as query_cnt
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  and metric.type = 'bigquery.googleapis.com/query/count'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
group by extract_date
order by extract_date

שאילתה לדוגמה: מכונות Compute Engine

השאילתה הבאה מוצאת את הערכים המינימליים, המקסימליים והממוצעים של מדד השימוש במעבד (CPU) במכונות וירטואליות של Compute Engine בפרויקט, לפי שבוע. ‫metric.type מציין את המדד של Compute Engine, והתוויות מציינות את המופעים על סמך ערך התווית project_id. הערכים בשדה end_time מתייחסים ל-30 הימים האחרונים.

SELECT
  EXTRACT(WEEK  FROM point.interval.end_time) AS extract_date,
  min(point.value.double_value) as min_cpu_util,
  max(point.value.double_value) as max_cpu_util,
  avg(point.value.double_value) as avg_cpu_util
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'compute.googleapis.com/instance/cpu/utilization'
group by extract_date
order by extract_date

המחשה חזותית של נתונים

‫BigQuery משולב עם הרבה כלים שבהם אפשר להשתמש כדי ליצור ויזואליזציה של נתונים.

‫Looker Studio הוא כלי חינמי שפיתחה Google, שבו אפשר ליצור תרשימים ולוחות בקרה של נתונים כדי להציג את נתוני המדדים, ואז לשתף אותם עם הצוות. בדוגמה הבאה מוצג תרשים קו מגמה של זמן האחזור והספירה של המדד appengine.googleapis.com/http/server/response_latencies לאורך זמן.

תרשים של מגמות ב-App Engine לאורך זמן

‫Colaboratory הוא כלי מחקר ללמידת מכונה ולמחקר. זהו סביבת מחברת Jupyter מתארחת שלא צריך להגדיר כדי להשתמש בה ולגשת לנתונים ב-BigQuery. באמצעות notebook של Colab, פקודות Python ושאילתות SQL, אפשר לפתח ניתוחים מפורטים והמחשות חזותיות.

תרשים של השימוש במעבד

מעקב אחרי יישום הייצוא לדוגמה

במהלך הייצוא, צריך לעקוב אחריו. אחת הדרכים להחליט אילו מדדים כדאי לעקוב אחריהם היא להגדיר יעד למדידת רמת השירות (SLO). הסכם רמת שירות (SLO) הוא ערך יעד או טווח ערכים לרמת שירות שנמדדת באמצעות מדד. בספר Site reliability engineering מתוארים 4 תחומים עיקריים של יעדי SLO: זמינות, תפוקה, שיעור שגיאות וזמן אחזור. כשמייצאים נתונים, שני שיקולים חשובים הם קצב העברת הנתונים ושיעור השגיאות. אפשר לעקוב אחריהם באמצעות המדדים הבאים:

קצב העברת נתונים – appengine.googleapis.com/http/server/response_count
שיעור השגיאות – logging.googleapis.com/log_entry_count

לדוגמה, אפשר לעקוב אחרי שיעור השגיאות באמצעות המדד log_entry_count ולסנן אותו לפי אפליקציות App Engine ‏ (list-metrics,‏ get-timeseries, ‏ write-metrics) עם רמת חומרה של ERROR. אחר כך תוכלו להשתמש במדיניות ההתראות ב-Cloud Monitoring כדי לקבל התראה על שגיאות שנתקלתם בהן באפליקציית הייצוא.

כללי מדיניות התראות

בממשק המשתמש של ההתראות מוצג תרשים של המדד log_entry_count בהשוואה לסף ליצירת ההתראה.

תרשים של תנאים

המאמרים הבאים

אפשר לראות את הטמעת ההפניה ב-GitHub.
מסמכי Cloud Monitoring
מאמרי העזרה בנושא Cloud Monitoring v3 API
לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
אפשר גם לקרוא את המשאבים שלנו בנושא DevOps.
מידע נוסף על היכולות של DevOps שקשורות לפתרון הזה:
אתם יכולים לעשות את הבדיקה המהירה של DevOps כדי להבין מה מצבכם בהשוואה לשאר האנשים בתחום.

ייצוא מדדים מ-Cloud Monitoring קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.