במאמר הזה מוסבר איך להגדיר בדיקה תקופתית של הקישורים שכלולים ב-URI באמצעות יצירת כלי מעקב סינתטי. מציינים את האפשרויות לבדיקה, כמו URI המקור, מספר הקישורים שנבדקו ומספר הניסיונות החוזרים, ואז פורסים פונקציית Cloud Run שהוגדרה מראש. כדי לעזור לכם לפתור בעיות ולבצע ניפוי באגים, כלי המעקב הסינתטי שומר מידע מפורט על כל בדיקה, כולל צילומי מסך. צילומי המסך מאפשרים לכם לראות את התגובה המדויקת שהלקוחות של האפליקציה שלכם רואים.
מידע נוסף על בדיקות סינתטיות זמין במאמר מידע על בדיקות סינתטיות.
התכונה הזו נתמכת רק בפרויקטים של Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
מידע על כלים לבדיקת קישורים מנותקים
כל כלי לבדיקת קישורים שבורים בודק את הקישורים ברצף, ויש פסק זמן סינתטי כללי שניתן להגדרה.
כברירת מחדל, בודק הקישורים השבורים מבצע את הפעולות הבאות:
- התג הזה מחפש ב-URI של המקור רכיבי עוגן HTML עם מאפייני
href. - בודק את 10 הקישורים הראשונים שנמצאו במזהה ה-URI של המקור.
- לכל קישור, הכלי לבדיקת קישורים שולח בקשה ואז מחכה עד 30 שניות לתשובה. כשמתקבלת תגובה, הכלי לבדיקה מוודא שסטטוס תגובת HTTP הוא
200, שמציין שהתגובה התקבלה בהצלחה. הכלי לבדיקת תאימות לא מנסה שוב.
מציינים את ה-URI של המקור. אתם יכולים להגדיר אילו רכיבי HTML יחפש הכלי לבדיקת קישורים שבורים, מה המספר המקסימלי של רכיבים שייבדקו, מה הזמן הקצוב לתפוגה לכל בדיקה והאם יתבצעו ניסיונות חוזרים. אפשר גם להגדיר בודקי קישורים שבורים להמתין עד שיופיע בורר.
בודקי קישורים שבורים משתמשים בתבנית broken-links-ok. ההגדרה של הכלי לבדיקת קישורים שבורים מצוינת באובייקט options של הקובץ index.js. אם יוצרים את הכלי לבדיקה באמצעות מסוףGoogle Cloud , מוצגת בקשה לכל אפשרות הגדרה והפונקציה של Cloud Run מתעדכנת בשבילכם. אבל אם משתמשים ב-Cloud Monitoring API או ב-Terraform, צריך לאכלס את האובייקט הזה.
אחרי שיוצרים כלי לבדיקת קישורים שבורים, כדי לשנות את ההגדרות, מעדכנים את האובייקט options ופורסים מחדש את פונקציית Cloud Run.
לפני שמתחילים
מגדירים את הפרויקט ואת תפקידי ה-IAM, ובוחרים את הממשק שמתכננים להשתמש בו.
הגדרת הפרויקט והתפקידים
-
כדי לקבל את ההרשאות שדרושות להצגה ולשינוי של בדיקות סינתטיות באמצעות Google Cloud המסוף, צריך לבקש מהאדמין להקצות לכם בפרויקט את תפקידי ה-IAM הבאים:
- עריכה של מעקב (
roles/monitoring.editor) - Cloud Functions Developer (
roles/cloudfunctions.developer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
- עריכה של מעקב (
-
מפעילים את Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API ו-Cloud Run Admin API.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, נדרשת ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים מוודאים ש Google Cloud הפרויקט מכיל את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. חשבון השירות הזה נוצר כשמפעילים את Compute Engine API, והשם שלו דומה ל-
12345-compute@developer.gserviceaccount.com.נכנסים לדף Service Accounts במסוף Google Cloud .
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
אם חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לא קיים, לוחצים על יצירת חשבון שירות וממלאים את תיבת הדו-שיח.
מוודאים שחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או חשבון השירות שיצרתם קיבל את התפקיד 'עריכה' (
roles/editor).כדי לראות את התפקידים שניתנו לחשבון השירות:
-
נכנסים לדף IAM במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
- בוחרים באפשרות Include Google-provided role grants.
- אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד Cloud Trace Agent (
roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.
-
- מגדירים את ערוצי ההתראות שבהם רוצים להשתמש כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף זמין במאמרים בנושא יצירה וניהול של ערוצי התראות ויצירה וניהול של ערוצי התראות באמצעות API.
בחירת הממשק שבו רוצים להשתמש
המסוף
כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud
Terraform
כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Terraform שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.
-
התקינו את ה-CLI של Google Cloud.
-
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
-
אם אתם משתמשים במעטפת מקומית, אתם צריכים ליצור פרטי כניסה לאימות מקומי עבור חשבון המשתמש:
gcloud auth application-default login
אם אתם משתמשים ב-Cloud Shell, אין צורך לבצע את הפעולה הזו.
אם מוחזרת שגיאת אימות ואתם משתמשים בספק זהויות חיצוני (IdP), ודאו ש נכנסתם ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
למידע נוסף, ראו הגדרת ADC לסביבת פיתוח מקומית במאמרי העזרה בנושא אימות Google Cloud .
REST
כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.
התקינו את ה-CLI של Google Cloud.
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .
יצירת כלי לבדיקת קישורים שבורים
המסוף
כשיוצרים בדיקה סינתטית באמצעות Google Cloud המסוף, נפרסת פונקציית Cloud Run חדשה (דור שני) ונוצרת הבדיקה עבור פונקציית Cloud Run הזו. אי אפשר ליצור בדיקה סינתטית שעוקבת אחרי פונקציית Cloud Run קיימת.
מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, ושהחשבון הזה קיבל את התפקיד 'עריכה' (
roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.-
במסוף Google Cloud , עוברים לדף
Synthetic monitoring:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
- בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
- בוחרים באפשרות יצירת בדיקה סינתטית.
- בוחרים בתבנית Broken link checker (בדיקת קישורים מנותקים).
- מזינים שם לניטור הסינתטי.
אופציונלי: מעדכנים את זמן קצוב לתפוגה של התגובה ואת תדירות הבדיקה, ומוסיפים תוויות שהוגדרו על ידי המשתמש.
מגדירים את ה-URI ואת הרכיבים לבדיקה:
לוחצים על Origin URI ומזינים URI שרוצים לבדוק. הערך שאתם מזינים חייב להיות נקודת קצה מסוג HTTP או HTTPS. לדוגמה, אפשר להזין
https://mywebsite.example.com.אופציונלי: בשדה מספר הקישורים למעקב, מעדכנים את המספר המקסימלי של הקישורים שנבדקים. ערך ברירת המחדל של השדה הזה הוא 10.
אופציונלי: בשדה HTML element selector (סלקטור של רכיב HTML), מזינים את רכיב ה-HTML שרוצים להתאים, כרשימה מופרדת בפסיקים. הערך שאתם מזינים מומר למחרוזת ואז מועבר לשיטה
Document: querySelectorAll().כברירת מחדל, השדה הזה מוגדר ל-
a, שמתאים לעוגנים. אפשר להזין ערכים כמוa, img, אם רוצים להתאים גם עוגנים וגם תמונות.אופציונלי: בשדה HTML attributes to follow (מאפייני HTML להוספה), מזינים את מאפייני ה-HTML שרוצים להתאים. הערכים המופרדים בפסיקים שאתם מזינים מועברים בנפרד לשיטה
getAttribute().כברירת מחדל, השדה הזה מוגדר ל-
href, שמציין את ה-URI של הקישור. אפשר להזין כמה מאפיינים. לדוגמה, אפשר להזיןhref, src. בדוגמה הזו, הקוד מחפש את המאפייןhrefואז מחפש את המאפייןsrc.אופציונלי: הגדרת המתנה לסלקטור, זמן קצוב לתפוגה לכל URI, ניסיונות חוזרים וקודי סטטוס צפויים:
- לוחצים על הצגת הגדרות נוספות.
כדי להגדיר את הכלי לבדיקת קישורים שבורים כך שימתין להופעה של סלקטור ספציפי ב-URI לפני שיתבצע גירוד של קישורים, מזינים את הסלקטורים ב-CSS בשדה Wait for element selector (המתנה לסלקטור של רכיב). הערך שאתם מזינים מומר למחרוזת ואז מועבר לשיטה
page.waitForSelector().אם הבורר לא מופיע לפני שפג הזמן הקצוב לתפוגה, הכשל מתועד ביומנים.
עדכון הסדר שבו הקישורים נבחרים לבדיקה.
הגדרת ניסיונות חוזרים.
כברירת מחדל, נשלחת בקשה אחת לכל קישור, ואם הבקשה הראשונית נכשלת מסיבה כלשהי, למשל אם פג הזמן הקצוב לתפוגה של הפקודה או אם קוד הסטטוס של HTTP הוא לא
200, הקישור מסומן כנכשל.בשדה הזה מציינים את מספר הפעמים שבודק הקישורים השבורים יכול לשלוח בקשת HTTP לקישור לפני שהוא מסמן את הקישור כנכשל.
מגדירים זמן קצוב לתפוגה שחל על כל מזהה URI. כברירת מחדל, הערך הזה מוגדר ל-30 שניות.
כדי לציין את קוד הסטטוס וזמן הקצוב לתפוגה הצפויים עבור URI ספציפי, לוחצים על Add per-link option (הוספת אפשרות לכל קישור) ומשלימים את תיבת הדו-שיח.
אופציונלי: מגדירים אם צילומי מסך של תשובות ייאספו ויישמרו. אם משתמשים בהגדרות ברירת המחדל, צילומי המסך לא נשמרים. אם מפעילים את איסוף צילומי המסך, אפשר לאסוף צילומי מסך לכל הבדיקות או רק לבדיקות שנכשלו. ב-Cloud Monitoring משתמשים במוסכמה הבאה כדי לתת שם לקטגוריה של Cloud Storage:
gcm-PROJECT_ID-synthetics-LOCATIONבביטוי הקודם:
- PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- LOCATION: המיקום של הקטגוריה שלכם ב-Cloud Storage.
יש לכם אפשרות להשתמש בקטגוריה קיימת של Cloud Storage.
בודקים את ההגדרה ומוודאים שהיא נכונה ומלאה, ואז יוצרים את פונקציית Cloud Run:
לוחצים על Create Function (יצירת פונקציה).
הערכים בשדות הגדרת ה-URI מועתקים לאובייקט
Optionsבקובץindex.jsכשלוחצים על יצירת פונקציה. אחרי שלוחצים על Create Function (יצירת פונקציה), כדי לשנות את ההגדרה, עורכים את האובייקטOptions.מזינים שם לתצוגה ובוחרים אזור. השמות צריכים להיות ייחודיים באזור מסוים.
בקטע Runtime, build, connections and security settings (הגדרות של זמן ריצה, build, חיבורים ואבטחה):
בכרטיסייה Connections (חיבורים), מוודאים שהאפשרות Allow all traffic (התרת כל התעבורה) מסומנת.
בודקים את הגדרות ברירת המחדל ומעדכנים אותן לפי הצורך.
- בשדה Runtime service account בוחרים חשבון שירות.
לוחצים על החלת הפונקציה.
מגדירים את מדיניות ההתראות:
אופציונלי: מעדכנים את השם של מדיניות ההתראות ואת משך הכישלון לפני שליחת ההתראות.
מוסיפים את ערוצי ההתראות.
לוחצים על יצירה.
הפונקציה של Cloud Run שהגדרתם נבנית ונפרסת כדור שני, והמוניטור הסינתטי נוצר.
Terraform
תהליך היצירה של כלי לבדיקת קישורים שבורים באמצעות Terraform זהה לתהליך היצירה של כל כלי אחר לניטור סינתטי. מידע על שימוש ב-Terraform ליצירת בדיקה סינתטית זמין במאמר יצירת בדיקה סינתטית. צריך לבחור בכרטיסייה Terraform.
בודקי קישורים שבורים משתמשים בתבנית broken-links-ok. ההגדרה של הכלי לבדיקת קישורים שבורים מצוינת באובייקט options של קובץ index.js.
כשמגדירים את המבנה options.screenshot_options, הכלי לבדיקת קישורים שבורים אוסף צילומי מסך ושומר אותם בקטגוריה של Cloud Storage.
אם השדה screenshot_options.storage_location לא מוגדר או שהערך שלו הוא מחרוזת ריקה, Monitoring יוצר קטגוריה של Cloud Storage וצילומי המסך נשמרים בקטגוריה הזו.
ב-Monitoring משתמשים במוסכמה הבאה כדי לתת שם לקטגוריה של Cloud Storage:
gcm-PROJECT_ID-synthetics-LOCATION
בביטוי הקודם:
- PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- LOCATION: המיקום של הקטגוריה שלכם ב-Cloud Storage.
REST
תהליך היצירה של בודק קישורים שבורים באמצעות Cloud Monitoring API זהה לתהליך היצירה של כל בודק סינתטי אחר. מידע על שימוש ב-Cloud Monitoring API כדי ליצור בדיקה סינתטית זמין במאמר יצירת בדיקה סינתטית. צריך לבחור בכרטיסייה Cloud Monitoring.
בודקי קישורים שבורים משתמשים בתבנית broken-links-ok. ההגדרה של הכלי לבדיקת קישורים שבורים מצוינת באובייקט options של הקובץ index.js.
כשמגדירים את המבנה options.screenshot_options, הכלי לבדיקת קישורים שבורים אוסף צילומי מסך ושומר אותם בקטגוריה של Cloud Storage.
אם השדה screenshot_options.storage_location לא מוגדר או שהערך שלו הוא מחרוזת ריקה, Monitoring יוצר קטגוריה של Cloud Storage וצילומי המסך נשמרים בקטגוריה הזו.
ב-Monitoring משתמשים במוסכמה הבאה כדי לתת שם לקטגוריה של Cloud Storage:
gcm-PROJECT_ID-synthetics-LOCATION
בביטוי הקודם:
- PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- LOCATION: המיקום של הקטגוריה שלכם ב-Cloud Storage.
עיון בתוצאות
בכל הפעלה, בודק הקישורים השבורים מבצע את הפעולות הבאות:
יוצר טבלה שבה כל שורה מספקת מידע על הבדיקה של URI ספציפי. פרטי הסיכום כוללים את ה-URI של היעד, זמן האחזור, הסטטוס ומזהה רכיב ה-HTML. לדוגמה, בעמודה הזו מופיע הערך a כשבודקים רכיב עוגן של HTML. כשהשורה תואמת ל-URI של המקור, הערך של מזהה רכיב ה-HTML הוא -.
איסוף מדדים, נתוני מעקב ונתוני יומן.
איסוף צילומי מסך, אם מוגדר.
מידע נוסף על ניתוח הנתונים שנאספו זמין במאמר ניתוח תוצאות של בדיקות סינתטיות.
פתרון בעיות
בקטע הזה מוסבר איך אפשר לפתור בעיות שקשורות לכלי לבדיקת קישורים שבורים.
אי אפשר לערוך את ההגדרה של הכלי לבדיקת קישורים שבורים
יצרתם כלי לבדיקת קישורים שבורים באמצעות Google Cloud המסוף, ואתם רוצים לשנות את רכיבי ה-HTML שנבדקים, או לשנות את הזמן הקצוב לתפוגה של ה-URI, את מספר הניסיונות החוזרים, את ההמתנה לבחירת הרכיב ואת האפשרויות לכל קישור. עם זאת, כשעורכים את הכלי לבדיקת קישורים שבורים, שדות ההגדרה לא מוצגים במסוף Google Cloud .
כדי לפתור את הבעיה, מבצעים את הפעולות הבאות:
-
במסוף Google Cloud , עוברים לדף
Synthetic monitoring:
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
- בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
- מחפשים את הבדיקה הסינתטית שרוצים לערוך, לוחצים על more_vert אפשרויות נוספות ובוחרים באפשרות עריכה.
- לוחצים על עריכת הפונקציה.
עורכים את האובייקט
optionsבקובץindex.jsולוחצים על החלת הפונקציה.מידע על השדות והתחביר של האובייקט הזה זמין במאמר
broken-links-ok/index.js.לוחצים על Save.
Google Cloud המסוף מציג הודעה על כך ששמירת צילומי המסך נכשלה
יצרתם כלי לבדיקת קישורים שבורים והגדרתם אותו לשמירת צילומי מסך. עם זאת, במסוף Google Cloud מוצגת אחת מהודעות האזהרה הבאות, יחד עם מידע מפורט יותר:
InvalidStorageLocationStorageValidationErrorBucketCreationErrorScreenshotFileUploadError
כדי לפתור את הבעיות האלה, אפשר לנסות את הפתרונות הבאים:
אם מופיעה ההודעה
InvalidStorageLocation, צריך לוודא שהקטגוריה של Cloud Storage שצוינה בשדהoptions.screenshot_options.storage_locationקיימת.צפייה ביומנים שקשורים לפונקציית Cloud Run. מידע נוסף מופיע במאמר בנושא איתור יומנים.
מוודאים שלחשבון השירות שבו משתמשים בפונקציית Cloud Run המתאימה יש תפקיד בניהול הזהויות ובהרשאות הגישה (IAM) שמאפשר לו ליצור קטגוריות של Cloud Storage, לגשת אליהן ולכתוב בהן.