אתם יכולים להשתמש בsink ביומן ב-Cloud Logging כדי לנתב רשומות ביומן מהפרויקט Google Cloud שלכם אל יעדים נתמכים לאחסון לטווח ארוך, לניתוח נתונים או לסטרימינג.
רכיב היעד מבצע פעולת כתיבה, ולכן צריך לאשר לו לכתוב ליעד. אם היעד הוא מאגר יומנים באותו פרויקט שבו נמצאת ההפניה, ההפניה מקבלת הרשאה באופן אוטומטי. בכל שאר היעדים, צריך לצרף את יעד הנתונים לחשבון שירות שקיבל את ההרשאות הנדרשות לכתיבת נתונים ביעד.
כשנדרש חשבון שירות, Cloud Logging יוצר ומנהל אותו באופן אוטומטי. עם זאת, יכול להיות שתצטרכו לשנות את ההרשאות שניתנו לחשבון השירות. לא חייבים להשתמש בחשבון השירות שנוצר על ידי Logging. אתם יכולים ליצור ולנהל חשבון שירות שמשמש את מאגרי הנתונים בכמה פרויקטים. מידע נוסף זמין במאמר הגדרת sink ביומן באמצעות חשבונות שירות בניהול משתמשים.
סקירה כללית
במאמר הזה מוסבר איך ליצור יעד לניקוז נתונים ואיך להגדיר את האפשרויות שמוצגות כשמשתמשים במסוף Google Cloud , ב-Google Cloud CLI או ב-API.
יעדים שייכים למשאב נתון: Google Cloud פרויקט, Google Cloud חשבון לחיוב, תיקייה או ארגון. כשמשאב מקבל רשומה ביומן, כל יעד במשאב מעבד את הרשומה ביומן. אם רשומה ביומן תואמת למסננים של מאגר היעד, היא מנותבת ליעד של מאגר היעד.
בדרך כלל, מאגרי מידע מפנים רק את רשומות היומן שמקורן במשאב. עם זאת, אפשר ליצור מאגרי נתונים מצטברים לתיקיות ולארגונים. יעדים כאלה מעבירים רשומות ביומן שמקורן בתיקייה או בארגון, ושמקורן במשאבי הצאצא שלהם. במסמך הזה לא מוסבר על מאגרי נתונים מצטברים. מידע נוסף מופיע במאמר סקירה כללית על מאגרי נתונים מצטברים.
כדי ליצור ולנהל יעד ליומנים, אפשר להשתמש במסוף Google Cloud , ב-Cloud Logging API וב-Google Cloud CLI. מומלץ להשתמש במסוף Google Cloud מהסיבות הבאות:
- אתם יכולים להגדיר יעדי יעד כחלק מהזרימה כדי ליצור יעד.
- אתם יכולים לראות תצוגה מקדימה של רשומות היומן שתואמות למסננים של יעד הנתונים.
- חלק משלבי ההרשאה פשוטים יותר.
מומלץ לבדוק את ההגדרה של sink ביומן כשמבצעים שינויים באחסון היומנים. לדוגמה, אם מוחקים את היעד של sink ביומן, צריך למחוק גם את sink ביומן התואם.
בקטע ניהול אובייקטים מסוג sink ביומן במסמך הזה מוסבר איך לראות את אובייקטים מסוג sink ביומן ולנהל אותם.
יעדים נתמכים
יעד של מאגר יכול להיות במשאב אחר מהמאגר. לדוגמה, אפשר להשתמש ב-sink ביומן כדי להעביר רשומות ביומן מפרויקט אחד לקטגוריה ביומן שמאוחסנת בפרויקט אחר.
היעדים הבאים נתמכים:
- פרויקטGoogle Cloud
בוחרים ביעד הזה כשרוצים שהיעדים של יומני הבקרה בפרויקט היעד ינתבו מחדש את רשומות היומן, או כשיוצרים יעד צבירה שחוסם את הרשומות. ה-log sinks בפרויקט היעד יכולים לנתב מחדש את רשומות היומן לכל יעד נתמך, למעט פרויקט.
מאגרי ה-sink ביומן שנוצרו על ידי המערכת בפרויקט היעד לא כוללים רשומות ביומן שמנותבות לקטגוריה ביומן
_Requiredבפרויקט המקור. לדוגמה, אם מעבירים יומנים של יומן פעילות אדמין לפרויקט אחר, גם_Requiredוגם_Defaultב-sink ביומן בפרויקט היעד לא יכללו את הרשומות ביומן האלה. כדי לאחסן את רשומות היומן האלה, בפרויקט היעד צריך לעדכן את_Defaultsink ביומן או ליצור sink ביומן בהתאמה אישית.
- קטגוריה ביומן
- בוחרים ביעד הזה כשרוצים לאחסן את נתוני היומן במשאבים שמנוהלים על ידי Cloud Logging. אפשר להציג ולנתח נתוני יומן שמאוחסנים בדלי יומנים באמצעות שירותים כמו Logs Explorer.
- נושא Pub/Sub
- בוחרים ביעד הזה כשרוצים לייצא את נתוני היומן מ-Google Cloud ואז להשתמש בשילוב עם צד שלישי. ערכי היומן מעוצבים כ-JSON ואז מנותבים לנושא Pub/Sub.
מגבלות על יעדים
בקטע הזה מתוארות מגבלות שספציפיות ליעדים:
- כשמגדירים יעד ל-sink, צריך לספק את הנתיב המלא ולהשתמש בנקודת הקצה הגלובלית של השירות.
אין תמיכה בנקודות קצה אזוריות של שירותים (REP), כמו
pubsub.LOCATION.rep.googleapis.com.
אי אפשר לנתב יומנים לנושא ב-Pub/Sub שמוגדרות בו הגבלות על נתונים במעבר. הרישום ביומן לא יכול להבטיח שבקשות פרסום מגיעות מאזור מותר, ולכן נגרמות
topic_region_not_allowedשגיאות בהגדרות ויומנים מושמטים.ההגבלות הבאות חלות כשהיעד של sink ביומן הוא Google Cloud פרויקט:
- יש הגבלה של קפיצה אחת.
_Requiredsink ביומן בפרויקט היעד מעביר רשומות ביומן אל_Requiredקטגוריה ביומן של הפרויקט אם הרשומות ביומן תואמות למסנן של sink ביומן ומקורן בפרויקט היעד._Defaultאובייקט ה-sink ביומן בפרויקט היעד מעביר רשומות ביומן שתואמות למסנן ההכללה שלו ולא תואמות לאף מסנן החרגה. ה-sink ביומן_Defaultלא כולל חלק מהרשומות ביומן. לדוגמה, יעד כזה לא מעביר רשומות ביומן של פעילות אדמין ואירועי מערכת. אפשר לשנות את היעד הזה.- רק מאגרי נתונים (sinks) מצטברים שנמצאים בהיררכיית המשאבים של רשומה ביומן מעבדים את הרשומה.
לדוגמה, נניח שיעד של sink ביומן בפרויקט
Aהוא פרויקטB. במקרה כזה, הכללים הבאים חלים:- בגלל מגבלת הדילוג האחד, מאגרי ה-sink ביומן בפרויקט
Bלא יכולים לנתב מחדש רשומות ביומן לפרויקט Google Cloud אחר. - בקטגוריית היומן
_Requiredשל פרויקטBנשמרים רק רשומות יומן שמקורן בפרויקטB. מאגר היומנים הזה לא מאחסן רשומות ביומן שמקורן במשאבים אחרים, כולל רשומות שמקורן בפרויקטA. - אם לפרויקט
AולפרויקטBיש היררכיות שונות של משאבים, רשומה ביומן ש-sink ביומן בפרויקטAמעביר לפרויקטBלא נשלחת ל-sinks המצטברים בהיררכיית המשאבים של פרויקטB. - אם לפרויקט
AולפרויקטBיש אותה היררכיית משאבים, רשומות היומן נשלחות למאגרי הנתונים המצטברים בהיררכיה הזו. אם רשומת יומן לא נחסמת על ידי יעד מצטבר, נתב היומנים שולח את הרשומה ליעדים בפרויקטA.
לפני שמתחילים
ההוראות במסמך הזה מתארות איך ליצור ולנהל מאגרי נתונים ברמתGoogle Cloud הפרויקט. אפשר להשתמש באותו תהליך כדי ליצור יעד שמעביר רשומות ביומן שמקורן בארגון, בתיקייה או בחשבון לחיוב.
כדי להתחיל, מבצעים את הפעולות הבאות:
-
מפעילים את Cloud Logging API, אם הוא עדיין לא מופעל.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה
serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים מוודאים ש Google Cloud הפרויקט מכיל רשומות ביומן שאפשר לראות בLogs Explorer.
-
כדי לקבל את ההרשאות שנדרשות ליצירה, לשינוי או למחיקה של יעד, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד כותב הגדרות של יומנים (
roles/logging.configWriter) בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
מידע על מתן תפקידי IAM מופיע במדריך בקרת הגישה בנושא Logging.
מוודאים שיש לכם משאב ביעד נתמך או שיש לכם אפשרות ליצור משאב כזה.
כדי להפנות רשומות ביומן ליעד, היעד צריך להתקיים לפני שיוצרים את מאגר הנתונים. אפשר ליצור את היעד בכלGoogle Cloud פרויקט בכל ארגון.
לפני שיוצרים יעד, חשוב לעיין במגבלות שחלות על היעד של הנתונים. מידע נוסף זמין בקטע מגבלות על יעדים במאמר הזה.
בוחרים את הממשק שבו רוצים להשתמש:
המסוף
כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.
gcloud
מתקינים את ה-CLI של Google Cloud ואז נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
gcloud initREST
כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.
מתקינים את ה-CLI של Google Cloud ואז נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.
מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .
יצירת יעד
בקטע הזה מוסבר איך ליצור יעד בפרויקט ב- Google Cloud .
אפשר ליצור עד 200 יעדים לכל Google Cloud פרויקט.
כדי לראות את המספר והנפח של רשומות היומן שמועברות, אפשר לעיין במדדים של logging.googleapis.com/exports/.
משתמשים בשפת השאילתות של רישום ביומן כדי ליצור ביטוי מסנן שתואם לרשומות ביומן שרוצים לכלול. אל תכללו מידע רגיש במסנני יעד. מסנני יעד נחשבים כנתוני שירות.
כששאילתה מכילה כמה הצהרות, אפשר לציין איך ההצהרות האלה מצורפות או להסתמך על Cloud Logging שמוסיף באופן מרומז את ההגבלה המצטרפת, AND, בין ההצהרות. לדוגמה,
נניח שבתיבת דו-שיח של שאילתה או מסנן יש שתי הצהרות,
resource.type = "gce_instance" ו-severity >= "ERROR".
השאילתה בפועל היא resource.type = "gce_instance" AND severity >= "ERROR".
Cloud Logging תומך בהגבלות דיסג'נקטיביות, OR, ובהגבלות קוניונקטיביות, AND. כשמשתמשים בהצהרות OR, מומלץ לקבץ את הסעיפים באמצעות סוגריים.
כדי ליצור יעד:
המסוף
-
במסוף Google Cloud , עוברים לדף Log Router:
אם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
בוחרים את Google Cloud הפרויקט שממנו מגיעים רשומות היומן שרוצים להפנות.
לדוגמה, אם רוצים להפנות את הרשומות ביומן Data Access מהפרויקט בשם
Project-Aלקטגוריית יומנים בפרויקט בשםProject-B, צריך לבחור באפשרותProject-A.לוחצים על יצירת יעד.
בחלונית פרטי יעד, מזינים את הפרטים הבאים:
שם יעד: מזינים מזהה ליעד. אחרי שיוצרים את יעד הנתונים, אי אפשר לשנות את השם שלו, אבל אפשר למחוק אותו וליצור יעד נתונים חדש.
תיאור של יעד הנתונים (אופציונלי): מתארים את המטרה או את תרחיש השימוש של יעד הנתונים.
בחלונית Sink destination, בוחרים את שירות היעד ואת היעד באמצעות התפריט Select sink service. מבצעים אחת מהפעולות הבאות:
כדי לנתב רשומות ביומן לשירות שנמצא באותו פרויקטGoogle Cloud , בוחרים באחת מהאפשרויות הבאות:
- קטגוריה ב-Cloud Logging: בוחרים או יוצרים קטגוריה ב-Logging.
- נושא Pub/Sub: בוחרים או יוצרים את הנושא לקבלת רשומות היומן שהועברו.
כדי להפנות רשומות ביומן לפרויקט אחר של Google Cloud , בוחרים באפשרות Google Cloud project, ואז מזינים את השם המלא של היעד:
logging.googleapis.com/projects/DESTINATION_PROJECT_IDכדי להעביר רשומות ביומן לשירות שנמצא בGoogle Cloud פרויקט אחר, צריך לבצע את הפעולות הבאות:
- בוחרים באפשרות משאב אחר.
- מזינים את השם המלא של היעד. מידע על התחביר מופיע במאמר פורמטים של נתיבי יעד.
מציינים את הרשומות ביומן שרוצים לכלול:
עוברים לחלונית Choose logs to include in sink (בחירת יומנים להכללה ב-sink).
בשדה מסנן הכללה, מזינים ביטוי מסנן שתואם לרשומות ביומן שרוצים לכלול. מידע על התחביר מופיע במאמר שפת שאילתות לרישום ביומן.
אם לא מגדירים מסנן, כל רשומות היומן מהמשאב שנבחר מנותבות ליעד.
לדוגמה, כדי להפנות את כל הרשומות ביומן הגישה לנתונים אל מאגר Logging, אפשר להשתמש במסנן הבא:
log_id("cloudaudit.googleapis.com/data_access") OR log_id("externalaudit.googleapis.com/data_access")האורך של מסנן מוגבל ל-20,000 תווים.
כדי לוודא שהזנתם את המסנן הנכון, בוחרים באפשרות תצוגה מקדימה של היומנים. הכלי Logs Explorer ייפתח בכרטיסייה חדשה עם מסנן שאוכלס מראש.
(אופציונלי) מגדירים מסנן החרגה כדי להסיר חלק מהרשומות ביומן:
עוברים לחלונית Choose logs to filter out of sink (בחירת יומנים להחרגה מהיעד).
בשדה Exclusion filter name (שם מסנן ההחרגה), מזינים שם.
בשדה Build an exclusion filter (יצירת מסנן החרגה), מזינים ביטוי מסנן שתואם לרשומות ביומן שרוצים להחריג. אפשר גם להשתמש בפונקציה
מסנן ההחרגה.sampleכדי לבחור חלק מהרשומות ביומן להחרגה.
אפשר ליצור עד 50 מסנני החרגה לכל יעד. שימו לב שאורך המסנן לא יכול להיות יותר מ-20,000 תווים.
לוחצים על יצירת יעד.
נותנים לחשבון השירות של יעד הניקוז הרשאה לכתוב רשומות יומן ליעד הניקוז. מידע נוסף זמין במאמר בנושא הגדרת הרשאות ליעדים.
gcloud
כדי ליצור יעד:
מריצים את הפקודה הבאה
gcloud logging sinks create:gcloud logging sinks create SINK_NAME SINK_DESTINATION
לפני שמריצים את הפקודה, מחליפים את המשתנים הבאים בערכים:
- SINK_NAME: השם של ה-sink ביומן. אי אפשר לשנות את השם של מאגר אחרי שיוצרים אותו.
SINK_DESTINATION: השירות או הפרויקט שאליהם רוצים לנתב את רשומות היומן. מגדירים את SINK_DESTINATION לנתיב המתאים, כפי שמתואר במאמר פורמטים של נתיב יעד.
לדוגמה, אם יעד ה-sink הוא נושא ב-Pub/Sub, אז SINK_DESTINATION ייראה כך:
pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
אפשר גם לספק את האפשרויות הבאות:
-
--log-filter: משתמשים באפשרות הזו כדי להגדיר מסנן שתואם לרשומות ביומן שרוצים לכלול במאגר. אם לא מציינים ערך למסנן ההכללה, המסנן הזה תואם לכל רשומות היומן. -
--exclusion: משתמשים באפשרות הזו כדי להגדיר מסנן החרגה לרשומות ביומן שלא רוצים שהיעד ינתב. אפשר גם להשתמש בפונקציהsampleכדי לבחור חלק מהרשומות ביומן להחרגה. אפשר לחזור על האפשרות הזו כמה פעמים, וליצור עד 50 מסנני החרגה לכל מאגר. --description: משתמשים באפשרות הזו כדי לתאר את המטרה או את תרחיש השימוש של מאגר הנתונים.
לדוגמה, כדי ליצור יעד לנתונים בדלי של Logging, הפקודה יכולה להיראות כך:
gcloud logging sinks create my-sink logging.googleapis.com/projects/myproject123/locations/global/buckets/my-bucket \ --log-filter='logName="projects/myproject123/logs/matched"' --description="My first sink"
מידע נוסף על יצירת יעדים באמצעות Google Cloud CLI זמין במאמר
gcloud logging sinks.אם התשובה של הפקודה מכילה מפתח JSON עם התווית
"writerIdentity", צריך להעניק לחשבון השירות של יעד הנתונים הרשאה לכתוב ליעד הנתונים. מידע נוסף זמין במאמר בנושא הגדרת הרשאות ליעדים.אין צורך להגדיר הרשאות ליעד אם התגובה לא מכילה מפתח JSON עם התווית
"writerIdentity".
REST
כדי ליצור sink ביומן ב Google Cloud פרויקט, משתמשים ב-
projects.sinks.createב-Logging API. באובייקטLogSink, מציינים את ערכי החובה המתאימים בגוף הבקשה של השיטה:name: מזהה של יעד. אחרי שיוצרים את יעד הנתונים, אי אפשר לשנות את השם שלו, אבל אפשר למחוק אותו וליצור יעד נתונים חדש.
destination: השירות והיעד שאליהם רוצים לנתב את רשומות היומן. כדי לנתב רשומות ביומן לפרויקט אחר, או ליעד שנמצא בפרויקט אחר, צריך להגדיר את השדהdestinationלנתיב המתאים, כמו שמתואר במאמר פורמטים של נתיבי יעד.לדוגמה, אם יעד ה-sink הוא נושא ב-Pub/Sub, אז
destinationייראה כך:pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID
באובייקט
LogSink, מציינים את המידע האופציונלי המתאים:-
filter: מגדירים את השדהfilterכך שיתאים לרשומות ביומן שרוצים לכלול ב-Sink. אם לא מגדירים מסנן, כל רשומות היומן מהפרויקטGoogle Cloud מועברות ליעד. חשוב לדעת שאורך המסנן לא יכול לחרוג מ-20,000 תווים. -
exclusions: מגדירים את השדה הזה כך שיתאים לרשומות ביומן שרוצים להחריג מהיעד. אפשר גם להשתמש בפונקציהsampleכדי לבחור חלק מהרשומות ביומן להחרגה. אפשר ליצור עד 50 מסנני החרגה לכל יעד. -
description: מגדירים את השדה הזה כדי לתאר את המטרה או את תרחיש השימוש של מאגר הנתונים.
-
מפעילים את הפקודה
projects.sinks.createכדי ליצור את יעד הנתונים.אם תגובה מה-API מכילה מפתח JSON עם התווית
"writerIdentity", צריך לתת לחשבון השירות של ה-sink הרשאת כתיבה ליעד ה-sink. מידע נוסף זמין במאמר בנושא הגדרת הרשאות ליעדים.אין צורך להגדיר הרשאות ליעד אם תגובה מה-API לא מכילה מפתח JSON עם התווית
"writerIdentity".
מידע נוסף על יצירת יעדים באמצעות Logging API מופיע במאמר LogSink.
אם אתם מקבלים התראות על שגיאות, כדאי לעיין במאמר בנושא פתרון בעיות שקשורות לניתוב ולמאגרי נתונים.
פורמטים של נתיב יעד
כשמגדירים יעד של sink, צריך לספק את הנתיב המלא ולהשתמש בנקודת הקצה הגלובלית של השירות.
אין תמיכה בנקודות קצה אזוריות של שירותים (REP), כמו pubsub.LOCATION.rep.googleapis.com.
בפורמטים הבאים של נתיבים, DESTINATION_PROJECT_ID מתייחס למזהה או למספר של פרויקט היעד:
קטגוריה ביומן ב-Cloud Logging:
logging.googleapis.com/projects/DESTINATION_PROJECT_ID/locations/LOCATION/buckets/BUCKET_NAME
פרויקט Google Cloud אחר:
logging.googleapis.com/projects/DESTINATION_PROJECT_ID
נושא Pub/Sub:
pubsub.googleapis.com/projects/DESTINATION_PROJECT_ID/topics/TOPIC_ID
הגדרת הרשאות ליעד
בקטע הזה מוסבר איך מעניקים ל-Logging את ההרשאות לניהול זהויות והרשאות גישה (IAM) כדי לכתוב רשומות ביומן ליעד של מאגר. רשימה מלאה של התפקידים וההרשאות ב-Logging זמינה במאמר בקרת גישה.
כשיוצרים יעד, Cloud Logging יוצר חשבון שירות משותף למשאב, אלא אם חשבון השירות הנדרש כבר קיים. יכול להיות שחשבון השירות קיים כי אותו חשבון שירות משמש לכל מאגרי הנתונים (sinks) במשאב הבסיסי. משאב יכול להיות Google Cloud פרויקט, ארגון, תיקייה או חשבון לחיוב.
זהות הכתיבה של יעד היא המזהה של חשבון השירות שמשויך ליעד הזה. לכל יעד יש זהות כתיבה, חוץ מיעדים שכותבים לקטגוריית יומנים באותו פרויקט שממנו מגיעים רשומות היומן. Google Cloud בהגדרה השנייה, לא נדרש חשבון שירות, ולכן השדה writer identity של יעד הסינכרון מופיע כ-None במסוף. ה-API והפקודות של Google Cloud CLI לא מדווחים על זהות הכותב.
ההוראות הבאות רלוונטיות לפרויקטים, לתיקיות, לארגונים ולחשבונות לחיוב:
המסוף
מוודאים שיש לכם גישת בעלים לGoogle Cloud פרויקט שמכיל את היעד. אם אין לכם גישת בעלים ליעד של ה-sink, צריך לבקש מ-Project Owner להוסיף את זהות הכתיבה כישות מורשית.
כדי לקבל את זהות הכותב של יעד הנתונים – כתובת אימייל – מיעד הנתונים החדש, מבצעים את הפעולות הבאות:
-
במסוף Google Cloud , עוברים לדף Log Router:
אם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
- בסרגל הכלים, בוחרים את הפרויקט שמכיל את היעד.
- בוחרים באפשרות more_vert תפריט ואז באפשרות הצגת פרטים של יעד. זהות הכותב מופיעה בחלונית Sink details.
-
אם הערך של השדה
writerIdentityמכיל כתובת אימייל, ממשיכים לשלב הבא. אם הערך הואNone, לא צריך להגדיר הרשאות יעד ל-sink.מעתיקים את זהות הכתיבה של יעד הנתונים ללוח.
כתובת האימייל מזהה את חשבון המשתמש. הקידומת
serviceAccount:מציינת את סוג החשבון.נותנים לחשבון המשתמש שצוין כזהות הכותב של יעד הסינכרון הרשאה לכתוב נתוני יומן ליעד:
-
נכנסים לדף IAM במסוף Google Cloud :
אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.
בסרגל הכלים, מוודאים שהפרויקט שנבחר הוא הפרויקט שבו מאוחסן היעד או שהוא יעד ה-sink. לדוגמה, אם היעד הוא קטגוריית יומנים, צריך לוודא שבסרגל הכלים מוצג הפרויקט שבו מאוחסנת קטגוריית היומנים.
לוחצים על Grant access.
מעניקים לחשבון המשתמש שצוין בזהות הכותב של יעד השינויים תפקיד IAM על סמך היעד של יעד השינויים ביומן:
- לכל היעדים, צריך להקצות את התפקיד Logs Writer (
roles/logging.logWriter). באופן ספציפי, לחשבון המשתמש צריכה להיות ההרשאהlogging.logEntries.route. - מקצים אחד מהתפקידים הבאים בהתאם ליעד:
- מאגר יומנים: צריך להעניק את התפקיד Logs Bucket Writer (
roles/logging.bucketWriter). - נושא Pub/Sub: צריך להעניק את התפקיד 'פרסום הודעות ב-Pub/Sub' (
roles/pubsub.publisher).
- מאגר יומנים: צריך להעניק את התפקיד Logs Bucket Writer (
- לכל היעדים, צריך להקצות את התפקיד Logs Writer (
-
gcloud
מוודאים שיש לכם גישת בעלים לGoogle Cloud פרויקט שמכיל את היעד. אם אין לכם גישת בעלים ליעד של ה-sink, צריך לבקש מ-Project Owner להוסיף את זהות הכתיבה כישות מורשית.
מקבלים את חשבון השירות מהשדה
writerIdentityביעד:gcloud logging sinks describe SINK_NAME
מוצאים את יעד הייצוא שרוצים לשנות את ההרשאות שלו. אם בפרטים של יעד הייצוא מופיעה שורה עם
writerIdentity, ממשיכים לשלב הבא. אם הפרטים לא כוללים שדהwriterIdentityלא צריך להגדיר הרשאות יעד ל-sink.הזהות של חשבון השירות עם הרשאת כתיבה נראית כך:
serviceAccount:service-123456789012@gcp-sa-logging.
מעניקים להרשאת הזהות של הכותב של יעד הנתונים הרשאה לכתוב נתוני יומן ליעד באמצעות הפקודה
gcloud projects add-iam-policy-binding.לפני שמשתמשים בפקודה הבאה, מחליפים את הערכים הבאים:
- PROJECT_ID: מזהה הפרויקט. מציינים את הפרויקט שבו מאוחסן יעד sink ביומן. אם היעד הוא פרויקט, מציינים את הפרויקט.
- PRINCIPAL: מזהה של חשבון המשתמש שרוצים להקצות לו את התפקיד. בדרך כלל, מזהי החשבונות הראשיים מופיעים בפורמט הבא:
PRINCIPAL-TYPE:ID. לדוגמה,. רשימה מלאה של הפורמטים האפשריים שלPRINCIPALמופיעה במאמר מזהים של חשבונות משתמשים. ROLE: תפקיד IAM. מקצים לזהות הכתיבה של ה-sink תפקיד IAM על סמך היעד של sink ביומן:
- לכל היעדים, צריך להקצות את התפקיד Logs Writer (
roles/logging.logWriter). באופן ספציפי, לחשבון המשתמש צריכה להיות ההרשאהlogging.logEntries.route. - מקצים אחד מהתפקידים הבאים בהתאם ליעד:
- מאגר יומנים: צריך להעניק את התפקיד Logs Bucket Writer (
roles/logging.bucketWriter). - נושא Pub/Sub: צריך להעניק את התפקיד 'פרסום הודעות ב-Pub/Sub' (
roles/pubsub.publisher).
- מאגר יומנים: צריך להעניק את התפקיד Logs Bucket Writer (
- לכל היעדים, צריך להקצות את התפקיד Logs Writer (
מריצים את הפקודה
gcloud projects add-iam-policy-binding:gcloud projects add-iam-policy-binding PROJECT_ID --member=PRINCIPAL --role=ROLE
REST
מומלץ להשתמש במסוף Google Cloud או ב-Google Cloud CLI כדי להקצות תפקיד לחשבון השירות.
דוגמאות לסינון
ריכזנו כאן כמה דוגמאות למסננים שימושיים במיוחד כשיוצרים מאגרי נתונים. במאמר דוגמאות לשאילתות אפשר למצוא דוגמאות נוספות שיכולות לעזור לכם ליצור מסנני הכללה ומסנני החרגה.
שחזור המסנן של _Default
אם ערכתם את המסנן של יעד _Default, יכול להיות שתרצו לשחזר את ההגדרות המקוריות של היעד הזה. כשיוצרים את אובייקט ה-sink _Default, הוא מוגדר עם מסנן ההכללה הבא ומסנן החרגה ריק:
NOT log_id("cloudaudit.googleapis.com/activity") AND NOT \
log_id("externalaudit.googleapis.com/activity") AND NOT \
log_id("cloudaudit.googleapis.com/system_event") AND NOT \
log_id("externalaudit.googleapis.com/system_event") AND NOT \
log_id("cloudaudit.googleapis.com/access_transparency") AND NOT \
log_id("externalaudit.googleapis.com/access_transparency")
החרגה של יומנים של קונטיינרים ו-Pods ב-Google Kubernetes Engine
כדי להחריג את רשומות היומן של קונטיינרים ו-Pods של Google Kubernetes Engine עבור מערכת GKE namespaces, משתמשים במסנן הבא:
resource.type = ("k8s_container" OR "k8s_pod")
resource.labels.namespace_name = (
"cnrm-system" OR
"config-management-system" OR
"gatekeeper-system" OR
"gke-connect" OR
"gke-system" OR
"istio-system" OR
"knative-serving" OR
"monitoring-system" OR
"kube-system")
כדי לא לכלול רשומות ביומן של צומת Google Kubernetes Engine עבור ערכי מערכת GKE log_id, משתמשים במסנן הבא:
resource.type = "k8s_node"
(log_id("container-runtime") OR
log_id("docker") OR
log_id("kube-container-runtime-monitor") OR
log_id("kube-logrotate") OR
log_id("kube-node-configuration") OR
log_id("kube-node-installation") OR
log_id("kubelet") OR
log_id("kubelet-monitor") OR
log_id("node-journal") OR
log_id("node-problem-detector"))
יכולת תמיכה
אמנם Cloud Logging מאפשר לכם להחריג רשומות ביומן ולמנוע את השמירה שלהן בקטגוריית יומנים, אבל כדאי לשקול לשמור רשומות ביומן שיכולות לעזור לכם לקבל תמיכה. השימוש ברשומות האלה ביומן יכול לעזור לכם לפתור בעיות ולזהות בעיות באפליקציות שלכם.
לדוגמה, רשומות ביומן המערכת של GKE שימושיות לפתרון בעיות באפליקציות ובאשכולות של GKE, כי הן נוצרות עבור אירועים שמתרחשים באשכול. רשומות היומן האלה יכולות לעזור לכם לקבוע אם קוד האפליקציה או אשכול GKE הבסיסי גורמים לשגיאה באפליקציה. יומני המערכת של GKE כוללים גם יומני ביקורת של Kubernetes שנוצרו על ידי רכיב שרת ה-API של Kubernetes, כולל שינויים שבוצעו באמצעות הפקודה kubectl ואירועים של Kubernetes.