במסמך הזה מוסבר איך להשתמש ב-Cloud Monitoring API כדי ליצור, לערוך, למחוק, להציג ולקבל מדיניות התראות מבוססת-מדדים באופן פרוגרמטי. בדוגמאות מוסבר איך להשתמש ב-Google Cloud CLI ובספריות לקוח. התוכן הזה לא רלוונטי למדיניות התראות שמבוססת על יומנים. מידע על מדיניות התראות שמבוססת על יומנים זמין במאמר מעקב אחרי היומנים.
אפשר לבצע את המשימות האלה גם באמצעות המסוף Google Cloud . מידע נוסף זמין במסמכים הבאים:
- יצירת מדיניות התראות מבוססת-מדדים באמצעות מסוף Google Cloud
- ניהול מדיניות ההתראות באמצעות מסוף Google Cloud
התכונה הזו נתמכת רק בפרויקטים של Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
מידע על כללי מדיניות התראות
מדיניות התראות מיוצגת על ידי אובייקט AlertPolicy, שמתאר קבוצה של תנאים שמצביעים על סטטוס לא תקין פוטנציאלי במערכת. כללי מדיניות התראות מתייחסים לערוצי התראות, שמאפשרים לכם לציין איך אתם רוצים לקבל מידע על הפעלה של כללי מדיניות התראות.
כל מדיניות התראה שייכת לפרויקט היקף של היקף מדדים. כל פרויקט יכול להכיל עד 2,000 כללי מדיניות.
כשמבצעים קריאות ל-API, צריך לספק 'מזהה פרויקט'. הערך שצריך להזין הוא המזהה של פרויקט ההיקף של היקף המדדים. בדוגמאות האלה, המזהה של פרויקט ההיקף של היקף המדדים הוא a-gcp-project.
משאב AlertPolicy תומך בחמש פעולות:
- יצירת מדיניות חדשה
- מחיקה של כללי מדיניות קיימים
- אחזור מדיניות ספציפית
- אחזור של כל כללי המדיניות
- שינוי מדיניות קיימת
אפשר להגדיר מדיניות התראות בפורמט JSON או YAML, כך שאפשר לתעד את המדיניות בקבצים ולהשתמש בקבצים כדי לגבות ולשחזר את המדיניות. באמצעות Google Cloud CLI, אפשר ליצור כללי מדיניות מקבצים בכל אחד מהפורמטים. באמצעות API בארכיטקטורת REST, אפשר ליצור מדיניות מקובצי JSON. בקטע מדיניות לדוגמה תוכלו לראות מבחר של מדיניות התראות בפורמט JSON.
בדוגמאות הבאות נעשה שימוש בממשק gcloud וב-API כדי להמחיש את תרחישי השימוש הבסיסיים האלה. דוגמאות ה-API הן קטעים מתוכנית לדוגמה שמשתמשת ב-API כדי להטמיע מערכת לגיבוי ולשחזור של מדיניות התראות. דוגמאות מלאות יותר מופיעות במאמר דוגמה: גיבוי ושחזור.
לפני שמתחילים
לפני שכותבים קוד שמשתמש ב-API, צריך:
- חשוב להכיר את המושגים הכלליים ואת המינוח שמשמשים במדיניות בנושא התראות. מידע נוסף זמין במאמר סקירה כללית על התראות.
- מוודאים ש-Cloud Monitoring API מופעל. מידע נוסף זמין במאמר בנושא הפעלת ה-API.
- אם אתם מתכננים להשתמש בספריות לקוח, אתם צריכים להתקין את הספריות בשפות שבהן אתם רוצים להשתמש. פרטים נוספים זמינים במאמר ספריות לקוח. תמיכה ב-API להגדרת התראות זמינה רק בשפות C#, Go, Java, Node.js ו-Python.
אם אתם מתכננים להשתמש ב-Google Cloud CLI, אתם צריכים להתקין אותו. עם זאת, אם אתם משתמשים ב-Cloud Shell, Google Cloud CLI כבר מותקן.
בנוסף, מופיעות כאן דוגמאות לשימוש בממשק
gcloud. שימו לב: בכל הדוגמאות שלgcloudמניחים שהפרויקט הנוכחי כבר הוגדר כיעד (gcloud config set project [PROJECT_ID]), ולכן ההפעלות לא כוללות את הדגל--projectהמפורש. המזהה של הפרויקט הנוכחי בדוגמאות הואa-gcp-project. בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
-
כדי לקבל את ההרשאות שנדרשות ליצירה ולשינוי של מדיניות התראות באמצעות Cloud Monitoring API, צריך לבקש מהאדמין להקצות לכם את התפקיד Monitoring AlertPolicy Editor (
roles/monitoring.alertPolicyEditor) ב-IAM בפרויקט. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
מידע מפורט על תפקידי IAM ב-Monitoring זמין במאמר בקרת גישה באמצעות ניהול זהויות והרשאות גישה (IAM).
תכננו את האפליקציה כך שקריאות ל-Cloud Monitoring API שמשנות את הסטטוס של מדיניות התראות בGoogle Cloud פרויקט יתבצעו בשרשור יחיד. לדוגמה, קריאות API של thread יחיד שיוצרות, מעדכנות או מוחקות מדיניות התראות.
יצירת מדיניות התראות
כדי ליצור מדיניות התראות בפרויקט, משתמשים ב-method alertPolicies.create. מידע על הפעלת השיטה הזו, על הפרמטרים שלה ועל נתוני התגובה מופיע בדף העזר alertPolicies.create.
אפשר ליצור מדיניות מקובצי JSON או YAML.
Google Cloud CLI מקבל את הקבצים האלה כארגומנטים, ואפשר לקרוא קובצי JSON באופן פרוגרמטי, להמיר אותם לאובייקטים של AlertPolicy וליצור מהם כללי מדיניות באמצעות השיטה alertPolicies.create. אם יש לכם קובץ תצורה של Prometheus בפורמט JSON או YAML עם כלל התראות, ה-CLI של gcloud יכול להעביר אותו למדיניות התראות של Cloud Monitoring עם תנאי PromQL. מידע נוסף זמין במאמר בנושא העברה של כללי התראות ושל נמענים מ-Prometheus.
בדוגמאות הבאות מוצג תהליך היצירה של מדיניות התראות, אבל לא מוסבר בהן איך ליצור קובץ JSON או YAML שמתאר מדיניות התראות. במקום זאת, הדוגמאות מניחות שקיים קובץ בפורמט JSON, וממחישות איך לשלוח את קריאת ה-API. דוגמאות לקובצי JSON מופיעות במאמר מדיניות לדוגמה. מידע כללי על מעקב אחרי יחסי מדדים זמין במאמר יחסי מדדים.
gcloud
כדי ליצור מדיניות התראות בפרויקט, משתמשים בפקודה gcloud monitoring
policies create. בדוגמה הבאה נוצרת מדיניות התראות ב-a-gcp-project מהקובץ rising-cpu-usage.json:
gcloud monitoring policies create --policy-from-file="rising-cpu-usage.json"
אם הפקודה מסתיימת ללא שגיאות, היא מחזירה את השם של המדיניות החדשה, לדוגמה:
Created alert policy [projects/a-gcp-project/alertPolicies/12669073143329903307].
הקובץ rising-cpu-usage.json מכיל את ה-JSON של מדיניות עם שם התצוגה 'שיעור שינוי גבוה של CPU'. פרטים על המדיניות הזו מופיעים במאמר מדיניות שיעור השינוי.
מידע נוסף מופיע במפרט של השיטה ב-gcloud monitoring policies create.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
לאובייקט AlertPolicy שנוצר יהיו שדות נוספים.
למדיניות עצמה יהיו השדות name, creationRecord ו-mutationRecord. בנוסף, לכל תנאי במדיניות מוקצה גם name.
אי אפשר לשנות את השדות האלה מבחוץ, ולכן אין צורך להגדיר אותם כשיוצרים מדיניות. אף אחת מדוגמאות ה-JSON שמשמשות ליצירת מדיניות לא כוללת אותם, אבל אם מאחזרים מדיניות שנוצרה מהן אחרי היצירה, השדות יופיעו.
הצגה של רשימת כללי מדיניות התראות וקבלת פרטים על כללי מדיניות התראות
כדי לאחזר רשימה של המדיניות בפרויקט, משתמשים בשיטה alertPolicies.list.
אפשר להשתמש בשיטה הזו כדי לאחזר מדיניות ולבצע פעולה מסוימת על כל אחת מהן, למשל גיבוי. בשיטה הזו יש גם תמיכה באפשרויות filter ו-orderBy להגבלת התוצאות ולמיון שלהן. מידע נוסף זמין במאמר בנושא מיון וסינון.
אם אתם מחפשים מדיניות ספציפית ואתם יודעים את השם שלה, אתם יכולים להשתמש בשיטה alertPolicies.get כדי לאחזר רק את המדיניות הזו. שם המדיניות הוא הערך של השדה name ולא של displayName באובייקט AlertPolicy. הפורמט של שם המדיניות הוא projects/[PROJECT_ID]/alertPolicies/[POLICY_ID], לדוגמה:
projects/a-gcp-project/alertPolicies/12669073143329903307
gcloud
כדי להציג את כללי מדיניות ההתראות בפרויקט, משתמשים בפקודה gcloud monitoring
policies list:
gcloud monitoring policies list
אם הפעולה בוצעה ללא שגיאות, הפקודה list תחזיר רשימה של כל כללי המדיניות בפרויקט שצוין, בפורמט YAML. לדוגמה, המדיניות עם השם המוצג High CPU rate of change בפרויקט a-gcp-project מופיעה כך, בין שאר המדיניות שמופיעה ברשימה:
---
combiner: OR
conditions:
- conditionThreshold:
aggregations:
- alignmentPeriod: 900s
perSeriesAligner: ALIGN_PERCENT_CHANGE
comparison: COMPARISON_GT
duration: 180s
filter: metric.type="compute.googleapis.com/instance/cpu/utilization" AND resource.type="gce_instance"
thresholdValue: 0.5
trigger:
count: 1
displayName: CPU usage is increasing at a high rate
name: projects/a-gcp-project/alertPolicies/12669073143329903307/conditions/12669073143329903008
creationRecord:
mutateTime: '2018-03-26T18:52:39.363601689Z'
mutatedBy: [USER@DOMAIN]
displayName: High CPU rate of change
enabled: true
mutationRecord:
mutateTime: '2018-03-26T18:52:39.363601689Z'
mutatedBy: [USER@DOMAIN]
name: projects/a-gcp-project/alertPolicies/12669073143329903307
---
כדי להציג רשימה של מדיניות התראה אחת, משתמשים במקום זאת בפקודה gcloud monitoring policies
describe ומציינים את שם המדיניות. לדוגמה, הפקודה הזו תחזיר רק את הרשימה שלמעלה:
gcloud monitoring policies describe projects/a-gcp-project/alertPolicies/12669073143329903307
מידע נוסף זמין במאמרים בנושא gcloud monitoring policies list וdescribe. הפקודה describe תואמת לשיטה alertPolicies.get ב-API.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
מחיקת מדיניות התראות
כדי למחוק מדיניות מפרויקט, משתמשים בשיטה alertPolicies.delete ומזינים את השם של מדיניות ההתראות שרוצים למחוק.
gcloud
כדי למחוק מדיניות התראות, משתמשים ב-gcloud monitoring policies
delete ומציינים את שם המדיניות שרוצים למחוק. לדוגמה, הפקודה הבאה מוחקת את המדיניות עם השם המוצג 'שיעור שינוי גבוה של CPU':
gcloud monitoring policies delete projects/a-gcp-project/alertPolicies/12669073143329903307
מידע נוסף מופיע במפרט של השיטה ב-gcloud monitoring policies delete.
שינוי מדיניות התראות
כדי לשנות מדיניות התראות, משתמשים ב-method alertPolicies.patch (ב-API בארכיטקטורת REST).
הטמעה אחרת של API וקריאה לממשק gcloud במקום update
במקום patch.
פעולת עדכון יכולה להחליף לחלוטין את המדיניות הקיימת, או לשנות קבוצת משנה של שדות. פעולת עדכון מקבלת אובייקט AlertPolicy חדש וfield mask אופציונלי.
אם מציינים מסכת שדות, כל שדה שמופיע במסכת השדות מתעדכן עם הערך במדיניות שסופקה. אם המדיניות שסופקה לא כוללת שדה שמוזכר במסכת השדות, השדה הזה ינוקה ויוגדר לערך ברירת המחדל שלו. כל שדה שלא מופיע במסכה שומר על הערך הקודם שלו.
אם לא מציינים מסיכת שדות, המדיניות הקיימת מוחלפת במדיניות שסופקה, אבל השם (projects/[PROJECT_ID]/alertPolicies/[POLICY_ID]) משמש שוב. כל התנאים במדיניות החדשה שיש להם ערכים של name שכוללים CONDITION_ID ישמרו את השמות האלה. אם לא, נוצרים שמות חדשים של תנאים ומדיניות.
כשמשתמשים בשורת הפקודה gcloud כדי לעדכן מדיניות, משתמשים בדגלים של שורת הפקודה ולא במסכת שדות כדי לציין את השדות לעדכון.
פרטים נוספים מופיעים בgcloud monitoring policies update.
אפשר להשתמש בתוויות כדי לשייך מדיניות התראות לאפליקציה ב-App Hub. מידע נוסף זמין במאמר בנושא איך משייכים מדיניות התראות לאפליקציה ב-App Hub.
הפעלה או השבתה של מדיניות התראות
כדי להפעיל או להשבית מדיניות, משנים את הערך של השדה הבוליאני enabled באובייקט AlertPolicy. חשוב לדעת שאחרי שמפעילים מדיניות, עדיין יכול להיות שהיא תופעל על סמך נתונים שנאספו בזמן שהיא הייתה מושבתת.
gcloud
כדי להשבית מדיניות התראות, משתמשים בפקודה gcloud monitoring policies update ומספקים את הדגל --no-enabled. הפקודה הבאה משביתה את מדיניות ההתראות 'שיעור שינוי גבוה של CPU' בפרויקט a-gcp-project:
gcloud monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 --no-enabled
כדי להפעיל את המדיניות, משתמשים באותה פקודה ומספקים את הדגל --enabled.
מידע נוסף זמין במפרט של השיטה ב-gcloud monitoring policies update. הפקודה update תואמת ל-method alertPolicies.patch ב-API בארכיטקטורת REST.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
עדכון ערוצי ההתראות במדיניות התראות
אפשר גם לעדכן את ערוצי ההתראות שאליהם מתייחסת מדיניות ההתראות. כללי מדיניות התראות מתייחסים לערוצי התראות לפי שם. הערוצים צריכים להתקיים לפני שאפשר להשתמש בהם במדיניות התראות.
אתם יכולים ליצור ולנהל ערוצי התראות באופן פרוגרמטי באמצעות המשאבים NotificationChannel ו-NotificationChannelDescriptors.
בדוגמאות שבקטע הזה מניחים שהערוצים האלה כבר קיימים, וגם בדוגמאות הפרוגרמטיות מופיעים שימושים בממשקי ה-API האלה.
למידע נוסף על אובייקטים של ערוצי התראות, אפשר לעיין במאמר בנושא יצירה וניהול של ערוצי התראות באמצעות API.
gcloud
כדי לשנות את ערוצי ההתראות במדיניות התראות, משתמשים בפקודה gcloud monitoring policies update. יש כמה דגלים שקשורים לערוצי התראות, שמאפשרים לכם להסיר ערוצי התראות, להחליף ערוצי התראות ולהוסיף ערוצי התראות חדשים.
לדוגמה, המדיניות עם השם המוצג “High CPU rate of change” בפרויקט a-gcp-project נוצרה ללא ערוצי התראה.
כדי להוסיף ערוץ התראות למדיניות הזו, משתמשים בפקודה gcloud monitoring
policies update ומציינים את הערוץ שרוצים להוסיף באמצעות הדגל --add-notification-channels:
gcloud monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 \
--add-notification-channels="projects/a-gcp-project/notificationChannels/1355376463305411567"
מידע נוסף זמין במפרט של השיטה ב-gcloud monitoring policies update. הפקודה update תואמת ל-method alertPolicies.patch ב-API בארכיטקטורת REST.
ערוץ ההתראות שמוסיפים כאן צריך כבר להתקיים. מידע נוסף זמין במאמר בנושא יצירת ערוץ התראות.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
שינוי התיעוד במדיניות התראות
מדיניות יכולה לכלול תיעוד שמופיע עם אירועים והתראות שקשורים למדיניות. בשדה הזה אפשר לכלול מידע שיעזור למשיבים להבין את הבעיה שמצוינת במדיניות ההתראות ולטפל בה. התיעוד נכלל בהתראות באימייל ובסוגי התראות שמאפשרים זאת. יכול להיות שהוא לא ייכלל בסוגים אחרים של ערוצים.
gcloud
כדי להוסיף מאמרי עזרה למדיניות או להחליף מאמרי עזרה קיימים, משתמשים בפקודהgcloud monitoring policies update ומספקים את הדגל --documentation-format="text/markdown" (הפורמט הנתמך היחיד) ואת הדגל --documentation (כדי להזין את הערך משורת הפקודה) או את הדגל --documentation-from-file (כדי לקרוא את הערך מקובץ).
לדוגמה, המדיניות עם השם המוצג “High CPU rate of change” בפרויקט a-gcp-project נוצרה ללא תיעוד.
הפקודה הבאה מגדירה את השדה documentation במדיניות שצוינה לתוכן של הקובץ cpu-usage-doc.md:
gcloud monitoring policies update projects/a-gcp-project/alertPolicies/12669073143329903307 \
--documentation-format="text/markdown" \
--documentation-from-file="cpu-usage-doc.md"
מידע נוסף זמין במפרט של השיטה ב-gcloud monitoring policies update. הפקודה update תואמת ל-method alertPolicies.patch ב-API בארכיטקטורת REST.
הוספת מדיניות התראות למרכז בקרה
כדי להציג סיכום של מדיניות התראות עם תנאי יחיד בלוח בקרה מותאם אישית, מוסיפים ללוח הבקרה ווידג'ט AlertChart.
משתמשים בשיטה dashboards.create כדי ליצור מרכז בקרה חדש ובשיטה dashboards.patch כדי לערוך מרכז בקרה קיים.
אם מציינים מדיניות התראות עם כמה תנאים, בווידג'ט AlertChart לא יוצגו נתונים.
מידע מפורט על השימוש בשיטות ה-API האלה זמין במאמר יצירה וניהול של לוחות בקרה באמצעות API.
דוגמה: גיבוי ושחזור
כל הדוגמאות ל-API שמוצגות כאן נלקחו מאפליקציה גדולה יותר שיכולה לגבות את מדיניות ההתראות בפרויקט לקובץ, ולשחזר את המדיניות, אולי לפרויקט אחר. אם הפרויקטים שמשמשים לגיבוי ולשחזור הם שונים, האפליקציה מייצאת ומייבאת מדיניות מפרויקט אחד לפרויקט אחר.
בקטע הזה מוצג הקוד לגיבוי ולשחזור בהקשר, ולא כקבוצה של קטעים קצרים ומבודדים.
גיבוי של מדיניות
פעולת הגיבוי היא פשוטה. קבוצת מדיניות ההתראות וקבוצת ערוצי ההתראות בכל פרויקט נאספות ונשמרות באחסון חיצוני בפורמט JSON.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
שחזור כללי המדיניות שגובו
תהליך השחזור מורכב יותר מתהליך הגיבוי המקורי. אפשר לשחזר את הפרויקט שגיביתם במקור. אפשר גם לשחזר לפרויקט אחר, וכך לייבא מדיניות התראות.
אם משחזרים לאותו פרויקט, כל הערוצים או כללי המדיניות הקיימים מתעדכנים אם הם עדיין קיימים. אם לא, הן נוצרות מחדש. השדות לקריאה בלבד, כמו רשומות היצירה והשינוי, במדיניות שגובתה, מנוקים בתהליך השחזור לפני שנוצרות מחדש מדיניות והתראות.
אפשר להשתמש במדיניות שנשמרה בפרויקט אחד כדי ליצור מדיניות חדשה או דומה בפרויקט אחר. עם זאת, קודם צריך לבצע את השינויים הבאים בעותק של המדיניות השמורה:
- מסירים את השדות הבאים מכל ערוצי ההתראות:
nameverificationStatus
- צריך ליצור ערוצי התראות לפני שמתייחסים לערוצים במדיניות בנושא התראות (נדרשים מזהי הערוצים החדשים).
- מסירים את השדות הבאים מכל מדיניות התראות שיוצרים מחדש:
namecondition.namecreationRecordmutationRecord
אם המדיניות נוצרת מחדש בפרויקט חדש, השמות של כל התנאים במדיניות שגובתה נמחקים יחד עם רשומות היצירה והשינוי.
בנוסף, כשיוצרים מחדש ערוץ התראות בפרויקט אחר, הוא מקבל שם אחר. לכן, בתהליך השחזור צריך למפות את השמות של הערוצים במדיניות ההתראות שגובתה לשמות החדשים שלהם, ולהחליף את השמות הישנים בשמות החדשים.
בנוסף לשמות של ערוצי התראות, אי אפשר להגדיר את הערך של השדה verificationStatus כשיוצרים או מעדכנים את הערוץ, ולכן נעשה שימוש בערך sentinel, unspecified. אחרי שמשחזרים ערוצים לפרויקט חדש, צריך לאמת אותם באופן מפורש.
C#
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Go
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Java
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Node.js
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
PHP
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
Python
כדי לבצע אימות ב-Monitoring, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.
התראות ו-Google Cloud CLI
ב-Google Cloud CLI, קבוצת הפקודות לניהול מדיניות התראות וערוצי התראות היא monitoring.
כל הפקודות האלה יתחילו ב:
gcloud monitoring
כדי לבדוק אם Google Cloud CLI מותקן, מריצים את הפקודה הבאה:
gcloud --version
אם Google Cloud CLI לא מותקן, אפשר לעיין במאמר התקנת Google Cloud CLI.
כדי לבדוק אם קיימת קבוצת monitoring, מריצים את הפקודה הבאה:
gcloud monitoring --help
אם הקבוצה monitoring לא מופיעה, תופיע ב-Google Cloud CLI בקשה להוסיף אותה:
You do not currently have this command group installed.
[...]
Do you want to continue (Y/n)? y