Genkit Monitoring: פתרון בעיות

לא רואים נתוני מעקב ו/או מדדים ב-Firebase Genkit Monitoring

  1. מוודאים שממשקי ה-API הבאים מופעלים בפרויקט הבסיסי ב-GCP:
  2. מוודאים שהתפקידים הבאים חלים על חשבון השירות שמריץ את הקוד (או על חשבון השירות שהוגדר כחלק מאפשרויות הפלאגין) ב-Cloud IAM.
    • כתיבה של מדדי מעקב (roles/monitoring.metricWriter)
    • Cloud Trace Agent‏ (roles/cloudtrace.agent)
    • כתיבה ביומן (roles/logging.logWriter)

  3. בודקים את יומני האפליקציה כדי למצוא שגיאות שרשומים ב-Cloud Logging, ב-Cloud Trace ו/או ב-Cloud Monitoring. בתשתית של GCP, כמו Firebase Functions ו-Cloud Run, גם אם טלמטריה מוגדרת באופן שגוי, יומני stdout/stderr עוברים הטמעה (ingestion) באופן אוטומטי על ידי Cloud Logging Agent, ומאפשרים לאבחן בעיות במסוף Cloud Logging.

  4. ניפוי באגים באופן מקומי:

    מפעילים את הייצוא של נתוני הפיתוח:

    enableFirebaseTelemetry({
  forceDevExport: true
});

    כדי לבדוק עם פרטי הכניסה האישיים של המשתמש, משתמשים ב-[CLI של gcloud] כדי לבצע אימות מול Google Cloud. הפעולה הזו יכולה לעזור לאבחן ממשקי API מופעלים/מושבתים, אבל היא לא בודקת את האפשרות gcloud auth application-default login.

    לחלופין, התחזות לחשבון השירות מאפשרת לבדוק גישה שדומה לגישה בסביבת הייצור. כדי להתחזות לחשבונות שירות, צריך להחיל את התפקיד roles/iam. serviceAccountTokenCreator ב-IAM על חשבון המשתמש:

    gcloud auth application-default login --impersonate-service-account <SERVICE_ACCT_EMAIL>

    למידע נוסף, עיינו במסמכי התיעוד של ADC.

מהי מהימנות ההעלאה של נתוני טלמטריה ב-Firebase Functions או ב-Cloud Run

כש-Genkit מתארח ב-Google Cloud Run (כולל Cloud Functions for Firebase), יכול להיות שההעלאה של נתוני הטלמטריה תהיה פחות מהימנה כי הקונטיינר עובר למצב מחזור חיים 'לא פעיל'. אם חשוב לכם לשפר את האמינות, מומלץ לשנות את הקצאת המעבד ל-always allocated במסוף Google Cloud.