Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Last reviewed 2024-08-14 UTC

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

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

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

תרחישים לדוגמה לייצוא מדדים

‫Cloud Monitoring אוסף מדדים ומטא-נתונים מ Google Cloud ומאינסטרומנטציה של אפליקציות. מדדי המעקב מספקים יכולת מעקב מפורטת אחר הביצועים, זמן הפעולה התקינה והתקינות הכוללת של אפליקציות בענן באמצעות 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.
מדדי דוחות: אפשר להשתמש ב-Data 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 ול-Pub/Sub APIs מתבצעת באמצעות ספריית הלקוח של Google API ל-Python, בגלל הגישה הגמישה שלה ל-Google APIs.

Get timeseries

אתם מחלצים את 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 מאפשרת לטפל בפיצול פוטנציאלי גדול בלי לחרוג מהזמן הקצוב לתפוגה.

תקופת ההתאמה שצוינה כקלט פירושה שהערכים במהלך פרק הזמן הזה מצטברים לערך יחיד, כמו שמוצג בתגובה לדוגמה הקודמת. תקופת ההתאמה מגדירה גם את התדירות שבה יופעל הייצוא. לדוגמה, אם תקופת ההתאמה שלכם היא 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. השימוש ב-point.value.distribution_value.mean נובע מכך שהמדד הזה הוא ערך DISTRIBUTION ב-Monitoring API, שממופה לאובייקט השדה distribution_value ב-BigQuery. השדה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 משולב עם הרבה כלים שבהם אפשר להשתמש כדי ליצור ויזואליזציה של נתונים.

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

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

‫Colaboratory הוא כלי מחקר ללמידת מכונה ולמחקר. זו סביבת מחברת Jupyter מארחת שלא צריך להגדיר כדי להשתמש בה ולגשת לנתונים ב-BigQuery. באמצעות מחברת 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 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.