Mengonfigurasi Agen Operasional

Dokumen ini memberikan detail tentang konfigurasi default dan kustom Ops Agent. Baca dokumen ini jika salah satu hal berikut berlaku untuk Anda:

  • Anda ingin mengubah konfigurasi Agen Operasional untuk mencapai tujuan berikut:

  • Anda tertarik untuk mempelajari detail teknis konfigurasi Ops Agent.

Model konfigurasi

Agen Operasi menggunakan konfigurasi default bawaan; Anda tidak dapat langsung mengubah konfigurasi bawaan ini. Sebagai gantinya, Anda membuat file penggantian yang digabungkan dengan konfigurasi bawaan saat agen dimulai ulang.

Elemen penyusun konfigurasi adalah sebagai berikut:

  • receivers: Elemen ini menjelaskan apa yang dikumpulkan oleh agen.
  • processors: Elemen ini menjelaskan cara agen dapat mengubah informasi yang dikumpulkan.
  • service: Elemen ini menautkan penerima dan pemroses untuk membuat alur data, yang disebut pipeline. Elemen service berisi elemen pipelines, yang dapat berisi beberapa pipeline.

Konfigurasi bawaan terdiri dari elemen-elemen ini, dan Anda menggunakan elemen yang sama untuk mengganti konfigurasi bawaan tersebut.

Konfigurasi bawaan

Konfigurasi bawaan untuk Agen Operasional menentukan pengumpulan default untuk log dan metrik. Berikut ini menunjukkan konfigurasi bawaan untuk Linux dan Windows:

Linux

Secara default, Agen Operasi mengumpulkan log syslog berbasis file dan metrik host.

Untuk informasi selengkapnya tentang metrik yang dikumpulkan, lihat Metrik yang diserap oleh penerima.

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

Secara default, Agen Operasi mengumpulkan log peristiwa Windows dari saluran System, Application, dan Security, serta metrik host, metrik IIS, dan metrik SQL Server.

Untuk informasi selengkapnya tentang metrik yang dikumpulkan, lihat Metrik yang diserap oleh penerima.

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]

Konfigurasi ini dibahas secara lebih mendetail di Konfigurasi logging dan Konfigurasi metrik.

Konfigurasi yang ditentukan pengguna

Untuk mengganti konfigurasi bawaan, Anda perlu menambahkan elemen konfigurasi baru ke file konfigurasi pengguna. Masukkan konfigurasi Anda untuk Ops Agent dalam file berikut:

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

Setiap konfigurasi yang ditentukan pengguna digabungkan dengan konfigurasi bawaan saat agen dimulai ulang.

Untuk mengganti penerima, pemroses, atau pipeline bawaan, tentukan ulang dalam file config.yaml dengan mendeklarasikannya dengan ID yang sama. Mulai dari Ops Agent versi 2.31.0, Anda juga dapat mengonfigurasi fitur rotasi log agen; untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi rotasi log di Ops Agent.

Misalnya, konfigurasi bawaan untuk metrik menyertakan penerima hostmetrics yang menentukan interval pengumpulan 60 detik. Untuk mengubah interval pengumpulan metrik host menjadi 30 detik, sertakan penerima metrik yang disebut hostmetrics dalam file config.yaml yang menetapkan nilai collection_interval ke 30 detik, seperti yang ditunjukkan dalam contoh berikut:

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

Untuk contoh lain mengubah konfigurasi bawaan, lihat Konfigurasi logging dan Konfigurasi metrik. Anda juga dapat menonaktifkan pengumpulan data logging atau metrik. Perubahan ini dijelaskan dalam contoh konfigurasi service logging dan konfigurasi service metrik.

Anda dapat menggunakan file ini untuk mencegah agen mengumpulkan log mandiri dan mengirim log tersebut ke Cloud Logging. Untuk informasi selengkapnya, lihat Pengumpulan log mandiri.

Anda juga dapat mengonfigurasi fitur rotasi log agen menggunakan file ini; untuk informasi selengkapnya, lihat Mengonfigurasi rotasi log di Ops Agent.

Anda tidak dapat mengonfigurasi Agen Operasional untuk mengekspor log atau metrik ke layanan selain Cloud Logging dan Cloud Monitoring.

Konfigurasi logging

Konfigurasi logging menggunakan model konfigurasi yang dijelaskan sebelumnya:

  • receivers: Elemen ini menjelaskan data yang akan dikumpulkan dari file log; data ini dipetakan ke dalam model <stempel waktu, data>.
  • processors: Elemen opsional ini menjelaskan cara agen dapat mengubah informasi yang dikumpulkan.
  • service: Elemen ini menautkan penerima dan pemroses untuk membuat alur data, yang disebut pipeline. Elemen service berisi elemen pipelines, yang dapat menyertakan beberapa definisi pipeline.

Setiap penerima dan setiap pemroses dapat digunakan di beberapa pipeline.

Bagian berikut menjelaskan setiap elemen ini.

Agen Operasional mengirimkan log ke Cloud Logging. Anda tidak dapat mengonfigurasinya untuk mengekspor log ke layanan lain. Namun, Anda dapat mengonfigurasi Cloud Logging untuk mengekspor log; untuk mengetahui informasi selengkapnya, lihat Merutekan log ke tujuan yang didukung.

Penerima logging

Elemen receivers berisi kumpulan penerima, yang masing-masing diidentifikasi oleh RECEIVER_ID. Penerima menjelaskan cara mengambil log; misalnya, dengan melacak file, menggunakan port TCP, atau dari Log Aktivitas Windows.

Struktur penerima logging

Setiap penerima harus memiliki ID, RECEIVER_ID, dan menyertakan elemen type. Jenis yang valid adalah:

  • files: Mengumpulkan log dengan melacak file di disk.
  • fluent_forward (Agen Operasional versi 2.12.0 dan yang lebih baru): mengumpulkan log yang dikirim melalui protokol Fluent Forward melalui TCP.
  • tcp (Ops Agent versi 2.3.0 dan yang lebih baru): Kumpulkan log dalam format JSON dengan memproses port TCP.
  • Khusus Linux:
    • syslog: Mengumpulkan pesan Syslog melalui TCP atau UDP.
    • systemd_journald (Ops Agent versi 2.4.0 dan yang lebih baru): Mengumpulkan log jurnal systemd dari layanan systemd-journald.
  • Khusus Windows:
    • windows_event_log: Mengumpulkan Log Peristiwa Windows menggunakan Windows Event Log API.
  • Penerima log aplikasi pihak ketiga

Struktur receivers terlihat seperti berikut:

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

Bergantung pada nilai elemen type, mungkin ada opsi konfigurasi lainnya, seperti berikut:

  • Penerima files:

    • include_paths: Wajib diisi. Daftar jalur sistem file yang akan dibaca dengan mengikuti setiap file. Karakter pengganti (*) dapat digunakan dalam jalur; misalnya, /var/log/*.log (Linux) atau C:\logs\*.log (Windows).

      Untuk mengetahui daftar file log aplikasi Linux umum, lihat File log Linux umum.

    • exclude_paths: Opsional. Daftar pola jalur sistem file yang akan dikecualikan dari kumpulan yang dicocokkan oleh include_paths.

    • record_log_file_path: Opsional. Jika ditetapkan ke true, jalur ke file tertentu tempat data log diperoleh akan muncul di entri log output sebagai nilai label agent.googleapis.com/log_file_path. Saat menggunakan karakter pengganti, hanya jalur file tempat data diperoleh yang dicatat.

    • wildcard_refresh_interval: Opsional. Interval saat jalur file karakter pengganti di include_paths diperbarui. Diberikan sebagai durasi waktu, misalnya, 30s, 2m. Properti ini mungkin berguna dalam throughput logging yang tinggi, dengan file log dirotasi lebih cepat daripada interval default. Jika tidak ditentukan, interval defaultnya adalah 60 detik.

  • Penerima fluent_forward:

    • listen_host: Opsional. Alamat IP yang akan diproses. Nilai defaultnya adalah 127.0.0.1.

    • listen_port: Opsional. Port yang akan diproses. Nilai defaultnya adalah 24224.

  • Penerima syslog (khusus Linux):

    • transport_protocol: Nilai yang didukung: tcp, udp.

    • listen_host: Alamat IP yang akan diproses.

    • listen_port: Port yang akan diproses.

  • Penerima tcp:

    • format: Wajib diisi. Format log. Nilai yang didukung: json.

    • listen_host: Opsional. Alamat IP yang akan diproses. Nilai defaultnya adalah 127.0.0.1.

    • listen_port: Opsional. Port yang akan diproses. Nilai defaultnya adalah 5170.

  • Penerima windows_event_log (khusus Windows):

    • channels: Wajib diisi. Daftar saluran Log Aktivitas Windows tempat log dibaca.

    • receiver_version: Opsional. Mengontrol Windows Event Log API yang akan digunakan. Nilai yang didukung adalah 1 dan 2. Nilai defaultnya adalah 1.

    • render_as_xml: Opsional. Jika ditetapkan ke true, semua kolom Log Aktivitas, kecuali jsonPayload.Message dan jsonPayload.StringInserts, akan dirender sebagai dokumen XML di kolom string bernama jsonPayload.raw_xml. Nilai defaultnya adalah false. Ini tidak dapat ditetapkan ke true jika receiver_version adalah 1.

Contoh penerima logging

Contoh penerima files:

receivers:
  RECEIVER_ID:
    type: files

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

Contoh penerima fluent_forward:

receivers:
  RECEIVER_ID:
    type: fluent_forward

    listen_host: 127.0.0.1
    listen_port: 24224

Contoh penerima syslog (khusus Linux):

receivers:
  RECEIVER_ID:
    type: syslog

    transport_protocol: tcp
    listen_host: 0.0.0.0
    listen_port: 5140

Contoh penerima tcp:

receivers:
  RECEIVER_ID:
    type: tcp

    format: json
    listen_host: 127.0.0.1
    listen_port: 5170

Contoh penerima windows_event_log (khusus Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Contoh penerima windows_event_log yang mengganti penerima bawaan untuk menggunakan versi 2:

receivers:
  windows_event_log:
    type: windows_event_log

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

Contoh penerima systemd_journald:

receivers:
  RECEIVER_ID:
    type: systemd_journald

Kolom khusus dalam payload terstruktur

Untuk pemroses dan penerima yang dapat menyerap data terstruktur (penerima fluent_forward dan tcp serta pemroses parse_json), Anda dapat menetapkan kolom khusus dalam input yang akan dipetakan ke kolom tertentu dalam objek LogEntry yang ditulis agen ke Logging API.

Saat menerima data log terstruktur eksternal, Ops Agent akan menempatkan kolom tingkat teratas ke kolom jsonPayload LogEntry, kecuali jika nama kolom tercantum dalam tabel berikut:

Kolom data Kolom LogEntry

Opsi 1


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

Opsi 2


{
  "timestampSeconds": CURRENT_SECONDS,
  "timestampNanos": CURRENT_NANOS,
}
 		timestamp
receiver_id (bukan kolom data) logName
logging.googleapis.com/httpRequest (HttpRequest) httpRequest
logging.googleapis.com/severity (string) 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 (string) trace
logging.googleapis.com/spanId (string) spanId

Setiap kolom data terstruktur yang tersisa tetap menjadi bagian dari struktur jsonPayload.

File log Linux umum

Tabel berikut mencantumkan file log umum untuk aplikasi Linux yang sering digunakan:

Aplikasi File log umum
apache Untuk informasi tentang file log Apache, lihat Memantau aplikasi pihak ketiga: Server Web Apache.
cassandra Untuk mengetahui informasi tentang file log Cassandra, lihat Memantau aplikasi pihak ketiga: Cassandra.
koki /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 Untuk mengetahui informasi tentang file log Memcached, lihat Memantau aplikasi pihak ketiga: Memcached.
mongodb Untuk informasi tentang file log MongoDB, lihat Memantau aplikasi pihak ketiga: MongoDB.
mysql Untuk informasi tentang file log MySQL, lihat Memantau aplikasi pihak ketiga: MySQL.
nginx Untuk informasi tentang file log nginx, lihat Memantau aplikasi pihak ketiga: nginx.
postgres Untuk informasi tentang file log PostgreSQL, lihat Memantau aplikasi pihak ketiga: PostgreSQL.
boneka /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 Untuk mengetahui informasi tentang file log RabbitMQ, lihat Memantau aplikasi pihak ketiga: RabbitMQ.
redis Untuk informasi tentang file log Redis, lihat Memantau aplikasi pihak ketiga: Redis.
redmine /var/log/redmine/*.log
garam /var/log/salt/key
/var/log/salt/master
/var/log/salt/minion
/var/log/salt/syndic.loc
solr Untuk informasi tentang file log Apache Solr, lihat Memantau aplikasi pihak ketiga: Apache Solr.
sugarcrm /var/www/*/sugarcrm.log
syslog /var/log/syslog
/var/log/messages
tomcat Untuk informasi tentang file log Apache Tomcat, lihat Memantau aplikasi pihak ketiga: Apache Tomcat.
zookeeper Untuk informasi tentang file log Apache ZooKeeper, lihat Memantau aplikasi pihak ketiga: Apache ZooKeeper.

Label default yang diserap

Log dapat berisi label berikut secara default di LogEntry:

Kolom Nilai Contoh Deskripsi
labels."compute.googleapis.com/resource_name" test_vm Nama virtual machine tempat log ini berasal. Ditulis untuk semua log.
labels."logging.googleapis.com/instrumentation_source" agent.googleapis.com/apache_access Nilai penerima type tempat log berasal, diawali dengan agent.googleapis.com/. Hanya ditulis oleh penerima dari integrasi pihak ketiga.

Pemroses logging

Elemen processors opsional berisi kumpulan perintah pemrosesan, yang masing-masing diidentifikasi oleh PROCESSOR_ID. Prosesor menjelaskan cara memanipulasi informasi yang dikumpulkan oleh penerima.

Setiap pemroses harus memiliki ID unik dan menyertakan elemen type. Jenis yang valid adalah:

  • parse_json: Mengurai log terstruktur berformat JSON.
  • parse_multiline: Mengurai log multibaris. (Khusus Linux)
  • parse_regex: Mengurai log berformat teks melalui pola ekspresi reguler untuk mengubahnya menjadi log terstruktur berformat JSON.
  • exclude_logs: Mengecualikan log yang cocok dengan aturan yang ditentukan (mulai dari 2.9.0).
  • modify_fields: Menetapkan/mengubah kolom dalam entri log (mulai versi 2.14.0).

Struktur processors terlihat seperti berikut:

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

Bergantung pada nilai elemen type, ada opsi konfigurasi lainnya, sebagai berikut.

Prosesor parse_json

Struktur konfigurasi

processors:
  PROCESSOR_ID:
    type: parse_json

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

Prosesor parse_json mengurai JSON input ke dalam kolom jsonPayload dari LogEntry. Bagian lain dari LogEntry dapat diuraikan dengan menetapkan kolom tingkat teratas khusus tertentu.

  • time_key: Opsional. Jika entri log menyediakan kolom dengan stempel waktu, opsi ini menentukan nama kolom tersebut. Nilai yang diekstrak digunakan untuk menetapkan kolom timestamp dari LogEntry yang dihasilkan dan dihapus dari payload.

    Jika opsi time_key ditentukan, Anda juga harus menentukan hal berikut:

    • time_format: Wajib ada jika time_key digunakan. Opsi ini menentukan format kolom time_key sehingga dapat dikenali dan dianalisis dengan benar. Untuk mengetahui detail formatnya, lihat panduan strptime(3).
Contoh konfigurasi
processors:
  PROCESSOR_ID:
    type: parse_json

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

Prosesor parse_multiline

Struktur konfigurasi

processors:
  PROCESSOR_ID:
    type: parse_multiline

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

  • match_any: Wajib diisi. Daftar satu atau beberapa aturan.

    • type: Wajib diisi. Hanya satu nilai yang didukung:

      • language_exceptions: Memungkinkan prosesor menyambungkan pengecualian menjadi satu LogEntry, berdasarkan nilai opsi language.

    • language: Wajib diisi. Hanya satu nilai yang didukung:

      • java: Menggabungkan pengecualian Java umum menjadi satu LogEntry.
      • python: Menggabungkan pengecualian Python umum menjadi satu LogEntry.
      • go: Menggabungkan pengecualian Go umum menjadi satu LogEntry.
Contoh konfigurasi
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]

Jika Anda menggunakan konfigurasi sebelumnya dan memiliki file log dengan konten berikut:

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

lalu, agen akan menyerap log ke Cloud Logging dalam format berikut:

{
  "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"
}

Prosesor parse_regex

Struktur konfigurasi

processors:
  PROCESSOR_ID:
    type: parse_regex

    regex: <regular expression>

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

  • time_key: Opsional. Jika entri log menyediakan kolom dengan stempel waktu, opsi ini menentukan nama kolom tersebut. Nilai yang diekstrak digunakan untuk menetapkan kolom timestamp dari LogEntry yang dihasilkan dan dihapus dari payload.

    Jika opsi time_key ditentukan, Anda juga harus menentukan hal berikut:

    • time_format: Wajib ada jika time_key digunakan. Opsi ini menentukan format kolom time_key sehingga dapat dikenali dan dianalisis dengan benar. Untuk mengetahui detail formatnya, lihat panduan strptime(3).

  • regex: Wajib diisi. Ekspresi reguler untuk mengurai kolom. Ekspresi harus menyertakan nama kunci untuk subekspresi yang cocok; misalnya, "^(?<time>[^ ]*) (?<severity>[^ ]*) (?<msg>.*)$".

    Teks yang cocok dengan grup pengambilan bernama akan ditempatkan ke dalam kolom di kolom jsonPayload LogEntry. Untuk menambahkan struktur tambahan ke log, gunakan pemroses modify_fields.

    Untuk serangkaian ekspresi reguler guna mengekstrak informasi dari file log aplikasi Linux umum, lihat File log Linux umum.

Contoh konfigurasi
processors:
  PROCESSOR_ID:
    type: parse_regex

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

Prosesor exclude_logs

Struktur konfigurasi:

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

Konfigurasi tingkat atas untuk pemroses ini berisi satu kolom, match_any, yang berisi daftar aturan filter.

  • match_any: Wajib diisi. Daftar satu atau beberapa aturan. Jika entri log cocok dengan aturan apa pun, Ops Agent tidak akan menyerap entri tersebut.

    Log yang diserap oleh Agen Operasi mengikuti struktur LogEntry. Nama kolom peka huruf besar/kecil. Anda hanya dapat menentukan aturan berdasarkan kolom berikut dan subkolomnya:

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

    Contoh aturan berikut

    severity =~ "(DEBUG|INFO)"

    menggunakan ekspresi reguler untuk mengecualikan semua log level DEBUG dan INFO.

    Aturan mengikuti sintaksis bahasa kueri Cloud Logging, tetapi hanya mendukung sebagian fitur yang didukung bahasa kueri Logging:

    • Operator perbandingan: =, !=, :, =~, !~. Hanya perbandingan string yang didukung.
    • Operator navigasi: .. Contohnya, jsonPayload.message.
    • Operator Boolean: AND, OR, NOT.
    • Mengelompokkan ekspresi dengan ( ).

Contoh konfigurasi

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"'

Prosesor modify_fields

Prosesor modify_fields memungkinkan penyesuaian struktur dan konten entri log.

Struktur konfigurasi

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>

Konfigurasi tingkat atas untuk pemroses ini berisi satu kolom, fields, yang berisi peta nama kolom output dan terjemahan yang sesuai. Untuk setiap kolom output, sumber opsional dan nol atau beberapa operasi mutasi diterapkan.

Semua nama kolom menggunakan sintaksis yang dipisahkan titik dari bahasa kueri Cloud Logging. Filter menggunakan bahasa kueri Cloud Logging.

Semua transformasi diterapkan secara paralel, yang berarti sumber dan filter beroperasi pada entri log input asli sehingga tidak dapat mereferensikan nilai baru dari kolom lain yang diubah oleh prosesor yang sama.

Opsi sumber: Maksimal satu sumber yang ditentukan diizinkan.

  • Sumber tidak ditentukan

    Jika tidak ada nilai sumber yang ditentukan, nilai yang ada di kolom tujuan akan diubah.

  • move_from: <source field>

    Nilai dari <source field> akan digunakan sebagai sumber untuk kolom tujuan. Selain itu, <source field> akan dihapus dari entri log. Jika kolom sumber direferensikan oleh move_from dan copy_from, kolom sumber akan tetap dihapus.

  • copy_from: <source field>

    Nilai dari <source field> akan digunakan sebagai sumber untuk kolom tujuan. <source field> tidak akan dihapus dari entri log kecuali jika juga dirujuk oleh operasi move_from atau diubah.

  • static_value: <string>

    String statis <string> akan digunakan sebagai sumber untuk kolom tujuan.

Opsi mutasi: Nol atau beberapa operator mutasi dapat diterapkan ke satu kolom. Jika ada beberapa operator yang disediakan, operator tersebut akan selalu diterapkan dalam urutan berikut.

  1. default_value: <string>

    Jika kolom sumber tidak ada, nilai output akan ditetapkan ke <string>. Jika kolom sumber sudah ada (meskipun berisi string kosong), nilai aslinya tidak akan diubah.

  2. map_values: <map>

    Jika nilai input cocok dengan salah satu kunci di <map>, nilai output akan diganti dengan nilai yang sesuai dari peta.

  3. map_values_exclusive: {true|false}

    Jika nilai <source field> tidak cocok dengan kunci apa pun yang ditentukan dalam pasangan map_values, kolom tujuan akan dihapus secara paksa jika map_values_exclusive benar, atau dibiarkan tidak tersentuh jika map_values_exclusive salah.

  4. type: {integer|float}

    Nilai input akan dikonversi menjadi bilangan bulat atau float. Jika string tidak dapat dikonversi menjadi angka, nilai output tidak akan ditetapkan. Jika string berisi float, tetapi jenisnya ditentukan sebagai integer, angka akan terpotong menjadi bilangan bulat.

    Perhatikan bahwa Cloud Logging API menggunakan JSON sehingga tidak mendukung bilangan bulat 64-bit penuh; jika bilangan bulat 64-bit (atau lebih besar) diperlukan, bilangan bulat tersebut harus disimpan sebagai string dalam entri log.

  5. omit_if: <filter>

    Jika filter cocok dengan kumpulan data log input, kolom output akan dihapus. Ini dapat digunakan untuk menghapus nilai placeholder, seperti:

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

Contoh Konfigurasi

Pemroses parse_json akan mengubah file JSON yang berisi

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

menjadi struktur LogEntry yang terlihat seperti ini:

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

Kemudian, ini dapat diubah dengan modify_fields menjadi LogEntry ini:

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

dengan menggunakan konfigurasi Agen Operasional ini:

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]

Konfigurasi ini membaca log berformat JSON dari /var/log/http.json dan mengisi bagian struktur httpRequest dari kolom dalam log.

Layanan logging

Layanan logging menyesuaikan panjang untuk log Agen Operasional sendiri, dan menautkan penerima dan pemroses logging ke dalam pipeline. Bagian service memiliki elemen berikut:

  • log_level
  • pipelines

Level verbositas log

Kolom log_level, yang tersedia dengan Ops Agent versi 2.6.0 dan yang lebih baru, menyesuaikan panjang untuk log submodul logging Ops Agent sendiri. Defaultnya adalah info. Opsi yang tersedia adalah: error, warn, info, debug, trace.

Konfigurasi berikut menyesuaikan panjang log untuk submodul logging menjadi debug:

logging:
  service:
    log_level: debug

Pipeline logging

Kolom pipelines dapat berisi beberapa ID dan definisi pipeline. Setiap nilai pipeline terdiri dari elemen berikut:

  • receivers: Wajib untuk pipeline baru. Daftar ID penerima, seperti yang dijelaskan dalam Mencatat penerima ke dalam log. Urutan ID penerima dalam daftar tidak menjadi masalah. Pipeline mengumpulkan data dari semua penerima yang tercantum.

  • processors: Opsional. Daftar ID pemroses, seperti yang dijelaskan dalam Pemroses logging. Urutan ID pemroses dalam daftar penting. Setiap data dijalankan melalui prosesor dalam urutan yang tercantum.

Contoh konfigurasi service logging

Konfigurasi service memiliki struktur berikut:

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

Untuk menghentikan agen mengumpulkan dan mengirim entri /var/log/message atau /var/log/syslog, tentukan ulang pipeline default dengan daftar receivers kosong dan tanpa pemroses. Konfigurasi ini tidak menghentikan subkomponen logging agen, karena agen harus dapat mengumpulkan log untuk subkomponen pemantauan. Seluruh konfigurasi logging kosong akan terlihat seperti berikut:

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

Konfigurasi service berikut menentukan pipeline dengan ID custom_pipeline:

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

Konfigurasi metrik

Konfigurasi metrics menggunakan model konfigurasi yang dijelaskan sebelumnya:

  • receivers: daftar definisi penerima. receiver menjelaskan sumber metrik; misalnya, metrik sistem seperti cpu atau memory. Penerima dalam daftar ini dapat dibagikan di antara beberapa pipeline.
  • processors: daftar definisi pemroses. processor menjelaskan cara mengubah metrik yang dikumpulkan oleh penerima.
  • service: berisi bagian pipelines yang merupakan daftar definisi pipeline. pipeline menghubungkan daftar receivers dan daftar processors untuk membentuk aliran data.

Bagian berikut menjelaskan setiap elemen ini.

Agen Operasional mengirimkan metrik ke Cloud Monitoring. Anda tidak dapat mengonfigurasinya untuk mengekspor metrik ke layanan lain.

Penerima metrik

Elemen receivers berisi kumpulan definisi penerima. Penerima menjelaskan dari mana metrik diambil, seperti cpu dan memory. Penerima dapat dibagikan di antara beberapa pipeline.

Struktur penerima metrik

Setiap penerima harus memiliki ID, RECEIVER_ID, dan menyertakan elemen type. Jenis bawaan yang valid adalah:

  • hostmetrics
  • iis (Khusus Windows)
  • mssql (Khusus Windows)

Penerima juga dapat menentukan opsi collection_interval operasi. Nilai berada dalam format durasi, misalnya, 30s atau 2m. Nilai defaultnya adalah 60s.

Setiap jenis penerima ini mengumpulkan kumpulan metrik; untuk informasi tentang metrik tertentu yang disertakan, lihat Metrik yang diserap oleh penerima.

Anda hanya dapat membuat satu penerima untuk setiap jenis. Misalnya, Anda tidak dapat menentukan dua penerima jenis hostmetrics.

Mengubah interval pengumpulan di penerima metrik

Beberapa beban kerja penting mungkin memerlukan pemberitahuan cepat. Dengan mengurangi interval pengumpulan untuk metrik, Anda dapat mengonfigurasi pemberitahuan yang lebih sensitif. Untuk informasi tentang cara pemberitahuan dievaluasi, lihat Perilaku kebijakan pemberitahuan berbasis metrik.

Misalnya, penerima berikut mengubah interval pengumpulan untuk metrik host (ID penerima adalah hostmetrics) dari default 60 detik menjadi 10 detik:

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

Anda juga dapat mengganti interval pengumpulan untuk penerima metrik iis dan mssql Windows menggunakan teknik yang sama.

Metrik yang diserap oleh penerima

Metrik yang diserap oleh Agen Operasional memiliki ID yang dimulai dengan pola berikut: agent.googleapis.com/GROUP. Komponen GROUP mengidentifikasi kumpulan metrik terkait; komponen ini memiliki nilai seperti cpu, network, dan lainnya.

Penerima hostmetrics

Penerima hostmetrics menyerap grup metrik berikut. Untuk mengetahui informasi selengkapnya, lihat bagian tertaut untuk setiap grup di halaman Metrik Agen Ops.

Grup Metrik
cpu Beban CPU dengan interval 1 menit
Beban CPU dengan interval 5 menit
Beban CPU dengan interval 15 menit
Penggunaan CPU, dengan label untuk jumlah CPU dan status CPU
Persentase penggunaan CPU, dengan label untuk jumlah CPU dan status CPU
disk Byte disk yang dibaca, dengan label untuk perangkat
Byte disk yang ditulis, dengan label untuk perangkat
Waktu I/O disk, dengan label untuk perangkat
Waktu I/O disk berbobot, dengan label untuk perangkat
Operasi disk yang tertunda, dengan label untuk perangkat
Operasi disk yang digabungkan, dengan label untuk perangkat dan arah
Operasi disk, dengan label untuk perangkat dan arah
Waktu operasi disk, dengan label untuk perangkat dan arah
Penggunaan disk, dengan label untuk perangkat dan status
Penggunaan disk, dengan label untuk perangkat dan status
gpu
Khusus Linux; lihat Tentang metrik gpu untuk mengetahui informasi penting lainnya. 		Jumlah byte memori GPU saat ini yang digunakan, menurut status
Jumlah maksimum memori GPU, dalam byte, yang telah dialokasikan oleh proses
Persentase waktu dalam masa aktif proses saat satu atau beberapa kernel telah berjalan di GPU
Persentase waktu, sejak sampel terakhir, GPU telah aktif
interface
Khusus Linux 		Total jumlah error jaringan
Total jumlah paket yang dikirim melalui jaringan
Total jumlah byte yang dikirim melalui jaringan
memory Penggunaan memori, dengan label untuk status (di-buffer, di-cache, bebas, slab, digunakan)
Persentase penggunaan memori, dengan label untuk status (di-buffer, di-cache, bebas, slab, digunakan)
network Jumlah koneksi TCP, dengan label untuk port dan status TCP
swap Operasi swap I/O, dengan label untuk arah
Byte swap yang digunakan, dengan label untuk perangkat dan status
Persentase swap yang digunakan, dengan label untuk perangkat dan status
pagefile
Khusus Windows 		Persentase pagefile saat ini yang digunakan oleh status
processes Jumlah proses, dengan label untuk status
Jumlah proses yang di-fork
I/O baca disk per proses, dengan label untuk nama proses + lainnya
I/O tulis disk per proses, dengan label untuk nama proses + lainnya
Penggunaan RSS per proses, dengan label untuk nama proses + lainnya
Penggunaan VM per proses, dengan label untuk nama proses + lainnya
Penerima iis (khusus Windows)

Penerima iis (khusus Windows) menyerap metrik grup iis. Untuk informasi selengkapnya, lihat halaman Metrik agen.

Grup Metrik
iis
Khusus Windows 		Koneksi yang saat ini terbuka ke IIS
Byte jaringan yang ditransfer oleh IIS
Koneksi yang dibuka ke IIS
Permintaan yang dibuat ke IIS
Penerima mssql (khusus Windows)

Penerima mssql (khusus Windows) menyerap metrik grup mssql. Untuk mengetahui informasi selengkapnya, lihat halaman Metrik Agen Ops.

Grup Metrik
mssql
Khusus Windows 		Saat ini membuka koneksi ke server SQL
Total transaksi server SQL per detik
Transaksi tulis server SQL per detik

Pemroses metrik

Elemen processor berisi kumpulan definisi prosesor. Pemroses menjelaskan metrik dari jenis penerima yang akan dikecualikan. Satu-satunya jenis yang didukung adalah exclude_metrics, yang menggunakan opsi metrics_pattern. Nilainya adalah daftar glob yang cocok dengan jenis metrik Agen Ops yang ingin Anda kecualikan dari grup yang dikumpulkan oleh penerima. Contoh:

Contoh pemroses metrik

Contoh berikut menunjukkan prosesor exclude_metrics yang disediakan dalam konfigurasi bawaan. Pemroses ini menyediakan nilai metrics_pattern kosong, sehingga tidak mengecualikan metrik apa pun.

processors:
  metrics_filter:
    type: exclude_metrics
    metrics_pattern: []

Untuk menonaktifkan pengumpulan semua metrik proses oleh Agen Operasi, tambahkan kode berikut ke file config.yaml:

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

Hal ini mengecualikan metrik proses dari pengumpulan di prosesor metrics_filter yang berlaku untuk pipeline default di layanan metrics.

Layanan metrik

Layanan metrik menyesuaikan panjang untuk log modul metrik Ops Agent sendiri dan menautkan penerima dan pemroses metrik ke dalam pipeline. Bagian service memiliki dua elemen: log_level dan pipelines.

Tingkat kedetailan metrik

log_level, yang tersedia dengan Ops Agent versi 2.6.0 dan yang lebih baru, menyesuaikan panjang teks untuk log submodul metrik Ops Agent sendiri. Defaultnya adalah info. Opsi yang tersedia adalah: error, warn, info, debug.

Pipeline metrik

Bagian service memiliki satu elemen, pipelines, yang dapat berisi beberapa ID dan definisi pipeline. Setiap definisi pipeline terdiri dari elemen berikut:

  • receivers: Wajib untuk pipeline baru. Daftar ID penerima, seperti yang dijelaskan di Penerima metrik. Urutan ID penerima dalam daftar tidak menjadi masalah. Pipeline mengumpulkan data dari semua penerima yang tercantum.

  • processors: Opsional. Daftar ID pemroses, seperti yang dijelaskan dalam Pemroses metrik. Urutan ID pemroses dalam daftar penting. Setiap titik metrik dijalankan melalui pemroses dalam urutan yang tercantum.

Contoh konfigurasi service metrik

Konfigurasi service memiliki struktur berikut:

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

Untuk menonaktifkan penyerapan metrik host bawaan, tentukan ulang pipeline default dengan daftar receivers kosong dan tanpa pemroses. Seluruh konfigurasi metrik akan terlihat seperti berikut:

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

Contoh berikut menunjukkan konfigurasi service bawaan untuk Windows:

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

Konfigurasi service berikut menyesuaikan panjang log untuk submodul metrik menjadi debug:

metrics:
  service:
    log_level: debug

Kumpulan log mandiri

Secara default, log mandiri Fluent Bit Agen Operasional dikirim ke Cloud Logging. Log ini dapat mencakup banyak informasi, dan volume tambahan tersebut dapat meningkatkan biaya Anda untuk menggunakan Cloud Logging.

Anda dapat menonaktifkan pengumpulan log mandiri ini, mulai dari Ops Agent versi 2.44.0, dengan menggunakan opsi default_self_log_file_collection.

Untuk menonaktifkan pengumpulan log mandiri, tambahkan bagian global ke file konfigurasi yang ditentukan pengguna dan tetapkan opsi default_self_log_file_collection ke nilai false:

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

Konfigurasi rotasi log

Mulai Ops Agent versi 2.31.0, Anda juga dapat menyiapkan fitur rotasi log agen menggunakan file konfigurasi. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi rotasi log di Ops Agent.