הגדרת שעה מדויקת למכונות Compute Engine מסוג U4

בדף הזה מוסבר איך להגדיר זמן מדויק למכונה וירטואלית (VM) ב-Compute Engine מדגם U4, ואיך להגדיר מעקב כדי שתוכלו לראות את רמת הדיוק של סנכרון הזמן.

איך זה עובד

Google Cloud פתרון עם זמן טעינה קצר במיוחד (ULL) משתמש בפרוטוקול Firefly לסנכרון השעון כדי לספק סנכרון ברמת הננו-שנייה. ‫Firefly מבצע באופן אוטומטי את הפעולות הבאות:

  • מבצע סנכרון פנימי כדי לסנכרן את השעונים של ממשק הרשת הפיזי (NIC) של כל השרתים המארחים של מופעי U4 אחד עם השני.
  • מבצעת סנכרון חיצוני כדי לסנכרן את השעונים של כרטיסי ה-NIC הפיזיים של כל שרתי המארחים של מופעי U4 עם הזמן האוניברסלי המתואם (UTC).

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

מידע נוסף על Firefly זמין ב Google Cloud פוסט בבלוג: הסבר על פרוטוקול סנכרון השעון של Firefly.

לפני שמתחילים

לפני שמגדירים שעה מדויקת למכונות U4 ב-Compute Engine, צריך לעמוד בדרישות הבאות.

יצירת מכונת U4

אם עוד לא עשיתם זאת, צרו מכונה של Compute Engine מסוג U4. עיינו בהליך שמתאים לתרחיש השימוש שלכם:

מוודאים שלא פועלים שירותים אחרים לסנכרון השעון

בנהלים שבדף הזה נעשה שימוש ב-chrony כלקוח מומלץ לסנכרון השעון. לפני שמתחילים, מוודאים שלא פועלים במופע שירותים אחרים לסנכרון השעון, כמו ntpd, ‏ systemd-timesyncd או phc2sys. אינטראקציות לא צפויות עם השירותים האלה עלולות לגרום לשגיאות בהגדרה של chrony.

ב-chrony גרסה 4.7 ואילך, אפשר להריץ את הפקודה הבאה כדי לבדוק את יומן האזהרות של chronyd שירותים אחרים לסנכרון השעון:

journalctl -u chronyd

אם פועל שירות אחר לסנכרון השעון, הפלט כולל הודעת אזהרה כמו: System clock interference detected (another NTP client?).

הגדרה של chrony כך שייטען רק אחרי שמנהלי ההתקנים של הרשת יציבים

במקרים מסוימים, יכול להיות ש-systemd ייטען chrony לפני שהאתחול של מנהלי ההתקנים של ממשק הרשת יסתיים, ולכן chrony לא יופעל כי הוא לא יכול לאתחל את מכשיר שעון החומרה של PTP‏ (PHC).

כדי למנוע את הבעיה שצוינה למעלה, צריך לבטל את ההגדרה של קובץ היחידה chrony של systemd כדי להמתין עד שמכשירי PHC יהיו מוכנים:

  1. מריצים את פקודת העריכה:

    systemctl edit chronyd

  2. מוסיפים את שינוי ברירת המחדל שמתאים לסוג המופע:

    • במקרים של מופעי U4P ו-U4C:

      [Unit]
After=dev-ptp0.device dev-ptp1.device dev-ptp2.device
Requires=dev-ptp0.device dev-ptp1.device dev-ptp2.device

    • במקרים של מופעי U4S:

      [Unit]
After=dev-ptp0.device
Requires=dev-ptp0.device

  3. מפעילים מחדש את השירות. הפקודה systemctl edit שהרצתם קודם טענה מחדש את הדמון באופן אוטומטי, אבל מומלץ להריץ את הפקודה הבאה כדי לוודא ש-chrony פועל אחרי השינויים.

    systemctl restart chronyd

אחזור שמות של ממשקי רשת

מקבלים את השמות של ממשקי הרשת הווירטואלית (vNIC) של המופע כפי שהוקצו על ידי מערכת ההפעלה של האורח. בזמן ש- Google Cloud משתמש בשמות כמו nic0 ו-nic1, הפורמט של השמות במערכת ההפעלה של האורח שונה, למשל enp22s0f0 ו-ens8f0.

כדי להציג את שמות ה-vNIC בסדר מסוים, מריצים את הפקודה הבאה:

find /sys/class/net -type l -not -lname '*virtual*' -printf '%l %f\n' | sort | awk '{print $2}'

הגדרת chrony לשימוש בשעון של כרטיס ה-NIC הפיזי שסונכרן עם Firefly

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

ממשקי הרשת הווירטואליים (vNIC) של מופע U4, כפי שמוצגים במערכת ההפעלה של האורח (למשל enp22s0f0), ממופים לממשקי רשת פיזיים בשרת המארח של המופע. כרטיס רשת וירטואלי יכול לגשת לשעון הפיזי של כרטיס הרשת באמצעות מכשיר PTP hardware clock (PHC) (שעון חומרה של PTP) מתאים:

  • שמות מכשירי PHC ב-Linux הם בפורמט הבא: /dev/ptpNUMBER, כאשר NUMBER נקבע על ידי ליבת Linux בהתאם לסדר האתחול של המכשיר. לדוגמה, שמות המכשירים הבאים של PHC: ‏ /dev/ptp0, ‏ /dev/ptp1, ‏ /dev/ptp2.

  • כדי לציין שעון NIC פיזי כמקור לסנכרון, ההגדרה chrony צריכה להשתמש במכשיר PHC המתאים או להפנות אליו.

בכל אחד מהקטעים הבאים מופיעות דוגמאות לאופן ההגדרה של chrony בהתאם לדרישות הקודמות. עוברים לקטע שמתאים לסוג המופע ולגרסה של chrony:

הגדרת chrony מגרסה 4.7 ואילך במכונות U4P ו-U4C

chrony בגרסה 4.7 ואילך אפשר לציין שם של vNIC כמקור השעון, והמערכת תמיר אותו באופן אוטומטי למכשיר השעון התואם של PTP (PHC) שמייצג את השעון של ה-NIC הפיזי.

כדי להגדיר את chrony בגרסה 4.7 ואילך במופע U4P או U4C, צריך לבצע את הפעולות הבאות:

  1. מוסיפים את הטקסט הבא לקובץ התצורה chrony, /etc/chrony.conf. הקובץ צריך להכיל רק את ההגדרות הבאות. חשוב לוודא שמסירים או מחליפים את כל התוכן הקיים בקובץ.

    # Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC NIC0:nocrossts poll -1 noselect
refclock PHC NIC1:nocrossts poll -1
refclock PHC NIC2:nocrossts poll -1 noselect

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC NIC0 poll -1 noselect
refclock PHC NIC1 poll -1 noselect
refclock PHC NIC2 poll -1 noselect

    מחליפים את NIC0,‏ NIC1 ו-NIC2 בשמות המתאימים שקיבלתם קודם. אם צריך, אפשר לעיין במאמר בנושא קבלת שמות של ממשקי רשת.

  2. כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:

    systemctl restart chronyd

    ‫chrony מתעד ביומנים נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של NIC1 כמקור הזמן.

הגדרת chrony 4.6.1 וגרסאות קודמות במופעי U4P ו-U4C

בגרסאות 4.6.1 ואילך של chrony, צריך לציין באופן ידני את שם המכשיר של שעון החומרה PTP ‏ (PHC) בקובץ ההגדרה.

כדי להגדיר את chrony בגרסה 4.6.1 ובגרסאות קודמות במופע U4P או U4C, צריך לבצע את הפעולות הבאות:

  1. מקבלים את מספר האינדקס של מכשיר ה-PHC שמשויך ל-vNIC. בדוגמה הבאה נעשה שימוש ב-vNIC הראשון.

    ethtool -T NIC0

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

    1. בדיקת הפלט של PTP Hardware Clock:NUMBER

      בדוגמה הזו של הפלט מוצג הערך PTP Hardware Clock: 1, שמתאים לערך /dev/ptp1.

      Time stamping parameters for enp22s0f0:
Capabilities:
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
        off
Hardware Receive Filter Modes:
        none
        all

  2. מוסיפים את הטקסט הבא לקובץ התצורה chrony, /etc/chrony.conf. הקובץ צריך להכיל רק את ההגדרות הבאות. חשוב לוודא שמסירים או מחליפים את כל התוכן הקיים בקובץ.

    הפלט ethtool בשלב הקודם הראה ש-enp22s0f0 משתמש ב-/dev/ptp1. בדוגמה הבאה, השעון של המערכת מסונכרן עם השעון הפיזי של כרטיס ה-NIC המתאים ל-enp22s0f0 על ידי ציון: refclock PHC /dev/ptp1:nocrossts poll -1.

    # Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC /dev/ptp0:nocrossts poll -1 noselect
refclock PHC /dev/ptp1:nocrossts poll -1
refclock PHC /dev/ptp2:nocrossts poll -1 noselect

# The following lines opportunistically enable Precision Time Measurement (PTM) based clock synchronization.
# Note that PTM can potentially result in a (constant) clock skew of up to 700 nanoseconds
# which is not accounted for in chrony's accuracy metrics.
refclock PHC /dev/ptp0 poll -1 noselect
refclock PHC /dev/ptp1 poll -1 noselect
refclock PHC /dev/ptp2 poll -1 noselect

  3. כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:

    systemctl restart chronyd

    ‫chrony מתעד ביומנים נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של enp22s0f0 כמקור הזמן.

הגדרת chrony בגרסה 4.7 ואילך במכונות U4S

מומלץ להשתמש בגרסאות chrony 4.7 ואילך עבור מופעי U4S. שימוש בגרסאות קודמות עלול לגרום לשגיאות תכופות, כי מכשיר סנכרון השעון של Compute Engine למכונות וירטואליות (ptp_kvm) עלול לגרום לשינויים במספרי האינדקס של מכשירי שעון חומרה של PTP ‏(PHC).

ההגדרה לדוגמה הזו של מופעי U4S דומה לזו שמשמשת למופעי U4P ו-U4C, אבל יש ביניהן את ההבדלים הבאים:

  • בדוגמה הזו יש כרטיס רשת וירטואלי אחד. למופע U4S יכולים להיות כמה vNIC, אבל כולם מגובים על ידי אותו NIC פיזי וניגשים לאותו שעון NIC פיזי.
  • מדידת זמן מדויקת (PTM) לא זמינה.

כדי להגדיר את chrony בגרסה 4.7 ואילך במופע U4S, מבצעים את הפעולות הבאות:

  1. מוסיפים את הטקסט הבא לקובץ התצורה chrony, /etc/chrony.conf. הקובץ צריך להכיל רק את ההגדרות הבאות. חשוב לוודא שמסירים או מחליפים את כל התוכן הקיים בקובץ.

    # Record the rate at which the system clock gains/loses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 micro-second.
makestep 0.0000001 3

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
log measurements statistics tracking refclocks

# U4 Compute Engine instance clocks are 200ppb accurate
maxclockerror 0.2

# Configure all clocks for tracking, but select only one of them as source.
refclock PHC NIC0:nocrossts poll -1

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

  2. כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:

    systemctl restart chronyd

    ‫chrony מתעד ביומנים נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של NIC0 כמקור הזמן.

אימות ההגדרה של chrony

כדי לוודא ש-chrony מוגדר בצורה נכונה, מריצים את הפקודה הבאה:

chronyc sourcestats

אם ההגדרה בוצעה בהצלחה, הפלט ייראה כך:

Name/IP Address             NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PHC0                        5   3     2     -0.002      0.014     +9ns     2ns
PHC1                        5   3     2     -0.003      0.007     -0ns     1ns
PHC2                        5   3     2     -0.004      0.016    +33ns     2ns
PHC3                        5   5     2     +0.002      0.078   +135ns    10ns
PHC4                        5   3     2     -0.005      0.077   +130ns     9ns
PHC5                        5   5     2     -0.006      0.131   +123ns    16ns

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

שינוי ההגדרה של chrony

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

  1. מסירים את noselect מהשורה שכוללת את שם ה-vNIC שרוצים להשתמש בשעון ה-NIC הפיזי המתאים לו.
  2. מוסיפים את noselect לשורה שכוללת את שם ה-vNIC שרוצים להפסיק להשתמש בשעון ה-NIC הפיזי התואם שלו.
  3. מחילים את ההגדרה החדשה על ידי הפעלה מחדש של chronyd: systemctl restart chronyd.

מעקב אחרי סנכרון הזמן

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

מדדים זמינים לסנכרון זמן

אפשר להשתמש במדדים הבאים כדי לעקוב אחרי סנכרון הזמן:

מדידה המדד הזמין והתיאור שלו
העתקת שעון המערכת של המופע לשעון של כרטיס ה-NIC הפיזי logging.googleapis.com/user/phc-clock-max-error

המדד הזה בודק את הדיוק של הסנכרון בין שעון המערכת של המופע לבין שעון ה-NIC הפיזי בשרת המארח שלו.

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

שעון כרטיס רשת פיזי לפי UTC compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty

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

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

הסטטוס הכללי של השעון הפיזי של כרטיס ה-NIC compute.googleapis.com/instance/time/firefly_nic_sync_healthy

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

אפשר להציג את המדד הזה, להגדיר מדיניות התראות וליצור לוחות בקרה מותאמים אישית כמו שמתואר במאמר שימוש במדדים של Cloud Monitoring.

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

הגדרת מדד מותאם אישית לשעון המערכת של המופע

בקטע הזה מופיעה דוגמה להגדרת מעקב שמבצעת את הפעולות הבאות:

  • הגדרת סוכן התפעול לאיסוף יומן של chrony לצורך דיוק הסנכרון מהמכונה
  • מגדיר את Cloud Monitoring כך שיקבל את היומן המתאים מכל המופעים בפרויקט בתור מדד מבוסס-יומן

הגדרת סוכן התפעול של Google Cloud במופע

כדי להגדיר את סוכן תפעול לאיסוף המדד שנדרש למעקב, מבצעים את הפעולות הבאות:

  1. אם עדיין לא עשיתם זאת, מתקינים את סוכן תפעול במכונה.

  2. מוסיפים את ההגדרה הבאה לקובץ /etc/google-cloud-ops-agent/config.yaml:

    logging:
  receivers:
    chrony_tracking_receiver:
      type: files
      include_paths:
        - /var/log/chrony/tracking.log
  processors:
    chrony_tracking_processor:
      type: parse_regex
      regex: "^.*PHC.*  (?<max_error>[-\d\.eE]+)$"
  service:
    pipelines:
      chrony_tracking_pipeline:
        receivers: [chrony_tracking_receiver]
        processors: [chrony_tracking_processor]

  3. מפעילים מחדש את סוכן תפעול באמצעות הפקודה הבאה:

    systemctl restart google-cloud-ops-agent

הגדרת מדד מבוסס-יומן ולוח בקרה בפרויקט

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

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

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

#!/bin/bash

if [ -z "$1" ]; then
    echo "Usage: setup_logging.sh <project_id>" >&2
    exit 1
fi

PROJECT_ID="$1"
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID  --format="value(projectNumber)")
SERVICE_ACCOUNT_EMAIL=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

# Grant permissions:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/compute.instanceAdmin"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/monitoring.metricWriter"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/logging.logWriter"

# Configure log-based metric
METRIC_CONF='
{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "logName=~\".*/logs/chrony_tracking_receiver\"",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": [ { "key": "instance_id", "valueType": "STRING",
          "description": "Instance ID for the source instance" } ]
  },
  "valueExtractor": "REGEXP_EXTRACT(jsonPayload.max_error, \"(.*)\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 1.0E-6, 5.0E-6, 1.0E-5, 1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  },
  "labelExtractors": {
    "instance_id": "REGEXP_EXTRACT(resource.labels.instance_id, \"(.*)\")"
  }
}
'
echo "$METRIC_CONF" > /tmp/clock-error-metric.json
gcloud logging metrics create --project=${PROJECT_ID} phc-clock-max-error --config-from-file=/tmp/clock-error-metric.json

# Create a dashboard plotting the clock accuracy

DASHBOARD_CONF='
{
  "displayName": "Clock Accuracy",
  "dashboardFilters": [],
  "description": "",
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "height": 19,
        "width": 48,
        "widget": {
          "title": "Combined Accuracy With Threshold",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "prometheusQuery": "(\n  histogram_quantile(\n    1, \n    sum by (le, instance_id) (\n      increase({\"__name__\"=\"logging.googleapis.com/user/phc-clock-max-error_bucket\", monitored_resource=\"gce_instance\"}[${__interval}])\n    )\n  ) * 1e9\n) \n+ on(instance_id) \nmax by (instance_id) (\n  max_over_time({\"__name__\"=\"compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty\", monitored_resource=\"gce_instance\"}[${__interval}])\n)",
                  "unitOverride": "ns"
                }
              }
            ],
            "thresholds": [
              {
                "color": "COLOR_UNSPECIFIED",
                "direction": "DIRECTION_UNSPECIFIED",
                "label": "",
                "targetAxis": "Y1",
                "value": 30000
              }
            ],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      },
      {
        "yPos": 19,
        "height": 16,
        "width": 24,
        "widget": {
          "title": "NIC-UTC sync accuracy",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "minAlignmentPeriod": "60s",
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "timeSeriesFilter": {
                    "aggregation": {
                      "alignmentPeriod": "60s",
                      "crossSeriesReducer": "REDUCE_SUM",
                      "groupByFields": [
                        "metric.label.\"instance_name\"",
                        "metric.label.\"nic_id\"",
                        "resource.label.\"instance_id\""
                      ],
                      "perSeriesAligner": "ALIGN_MEAN"
                    },
                    "filter": "metric.type=\"compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty\" resource.type=\"gce_instance\""
                  },
                  "unitOverride": ""
                }
              }
            ],
            "thresholds": [],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      },
      {
        "yPos": 19,
        "xPos": 24,
        "height": 16,
        "width": 24,
        "widget": {
          "title": "VM-NIC sync Accuracy",
          "id": "",
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR",
              "showLegend": false
            },
            "dataSets": [
              {
                "breakdowns": [],
                "dimensions": [],
                "legendTemplate": "",
                "measures": [],
                "minAlignmentPeriod": "60s",
                "plotType": "LINE",
                "sort": [],
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "outputFullDuration": false,
                  "timeSeriesFilter": {
                    "aggregation": {
                      "alignmentPeriod": "60s",
                      "crossSeriesReducer": "REDUCE_PERCENTILE_99",
                      "groupByFields": [
                        "metric.label.\"instance_id\""
                      ],
                      "perSeriesAligner": "ALIGN_DELTA"
                    },
                    "filter": "metric.type=\"logging.googleapis.com/user/phc-clock-max-error\""
                  },
                  "unitOverride": ""
                }
              }
            ],
            "thresholds": [],
            "yAxis": {
              "label": "",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}
'

echo "$DASHBOARD_CONF" > /tmp/metrics-dashboard.json

gcloud monitoring dashboards create --project=${PROJECT_ID} --config-from-file=/tmp/metrics-dashboard.json

שימוש במדדים של Cloud Monitoring

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

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

הצגת מדדים במעקב

בקטע הזה מוסבר איך לראות את המדדים ב-Monitoring.

המסוף

כדי לראות את המדדים של משאבים שבמעקב באמצעות Metrics Explorer:

  1. נכנסים לדף  Metrics explorer במסוף Google Cloud :

    עוברים אל Metrics Explorer

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

  2. בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח של מרכז האפליקציות או את פרויקט הניהול של התיקייה לניהול אפליקציות.
  3. ברכיב Metric, מרחיבים את התפריט Select a metric, כותבים VM instance בשורת הסינון ומשתמשים בתפריטי המשנה כדי לבחור סוג ספציפי של משאב ומדד:
    1. בתפריט Active resources בוחרים באפשרות VM instance.
    2. כדי לבחור מדד, משתמשים בתפריטים Active metric categories ו-Active metrics. רשימת המדדים הזמינים מופיעה במאמר מדדים זמינים לסנכרון זמן.
    3. לוחצים על אישור.

  4. כדי להוסיף מסננים שמסירים סדרות זמן מתוצאות השאילתה, משתמשים ברכיב Filter.

  5. מגדירים את אופן התצוגה של הנתונים. כברירת מחדל, התצוגה מסכמת את המדדים מכל המקרים ומכל כרטיסי ה-NIC הפיזיים. כדי להציג מדדים לפי כרטיס רשת (NIC) ולפי מופע, מבצעים את הפעולות הבאות: ברכיב Aggregation, בוחרים באפשרות Unaggregated.

    מידע נוסף על הגדרת תרשים זמין במאמר איך בוחרים מדדים כשמשתמשים ב-Metrics Explorer.

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

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

כשמגדירים איך כלי המעקב מעריך תנאי כשנתונים מפסיקים להגיע, מומלץ לבחור באפשרות Missing data points treated as values that violate the policy condition (נקודות נתונים חסרות נחשבות כערכים שלא עומדים בתנאי המדיניות). האפשרות הזו עוזרת לזהות אובדן נתונים שקט. עם זאת, ההגדרה הזו גורמת להתראות חיוביות כוזבות כשמוחקים מכונה.

המסוף

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

  1. נכנסים לדף  Alerting במסוף Google Cloud :

    עוברים אל התראות

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

  2. אם לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels (עריכת ערוצי התראות) ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף התראות.
  3. בדף Alerting, לוחצים על Create policy.
  4. כדי לבחור את המדד, מרחיבים את התפריט Select a metric ומבצעים את הפעולות הבאות:
    1. כדי להגביל את התפריט לרשומות רלוונטיות, מזינים VM Instance בסרגל הסינון. אם לא מוצאים תוצאות אחרי סינון התפריט, משביתים את המתג Show only active resources & metrics.
    2. בשדה Resource type, בוחרים באפשרות VM Instance.
    3. בקטע Metric category, בוחרים באפשרות Instance.
    4. בקטע Metric, בוחרים מדד מהרשימה Available metrics for time synchronization.
    5. לוחצים על אישור.
  5. לוחצים על הבא.
  6. ההגדרות בדף Configure alert trigger קובעות מתי ההתראה תופעל. בוחרים סוג תנאי, ואם צריך, מציינים סף. מידע נוסף זמין במאמר בנושא יצירת כללי מדיניות להתראות על סמך סף מדד.
  7. לוחצים על הבא.
  8. אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.
  9. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של ההתראה. השדה הזה קובע מתי מערכת Monitoring סוגרת התראות כשאין נתוני מדדים.
  10. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
  11. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
  12. לוחצים על יצירת מדיניות.
מידע נוסף זמין במאמר סקירה כללית על התראות.

יצירת לוחות בקרה מותאמים אישית של Monitoring

בקטע הזה מוסבר איך ליצור מרכזי בקרה בהתאמה אישית. דוגמה ספציפית לשימוש בשאילתת PromQL מופיעה במאמר דוגמה: יצירת לוח בקרה בהתאמה אישית שמשלב מדדי דיוק.

המסוף

  1. במסוף Google Cloud , עוברים לדף  Dashboards:

    עוברים אל מרכזי בקרה.

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

  2. לוחצים על יצירת מרכז בקרה.
  3. אופציונלי: מעדכנים את שם לוח הבקרה בשם תיאורי.

  4. לכל ווידג'ט שרוצים להוסיף ללוח הבקרה, לוחצים על הוספת ווידג'ט, משלימים את תיבת הדו-שיח ולוחצים על החלה.

    מידע נוסף על הוספת ווידג'טים זמין בדפים הבאים:

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

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

בקטע הזה יש דוגמה לשאילתת PromQL שאפשר להדביק בלוח בקרה מותאם אישית של Monitoring. מידע נוסף על PromQL זמין במאמר בנושא PromQL ל-Cloud Monitoring.

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

  • המדד שבודק את הדיוק של השעון של מערכת המופע ביחס לשעון של כרטיס ה-NIC הפיזי (phc-clock-max-error)

  • המדד שמודד את הדיוק של השעון הפיזי של כרטיס ה-NIC ביחס לשעון UTC ‏ (firefly_utc_traceable_uncertainty)

המסוף

  1. פועלים לפי השלבים כדי להיכנס לכלי לעריכת קוד עבור PromQL.

  2. מזינים את השאילתה הבאה בשדה הטקסט:

    (
  histogram_quantile(
   1,
   sum by (le, instance_id) (
     increase({"__name__"="logging.googleapis.com/user/phc-clock-max-error_bucket", monitored_resource="gce_instance"}[${__interval}])
   )
  ) * 1e9
)
+ on(instance_id)
max by (instance_id) (
 max_over_time({"__name__"="compute.googleapis.com/instance/time/firefly_utc_traceable_uncertainty", monitored_resource="gce_instance"}[${__interval}])
)

  3. לוחצים על Run Query (הפעלת שאילתה).

מידע נוסף על השימוש בכלי העריכה ועל שמירת התרשימים זמין במאמר שימוש בכלי לעריכת קוד ל-PromQL.

פתרון בעיות

יכול להיות שתקבלו פלט לא צפוי כשתאמתו את ההגדרה של chrony, כמו הפלט הבא שמציין שchrony לא הופעל:

506 Cannot talk to daemon

כדי לפתור את הבעיה, בודקים את היומנים של journald chrony:

journalctl -u chronyd.service

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

Feb 19 06:19:42 host-name systemd[1]: Starting chronyd.service - NTP client/server...
Feb 19 06:19:42 host-name chronyd[35160]: chronyd version 4.6.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
Feb 19 06:19:42 host-name chronyd[35160]: Setting filter length for PHC0 to 1
Feb 19 06:19:42 host-name chronyd[35160]: Could not open eth0 : No such file or directory
Feb 19 06:19:42 host-name chronyd[35160]: Fatal error : Could not open PHC
Feb 19 06:19:42 host-name chronyd[35157]: Could not open PHC
Feb 19 06:19:42 host-name systemd[1]: chronyd.service: Control process exited, code=exited, status=1/FAILURE
Feb 19 06:19:42 host-name systemd[1]: chronyd.service: Failed with result 'exit-code'.
Feb 19 06:19:42 host-name systemd[1]: Failed to start chronyd.service - NTP client/server.

בעיות מוכרות

יכול להיות שתיתקלו בבעיות הבאות כשמגדירים שעה מדויקת למופעי U4:

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