‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

בדף הזה נסביר איך להגדיר זמן מדויק במכונת Compute Engine מסוג U4 ואיך להגדיר מעקב כדי שתוכלו לראות את רמת הדיוק של סנכרון הזמן.

איך זה עובד

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

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

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

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

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

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

יצירת מופע U4

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

כדי ליצור מכונת U4P או U4C, אפשר לעיין במאמר בנושא יצירת מכונות Compute Engine עם זמן אחזור נמוך במיוחד.
כדי ליצור מכונת U4S, אפשר לעיין במאמר בנושא יצירת מכונות Compute Engine שאינן ULL לעומסי עבודה משניים.

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

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

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

journalctl -u chronyd

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

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

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

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

מריצים את פקודת העריכה:
```
systemctl edit chronyd
```

מוסיפים את ההחלפה שמתאימה לסוג המופע:

במקרים של מופעי 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

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

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

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

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

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

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

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

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

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

מוסיפים את הטקסט הבא לקובץ התצורה 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 בשמות המתאימים שקיבלתם קודם. במקרה הצורך, אפשר לעיין במאמר איך מקבלים את השמות של ממשקי הרשת.

כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את 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, צריך לבצע את הפעולות הבאות:

קבלת מספר האינדקס של מכשיר 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
```

הפלט 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

כדי להחיל את ההגדרה, מריצים את הפקודה הבאה כדי להפעיל מחדש את chrony:
```
systemctl restart chronyd
```
‫chrony מתעד ביומן נתונים סטטיסטיים של סנכרון השעון אל /var/log/chrony/tracking.log באמצעות שעון החומרה PTP של enp22s0f0 כמקור הזמן.

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

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

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

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

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

# 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. במקרה הצורך, אפשר לעיין במאמר בנושא קבלת שמות של ממשקי רשת.

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

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

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

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

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

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

מדידה המדד הזמין והתיאור שלו

שעון המערכת של המופע לשעון של כרטיס ה-NIC הפיזי

מדידה	המדד הזמין והתיאור שלו
שעון המערכת של המופע לשעון של כרטיס ה-NIC הפיזי	`logging.googleapis.com/user/phc-clock-max-error` המדד הזה בודק את הדיוק של הסנכרון בין שעון המערכת של המופע לבין השעון של כרטיס ה-NIC הפיזי בשרת המארח שלו. כדי להגדיר את המדד הזה, צריך לאסוף אותו מ-Ops Agent וליצור מדד מבוסס-יומן כמו שמתואר במאמר הגדרת מדד מותאם אישית לשעון המערכת של המופע, שבו מוסבר גם איך ליצור לוח בקרה מותאם אישית. בנוסף, אפשר להשתמש במדד הזה בתהליכים שמתוארים במאמר שימוש במדדים של Cloud Monitoring.
שעון NIC פיזי ל-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` המדד הבוליאני הזה מציין את סטטוס התקינות הכללי של השעון הפיזי של כרטיס ה-NIC, כולל סנכרון בין כרטיסי NIC וסנכרון בין כרטיס NIC ל-UTC. הוא מדווח אוטומטית ל-Cloud Monitoring. אפשר לראות את המדד הזה, להגדיר מדיניות התראות וליצור לוחות בקרה בהתאמה אישית כמו שמתואר במאמר שימוש במדדים של Cloud Monitoring.

logging.googleapis.com/user/phc-clock-max-error

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

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

שעון NIC פיזי ל-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

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

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

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

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

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

הגדרת Google Cloud Ops Agent במופע

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

אם עדיין לא עשיתם זאת, מתקינים את Ops Agent במופע.

מוסיפים את ההגדרה הבאה לקובץ /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]

מפעילים מחדש את Ops Agent באמצעות הפקודה הבאה:
```
systemctl restart google-cloud-ops-agent
```

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

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

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

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

#!/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": "Chrony Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "height": 28,
        "width": 28,
        "widget": {
          "xyChart": {
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n    histogram_quantile(\n        1,\n        sum by (le, instance_id, monitored_resource) (\n            increase(\n                logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"gce_instance\"}[1m]\n            )\n        )\n    ) * 1000000000\n)",
                  "unitOverride": "ns"
                }
              }
            ],
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "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. בקטעים הבאים מפורטים כל המדדים שזמינים לסנכרון זמן.

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

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

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

המסוף

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

נכנסים לדף Metrics explorer במסוף Google Cloud :
כניסה אל Metrics Explorer

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

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

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

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

המסוף

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

נכנסים לדף Alerting במסוף Google Cloud :
כניסה אל התראות

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

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

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

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

המסוף

במסוף Google Cloud , עוברים לדף Dashboards:
מעבר אל מרכזי בקרה

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

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

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

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

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

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

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

המסוף

כדי לגשת לכלי לעריכת קוד עבור PromQL, פועלים לפי השלבים.

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

histogram_quantile(
 1,
 sum by (le, instance_id) (
   increase({"__name__"="logging.googleapis.com/user/phc-clock-max-error_bucket", monitored_resource="gce_instance"}[${__interval}])
 )
)
+ 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}])
)

לוחצים על 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.

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

איך זה עובד

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

יצירת מופע U4

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

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

קבלת שמות של ממשקי רשת

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

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

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

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

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

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

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

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

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

הגדרת Google Cloud Ops Agent במופע

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

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

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

המסוף

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

המסוף

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

המסוף

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

המסוף

פתרון בעיות

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

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

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

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

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

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

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