Mengonfigurasi Agen Operasional

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

Anda ingin mengubah konfigurasi Agen Operasional untuk mencapai sasaran berikut:
- Nonaktifkan logging bawaan atau penyerapan metrik.
  - Untuk menonaktifkan penyerapan logging, lihat Contoh konfigurasi service logging.
  - Untuk menonaktifkan penyerapan metrik host, lihat Contoh konfigurasi service metrik.
- Sesuaikan jalur file file log tempat agen mengumpulkan log ; lihat Penerima logging.
- Sesuaikan format log terstruktur yang digunakan agen untuk memproses entri log, dengan menguraikan JSON atau menggunakan ekspresi reguler; lihat Pemroses log.
- Mengubah frekuensi sampling untuk metrik; lihat Penerima metrik.
- Sesuaikan grup atau grup metrik yang akan diaktifkan. Agen mengumpulkan semua metrik sistem, seperti cpu dan memory, secara default; lihat Pemroses metrik.
- Menyesuaikan cara agen merotasi log; lihat Konfigurasi rotasi log.
- Kumpulkan metrik dan log dari aplikasi pihak ketiga yang didukung. Lihat Memantau aplikasi pihak ketiga untuk mengetahui daftar aplikasi yang didukung.
- Gunakan penerima Prometheus untuk mengumpulkan metrik kustom.
- Gunakan penerima OpenTelemetry Protocol (OTLP) untuk mengumpulkan metrik dan trace kustom.
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 saja yang dikumpulkan oleh agen.
processors: Elemen ini menjelaskan cara agen dapat mengubah informasi yang dikumpulkan.
service: Elemen ini menautkan penerima dan pemroses bersama-sama untuk membuat aliran 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 Operasi menentukan pengumpulan default untuk log dan metrik. Berikut ini konfigurasi bawaan untuk Linux dan Windows:

Linux

Secara default, Agen Operasional 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 Operasional 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 menambahkan elemen konfigurasi baru ke file konfigurasi pengguna. Masukkan konfigurasi Anda untuk Agen Operasional di 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 akan digabungkan dengan konfigurasi bawaan saat agen dimulai ulang.

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

Misalnya, konfigurasi bawaan untuk metrik menyertakan penerima hostmetrics yang menentukan interval pengumpulan 60 detik. Untuk mengubah interval pengumpulan untuk metrik host menjadi 30 detik, sertakan penerima metrik bernama hostmetrics di 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 terkait perubahan konfigurasi bawaan, lihat Konfigurasi logging dan Konfigurasi metrik. Anda juga dapat menonaktifkan pengumpulan data logging atau metrik. Perubahan ini dijelaskan dalam contoh logging konfigurasi service dan konfigurasi service metrik.

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

Anda juga akan mengonfigurasi fitur rotasi log agen menggunakan file ini; untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi rotasi log di Agen Operasional.

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 menautkan penerima dan pemroses bersama-sama untuk membuat aliran data, yang disebut pipeline. Elemen service berisi elemen pipelines, yang dapat mencakup beberapa definisi pipeline.

Setiap penerima dan setiap prosesor dapat digunakan di beberapa pipeline.

Bagian berikut menjelaskan setiap elemen ini.

Agen Operasional mengirim 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 lebih lanjut, lihat Merutekan log ke tujuan yang didukung.

Penerima logging

Elemen receivers berisi sekumpulan penerima, yang masing-masing diidentifikasi oleh RECEIVER_ID. Penerima menjelaskan cara mengambil log; misalnya, dengan melakukan tail 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 melakukan tailing 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 (Agen Operasional versi 2.3.0 dan yang lebih baru): Mengumpulkan 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): Kumpulkan log jurnal sistem 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:

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).
  
  Catatan: Saat menentukan karakter pengganti di Windows, Anda harus menggunakan \ sebagai pemisah.
  
  Untuk daftar file log aplikasi Linux yang umum, lihat File log Linux umum.
- exclude_paths: Opsional. Daftar pola jalur sistem file yang akan dikecualikan dari kumpulan yang cocok dengan include_paths.
- record_log_file_path: Opsional. Jika ditetapkan ke true, jalur ke file tertentu tempat catatan 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 data diperoleh yang akan dicatat.
- wildcard_refresh_interval: Opsional. Interval saat jalur file karakter pengganti di include_paths dimuat ulang. Diberikan sebagai durasi waktu, misalnya, 30s, 2m. Properti ini mungkin berguna pada throughput logging yang tinggi, karena file log diputar lebih cepat daripada interval default. Jika tidak ditentukan, interval defaultnya adalah 60 detik.
fluent_forward penerima:
- listen_host: Opsional. Alamat IP untuk memproses. Nilai defaultnya adalah 127.0.0.1.
- listen_port: Opsional. Port untuk memproses. Nilai defaultnya adalah 24224.
Penerima syslog (hanya untuk Linux):
- transport_protocol: Opsional. Nilai yang didukung: tcp, udp. Defaultnya adalah tcp.
- listen_host: Opsional. Alamat IP untuk memproses. Nilai defaultnya adalah 0.0.0.0.
- listen_port: Opsional. Port untuk memproses. Nilai defaultnya adalah 5140.
tcp penerima:
- format: Wajib diisi. Format log. Nilai yang didukung: json.
- listen_host: Opsional. Alamat IP untuk memproses. Nilai defaultnya adalah 127.0.0.1.
- listen_port: Opsional. Port untuk memproses. Nilai defaultnya adalah 5170.
Penerima windows_event_log (khusus Windows):
- channels: Wajib diisi. Daftar saluran Windows Event Log yang digunakan untuk membaca log.
- receiver_version: Opsional. Mengontrol Windows Event Log API yang akan digunakan. Nilai yang didukung adalah 1 dan 2. Nilai defaultnya adalah 1.
  
  Perhatian: Versi 1 hanya didukung untuk kompatibilitas mundur. Saat mengonfigurasi penerima baru, gunakan versi 2. Untuk membaca dari saluran dalam kategori "Applications and Services" di Event Viewer, Anda harus menggunakan versi 2.
- render_as_xml: Opsional. Jika ditetapkan ke true, semua kolom Log Peristiwa, kecuali untuk jsonPayload.Message dan jsonPayload.StringInserts, akan dirender sebagai dokumen XML dalam kolom string yang 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:

Catatan: Tag dari kumpulan data yang masuk dipertahankan di kolom logName LogEntry sebagai akhiran yang dipisahkan titik (logName = "projects/PROJECT_ID/logs/RECEIVER_ID.TAG").

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, Agen Operasional akan menempatkan kolom tingkat atas ke dalam kolom jsonPayload LogEntry, kecuali jika nama kolom tersebut tercantum dalam tabel berikut:

bidang Rekam	Kolom LogEntry
Opsi 1 `"timestamp": { "seconds": CURRENT_SECONDS, "nanos": CURRENT_NANOS, }` Opsi 2 `{ "timestampSeconds": CURRENT_SECONDS, "timestampNanos": CURRENT_NANOS, }`	`timestamp`
penerima_id (bukan kolom kumpulan data)	`logName`
`logging.googleapis.com/httpRequest` (HttpRequest)	`httpRequest`
`logging.googleapis.com/severity` (string)	`severity`
`logging.googleapis.com/labels` (struktur 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 catatan 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 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 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`
perusahaan boneka	/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 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 mengetahui informasi tentang file log Apache Solr, lihat Memantau aplikasi pihak ketiga: Apache Solr.
sugarcrm	`/var/www/*/sugarcrm.log`
{i>syslog<i}	`/var/log/syslog /var/log/messages`
tomcat	Untuk mengetahui informasi tentang file log Apache Tomcat, lihat Memantau aplikasi pihak ketiga: Apache Tomcat.
zookeeper	Untuk mengetahui informasi tentang file log Apache ZooKeeper, lihat Memantau aplikasi pihak ketiga: Apache ZooKeeper.

Label default yang diserap

Secara default, log dapat berisi label berikut 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 `type` penerima tempat log berasal, yang diawali dengan `agent.googleapis.com/`. Hanya ditulis oleh penerima dari integrasi pihak ketiga.

Pemroses logging

Elemen processors opsional berisi kumpulan perintah pemrosesan, masing-masing diidentifikasi oleh PROCESSOR_ID. Pemroses 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, seperti berikut.

Prosesor `parse_json`

Struktur konfigurasi

processors:
  PROCESSOR_ID:
    type: parse_json

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

Pemroses parse_json akan mengurai JSON input ke dalam kolom jsonPayload dari LogEntry. Bagian lain dari LogEntry dapat diurai dengan menetapkan kolom tingkat atas 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 LogEntry yang dihasilkan dan dihapus dari payload.

Jika opsi time_key ditentukan, Anda juga harus menentukan hal berikut:
- time_format: Wajib jika time_key digunakan. Opsi ini menentukan format kolom time_key agar dapat dikenali dan dianalisis dengan benar. Untuk detail format, 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 yang berisi satu atau beberapa aturan.
- type: Wajib diisi. Hanya mendukung satu nilai:
  - language_exceptions: Memungkinkan pemroses menggabungkan pengecualian menjadi satu LogEntry, berdasarkan nilai opsi language.
- language: Wajib diisi. Hanya mendukung satu nilai:
  - 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

agen akan menyerap log ke dalam 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 LogEntry yang dihasilkan dan dihapus dari payload.

Jika opsi time_key ditentukan, Anda juga harus menentukan hal berikut:
- time_format: Wajib jika time_key digunakan. Opsi ini menentukan format kolom time_key agar dapat dikenali dan dianalisis dengan benar. Untuk detail format, 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 tangkapan bernama akan ditempatkan ke dalam kolom dalam kolom jsonPayload LogEntry. Untuk menambahkan struktur tambahan ke log Anda, gunakan pemroses modify_fields.

Untuk sekumpulan 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 level teratas untuk pemroses ini berisi satu kolom, match_any, yang berisi daftar aturan filter.

match_any: Wajib diisi. Daftar yang berisi satu atau beberapa aturan. Jika entri log cocok dengan aturan apa pun, Agen Operasional tidak akan menyerap entri tersebut.

Log yang diserap 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 bahasa kueri Logging:
- Operator perbandingan: =, !=, :, =~, !~. Hanya perbandingan string yang didukung.
- Operator navigasi: .. Contohnya, jsonPayload.message.
- Operator Boolean: AND, OR, NOT.
- Mengelompokkan ekspresi dengan ( ).

Catatan: Penggunaan pemroses exclude_logs memiliki implikasi performa, jadi sebaiknya hindari penggunaan pemroses ini jika Anda dapat mengecualikan log dari sumber atau jika Anda dapat menyiapkan filter pengecualian. Jika Anda perlu menggunakan pemroses exclude_logs, sebaiknya ikuti praktik terbaik berikut:

Minimalkan jumlah prosesor exclude_logs.
Gunakan pencocokan persis jika memungkinkan, bukan menggunakan pencocokan ekspresi reguler.

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`

Pemroses 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 prosesor 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 akan 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 pemroses yang sama.

Opsi sumber: Diizinkan maksimal satu sumber yang ditentukan.

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 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 direferensikan 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 beberapa operator disediakan, operator tersebut akan selalu diterapkan dengan urutan berikut.

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.
map_values: <map>

Jika nilai input cocok dengan salah satu kunci dalam <map>, nilai output akan diganti dengan nilai yang sesuai dari peta.
map_values_exclusive: {true|false}

Jika nilai <source field> tidak cocok dengan kunci apa pun yang ditentukan dalam pasangan map_values, kolom tujuan akan dibatalkan penetapannya secara paksa jika map_values_exclusive bernilai benar (true), atau tidak akan disentuh jika map_values_exclusive adalah salah (false).
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 ditetapkan sebagai integer, angka tersebut akan dipotong menjadi bilangan bulat.

Perlu diperhatikan bahwa Cloud Logging API menggunakan JSON, sehingga tidak mendukung bilangan bulat 64-bit penuh. Jika diperlukan bilangan bulat 64-bit (atau yang lebih besar), bilangan bulat tersebut harus disimpan sebagai string dalam entri log.
omit_if: <filter>

Jika filter cocok dengan kumpulan data log input, kolom output tidak akan ditetapkan. 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": "-"
  }
}

ID ini kemudian dapat diubah dengan modify_fields menjadi LogEntry ini:

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

menggunakan konfigurasi Agen Operasi 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 = "-"
  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 Operasi, dan menautkan penerima serta prosesor logging secara bersamaan ke dalam pipeline. Bagian service memiliki elemen berikut:

log_level
pipelines

Catat level verbositas

Kolom log_level, yang tersedia di Agen Operasional versi 2.6.0 dan yang lebih baru, menyesuaikan panjang untuk log submodul logging Agen Operasi. Defaultnya adalah info. Opsi yang tersedia adalah: error, warn, info, debug, trace.

Konfigurasi berikut menyesuaikan verbositas log untuk submodul logging menjadi debug sebagai gantinya:

logging:
  service:
    log_level: debug

Pipeline logging

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

receivers: Diperlukan untuk pipeline baru. Daftar ID penerima, seperti yang dijelaskan dalam Penerima logging. Urutan ID penerima dalam daftar tidak menjadi masalah. Pipeline mengumpulkan data dari semua penerima yang tercantum.
processors: Opsional. Daftar ID prosesor, seperti yang dijelaskan dalam Pemroses logging. Urutan ID prosesor dalam daftar memang penting. Setiap catatan 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 mencegah 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 prosesor. 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 tempat mengambil metrik, seperti cpu dan memory. Sebuah 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. Nilainya 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 notifikasi yang lebih sensitif. Untuk informasi mengenai cara mengevaluasi pemberitahuan, 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 dan 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 Operasional.

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 jumlah CPU dan status CPU Persentase penggunaan CPU, dengan label untuk jumlah CPU dan status CPU
`disk`	Byte disk dibaca, dengan label untuk perangkat Byte disk ditulis, dengan label untuk perangkat Waktu I/O disk, dengan label untuk perangkat Waktu I/O disk tertimbang, dengan label untuk perangkat Operasi tertunda disk, dengan label untuk perangkat Operasi gabungan disk, dengan label untuk perangkat dan arah Operasi disk, dengan label untuk perangkat dan arah Waktu operasi disk, dengan label untuk perangkat dan arah Penggunaan dan status disk, dengan label untuk perangkat dan arah Penggunaan dan status disk, dengan label untuk perangkat dan arah Penggunaan dan status disk
`gpu` Khusus Linux; lihat Tentang metrik `gpu` untuk mengetahui informasi penting lainnya.	Jumlah byte memori GPU yang digunakan saat ini, menurut status Jumlah maksimum memori GPU, dalam byte, yang telah dialokasikan oleh proses Persentase waktu selama masa aktif proses saat satu atau beberapa kernel telah berjalan di GPU Persentase waktu, sejak contoh terakhir, GPU telah aktif
`interface` Khusus Linux	Jumlah total 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, cache, gratis, slab, digunakan) Persentase penggunaan memori, dengan label untuk status (di-buffer, di-cache, gratis, 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 Persentase penukaran digunakan, dengan label untuk perangkat dan status
`pagefile` Khusus Windows	Persentase pagefile saat ini yang digunakan menurut status
`processes`	Jumlah proses, dengan label untuk status Jumlah proses yang bercabang I/O pembacaan disk per proses, dengan label untuk nama proses + lainnya I/O penulisan 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

Tentang metrik gpu:

Penerima hostmetrics mengumpulkan metrik yang dilaporkan oleh NVIDIA Management Library (NVML) sebagai metrik agent.googleapis.com/gpu.

Untuk mengumpulkan metrik ini, Anda harus membuat VM dengan GPU yang terpasang dan menginstal driver GPU. Penerima hostmetrics tidak mengumpulkan metrik ini di VM tanpa GPU yang terpasang.

Hanya Agen Operasional versi 2.38.0 atau versi 2.41.0 atau yang lebih baru yang kompatibel dengan pemantauan GPU. Jangan instal Agen Operasional versi 2.39.0 dan 2.40.0 pada VM dengan GPU terpasang. Untuk mengetahui informasi selengkapnya, lihat Error dan laporan agen menyebutkan NVIDIA.

Anda dapat menginstal atau mengupgrade driver GPU NVIDIA menggunakan pengelola paket atau skrip penginstalan lokal. Saat menggunakan skrip penginstalan lokal, layanan Agen Operasional harus dihentikan sebelum penginstalan driver dapat dilanjutkan. Untuk menghentikan agen, jalankan perintah berikut:

sudo systemctl stop google-cloud-ops-agent

Anda juga harus memulai ulang VM setelah menginstal atau mengupgrade driver GPU NVIDIA.

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	Saat ini koneksi terbuka ke IIS Byte jaringan yang ditransfer oleh IIS Koneksi 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 Operasional.

Grup	Metrik
`mssql` Khusus Windows	Saat ini koneksi terbuka ke server SQL Total transaksi SQL server per detik Transaksi penulisan server SQL per detik

Pemroses metrik

Elemen processor berisi kumpulan definisi pemroses. 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 Operasional yang ingin Anda kecualikan dari grup yang dikumpulkan oleh penerima. Contoh:

Untuk mengecualikan semua metrik CPU agen, tentukan agent.googleapis.com/cpu/*.
Untuk mengecualikan metrik pemakaian CPU agen, tentukan agent.googleapis.com/cpu/utilization.
Untuk mengecualikan metrik jumlah permintaan sisi klien dari metrik yang dikumpulkan oleh integrasi pihak ketiga Apache Cassandra, tentukan workloads.googleapis.com/cassandra.client.request.count.
Untuk mengecualikan semua metrik sisi klien dari metrik yang dikumpulkan oleh integrasi pihak ketiga Apache Cassandra, tentukan workloads.googleapis.com/cassandra.client.*.

Contoh pemroses metrik

Contoh berikut menunjukkan prosesor exclude_metrics yang disertakan dalam konfigurasi bawaan. Pemroses ini memberikan 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 tidak mencakup metrik proses dari pengumpulan di prosesor metrics_filter yang berlaku pada pipeline default di layanan metrics.

Layanan metrik

Layanan metrik menyesuaikan panjang untuk log yang dimiliki modul metrik Agen Operasional dan menautkan penerima serta prosesor metrik bersama-sama ke dalam pipeline. Bagian service memiliki dua elemen: log_level dan pipelines.

Tingkat panjang metrik

log_level, tersedia di Agen Operasional versi 2.6.0 dan yang lebih baru, menyesuaikan verbositas untuk log submodul metrik Agen Operasi 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: Diperlukan 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 prosesor dalam daftar memang 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 verbositas log untuk submodul metrik menjadi debug sebagai gantinya:

metrics:
  service:
    log_level: debug

Kumpulan catatan mandiri

Secara default, log mandiri Fluent Bit Agen Operasi dikirim ke Cloud Logging. Log ini dapat berisi banyak informasi, dan volume tambahannya dapat meningkatkan biaya Anda untuk menggunakan Cloud Logging.

Anda dapat menonaktifkan pengumpulan log mandiri ini, mulai dari Agen Operasional versi 2.44.0, 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 Agen Operasional 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 Operasional.

Mengonfigurasi Agen Operasional

Model konfigurasi

Konfigurasi bawaan

Linux

Windows

Konfigurasi yang ditentukan pengguna

Konfigurasi logging

Penerima logging

Struktur penerima logging

Contoh penerima logging

Kolom khusus dalam payload terstruktur

File log Linux umum

Label default yang diserap

Pemroses logging

Prosesor parse_json

Struktur konfigurasi

Contoh konfigurasi

Prosesor parse_multiline

Struktur konfigurasi

Contoh konfigurasi

Prosesor parse_regex

Struktur konfigurasi

Contoh konfigurasi

Prosesor exclude_logs

Struktur konfigurasi:

Contoh konfigurasi

Prosesor modify_fields

Struktur konfigurasi

Contoh Konfigurasi

Layanan logging

Catat level verbositas

Pipeline logging

Contoh konfigurasi service logging

Konfigurasi metrik

Penerima metrik

Struktur penerima metrik

Mengubah interval pengumpulan di penerima metrik

Metrik yang diserap oleh penerima

Penerima hostmetrics

Penerima iis (khusus Windows)

Penerima mssql (khusus Windows)

Pemroses metrik

Contoh pemroses metrik

Layanan metrik

Tingkat panjang metrik

Pipeline metrik

Contoh konfigurasi service metrik

Kumpulan catatan mandiri

Konfigurasi rotasi log

Prosesor `parse_json`

Prosesor `parse_multiline`

Prosesor `parse_regex`

Prosesor `exclude_logs`

Prosesor `modify_fields`

Contoh konfigurasi `service` logging

Penerima `hostmetrics`

Penerima `iis` (khusus Windows)

Penerima `mssql` (khusus Windows)

Contoh konfigurasi `service` metrik