Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengkonfigurasi log Amazon ECS untuk throughput tinggi
Untuk skenario throughput log tinggi, sebaiknya gunakan driver `awsfirelens` log dengan FireLens danFluent Bit. Fluent Bitadalah prosesor log ringan yang efisien dengan sumber daya dan dapat menangani jutaan catatan log. Namun, mencapai kinerja optimal pada skala memerlukan penyetelan konfigurasinya.
Bagian ini mencakup teknik Fluent Bit optimasi canggih untuk menangani throughput log tinggi sambil menjaga stabilitas sistem dan memastikan tidak ada kehilangan data.
Untuk informasi tentang cara menggunakan file konfigurasi kustom dengan FireLens, lihat[Gunakan file konfigurasi khusus](firelens-taskdef.md#firelens-taskdef-customconfig). Untuk contoh tambahan, lihat [ FireLens contoh Amazon ECS](https://github.com/aws-samples/amazon-ecs-firelens-examples) di GitHub.
**catatan**
Beberapa opsi konfigurasi di bagian ini, seperti `workers` dan`threaded`, memerlukan AWS Fluent Bit versi 3 atau yang lebih baru. Untuk informasi tentang versi yang tersedia, lihat [AWS untuk rilis Fluent Bit](https://github.com/aws/aws-for-fluent-bit/releases).
## Memahami potongan
Fluent BitMemproses data dalam satuan yang disebut *chunks*. Ketika plugin INPUT menerima data, mesin membuat potongan yang disimpan dalam memori atau pada sistem file sebelum dikirim ke tujuan OUTPUT.
Perilaku buffering tergantung pada `storage.type` pengaturan di bagian INPUT Anda. Secara default, Fluent Bit menggunakan buffering memori. Untuk skenario throughput atau produksi tinggi, buffering sistem file memberikan ketahanan yang lebih baik.
Untuk informasi lebih lanjut, lihat [Potongan](https://docs.fluentbit.io/manual/administration/buffering-and-storage#chunks) dalam Fluent Bit dokumentasi dan [Apa itu Potongan?](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#what-is-a-chunk) dalam repositori AWS untuk Fluent Bit contoh.
## Buffering memori (default)
Secara default, Fluent Bit menggunakan memori buffering (`storage.type memory`). Anda dapat membatasi penggunaan memori per plugin INPUT menggunakan `Mem_Buf_Limit` parameter.
Contoh berikut menunjukkan konfigurasi masukan buffered memori:
```
[INPUT]
Name tcp
Tag ApplicationLogs
Port 5170
storage.type memory
Mem_Buf_Limit 5MB
```
**penting**
Ketika `Mem_Buf_Limit` terlampaui untuk sebuah plugin, Fluent Bit jeda input dan catatan baru hilang. Ini dapat menyebabkan tekanan balik dan memperlambat aplikasi Anda. Peringatan berikut muncul di Fluent Bit log:
```
[input] tcp.1 paused (mem buf overlimit)
```
Buffering memori cocok untuk kasus penggunaan sederhana dengan throughput log rendah hingga sedang. Untuk skenario throughput atau produksi tinggi di mana kehilangan data menjadi perhatian, gunakan buffering sistem file sebagai gantinya.
Untuk informasi selengkapnya, lihat [Buffering dan Memory](https://docs.fluentbit.io/manual/administration/buffering-and-storage#buffering-and-memory) dalam Fluent Bit dokumentasi dan [Memory Buffering Only](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-1-memory-buffering-only-default-or-storagetype-memory) di repositori AWS for Fluent Bit examples.
## Penyangga sistem file
Untuk skenario throughput tinggi, sebaiknya gunakan buffering sistem file. Untuk informasi selengkapnya tentang cara Fluent Bit mengelola buffering dan penyimpanan, lihat [Buffering dan Storage](https://docs.fluentbit.io/manual/administration/buffering-and-storage) dalam dokumentasi. Fluent Bit
Filesystem buffering memberikan keuntungan sebagai berikut:
+ **Kapasitas buffer yang lebih besar** — Ruang disk biasanya lebih melimpah daripada memori.
+ **Persistensi** — Data buffered bertahan Fluent Bit restart.
+ **Degradasi anggun** — Selama kegagalan output, data terakumulasi pada disk daripada menyebabkan kelelahan memori.
Untuk mengaktifkan buffering sistem file, sediakan file konfigurasi khusus. Fluent Bit Contoh berikut menunjukkan konfigurasi yang disarankan:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
Parameter konfigurasi kunci:
`storage.path`
Direktori tempat Fluent Bit menyimpan potongan buffer pada disk.
`storage.backlog.flush_on_shutdown`
Saat diaktifkan, Fluent Bit mencoba untuk menghapus semua potongan sistem file backlog ke tujuan mereka selama shutdown. Ini membantu memastikan pengiriman data sebelum Fluent Bit berhenti, tetapi dapat meningkatkan waktu shutdown.
`storage.max_chunks_up`
Jumlah potongan yang tersisa dalam memori. Defaultnya adalah 128 chunks, yang dapat mengkonsumsi 500 MB\$1memori karena setiap potongan dapat menggunakan hingga 4-5 MB. Dalam lingkungan yang dibatasi memori, turunkan nilai ini. Misalnya, jika Anda memiliki 50 MB yang tersedia untuk buffering, atur ini menjadi 8-10 potongan.
`storage.type filesystem`
Mengaktifkan penyimpanan sistem file untuk plugin input. Terlepas dari namanya, Fluent Bit digunakan `mmap` untuk memetakan potongan ke memori dan disk, memberikan ketekunan tanpa mengorbankan kinerja.
`storage.total_limit_size`
Ruang disk maksimum untuk data buffer untuk plugin OUTPUT tertentu. Ketika batas ini tercapai, catatan tertua untuk output tersebut dijatuhkan. Untuk informasi lebih lanjut tentang ukuran, lihat[Memahami `storage.total_limit_size`](#firelens-storage-sizing).
`threaded true`
Menjalankan input di utasnya sendiri, terpisah dari Fluent Bit loop acara utama. Ini mencegah input lambat memblokir seluruh pipa.
Untuk informasi selengkapnya, lihat [Filesystem Buffering](https://docs.fluentbit.io/manual/administration/buffering-and-storage#filesystem-buffering) dalam Fluent Bit dokumentasi dan [Filesystem dan Memory Buffering di repositori](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/fluent-bit/oomkill-prevention#case-2-filesystem-and-memory-buffering-storagetype-filesystem) for examples. AWS Fluent Bit
## Memahami `storage.total_limit_size`
`storage.total_limit_size`Parameter pada setiap plugin OUTPUT mengontrol ruang disk maksimum untuk data buffer untuk output tersebut. Ketika batas ini tercapai, catatan tertua untuk output tersebut dijatuhkan untuk memberi ruang bagi data baru. Ketika ruang disk benar-benar habis, Fluent Bit gagal mengantri catatan dan hilang.
Gunakan rumus berikut untuk menghitung yang sesuai `storage.total_limit_size` berdasarkan tingkat log Anda dan jendela pemulihan yang diinginkan:
```
If log rate is in KB/s, convert to MB/s first:
log_rate (MB/s) = log_rate (KB/s) / 1000
storage.total_limit_size (GB) = log_rate (MB/s) × duration (hours) × 3600 (seconds/hour) / 1000 (MB to GB)
```
Tabel berikut menunjukkan contoh perhitungan untuk tingkat log umum dan jendela pemulihan:
| Tingkat Log | 1 jam | 6 jam | 12 jam | 24 jam |
| --- | --- | --- | --- | --- |
| 0, 25 MB/s | 0,9 GB | 5,4 GB | 10,8 GB | 21,6 GB |
| 0, 5 MB/s | 1,8 GB | 10,8 GB | 21,6 GB | 43,2 GB |
| 1 MB/s | 3,6 GB | 21,6 GB | 43,2 GB | 86,4 GB |
| 5 MB/s | 18 GB | 108 GB | 216 GB | 432 GB |
| 10 MB/s | 36 GB | 216 GB | 432 GB | 864 GB |
Untuk mengamati throughput puncak dan memilih ukuran buffer yang sesuai, gunakan sampel [ FireLens ukuran-throughput](https://github.com/aws-samples/amazon-ecs-firelens-examples/tree/mainline/examples/measure-throughput).
Gunakan rumus, contoh perhitungan, dan benchmarking untuk memilih yang cocok `storage.total_limit_size` yang menyediakan landasan pacu untuk pemulihan upaya terbaik selama pemadaman.
## Persyaratan penyimpanan tugas Amazon ECS
Jumlahkan semua `storage.total_limit_size` nilai di seluruh bagian OUTPUT dan tambahkan buffer untuk overhead. Total ini menentukan ruang penyimpanan yang dibutuhkan dalam definisi tugas Amazon ECS Anda. Misalnya, 3 output × 10 GB masing-masing = 30 GB\$1buffer (5—10 GB) = 35—40 GB total yang diperlukan. Jika total melebihi penyimpanan yang tersedia, Fluent Bit mungkin gagal untuk mengantri catatan dan mereka akan hilang.
Opsi penyimpanan berikut tersedia:
Bind mount (penyimpanan sementara)
+ Untuk AWS Fargate, defaultnya adalah penyimpanan sementara 20 GB (maks 200 GB). Konfigurasikan penggunaan `ephemeralStorage` dalam definisi tugas. Untuk informasi selengkapnya, lihat [EphemeralStorage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-ephemeralstorage.html) di *AWS CloudFormation Panduan Pengguna*.
+ Untuk EC2, defaultnya adalah 30 GB saat menggunakan AMI Amazon ECS yang dioptimalkan (dibagi antara OS dan Docker). Tingkatkan dengan mengubah ukuran volume root.
Volume Amazon EBS
+ Menyediakan penyimpanan blok yang sangat tersedia, tahan lama, dan berkinerja tinggi.
+ Memerlukan konfigurasi volume dan `mountPoint` dalam definisi tugas menunjuk ke `storage.path` (default:`/var/log/flb-storage/`).
+ Untuk informasi selengkapnya, lihat [Tunda konfigurasi volume untuk waktu peluncuran dalam definisi tugas Amazon ECS](specify-ebs-config.md).
Volume Amazon EFS
+ Menyediakan penyimpanan file yang sederhana dan dapat diskalakan.
+ Memerlukan konfigurasi volume dan `mountPoint` dalam definisi tugas menunjuk ke `storage.path` (default:`/var/log/flb-storage/`).
+ Untuk informasi selengkapnya, lihat [Menentukan sistem file Amazon EFS dalam definisi tugas Amazon ECS](specify-efs-config.md).
Untuk informasi selengkapnya tentang volume data, lihat[Opsi penyimpanan untuk tugas Amazon ECS](using_data_volumes.md).
## Optimalkan konfigurasi keluaran
Masalah jaringan, pemadaman layanan, dan pembatasan tujuan dapat mencegah log dikirimkan. Konfigurasi output yang tepat memastikan ketahanan tanpa kehilangan data.
Ketika output flush gagal, Fluent Bit dapat mencoba kembali operasi. Parameter berikut mengontrol perilaku coba lagi:
`retry_limit`
Jumlah maksimum percobaan ulang setelah upaya awal sebelum menjatuhkan catatan. Default-nya adalah 1. Misalnya, `retry_limit 3` berarti 4 total upaya (1 awal \$13 percobaan ulang). Untuk lingkungan produksi, kami merekomendasikan 15 atau lebih tinggi, yang mencakup beberapa menit pemadaman dengan backoff eksponensial.
Setel ke `no_limits` atau `False` untuk percobaan ulang tak terbatas:
+ Dengan buffering memori, percobaan ulang tak terbatas menyebabkan plugin input berhenti saat batas memori tercapai.
+ Dengan buffering sistem file, catatan tertua dijatuhkan saat tercapai. `storage.total_limit_size`
Setelah menghabiskan semua upaya coba lagi (1 percobaan ulang awal \$1`retry_limit`), catatan dijatuhkan. AWS plugin dengan `auto_retry_requests true` (default) menyediakan lapisan coba lagi tambahan sebelum mekanisme coba Fluent Bit lagi. Untuk informasi selengkapnya, lihat [Mengonfigurasi percobaan ulang](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-retries) dalam Fluent Bit dokumentasi.
Misalnya, `retry_limit 3` dengan pengaturan default (`scheduler.base 5`,`scheduler.cap 2000`,`net.connect_timeout 10s`) menyediakan sekitar 70 detik waktu tunggu penjadwal (10-an\$120-an\$140-an), 40 detik batas waktu koneksi jaringan (4 upaya × 10 detik), ditambah percobaan ulang AWS plugin - total sekitar 2-10 menit tergantung pada kondisi jaringan dan batas waktu OS TCP.
`scheduler.base`
Detik dasar antara percobaan ulang (default: 5). Kami merekomendasikan 10 detik.
`scheduler.cap`
Detik maksimum antara percobaan ulang (default: 2000). Kami merekomendasikan 60 detik.
Waktu tunggu antara percobaan ulang menggunakan backoff eksponensial dengan jitter:
```
wait_time = random(base, min(base × 2^retry_number, cap))
```
Misalnya, dengan `scheduler.base 10` dan`scheduler.cap 60`:
+ Coba lagi pertama: tunggu acak antara 10-20 detik
+ Coba lagi kedua: tunggu acak antara 10-40 detik
+ Coba lagi ketiga dan kemudian: tunggu acak antara 10-60 detik (dibatasi)
Untuk informasi selengkapnya, lihat [Mengkonfigurasi waktu tunggu untuk mencoba lagi](https://docs.fluentbit.io/manual/administration/scheduling-and-retries#configure-wait-time-for-retry) dan [Jaringan](https://docs.fluentbit.io/manual/administration/networking) dalam Fluent Bit dokumentasi.
`workers`
Jumlah thread untuk pemrosesan output paralel. Beberapa pekerja memungkinkan pembilasan bersamaan, meningkatkan throughput saat memproses banyak potongan.
`auto_retry_requests`
Pengaturan AWS khusus plugin yang menyediakan lapisan coba lagi tambahan sebelum mekanisme coba ulang bawaanFluent Bit. Nilai default-nya `true`. Saat diaktifkan, plugin AWS keluaran mencoba ulang permintaan yang gagal secara internal sebelum permintaan dianggap sebagai flush yang gagal dan tunduk pada konfigurasi. `retry_limit`
`Grace`Parameter di `[SERVICE]` bagian mengatur waktu Fluent Bit menunggu selama shutdown untuk menyiram data buffer. `Grace`Periode harus dikoordinasikan dengan wadah. `stopTimeout` Pastikan bahwa `stopTimeout` melebihi `Grace` periode untuk memungkinkan Fluent Bit untuk menyelesaikan pembilasan sebelum menerima. `SIGKILL` Misalnya, jika `Grace` 120 detik, atur `stopTimeout` ke 150 detik.
Contoh berikut menunjukkan Fluent Bit konfigurasi lengkap dengan semua pengaturan yang direkomendasikan untuk skenario throughput tinggi:
```
[SERVICE]
# Flush logs every 1 second
Flush 1
# Wait 120 seconds during shutdown to flush remaining logs
Grace 120
# Directory for filesystem buffering
storage.path /var/log/flb-storage/
# Limit chunks stored 'up' in memory (reduce for memory-constrained environments)
storage.max_chunks_up 32
# Flush backlog chunks to destinations during shutdown (prevents log loss)
storage.backlog.flush_on_shutdown On
# Minimum seconds between retries
scheduler.base 10
# Maximum seconds between retries (exponential backoff cap)
scheduler.cap 60
[INPUT]
Name forward
unix_path /var/run/fluent.sock
# Run input in separate thread to prevent blocking
threaded true
# Enable filesystem buffering for persistence
storage.type filesystem
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
# Use multiple workers for parallel processing
workers 2
# Retry failed flushes up to 15 times
retry_limit 15
# Maximum disk space for buffered data for this output
storage.total_limit_size 10G
```
## Memahami skenario kehilangan data
Catatan dapat hilang selama pemadaman yang diperpanjang atau masalah dengan tujuan output. Rekomendasi konfigurasi dalam panduan ini adalah pendekatan upaya terbaik untuk meminimalkan kehilangan data, tetapi tidak dapat menjamin nol kerugian selama kegagalan yang berkepanjangan. Memahami skenario ini membantu Anda mengonfigurasi Fluent Bit untuk memaksimalkan ketahanan.
Rekaman dapat hilang dengan dua cara: catatan tertua dijatuhkan saat penyimpanan terisi, atau catatan terbaru ditolak ketika sistem tidak dapat menerima lebih banyak data.
### Rekor tertua dijatuhkan
Catatan buffer tertua dijatuhkan ketika upaya coba lagi habis atau saat `storage.total_limit_size` diisi dan perlu memberi ruang untuk data baru.
Batas coba lagi terlampaui
Terjadi setelah AWS plugin mencoba ulang (jika`auto_retry_requests true`) ditambah 1 Fluent Bit upaya awal ditambah percobaan `retry_limit` ulang. Untuk mengurangi, atur `retry_limit no_limits` per plugin OUTPUT untuk percobaan ulang tak terbatas:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
retry_limit no_limits
auto_retry_requests true
```
Percobaan ulang tak terbatas mencegah jatuhnya catatan karena kelelahan coba lagi, tetapi dapat menyebabkan pengisian. `storage.total_limit_size`
Batas penyimpanan tercapai (buffering sistem file)
Terjadi ketika tujuan output tidak tersedia lebih lama dari buffer yang `storage.total_limit_size` dapat dikonfigurasi. Misalnya, buffer 10 GB pada 1 MB/s log rate menyediakan sekitar 2,7 jam buffering. Untuk mengurangi, tingkatkan `storage.total_limit_size` per plugin OUTPUT dan sediakan penyimpanan tugas Amazon ECS yang memadai:
```
[OUTPUT]
Name cloudwatch_logs
Match ApplicationLogs
storage.total_limit_size 10G
```
### Catatan terbaru ditolak
Catatan terbaru dijatuhkan saat ruang disk habis atau saat input dijeda karena. `Mem_Buf_Limit`
Ruang disk habis (buffering sistem file)
Terjadi ketika ruang disk benar-benar habis. Fluent Bitgagal mengantri catatan baru dan hilang. Untuk mengurangi, jumlahkan semua `storage.total_limit_size` nilai dan sediakan penyimpanan tugas Amazon ECS yang memadai. Untuk informasi selengkapnya, lihat [Persyaratan penyimpanan tugas Amazon ECS](#firelens-storage-task-requirements).
Batas memori tercapai (buffering memori)
Terjadi ketika tujuan output tidak tersedia dan buffer memori terisi. Plugin input yang dijeda berhenti menerima catatan baru. Untuk mengurangi, gunakan `storage.type filesystem` untuk ketahanan yang lebih baik, atau tingkatkan. `Mem_Buf_Limit`
### Praktik terbaik untuk meminimalkan kehilangan data
Pertimbangkan praktik terbaik berikut untuk meminimalkan kehilangan data:
+ **Gunakan buffering sistem file - Tetapkan `storage.type filesystem` untuk ketahanan yang lebih baik selama pemadaman**.
+ **Ukuran penyimpanan dengan tepat** — Hitung `storage.total_limit_size` berdasarkan tingkat log dan jendela pemulihan yang diinginkan.
+ **Menyediakan disk yang memadai** — Pastikan tugas Amazon ECS memiliki penyimpanan sementara yang cukup, Amazon EBS, atau Amazon EFS.
+ **Konfigurasikan perilaku coba lagi** - Seimbangkan antara `retry_limit` (menjatuhkan catatan setelah percobaan ulang yang melelahkan) dan `no_limits` (mencoba ulang tanpa batas tetapi dapat mengisi penyimpanan).
## Gunakan pencatatan multi-tujuan untuk keandalan
Mengirim log ke beberapa tujuan menghilangkan satu titik kegagalan. Misalnya, jika CloudWatch Log mengalami pemadaman, log masih mencapai Amazon S3.
Pencatatan multi-tujuan memberikan manfaat berikut. Plugin keluaran Amazon S3 juga mendukung opsi kompresi seperti format gzip dan Parket, yang dapat mengurangi biaya penyimpanan. Untuk informasi selengkapnya, lihat [kompresi S3](https://docs.fluentbit.io/manual/pipeline/outputs/s3#compression) dalam Fluent Bit dokumentasi.
Pencatatan multi-tujuan dapat memberikan manfaat berikut:
+ **Redundansi** — Jika satu tujuan gagal, log masih mencapai yang lain.
+ **Pemulihan** — Rekonstruksi kesenjangan dalam satu sistem dari yang lain.
+ **Daya Tahan** - Arsipkan log di Amazon S3 untuk retensi jangka panjang.
+ **Pengoptimalan biaya** — Simpan log terbaru dalam layanan kueri cepat seperti CloudWatch Log dengan retensi lebih pendek, sambil mengarsipkan semua log ke penyimpanan Amazon S3 berbiaya lebih rendah untuk retensi jangka panjang.
Fluent BitKonfigurasi berikut mengirimkan log ke CloudWatch Log dan Amazon S3:
```
[OUTPUT]
Name cloudwatch_logs
Match *
region us-west-2
log_group_name /aws/ecs/my-app
log_stream_name $(ecs_task_id)
workers 2
retry_limit 15
[OUTPUT]
Name s3
Match *
bucket my-logs-bucket
region us-west-2
total_file_size 100M
s3_key_format /fluent-bit-logs/$(ecs_task_id)/%Y%m%d/%H/%M/$UUID
upload_timeout 10m
# Maximum disk space for buffered data for this output
storage.total_limit_size 5G
```
Kedua output menggunakan `Match *` pola yang sama, sehingga semua catatan dikirim ke kedua tujuan secara independen. Selama pemadaman satu tujuan, log terus mengalir ke tujuan lainnya sementara flush yang gagal menumpuk di buffer sistem file untuk dicoba lagi nanti.
## Gunakan logging berbasis file dengan plugin input ekor
Untuk skenario throughput tinggi di mana kehilangan log merupakan masalah penting, Anda dapat menggunakan pendekatan alternatif: minta aplikasi Anda menulis log ke file di disk, dan konfigurasikan Fluent Bit untuk membacanya menggunakan plugin `tail` input. Pendekatan ini sepenuhnya melewati lapisan driver logging Docker.
Pencatatan berbasis file dengan plugin ekor memberikan manfaat berikut:
+ **Offset tracking** - Plugin ekor dapat menyimpan offset file dalam file database (menggunakan `DB` opsi), memberikan daya tahan di seluruh Fluent Bit restart. Ini membantu mencegah kehilangan log selama restart kontainer.
+ **Buffering tingkat input** - Anda dapat mengonfigurasi batas buffer memori langsung pada plugin input menggunakan`Mem_Buf_Limit`, memberikan kontrol yang lebih terperinci atas penggunaan memori.
+ **Menghindari overhead Docker** — Log masuk langsung dari file ke Fluent Bit tanpa melewati buffer log Docker.
Untuk menggunakan pendekatan ini, aplikasi Anda harus menulis log ke file alih-alih`stdout`. Baik wadah aplikasi dan Fluent Bit wadah memasang volume bersama tempat file log disimpan.
Contoh berikut menunjukkan konfigurasi input ekor dengan praktik terbaik:
```
[INPUT]
Name tail
# File path or glob pattern to tail
Path /var/log/app.log
# Database file for storing file offsets (enables resuming after restart)
DB /var/log/flb_tail.db
# when true, controls that only fluent-bit will access the database (improves performance)
DB.locking true
# Skip long lines instead of skipping the entire file
Skip_Long_Lines On
# How often (in seconds) to check for new files matching the glob pattern
Refresh_Interval 10
# Extra seconds to monitor a file after rotation to account for pending flush
Rotate_Wait 30
# Maximum size of the buffer for a single line
Buffer_Max_Size 10MB
# Initial allocation size for reading file data
Buffer_Chunk_Size 1MB
# Maximum memory buffer size (tail pauses when full)
Mem_Buf_Limit 75MB
```
Saat menggunakan plugin input ekor, pertimbangkan hal berikut:
+ Terapkan rotasi log untuk log aplikasi Anda untuk mencegah kelelahan disk. Pantau metrik volume yang mendasarinya untuk mengukur kinerja.
+ Pertimbangkan pengaturan seperti`Ignore_Older`,`Read_from_Head`, dan parser multiline berdasarkan format log Anda.
Untuk informasi selengkapnya, lihat [Ekor](https://docs.fluentbit.io/manual/pipeline/inputs/tail) dalam Fluent Bit dokumentasi. Untuk praktik terbaik, lihat [Konfigurasi ekor dengan praktik terbaik](https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#tail-config-with-best-practices) dalam panduan AWS Fluent Bit pemecahan masalah.
## Log langsung ke FireLens
Ketika driver `awsfirelens` log ditentukan dalam definisi tugas, agen penampung Amazon ECS menyuntikkan variabel lingkungan berikut ke dalam wadah:
`FLUENT_HOST`
Alamat IP yang ditetapkan ke FireLens wadah.
Jika Anda menggunakan EC2 dengan mode `bridge` jaringan, variabel `FLUENT_HOST` lingkungan dalam wadah aplikasi Anda dapat menjadi tidak akurat setelah restart wadah router FireLens log (wadah dengan `firelensConfiguration` objek dalam definisi kontainer). Ini karena `FLUENT_HOST` merupakan alamat IP dinamis dan dapat berubah setelah restart. Logging langsung dari wadah aplikasi ke alamat `FLUENT_HOST` IP dapat mulai gagal setelah alamat berubah. Untuk informasi selengkapnya tentang memulai ulang kontainer individual, lihat. [Mulai ulang kontainer individual dalam tugas Amazon ECS dengan kebijakan restart kontainer](container-restart-policy.md)
`FLUENT_PORT`
Port tempat protokol Fluent Forward mendengarkan.
Anda dapat menggunakan variabel lingkungan ini untuk log langsung ke router Fluent Bit log dari kode aplikasi Anda menggunakan protokol Fluent Forward, alih-alih menulis ke`stdout`. Pendekatan ini melewati lapisan driver logging Docker, yang memberikan manfaat berikut:
+ **Latensi yang lebih rendah** - Log langsung masuk Fluent Bit tanpa melewati infrastruktur logging Docker.
+ **Pencatatan terstruktur** — Kirim data log terstruktur secara native tanpa overhead encoding JSON.
+ **Kontrol yang lebih baik** - Aplikasi Anda dapat menerapkan buffering sendiri dan logika penanganan kesalahan.
Pustaka logger Fluent berikut mendukung protokol Fluent Forward dan dapat digunakan untuk mengirim log langsung ke: Fluent Bit
+ **Go** — [fluent-logger-golang](https://github.com/fluent/fluent-logger-golang)
+ **Python** – [fluent-logger-python](https://github.com/fluent/fluent-logger-python)
+ **Jawa** — [fluent-logger-java](https://github.com/fluent/fluent-logger-java)
+ **Node.js** – [fluent-logger-node](https://github.com/fluent/fluent-logger-node)
+ **Ruby** – [fluent-logger-ruby](https://github.com/fluent/fluent-logger-ruby)
## Konfigurasikan batas buffer Docker
Saat Anda membuat definisi tugas, Anda dapat menentukan jumlah baris log yang di-buffer dalam memori dengan menentukan nilainya. `log-driver-buffer-limit` Ini mengontrol buffer antara Docker dan. Fluent Bit Untuk informasi selengkapnya, lihat [Driver logging fluentd](https://docs.docker.com/engine/logging/drivers/fluentd/) di dokumentasi Docker.
Gunakan opsi ini ketika ada throughput tinggi, karena Docker mungkin kehabisan memori buffer dan membuang pesan buffer sehingga dapat menambahkan pesan baru.
Pertimbangkan hal berikut saat menggunakan opsi ini:
+ Opsi ini didukung pada jenis EC2 dan Fargate dengan `1.4.0` versi platform atau yang lebih baru.
+ Opsi ini hanya valid ketika `logDriver` disetel ke`awsfirelens`.
+ Batas buffer default adalah baris `1048576` log.
+ Batas buffer harus lebih besar dari atau sama dengan `0` dan kurang dari garis `536870912` log.
+ Jumlah maksimum memori yang digunakan untuk buffer ini adalah produk dari ukuran setiap baris log dan ukuran buffer. Misalnya, jika baris log aplikasi rata-rata `2` KiB, batas buffer 4096 akan menggunakan paling banyak `8` MiB. Jumlah total memori yang dialokasikan pada tingkat tugas harus lebih besar dari jumlah memori yang dialokasikan untuk semua wadah selain buffer memori driver log.
Definisi tugas berikut menunjukkan cara mengkonfigurasi`log-driver-buffer-limit`:
```
{
"containerDefinitions": [
{
"name": "my_service_log_router",
"image": "public.ecr.aws/aws-observability/aws-for-fluent-bit:3",
"cpu": 0,
"memoryReservation": 51,
"essential": true,
"firelensConfiguration": {
"type": "fluentbit"
}
},
{
"essential": true,
"image": "public.ecr.aws/docker/library/httpd:latest",
"name": "app",
"logConfiguration": {
"logDriver": "awsfirelens",
"options": {
"Name": "firehose",
"region": "us-west-2",
"delivery_stream": "my-stream",
"log-driver-buffer-limit": "52428800"
}
},
"dependsOn": [
{
"containerName": "my_service_log_router",
"condition": "START"
}
],
"memoryReservation": 100
}
]
}
```