יצירת כלי לבדיקת קישורים שבורים

במסמך הזה מוסבר איך להגדיר בדיקה תקופתית של הקישורים שכלולים ב-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.

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

צריך לבצע את השלבים הבאים בפרויקט Google Cloud שבו יאוחסן בודק הקישורים:

  1. כדי לקבל את ההרשאות שדרושות להצגה ולשינוי של בדיקות סינתטיות באמצעות Google Cloud המסוף, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

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

  2. Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  3. מוודאים ש Google Cloud הפרויקט מכיל את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. חשבון השירות הזה נוצר כשמפעילים את Compute Engine API, והשם שלו דומה ל-12345-compute@developer.gserviceaccount.com.

    נכנסים לדף Service Accounts במסוף Google Cloud :

    לדף Service Accounts

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

    אם חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לא קיים, לוחצים על יצירת חשבון שירות וממלאים את תיבת הדו-שיח.

  4. מוודאים שחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או חשבון השירות שיצרתם קיבל את התפקיד 'עריכה' (roles/editor).

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

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

      כניסה לדף IAM

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

    2. מסמנים את התיבה Include Google-provided role grants.
    3. אם חשבון השירות שבו נעשה שימוש בבדיקה הסינתטית לא מופיע, או אם לא הוקצה לו תפקיד שכולל את ההרשאות בתפקיד של Cloud Trace Agent ‏ (roles/cloudtrace.agent), צריך להקצות את התפקיד הזה לחשבון השירות.
  5. מגדירים את ערוצי ההתראות שבהם רוצים להשתמש כדי לקבל התראות. מומלץ ליצור כמה סוגים של ערוצי התראות. מידע נוסף זמין במאמרים בנושא יצירה וניהול של ערוצי התראות ויצירה וניהול של ערוצי התראות באמצעות API.

  6. Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    Terraform

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Terraform שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

      If you're using a local shell, then create local authentication credentials for your user account: 

      gcloud auth application-default login

      You don't need to do this if you're using Cloud Shell.

      If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

    למידע נוסף, ראו הגדרת 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 קיימת.

    1. מוודאים שהפעלתם את ממשקי ה-API הנדרשים, שהפרויקט מכיל חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, ושהחשבון הזה קיבל את התפקיד 'עריכה' (roles/editor). מידע נוסף זמין במאמר לפני שמתחילים.

    2. במסוף Google Cloud , עוברים לדף  Synthetic monitoring:

      כניסה אל Synthetic monitoring

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

    3. בסרגל הכלים של מסוף Google Cloud , בוחרים את הפרויקט הרלוונטי ב- Google Cloud . בהגדרות של מרכז האפליקציות, בוחרים את פרויקט המארח או את פרויקט הניהול של מרכז האפליקציות.
    4. בוחרים באפשרות יצירת בדיקה סינתטית.
    5. בוחרים את התבנית Broken link checker (בדיקת קישורים מנותקים).
    6. מזינים שם לניטור הסינתטי.

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

    8. מגדירים את ה-URI ואת הרכיבים לבדיקה:

      1. לוחצים על Origin URI ומזינים URI שרוצים לבדוק. הערך שאתם מזינים חייב להיות נקודת קצה מסוג HTTP או HTTPS. לדוגמה, אפשר להזין https://mywebsite.example.com.

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

      3. אופציונלי: בשדה HTML element selector (סלקטור של רכיב HTML), מזינים את רכיב ה-HTML שרוצים להתאים, כרשימה מופרדת בפסיקים. הערך שאתם מזינים מומר למחרוזת ואז מועבר לשיטה Document: querySelectorAll().

        כברירת מחדל, השדה הזה מוגדר ל-a, שמתאים לעוגנים. אפשר להזין ערכים כמו a, img, אם רוצים להתאים גם עוגנים וגם תמונות.

      4. אופציונלי: בשדה HTML attributes to follow (מאפייני HTML להמשך), מזינים את מאפייני ה-HTML שרוצים להתאים. הערכים המופרדים בפסיקים שאתם מזינים מועברים בנפרד אל השיטה getAttribute().

        כברירת מחדל, השדה הזה מוגדר ל-href, שמציין את ה-URI של הקישור. אפשר להזין כמה מאפיינים. לדוגמה, אפשר להזין href, src. בדוגמה הזו, הקוד מחפש את המאפיין href ואז מחפש את המאפיין src.

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

        1. לוחצים על הצגת אפשרויות נוספות.

        2. כדי להגדיר את הכלי לבדיקת קישורים שבורים כך שימתין להופעה של סלקטור ספציפי ב-URI לפני שיתבצע גירוד של קישורים, מזינים את הסלקטורים ב-CSS בשדה Wait for element selector (המתנה לסלקטור של רכיב). הערך שאתם מזינים מומר למחרוזת ואז מועבר לשיטה page.waitForSelector().

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

        3. עדכון הסדר שבו הקישורים נבחרים לבדיקה.

        4. הגדרת ניסיונות חוזרים.

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

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

        5. מגדירים זמן קצוב לתפוגה שחל על כל מזהה URI. כברירת מחדל, הערך הזה מוגדר ל-30 שניות.

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

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

      gcm-PROJECT_ID-synthetics-LOCATION

      בביטוי הקודם:

      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫LOCATION: המיקום של הקטגוריה שלכם ב-Cloud Storage.

      יש לכם אפשרות להשתמש בקטגוריה קיימת של Cloud Storage.

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

      1. לוחצים על יצירת פונקציה.

        הערכים בשדות הגדרת ה-URI מועתקים לאובייקט Options בקובץ index.js כשלוחצים על יצירת פונקציה. אחרי שלוחצים על Create Function (יצירת פונקציה), כדי לשנות את ההגדרה, עורכים את האובייקט Options.

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

      3. בקטע Runtime, build, connections and security settings (הגדרות של זמן ריצה, build, חיבורים ואבטחה):

        • בכרטיסייה Connections (חיבורים), מוודאים שהאפשרות Allow all traffic (התרת כל התעבורה) מסומנת.

        • בודקים את הגדרות ברירת המחדל ומעדכנים אותן לפי הצורך.

        • בשדה Runtime service account בוחרים חשבון שירות.

      4. לוחצים על החלת הפונקציה.

    11. מגדירים את מדיניות ההתראות:

      1. אופציונלי: מעדכנים את השם של מדיניות ההתראות ואת משך הכישלון לפני שליחת ההתראות.

      2. מוסיפים את ערוצי ההתראות.

    12. לוחצים על יצירה.

      פונקציית Cloud Run שהגדרתם נבנית ונפרסת כדור שני, והמוניטור הסינתטי נוצר.

    Terraform

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

    כדי לפתור את הבעיה, מבצעים את הפעולות הבאות:

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

      כניסה אל Synthetic monitoring

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

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

    5. עורכים את האובייקט options בקובץ index.js ולוחצים על החלת הפונקציה.

      מידע על השדות והתחביר של האובייקט הזה זמין במאמר broken-links-ok/index.js.

    6. לוחצים על Save.

    Google Cloud המסוף מציג שהשמירה של צילומי המסך נכשלה

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

    • InvalidStorageLocation
    • StorageValidationError
    • BucketCreationError
    • ScreenshotFileUploadError

    כדי לפתור את הבעיות האלה, נסו את הפתרונות הבאים:

    • אם מופיעה ההודעה InvalidStorageLocation, צריך לוודא שהקטגוריה של Cloud Storage שצוינה בשדה options.screenshot_options.storage_location קיימת.

    • צפייה ביומנים שקשורים לפונקציית Cloud Run. מידע נוסף מופיע במאמר בנושא איתור יומנים.

    • מוודאים שלחשבון השירות שבו נעשה שימוש בפונקציית Cloud Run המתאימה יש תפקיד בניהול הזהויות והרשאות הגישה (IAM) שמאפשר לו ליצור קטגוריות של Cloud Storage, לגשת אליהן ולכתוב בהן.

    המאמרים הבאים