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

במסמך הזה מפורטות הגדרות ברירת המחדל וההגדרות המותאמות אישית של 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 שניות, צריך לכלול מקלט מדדים בשם hostmetrics בקובץ config.yaml, שבו הערך של collection_interval מוגדר ל-30 שניות, כמו בדוגמה הבאה:

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

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

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

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

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

במעבדים ובמקבלי נתונים שיכולים לקלוט נתונים מובְנים (המקבלי 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 זמין במאמר בנושא מעקב אחרי אפליקציות של צד שלישי: 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>.*)$".

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

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

מדדים שמוזנים על ידי הנמענים

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

מקלט hostmetrics

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

קבוצה מדד
cpu עומס על ה-CPU במרווחי זמן של דקה
עומס על ה-CPU במרווחי זמן של 5 דקות
עומס על ה-CPU במרווחי זמן של 15 דקות
שימוש ב-CPU, עם תוויות של מספר ה-CPU ומצב ה-CPU
אחוז השימוש ב-CPU, עם תוויות של מספר ה-CPU ומצב ה-CPU
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 לכל תהליך, עם תוויות לשם התהליך + אחרים
שימוש ב-VM לכל תהליך, עם תוויות לשם התהליך + אחרים
מקלט 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 שתואמות לסוגי המדדים של סוכן תפעול שרוצים להחריג מהקבוצה שנאספת על ידי רכיב Receiver. לדוגמה:

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

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