ניראות (observability) עם Envoy

במסמך הזה מוסבר איך ליצור מעקב ורישום ביומן עבור Envoy proxy. בנוסף, מוסבר במאמר איך לייצא את המידע אל Cloud Trace ו-Cloud Logging.

שימוש ב-service mesh מאפשר לכם לעקוב אחרי תעבורת הנתונים אל השירותים וממנו, וכך ליהנות מניטור עשיר יותר ומניפוי באגים בלי לבצע שינויים בקוד של השירות עצמו. באדריכלות של שרת proxy מסוג sidecar שמשמשת את Cloud Service Mesh, שרת ה-proxy הוא הרכיב שמטפל בבקשות ומספק את נתוני הטלמטריה הנדרשים. צריך לאסוף את נתוני הטלמטריה ולאחסן אותם במיקום מרכזי כדי להשתמש בהם למטרות נוספות, כמו ניתוח נתונים, התראות ופתרון בעיות.

הגדרת הדגמה

בדוגמה הבאה נעשה שימוש בהגדרה הבאה כדי להדגים מעקב ורישום ביומן:

  • אפליקציה יחידה שמקשיבה ביציאת ה-HTTP ומחזירה את שם המארח של המכונה הווירטואלית (VM) שטיפלה בבקשה. בתרשים, האפליקציה הזו נמצאת בפינה השמאלית העליונה, עם התווית HTTP service(s) (10.10.10.10:80). מכונה וירטואלית אחת או יותר יכולות לספק את השירות הזה.
  • מכונה וירטואלית אחת ב-Compute Engine שמריצה צרכן של השירות הזה. בתרשים, היא מסומנת בתווית Demo Compute Engine VM.
  • שרת proxy מסוג Envoy sidecar שהותקן והוגדר על ידי Cloud Service Mesh. בתרשים, הרכיב הזה מסומן בתווית envoy.
  • אפליקציה של צרכן שירות, שמוצגת בתיבה בצד ימין, היא הצרכן של שירות ה-HTTP שפועל ב-10.10.10.10:80.
אפליקציית הדגמה לרישום ביומן ולמעקב ב-Envoy.
אפליקציה להדגמה של רישום ביומן ומעקב ב-Envoy (לחצו כדי להגדיל)

השלבים הבאים תואמים לתוויות הממוספרות בתרשים:

  1. ‫Cloud Service Mesh מגדיר את שרת ה-proxy של Envoy כך שיבצע את הפעולות הבאות:

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

  2. אחרי שהצרכן שולח בקשה אל 10.10.10.10, פרוקסי ה-sidecar מנתב את הבקשה ליעד הנכון.

  3. שרת ה-proxy של קובץ העזר החיצוני גם יוצר את נתוני הטלמטריה הנדרשים:

    1. מוסיפה רשומה ליומן הגישה בדיסק המקומי עם מידע נוסף על הבקשה.
    2. הפונקציה יוצרת רשומה של נתוני מעקב ושולחת אותה אל Trace באמצעות מעקב OpenCensus Envoy.

  4. סוכן Logging מייצא את הנתונים האלה אל Cloud Logging API, כדי שהנתונים יהיו זמינים בממשק של Cloud Logging.

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

לפני שמסיימים את שלבי ההגדרה, צריך לוודא שבוצעו הפעולות הבאות:

  1. ממשק Traffic Director API מופעל ומתקיימות דרישות מוקדמות אחרות, כמו שמתואר במאמר הכנה להגדרה עם מכונות וירטואליות ועומסי עבודה ללא שרת proxy.
  2. ‫Cloud Trace API מופעל.
  3. לחשבון השירות שבו משתמשת המכונה הווירטואלית של Compute Engine מוגדרים התפקידים הבאים בניהול זהויות והרשאות גישה (IAM):
  4. כללי חומת האש מאפשרים תעבורה למכונה הווירטואלית שהגדרתם כחלק מההגדרה הזו.

הגדרת שירות ההדגמה ו-Cloud Service Mesh

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

  1. מפעילים מכונה וירטואלית ב-Compute Engine ומגדירים את שירות ה-HTTP במכונה הווירטואלית:

    curl -sSO https://storage.googleapis.com/traffic-director/demo/observability/setup_demo_service.sh
chmod 755 setup_demo_service.sh && ./setup_demo_service.sh

    הסקריפט setup_demo_service.sh יוצר תבנית של מכונה וירטואלית שמפעילה את apache2 כשמכונה וירטואלית מופעלת, וקבוצה מנוהלת של מכונות וירטואליות שמשתמשת בתבנית הזו. הסקריפט מפעיל מופע יחיד ללא הפעלה של שינוי גודל אוטומטי.

  2. משתמשים ב-Cloud Service Mesh כדי להגדיר ניתוב לשירות 10.10.10.10:

    curl -sSO https://storage.googleapis.com/traffic-director/demo/observability/setup_demo_trafficdirector.sh
chmod 755 setup_demo_trafficdirector.sh && ./setup_demo_trafficdirector.sh

    סקריפט setup_demo_trafficdirector.sh מגדיר את הפרמטרים הנדרשים לשירות המנוהל Cloud Service Mesh.

  3. מפעילים מכונה וירטואלית ב-Compute Engine שמריצה צרכן של שירות HTTP, עם שרת proxy מסוג קובץ עזר חיצוני שמותקן ומוגדר במכונה הווירטואלית. בפקודה הבאה, מחליפים את PROJECT_ID במזהה הפרויקט שאליו רוצים לשלוח את פרטי Trace. בדרך כלל זה אותו פרויקט Google Cloud שאליו שייכת המכונה הווירטואלית.

    curl -sSO https://storage.googleapis.com/traffic-director/demo/observability/setup_demo_client.sh
chmod 755 setup_demo_client.sh && ./setup_demo_client.sh PROJECT_ID

    הסקריפט setup_demo_client.sh יוצר מכונה וירטואלית ב-Compute Engine עם Envoy Proxy שהוגדר מראש לשימוש ב-Cloud Service Mesh.

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

  • משתני המטא-נתונים של צומת האתחול TRAFFICDIRECTOR_ACCESS_LOG_PATH ו-TRAFFICDIRECTOR_ENABLE_TRACING מאפשרים רישום ביומן ומעקב, כפי שמתואר במאמר הגדרת מאפייני אתחול של Envoy ל-Cloud Service Mesh.
  • הגדרת אתחול סטטית מאפשרת ייצוא של מידע ממעקבים אל Trace באמצעות OpenCensus.

אחרי שמריצים את הסקריפטים האלה, אפשר להיכנס למכונה הווירטואלית ולגשת לשירות ה-HTTP שזמין בכתובת 10.10.10.10:td-observability-demo-client

curl http://10.10.10.10

בשלב הזה, Envoy יוצר יומני גישה ופרטי מעקב. בקטע הבא מוסבר איך לייצא יומנים ופרטי מעקב.

הגדרת ייצוא של נתוני מעקב ל-Cloud Trace

הגדרת ה-bootstrap של Envoy שיצרתם כשמריצים את הסקריפט setup-demo-client.sh מספיקה כדי ליצור מידע על מעקב. כל שאר ההגדרות הן אופציונליות. כדי להגדיר פרמטרים נוספים, אפשר לעיין בדף ההגדרות של OpenCensus Envoy ולשנות את אפשרויות המעקב בהגדרות האתחול של Envoy.

אחרי ששולחים בקשת לדוגמה לשרת ההדגמה (curl 10.10.10.10), במסוף curl 10.10.10.10 עוברים לממשק Trace ‏(Trace > Trace list). Google Cloud מוצגת רשומת מעקב שמתאימה לבקשה שהגשתם.

מידע נוסף על השימוש ב-Trace זמין במסמכי התיעוד של Cloud Trace.

הגדרת ייצוא של יומני גישה ל-Logging

בשלב הזה, Envoy אמור לתעד את פרטי יומן הגישה בדיסק המקומי של המכונה הווירטואלית שבה הוא פועל. כדי לייצא את הרשומות האלה ל-Logging, צריך להתקין את סוכן Logging באופן מקומי. כדי לעשות זאת, צריך להתקין ולהגדיר את סוכן Logging.

התקנת סוכן Logging

מתקינים את סוכן Logging במכונה הווירטואלית שממנה מייצאים את פרטי הרישום ביומן. בהגדרה לדוגמה הזו, המכונה הווירטואלית היא td-observability-demo-vm.

curl -sSO https://dl.google.com/cloudagents/add-logging-agent-repo.sh
sudo bash add-logging-agent-repo.sh --also-install

מידע נוסף זמין במאמר איך מתקינים את סוכן Cloud Logging במכונה וירטואלית אחת.

הגדרת סוכן Logging

אפשר לייצא את היומנים של Envoy כטקסט לא מובנה או מובנה.

ייצוא יומני Envoy כטקסט לא מובנה

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

  1. מורידים ומתקינים את קובץ ההגדרות לייצוא לא מובנה של יומן הגישה של Envoy:

    curl -sSO https://storage.googleapis.com/traffic-director/demo/observability/envoy_access_fluentd_unstructured.conf
sudo cp envoy_access_fluentd_unstructured.conf /etc/google-fluentd/config.d/envoy_access.conf

  2. מפעילים מחדש את הסוכן. השינויים ייכנסו לתוקף כשהסוכן יופעל:

    sudo service google-fluentd restart

ייצוא יומני Envoy כטקסט מובנה

  1. מתקינים את הכלי Envoy access log parser מ-GitHub:

    sudo /opt/google-fluentd/embedded/bin/gem install fluent-plugin-envoy-parser

  2. מורידים ומתקינים את קובץ ההגדרות לייצוא יומני הגישה של Envoy בפורמט מובנה:

    curl -sSO https://storage.googleapis.com/traffic-director/demo/observability/envoy_access_fluentd_structured.conf
sudo cp envoy_access_fluentd_structured.conf /etc/google-fluentd/config.d/envoy_access.conf

  3. מפעילים מחדש את הסוכן. השינויים ייכנסו לתוקף כשהסוכן יופעל:

    sudo service google-fluentd restart

מידע נוסף זמין במאמר הגדרת סוכן Logging.

אימות ההגדרה

  1. מהמכונה הווירטואלית של שרת ה-Proxy מסוג Sidecar, יוצרים בקשה לשירות ההדגמה. הפעולה הזו יוצרת רשומה חדשה ביומן המקומי. לדוגמה, אפשר להריץ את הפקודה curl 10.10.10.10.
  2. במסוף Google Cloud , נכנסים אל Logging > Logs Explorer. בתפריט הנפתח, בוחרים בסוג היומן envoy-access. מוצגת רשומה ביומן של הבקשה האחרונה בפורמט לא מובנה או מובנה, בהתאם לסוג ההגדרה שבחרתם קודם.

פתרון בעיות

בקטעים הבאים מוסבר איך לפתור בעיות שונות שקשורות ליכולת הצפייה בנתונים באמצעות Envoy.

הגדרת מעקב בכמה פרויקטים

אם רוצים לעקוב אחרי בקשות ב-Envoys שנפרסו בכמה פרויקטים, צריך לשים לב לנקודות הבאות:

  • צריך להגדיר כל Envoy עם פרטי הכניסה של הפרויקט שבו הוא פועל.
  • כל Envoy שולח נתוני מעקב לפרויקט שמתאים לפרטי הכניסה שהוא פועל איתם.
  • תוכלו לראות טווחים של מעקב לבקשות בין פרויקטים אם האפליקציות שלכם שומרות על הערך של כותרת ה-HTTP‏ X-Cloud-Trace-Context כשמתבצעות בקשות.

תאימות של Trace לאפליקציות gRPC ללא שרת proxy

ההגדרה של כלי המעקב OpenCensus ב-Envoy מאפשרת לייצא נתוני מעקב מאפליקציות gRPC בלי שרת Proxy ומ-Envoy proxies, כך שהם יהיו תואמים באופן מלא בתוך Service mesh. כדי להבטיח תאימות, קובץ ה-bootstrap של Envoy צריך להגדיר את הקשר של המעקב כך שיכלול את פורמט המעקב GRPC_TRACE_BIN ב-OpenCensusConfig שלו, באופן הבא:

tracing:
  http:
      name: envoy.tracers.opencensus
      typed_config:
        "@type": type.googleapis.com/envoy.config.trace.v2.OpenCensusConfig
        stackdriver_exporter_enabled: "true"
        stackdriver_project_id: "PROJECT_ID"
        incoming_trace_context: ["CLOUD_TRACE_CONTEXT", "GRPC_TRACE_BIN"]
        outgoing_trace_context: ["CLOUD_TRACE_CONTEXT", "GRPC_TRACE_BIN"]

אם ההגדרה הושלמה אבל לא רואים עקבות או רשומות של רישום ביומן, צריך לבדוק את הדברים הבאים:

  1. לחשבונות השירות של המכונה הוירטואלית ב-Compute Engine יש את הרשאות ה-IAM הנדרשות ל-Trace ול-Logging, כפי שמפורט בדרישות המוקדמות. מידע על הרשאות IAM ב-Trace זמין במאמר בקרת גישה. מידע על הרשאות ב-Logging זמין במאמר בקרת גישה.
  2. לצורך רישום ביומן: מוודאים שאין שגיאות ב-/var/log/google-fluentd/google-fluentd.log.
  3. לרישום ביומן: מוודאים שערכים חדשים מופיעים בקובץ יומן הגישה המקומי כשמתבצעות בקשות.

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