Konfigurasikan dan gunakan log standar (log akses) - Amazon CloudFront

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Konfigurasikan dan gunakan log standar (log akses)

Anda dapat mengonfigurasi CloudFront untuk membuat file log yang berisi informasi terperinci tentang setiap permintaan pengguna yang CloudFront diterima. Ini disebut log standar, juga dikenal sebagai log akses. Jika Anda mengaktifkan log standar, Anda juga dapat menentukan bucket Amazon S3 tempat Anda CloudFront ingin menyimpan file.

Anda dapat mengaktifkan log standar saat membuat atau memperbarui distribusi. Untuk informasi selengkapnya, lihat Pencatatan log.

CloudFront juga menawarkan log real-time, yang memberi Anda informasi tentang permintaan yang dibuat ke distribusi secara real time (log dikirimkan dalam hitungan detik setelah menerima permintaan). Anda dapat menggunakan log waktu nyata untuk memantau, menganalisis, dan mengambil tindakan berdasarkan kinerja pengiriman konten. Untuk informasi selengkapnya, lihat Gunakan log waktu nyata.

Cara kerja pencatatan standar

Diagram berikut menunjukkan bagaimana CloudFront log informasi tentang permintaan untuk objek Anda.

Aliran dasar untuk log akses

Berikut ini menjelaskan bagaimana CloudFront log informasi tentang permintaan untuk objek Anda, seperti yang diilustrasikan dalam diagram sebelumnya.

  1. Dalam diagram ini, Anda memiliki dua situs web, A dan B, dan dua CloudFront distribusi yang sesuai. Pengguna meminta objek Anda menggunakan URL yang terkait dengan distribusi Anda.

  2. CloudFront merutekan setiap permintaan ke lokasi tepi yang sesuai.

  3. CloudFront menulis data tentang setiap permintaan ke file log khusus untuk distribusi itu. Dalam contoh ini, informasi tentang permintaan yang terkait dengan Distribusi A masuk ke file log hanya untuk Distribusi A, dan informasi tentang permintaan yang terkait dengan Distribusi B masuk ke file log hanya untuk Distribusi B.

  4. CloudFront menyimpan file log secara berkala untuk distribusi di bucket Amazon S3 yang Anda tentukan saat mengaktifkan logging. CloudFront kemudian mulai menyimpan informasi tentang permintaan berikutnya dalam file log baru untuk distribusi.

Jika tidak ada pengguna yang mengakses konten Anda selama satu jam tertentu, Anda tidak akan menerima file log selama satu jam tersebut.

Setiap entri dalam file log memberikan detail tentang permintaan tunggal. Untuk informasi lebih lanjut tentang format file log, lihat Format file log standar.

catatan

Kami menyarankan Anda menggunakan log untuk memahami sifat permintaan untuk konten Anda, bukan sebagai akuntansi lengkap dari semua permintaan. CloudFront memberikan log akses dengan upaya terbaik. Entri log untuk permintaan tertentu mungkin dikirim dalam waktu lama setelah permintaan diproses secara aktual dan, dalam kasus yang jarang, entri log mungkin tidak dikirimkan sama sekali. Ketika entri log dihilangkan dari log akses, jumlah entri dalam log akses tidak akan cocok dengan penggunaan yang muncul dalam laporan AWS penagihan dan penggunaan.

Pilih bucket Amazon S3 untuk log standar

Saat mengaktifkan pencatatan untuk distribusi, Anda menentukan bucket Amazon S3 tempat Anda CloudFront ingin menyimpan file log. Jika Anda menggunakan Amazon S3 sebagai asal Anda, sebaiknya gunakan bucket terpisah untuk file log Anda.

Anda dapat menyimpan file log untuk beberapa distribusi dalam buket yang sama. Saat Anda mengaktifkan log, Anda dapat menentukan prefiks opsional untuk nama file, sehingga Anda dapat terus melacak file log yang terkait dengan distribusi yang mana.

Tentang memilih ember S3
  • Bucket Anda harus mengaktifkan daftar kontrol akses (ACL). Jika Anda memilih bucket tanpa ACL diaktifkan dari CloudFront konsol, pesan kesalahan akan muncul. Lihat Izin yang diperlukan untuk mengonfigurasi logging standar dan mengakses file log.

  • Jangan memilih bucket Amazon S3 dengan Kepemilikan Objek S3 yang disetel ke pemilik bucket yang diberlakukan. Pengaturan itu menonaktifkan ACL untuk bucket dan objek di dalamnya, yang CloudFront mencegah pengiriman file log ke bucket.

  • Jangan memilih bucket Amazon S3 berikut ini. Wilayah AWS CloudFront tidak mengirimkan log standar ke ember di Wilayah ini:

    • Afrika (Cape Town)

    • Asia Pasifik (Hong Kong)

    • Asia Pasifik (Hyderabad)

    • Asia Pasifik (Jakarta)

    • Asia Pasifik (Melbourne)

    • Kanada Barat (Calgary)

    • Eropa (Milan)

    • Eropa (Spanyol)

    • Eropa (Zürich)

    • Israel (Tel Aviv)

    • Timur Tengah (Bahrain)

    • Middle East (UAE)

Izin yang diperlukan untuk mengonfigurasi logging standar dan mengakses file log

penting

Mulai April 2023, Anda harus mengaktifkan S3 ACL untuk bucket S3 baru yang digunakan untuk log standar. CloudFront Anda dapat mengaktifkan ACL saat membuat bucket, atau mengaktifkan ACL untuk bucket yang sudah ada.

Untuk informasi selengkapnya tentang perubahan, lihat Pengaturan default untuk bucket S3 baru FAQ di Panduan Pengguna Amazon Simple Storage Service dan Heads-Up: Perubahan Keamanan Amazon S3 Akan Datang pada bulan April 2023 di Blog Berita.AWS

Anda Akun AWS harus memiliki izin berikut untuk bucket yang Anda tentukan untuk file log:

  • ACL untuk ember harus memberi AndaFULL_CONTROL. Jika Anda adalah pemilik bucket, akun Anda memiliki izin ini secara default. Jika tidak, pemilik keranjang harus memperbarui ACL untuk buket.

  • s3:GetBucketAcl

  • s3:PutBucketAcl

ACL untuk buket

Saat Anda membuat atau memperbarui distribusi dan mengaktifkan pencatatan, CloudFront gunakan izin ini untuk memperbarui ACL untuk bucket guna memberikan izin awslogsdelivery akunFULL_CONTROL. awslogsdelivery akun menulis file log ke dalam buket. Jika akun Anda tidak memiliki izin yang diperlukan untuk memperbarui ACL, membuat atau memperbarui distribusi akan gagal.

Dalam beberapa keadaan, jika Anda secara program mengirimkan permintaan untuk membuat buket tetapi buket dengan nama yang ditentukan sudah ada, S3 mengatur ulang izin pada buket ke nilai default. Jika Anda mengonfigurasi CloudFront untuk menyimpan log akses di bucket S3 dan Anda berhenti mendapatkan log di bucket itu, periksa izin di bucket untuk memastikan bahwa CloudFront memiliki izin yang diperlukan.

Memulihkan ACL untuk ember

Jika Anda menghapus izin untuk awslogsdelivery akun, tidak CloudFront akan dapat menyimpan log ke bucket S3. Untuk mengaktifkan CloudFront untuk mulai menyimpan log untuk distribusi Anda lagi, pulihkan izin ACL dengan melakukan salah satu hal berikut:

  • Nonaktifkan pencatatan untuk distribusi Anda CloudFront, lalu aktifkan lagi. Untuk informasi selengkapnya, lihat Pencatatan log.

  • Tambahkan izin ACL untuk awslogsdelivery secara manual dengan menavigasi ke bucket S3 di konsol Amazon S3 dan menambahkan izin. Untuk menambahkan ACL untuk awslogsdelivery, Anda harus memberikan ID kanonik untuk akun tersebut, yang merupakan di Wilayah Tiongkok:

    c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

    Untuk informasi selengkapnya tentang menambahkan ACL ke bucket S3, lihat Mengonfigurasi ACL di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

ACL untuk setiap file log

Selain ACL pada buket, ada ACL pada setiap file log. Pemilik keranjang memiliki FULL_CONTROL izin di setiap file log, pemilik distribusi (jika berbeda dari pemilik bucket) tidak memiliki izin, dan awslogsdelivery akun memiliki izin baca dan tulis.

Menonaktifkan log

Jika Anda menonaktifkan logging, CloudFront tidak menghapus ACL baik untuk bucket atau file log. Anda dapat menghapus ACL jika diperlukan.

Kebijakan kunci yang diperlukan untuk bucket SSE-KMS

Jika bucket S3 untuk log standar Anda menggunakan enkripsi sisi server dengan AWS KMS keys (SSE-KMS) menggunakan kunci terkelola pelanggan, Anda harus menambahkan pernyataan berikut ke kebijakan kunci untuk kunci terkelola pelanggan Anda. Hal ini memungkinkan CloudFront untuk menulis file log ke bucket. Anda tidak dapat menggunakan SSE-KMS dengan Kunci yang dikelola AWS karena CloudFront tidak akan dapat menulis file log ke ember.

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "kms:GenerateDataKey*", "Resource": "*" }

Jika bucket S3 untuk log standar Anda menggunakan SSE-KMS dengan Kunci Bucket S3, Anda juga perlu menambahkan izin kms:Decrypt untuk pernyataan kebijakan. Dalam hal ini, pernyataan kebijakan penuh terlihat seperti berikut ini.

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": [ "kms:GenerateDataKey*", "kms:Decrypt" ], "Resource": "*" }

Format nama file

Nama setiap file log yang CloudFront disimpan di bucket Amazon S3 Anda menggunakan format nama file berikut:

<optional prefix>/<distribution ID>.YYYY-MM-DD-HH.unique-ID.gz

Tanggal dan waktu berada dalam Waktu Universal Terkoordinasi (UTC).

Misalnya, jika Anda menggunakan example-prefix karena prefiks, dan ID distribusi Anda adalah EMLARXS9EXAMPLE, nama file Anda terlihat mirip dengan ini:

example-prefix/EMLARXS9EXAMPLE.2019-11-14-20.RT4KCN4SGK9.gz

Saat Anda mengaktifkan pencatatan untuk distribusi, Anda dapat menentukan prefiks opsional untuk nama file, sehingga Anda dapat melacak file log yang terkait dengan distribusi mana. Jika Anda menyertakan nilai untuk awalan file log dan awalan Anda tidak diakhiri dengan garis miring (/), CloudFront tambahkan satu secara otomatis. Jika awalan Anda diakhiri dengan garis miring ke depan, jangan CloudFront tambahkan yang lain.

.gzDi akhir nama file menunjukkan bahwa CloudFront telah dikompresi file log menggunakan gzip.

Waktu pengiriman file log standar

CloudFront memberikan log standar untuk distribusi hingga beberapa kali dalam satu jam. Secara umum, file log berisi informasi tentang permintaan yang CloudFront diterima selama periode waktu tertentu. CloudFront biasanya mengirimkan file log untuk jangka waktu tersebut ke bucket Amazon S3 Anda dalam waktu satu jam setelah peristiwa yang muncul di log. Namun, perhatikan bahwa beberapa atau semua entri file log untuk periode waktu terkadang dapat tertunda hingga 24 jam. Ketika entri log tertunda, CloudFront simpan dalam file log yang nama file termasuk tanggal dan waktu periode di mana permintaan terjadi, bukan tanggal dan waktu ketika file dikirim.

Saat membuat file log, CloudFront konsolidasikan informasi untuk distribusi Anda dari semua lokasi tepi yang menerima permintaan untuk objek Anda selama periode waktu yang dicakup oleh file log.

CloudFront dapat menyimpan lebih dari satu file untuk jangka waktu tergantung pada berapa banyak permintaan yang CloudFront diterima untuk objek yang terkait dengan distribusi.

CloudFront mulai mengirimkan log akses dengan andal sekitar empat jam setelah Anda mengaktifkan pencatatan. Anda mungkin mendapatkan beberapa log akses sebelum waktu tersebut.

catatan

Jika tidak ada pengguna yang meminta objek Anda selama periode waktu tersebut, Anda tidak akan menerima file log untuk periode tersebut.

CloudFront juga menawarkan log real-time, yang memberi Anda informasi tentang permintaan yang dibuat ke distribusi secara real time (log dikirimkan dalam hitungan detik setelah menerima permintaan). Anda dapat menggunakan log waktu nyata untuk memantau, menganalisis, dan mengambil tindakan berdasarkan kinerja pengiriman konten. Untuk informasi selengkapnya, lihat Gunakan log waktu nyata.

Bagaimana permintaan dicatat saat URL atau header permintaan melebihi ukuran maksimum

Jika ukuran total semua header permintaan, termasuk cookie, melebihi 20 KB, atau jika URL melebihi 8192 byte, tidak CloudFront dapat mengurai permintaan sepenuhnya dan tidak dapat mencatat permintaan. Karena permintaan tersebut tidak dicatat, Anda tidak akan melihat kode status kesalahan HTTP kembali.

Jika badan permintaan melebihi ukuran maksimum, permintaan akan dicatat, termasuk kode status kesalahan HTTP.

Menganalisis log standar

Karena Anda dapat menerima beberapa log akses per jam, kami sarankan Anda menggabungkan semua file log yang Anda terima untuk periode waktu tertentu ke dalam satu file. Anda kemudian dapat menganalisis data untuk periode tersebut dengan lebih akurat dan lengkap.

Salah satu cara untuk menganalisis log akses Anda adalah dengan menggunakan Amazon Athena. Athena adalah layanan kueri interaktif yang dapat membantu Anda menganalisis data untuk AWS layanan, termasuk. CloudFront Untuk mempelajari selengkapnya, lihat Menanyakan CloudFront Log Amazon di Panduan Pengguna Amazon Athena.

Selain itu, posting AWS blog berikut membahas beberapa cara untuk menganalisis log akses.

penting

Kami menyarankan Anda menggunakan log untuk memahami sifat permintaan untuk konten Anda, bukan sebagai akuntansi lengkap dari semua permintaan. CloudFront memberikan log akses dengan upaya terbaik. Entri log untuk permintaan tertentu mungkin dikirim dalam waktu lama setelah permintaan diproses secara aktual dan, dalam kasus yang jarang, entri log mungkin tidak dikirimkan sama sekali. Ketika entri log dihilangkan dari log akses, jumlah entri dalam log akses tidak akan cocok dengan penggunaan yang muncul dalam laporan AWS penggunaan dan penagihan.

Edit pengaturan logging standar

Anda dapat mengaktifkan atau menonaktifkan logging, mengubah bucket Amazon S3 tempat log Anda disimpan, dan mengubah awalan untuk file log menggunakan CloudFront konsol atau API. CloudFront Perubahan Anda pada pengaturan log mulai berlaku dalam 12 jam.

Untuk informasi selengkapnya, lihat topik berikut.

  • Untuk memperbarui distribusi menggunakan CloudFront konsol, lihatPerbarui distribusi.

  • Untuk memperbarui distribusi menggunakan CloudFront API, lihat UpdateDistributiondi Referensi Amazon CloudFront API.

Hapus file log standar dari bucket Amazon S3

CloudFront tidak secara otomatis menghapus file log dari bucket Amazon S3 Anda. Untuk informasi tentang menghapus file log dari keranjang Amazon S3, lihat topik berikut:

  • Menggunakan konsol Amazon S3: Menghapus Objek di Panduan Pengguna Amazon Simple Storage Service Console.

  • Menggunakan REST API: DeleteObjectdi Referensi API Amazon Simple Storage Service.

Format file log standar

Setiap entri dalam file log memberikan detail tentang permintaan penampil tunggal. File log memiliki karakteristik sebagai berikut:

  • Gunakan Format file log yang diperluas W3C.

  • Berisi nilai yang dipisahkan dengan tab.

  • Berisi catatan yang tidak selalu kronologis.

  • Berisi dua baris header: satu dengan versi format file, dan satu lagi yang mencantumkan kolom W3C yang disertakan dalam setiap catatan.

  • Berisi URL berkode setara untuk spasi dan karakter tertentu lainnya dalam nilai kolom.

    Ekuivalen berkode URL digunakan untuk karakter berikut ini:

    • Kode karakter ASCII 0 melalui 32, inklusif

    • Kode karakter ASCII 127 dan lebih tinggi

    • Semua karakter dalam tabel berikut

    Standar pengkodean URL ditetapkan dalam RFC 1738.

Nilai yang dikodekan URL

Karakter

%3C

<

%3E

>

%22

"

%23

#

%25

%

%7B

{

%7D

}

%7C

|

%5C

\

%5E

^

%7E

~

%5B

[

%5D

]

%60

`

%27

'

%20

yang lebih besar

Bidang file log standar

File log untuk distribusi berisi 33 bidang. Daftar berikut berisi setiap nama kolom, secara berurutan, bersama dengan deskripsi informasi di bidang tersebut.

  1. date

    Tanggal di mana peristiwa terjadi dalam format YYYY-MM-DD. Sebagai contoh, 2019-06-30. Tanggal dan waktu berada dalam Waktu Universal Terkoordinasi (UTC). Untuk WebSocket koneksi, ini adalah tanggal ketika koneksi ditutup.

  2. time

    Waktu ketika CloudFront server selesai menanggapi permintaan (dalam UTC), misalnya,. 01:42:39 Untuk WebSocket koneksi, ini adalah waktu ketika koneksi ditutup.

  3. x-edge-location

    Lokasi tepi yang melayani permintaan. Setiap lokasi tepi diidentifikasi dengan kode tiga huruf dan nomor yang diberikan secara sewenang-wenang (misalnya, DFW3). Kode tiga huruf biasanya sesuai dengan kode bandara International Air Transport Association (IATA) untuk bandara di dekat lokasi geografis lokasi tepi. (Ringkasan ini mungkin berubah di masa mendatang.)

  4. sc-bytes

    Jumlah total byte yang dikirim server ke penampil sebagai respons terhadap permintaan, termasuk header. Untuk WebSocket koneksi, ini adalah jumlah total byte yang dikirim dari server ke klien melalui koneksi.

  5. c-ip

    Alamat IP penampil yang membuat permintaan, misalnya, 192.0.2.183 atau 2001:0db8:85a3::8a2e:0370:7334. Jika penampil menggunakan proksi HTTP atau penyeimbang beban untuk mengirim permintaan, nilai bidang ini adalah alamat IP dari perantara atau penyeimbang beban. Lihat juga x-forwarded-for bidang.

  6. cs-method

    Metode permintaan HTTP yang diterima dari penampil.

  7. cs(Host)

    Nama domain CloudFront distribusi (misalnya, d111111abcdef8.cloudfront.net).

  8. cs-uri-stem

    Bagian URL permintaan yang mengidentifikasi jalur dan objek (misalnya, /images/cat.jpg). Tanda tanya (?) di URL dan string kueri tidak disertakan dalam log.

  9. sc-status

    Berisi salah satu nilai berikut:

    • Kode status HTTP dari respon server (misalnya,200).

    • 000, yang menunjukkan bahwa penampil menutup koneksi sebelum server dapat merespons permintaan. Jika penampil menutup koneksi setelah server mulai mengirim respons, bidang ini berisi kode status HTTP dari respons yang mulai dikirim server.

  10. cs(Referer)

    Nilai dari Referer header dalam permintaan. Ini adalah nama domain yang membuat permintaan. Perujuk umum termasuk mesin pencari, situs web lain yang terhubung langsung ke objek Anda, dan situs web Anda sendiri.

  11. cs(User-Agent)

    Nilai dari User-Agent header dalam permintaan. User-Agent header mengidentifikasi sumber permintaan, seperti jenis perangkat dan peramban yang mengirimkan permintaan atau, jika permintaan berasal dari mesin pencari, mesin pencari mana.

  12. cs-uri-query

    Bagian utas kueri URL permintaan, jika ada.

    Ketika URL tidak berisi string kueri, nilai bidang ini adalah tanda hubung (-). Untuk informasi selengkapnya, lihat Konten cache berdasarkan parameter string kueri.

  13. cs(Cookie)

    Cookie header dalam permintaan, termasuk nama—pasangan nilai dan atribut terkait.

    Jika Anda mengaktifkan pencatatan cookie, CloudFront catat cookie di semua permintaan terlepas dari cookie mana yang Anda pilih untuk diteruskan ke asal. Ketika permintaan tidak menyertakan header cookie, nilai bidang ini adalah tanda hubung (-). Untuk informasi selengkapnya tentang cookie, lihat Konten cache berdasarkan cookie.

  14. x-edge-result-type

    Bagaimana server menggolongkan respons setelah byte terakhir meninggalkan server. Dalam beberapa kasus, jenis hasil dapat berubah antara waktu saat server siap mengirimkan respons dan waktu saat server selesai mengirimkan respons. Lihat juga x-edge-response-result-type bidang.

    Misalnya, dalam streaming HTTP, seandainya server menemukan segmen aliran di cache. Dalam skenario itu, nilai kolom ini biasanya adalah Hit. Namun, jika penampil menutup koneksi sebelum server mengirimkan seluruh segmen, jenis hasil akhir (dan nilai kolom ini) adalah Error.

    WebSocket koneksi akan memiliki nilai Miss untuk bidang ini karena konten tidak dapat di-cache dan diproksi langsung ke asal.

    Nilai yang mungkin termasuk:

    • Hit – Server melayani objek ke penampil dari cache.

    • RefreshHit – Server menemukan objek dalam cache tetapi objek telah kedaluwarsa, sehingga server menghubungi asal untuk memverifikasi bahwa cache memiliki versi terbaru dari objek tersebut.

    • Miss – Permintaan tidak dapat dipenuhi oleh objek di dalam cache, sehingga server meneruskan permintaan ke asal dan mengembalikan hasil ke penampil.

    • LimitExceeded— Permintaan ditolak karena CloudFront kuota (sebelumnya disebut sebagai batas) terlampaui.

    • CapacityExceededServer mengembalikan kode status HTTP 503 karena tidak memiliki kapasitas yang cukup pada saat permintaan untuk melayani objek.

    • Error – Biasanya, ini berarti permintaan tersebut mengakibatkan kesalahan klien (nilai sc-status bidang ada di 4xx atau kesalahan server (nilai sc-status bidang ada di 5xx beragam). Jika nilai sc-status adalah 200, atau jika nilai bidang ini adalah Error dan nilai dari x-edge-response-result-type bidang tidak Error, artinya permintaan HTTP berhasil tetapi klien terputus sebelum menerima semua byte.

    • Redirect – Server mengarahkan penampil dari HTTP ke HTTPS sesuai dengan pengaturan distribusi.

  15. x-edge-request-id

    String buram yang secara unik mengidentifikasi permintaan. CloudFront juga mengirimkan string ini di header x-amz-cf-id respons.

  16. x-host-header

    Nilai yang disertakan oleh penampil dalam Host header permintaan. Jika Anda menggunakan nama CloudFront domain di URL objek Anda (seperti d111111abcdef8.cloudfront.net), bidang ini berisi nama domain tersebut. Jika Anda menggunakan nama domain alternatif (CNames) di URL objek Anda (seperti www.example.com), bidang ini berisi nama domain alternatif.

    Jika Anda menggunakan nama domain alternatif, lihat cs(Host) di bidang 7 untuk nama domain yang terkait dengan distribusi Anda.

  17. cs-protocol

    Protokol permintaan penampil (http, https, ws, atau wss).

  18. cs-bytes

    Jumlah total byte data yang disertakan oleh penampil, termasuk header. Untuk WebSocket koneksi, ini adalah jumlah total byte yang dikirim dari klien ke server pada koneksi.

  19. time-taken

    Jumlah detik (hingga seperseribu detik, misalnya, 0,082) dari saat server menerima permintaan penampil hingga saat server menulis byte terakhir dari respons ke antrian output, yang diukur pada server. Dari perspektif penampil, total waktu untuk mendapatkan respons penuh akan lebih lama dari nilai ini karena latensi jaringan dan buffering TCP.

  20. x-forwarded-for

    Jika penampil menggunakan proksi HTTP atau timbangantor beban untuk mengirim permintaan, nilai c-ip adalah alamat IP dari perantara atau pemukul beban. Dalam hal ini, bidang ini adalah alamat IP penampil yang memulai permintaan. Bidang ini dapat berisi beberapa alamat IP yang dipisahkan koma. Setiap alamat IP dapat berupa alamat IPv4 (misalnya,192.0.2.183) atau alamat IPv6 (misalnya,). 2001:0db8:85a3::8a2e:0370:7334

    Jika penampil tidak menggunakan proksi HTTP atau penyeimbang beban, nilai bidang ini adalah tanda hubung (-).

  21. ssl-protocol

    Saat permintaan menggunakan HTTPS, kolom ini berisi protokol SSL/TLS yang dinegosiasikan penampil dan server untuk mentransmisikan permintaan dan respons. Untuk daftar kemungkinan nilai, lihat protokol SSL/TLS yang didukung dalam Protokol dan cipher yang didukung antara pemirsa dan CloudFront.

    Saat cs-protocol di kolom 17 adalah http, nilai untuk kolom ini adalah tanda hubung (-).

  22. ssl-cipher

    Saat permintaan menggunakan HTTPS, kolom ini berisi cipher SSL/TLS yang dinegosiasikan penampil dan server untuk mengenkripsi permintaan dan respons. Untuk daftar kemungkinan nilai, lihat cipher SSL/TLS yang didukung dalam Protokol dan cipher yang didukung antara pemirsa dan CloudFront.

    Saat cs-protocol di kolom 17 adalah http, nilai untuk kolom ini adalah tanda hubung (-).

  23. x-edge-response-result-type

    Bagaimana server mengklasifikasikan respons tepat sebelum mengembalikan respons ke penampil. Lihat juga x-edge-result-type bidang. Nilai yang mungkin termasuk:

    • Hit – Server melayani objek ke penampil dari cache.

    • RefreshHit – Server menemukan objek dalam cache tetapi objek telah kedaluwarsa, sehingga server menghubungi asal untuk memverifikasi bahwa cache memiliki versi terbaru dari objek tersebut.

    • Miss – Permintaan tidak dapat dipenuhi oleh objek dalam cache, sehingga server meneruskan permintaan ke server asal dan mengembalikan hasil ke penampil.

    • LimitExceeded— Permintaan ditolak karena CloudFront kuota (sebelumnya disebut sebagai batas) terlampaui.

    • CapacityExceeded— Server mengembalikan kesalahan 503 karena tidak memiliki kapasitas yang cukup pada saat permintaan untuk melayani objek.

    • Error – Biasanya, ini berarti permintaan tersebut mengakibatkan kesalahan klien (nilai sc-status bidang ada di 4xx atau kesalahan server (nilai sc-status bidang ada di 5xx beragam).

      Jika nilai x-edge-result-type adalah Error dan nilai bidang ini tidak Error, klien terputus sebelum menyelesaikan unduhan.

    • Redirect – Server mengarahkan penampil dari HTTP ke HTTPS sesuai dengan pengaturan distribusi.

  24. cs-protocol-version

    Versi HTTP yang ditentukan penampil dalam permintaan. Nilai yang mungkin termasuk adalah HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0, dan HTTP/3.0.

  25. fle-status

    Saat enkripsi tingkat lapangan dikonfigurasi untuk distribusi, bidang ini berisi kode yang menunjukkan apakah badan permintaan berhasil diproses. Ketika server berhasil memproses isi permintaan, mengenkripsi nilai dalam bidang yang ditentukan, dan meneruskan permintaan ke asal, nilai bidang ini adalah Processed. Nilai dari x-edge-result-type masih dapat menunjukkan kesalahan sisi klien atau sisi server dalam kasus ini.

    Nilai yang mungkin untuk kolom ini meliputi:

    • ForwardedByContentType – Server meneruskan permintaan ke tempat asal tanpa mengurai atau enkripsi karena tidak ada jenis konten yang dikonfigurasi.

    • ForwardedByQueryArgs— Server meneruskan permintaan ke asal tanpa parsing atau enkripsi karena permintaan berisi argumen kueri yang tidak ada dalam konfigurasi untuk enkripsi tingkat lapangan.

    • ForwardedDueToNoProfile – Server meneruskan permintaan ke tempat asal tanpa mengurai atau enkripsi karena tidak ada profil yang ditentukan dalam konfigurasi untuk enkripsi tingkat lapangan.

    • MalformedContentTypeClientError – Server menolak permintaan dan mengembalikan kode status HTTP 400 ke penampil karena nilai Content-Type header dalam format yang tidak valid.

    • MalformedInputClientError – Server menolak permintaan dan mengembalikan kode status HTTP 400 ke penampil karena bodi permintaan dalam format yang tidak valid.

    • MalformedQueryArgsClientError – Server menolak permintaan dan mengembalikan kode status HTTP 400 ke penampil karena argumen kueri kosong atau dalam format yang tidak valid.

    • RejectedByContentType – Server menolak permintaan dan mengembalikan kode status HTTP 400 ke penampil karena tidak ada jenis konten yang ditentukan dalam konfigurasi untuk enkripsi tingkat lapangan.

    • RejectedByQueryArgs – Server menolak permintaan dan mengembalikan kode status HTTP 400 ke penampil karena tidak ada alasan kueri yang ditentukan dalam konfigurasi untuk enkripsi tingkat lapangan.

    • ServerError – Server asal mengembalikan kesalahan.

    Jika permintaan melebihi kuota enkripsi tingkat lapangan (sebelumnya disebut sebagai batas), bidang ini berisi salah satu kode kesalahan berikut, dan server mengembalikan kode status HTTP 400 ke penampil. Untuk daftar kuota saat ini pada enkripsi tingkat lapangan, lihat Kuotas pada enkripsi tingkat lapangan.

    • FieldLengthLimitClientError – Kolom yang dikonfigurasi untuk dienkripsi melebihi panjang maksimum yang diizinkan.

    • FieldNumberLimitClientError – Permintaan agar distribusi dikonfigurasi untuk mengenkripsi berisi lebih dari jumlah kolom yang diperbolehkan.

    • RequestLengthLimitClientError – Panjang badan permintaan melebihi panjang maksimum yang diperbolehkan ketika enkripsi tingkat lapangan dikonfigurasi.

    Jika enkripsi tingkat bidang tidak dikonfigurasi untuk distribusi, nilai bidang ini adalah tanda hubung (-).

  26. fle-encrypted-fields

    Jumlah bidang enkripsi tingkat lapangan yang dienkripsi dan diteruskan oleh server ke asal. CloudFront server mengalirkan permintaan yang diproses ke asal saat mereka mengenkripsi data, sehingga bidang ini dapat memiliki nilai meskipun nilainya fle-status adalah kesalahan.

    Jika enkripsi tingkat bidang tidak dikonfigurasi untuk distribusi, nilai bidang ini adalah tanda hubung (-).

  27. c-port

    Nomor port permintaan dari penampil.

  28. time-to-first-byte

    Jumlah detik antara menerima permintaan dan menulis byte pertama respons, sebagaimana diukur pada server.

  29. x-edge-detailed-result-type

    Bidang ini berisi nilai yang sama dengan x-edge-result-type bidang, kecuali dalam kasus berikut:

    • Ketika objek disajikan ke penampil dari lapisan Origin Shield, bidang ini berisiOriginShieldHit.

    • Ketika objek tidak dalam CloudFront cache dan respons dihasilkan oleh permintaan asal fungsi Lambda @Edge, bidang ini berisi. MissGeneratedResponse

    • Ketika nilai bidang adalahError, x-edge-result-type bidang ini berisi salah satu nilai berikut dengan informasi lebih lanjut tentang kesalahan:

      • AbortedOrigin – Server mengalami masalah dengan asal usul.

      • ClientCommError – Respons ke penampil terganggu karena masalah komunikasi antara server dan penampil.

      • ClientGeoBlocked— Distribusi dikonfigurasi untuk menolak permintaan dari lokasi geografis pemirsa.

      • ClientHungUpRequest – Penampil berhenti sebelum waktunya saat mengirim permintaan.

      • Error— Terjadi kesalahan yang jenis kesalahannya tidak sesuai dengan kategori lainnya. Jenis kesalahan ini dapat terjadi saat server menjalankan respons kesalahan dari cache.

      • InvalidRequest – Server menerima permintaan yang tidak valid dari penampil.

      • InvalidRequestBlocked – Akses ke sumber daya yang diminta diblokir.

      • InvalidRequestCertificate— Distribusi tidak cocok dengan sertifikat SSL/TLS tempat koneksi HTTPS dibuat.

      • InvalidRequestHeader Permintaan mengandung header yang tidak valid.

      • InvalidRequestMethod – Distribusi tidak dikonfigurasi untuk menangani metode permintaan HTTP yang digunakan. Ini dapat terjadi ketika distribusi hanya mendukung permintaan yang dapat disimpan.

      • OriginCommError— Permintaan habis waktu saat menghubungkan ke asal, atau membaca data dari asal.

      • OriginConnectError— Server tidak dapat terhubung ke asal.

      • OriginContentRangeLengthErrorContent-Length Header dalam respons asal tidak cocok dengan panjang di Content-Range header.

      • OriginDnsError— Server tidak dapat menyelesaikan nama domain asal.

      • OriginError - Asal memberikan jawaban yang salah.

      • OriginHeaderTooBigError – Header yang dikembalikan oleh asalnya terlalu besar untuk diproses oleh server edge.

      • OriginInvalidResponseError – Asal memberikan respons tidak valid.

      • OriginReadError— Server tidak bisa membaca dari asalnya.

      • OriginWriteError— Server tidak bisa menulis ke asal.

      • OriginZeroSizeObjectError – Objek seukuran nol yang dikirim dari sumber mengakibatkan kesalahan.

      • SlowReaderOriginError – Penampil lambat untuk membaca pesan yang menyebabkan kesalahan asal.

  30. sc-content-type

    Nilai HTTP Content-Type header respons.

  31. sc-content-len

    Nilai HTTP Content-Length header respons.

  32. sc-range-start

    Saat tanggapan berisi HTTP Content-Range header, kolom ini berisi nilai mulai rentang.

  33. sc-range-end

    Saat tanggapan berisi HTTP Content-Range header, kolom ini berisi nilai akhir rentang.

Berikut ini contoh file log untuk distribusi:

#Version: 1.0 #Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit k6WGMNkEzR5BEM_SaF47gjtX9zBDO2m349OY2an0QPEaUum1ZOLrow== d111111abcdef8.cloudfront.net https 23 0.000 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.000 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit f37nTMVvnKvV2ZSvEsivup_c2kZ7VXzYdjC-GUQZ5qNs-89BlWazbw== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-13 22:36:27 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net /favicon.ico 502 http://www.example.com/ Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 1pkpNfBQ39sYMnjjUQjmH2w1wdJnbHYTbag21o_3OfcQgPzdL2RSSQ== www.example.com http 675 0.102 - - - Error HTTP/1.1 - - 25260 0.102 OriginDnsError text/html 507 - - 2019-12-13 22:36:26 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 3AqrZGCnF_g0-5KOvfA7c9XLcf4YGvMFSeFdIetR1N_2y8jSis8Zxg== www.example.com http 735 0.107 - - - Error HTTP/1.1 - - 3802 0.107 OriginDnsError text/html 507 - - 2019-12-13 22:37:02 SEA19-C2 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - curl/7.55.1 - - Error kBkDzGnceVtWHqSCqBUqtA_cEs2T3tFUBbnBNkB9El_uVRhHgcZfcw== www.example.com http 387 0.103 - - - Error HTTP/1.1 - - 12644 0.103 OriginDnsError text/html 507 - -

Biaya untuk log standar

Pencatatan standar adalah fitur opsional dari CloudFront. Tidak ada biaya tambahan untuk mengaktifkan pencatatan standar. Namun, Anda mengumpulkan biaya Amazon S3 biasa untuk menyimpan dan mengakses file di Amazon S3 (Anda dapat menghapusnya kapan saja).

Untuk informasi selengkapnya tentang harga Amazon S3, lihat Harga Amazon S3.

Untuk informasi selengkapnya tentang CloudFront harga, lihat CloudFront Harga.