Saat bermigrasi dari agen Logging ke Fluentd upstream, Anda mungkin mengalami inkompatibilitas konfigurasi yang memerlukan solusi untuk mencegah error saat startup. Dokumen ini menjelaskan cara menyelesaikan ketidakcocokan konfigurasi.
Perubahan sintaksis antara agen Logging lama dan Fluentd upstream
Meskipun agen Logging lama mengandalkan sintaksis Fluentd v0.12, Fluentd upstream mengadopsi standar v1. Transisi ini melibatkan penghentian penggunaan berbagai parameter dan pengenalan direktif bertingkat baru untuk menangani fungsi inti, menggantikan struktur konfigurasi datar yang digunakan sebelumnya.
Untuk mencegah kegagalan saat memulai dan memastikan log Anda diproses dengan benar, Anda harus menghapus atau mengganti parameter yang tidak digunakan lagi. Bagian berikut menjelaskan cara memperbarui parameter yang tidak digunakan lagi.
Konfigurasi plugin output
Tabel berikut mencantumkan parameter yang harus diperbarui dalam konfigurasi plugin output untuk menghindari error:
| Sintaksis agen Logging lama | Sintaksis Fluentd upstream | Catatan |
|---|---|---|
| T/A | <buffer> |
Plugin output Fluentd mendukung bagian <buffer>, di bagian <match>, untuk mengonfigurasi buffering peristiwa. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Fluentd Config: Buffer Section. |
buffer_type |
@type |
|
buffer_path |
path |
|
buffer_chunk_limit |
chunk_limit_size |
|
disable_retry_limit |
retry_forever |
|
retry_limit |
retry_max_times |
|
max_retry_wait |
retry_max_interval |
|
num_threads |
flush_thread_count |
|
partial_success |
T/A | Hapus parameter ini. Fluentd upstream mengaktifkan keberhasilan sebagian secara permanen secara default, hanya menghapus baris yang tidak valid. |
Berikut adalah contoh konfigurasi plugin output google-cloud
di agen Logging lama:
<match **>
@type google_cloud
buffer_type file
buffer_path /var/log/google-fluentd/buffers
buffer_chunk_limit 512KB
flush_interval 5s
disable_retry_limit false
retry_limit 3
retry_wait 10
max_retry_wait 300
num_threads 8
</match>
Setelah melakukan update, konfigurasi akan terlihat seperti berikut:
<match **>
@type google_cloud
<buffer>
@type file
path /var/log/google-fluentd/buffers
chunk_limit 512KB
flush_interval 5s
retry_forever false
retry_max_times 3
retry_wait 10
retry_max_interval 300
flush_thread_count 8
</buffer>
</match>
Konfigurasi plugin input
Tabel berikut mencantumkan parameter yang harus diperbarui dalam konfigurasi plugin input Anda untuk menghindari error:
| Sintaksis agen Logging lama | Sintaksis Fluentd upstream | Catatan |
|---|---|---|
format |
<parse> |
Untuk mengetahui informasi selengkapnya, lihat dokumentasi Fluentd Config: Parse Section. |
protocol_type |
<transport> |
Tunjukkan protokol transportasi syslog, yaitu udp, tcp,, atau tls. |
auto_typecast |
Hapus parameter ini saat digunakan dalam plugin penguraian json. |
Berikut adalah contoh konfigurasi plugin input di agen Logging lama:
<source>
@type tail
path /var/log/my-app.log
format json
</source>
Setelah melakukan update, konfigurasi akan terlihat seperti berikut:
<source>
@type tail
path /var/log/my-app.log
<parse>
@type json
</parse>
</source>
Serialisasi objek Ruby Time
Fluentd upstream memerlukan casting eksplisit untuk objek Time Ruby mentah yang digunakan di dalam filter <record>, seperti record_transformer. Tanpa transmisi
eksplisit, objek ini menyebabkan error serialisasi fatal selama penghapusan buffer.
Jika konfigurasi Anda menggunakan ${time} dengan enable_ruby true, Anda harus
secara eksplisit melakukan transmisi objek ke jenis primitif, bilangan bulat, atau string.
Berikut adalah contoh konfigurasi plugin filter di agen Logging lama:
<filter foo.bar>
@type record_transformer
enable_ruby true
<record>
raw_timestamp ${time}
</record>
</filter>
Setelah melakukan update, konfigurasi akan terlihat seperti berikut:
<filter foo.bar>
@type record_transformer
enable_ruby true
<record>
raw_timestamp ${time.to_i}
</record>
</filter>
Default kompresi dan transport gRPC
Plugin output google_cloud memungkinkan Anda mengonfigurasi apakah akan menggunakan gRPC
alih-alih REST/JSON untuk berkomunikasi dengan Cloud Logging API.
Untuk performa yang lebih baik, sebaiknya aktifkan transportasi gRPC dan konfigurasi
grpc_compression_algorithm gzip. Kombinasi ini meminimalkan
overhead jaringan dan penggunaan CPU, terutama saat memproses volume log yang besar.
Untuk menerapkan pengoptimalan ini, gunakan konfigurasi berikut:
<match **>
@type google_cloud
use_grpc true
grpc_compression_algorithm gzip
</match>
Selain itu, karena gRPC mengandalkan streaming HTTP/2 di port 443, Anda harus
memastikan bahwa infrastruktur jaringan Anda mengizinkan traffic gRPC/HTTP/2. Di
lingkungan tempat gRPC dibatasi, Anda harus secara eksplisit menentukan
use_grpc false untuk kembali ke komunikasi HTTP/REST standar.
Pola ekspresi reguler RabbitMQ
Pola ekspresi reguler yang digunakan oleh agen Logging lama untuk penyerapan log RabbitMQ sering kali tidak kompatibel dengan format output versi RabbitMQ modern. Perbedaan ini dapat menyebabkan log diproses dengan tidak benar atau dihapus secara diam-diam selama proses pengumpulan.
Log RabbitMQ modern menyertakan presisi milidetik dalam stempel waktu, seperti
YYYY-MM-DD HH:MM:SS.L, dan menampilkan penanda PID dan tingkat keparahan tertentu seperti
[info] <0.213.0>, yang gagal dicocokkan oleh ekspresi reguler lama.
Jika agen Fluentd Anda dikonfigurasi untuk mengumpulkan log RabbitMQ, Anda harus memperbarui bagian <parser> untuk menangani format log saat ini dengan benar.
Berikut adalah contoh konfigurasi plugin input RabbitMQ untuk agen Logging lama:
<source>
@type tail
path /var/log/rabbitmq/*.log
pos_file /var/lib/google-fluentd/pos/rabbitmq.pos
tag rabbitmq
format multiline
format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/
format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?<severity>\w+)\] (?<message>.*)/
time_format %Y-%m-%d %H:%M:%S
</source>
Setelah melakukan update, konfigurasi akan terlihat seperti berikut:
<source>
@type tail
path /var/log/rabbitmq/*.log
pos_file /var/log/fluentd/pos/rabbitmq.pos
read_from_head true
tag rabbitmq
<parse>
@type multiline
format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/
format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \[(?<severity>[^\]]+)\] <(?<pid>[^>]+)> (?m:(?<message>.*))$/
time_format %Y-%m-%d %H:%M:%S.%L
</parse>
</source>