סקירה כללית על ניראות

יכולת התבוננות לעומק בסוכנים ב-Gemini Enterprise Agent Platform מספקת תמונה מקיפה על הביצועים, ההתנהגות והתקינות של הסוכנים שנפרסו ושל שרתי Model Context Protocol‏ (MCP). מעקב אחרי מדדי מפתח, מעקב אחרי נתיבי ביצוע וצפייה במערכת מרובת הסוכנים (MAS) בכללותה, מאפשרים לכם לאבחן בעיות, לבצע אופטימיזציה של צריכת המשאבים ולשפר את האמינות של הסוכנים.

במסמך הזה מפורטת סקירה כללית על כלי התצפית שזמינים בפלטפורמת Gemini Enterprise Agent, כולל טופולוגיה ברמת המערכת, מעקב אחרי סוכנים ספציפיים ומדדי שרת MCP.

הגדרת טלמטריה

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

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

במקורות המידע הבאים מפורטות ההוראות והדרישות להגדרת טלמטריה של סוכנים:

אותות ניראות (observability)

פלטפורמת הסוכנים של Gemini Enterprise מספקת יכולת תצפית באמצעות מדדים, מעקבים ויומנים.

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

  • סקירה כללית: מעקב אחרי השימוש ברמה גבוהה במסגרת הזמן שנבחרה, כולל סך כל הסשנים, מספר הפניות הממוצע בכל סשן וסך כל הקריאות לנציג. בתרשימים של סדרות הזמן מוצגים השימוש בטוקנים (קלט לעומת פלט), נפח התנועה הכולל של הנציג, אחוזוני זמן האחזור (p50,‏ p95,‏ p99) ושיעורי השגיאות.
  • הערכה: הצגת מוניטורים אונליין להערכת איכות רציפה. הווידג'טים האלה כוללים סדרות זמנים שעוקבות אחרי האיכות הממוצעת של התשובות, מדדי בטיחות, שיעורי הזיות ואיכות השימוש בכלים.
  • מודלים: פירוט של הביצועים לפי מודל הבסיס. אתם יכולים לעקוב אחרי זמן האחזור באחוזון ה-95, מספר הקריאות הכולל, שיעורי השגיאות, כשלים במכסות לקצב הגשת בקשות ושימוש בטוקנים, לפי מודלים ספציפיים.
  • כלים: מעקב אחרי הכלים והשירותים החיצוניים שמחוברים לנציג. בתצוגה הזו מפורטים זמן האחזור באחוזון ה-95, מספר הקריאות ושיעורי השגיאות לכל כלי, וגם תדירות האינטראקציות שבהן לא בוצעה קריאה לאף כלי.
  • שימוש: מספק מדדים ברמת התשתית לסביבת זמן הריצה של הנציג, כולל הקצאת מעבד (CPU) לקונטיינר, הקצאת זיכרון לקונטיינר ושימוש בטוקנים.
  • יומנים: הצגת זרם של יומני פעילות גולמיים של הסוכן שאפשר לסנן, כולל רמת החומרה, חותמות זמן וסיכומי ביצוע, כדי לפתור בעיות לעומק. צפייה ביומני הפעילות של סוכן

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

בשרתי MCP, אתם יכולים לעקוב אחרי מספר הבקשות ומשך הבקשות באחוזון ה-95 כדי לבדוק את השימוש ואת מהירות התגובה.

בדיקת הפעולות של הסוכן

כדי לתמוך בביקורות אבטחה ותאימות בארגון, Gemini Enterprise Agent Platform משתמשת ברישום ביומן עם שיוך כפול כדי לתעד את פעילות הסוכן ב-Cloud Logging. כשנציג מבצע פעולה או קורא לכלי בשם אדם (סמכות שהוקצתה על ידי המשתמש), ביומני הביקורת והביצוע מתועדים גם זהות הנציג שמבוססת על SPIFFE (principal://... ביומני הביקורת או spiffe://... ביומני הביצוע) וגם הזהות של המשתמש האנושי שיזם את הפעולה. כשהסוכן פועל באופן אוטונומי, הפעולה משויכת ביומנים ישירות לזהות הייחודית של הסוכן.

מנהלי אבטחה וניהול כללים לביקורת יכולים לבודד ולבדוק אירועים שהסוכן יזם ב-Cloud Logging, על ידי סינון לפי הדגל is_agentic=true בשאילתות ביומן. שילוב של is_agentic=true עם זהות הסוכן או חשבון המשתמש מאפשר לעקוב אחרי נתיבי הביצוע מקצה לקצה, ולוודא שהמדיניות נאכפת בכל האינטראקציות של הסוכן.

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

כשמגיבים לאירוע אבטחה או להתנהגות חריגה של סוכן, Agent Platform מספקת שתי שכבות משלימות להפסקת הפעילות של הסוכן:

  • סיום מיידי של זמן הריצה או ניתוב מחדש של התנועה: כשמוחקים סוכן שנפרס ב-Agent Runtime (runtimes.delete או reasoningEngines.delete), המערכת מסיימת מיד את המופעים של הקונטיינר שלו, מפסיקה את הסשנים הפעילים ואת הקריאות לסטרימינג, ומבטלת באופן סופי את זהות הסוכן ב-SPIFFE אחרי שפעולת המחיקה מסתיימת. לחלופין, אפשר לנתב מחדש 100% מהתנועה ברמה הבסיסית (root) לגרסה תקינה ידועה באמצעות trafficSplitManual, או להעביר גרסאות קיימות לארכיון על ידי עדכון spec.deployment_spec.agent_gateway_config.
  • ביטול גישה מבוסס-מדיניות: הוספת כלל DENY למערכת גישה מאוחדת לכללי מדיניות (UAP) שנאכפת על ידי Agent Gateway‏ (iamEnforcementMode: "ENFORCE"), או החלת מדיניות דחייה או ביטול תפקיד של ניהול זהויות והרשאות גישה (IAM). הפעולות האלה חוסמות קריאות יוצאות לכלים ול-API, אבל שומרות את מאגר זמן הריצה לניתוח משפטי. עם זאת, העדכונים של כללי מדיניות ה-UAP וה-IAM הם עקביים בסופו של דבר: שינויים ישירים במדיניות נכנסים לתוקף בדרך כלל תוך 2 דקות, אבל יכול להיות שיעברו עד 7 דקות או יותר עד שהם יופצו באופן גלובלי (ראו הפצת שינויים בגישה), ויכול להיות שיעברו כמה דקות עד כמה שעות עד שהעדכונים של principalSet או של החברות בקבוצה יסונכרנו. עדכוני מדיניות נבדקים בבדיקות הרשאה חדשות, ולא סוגרים בכוח חיבורי סטרימינג שכבר נוצרו, אלא אם הם עוברים הרשאה מחדש.

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

זמן אחזור של טלמטריה וממצאי אבטחה

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

בטבלה הבאה מפורטים מודל ההערכה והזמן האחזור הצפוי לכל אות טלמטריה ואות מאובטח ב-Agent Platform:

אות או אמצעי בקרה מודל הערכה והטמעה זמן אחזור אופייני
יומני ביקורת של Cloud ויומני בקשות של Agent Gateway (cloudaudit.googleapis.com/*, networkservices.googleapis.com/gateway_requests) הם נוצרים באופן סינכרוני כשמתבצעת הערכה של קריאות ל-API ובדיקות הרשאה של שער, ואז נקלטים ב-Logging. כמעט בזמן אמת (בדרך כלל אפשר לחפש ב-Logs Explorer תוך כמה שניות). מסנני עדכניות צרים של CLI כמו --freshness=6h עלולים לפעמים לפספס רשומות שנוספו לאחרונה לאינדקס. צריך להשתמש ב---freshness=1d כשמאמתים אירועים מהזמן האחרון.
יומני הביצוע של Agent Runtime (aiplatform.googleapis.com/reasoning_engine_stdout, reasoning_engine_stderr) מועברים בסטרימינג באופן אסינכרוני ממאגר זמן הריצה ל-Logging. בדרך כלל מופיעים תוך כמה שניות מרגע השליחה.
מעקבים מבוזרים ב-Cloud Trace הייצוא מתבצע באופן אסינכרוני כשהטווחים של OpenTelemetry מסתיימים, בכפוף לכללים של samplingRate ו-parentBasedSampling שהוגדרו. בדרך כלל אפשר לחפש אותם תוך כמה שניות מסיום הטווח.
מדדים של Cloud Monitoring דגימה תקופתית מ-Agent Runtime, מ-Agent Gateway ומצינורות עיבוד נתונים לזיהוי אנומליות. הדגימה מתבצעת כל 60 עד 120 שניות, עם עיכוב של עד 180 עד 420 שניות בהצגה ב-Metrics Explorer ובלוחות הבקרה.
אכיפת מדיניות מוטמעת (Agent Gateway, שרת proxy לאימות זהויות (IAP), הגנה מוגברת על המודל) הבדיקה מתבצעת באופן סינכרוני בנתיב הבקשה בזמן אמת, לפני שמושלמת קריאת API לכלי, בקשת MCP או הנחיה למודל. יירוט מוטמע בזמן אמת (ללא עיכוב לאחר העיבוד).
זיהוי אנומליות אצל סוכנים וממצאים של Security Command Center‏ (AGENT_SESSION_ANOMALY) ההערכה מתבצעת באופן אסינכרוני מחוץ לפס, בפייפליין זיהוי רב-שכבתי, אחרי שיומני הסשנים והמעקבים נקלטים, בלי להוסיף זמן אחזור לתשובות של הנציג בזמן אמת. ההפעלה הראשונית של ההיקף נמשכת כ-40 דקות. מדדי האנומליות נדגמים כל 120 שניות (עד 420 שניות של עיכוב בהצגה), ויש זמן אחזור נוסף של סנכרון לפני שהממצאים המאומתים מופיעים ב-Security Command Center.

שמירה של יומני ביקורת עם זיהוי שינויים

הרשומות ביומני הביקורת של Cloud לא ניתנות לשינוי: אחרי ש-Logging כותב רשומה ביומן הביקורת, אי אפשר לשנות את המטען הייעודי (payload) ואת המטא-נתונים שלה. יומני הביקורת Admin Activity ו-System Event מאוחסנים בקטגוריית היומנים _Required, שבה נאכפת תקופת שמירה קבועה של 400 ימים, ואי אפשר לשנות או למחוק אותה.

כברירת מחדל, יומני הביקורת של בקרת הרשאות גישה לנתונים (cloudaudit.googleapis.com/data_access), יומני דחיית המדיניות (cloudaudit.googleapis.com/policy_denied), יומני הבקשות של Agent Gateway‏ (networkservices.googleapis.com/gateway_requests) ויומני הביצוע של סוכנים עם שיוך כפול (is_agentic=true) מנותבים לקטגוריית היומנים _Default עם תקופת שמירה של 30 ימים.

כדי לאכוף שמירה של ראיות תאימות מסוג WORM (כתיבה פעם אחת, קריאה הרבה פעמים) שמעידות על שיבוש, צריך לנתב את יומני הביקורת של הנציג ויומני השער לקטגוריית Logging בהתאמה אישית, להגדיר תקופת שמירה בהתאמה אישית (מיום אחד עד 3,650 ימים) ולנעול את הקטגוריה באופן סופי. נעילת קטגוריית רישום ביומן היא פעולה בלתי הפיכה שמונעת מכל אחד, כולל Project Owner ו-Organization Administrator, למחוק את הקטגוריה, למחוק רשומות ביומן לפני שתקופת השמירה שלהן מסתיימת או לקצר את תקופת השמירה.

כדי ליצור ולנעול קטגוריה בהתאמה אישית ב-Logging ליומני ביקורת של נציגים באמצעות Google Cloud CLI, מריצים את הפקודות הבאות:

gcloud logging buckets create BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --locked \
    --project=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

  • ‫BUCKET_ID: מזהה ייחודי לקטגוריית יומן הביקורת (לדוגמה, agent-audit-worm-bucket).
  • ‫LOCATION: מיקום הקטגוריה (לדוגמה, global,‏ us או eu).
  • ‫RETENTION_DAYS: מספר הימים לשמירת רשומות ביומן (בין 1 ל-3650).
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

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

ייצוא של יומני ביקורת למערכת SIEM

כדי לרכז את המעקב אחרי האבטחה, את ההתאמה ואת הארכוב לטווח ארוך לצורך תאימות, אתם יכולים לייצא באופן רציף את יומני הביקורת של הסוכנים, את החלטות ההרשאה של Agent Gateway ואת יומני הביצוע של is_agentic=true אל Google Security Operations ‏(Google SecOps) או אל מערכת של צד שלישי לניהול אבטחת מידע ואירועים (SIEM).

אתם יכולים להגדיר sink ביומן ברמת הפרויקט או sink מצטבר ברמת הארגון או התיקייה, כדי לנתב את היומנים ליעדים הבאים:

  • ‫Google Security Operations: הטמעת יומני ביקורת של Cloud, יומני Agent Gateway וממצאים של AGENT_SESSION_ANOMALY מ-Security Command Center ב-Google SecOps באופן מובנה או דרך פיד של Pub/Sub או Cloud Storage, כדי לחקור סשנים של סוכנים לצד נתוני טלמטריה של אבטחה ארגונית. הוראות להגדרה מופיעות במאמר ייצוא נתוני Google Cloud אל Google SecOps.
  • ‫Pub/Sub (Pub/Sub): העברת יומני ביקורת של נציגים בזמן אמת לנושא Pub/Sub, כדי להטמיע אותם בפלטפורמות SIEM של צד שלישי (כמו Splunk, ‏ Datadog או QRadar) באמצעות מינוי ל-Pub/Sub או מחבר Dataflow. למידע נוסף, קראו את המאמר ניתוב יומנים ל-Pub/Sub.
  • ‫BigQuery או Observability Analytics: ייצוא יומנים למערך נתונים ב-BigQuery או קישור של מאגר יומנים עם Observability Analytics ל-BigQuery כדי להריץ שאילתות SQL בנושא תאימות על זהויות של נציגים, הקצאות של משתמשים ודחיות של מדיניות שער.
  • ‫Cloud Storage: ייצוא קובצי יומן בפורמט JSON באצווה לקטגוריה של Cloud Storage, עם הפעלה של נעילת קטגוריה, לצורך העברה לארכיון לטווח ארוך ללא שינויים.

כדי ליצור ב-Logging כיור שמעביר בסטרימינג את יומני הביקורת של הנציגים ויומני השער לנושא Pub/Sub להטמעה ב-SIEM, מבצעים את השלבים הבאים:

  1. יוצרים את ה-sink ביומן עם מסנן הכללה שמתעד את יומני הביקורת של Cloud, יומני הבקשות של Agent Gateway, יומני Agent Runtime ורשומות של שיוך כפול (is_agentic=true):

    gcloud logging sinks create SINK_NAME \
    pubsub.googleapis.com/projects/DESTINATION_PROJECT_ID/topics/TOPIC_ID \
    --log-filter='logName:("cloudaudit.googleapis.com" OR "networkservices.googleapis.com%2Fgateway_requests" OR "aiplatform.googleapis.com%2Freasoning_engine") OR jsonPayload.is_agentic=true OR labels.is_agentic="true"' \
    --project=PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SINK_NAME: שם ל-sink ביומן (לדוגמה, agent-audit-siem-sink).
    • ‫DESTINATION_PROJECT_ID: מזהה הפרויקט שמארח את נושא היעד ב-Pub/Sub.
    • ‫TOPIC_ID: המזהה של נושא Pub/Sub שה-SIEM שלכם נרשם אליו.
    • ‫PROJECT_ID: מזהה הפרויקט שממנו מייצאים את היומנים. כדי לייצא את כל הארגון, מחליפים את --project=PROJECT_ID ב---organization=ORGANIZATION_ID --include-children.

  2. מאחזרים את הזהות של חשבון השירות של הכותב בכיור, ומקצים לו את התפקיד "פרסום הודעות ב-Pub/Sub"‏ (roles/pubsub.publisher) בנושא היעד:

    WRITER_IDENTITY=$(gcloud logging sinks describe SINK_NAME \
    --project=PROJECT_ID \
    --format='value(writerIdentity)')

gcloud pubsub topics add-iam-policy-binding TOPIC_ID \
    --project=DESTINATION_PROJECT_ID \
    --member="${WRITER_IDENTITY}" \
    --role="roles/pubsub.publisher"

מוסכמות של OpenTelemetry ל-AI גנרטיבי

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

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

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