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 sasaran berikut:

  • Anda tertarik untuk mempelajari detail teknis konfigurasi Agen Operasional.

Model konfigurasi

Agen Operasional menggunakan konfigurasi default bawaan; Anda tidak dapat mengubah konfigurasi bawaan ini secara langsung. 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 menghubungkan 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 menunjukkan konfigurasi bawaan untuk Linux dan Windows:

Linux

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

Untuk mengetahui 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 Operasional mengumpulkan log peristiwa Windows dari channel System, Application, dan Security, serta metrik host, metrik IIS, dan metrik SQL Server.

Untuk mengetahui 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 lebih mendetail di Konfigurasi logging dan Konfigurasi metrik.

Konfigurasi yang ditentukan pengguna

Untuk mengganti konfigurasi bawaan, Anda menambahkan elemen konfigurasi baru ke file konfigurasi pengguna. Masukkan konfigurasi Anda untuk Agen Operasional 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

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

Untuk mengganti penerima, pemroses, atau pipeline bawaan, definisikan ulang di 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 mencakup 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 menjadi 30 detik, seperti yang ditunjukkan dalam contoh berikut:

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

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

Anda dapat menggunakan file ini untuk mencegah agen mengumpulkan lognya sendiri dan mengirimkan log tersebut ke Cloud Logging. Untuk mengetahui informasi selengkapnya, lihat Pengumpulan log diri sendiri.

Anda juga mengonfigurasi fitur rotasi log agen menggunakan file ini; untuk mengetahui 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 <timestamp, record>.
  • processors: Elemen opsional ini menjelaskan cara agen dapat mengubah informasi yang dikumpulkan.
  • service: Elemen ini menghubungkan penerima dan pemroses untuk membuat alur data, yang disebut pipeline. Elemen service berisi elemen pipelines, yang dapat mencakup beberapa definisi pipeline.

Setiap penerima dan setiap pemroses dapat digunakan dalam 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 serangkaian penerima, yang masing-masing diidentifikasi oleh RECEIVER_ID. Penerima menjelaskan cara mengambil log; misalnya, dengan mengikuti file, menggunakan port TCP, atau dari Log Peristiwa Windows.

Struktur penerima logging

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

  • files: Mengumpulkan log dengan mengikuti 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 (Agen Operasional versi 2.4.0 dan yang lebih baru): Mengumpulkan log journald systemd dari layanan systemd-journald.
  • Khusus Windows:
    • windows_event_log: Kumpulkan Log Peristiwa Windows menggunakan Windows Event Log API.
  • Penerima log aplikasi pihak ketiga

Struktur receivers akan terlihat seperti berikut:

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

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

  • files penerima:

    • include_paths: Wajib diisi. Daftar jalur sistem file yang akan dibaca dengan mengikuti setiap file. Karakter pengganti (*) dapat digunakan di 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 set yang cocok dengan include_paths.

    • record_log_file_path: Opsional. Jika disetel ke true, jalur ke file tertentu tempat rekaman log diperoleh akan muncul dalam entri log output sebagai nilai label agent.googleapis.com/log_file_path. Saat menggunakan karakter pengganti, hanya jalur file tempat rekaman 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 saat file log dirotasi lebih cepat daripada interval default. Jika tidak ditentukan, interval defaultnya adalah 60 detik.

  • fluent_forward penerima:

    • 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 untuk Linux):

    • transport_protocol: Nilai yang didukung: tcp, udp.

    • listen_host: Alamat IP yang akan diproses.

    • listen_port: Port yang akan diproses.

  • tcp penerima:

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

  • windows_event_log penerima (khusus untuk Windows):

    • channels: Wajib diisi. Daftar channel Log Aktivitas Windows yang akan dibaca lognya.

    • 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 disetel ke true, semua kolom Log Peristiwa, kecuali jsonPayload.Message dan jsonPayload.StringInserts, dirender sebagai dokumen XML dalam kolom string bernama jsonPayload.raw_xml. Nilai defaultnya adalah false. Setelan 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

Penerima syslog sampel (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

Penerima windows_event_log contoh (khusus Windows):

receivers:
  RECEIVER_ID:
    type: windows_event_log

    channels: [System,Application,Security]

Contoh penerima windows_event_log yang menggantikan 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 memproses 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, Agen Operasi akan menempatkan kolom tingkat teratas ke kolom jsonPayload LogEntry, kecuali jika nama kolom tercantum dalam tabel berikut:

Kolom catatan 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 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

Kolom rekaman terstruktur yang tersisa tetap menjadi bagian dari jsonPayload struktur.

File log Linux umum

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

Aplikasi File log umum
apache Untuk mengetahui 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 mengetahui informasi tentang file log MongoDB, lihat Memantau aplikasi pihak ketiga: MongoDB.
mysql Untuk mengetahui informasi tentang file log MySQL, lihat Memantau aplikasi pihak ketiga: MySQL.
nginx Untuk mengetahui informasi tentang file log nginx, lihat Memantau aplikasi pihak ketiga: nginx.
postgres Untuk mengetahui 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 mengetahui 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 mengetahui 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 mengetahui informasi tentang file log Apache Tomcat, lihat Memantau aplikasi pihak ketiga: Apache Tomcat.
petugas kebun binatang Untuk mengetahui informasi tentang file log Apache ZooKeeper, lihat Memantau aplikasi pihak ketiga: Apache ZooKeeper.

Label yang di-ingest default

Log dapat berisi label berikut secara default di LogEntry:

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

Pemroses logging

Elemen processors opsional berisi serangkaian petunjuk 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 multiline. (Khusus Linux)
  • parse_regex: Mengurai log berformat teks melalui pola regex 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 dari 2.14.0).

Struktur processors akan terlihat seperti berikut:

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

Bergantung pada nilai elemen type, ada opsi konfigurasi lain, 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 berikut ini:

    • 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 pemroses menggabungkan 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]

Di pemroses extract_structure, pernyataan field: message berarti bahwa ekspresi reguler diterapkan ke kolom jsonPayload.message entri log. Secara default, penerima file menempatkan setiap baris file log ke dalam entri log dengan satu kolom payload bernama jsonPayload.message.

Prosesor extract_structure menempatkan kolom yang diekstrak ke dalam sub-kolom dari kolom LogEntry.jsonPayload. Pernyataan lain dalam file YAML menyebabkan dua kolom yang diekstrak, time dan severity, dipindahkan. Pernyataan time_key: time menarik kolom LogEntry.jsonPayload.time, mengurai stempel waktu, lalu menambahkan kolom LogEntry.timestamp. Prosesor move_severity memindahkan kolom tingkat keparahan dari kolom LogEntry.jsonPayload.severity ke kolom LogEntry.severity.

Contoh file log:

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

Agen menyerap setiap baris dari file 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 berikut ini:

    • 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 Anda, gunakan pemroses modify_fields.

    Untuk mengetahui kumpulan ekspresi reguler untuk 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 teratas 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, Agen Operasi tidak akan menyerap entri tersebut.

    Log yang diproses oleh Agen Operasional 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 oleh 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"'

modify_fields Prosesor

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 teratas 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 lebih banyak operasi mutasi diterapkan.

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

Semua transformasi diterapkan secara paralel, yang berarti bahwa sumber dan filter beroperasi pada entri log input asli dan oleh karena itu tidak dapat mereferensikan nilai baru dari kolom lain yang dimodifikasi oleh pemroses yang sama.

Opsi sumber: Maksimal satu sumber yang ditentukan diizinkan.

  • Tidak ada sumber yang 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 dirujuk 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 lebih operator mutasi dapat diterapkan ke satu kolom. Jika beberapa operator 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 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 yang ditentukan dalam pasangan map_values, kolom tujuan akan dibatalkan 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 disetel. Jika string berisi float, tetapi jenisnya ditentukan sebagai integer, angka akan dipangkas menjadi bilangan bulat.

    Perhatikan bahwa Cloud Logging API menggunakan JSON dan oleh karena itu tidak mendukung bilangan bulat 64-bit penuh; jika bilangan bulat 64-bit (atau yang 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 tidak akan disetel. Hal ini dapat digunakan untuk menghapus nilai placeholder, seperti:

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

Contoh Konfigurasi

Prosesor parse_json akan mengubah file JSON yang berisi

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

ke dalam struktur LogEntry yang terlihat seperti ini:

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

Kemudian, modify_fields 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 sebagian struktur httpRequest dari kolom dalam log.

Layanan logging

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

  • log_level
  • pipelines

Level verbositas log

Kolom log_level, yang tersedia dengan Agen Operasional versi 2.6.0 dan yang lebih baru, menyesuaikan kejelasan untuk log submodul logging Agen Operasional itu sendiri. Defaultnya adalah info. Opsi yang tersedia adalah: error, warn, info, debug, trace.

Konfigurasi berikut menyesuaikan kejelasan 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. 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 Mencatat pemroses. Urutan ID pemroses dalam daftar penting. Setiap data dijalankan melalui prosesor dalam urutan yang tercantum.

Contoh konfigurasi logging service

Konfigurasi service memiliki struktur berikut:

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

Untuk menghentikan pengumpulan dan pengiriman entri /var/log/message atau /var/log/syslog oleh agen, definisikan 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 alur 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 serangkaian definisi penerima. Penerima mendeskripsikan 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 operasi collection_interval. Nilainya dalam format durasi, misalnya, 30s atau 2m. Nilai defaultnya adalah 60s.

Setiap jenis penerima ini mengumpulkan serangkaian metrik; untuk mengetahui informasi tentang metrik spesifik yang disertakan, lihat Metrik yang di-ingest oleh penerima.

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

Mengubah interval pengumpulan di penerima metrik

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

Misalnya, penerima berikut mengubah interval pengumpulan untuk metrik host (ID penerimanya 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 sekumpulan 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 yang ditautkan untuk setiap grup di halaman Metrik Ops Agent.

Grup Metrik
cpu Beban CPU pada interval 1 menit
Beban CPU pada interval 5 menit
Beban CPU pada interval 15 menit
Penggunaan CPU, dengan label untuk nomor CPU dan status CPU
Persentase penggunaan CPU, dengan label untuk nomor 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 berbobot disk, 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
Pemanfaatan 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 		Jumlah total error jaringan
Jumlah total paket yang dikirim melalui jaringan
Jumlah total byte yang dikirim melalui jaringan
memory Penggunaan memori, dengan label untuk status (di-buffer, di-cache, bebas, slab, digunakan)
Persen 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 Tukar operasi I/O, dengan label untuk arah
Tukar byte yang digunakan, dengan label untuk perangkat dan status
Tukar persentase yang digunakan, dengan label untuk perangkat dan status
pagefile
Khusus Windows 		Persentase penggunaan file halaman saat ini menurut 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 mengetahui 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 Operasi.

Grup Metrik
mssql
Khusus Windows 		Koneksi yang saat ini terbuka ke SQL Server
Total transaksi per detik SQL Server
Transaksi tulis per detik SQL Server

Pemroses metrik

Elemen processor berisi serangkaian definisi prosesor. Prosesor mendeskripsikan 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 Ops Agent 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. Prosesor 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 Operasional, tambahkan kode berikut ke file config.yaml Anda:

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 kejelasan untuk log modul metrik Ops Agent sendiri dan menautkan penerima dan pemroses metrik bersama-sama ke dalam pipeline. Bagian service memiliki dua elemen: log_level dan pipelines.

Tingkat kejelasan metrik

log_level, yang tersedia dengan Agen Operasional versi 2.6.0 dan yang lebih baru, menyesuaikan tingkat kejelasan untuk log submodul metrik Agen Operasional. 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 dalam 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 metrik service

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, tetapkan 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 kejelasan log untuk submodul metrik menjadi debug, bukan service:

metrics:
  service:
    log_level: debug

Pengumpulan log diri sendiri

Secara default, log mandiri Fluent Bit Agen Operasional dikirim ke Cloud Logging. Log ini dapat mencakup banyak informasi, dan volume tambahan dapat meningkatkan biaya penggunaan 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 dari 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 Agen Operasi.