הגדרת סוכן התפעול

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

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

    • משביתים את הרישום המובנה ביומן או את ההעברה של המדדים.

    • התאמה אישית של נתיב הקובץ של קובצי היומן שהסוכן אוסף מהם יומנים. מידע נוסף זמין במאמר בנושא מקבלים של יומנים.

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

    • שינוי קצב הדגימה של מדדים. מידע נוסף זמין במאמר בנושא מקבלים של מדדים.

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

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

    • איסוף מדדים ויומנים מאפליקציות נתמכות של צד שלישי. רשימת האפליקציות הנתמכות מופיעה במאמר בנושא מעקב אחרי אפליקציות של צד שלישי.

    • אפשר להשתמש במקלט Prometheus כדי לאסוף מדדים מותאמים אישית.

    • אפשר להשתמש במקלט OpenTelemetry Protocol (OTLP) כדי לאסוף מדדים מותאמים אישית ועקבות.

  • אתם רוצים ללמוד את הפרטים הטכניים של ההגדרות של Ops Agent.

מודל ההגדרה

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

אלה אבני הבניין של ההגדרה:

  • ‫receivers: הרכיב הזה מתאר את מה שנאסף על ידי הסוכן.
  • ‫processors: הרכיב הזה מתאר איך הסוכן יכול לשנות את המידע שנאסף.
  • ‫service: הרכיב הזה מקשר בין מקבלי נתונים ומעבדי נתונים כדי ליצור זרימות נתונים שנקראות צינורות. רכיב service מכיל רכיב pipelines שיכול להכיל כמה צינורות.

ההגדרה המובנית מורכבת מהרכיבים האלה, ואתם משתמשים באותם רכיבים כדי לשנות את ההגדרה המובנית.

הגדרה מובנית

ההגדרה המובנית של סוכן תפעול מגדירה את איסוף ברירת המחדל של יומנים ומדדים. בדוגמה הבאה מוצגת ההגדרה המובנית עבור Linux ועבור Windows:

Linux

כברירת מחדל, סוכן תפעול אוסף יומנים מבוססי-קובץ syslog ומדדים של המארח.

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

logging:
  receivers:
    syslog:
      type: files
      include_paths:
      - /var/log/messages
      - /var/log/syslog
  service:
    pipelines:
      default_pipeline:
        receivers: [syslog]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics]
        processors: [metrics_filter]

Windows

כברירת מחדל, סוכן תפעול אוסף יומני אירועים של Windows מהערוצים System,‏ Application ו-Security, וגם מדדים של המארח, מדדי IIS ומדדי SQL Server.

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

logging:
  receivers:
    windows_event_log:
      type: windows_event_log
      channels: [System, Application, Security]
  service:
    pipelines:
      default_pipeline:
        receivers: [windows_event_log]
metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 60s
    iis:
      type: iis
      collection_interval: 60s
    mssql:
      type: mssql
      collection_interval: 60s
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern: []
  service:
    pipelines:
      default_pipeline:
        receivers: [hostmetrics, iis, mssql]
        processors: [metrics_filter]

ההגדרות האלה מוסברות בפירוט במאמרים בנושא הגדרת רישום ביומן והגדרת מדדים.

הגדרה שנקבעה על ידי המשתמש

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

  • ב-Linux: /etc/google-cloud-ops-agent/config.yaml
  • ב-Windows: ‏ C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml

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

כדי לבטל את ההגדרה של מקלט, מעבד או צינור מובנים, צריך להגדיר אותם מחדש בקובץ config.yaml באמצעות הצהרה עם אותו מזהה. החל מגרסה 2.31.0 של סוכן תפעול, אפשר גם להגדיר את התכונה של החלפת יומנים של הסוכן. מידע נוסף זמין במאמר הגדרת החלפת יומנים ב-סוכן תפעול.

לדוגמה, ההגדרה המובנית של מדדים כוללת hostmetrics מקלט שמציין מרווח איסוף של 60 שניות. כדי לשנות את מרווח הזמן לאיסוף מדדים של המארח ל-30 שניות, צריך לכלול בקובץ config.yaml מקלט מדדים בשם hostmetrics שבו הערך של collection_interval מוגדר ל-30 שניות, כמו בדוגמה הבאה:

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 30s

דוגמאות נוספות לשינוי ההגדרות המובנות זמינות במאמרים הגדרת רישום ביומן והגדרת מדדים. אפשר גם להשבית את האיסוף של נתוני רישום או נתוני מדדים. השינויים האלה מתוארים בדוגמה logging service configurations וmetrics service configurations.

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

בנוסף, אפשר להגדיר את התכונה של החלפת יומנים (log rotation) של הסוכן באמצעות הקובץ הזה. מידע נוסף זמין במאמר הגדרת החלפת יומנים ב-Ops Agent.

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

הגדרות רישום

ההגדרה logging משתמשת במודל ההגדרה שתואר קודם:

  • ‫receivers: הרכיב הזה מתאר את הנתונים לאיסוף מקובצי יומן. הנתונים האלה ממופים למודל <timestamp, record>.
  • ‫processors: רכיב אופציונלי שמתאר איך הנציג יכול לשנות את המידע שנאסף.
  • ‫service: הרכיב הזה מקשר בין מקבלי נתונים ומעבדי נתונים כדי ליצור זרימות נתונים שנקראות צינורות. הרכיב service מכיל רכיב pipelines, שיכול לכלול כמה הגדרות של צינורות.

אפשר להשתמש בכל רכיב מקבל ובכל רכיב מעבד בכמה צינורות.

בקטעים הבאים מתואר כל אחד מהרכיבים האלה.

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

רישום נמענים

האלמנט receivers מכיל קבוצה של מקלטים, שכל אחד מהם מזוהה על ידי RECEIVER_ID. מקלט מתאר איך לאחזר את היומנים. לדוגמה, על ידי מעקב אחרי קבצים, על ידי שימוש ביציאת TCP או מיומן האירועים של Windows.

המבנה של נמעני הרישום ביומן

לכל נמען צריך להיות מזהה, RECEIVER_ID, והוא צריך לכלול רכיב type. הסוגים התקינים הם:

  • ‫files: איסוף יומנים על ידי מעקב אחרי קבצים בדיסק.
  • fluent_forward (סוכן תפעול בגרסה 2.12.0 ואילך): איסוף יומנים שנשלחים באמצעות פרוטוקול Fluent Forward דרך TCP.
  • ‫tcp (סוכן תפעול בגרסה 2.3.0 ואילך): איסוף יומנים בפורמט JSON על ידי האזנה ליציאת TCP.
  • ב-Linux בלבד:
    • ‫syslog: איסוף הודעות Syslog באמצעות TCP או UDP.
    • ‫systemd_journald (סוכן תפעול בגרסה 2.4.0 ואילך): איסוף יומנים של systemd journal משירות systemd-journald.
  • ‫Windows בלבד:
    • ‫windows_event_log: איסוף יומני אירועים של Windows באמצעות Windows Event Log API.
  • מקבלים של יומני אפליקציות של צד שלישי

המבנה של receivers נראה כך:

receivers:
  RECEIVER_ID:
    type: files
    ...
  RECEIVER_ID_2:
    type: syslog
    ...

בהתאם לערך של הרכיב type, יכולות להיות אפשרויות הגדרה אחרות, כמו האפשרויות הבאות:

  • ‫files receivers:

    • ‫include_paths: שדה חובה. רשימה של נתיבים במערכת הקבצים לקריאה על ידי מעקב אחרי כל קובץ. אפשר להשתמש בתווים הכלליים הבאים בנתיבים:

      • ‫*: תואם לכל רצף של תווים שאינם מפרידי נתיבים בתוך שם של ספרייה או קובץ יחיד.

        • דוגמה (Linux): /var/log/*.log תואם לכל הקבצים שמסתיימים ב-.log ישירות ב-/var/log/.
        • דוגמה (Linux): /var/log/app_*/server.log תואם ל-/var/log/app_1/server.log ול-/var/log/app_2/server.log, אבל לא תואם ל-/var/log/app_1/v2/server.log.

      • ‫** (globstar): מתאים לאפס או יותר ספריות בנתיב. התבנית הזו משמשת להתאמת קבצים בכמה רמות של ספריות (באופן רקורסיבי).

        • דוגמה (Linux): /var/log/**/*.log מתאים לכל קובץ שמסתיים ב-.log בתוך /var/log או בכל אחת מתתי-הספריות שלו בכל עומק (לדוגמה, /var/log/app1.log,/var/log/apache2/access.log).
        • דוגמה (Linux): כדי לאסוף יומנים ממופעים של אפליקציות שיוצרים ספריות משנה עם גרסאות או ספריות משנה ספציפיות למופע, כמו /opt/my-app/logs/instance-01/app.log,‏ /opt/my-app/logs/groupA/instance-02/app.log, אפשר להשתמש ב-globstar: /opt/my-app/logs/**/*.log

      רשימה של קובצי יומן נפוצים של אפליקציות Linux מופיעה במאמר קובצי יומן נפוצים של Linux.

    • ‫exclude_paths: אופציונלי. רשימה של תבניות של נתיבי מערכת קבצים שיוחרגו מהקבוצה שתואמת ל-include_paths.

    • ‫record_log_file_path: אופציונלי. אם הערך הוא true, הנתיב לקובץ הספציפי שממנו נלקחה רשומת היומן מופיע ברשומת היומן של הפלט כערך של התווית agent.googleapis.com/log_file_path. כשמשתמשים בתו כללי לחיפוש, מתועד רק הנתיב של הקובץ שממנו התקבל הרשומה.

    • ‫wildcard_refresh_interval: אופציונלי. המרווח שבו מתרחש רענון של נתיבי קבצים עם תו כללי לחיפוש ב-include_paths. הערך הוא משך זמן, לדוגמה, 30s, 2m. הנכס הזה יכול להיות שימושי כשקצב העברת הנתונים של היומנים גבוה, והקבצים מסתובבים מהר יותר מברירת המחדל של המרווח. אם לא מציינים את המרווח, ברירת המחדל היא 60 שניות.

  • ‫fluent_forward receivers:

    • ‫listen_host: אופציונלי. כתובת IP להאזנה. ערך ברירת המחדל הוא 127.0.0.1.

    • ‫listen_port: אופציונלי. יציאה להאזנה. ערך ברירת המחדל הוא 24224.

  • מקלט syslog (ל-Linux בלבד):

    • ‫transport_protocol: ערכים נתמכים: tcp, ‏ udp.

    • ‫listen_host: כתובת IP להאזנה.

    • ‫listen_port: יציאה להאזנה.

  • ‫tcp receivers:

    • ‫format: שדה חובה. פורמט היומן. ערך נתמך: json.

    • ‫listen_host: אופציונלי. כתובת IP להאזנה. ערך ברירת המחדל הוא 127.0.0.1.

    • ‫listen_port: אופציונלי. יציאה להאזנה. ערך ברירת המחדל הוא 5170.

  • מקלטים windows_event_log (ל-Windows בלבד):

    • ‫channels: שדה חובה. רשימה של ערוצים ביומן האירועים של Windows שמתוכם יתבצע קריאת יומנים.

    • ‫receiver_version: אופציונלי. קובעת באיזה Windows Event Log API להשתמש. הערכים הנתמכים הם 1 ו-2. ערך ברירת המחדל הוא 1.

    • ‫render_as_xml: אופציונלי. אם הערך הוא true, כל השדות ביומן האירועים, חוץ מjsonPayload.Message וjsonPayload.StringInserts, מוצגים כמסמך XML בשדה מחרוזת בשם jsonPayload.raw_xml. ערך ברירת המחדל הוא false. אי אפשר להגדיר את הערך true כאשר הערך של receiver_version הוא 1.

דוגמאות למקבלי יומנים

דוגמה למקלט files:

receivers:
  RECEIVER_ID:
    type: files

    include_paths: [/var/log/*.log]
    exclude_paths: [/var/log/not-this-one.log]
    record_log_file_path: true

דוגמה למקלט fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

דוגמה למקלט syslog (ב-Linux בלבד):

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

דוגמה למקלט tcp:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

דוגמה למקלט windows_event_log (Windows בלבד):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

דוגמה למקלט windows_event_log שמבטל את המקלט המובנה כדי להשתמש בגרסה 2:

receivers:
  windows_event_log:
    type: windows_event_log

    channels: [System,Application,Security]
    receiver_version: 2

דוגמה למקלט systemd_journald:

receivers:
  RECEIVER_ID:
    type: systemd_journald

שדות מיוחדים במטען ייעודי (payload) מובנה

למעבדים ולמקבלים שיכולים לקלוט נתונים מובְנים (מקבלים מסוג fluent_forward ו-tcp ומעבד מסוג parse_json), אפשר להגדיר שדות מיוחדים בקלט שימופו לשדות ספציפיים באובייקט LogEntry שהסוכן כותב ל-Logging API.

כשסוכן תפעול מקבל נתונים מובְנים מיומנים חיצוניים, הוא מציב שדות ברמה העליונה בשדה LogEntry's jsonPayload, אלא אם שם השדה מופיע בטבלה הבאה:

שדה הרשומה שדה LogEntry

אפשרות 1


"timestamp": {
  "seconds": CURRENT_SECONDS,
  "nanos": CURRENT_NANOS,
}

אפשרות 2


{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
 		timestamp
‫receiver_id (לא שדה של רשומה) logName
‫logging.googleapis.com/httpRequest (HttpRequest) httpRequest
logging.googleapis.com/severity (מחרוזת) severity
‫logging.googleapis.com/labels (struct of string:string) labels
logging.googleapis.com/operation (struct) operation
logging.googleapis.com/sourceLocation (struct) sourceLocation
logging.googleapis.com/trace (מחרוזת) trace
logging.googleapis.com/spanId (מחרוזת) spanId

כל השדות הנותרים של הרשומה המובנית נשארים חלק מהמבנה jsonPayload.

קובצי יומן נפוצים ב-Linux

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

בקשת הצטרפות קובצי יומן נפוצים
apache מידע על קובצי יומן של Apache זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: שרת אינטרנט של Apache.
cassandra מידע על קובצי יומן של Cassandra זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: Cassandra.
שף /var/log/chef-server/bookshelf/current
/var/log/chef-server/chef-expander/current
/var/log/chef-server/chef-pedant/http-traffic.log
/var/log/chef-server/chef-server-webui/current
/var/log/chef-server/chef-solr/current
/var/log/chef-server/erchef/current
/var/log/chef-server/erchef/erchef.log.1
/var/log/chef-server/nginx/access.log
/var/log/chef-server/nginx/error.log
/var/log/chef-server/nginx/rewrite-port-80.log
/var/log/chef-server/postgresql/current
gitlab /home/git/gitlab/log/application.log
/home/git/gitlab/log/githost.log
/home/git/gitlab/log/production.log
/home/git/gitlab/log/satellites.log
/home/git/gitlab/log/sidekiq.log
/home/git/gitlab/log/unicorn.stderr.log
/home/git/gitlab/log/unicorn.stdout.log
/home/git/gitlab-shell/gitlab-shell.log
jenkins /var/log/jenkins/jenkins.log
מזח /var/log/jetty/out.log
/var/log/jetty/*.request.log
/var/log/jetty/*.stderrout.log
joomla /var/www/joomla/logs/*.log
magento /var/www/magento/var/log/exception.log
/var/www/magento/var/log/system.log
/var/www/magento/var/report/*
mediawiki /var/log/mediawiki/*.log
memcached מידע על קובצי יומן של Memcached זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: Memcached.
mongodb מידע על קובצי יומן של MongoDB זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: MongoDB.
mysql מידע על קובצי יומן של MySQL זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: MySQL.
nginx מידע על קובצי יומן של nginx זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: nginx.
postgres מידע על קובצי יומן של PostgreSQL זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: PostgreSQL.
בובה /var/log/puppet/http.log
/var/log/puppet/masterhttp.log
puppet-enterprise /var/log/pe-activemq/activemq.log
/var/log/pe-activemq/wrapper.log
/var/log/pe-console-auth/auth.log
/var/log/pe-console-auth/cas_client.log
/var/log/pe-console-auth/cas.log
/var/log/pe-httpd/access.log
/var/log/pe-httpd/error.log
/var/log/pe-httpd/other_vhosts_access.log
/var/log/pe-httpd/puppetdashboard.access.log
/var/log/pe-httpd/puppetdashboard.error.log
/var/log/pe-httpd/puppetmasteraccess.log
/var/log/pe-mcollective/mcollective_audit.log
/var/log/pe-mcollective/mcollective.log
/var/log/pe-puppet-dashboard/certificate_manager.log
/var/log/pe-puppet-dashboard/event-inspector.log
/var/log/pe-puppet-dashboard/failed_reports.log
/var/log/pe-puppet-dashboard/live-management.log
/var/log/pe-puppet-dashboard/mcollective_client.log
/var/log/pe-puppet-dashboard/production.log
/var/log/pe-puppetdb/pe-puppetdb.log
/var/log/pe-puppet/masterhttp.log
/var/log/pe-puppet/rails.log
rabbitmq מידע על קובצי יומן של RabbitMQ זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: RabbitMQ.
redis מידע על קובצי יומן של Redis זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: Redis.
redmine /var/log/redmine/*.log
מלח /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr מידע על קובצי יומן של Apache Solr זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: Apache Solr.
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog
/var/log/messages
tomcat מידע על קובצי יומן של Apache Tomcat זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: Apache Tomcat.
מטפל בבעלי חיים מידע על קובצי יומן של Apache ZooKeeper זמין במאמר בנושא Monitoring third-party applications: Apache ZooKeeper (מעקב אחרי אפליקציות של צד שלישי: Apache ZooKeeper).

תוויות ברירת מחדל שנוספו

כברירת מחדל, היומנים יכולים להכיל את התוויות הבאות ב-LogEntry:

שדה ערך לדוגמה תיאור
labels."compute.googleapis.com/resource_name" test_vm השם של המכונה הווירטואלית שממנה נוצר היומן הזה. נכתב לכל היומנים.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access הערך של המקלט type שממנו נוצר היומן הזה, עם הקידומת agent.googleapis.com/. ההודעות נכתבות רק על ידי מקבלים משילובים של צד שלישי.

מעבדי רישום

הרכיב האופציונלי processors מכיל קבוצה של הוראות עיבוד, שכל אחת מהן מזוהה על ידי PROCESSOR_ID. מעבד מתאר איך לבצע מניפולציה במידע שנאסף על ידי מקלט.

לכל מעבד צריך להיות מזהה ייחודי, והוא צריך לכלול רכיב type. הסוגים התקינים הם:

  • ‫parse_json: ניתוח יומנים מובנים בפורמט JSON.
  • ‫parse_multiline: ניתוח יומנים מרובי שורות. (ב-Linux בלבד)
  • ‫parse_regex: ניתוח יומנים בפורמט טקסט באמצעות תבניות regex כדי להפוך אותם ליומנים מובנים בפורמט JSON.
  • ‫exclude_logs: החרגת יומנים שתואמים לכללים שצוינו (החל מגרסה 2.9.0).
  • ‫modify_fields: הגדרה או שינוי של שדות ברשומות ביומן (החל מגרסה 2.14.0).

המבנה של processors נראה כך:

processors:
  PROCESSOR_ID:
    type: parse_json
    ...
  PROCESSOR_ID_2:
    type: parse_regex
    ...

בהתאם לערך של רכיב type, יש אפשרויות הגדרה נוספות, כמו שמתואר בהמשך.

מעבד parse_json

מבנה ההגדרה

processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    <field name within jsonPayload>
    time_format: <strptime format string>

מעבד parse_json מנתח את קובץ ה-JSON של הקלט בשדה jsonPayload של LogEntry. אפשר לנתח חלקים אחרים של LogEntry על ידי הגדרה של שדות מיוחדים מסוימים ברמה העליונה.

  • ‫time_key: אופציונלי. אם רשומת היומן מספקת שדה עם חותמת זמן, האפשרות הזו מציינת את השם של השדה הזה. הערך שחולץ משמש להגדרת השדה timestamp של LogEntry שמתקבל, ומוסר ממטען הייעודי (payload).

    אם מציינים את האפשרות time_key, צריך לציין גם את הפרטים הבאים:

    • ‫time_format: חובה אם משתמשים ב-time_key. האפשרות הזו מציינת את הפורמט של השדה time_key כדי שהמערכת תוכל לזהות ולנתח אותו בצורה נכונה. פרטים על הפורמט זמינים במדריך strptime(3).
הגדרה לדוגמה
processors:
  PROCESSOR_ID:
    type: parse_json

    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

מעבד parse_multiline

מבנה ההגדרה

processors:
  PROCESSOR_ID:
    type: parse_multiline

    match_any:
    - type: <type of the exceptions>
      language: <language name>

  • ‫match_any: שדה חובה. רשימה של כלל אחד או יותר.

    • ‫type: שדה חובה. יש תמיכה רק בערך יחיד:

      • ‫language_exceptions: מאפשר למעבד לשרשר חריגים ל-LogEntry אחד, על סמך הערך של האפשרות language.

    • ‫language: שדה חובה. יש תמיכה רק בערך יחיד:

      • ‫java: שרשור של חריגים נפוצים ב-Java ל-LogEntry אחד.
      • ‫python: שרשור של חריגים נפוצים ב-Python ל-LogEntry אחד.
      • ‫go: שרשור של חריגים נפוצים ב-Go ל-LogEntry אחד.
הגדרה לדוגמה
logging:
  receivers:
    custom_file1:
      type: files
      include_paths:
      - /tmp/test-multiline28
  processors:
    parse_java_multiline:
      type: parse_multiline
      match_any:
      - type: language_exceptions
        language: java
    extract_structure:
      type: parse_regex
      field: message
      regex: "^(?<time>[\d-]*T[\d:.Z]*) (?<severity>[^ ]*) (?<file>[^ :]*):(?<line>[\d]*) - (?<message>(.|\\n)*)$"
      time_key: time
      time_format: "%Y-%m-%dT%H:%M:%S.%L"
    move_severity:
      type: modify_fields
      fields:
        severity:
          move_from: jsonPayload.severity
  service:
    pipelines:
      pipeline1:
        receivers: [custom_file1]
        processors: [parse_java_multiline, extract_structure, move_severity]

במעבד extract_structure, המשמעות של ההצהרה field: message היא שהביטוי הרגולרי מוחל על השדה jsonPayload.message של רשומת היומן. כברירת מחדל, מקבל הקבצים ממקם כל שורה בקובץ היומן ברשומה של יומן עם שדה מטען ייחודי שנקרא jsonPayload.message.

מעבד extract_structure ממקם את השדות שחולצו בשדות משנה של השדה LogEntry.jsonPayload. הצהרות אחרות בקובץ ה-YAML גורמות להזזה של שניים מהשדות שחולצו, time ו-severity. ההצהרה time_key: time שולפת את השדה LogEntry.jsonPayload.time, מנתחת את חותמת הזמן ואז מוסיפה את השדה LogEntry.timestamp. מעבד move_severity מעביר את שדה החומרה מהשדה LogEntry.jsonPayload.severity לשדה LogEntry.severity.

קובץ יומן לדוגמה:

2022-10-17T22:00:00.187512963Z ERROR HelloWorld:16 - javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)
    ... 27 common frames omitted

הסוכן מעביר כל שורה מקובץ היומן אל Cloud Logging בפורמט הבא:

{
  "insertId": "...",
  "jsonPayload": {
    "line": "16",
    "message": "javax.servlet.ServletException: Something bad happened\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)\n    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)\nCaused by: com.example.myproject.MyProjectServletException\n    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)\n    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)\n    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)\n    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)\n    ... 27 common frames omitted\n",
    "file": "HelloWorld"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "instance_id": "...",
      "project_id": "...",
      "zone": "..."
    }
  },
  "timestamp": "2022-10-17T22:00:00.187512963Z",
  "severity": "ERROR",
  "labels": {
    "compute.googleapis.com/resource_name": "..."
  },
  "logName": "projects/.../logs/custom_file",
  "receiveTimestamp": "2022-10-18T03:12:38.430364391Z"
}

מעבד parse_regex

מבנה ההגדרה

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex: <regular expression>

    time_key:    <field name within jsonPayload>
    time_format: <format string>

  • ‫time_key: אופציונלי. אם רשומת היומן מספקת שדה עם חותמת זמן, האפשרות הזו מציינת את השם של השדה הזה. הערך שחולץ משמש להגדרת השדה timestamp של LogEntry שמתקבל, ומוסר ממטען הייעודי (payload).

    אם מציינים את האפשרות time_key, צריך לציין גם את הפרטים הבאים:

    • ‫time_format: חובה אם משתמשים ב-time_key. האפשרות הזו מציינת את הפורמט של השדה time_key כדי שהמערכת תוכל לזהות ולנתח אותו בצורה נכונה. פרטים על הפורמט זמינים במדריך strptime(3).

  • ‫regex: שדה חובה. הביטוי הרגולרי לניתוח השדה. הביטוי צריך לכלול שמות של מפתחות לביטויי המשנה התואמים, לדוגמה, "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

    הטקסט שתואם לקבוצות לכידה עם שם ימוקם בשדות בשדה LogEntryשל jsonPayload. כדי להוסיף עוד מבנה ליומנים, משתמשים במעבד modify_fields.

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

הגדרה לדוגמה
processors:
  PROCESSOR_ID:
    type: parse_regex

    regex:       "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$"
    time_key:    time
    time_format: "%Y-%m-%dT%H:%M:%S.%L%Z"

מעבד exclude_logs

מבנה ההגדרות:

type: exclude_logs
match_any:
  - <filter>
  - <filter>

ההגדרה ברמה העליונה של המעבד הזה מכילה שדה יחיד, match_any, שמכיל רשימה של כללי סינון.

  • ‫match_any: שדה חובה. רשימה של כלל אחד או יותר. אם רשומה ביומן תואמת לכלל כלשהו, סוכן ה-Ops לא יקלוט את הרשומה הזו.

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

    • httpRequest
    • jsonPayload
    • labels
    • operation
    • severity
    • sourceLocation
    • trace
    • spanId

    הכלל הבא לדוגמה

    severity =~ "(DEBUG|INFO)"

    משתמש בביטוי רגולרי כדי להחריג את כל היומנים ברמה DEBUG וברמה INFO.

    הכללים פועלים לפי התחביר של שפת השאילתות של Cloud Logging, אבל הם תומכים רק בקבוצת משנה של התכונות ששפת השאילתות של Logging תומכת בהן:

    • אופרטורים להשוואה: =, ‏ !=, ‏ :, ‏ =~, ‏ !~. יש תמיכה רק בהשוואות של מחרוזות.
    • אופרטור ניווט: .. לדוגמה jsonPayload.message.
    • אופרטורים בוליאניים: AND, OR, NOT.
    • קיבוץ ביטויים באמצעות ( ).

הגדרה לדוגמה

processors:
  PROCESSOR_ID:
    type: exclude_logs
    match_any:
    - '(jsonPayload.message =~ "log spam 1" OR jsonPayload.message =~ "log spam 2") AND severity = "ERROR"'
    - 'jsonPayload.application = "foo" AND severity = "INFO"'

modify_fields מעבד

מעבד modify_fields מאפשר התאמה אישית של המבנה והתוכן של רשומות ביומן.

מבנה ההגדרה

type: modify_fields
fields:
  <destination field>:
    # Source
    move_from: <source field>
    copy_from: <source field>
    static_value: <string>
    
    # Mutation
    default_value: <string>
    map_values:
      <old value>: <new value>
    type: {integer|float}
    omit_if: <filter>

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

כל שמות השדות משתמשים בתחביר עם נקודות משפת השאילתות של Cloud Logging. המסננים משתמשים בשפת השאילתות של Cloud Logging.

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

אפשרויות מקור: אפשר לציין מקור אחד לכל היותר.

  • לא צוין מקור

    אם לא מציינים ערך מקור, הערך הקיים בשדה היעד ישתנה.

  • move_from: <source field>

    הערך מ-<source field> ישמש כמקור לשדה היעד. בנוסף, <source field> יוסר מהרשומה ביומן. אם שדה מקור מוזכר גם ב-move_from וגם ב-copy_from, שדה המקור עדיין יוסר.

  • copy_from: <source field>

    הערך מ-<source field> ישמש כמקור לשדה היעד. ‫<source field> לא יוסר מיומן הרישום, אלא אם הוא מוזכר גם בפעולה move_from או אם הוא ישונה בדרך אחרת.

  • static_value: <string>

    המחרוזת הסטטית <string> תשמש כמקור לשדה היעד.

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

  1. default_value: <string>

    אם שדה המקור לא קיים, ערך הפלט יוגדר כ-<string>. אם שדה המקור כבר קיים (גם אם הוא מכיל מחרוזת ריקה), הערך המקורי לא משתנה.

  2. map_values: <map>

    אם ערך הקלט תואם לאחד מהמפתחות ב-<map>, ערך הפלט יוחלף בערך התואם מהמיפוי.

  3. map_values_exclusive: {true|false}

    אם הערך של <source field> לא תואם לאף אחד מהמפתחות שצוינו בצמדי map_values, שדה היעד יבוטל בכוח אם map_values_exclusive הוא true, או יישאר ללא שינוי אם map_values_exclusive הוא false.

  4. type: {integer|float}

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

    שימו לב: Cloud Logging API משתמש ב-JSON ולכן הוא לא תומך במספר שלם מלא של 64 ביט. אם נדרש מספר שלם של 64 ביט (או יותר), צריך לאחסן אותו כמחרוזת ברשומה ביומן.

  5. omit_if: <filter>

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

    httpRequest.referer:
  move_from: jsonPayload.referer
  omit_if: httpRequest.referer = "-"

הגדרות לדוגמה

מעבד parse_json ימיר קובץ JSON שמכיל

{
  "http_status": "400",
  "path": "/index.html",
  "referer": "-"
}

לתוך מבנה LogEntry שנראה כך:

{
  "jsonPayload": {
    "http_status": "400",
    "path": "/index.html",
    "referer": "-"
  }
}

אפשר להפוך את זה באמצעות modify_fields לזה LogEntry:

{
  "httpRequest": {
    "status": 400,
    "requestUrl": "/index.html",
  }
}

באמצעות ההגדרה הזו של סוכן תפעול:

logging:
  receivers:
    in:
      type: files
      include_paths:
      - /var/log/http.json
  processors:
    parse_json:
      type: parse_json
    set_http_request:
      type: modify_fields
      fields:
        httpRequest.status:
          move_from: jsonPayload.http_status
          type: integer
        httpRequest.requestUrl:
          move_from: jsonPayload.path
        httpRequest.referer:
          move_from: jsonPayload.referer
          omit_if: jsonPayload.referer = "-"
  service:
    pipelines:
      pipeline:
        receivers: [in]
        processors: [parse_json, set_http_request]

ההגדרה הזו קוראת יומנים בפורמט JSON מ-/var/log/http.json ומאכלסת חלק מהמבנה httpRequest משדות ביומנים.

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

שירות רישום ביומן מתאים את רמת הפירוט של היומנים של Ops Agent, ומקשר בין מעבדי יומנים לבין מקבלי יומנים בצינורות. הקטע service כולל את הרכיבים הבאים:

  • log_level
  • pipelines

רמת הפירוט של הרישום ביומן

השדה log_level, שזמין ב-סוכן תפעול מגרסה 2.6.0 ואילך, מאפשר להתאים אישית את דרגת המלל של היומנים של מודול המשנה של סוכן תפעול לרישום ביומן. ברירת המחדל היא info. האפשרויות הזמינות הן: error, ‏ warn, ‏ info, ‏ debug, ‏ trace.

ההגדרה הבאה מתאימה אישית את רמת הפירוט של היומן עבור מודול המשנה של רישום ביומן ל-debug:

logging:
  service:
    log_level: debug

צינורות עיבוד נתונים לרישום ביומן

השדה pipelines יכול להכיל כמה מזהי צינורות והגדרות. כל ערך pipeline מורכב מהרכיבים הבאים:

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

  • ‫processors: אופציונלי. רשימה של מזהי מעבדים, כמו שמתואר במאמר בנושא מעבדי יומנים. הסדר של מזהי המעבדים ברשימה חשוב. כל רשומה מועברת דרך המעבדים לפי הסדר שמופיע ברשימה.

הגדרות לדוגמה של רישום ביומן service

הגדרות service כוללות את המבנה הבא:

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

כדי למנוע מהסוכן לאסוף ולשלוח רשומות של /var/log/message או של /var/log/syslog, צריך להגדיר מחדש את צינור ברירת המחדל עם רשימה ריקה של receivers וללא מעבדים. ההגדרה הזו לא מפסיקה את רכיב המשנה של רישום היומן של הסוכן, כי הסוכן צריך להיות מסוגל לאסוף יומנים עבור רכיב המשנה של המעקב. הגדרות הרישום ביומן הריקות נראות כך:

logging:
  service:
    pipelines:
      default_pipeline:
        receivers: []

ההגדרה הבאה service מגדירה צינור עיבוד נתונים עם המזהה custom_pipeline:

logging:
  service:
    pipelines:
      custom_pipeline:
        receivers:
        - RECEIVER_ID
        processors:
        - PROCESSOR_ID

הגדרות של מדדים

ההגדרה metrics משתמשת במודל ההגדרה שתואר קודם:

  • ‫receivers: רשימה של הגדרות של נמענים. receiver מתאר את המקור של המדדים. לדוגמה, מדדי מערכת כמו cpu או memory. אפשר לשתף את הרכיבים ברשימה הזו בין כמה צינורות.
  • ‫processors: רשימה של הגדרות מעבד. processor מתאר איך לשנות את המדדים שנאספים על ידי מקלט.
  • ‫service: מכיל קטע pipelines שהוא רשימה של הגדרות pipeline. pipeline מקשר בין רשימה של receivers ורשימה של processors כדי ליצור את זרימת הנתונים.

בקטעים הבאים מתואר כל אחד מהרכיבים האלה.

סוכן תפעול שולח מדדים ל-Cloud Monitoring. אי אפשר להגדיר אותו לייצוא מדדים לשירותים אחרים.

מקבלים של מדדים

הרכיב receivers מכיל קבוצה של הגדרות של מקלטים. מקבל מתאר מאיפה לאחזר את המדדים, כמו cpu ו-memory. אפשר לשתף מקלט בין כמה צינורות.

המבנה של מקבלי מדדים

לכל נמען צריך להיות מזהה, RECEIVER_ID, והוא צריך לכלול רכיב type. הסוגים המובנים התקינים הם:

  • hostmetrics
  • ‫iis (Windows בלבד)
  • ‫mssql (Windows בלבד)

הנמען יכול גם לציין את האפשרות collection_interval. הערך הוא משך זמן בפורמט של משך, לדוגמה, 30s או 2m. ערך ברירת המחדל הוא 60s.

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

שינוי מרווח האיסוף במקבלי המדדים

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

לדוגמה, המקלט הבא משנה את מרווח האיסוף של מדדי המארח (מזהה המקלט הוא hostmetrics) מברירת המחדל של 60 שניות ל-10 שניות:

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 10s

באותה שיטה אפשר גם לשנות את מרווח האיסוף של מקבלי המדדים של Windows iis ו-mssql.

מדדים שנקלטים על ידי הנמענים

למדדים שמוטמעים על ידי Ops Agent יש מזהים שמתחילים בדפוס הבא: agent.googleapis.com/GROUP. רכיב GROUP מזהה קבוצה של מדדים קשורים. הערכים שלו הם cpu, network ועוד.

מקלט hostmetrics

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

קבוצה מדד
cpu עומס על המעבד במרווחי זמן של דקה
עומס על המעבד במרווחי זמן של 5 דקות
עומס על המעבד במרווחי זמן של 15 דקות
שימוש במעבד, עם תוויות של מספר המעבד ומצב המעבד
אחוז השימוש במעבד, עם תוויות של מספר המעבד ומצב המעבד
disk ‫Disk bytes read, with label for device
‫ Disk bytes written, with label for device
‫ Disk I/O time, with label for device
‫ Disk weighted I/O time, with label for device
‫ Disk pending operations, with label for device
‫ Disk merged operations, with labels for device and direction
‫ Disk operations, with labels for device and direction
‫ Disk operation time, with labels for device and direction
‫ Disk usage, with labels for device and state
‫ Disk utilization, with labels for device and state
gpu
ל-Linux בלבד. מידע חשוב נוסף זמין במאמר בנושא מדדי gpu. 		מספר הבייטים הנוכחי של זיכרון ה-GPU בשימוש, לפי מצב
הכמות המקסימלית של זיכרון ה-GPU, בבייטים, שהוקצתה על ידי התהליך
אחוז הזמן במהלך משך החיים של התהליך שבו ליבה אחת או יותר פעלה ב-GPU
אחוז הזמן, מאז הדגימה האחרונה, שבו ה-GPU היה פעיל
interface
ב-Linux בלבד 		המספר הכולל של שגיאות ברשת
המספר הכולל של חבילות נתונים שנשלחו ברשת
המספר הכולל של בייטים שנשלחו ברשת
memory השימוש בזיכרון, עם תווית למצב (buffered, cached, free, slab, used)
אחוז השימוש בזיכרון, עם תווית למצב (buffered, cached, free, slab, used)
network מספר חיבורי TCP, עם תוויות של יציאה ומצב TCP
swap החלפת פעולות קלט/פלט, עם תווית לכיוון
החלפת בייטים בשימוש, עם תוויות למכשיר ולמצב
החלפת אחוז השימוש, עם תוויות למכשיר ולמצב
pagefile
Windows בלבד 		האחוז הנוכחי של קובץ ההחלפה שנעשה בו שימוש לפי מצב
processes מספר התהליכים, עם תווית למצב
מספר התהליכים המפוצלים
קריאת קלט/פלט בדיסק לכל תהליך, עם תוויות לשם התהליך + אחרים
כתיבת קלט/פלט בדיסק לכל תהליך, עם תוויות לשם התהליך + אחרים
שימוש ב-RSS לכל תהליך, עם תוויות לשם התהליך + אחרים
שימוש במכונה וירטואלית לכל תהליך, עם תוויות לשם התהליך + אחרים
מקלט iis (Windows בלבד)

ה-iis receiver (רק ב-Windows) קולט מדדים של קבוצת ה-iis. מידע נוסף זמין בדף מדדים של סוכנים.

קבוצה מדד
iis
Windows בלבד 		חיבורים פתוחים כרגע ל-IIS
בייטים ברשת שהועברו על ידי IIS
חיבורים שנפתחו ל-IIS
בקשות שנשלחו ל-IIS
מקלט mssql (Windows בלבד)

ה-mssql receiver (רק ב-Windows) קולט מדדים של קבוצת ה-mssql. מידע נוסף זמין בדף מדדים של סוכן תפעול.

קבוצה מדד
mssql
Windows בלבד 		חיבורים פתוחים כרגע לשרת SQL
סך העסקאות לשנייה בשרת SQL
עסקאות כתיבה לשנייה בשרת SQL

מעבדי מדדים

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

מעבד מדדים לדוגמה

בדוגמה הבאה מוצג המעבד exclude_metrics שסופק בתצורות המובנות. המעבד הזה מספק ערך ריק metrics_pattern ולכן הוא לא מחריג אף מדד.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

כדי להשבית את איסוף כל מדדי התהליך על ידי סוכן תפעול, מוסיפים את השורות הבאות לקובץ config.yaml:

metrics:
  processors:
    metrics_filter:
      type: exclude_metrics
      metrics_pattern:
      - agent.googleapis.com/processes/*

המדדים האלה לא נכללים באוסף המדדים של התהליך בmetrics_filter מעבד שחל על צינור ברירת המחדל בשירות metrics.

שירות המדדים

שירות המדדים מתאים אישית את דרגת המלל של היומנים של מודול המדדים של סוכן תפעול, ומקשר בין מקבלי מדדים לבין מעבדי מדדים כדי ליצור פייפליינים. הקטע service כולל שני רכיבים: log_level ו-pipelines.

רמת הפירוט של המדדים

‫log_level, שזמין בגרסאות 2.6.0 ואילך של סוכן תפעול, משמש להתאמה אישית של רמת הפירוט ביומנים של מודול המשנה של מדדי סוכן תפעול. ערך ברירת המחדל הוא info. האפשרויות הזמינות הן: error, ‏ warn, ‏ info, ‏ debug.

צינורות עיבוד נתונים של מדדים

בקטע service יש רכיב אחד, pipelines, שיכול להכיל כמה מזהים והגדרות של צינורות עיבוד נתונים. כל הגדרה של pipeline מורכבת מהרכיבים הבאים:

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

  • ‫processors: אופציונלי. רשימה של מזהי מעבדים, כמו שמתואר במאמר בנושא מעבדי מדדים. הסדר של מזהי המעבדים ברשימה חשוב. כל נקודת מדד עוברת דרך המעבדים לפי הסדר שמופיע ברשימה.

דוגמאות להגדרות של מדדים service

הגדרות service כוללות את המבנה הבא:

service:
  log_level: CUSTOM_LOG_LEVEL
  pipelines:
    PIPELINE_ID:
      receivers:  [...]
      processors: [...]
    PIPELINE_ID_2:
      receivers:  [...]
      processors: [...]

כדי להשבית את ההטמעה המובנית של מדדי המארח, צריך להגדיר מחדש את צינור ברירת המחדל עם רשימה ריקה של receivers וללא מעבדים. הגדרת המדדים המלאה נראית כך:

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers: []

בדוגמה הבאה מוצגת ההגדרה המובנית service עבור Windows:

metrics:
  service:
    pipelines:
      default_pipeline:
        receivers:
        - hostmetrics
        - iis
        - mssql
        processors:
        - metrics_filter

ההגדרה המותאמת אישית service הבאה משנה את רמת הפירוט של היומן של מודול המשנה metrics ל-debug:

metrics:
  service:
    log_level: debug

איסוף יומנים של עצמי

כברירת מחדל, היומנים העצמיים של Fluent Bit ב-Ops Agent נשלחים אל Cloud Logging. היומנים האלה יכולים לכלול הרבה מידע, והנפח הנוסף עשוי להגדיל את העלויות שלכם לשימוש ב-Cloud Logging.

אפשר להשבית את האיסוף של יומני הפעילות האלה החל מגרסה 2.44.0 של סוכן תפעול, באמצעות האפשרות default_self_log_file_collection.

כדי להשבית את האיסוף של יומני רישום עצמיים, מוסיפים קטע global לקובץ ההגדרות שצוין על ידי המשתמש ומגדירים את האפשרות default_self_log_file_collection לערך false:

logging:  ...
metrics:  ...
global:
  default_self_log_file_collection: false

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

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