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

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

משימות הגדרה נפוצות

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

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

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

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

  • ‫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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקבלים של רישום ביומן

הרכיב receivers מכיל קבוצה של נמענים, שכל אחד מהם מזוהה באמצעות RECEIVER_ID. מקלט מתאר איך לאחזר את היומנים, למשל באמצעות קובצי tail, באמצעות יציאת 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 מקלטים:

    • ‫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 מקלטים:

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

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

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

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

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

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

  • ‫tcp מקלטים:

    • ‫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

שדות מיוחדים במטענים מובְנים

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

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

שדה הרשומה השדה 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 (מבנה של 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
jetty /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, קראו את המאמר מעקב אחרי אפליקציות של צד שלישי: 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: ניתוח של יומנים בפורמט טקסט באמצעות דפוסי ביטויים רגולריים כדי להפוך אותם ליומנים מובְנים בפורמט 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>

המעבד (processor) של 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 של הרשומה ביומן. כברירת מחדל, מקלט הקבצים ממקם כל שורה בקובץ היומן ברשומת יומן עם שדה מטען ייעודי (payload) אחד שנקרא 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

ה-agent מעביר כל שורה מקובץ היומן ל-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>.*)$".

    הטקסט שתואם לקבוצות לחילוץ עם שם ימוקם בשדות בשדה jsonPayload של LogEntry. כדי להוסיף מבנה ליומנים, השתמשו במעבד 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 Agent לא מטמיע את הרשומה הזו.

    היומנים שמוטמעים על ידי סוכן התפעול תואמים למבנה של 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>

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

    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 משדות ביומנים.

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

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

  • log_level
  • pipelines

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

השדה log_level, שזמין בגרסאות 2.6.0 ואילך של Ops Agent, מאפשר להתאים אישית את דרגת המלל של היומנים של מודול המשנה לרישום ביומן של Ops Agent. ערך ברירת המחדל הוא 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

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

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

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

המקלט hostmetrics

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

קבוצה מדד
cpu עומס על המעבד (CPU) במרווחים של דקה אחת
עומס על המעבד (CPU) במרווחים של 5 דקות
עומס על המעבד (CPU) במרווחים של 15 דקות
שימוש במעבד (CPU), עם תוויות למספר המעבד ולמצב המעבד
אחוז השימוש במעבד (CPU), עם תוויות למספר המעבד ולמצב המעבד
disk בייטים שנקראו בדיסק, עם תווית למכשיר
בייטים שנכתבו בדיסק, עם תווית למכשיר
זמן קלט/פלט בדיסק, עם תווית למכשיר
זמן קלט/פלט משוקלל בדיסק, עם תווית למכשיר
פעולות בהמתנה בדיסק, עם תווית למכשיר
פעולות ממוזגות בדיסק, עם תוויות למכשיר ולכיוון
פעולות בדיסק, עם תוויות למכשיר ולכיוון
זמן פעולה בדיסק, עם תוויות למכשיר ולכיוון
שימוש בדיסק, עם תוויות למכשיר ולמצב
ניצול הדיסק, עם תוויות למכשיר ולמצב
gpu
ב-Linux בלבד. מידע חשוב נוסף זמין במאמר מידע על המדדים של gpu. 		מספר הבייטים הנוכחי של זיכרון ה-GPU שנעשה בהם שימוש, לפי מצב
הכמות המקסימלית של זיכרון ה-GPU, בבייטים, שהוקצתה על ידי התהליך
אחוז הזמן במהלך חיי התהליך שבו ליבה אחת או יותר פעלה ב-GPU
אחוז הזמן, מאז הדגימה האחרונה, שבו ה-GPU היה פעיל
interface
ב-Linux בלבד 		המספר הכולל של שגיאות בחיבור לרשת
המספר הכולל של חבילות הנתונים שנשלחו ברשת
המספר הכולל של בייטים שנשלחו ברשת
memory שימוש בזיכרון, עם תווית למצב (מאגר, מטמון, פנוי, slab, בשימוש)
אחוז השימוש בזיכרון, עם תווית למצב (מאגר, מטמון, פנוי, slab, בשימוש)
network מספר חיבורי ה-TCP, עם תוויות ליציאה ולמצב ה-TCP
swap פעולות קלט/פלט של החלפה, עם תווית לכיוון
בייטים של החלפה בשימוש, עם תוויות למכשיר ולמצב
אחוז החלפה בשימוש, עם תוויות למכשיר ולמצב
pagefile
Windows בלבד 		האחוז הנוכחי של קובץ ההחלפה (pagefile) בשימוש לפי מצב
processes מספר התהליכים, עם תווית למצב
מספר התהליכים המפוצלים
קלט/פלט של קריאה מהדיסק לכל תהליך, עם תוויות לשם התהליך + אחרים
קלט/פלט של כתיבה לדיסק לכל תהליך, עם תוויות לשם התהליך + אחרים
שימוש ב-RSS לכל תהליך, עם תוויות לשם התהליך + אחרים
שימוש במכונה וירטואלית לכל תהליך, עם תוויות לשם התהליך + אחרים
מקלט iis (Windows בלבד)

המקלט iis (ב-Windows בלבד) מטמיע מדדים של הקבוצה iis. למידע נוסף, קראו את הדף מדדי נציג.

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

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

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

מעבדי מדדים

הרכיב processor מכיל קבוצה של הגדרות מעבדים. מעבד (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 משנה את דרגת המלל של היומן במודול המשנה של המדדים ל-debug:

metrics:
  service:
    log_level: debug

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

כברירת מחדל, יומני ה-Fluent Bit של סוכן התפעול נשלחים ל-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 של Ops Agent, אפשר גם להגדיר את תכונת החלפת היומנים של הסוכן באמצעות קובצי התצורה. מידע נוסף זמין במאמר הגדרת החלפת יומנים ב-סוכן תפעול.