View a markdown version of this page

Cross-account Sentralisasi log lintas wilayah - CloudWatch Log Amazon
Konsep sentralisasi dataMenyiapkan sentralisasi logPemantauan dan pemecahan masalah aturan sentralisasi

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

Cross-account Sentralisasi log lintas wilayah

Sentralisasi data Amazon CloudWatch Logs berfungsi AWS Organizations untuk mengumpulkan data log dari beberapa akun anggota ke dalam satu repositori data menggunakan aturan sentralisasi lintas akun dan lintas wilayah. Anda menentukan aturan yang secara otomatis mereplikasi data log dari beberapa akun dan Wilayah AWS ke akun terpusat dalam organisasi Anda. Kemampuan ini menyederhanakan konsolidasi log untuk meningkatkan pemantauan terpusat, analisis, dan kepatuhan di seluruh AWS infrastruktur Anda.

CloudWatch Sentralisasi data log menawarkan fleksibilitas konfigurasi untuk memenuhi persyaratan operasional dan keamanan, seperti kemampuan untuk mengonfigurasi wilayah cadangan selama pengaturan aturan dalam akun tujuan untuk memastikan peningkatan ketahanan. Selain itu, Anda memiliki kontrol penuh atas perilaku enkripsi untuk grup log yang disalin dari akun sumber untuk menangani data yang awalnya dienkripsi dengan kunci KMS yang dikelola pelanggan.

catatan

Fitur sentralisasi CloudWatch log hanya memproses data log baru yang masuk ke akun sumber setelah Anda membuat aturan sentralisasi. Data log historis (log yang ada sebelum pembuatan aturan) tidak terpusat.

Konsep sentralisasi data

Sebelum Anda mulai menggunakan sentralisasi data CloudWatch Log, biasakan diri Anda dengan konsep-konsep berikut:

Aturan sentralisasi

Konfigurasi yang menentukan bagaimana data log dari akun sumber dan wilayah direplikasi ke akun tujuan dan wilayah. Aturan menentukan kriteria sumber dan pengaturan tujuan.

Akun sumber

AWS Akun tempat data log berasal. Peristiwa log dari akun sumber direplikasi ke akun tujuan berdasarkan aturan sentralisasi yang Anda tetapkan.

Akun tujuan

AWS Akun tujuan tempat data log yang direplikasi disimpan. Akun ini berfungsi sebagai lokasi terpusat untuk analisis dan pemantauan log.

Wilayah cadangan

Wilayah sekunder opsional dalam akun tujuan tempat data log dapat direplikasi untuk meningkatkan ketahanan dan tujuan pemulihan bencana.

Propagasi tag

Kemampuan opt-in yang menyebarkan tag sumber daya dari grup log sumber ke grup log tujuan yang sesuai. Propagasi tag menggunakan peran IAM yang dikelola pelanggan di akun tujuan untuk menambah, memperbarui, dan menghapus tag pada grup log tujuan. Anda mengonfigurasi propagasi tag dengan menambahkan TagPropagationConfiguration blok ke konfigurasi tujuan aturan sentralisasi Anda.

Enkripsi dalam CloudWatch Log

Data grup log selalu dienkripsi di CloudWatch Log. Secara default, CloudWatch Log menggunakan enkripsi sisi server dengan 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) untuk mengenkripsi data log saat diam. Sebagai alternatif, Anda dapat menggunakan Layanan Manajemen AWS Kunci untuk enkripsi ini. Untuk informasi selengkapnya, lihat dokumentasi Enkripsi CloudWatch Log.

  • Cara kerja enkripsi selama sentralisasi: S CloudWatch entralisasi log secara aktif menyalin data log pada waktu penyerapan dari akun sumber ke akun tujuan. Selama proses ini, data Anda tetap dienkripsi saat transit menggunakan kunci layanan yang AWS dimiliki. Data diam di grup log sumber dan tujuan dienkripsi menggunakan metode enkripsi yang Anda pilih (kunci KMS yang dikelola pelanggan atau AWS dimiliki). Jika Anda menggunakan kunci KMS yang dikelola pelanggan di grup log tujuan, tambahkan tag LogsManaged = true ke kunci kms untuk layanan Sentralisasi untuk mengaksesnya.

  • Ketika izin KMS diperlukan:

    • Jika Anda menggunakan kunci KMS yang dikelola pelanggan di akun sumber Anda, CloudWatch Log memerlukan izin KMS dalam skenario contoh berikut:

      • Manajemen Through put: Ketika batas throughput sentralisasi tercapai, data log disimpan sementara dienkripsi dengan kunci KMS yang dikelola pelanggan Anda sampai bandwidth tersedia.

      • Perlindungan dan Redaksi Data: Ketika grup log sumber mengaktifkan kebijakan perlindungan data, Log memerlukan izin CloudWatch mendekripsi untuk mengakses data log mentah untuk memusatkannya.

penting

Aturan sentralisasi dikelola oleh akun manajemen AWS Organisasi atau administrator yang didelegasikan. Untuk mengecualikan grup KMS-encrypted log yang dikelola pelanggan dari sentralisasi, konfigurasikan pengaturan aturan menjadi “Jangan memusatkan grup log yang dienkripsi dengan kunci AWS KMS.”

Menyiapkan sentralisasi log

Untuk mengatur S CloudWatch entralisasi Log, Anda perlu mengonfigurasi aturan sentralisasi yang menentukan cara data log mengalir dari grup log di akun sumber ke grup log di akun tujuan Anda.

Setelah aturan sentralisasi diaktifkan dan peristiwa log direplikasi ke akun tujuan, Anda dapat membuat filter metrik, langganan, dan akun pada grup log terpusat dengan kemampuan pemfilteran yang ditingkatkan. Filter ini dapat menargetkan peristiwa log dari akun dan wilayah sumber tertentu, dan dapat memancarkan akun sumber dan informasi wilayah sebagai dimensi metrik. Untuk informasi selengkapnya, lihat Membuat metrik dari peristiwa log dengan menggunakan filter.

Prasyarat

  • AWS Organizations harus diatur dan akun sumber dan tujuan harus dimiliki organisasi.

  • Akses tepercaya harus diaktifkan untuk CloudWatch, akun manajemen dan akun tujuan sehingga menyediakan akses ke data log.

    catatan

    Disarankan untuk mengaktifkan akses tepercaya melalui konsol, yang secara otomatis membuat peran terkait layanan (SLR) yang diperlukan. Jika akses tepercaya diaktifkan melalui metode lain, peran terkait layanan perlu dibuat secara terpisah.

Prasyarat propagasi tag

Untuk mengaktifkan propagasi tag, Anda harus menyelesaikan pengaturan tambahan berikut:

Membuat peran IAM yang dikelola pelanggan

Anda harus membuat peran IAM yang dikelola pelanggan di akun tujuan dengan konfigurasi berikut:

Kebijakan kepercayaan

Kebijakan kepercayaan peran harus memungkinkan peran terkait layanan sentralisasi untuk memikulnya. Contoh kebijakan kepercayaan berikut memberikan izin AWSServiceRoleForObservabilityAdmin_LogsCentralization peran terkait layanan untuk mengambil peran tujuan. Ganti <destination-account-id> dengan ID akun tujuan Anda dan <organization-id> dengan AWS Organizations ID Anda.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<destination-account-id>:role/aws-service-role/logs-centralization.observabilityadmin.amazonaws.com/AWSServiceRoleForObservabilityAdmin_LogsCentralization"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<organization-id>"
      }
    }
  }]
}
Kebijakan izin

Kebijakan izin peran harus memberikan operasi tag pada grup log tujuan. Contoh berikut memberikan izin minimum yang diperlukan. Ganti <destination-account-id> dengan nilai Anda. Anda dapat menelusuri Resource lebih jauh ke pola ARN grup log tertentu.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "logs:ListTagsForResource",
      "logs:TagResource",
      "logs:UntagResource"
    ],
    "Resource": "arn:aws:logs:*:<destination-account-id>:log-group:*"
  }]
}
Beri Iam: izin PassRole

Anda harus memiliki iam:PassRole izin pada peran tujuan, yang dicakup ke layanan sentralisasi melalui kunci iam:PassedToService kondisi. Contoh berikut memberikan izin untuk meneruskan peran. Ganti <destination-account-id> dan <your-tag-role-name> dengan nilai-nilai Anda.

catatan

Pernyataan ini berlaku pada kebijakan identitas Anda (panggilan utama CreateCentralizationRuleForOrganization atauUpdateCentralizationRuleForOrganization), bukan pada peran tujuan itu sendiri.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::<destination-account-id>:role/<your-tag-role-name>",
    "Condition": {
      "StringEquals": {
        "iam:PassedToService": "logs-centralization.observabilityadmin.amazonaws.com"
      }
    }
  }]
}

Menyesuaikan nama grup log tujuan

Saat Anda membuat aturan sentralisasi, Anda dapat menyesuaikan bagaimana nama grup log tujuan disusun menggunakan atribut. Atribut ini secara otomatis diganti dengan nilai aktual saat grup log dibuat, memungkinkan Anda mengatur log secara hierarkis di akun tujuan Anda. Secara default, hanya ${source.logGroup} atribut yang digunakan, yang menggabungkan semua grup log dengan nama yang sama di akun tujuan. Jika variabel tidak dapat diselesaikan, ia mewarisi nilai dari variabel induknya dalam hierarki.

Atribut yang tersedia

Anda dapat menggunakan atribut berikut dalam pola nama grup log tujuan Anda:

Atribut nama grup log tujuan
Atribut Deskripsi
${source.accountId} ID AWS akun tempat log berasal.
${source.region} Di Wilayah AWS mana log berasal.
${source.logGroup} Nama grup log asli dari akun sumber.
${source.org.id} AWS Organizations ID akun sumber Anda.
${source.org.ouId} ID unit organisasi dari akun sumber
${source.org.rootId} ID root organisasi
${source.org.path} Jalur organisasi lengkap dari akun ke root

Contoh

Pertahankan struktur grup log asli

Pola: /centralized/${source.accountId}${source.logGroup}

Hasil: /centralized/123456789012/aws/lambda/my-function

Atur berdasarkan akun dan wilayah

Pola: /centralized/${source.accountId}/${source.region}

Hasil: /centralized/123456789012/us-east-1

Mengatur berdasarkan struktur organisasi

Pola: /logs/${source.org.id}/${source.org.ouId}/${source.accountId}

Hasil: /logs/o-abc123/ou-xyz-12345678/123456789012

Struktur datar sederhana

Pola: /centralized-logs

Hasil: /centralized-logs

Praktik terbaik

  • Sertakan ID akun sumber untuk mengidentifikasi log akun mana yang berasal dengan mudah.

  • Sertakan wilayah sumber jika Anda memusatkan dari beberapa wilayah.

  • Struktur nama grup log tujuan harus di bawah 512 karakter. CloudWatch Log memberlakukan panjang nama grup log maksimum 512 karakter.

  • Jika Anda mengaktifkan propagasi tag, pola harus berisi ketiga atribut:${source.logGroup},${source.accountId}, dan${source.region}. Ini memastikan setiap grup log sumber dipetakan ke grup log tujuan yang unik.

Membuat aturan sentralisasi

Gunakan prosedur berikut untuk membuat aturan sentralisasi yang mereplikasi data log dari akun sumber ke akun tujuan Anda.

Untuk membuat aturan sentralisasi

  1. Arahkan ke CloudWatch konsol di akun Manajemen atau Administrator Delegasi organisasi.

  2. Pilih Pengaturan.

  3. Arahkan ke tab Organisasi.

  4. Pilih Konfigurasi aturan.

  5. Tentukan detail sumber dengan menyetel bidang berikut, lalu pilih Ber ikutnya:

    1. Nama aturan sentralisasi: Masukkan nama unik untuk aturan sentralisasi.

    2. Akun sumber: Tentukan kriteria pemilihan sumber untuk memilih akun dari mana data telemetri akan dipusatkan. Kriteria pemilihan dapat meliputi:

      • Daftar akun anggota dalam organisasi

      • Daftar unit organisasi dalam organisasi

      • Seluruh organisasi

      Anda dapat memberikan kriteria pemilihan dalam dua mode:

      • Pembangun: Pengalaman berbasis klik untuk menghasilkan kriteria pemilihan sumber

      • Editor: Kotak teks bentuk bebas untuk memberikan kriteria pemilihan sumber

      Sintaks yang didukung untuk kriteria pemilihan sumber:

      • Tombol yang Didukung: OrganizationId OrganizationUnitId | AccountId | | *

      • Operator yang Di dukung: = | IN | ATAU

    3. Wilayah Sumber: Pilih daftar wilayah untuk mencari data telemetri untuk dipusatkan.

  6. Tentukan detail tujuan dengan menyetel bidang berikut, lalu pilih Ber ikutnya:

    1. Akun tujuan: Pilih akun di organisasi yang bertindak sebagai tujuan pusat untuk data telemetri.

    2. Wilayah Tujuan: Pilih wilayah utama yang menyimpan salinan data telemetri terpusat.

    3. Wilayah Cad angan: Secara opsional pilih wilayah yang menyimpan salinan kedua dari data telemetri terpusat.

  7. Tentukan data telemetri dengan menyetel bidang berikut, lalu pilih Ber ikutnya:

    1. Grup log: Pilih salah satu opsi berikut:

      • Semua grup log: Sentralisasi log dari semua grup log di akun sumber.

      • Filter grup log: Sentralisasi log dari subset grup log di akun sumber, cocok dengan kriteria pemilihan. Anda dapat memberikan kriteria pemilihan dalam dua mode:

        • Pembangun: Pengalaman berbasis pilihan untuk menghasilkan kriteria seleksi

        • Editor: Kotak teks bentuk bebas untuk memberikan kriteria pemilihan

        Ada dua kriteria pemilihan yang dapat Anda gunakan untuk memfilter log:

        • Kriteria pemilihan grup log: Kriteria pemilihan yang menentukan grup log sumber mana yang akan dipusatkan.

          • Kunci yang Didukung: LogGroupName | *

          • Operator yang Didukung: = |! = | DALAM | TIDAK DI | DAN | ATAU | SUKA | TIDAK SUKA

        • Kriteria pemilihan sumber data: Kriteria pemilihan yang menentukan sumber data mana yang akan dipusatkan.

          • Kunci yang Didukung DataSourceName: DataSourceType

          • Operator yang Didukung: = |! = | DALAM | TIDAK DI | DAN | ATAU | SUKA | TIDAK SUKA

        Ketika kriteria pemilihan grup log dan kriteria pemilihan sumber data ditentukan, peristiwa log harus cocok dengan kedua kriteria untuk dipusatkan.

    2. Grup Log Terenkripsi KMS

      penting

      CloudWatch aturan sentralisasi akan gagal mengirimkan log dari akun sumber ke grup log tujuan jika Kunci KMS yang disediakan dalam aturan Sentralisasi tidak mengizinkan CloudWatch Log untuk menggunakannya. Jika Anda menggunakan kunci KMS yang dikelola pelanggan di grup log tujuan Anda, tambahkan tag LogsManaged = true ke kunci kms. Untuk informasi selengkapnya, lihat Langkah 2: Tetapkan izin pada kunci KMS.

      Pilih salah satu opsi berikut:

      • Memusatkan grup log sumber yang dienkripsi dengan kunci KMS yang dikelola pelanggan menggunakan kunci KMS yang dikelola pelanggan tertentu tujuan: Sentralisasikan peristiwa log dari grup log sumber yang dienkripsi dengan kunci KMS yang dikelola pelanggan ke grup log tujuan yang dienkripsi dengan kunci KMS yang dikelola pelanggan di akun tujuan.

        Ketika pengaturan ini dipilih, Anda juga harus mengatur yang berikut:

        • Kunci enkripsi tujuan ARN: ARN dari kunci KMS yang dikelola pelanggan di akun tujuan dan wilayah tujuan utama, untuk dikaitkan dengan grup log tujuan yang baru dibuat.

        • Kunci enkripsi tujuan cadangan ARN (jika wilayah cadangan dipilih): ARN dari kunci KMS yang dikelola pelanggan di akun tujuan dan wilayah tujuan cadangan, untuk dikaitkan dengan grup log tujuan yang baru dibuat.

        • Lewati sentralisasi ke grup log tujuan yang tidak dienkripsi (opsional): Jika grup log sudah ada tanpa kunci KMS yang dikelola pelanggan, CloudWatch tidak dapat memperbarui enkripsinya. Pilih opsi ini untuk melewati sentralisasi peristiwa log dari grup log sumber yang dienkripsi dengan kunci KMS yang dikelola pelanggan ke grup log tujuan yang tidak terkait dengan kunci KMS yang dikelola pelanggan.

      • Memusatkan grup log yang dienkripsi dengan kunci KMS yang dikelola pelanggan di akun tujuan dengan kunci KMS yang AWS dimiliki: Sentralisasikan peristiwa log dari grup log sumber yang dienkripsi dengan kunci KMS yang dikelola pelanggan ke grup log tujuan yang baru dibuat yang dienkripsi menggunakan kunci KMS yang dimiliki. AWS

      • Jangan memusatkan grup log yang dienkripsi dengan kunci KMS yang dikelola pelanggan: Lewati sentralisasi peristiwa log dari grup log sumber yang dienkripsi dengan kunci KMS yang dikelola pelanggan.

  8. Tinjau aturan sentralisasi, lakukan pengeditan menit terakhir secara opsional, dan pilih Buat kebijakan sentralisasi.

Memodifikasi aturan sentralisasi

Gunakan prosedur berikut untuk memodifikasi aturan sentralisasi yang ada.

Untuk memodifikasi aturan sentralisasi

  1. Arahkan ke CloudWatch konsol di akun Manajemen atau Administrator Delegasi organisasi.

  2. Pilih Pengaturan.

  3. Arahkan ke tab Organisasi.

  4. Pilih Kelola aturan.

  5. Pilih aturan yang akan diperbarui dan pilih Edit.

  6. Perbarui konfigurasi aturan sesuai kebutuhan, pilih Ber ikutnya untuk melanjutkan melalui setiap langkah.

  7. Pada Langkah 4, Tinjau dan konfigurasikan, pilih Per barui kebijakan sentralisasi.

Melihat aturan sentralisasi

Gunakan prosedur berikut untuk melihat detail aturan sentralisasi yang ada.

Untuk melihat aturan sentralisasi

  1. Arahkan ke CloudWatch konsol di akun Manajemen atau Administrator Delegasi organisasi.

  2. Pilih Pengaturan.

  3. Arahkan ke tab Organisasi.

  4. Pilih Kelola aturan.

  5. Lihat daftar semua aturan sentralisasi yang ada dan pilih nama aturan tertentu untuk melihat detailnya.

Menghapus aturan sentralisasi

Gunakan prosedur berikut untuk menghapus aturan sentralisasi yang ada.

Untuk menghapus aturan sentralisasi

  1. Arahkan ke CloudWatch konsol di akun Manajemen atau Administrator Delegasi organisasi.

  2. Pilih Pengaturan.

  3. Arahkan ke tab Organisasi.

  4. Pilih Kelola aturan.

  5. Pilih aturan yang akan dihapus dan pilih H apus.

  6. Konfirmasikan penghapusan dan pilih Hapus.

Pemantauan dan pemecahan masalah aturan sentralisasi

Anda dapat memantau status dan kinerja aturan sentralisasi menggunakan CloudWatch metrik, konsol CloudWatch Log, dan AWS CloudTrail log. Ini membantu Anda memastikan bahwa data log berhasil direplikasi dan mengidentifikasi masalah apa pun dengan konfigurasi sentralisasi Anda.

CloudWatch Log menyediakan:

  1. Kesehatan aturan per aturan Sentralisasi

    1. Pilih Pengaturan.

    2. Arahkan ke tab Organisasi.

    3. Pilih Kelola aturan.

  2. Mencatat panggilan API dengan AWS CloudTrail

  3. CloudWatch juga menerbitkan metrik untuk sentralisasi, termasuk peristiwa log yang direplikasi, kesalahan, dan pelambatan. Untuk informasi selengkapnya tentang metrik ini dan dimensinya, lihatMetrik dan dimensi sentralisasi.

Status kesehatan aturan sentralisasi

Setiap aturan sentralisasi memiliki status kesehatan yang menunjukkan apakah itu beroperasi dengan benar. Anda dapat memeriksa kesehatan aturan melalui konsol atau secara terprogram menggunakan API.

Status kesehatan aturan meliputi:

  • HEALTHY: Aturan beroperasi secara normal dan mereplikasi data log seperti yang dikonfigurasi

  • UNHEALTHY: Aturan mengalami masalah dan mungkin tidak mereplikasi data dengan benar

  • PROVISIONING: Sentralisasi untuk organisasi sedang dalam proses didirikan.

Ketika aturan ditandai sebagai TIDAK SEHAT, FailureReason bidang tersebut memberikan rincian tentang masalah spesifik yang perlu ditangani.

Tandai status kesehatan propagasi

Propagasi tag memiliki status kesehatan sendiri (TagPropagationStatus) yang independen dari keseluruhan RuleHealth untuk pengiriman log. Jika Anda salah mengkonfigurasi peran tujuan, kesehatan aturan Anda secara keseluruhan tidak terpengaruh — hanya propagasi tag yang ditampilkan sebagai tidak sehat.

  • Healthy: Upaya propagasi tag terbaru berhasil.

  • Unhealthy: Upaya propagasi tag terbaru gagal. Periksa TagPropagationFailureReason bidang untuk detailnya. Lihat bagian pemecahan masalah di bawah ini untuk langkah-langkah perbaikan.

Memantau panggilan API sentralisasi dengan AWS CloudTrail

AWS CloudTrail mencatat panggilan API yang dilakukan ke layanan sentralisasi, memungkinkan Anda melacak perubahan konfigurasi dan memecahkan masalah untuk akun yang merupakan anggota Anda AWS Organizations.

Per CloudTrail istiwa utama untuk sentralisasi meliputi:

  • CreateCentralizationRuleForOrganization: Ketika aturan sentralisasi baru dibuat

  • UpdateCentralizationRuleForOrganization: Ketika aturan yang ada diubah

  • DeleteCentralizationRuleForOrganization: Saat aturan dihapus

  • GetCentralizationRuleForOrganization: Saat detail aturan diambil

  • ListCentralizationRulesForOrganization: Ketika aturan terdaftar

Anda dapat menggunakan CloudTrail log untuk mengaudit perubahan konfigurasi sentralisasi dan menghubungkannya dengan masalah kinerja atau kegagalan replikasi.

Rekomendasi pemantauan

Untuk memastikan sentralisasi berfungsi dengan benar, sebaiknya siapkan CloudWatch alarm pada metrik sentralisasi utama yang kami jual ke Metrik. CloudWatch Pemantauan proaktif ini membantu Anda mendeteksi masalah lebih awal dan mempertahankan sentralisasi log yang andal di seluruh organisasi Anda.

Metrik utama untuk dipantau meliputi:

  • IncomingCopiedBytes: Pantau volume data log yang berhasil direplikasi ke akun tujuan Anda. Penurunan atau ketiadaan metrik ini secara tiba-tiba dapat mengindikasikan masalah sentralisasi.

  • CentralizationError: Siapkan alarm untuk setiap kesalahan dalam proses sentralisasi untuk mengidentifikasi dan menyelesaikan masalah dengan cepat.

  • CentralizationThrottled: Pantau peristiwa pelambatan yang dapat memengaruhi kinerja replikasi log.

Untuk daftar lengkap metrik sentralisasi yang tersedia dan dimensinya, lihatMetrik dan dimensi sentralisasi.

Jika log tidak terpusat seperti yang diharapkan, tinjau skenario umum berikut yang dapat mencegah sentralisasi log.

Data log historis

Fitur sentralisasi CloudWatch log hanya memproses data log baru yang masuk ke akun sumber setelah Anda membuat aturan sentralisasi. Data log historis (log yang ada sebelum pembuatan aturan) tidak terpusat.

Izin kunci KMS

Aturan sentralisasi akan gagal mengirimkan log dari akun sumber ke grup log tujuan jika kunci KMS yang disediakan dalam aturan sentralisasi tidak mengizinkan CloudWatch Log untuk menggunakannya. Pastikan kebijakan kunci KMS memberikan izin yang diperlukan untuk CloudWatch Log. Untuk informasi selengkapnya, lihat Langkah 2: Tetapkan izin pada kunci KMS.

Konfigurasi kunci KMS yang Dikelola Pelanggan

Jika Anda memilih Jangan memusatkan grup log yang dienkripsi dengan kunci KMS yang Dikelola Pelanggan selama pembuatan aturan, peristiwa log dari grup log sumber yang dienkripsi dengan kunci KMS yang Dikelola Pelanggan akan dilewati dan tidak terpusat.

Ketidakcocokan enkripsi tujuan

Jika grup log tujuan sudah ada dengan konfigurasi enkripsi KMS yang berbeda dari yang ditentukan aturan sentralisasi, dan resolusi konflik diatur ke SKIP, catatan akan dihapus dan DestinationEncryptionMismatch kesalahan akan dipancarkan. Misalnya, ini terjadi ketika tujuan memiliki enkripsi default tetapi aturan menentukan kunci KMS yang dikelola pelanggan.

Akses tepercaya tidak diaktifkan

Akses tepercaya harus diaktifkan AWS Organizations untuk CloudWatch akun manajemen dan akun tujuan untuk menyediakan akses ke data log.

Kriteria pemilihan sumber

Pastikan kriteria pemilihan sumber aturan sentralisasi Anda dikonfigurasi dengan benar:

  • Akun dan wilayah: Pastikan bahwa akun sumber dan wilayah tempat log berasal disertakan dalam aturan. Grup log dari akun atau wilayah yang tidak ditentukan dalam aturan tidak akan terpusat.

  • Filter grup log: Jika Anda mengonfigurasi filter grup log, hanya grup log yang cocok dengan kriteria yang ditentukan yang akan dipusatkan. Verifikasi bahwa kriteria pemilihan grup log Anda menyertakan grup log yang diharapkan untuk dipusatkan.

  • Keanggotaan organisasi: Akun sumber dan tujuan harus milik AWS Organizations organisasi yang sama. Akun di luar organisasi tidak dapat berpartisipasi dalam sentralisasi.

Batas kuota grup log tercapai

Jika akun tujuan telah mencapai batas kuota grup log, grup log baru tidak dapat dibuat untuk sentralisasi. Verifikasi bahwa akun tujuan memiliki kuota yang cukup untuk mengakomodasi grup log terpusat dari semua akun sumber. Anda dapat meminta kenaikan kuota jika diperlukan.

Batas panjang nama aliran log terlampaui

Nama aliran log memiliki batasan panjang maksimum. Saat sentralisasi mereplikasi aliran log ke akun tujuan, akhiran ditambahkan ke nama aliran log. Jika nama aliran log yang dihasilkan melebihi panjang maksimum yang diizinkan, catatan akan dihapus dan InvalidLogStream kesalahan akan dikirimkan ke akun pelanggan.

Aturan status kesehatan

Periksa status kesehatan aturan sentralisasi di konsol atau menggunakan GetCentralizationRuleForOrganization API. Jika aturan ditandai sebagai TIDAK SEHAT, tinjau FailureReason bidang untuk detail spesifik tentang masalah tersebut.

Menandai status kesehatan propagasi

Jika TagPropagationStatus ditampilkanUnhealthy, periksa TagPropagationFailureReason bidang:

  • RoleNotAssumable: Layanan tidak dapat mengambil peran tujuan. Verifikasi bahwa kebijakan kepercayaan peran memungkinkan peran terta sts:ExternalId ut layanan sentralisasi untuk mengasumsinya dan bahwa itu cocok dengan ID organisasi Anda.

  • RoleLacksPermissions: Peran diasumsikan tetapi panggilan API tag ditolak. Pastikan pemberian kebijakan izin peranlogs:ListTagsForResource,logs:TagResource, dan logs:UntagResource pada grup log tujuan.

Untuk mendiagnosis masalah sentralisasi, tinjau status kesehatan aturan sentralisasi di konsol, periksa CloudWatch metrik untuk kesalahan dan pelambatan, dan periksa AWS CloudTrail log untuk kegagalan panggilan API. Untuk informasi selengkapnya tentang metrik sentralisasi, lihatMetrik dan dimensi sentralisasi.