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 pengoptimalan lanjutan 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, lihatGunakan file konfigurasi khusus. Untuk contoh tambahan, lihat FireLens contoh Amazon ECS di GitHub.

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 dalam Fluent Bit dokumentasi dan Apa itu Potongan? 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

[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 dalam Fluent Bit dokumentasi dan Memory Buffering Only 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 dalam dokumentasi. Fluent Bit

Filesystem buffering memberikan keuntungan sebagai berikut:

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:

Untuk informasi selengkapnya, lihat Filesystem Buffering dalam Fluent Bit dokumentasi dan Filesystem dan Memory Buffering di repositori for examples. 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 untuk mengantri catatan dan mereka 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:

Untuk mengamati throughput puncak dan memilih ukuran buffer yang sesuai, gunakan sampel FireLens ukuran-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+buffer (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:

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

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:

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 Mengkonfigurasi waktu tunggu untuk mencoba lagi dan Jaringan dalam Fluent Bit dokumentasi.

GraceParameter di [SERVICE] bagian mengatur waktu Fluent Bit menunggu selama shutdown untuk menyiram data buffer. GracePeriode 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.

Catatan terbaru ditolak

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

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.

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 dalam Fluent Bit dokumentasi.

Pencatatan multi-tujuan 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 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:

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

Untuk informasi selengkapnya, lihat Ekor dalam Fluent Bit dokumentasi. Untuk praktik terbaik, lihat Konfigurasi ekor dengan praktik terbaik 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:

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 kestdout. Pendekatan ini melewati lapisan driver logging Docker, yang memberikan manfaat berikut:

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

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 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
        }
    ]
}