הגדרת תיוג בצד השרת באמצעות App Engine

במדריך הזה נסביר איך:

  • הקצאת שרת תיוג ב-Google Cloud Platform ‏ (GCP) App Engine.
  • משדרגים את שרת התיוג כדי לטפל בתנועה בזמן אמת.
  • להגדיל או להקטין את מספר השרתים שמריצים את מאגר התגים של Google Tag Manager.
  • חשוב לעדכן את הגרסה של שרת התיוג אחרי הקצאת השרת.

דרישות מוקדמות

  1. צריך חשבון ב-GCP. אם אין לכם חשבון, אתם צריכים ליצור חשבון GCP חדש.
  2. צריך חשבון לחיוב ב-GCP. אם אין לכם חשבון כזה, אתם צריכים ליצור חשבון לחיוב ב-GCP (נדרש תפקיד יוצר חשבון לחיוב).
  3. צריך את התפקיד 'יצירת פרויקטים' ואת התפקיד 'משתמש בחשבון לחיוב'. מידע נוסף על הוספת תפקידים

1. הקצאת שרת

כדי ליצור שרת תיוג חדש במכונה של App Engine, צריך:

  • יצירת מאגר תגים בצד השרת חדש ב-Tag Manager
  • יצירת פרויקט חדש ב-Google Cloud ‏ (GCP)
  • הקצאת שרת תיוג חדש ב-App Engine
  • מוסיפים את כתובת ה-URL של שרת התיוג החדש למאגר התגים בצד השרת של Tag Manager

יצירת מאגר תגים בצד השרת ב-Google Tag Manager

  1. פותחים את Google Tag Manager.

  2. בשורה של החשבון, לוחצים על סמל האפשרויות הנוספות > יצירת מאגר תגים.

  3. יוצרים מאגר תגים חדש בצד השרת.

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

יצירת פרויקט חדש ב-GCP

כדי ליצור פרויקט חדש ב-GCP לשרת התיוג:

  1. פותחים את מסוף Google Cloud.

  2. איך יוצרים פרויקט חדש ב-GCP?

  3. נותנים שם לפרויקט. מומלץ להשתמש במזהה מאגר התגים כדי שיהיה לכם נוח. השם הזה משמש רק ב-GCP.

  4. חשוב לשים לב למזהה הפרויקט ב-GCP, כי תצטרכו אותו כדי ליצור את שרת התיוג.

הקצאת שרת תיוג חדש

כדי ליצור את שרת התיוג:

  1. פותחים את Cloud Shell.

  2. מגדירים את פרויקט GCP ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שרשמתם קודם:

    gcloud config set project project ID

  3. יוצרים את שרת התיוג באמצעות סקריפט המעטפת. מגדירים את סוג הפריסה ל-testing.

    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

הוספת כתובת ה-URL של שרת התיוג ל-Tag Manager

  1. פותחים את Google Tag Manager.

  2. בקטע ניהול > הגדרות מאגר התגים, לוחצים על הוספת כתובת אתר. אם אתם לא יודעים מה כתובת ה-URL של השרת, מריצים את הפקודה הבאה ב-Cloud Shell:

    gcloud app browse

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

ההגדרה הראשונית של השרת (testing)

הגדרת הבדיקה מתאימה לבדיקת המוצר על ידי שליחת כמויות קטנות של תנועת בדיקה ושימוש בתכונה 'תצוגה מקדימה' ב-Tag Manager. המערך הזה הוא סוג מכונה F1 של App Engine בסביבה רגילה, וברוב המקרים לא תחויבו על השימוש בו.

2. שימוש ב-App Engine בסביבת ייצור

בהגדרה של production, כל שרת עולה בערך 40 $לחודש. כל שרת הוא מופע של App Engine עם 1 vCPU,‏ 0.5GB זיכרון ו-10GB דיסק בסביבה הגמישה.

במאמר ניהול עלויות ב-App Engine מוסבר על החיוב ב-App Engine ועל הגדרת התראות לגבי חיוב. אנחנו ממליצים בחום להגדיר התראה לגבי חיוב.

מומלץ להפעיל לפחות 3 שרתים כדי לצמצם את הסיכון לאובדן נתונים במקרה של הפסקה זמנית בשירות של שרת. עם זאת, אתם יכולים לבחור להפעיל פחות (או יותר) שרתים. אנחנו צופים שהתאמה אוטומטית לעומס של 3 עד 6 שרתים (ברירת המחדל) תטפל ב-50 עד 200 בקשות בשנייה. הביצועים תלויים במספר התגים ובפעולות שהתגים מבצעים.

כדי להגדיר את שרת התיוג:

  1. פותחים את Cloud Shell ב-Google Cloud Platform.
  2. מגדירים את הפרויקט ב-Cloud Platform ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שרשמתם קודם: 
    gcloud config set project project ID
  3. כדי להגדיר מחדש את שרת התיוג לסביבת ייצור, מריצים את סקריפט ההגדרה שבהמשך. מבצעים את המשימות הבאות: 
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"
    1. משנים את סוג הפריסה ל-production.
    2. הגדרת שרתים נוספים לטיפול בתעבורת נתונים בסביבת הייצור. מומלץ להשתמש בלפחות שלושה שרתים.

אופציונלי: השבתת הרישום ביומן

רישום בקשות ביומן

כברירת מחדל, ביומנים של App Engine נרשם מידע על כל בקשה (למשל, נתיב הבקשה, פרמטרים של שאילתה וכו') שהמערכת מקבלת. אם שרת התיוג שלכם מטפל בהרבה בקשות בחודש (למשל, יותר ממיליון), יכול להיות שתחויבו בסכומים גבוהים על רישום ביומן של הודעות היומן האלה. כדי להפחית את עלויות הרישום ביומן או לבטל אותן, מומלץ להשבית את רישום הבקשות ביומן של App Engine.

כדי להשבית את רישום הבקשות ביומן של App Engine:

  1. ב-Google Cloud Platform, פותחים את Logs Router. מוודאים שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
    צילום מסך של כלי לבחירת פרויקטים ב-GCP, שבו מוצג מזהה לדוגמה של מאגר תגים ב-Tag Manager.
  2. בשורה Type: Cloud Logging bucket, Name: _Default, לוחצים על סמל האפשרויות הנוספות ואז על Edit Sink.
  3. בקטע יעד להעברה, בוחרים באפשרות 'מאגר יומנים' _Default.

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

    NOT LOG_ID("appengine.googleapis.com/nginx.request") AND NOT
LOG_ID("appengine.googleapis.com/request_log")

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

    ‫
    NOT LOG_ID("requests")

  6. לוחצים על עדכון יעד כדי להחיל את השינויים. מעכשיו, בקשות App Engine לא ייכללו ברישום ביומן.

  7. מוודאים שלא מופיעות בקשות חדשות ביומנים של Logs Explorer.

רישום במסוף

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

זיהוי של יומני מסוף לא רצויים:

  1. ב-GCP, פותחים את Logs Explorer.

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

    תג עשוי לשלוח את היומנים הבאים:

    const logToConsole = require('logToConsole');

logToConsole('Custom message: ' + data.param1);
logToConsole('An important message to keep around!');
data.gtmOnSuccess()

    מחפשים את הודעות היומן המתאימות בשדה textPayload:
    צילום מסך של Logs Explorer ב-GCP, שבו מוצגים יומנים לדוגמה.

כדי להשבית הודעה ביומן המסוף:

  1. ב-Google Cloud Platform, פותחים את Logs Router. מוודאים שאתם נמצאים בפרויקט שתואם למזהה מאגר התגים:
    צילום מסך של כלי לבחירת פרויקטים ב-GCP, שבו מוצג מזהה לדוגמה של מאגר תגים ב-Tag Manager.
  2. בשורה Type: Cloud Logging bucket, Name: _Default, לוחצים על סמל האפשרויות הנוספות ואז על Edit Sink.
  3. בקטע יעד להעברה, בוחרים באפשרות 'מאגר יומנים' _Default.

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

    NOT textPayload:"Custom message:"

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

  5. לוחצים על עדכון יעד כדי להחיל את השינויים. ההודעה התואמת logToConsole צריכה להיות מוחרגת מהרישום ביומן.

  6. מוודאים שלא מופיעות הודעות חדשות ביומן המסוף בLogs Explorer.

3. מיפוי הפריסה לדומיין המותאם אישית

פריסת התיוג בצד השרת כברירת מחדל מתארחת בדומיין App Engine. מומלץ לשנות את הפריסה כך שתשתמש בתת-דומיין של האתר.

מיפוי של תת-הדומיין של האתר לשרת התיוג.

4. הוספת כתובת ה-URL של השרת ל-Google Tag Manager

אחרי שיש לכם שרת, אתם צריכים לוודא שמערכת Google Tag Manager יודעת שהיא צריכה להשתמש בשרת שלכם.

  1. פותחים את Google Tag Manager.

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

  3. פותחים את ההגדרות של מאגר תגים בצד השרת בכרטיסייה Admin (אדמין) > Container Settings (הגדרות מאגר תגים).

  4. לוחצים על הוספת כתובת URL ומדביקים את כתובת ה-URL של השרת.

  5. שומרים וחוזרים לסביבת העבודה.

5. אימות

אחרי שמגדירים את שרת התיוג, צריך לוודא שהוא פועל כמצופה.

אימות ממשק המשתמש

בסביבת העבודה ב-Tag Manager, לוחצים על הלחצן Preview (תצוגה מקדימה). אם דף התצוגה המקדימה נטען, סימן שההגדרה תקינה.

אימות API

אפשר גם לוודא שהשרת מגיב לבדיקות תקינות באמצעות ה-API שלו:

  1. מעתיקים את כתובת ה-URL של מאגר התגים בצד השרת מתוך Admin > Container Settings (ניהול > הגדרות מאגר התגים).
  2. פותחים כרטיסייה חדשה בדפדפן.
  3. מדביקים את כתובת ה-URL ומוסיפים /healthy לנתיב. לדוגמה: https://www.example.com/metrics/healthy
  4. אם השירות פועל, הטקסט ok אמור להופיע בדף.

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

מידע נוסף על שיטות מומלצות לאימות תיוג בצד השרת זמין במאמר הגדרת דומיין בהתאמה אישית.

תצוגה מקדימה של כמה כתובות URL

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

אם ציינתם כמה כתובות URL, כל הנתיבים (המחרוזת אחרי שם הדומיין) צריכים להיות זהים.

Works לא עובד
כתובת URL 1: example.com/abc
כתובת URL 2: example2.com/abc		 כתובת URL 1: example.com/abc
כתובת URL 2: example2.com/def

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

עדכון הגרסה של שרת התיוג

עדכונים חדשים של שרת התיוג מכילים תיקונים של נקודות חולשה באבטחה ותכונות חדשות. מומלץ לעדכן את שרת התיוג לפחות בכל פעם שיוצאת גרסה חדשה (לדוגמה, שדרוג מגרסה 1.x.x לגרסה 2.x.x) כשמערכת Tag Manager שולחת לכם הודעה לעדכן.

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

כדי לעדכן את שרת התיוג:

  1. פותחים את Cloud Shell ב-Google Cloud Platform.
  2. מגדירים את הפרויקט ב-Cloud Platform ב-Cloud Shell. מחליפים את project ID במזהה הפרויקט ב-GCP שרשמתם קודם: 
    gcloud config set project project ID
  3. מריצים את סקריפט ההגדרה עם אותן הגדרות שבהן השתמשתם קודם. ההגדרות הקיימות מוגדרות כברירת מחדל. 
    bash -c "$(curl -fsSL https://googletagmanager.com/static/serverjs/setup.sh)"

כדי לוודא שהעדכון בוצע בהצלחה:

  1. במאגר התגים בצד השרת, לוחצים על הלחצן תצוגה מקדימה כדי להתחיל סשן ניפוי באגים חדש ולשלוח בקשה בכרטיסייה נפרדת.
  2. בכרטיסייה Console (מסוף) שבקטע Summary (סיכום), מוודאים שלא מוצגות הודעות שמבקשות לעדכן את שרת התיוג.

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

פתרון בעיות שקשורות לפסק זמן בפריסה בסביבת הייצור

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

  1. לחשבונות השירות יש הרשאות שגויות – חשבונות השירות של Compute Engine ו-App Engine אחראים לפריסה ולתחזוקה של פריסת הייצור. כברירת מחדל, הן מוגדרות מראש עם ההרשאות המתאימות. עם זאת, במקרים מסוימים, מדיניות הארגון עלולה לגרום לכך שהם יהיו שגויים.

    1. בסרגל הניווט הימני במסוף Google Cloud, עוברים לדף IAM & Admin.
    2. מחפשים את חשבון השירות של Compute Engine‏ <project_number>-compute@developer.gserviceaccount.com ואת חשבון השירות של App Engine‏ <project_name>@appspot.gserviceaccount.com.
    3. לשני חשבונות השירות צריך להיות מוקצה התפקיד Editor. אם לאחד מהחשבונות אין תפקיד Editor, צריך לעדכן את התפקיד. לשם כך, לוחצים על סמל העיפרון משמאל לחשבון, לוחצים על התפריט הנפתח של התפקיד הקיים, גוללים למעלה ולוחצים על Project ואז על Editor.

  2. מכסה לא מספיקה – הפריסה בסביבת הייצור צורכת מכסה של Compute Engine. אם אין לפרויקט מספיק מכסה, יכול להיות שפסק הזמן של הפריסה יחלוף במהלך הניסיון להקצות משאבים.

    1. בסרגל הניווט הימני במסוף Google Cloud, עוברים לדף IAM & Admin (ניהול IAM), ואז לוחצים על הכרטיסייה Quotas (מכסות) בסרגל הניווט הימני.
    2. ליד החלק העליון של הדף, לוחצים על תיבת הטקסט סינון הטבלה ומקלידים Compute Engine API. לוחצים על התוצאה היחידה.
    3. מוודאים שכל סטטוסי המכסות נמצאים במסגרת המגבלה או שיש לידם סימן וי ירוק.
    4. מאתרים את האפשרות מעבדים ולוחצים עליה. מוודאים שהשימוש הנוכחי בתוספת מספר המכונות שנפרסות עדיין יהיה מתחת למכסה של אזור הפריסה.