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 dalam skala membutuhkan penyetelan konfigurasinya.

Bagian ini mencakup teknik peng Fluent Bit optimalan lanjutan untuk menangani throughput log tinggi sambil menjaga stabilitas sistem dan memastikan tidak ada kehilangan data.

Untuk informasi tentang cara menggunakan file konfigurasi khusus dengan FireLens, lihatGunakan file konfigurasi khusus. Untuk contoh tambahan, lihat FireLens contoh Amazon ECS di GitHub.

Memahami potongan

Fluent Bitmemproses data dalam unit yang disebut potongan. 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 buffer memori. Untuk skenario throughput tinggi atau produksi, buffering sistem file memberikan ketahanan yang lebih baik.

Untuk informasi selengkapnya, lihat Potongan dalam Fluent Bit dokumentasi dan Apa itu Chunk? di repositori AWS untuk Fluent Bit contoh.

Penyangga 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 input buffer memori:

[INPUT]
    Name          tcp
    Tag           ApplicationLogs
    Port          5170
    storage.type  memory
    Mem_Buf_Limit 5MB

[input] tcp.1 paused (mem buf overlimit)

Memori buffering cocok untuk kasus penggunaan sederhana dengan throughput log rendah hingga sedang. Untuk skenario throughput tinggi atau produksi di mana kehilangan data menjadi masalah, gunakan buffering sistem file sebagai gantinya.

Untuk informasi selengkapnya, lihat Buffering dan Mem ori dalam Fluent Bit dokumentasi dan Memory Buffering Only di repositori AWS untuk Fluent Bit contoh.

Buffering 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 Penyimpanan dalam dokumentasiFluent Bit.

Filesystem buffering memberikan keuntungan sebagai berikut:

Untuk mengaktifkan buffering sistem file, berikan file Fluent Bit konfigurasi khusus. 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 utama:

Untuk informasi selengkapnya, lihat Filesystem Buffering dalam Fluent Bit dokumentasi dan Sistem Berkas dan Buffer Memori di repositori untuk contoh. AWS Fluent Bit

Memahami storage.total_limit_size

storage.total_limit_sizeParameter 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 mereka hilang.

Gunakan rumus berikut untuk menghitung yang sesuai storage.total_limit_size berdasarkan tingkat log 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:

Untuk mengamati throughput puncak dan memilih ukuran buffer yang sesuai, gunakan sampel pengukuran throughput FireLens .

Gunakan rumus, contoh perhitungan, dan pembandingan untuk memilih landasan pacu storage.total_limit_size yang sesuai 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+ buffer (5—10 GB) = 35—40 GB total yang diperlukan. Jika total melebihi penyimpanan yang tersedia, Fluent Bit mungkin gagal mengantri catatan dan mereka akan hilang.

Opsi penyimpanan berikut tersedia:

Untuk informasi selengkapnya tentang volume data, lihatOpsi penyimpanan untuk tugas Amazon ECS.

Optimalkan konfigurasi keluaran

Masalah jaringan, pemadaman layanan, dan pelambatan tujuan dapat mencegah pengiriman log. Konfigurasi output yang tepat memastikan ketahanan tanpa kehilangan data.

Ketika keluaran flush gagal, Fluent Bit dapat mencoba lagi operasi. Parameter berikut mengontrol perilaku coba lagi:

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 danscheduler.cap 60:

Untuk informasi selengkapnya, lihat Mengonfigurasi waktu tunggu untuk coba lagi dan Jaringan dalam Fluent Bit dokumentasi.

GraceParameter di [SERVICE] bagian ini mengatur waktu Fluent Bit menunggu selama shutdown untuk membersihkan data buffer. GracePeriode harus dikoordinasikan dengan wadahstopTimeout. Pastikan bahwa stopTimeout melebihi Grace periode Fluent Bit untuk memungkinkan pembilasan selesai sebelum menerimaSIGKILL. Misalnya, jika Grace 120 detik, atur stopTimeout ke 150 detik.

Contoh berikut menunjukkan Fluent Bit konfigurasi lengkap dengan semua pengaturan yang disarankan 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 keluaran. Rekomendasi konfigurasi dalam panduan ini adalah pendekatan upaya terbaik untuk meminimalkan kehilangan data, tetapi tidak dapat menjamin kerugian nol selama kegagalan yang berkepanjangan. Memahami skenario ini membantu Anda mengonfigurasi Fluent Bit untuk memaksimalkan ketahanan.

Catatan dapat hilang dengan dua cara: catatan tertua dihapus ketika penyimpanan terisi, atau catatan terbaru ditolak ketika sistem tidak dapat menerima lebih banyak data.

Catatan tertua dijatuhkan

Catatan buffer tertua dihapus saat upaya coba ulang habis atau saat ter storage.total_limit_size isi dan perlu memberi ruang untuk data baru.

Catatan terbaru ditolak

Catatan terbaru dijatuhkan ketika ruang disk habis atau ketika input dijeda Mem_Buf_Limit karena.

Praktik terbaik untuk meminimalkan kehilangan data

Pertimbangkan praktik terbaik berikut untuk meminimalkan kehilangan data:

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.

Multi-destination logging 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 kompres i S3 dalam Fluent Bit dokumentasi.

Multi-destination logging dapat memberikan manfaat berikut:

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 gagal terakumulasi di buffer sistem file untuk dicoba lagi nanti.

Gunakan logging berbasis file dengan plugin input tail

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 melewati lapisan driver logging Docker sepenuhnya.

File-based logging dengan plugin tail memberikan manfaat berikut:

Untuk menggunakan pendekatan ini, aplikasi Anda harus menulis log ke file alih-alihstdout. Baik wadah aplikasi maupun 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:

Untuk informasi selengkapnya, lihat T ail dalam Fluent Bit dokumentasi. Untuk praktik terbaik, lihat konfigurasi Tail dengan praktik terbaik di panduan AWS pemec Fluent Bit ahan masalah.

Masuk langsung ke FireLens

Ketika driver awsfirelens log ditentukan dalam definisi tugas, agen kontainer Amazon ECS menyuntikkan variabel lingkungan berikut ke dalam wadah:

Anda dapat menggunakan variabel lingkungan ini untuk masuk langsung ke router Fluent Bit log dari kode aplikasi Anda menggunakan protokol Fluent Forward, alih-alih menulis kestdout. Pendekatan ini melewati lapisan driver logging Docker, yang memberikan manfaat berikut:

Pustaka Fluent logger berikut mendukung protokol Fluent Forward dan dapat digunakan untuk mengirim log langsung keFluent Bit:

Konfigurasikan batas buffer Docker

Saat Anda membuat definisi tugas, Anda dapat menentukan jumlah baris log yang disangga dalam memori dengan menentukan nilai dilog-driver-buffer-limit. Ini mengontrol buffer antara Docker danFluent Bit. Untuk informasi selengkapnya, lihat Driver logging 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:

Definisi tugas berikut menunjukkan cara mengkonfigurasilog-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
        }
    ]
}