Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Memantau log Amazon Aurora Amazon Setiap mesin RDS database menghasilkan log yang dapat Anda akses untuk audit dan pemecahan masalah. Jenis log ini bergantung pada mesin basis data Anda. Anda dapat mengakses log database untuk instans DB menggunakan Konsol Manajemen AWS, the AWS Command Line Interface (AWS CLI), atau Amazon RDSAPI. Anda tidak dapat menampilkan, melihat, atau mengunduh log transaksi. **catatan** Dalam beberapa kasus, log berisi data tersembunyi. Oleh karena itu, Konsol Manajemen AWS mungkin menampilkan konten dalam file log, tetapi file log mungkin kosong saat Anda mengunduhnya. **Topics** + [ # Melihat dan mencantumkan file log basis data ](USER_LogAccess.Procedural.Viewing.md) + [ # Mengunduh file log basis data ](USER_LogAccess.Procedural.Downloading.md) + [ # Melihat file log basis data ](USER_LogAccess.Procedural.Watching.md) + [ # Menerbitkan log database ke Amazon CloudWatch Logs ](USER_LogAccess.Procedural.UploadtoCloudWatch.md) + [ # Membaca isi file log menggunakan REST ](DownloadCompleteDBLogFile.md) + [ # File log database MySQL Aurora ](USER_LogAccess.Concepts.MySQL.md) + [ # ](USER_LogAccess.Concepts.PostgreSQL.md) # Melihat dan mencantumkan file log basis data Anda dapat melihat file log database untuk mesin Aurora DB Anda dengan menggunakan file. Konsol Manajemen AWS Anda dapat membuat daftar file log apa yang tersedia untuk diunduh atau dipantau dengan menggunakan AWS CLI atau Amazon RDSAPI. **catatan** Anda tidak dapat melihat file log untuk cluster Aurora Serverless v1 DB di RDS konsol. Namun, Anda dapat melihatnya di CloudWatch konsol Amazon di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). ## Konsol **Untuk melihat file log basis data** 1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Database**. 1. Pilih nama instans DB yang memiliki file log yang ingin dilihat. 1. Pilih tab **Log & peristiwa**. 1. Gulir ke bawah ke bagian **Log**. 1. (Opsional) Masukkan istilah pencarian untuk memfilter hasil. Contoh berikut mencantumkan log yang difilter dengan teks **error**. ![\[Mencantumkan log DB\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png) 1. Pilih log yang ingin dilihat, lalu pilih **Lihat**. ## AWS CLI Untuk membuat daftar file log database yang tersedia untuk instance DB, gunakan AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html)perintah. Contoh berikut menampilkan daftar file log untuk instans DB yang bernama `my-db-instance`. **Example** ``` 1. aws rds describe-db-log-files --db-instance-identifier my-db-instance ``` ## RDS API Untuk mencantumkan file log database yang tersedia untuk instans DB, gunakan RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html)tindakan Amazon. # Mengunduh file log basis data Anda dapat menggunakan Konsol Manajemen AWS, AWS CLI, atau API untuk mengunduh file log database. ## Konsol **Untuk mengunduh file log basis data** 1. Buka RDS konsol Amazon di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Database**. 1. Pilih nama instans DB yang memiliki file log yang ingin dilihat. 1. Pilih tab **Log & peristiwa**. 1. Gulir ke bawah ke bagian **Log**. 1. Di bagian **Log** pilih tombol di samping log yang ingin diunduh, lalu pilih **Unduh**. 1. Buka menu konteks (klik kanan) untuk tautan yang diberikan, lalu pilih **Simpan Tautan Sebagai**. Masukkan lokasi tempat file log ingin disimpan, lalu pilih **Simpan**. ![\[melihat file log\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png) ## AWS CLI Untuk mengunduh file log database, gunakan AWS CLI perintah [https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html). Secara default, perintah ini hanya mengunduh bagian terbaru dari file log. Namun, Anda dapat mengunduh seluruh file dengan menentukan parameter `--starting-token 0`. *Contoh berikut menunjukkan bagaimana untuk men-download seluruh isi dari file log yang disebut *log/ ERROR .4* dan menyimpannya dalam file lokal bernama errorlog.txt.* **Example** Untuk Linux, macOS, atau Unix: ``` 1. aws rds download-db-log-file-portion \ 2. --db-instance-identifier myexampledb \ 3. --starting-token 0 --output text \ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` Untuk Windows: ``` 1. aws rds download-db-log-file-portion ^ 2. --db-instance-identifier myexampledb ^ 3. --starting-token 0 --output text ^ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` ## RDS API Untuk mengunduh file log database, gunakan RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html)tindakan Amazon. # Melihat file log basis data Melihat file log basis data sama seperti membuntuti file pada sistem UNIX atau Linux. Anda dapat melihat file log dengan menggunakan Konsol Manajemen AWS. RDS menyegarkan ekor log setiap 5 detik. **Untuk melihat file log basis data** 1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Basis data**. 1. Pilih nama instans DB yang memiliki file log yang ingin dilihat. 1. Pilih tab **Log & peristiwa**. ![\[Pilih tab Log & peristiwa\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png) 1. Di bagian **Log**, pilih file log, lalu pilih **Lihat**. ![\[Pilih log\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png) RDS menunjukkan ekor log, seperti pada contoh MySQL berikut. ![\[Ekor file log\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png) # Menerbitkan log database ke Amazon CloudWatch Logs Dalam basis data on-premise, log basis data berada pada sistem file. Amazon RDS tidak menyediakan akses host ke log basis data pada sistem file klaster DB Anda. Untuk alasan ini, Amazon RDS memungkinkan Anda mengekspor log database ke [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Dengan CloudWatch Log, Anda dapat melakukan analisis real-time dari data log. Anda juga dapat menyimpan data dalam penyimpanan yang sangat tahan lama dan mengelola data dengan Agen CloudWatch Log. **Topics** + [ ## Ikhtisar integrasi RDS dengan CloudWatch Log ](#rds-integration-cw-logs) + [ ## Memutuskan log mana yang akan dipublikasikan ke CloudWatch Log ](#engine-specific-logs) + [ ## Menentukan log untuk dipublikasikan ke CloudWatch Log ](#integrating_cloudwatchlogs.configure) + [ ## Mencari dan memfilter log Anda di CloudWatch Log ](#accessing-logs-in-cloudwatch) ## Ikhtisar integrasi RDS dengan CloudWatch Log Di CloudWatch Log, *aliran log* adalah urutan peristiwa log yang berbagi sumber yang sama. Setiap sumber log terpisah di CloudWatch Log membentuk aliran log terpisah. *Grup log* adalah grup log stream yang berbagi pengaturan retensi, pemantauan, dan kontrol akses yang sama. Amazon Aurora terus mengalirkan data log klaster ke grup log. Misalnya, Anda memiliki grup log `/aws/rds/cluster/cluster_name/log_type` untuk setiap jenis log yang Anda terbitkan. Grup log ini berada di AWS Wilayah yang sama dengan instance database yang menghasilkan log. AWS menyimpan data log yang dipublikasikan ke CloudWatch Log untuk jangka waktu yang tidak terbatas kecuali Anda menentukan periode retensi. Untuk informasi selengkapnya, lihat [Ubah penyimpanan data log dalam CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention). ## Memutuskan log mana yang akan dipublikasikan ke CloudWatch Log Setiap mesin basis data RDS mendukung kumpulan log-nya sendiri. Untuk mempelajari opsi untuk mesin basis data Anda, baca topik berikut: + [Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md) + [Menerbitkan log Aurora PostgreSQL ke Amazon Logs CloudWatch](AuroraPostgreSQL.CloudWatch.md) ## Menentukan log untuk dipublikasikan ke CloudWatch Log Tentukan log yang akan diterbitkan di konsol. Pastikan Anda memiliki peran terkait layanan di AWS Identity and Access Management (IAM). Untuk mengetahui informasi selengkapnya tentang peran terkait layanan, lihat [Menggunakan peran terkait layanan untuk Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md). **Untuk menentukan log yang akan diterbitkan** 1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Basis Data**. 1. Lakukan salah satu dari langkah berikut: + Pilih **Buat basis data**. + Pilih basis data dari daftar, lalu pilih **Ubah**. 1. Di **Ekspor log**, pilih log yang akan diterbitkan. ## Mencari dan memfilter log Anda di CloudWatch Log Anda dapat mencari entri log yang memenuhi kriteria tertentu menggunakan konsol CloudWatch Log. Anda dapat mengakses log baik melalui konsol RDS, yang mengarahkan Anda ke konsol CloudWatch Log, atau dari konsol CloudWatch Log secara langsung. **Untuk mencari log RDS menggunakan konsol RDS** 1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Basis Data**. 1. Pilih klaster DB atau instans DB. 1. Pilih **Konfigurasi**. 1. Di bagian bawah **Log yang diterbitkan**, pilih log basis data yang ingin dilihat. **Untuk mencari log RDS Anda menggunakan konsol CloudWatch Log** 1. Buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Pada panel navigasi, pilih **Grup log**. 1. Di kotak filter, masukkan **/aws/rds**. 1. Untuk **Grup Log**, pilih nama grup log yang berisi log stream yang akan dicari. 1. Untuk **Log Stream**, pilih nama log stream yang akan dicari. 1. Di bagian **Peristiwa log**, masukkan sintaksis filter yang akan digunakan. Untuk informasi selengkapnya, lihat [Mencari dan memfilter data log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) di *Panduan Pengguna CloudWatch Log Amazon*. Untuk tutorial blog yang menjelaskan cara memantau log RDS, lihat [Membangun pemantauan basis data proaktif untuk Amazon RDS dengan Amazon CloudWatch Logs, AWS Lambda, dan Amazon](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/) SNS. # Membaca isi file log menggunakan REST Amazon RDS menyediakan REST endpoint yang memungkinkan akses ke file log instans DB. Ini berguna jika Anda perlu menulis aplikasi untuk melakukan streaming konten file RDS log Amazon. Sintaksnya adalah: ``` GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1 Content-type: application/json host: rds.region.amazonaws.com ``` Parameter-parameter berikut diperlukan: + `DBInstanceIdentifier`—nama instans basis data yang berisi file log yang ingin Anda unduh. + `LogFileName`—nama file log yang akan diunduh. Respons akan mengandung konten file log yang diminta, berupa sebuah aliran. *Contoh berikut mengunduh file log bernama *log/ ERROR .6* untuk instance DB bernama *sample-sql* di wilayah us-west-2.* ``` GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1 host: rds.us-west-2.amazonaws.com X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq= X-Amz-Date: 20140903T233749Z X-Amz-Algorithm: AWS4-HMAC-SHA256 X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request X-Amz-SignedHeaders: host X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855 X-Amz-Expires: 86400 X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558 ``` Jika Anda menentukan suatu instans basis data yang tidak ada, respons akan terdiri atas kesalahan berikut: + `DBInstanceNotFound`—`DBInstanceIdentifier` tidak mengacu ke instans basis data yang ada. (kode HTTP status: 404) # File log database MySQL Aurora Anda dapat memantau log Aurora MySQL langsung melalui konsol Amazon RDS, Amazon RDS API, atau. AWS CLI AWS SDKs Anda juga dapat mengakses log MySQL dengan mengarahkan log ke tabel basis data di basis data utama dan mengueri tabel tersebut. Anda dapat menggunakan utilitas mysqlbinlog untuk mengunduh log biner. Untuk mengetahui informasi selengkapnya tentang cara melihat, mengunduh, dan melihat log basis data berbasis file, lihat [Memantau log Amazon Aurora Amazon](USER_LogAccess.md). **Topics** + [ # Ringkasan log basis data Aurora MySQL ](USER_LogAccess.MySQL.LogFileSize.md) + [ # Mengirim keluaran log Aurora MySQL ke tabel ](Appendix.MySQL.CommonDBATasks.Logs.md) + [ # Mengkonfigurasi Aurora untuk database Single-AZ ](USER_LogAccess.MySQL.BinaryFormat.md) + [ # Mengakses log biner MySQL ](USER_LogAccess.MySQL.Binarylog.md) # Ringkasan log basis data Aurora MySQL Anda dapat memantau jenis file log Aurora MySQL berikut: + Log kesalahan + Log kueri lambat + Log umum + Log audit + Log contoh + Log kesalahan otentikasi basis data IAM Log kesalahan Aurora MySQL dihasilkan secara default. Anda dapat membuat kueri lambat dan log umum dengan mengatur parameter di grup parameter DB Anda. **Topics** + [ ## Log kesalahan Aurora MySQL ](#USER_LogAccess.MySQL.Errorlog) + [ ## Log umum dan kueri lambat Aurora MySQL ](#USER_LogAccess.MySQL.Generallog) + [ ## Log audit Aurora MySQL ](#ams-audit-log) + [ ## Log contoh MySQL Aurora ](#ams-instance-log) + [ ## Rotasi dan retensi log untuk Aurora MySQL ](#USER_LogAccess.AMS.LogFileSize.retention) + [ ## Menerbitkan log Aurora MySQL ke Amazon Logs CloudWatch ](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs) ## Log kesalahan Aurora MySQL Kesalahan tulis Aurora MySQL dalam file `mysql-error.log`. Setiap file log memiliki jam pembuatan (dalam UTC) yang ditambahkan pada namanya. File log juga memiliki stempel waktu yang membantu Anda menentukan kapan entri log ditulis. Aurora MySQL ditulis ke log kesalahan hanya saat dinyalakan, dimatikan, dan saat terjadi kesalahan. Instan DB dapat memakan waktu berjam-jam atau berhari-hari tanpa perlu menulis entri baru ke log kesalahan. Jika Anda melihat tidak ada entri terbaru, berarti server tidak mengalami kesalahan yang akan mengakibatkan entri log. Secara desain, log kesalahan difilter sehingga hanya peristiwa tak terduga seperti kesalahan yang ditampilkan. Namun, log kesalahan juga berisi beberapa informasi basis data tambahan, misalnya kemajuan kueri, yang tidak ditampilkan. Oleh karena itu, bahkan tanpa kesalahan aktual, ukuran log kesalahan mungkin meningkat dikarenakan aktivitas basis data yang sedang berlangsung. Dan sementara Anda mungkin melihat ukuran tertentu dalam byte atau kilobyte untuk log kesalahan di Konsol Manajemen AWS, mereka mungkin memiliki 0 byte saat Anda mengunduhnya. Aurora MySQL menulis `mysql-error.log` ke disk setiap 5 menit. Ini menambahkan konten log ke `mysql-error-running.log`. Aurora MySQL merotasi file `mysql-error-running.log` setiap jam. **catatan** Periode retensi log berbeda antara Amazon RDS dan Aurora. ## Log umum dan kueri lambat Aurora MySQL Anda dapat menulis log umum dan log kueri lambat Aurora MySQL ke file atau tabel basis data. Untuk melakukannya, atur parameter di grup parameter DB Anda. Untuk mengetahui informasi tentang cara membuat dan memodifikasi grup parameter DB, lihat [](USER_WorkingWithParamGroups.md). Anda harus mengatur parameter ini sebelum dapat melihat log kueri lambat atau log umum di konsol Amazon RDS atau dengan menggunakan Amazon RDS API, Amazon RDS CLI, atau. AWS SDKs Anda dapat mengontrol pencatatan log Aurora MySQL dengan menggunakan parameter dalam daftar ini: + `slow_query_log`: Untuk membuat log kueri lambat, atur ke 1. Default-nya adalah 0. + `general_log`: Untuk membuat log umum, atur ke 1. Default-nya adalah 0. + `long_query_time`: Untuk mencegah pencatatan log kueri yang berjalan cepat dalam log kueri lambat, tentukan nilai untuk runtime kueri terpendek yang akan dicatat, dalam detik. Nilai default-nya adalah 10 detik; nilai minimumnya adalah 0. Jika log\$1output = FILE, Anda dapat menentukan nilai titik mengambang yang masuk ke resolusi mikrodetik. Jika log\$1output = TABLE, Anda harus menentukan nilai integer dengan resolusi kedua. Hanya kueri yang runtime-nya melebihi nilai `long_query_time` yang akan dicatat. Misalnya, mengatur `long_query_time` ke 0,1 akan mencegah pencatatan log kueri apa pun yang berjalan kurang dari 100 milidetik. + `log_queries_not_using_indexes`: Untuk mencatat semua kueri yang tidak menggunakan indeks pada log kueri lambat, atur ke 1. Kueri yang tidak menggunakan indeks dicatat meskipun runtime-nya kurang dari nilai parameter `long_query_time`. Default-nya adalah 0. + `log_output option`: Anda dapat menentukan salah satu opsi berikut untuk parameter `log_output`. + **TABLE** – Menulis kueri umum ke tabel `mysql.general_log`, dan kueri lambat ke tabel `mysql.slow_log`. + **FILE** – Menulis log umum dan log kueri lambat ke sistem file. + **TIDAK ADA** – Menonaktifkan pencatatan log. Untuk Aurora MySQL versi 2 dan 3, defaultnya adalah. `log_output` `FILE` Agar data kueri lambat muncul di CloudWatch Log Amazon, kondisi berikut harus dipenuhi: + CloudWatch Log harus dikonfigurasi untuk menyertakan log kueri yang lambat. + `slow_query_log`harus diaktifkan. + `log_output` harus diatur ke `FILE`. + Kueri harus memakan waktu lebih lama dari waktu yang dikonfigurasi`long_query_time`. Untuk mengetahui informasi selengkapnya tentang log umum dan kueri lambat, buka topik berikut di dokumentasi MySQL: + [Log kueri lambat](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) + [Log kueri umum](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) ## Log audit Aurora MySQL Pencatatan log audit untuk Aurora MySQL disebut Audit Lanjutan. Untuk mengaktifkan Audit Lanjutan, tetapkan parameter klaster DB tertentu. Untuk informasi selengkapnya, lihat [Menggunakan Audit Lanjutan dengan klaster Amazon Aurora My DB SQL](AuroraMySQL.Auditing.md). ## Log contoh MySQL Aurora Aurora membuat file log terpisah untuk instans DB yang mengaktifkan jeda otomatis. File instance.log ini mencatat alasan mengapa instance DB ini tidak dapat dijeda saat diharapkan. Untuk informasi selengkapnya tentang perilaku file log instance dan kemampuan jeda otomatis Aurora, lihat Memantau aktivitas jeda dan melanjutkan [Aurora Tanpa Server v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). ## Rotasi dan retensi log untuk Aurora MySQL Saat pencatatan log diaktifkan, Amazon Aurora merotasi atau menghapus file log secara berkala. Langkah ini merupakan tindakan pencegahan untuk mengurangi kemungkinan file log besar memblokir penggunaan basis data atau memengaruhi performa. Aurora MySQL menangani rotasi dan penghapusan sebagai berikut: + Ukuran file log kesalahan Aurora MySQL dibatasi hingga tidak lebih dari 15 persen dari penyimpanan lokal untuk instans DB. Untuk mempertahankan ambang batas ini, log secara otomatis dirotasi setiap jam. Aurora MySQL menghapus log setelah 30 hari atau ketika 15% dari ruang disk tercapai. Jika ukuran file log gabungan melebihi ambang batas setelah file log lama dihapus, file log paling lama akan dihapus hingga ukuran file log tidak lagi melebihi ambang batas. + Aurora MySQL menghapus log audit, umum, dan kueri lambat setelah 24 jam atau ketika 15% dari penyimpanan telah terpakai. + Saat pencatatan log `FILE` diaktifkan, file log umum dan kueri lambat akan diperiksa setiap jam dan file log yang berusia lebih dari 24 jam akan dihapus. Dalam beberapa kasus, ukuran file log gabungan yang tersisa setelah penghapusan mungkin melebihi ambang batas 15 persen dari ruang lokal instans DB. Dalam kasus ini, file log yang paling lama akan dihapus hingga ukuran file log tidak lagi melebihi ambang batas. + Saat pencatatan log `TABLE` diaktifkan, tabel log tidak dirotasi atau dihapus. Tabel log akan dipotong jika ukuran semua log yang digabungkan terlalu besar. Anda dapat berlangganan kategori `low storage` acara untuk diberi tahu ketika tabel log harus diputar atau dihapus secara manual untuk mengosongkan ruang. Untuk informasi selengkapnya, lihat [Bekerja dengan pemberitahuan RDS acara Amazon](USER_Events.md). Anda dapat merotasi tabel `mysql.general_log` secara manual dengan memanggil prosedur `mysql.rds_rotate_general_log`. Anda dapat merotasi tabel `mysql.slow_log` dengan mengikuti prosedur `mysql.rds_rotate_slow_log`. Saat Anda merotasi tabel log secara manual, tabel log saat ini disalin ke tabel log cadangan dan entri di tabel log saat ini dihapus. Jika sudah ada, tabel log cadangan akan dihapus sebelum tabel log saat ini disalin ke cadangan. Anda dapat meminta tabel log cadangan jika diperlukan. Tabel log cadangan untuk tabel `mysql.general_log` bernama `mysql.general_log_backup`. Tabel log cadangan untuk tabel `mysql.slow_log` bernama `mysql.slow_log_backup`. + Log audit Aurora MySQL dirotasi saat ukuran file mencapai 100 MB, dan dihapus setelah 24 jam. + Amazon RDS memutar file log kesalahan otentikasi database IAM yang lebih besar dari 10 MB. Amazon RDS menghapus file log kesalahan otentikasi database IAM yang lebih tua dari lima hari atau lebih besar dari 100 MB. Untuk bekerja dengan log dari konsol Amazon RDS, Amazon RDS API, Amazon RDS CLI, AWS SDKs atau, atur `log_output` parameter ke FILE. Seperti log kesalahan Aurora MySQL, file log ini dirotasi setiap jam. File log yang dihasilkan selama 24 jam sebelumnya akan dipertahankan. Perhatikan bahwa periode retensi log berbeda antara Amazon RDS dan Aurora. ## Menerbitkan log Aurora MySQL ke Amazon Logs CloudWatch Anda dapat mengonfigurasi cluster DB MySQL Aurora Anda untuk mempublikasikan data log ke grup log di Amazon Logs. CloudWatch Dengan CloudWatch Log, Anda dapat melakukan analisis real-time dari data log, dan menggunakannya CloudWatch untuk membuat alarm dan melihat metrik. Anda dapat menggunakan CloudWatch Log untuk menyimpan catatan log Anda dalam penyimpanan yang sangat tahan lama. Lihat informasi yang lebih lengkap di [Menerbitkan log Amazon Aurora MySQL ke Amazon Logs CloudWatch](AuroraMySQL.Integrating.CloudWatch.md). # Mengirim keluaran log Aurora MySQL ke tabel Anda dapat mengarahkan log umum dan log kueri lambat ke tabel di instans DB dengan membuat grup parameter DB dan menetapkan parameter server `log_output` ke `TABLE`. Kueri umum lalu dicatat ke tabel `mysql.general_log` dan kueri lambat dicatat ke tabel `mysql.slow_log`. Anda dapat mengueri tabel untuk mengakses informasi log. Mengaktifkan pencatatan log ini akan meningkatkan jumlah data yang akan ditulis ke basis data, yang dapat menurunkan performa. Log umum dan log kueri lambat dinonaktifkan secara default. Untuk mengaktifkan pencatatan log ke tabel, Anda juga harus mengatur parameter server `general_log` dan `slow_query_log` ke `1`. Tabel log terus bertambah hingga aktivitas pencatatan log masing-masing dinonaktifkan dengan mengatur ulang parameter yang sesuai ke `0`. Banyak data yang sering terakumulasi seiring berjalannya waktu. Hal ini dapat menghabiskan cukup banyak ruang penyimpanan yang dialokasikan. Amazon Aurora tidak memungkinkan Anda memotong tabel log, tetapi Anda dapat memindahkan konten tabel. Merotasi tabel akan menyimpan kontennya ke tabel cadangan dan membuat tabel log kosong yang baru. Anda dapat merotasi tabel log secara manual dengan mengikuti prosedur perintah berikut, tempat permintaan perintah ditunjukkan oleh `PROMPT>`: ``` PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log; ``` Untuk menghapus data lama sepenuhnya dan mengosongkan kembali ruang disk, panggil prosedur yang sesuai dua kali secara berurutan. # Mengkonfigurasi Aurora untuk database Single-AZ *Log biner* adalah sekumpulan file log yang berisi informasi tentang modifikasi data yang dibuat ke instans server Aurora MySQL. Log biner berisi informasi seperti berikut: + Peristiwa yang menggambarkan perubahan basis data seperti pembuatan tabel atau modifikasi baris + Informasi tentang durasi setiap pernyataan yang memperbarui data + Peristiwa untuk pernyataan yang bisa saja memperbarui data, tetapi tidak Log biner mencatat pernyataan yang dikirim selama replikasi. Log ini juga diperlukan untuk beberapa operasi pemulihan. Untuk informasi selengkapnya, lihat [Log Biner](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dalam dokumentasi MySQL. Log biner hanya dapat diakses dari instans DB primer, bukan dari replika. MySQL di Amazon Aurora mendukung format pencatatan log biner *berbasis baris*, *berbasis pernyataan*, dan *campuran*. Kami merekomendasikan campuran kecuali Anda memerlukan format binlog tertentu. Untuk detail tentang berbagai format log biner Aurora MySQL, lihat [Format Pencatatan](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) Biner dalam dokumentasi MySQL. Jika Anda berencana menggunakan replikasi, format pencatatan log biner diperlukan karena menentukan catatan perubahan data yang dicatat di sumber dan dikirim ke target replikasi. Untuk informasi tentang kelebihan dan kekurangan format logging biner yang berbeda untuk replikasi, lihat [Keuntungan dan Kerugian Replikasi Berbasis Pernyataan dan Berbasis Baris dalam dokumentasi MySQL.](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) **penting** Dengan MySQL 8.0.34, MySQL menghentikan parameter. `binlog_format` Di versi MySQL selanjutnya, MySQL berencana untuk menghapus parameter dan hanya mendukung replikasi berbasis baris. Sebagai hasilnya, sebaiknya gunakan logging berbasis baris untuk pengaturan replikasi MySQL baru. Untuk informasi selengkapnya, lihat [binlog\$1format dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) MySQL. MySQL versi 8.0 dan 8.4 menerima parameter. `binlog_format` Saat menggunakan parameter ini, MySQL mengeluarkan peringatan penghentian. Dalam rilis utama future, MySQL akan menghapus parameter. `binlog_format` Replikasi berbasis pernyataan dapat menyebabkan inkonsistensi antara klaster DB dan replika baca. Untuk informasi selengkapnya, lihat [Penentuan Pernyataan Aman dan Tidak Aman di Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) di dokumentasi MySQL. Mengaktifkan logging biner meningkatkan jumlah I/O operasi write disk ke cluster DB. Anda dapat memantau penggunaan IOPS dengan `` `VolumeWriteIOPs` CloudWatch metrik. **Untuk mengatur format pencatatan log biner MySQL** 1. Buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Di panel navigasi, pilih **Grup parameter**. 1. Pilih grup parameter klaster DB, yang terkait dengan klaster DB, yang ingin dimodifikasi. Anda tidak dapat mengubah grup parameter default. Jika klaster DB menggunakan grup parameter default, buat grup parameter baru dan hubungkan dengan klaster DB. Untuk mengetahui informasi selengkapnya tentang grup parameter, lihat [](USER_WorkingWithParamGroups.md). 1. Dari **Tindakan**, pilih **Edit**. 1. Atur parameter `binlog_format` ke format pencatatan log biner pilihan Anda (`ROW`, `STATEMENT`, atau `MIXED`). Anda juga dapat menggunakan nilai `OFF` untuk menonaktifkan pencatatan log biner. **catatan** Pengaturan `binlog_format` ke `OFF` dalam kelompok parameter cluster DB menonaktifkan variabel `log_bin` sesi. Ini menonaktifkan logging biner pada cluster DB MySQL Aurora, yang pada gilirannya `binlog_format` mengatur ulang variabel sesi ke nilai default dalam database. `ROW` 1. Pilih **Simpan perubahan** untuk menyimpan pembaruan ke grup parameter klaster DB. Setelah melakukan langkah-langkah ini, Anda harus mem-boot ulang instans penulis di klaster DB untuk menerapkan perubahan. Dalam Aurora MySQL versi 2.09 dan yang lebih rendah, saat Anda mem-boot ulang instans penulis, semua instans pembaca di klaster DB juga akan di-boot ulang. Dalam Aurora MySQL versi 2.10 dan yang lebih baru, Anda harus mem-boot ulang semua instans pembaca secara manual. Untuk informasi selengkapnya, lihat [Mem-boot ulang klaster DB Amazon Aurora atau instans DB Amazon Aurora](USER_RebootCluster.md). **penting** Mengubah grup parameter klaster DB memengaruhi semua klaster DB yang menggunakan grup parameter tersebut. Jika Anda ingin menentukan format logging biner yang berbeda untuk cluster Aurora MySQL DB yang berbeda di AWS Wilayah, cluster DB harus menggunakan kelompok parameter cluster DB yang berbeda. Grup parameter ini mengidentifikasi format pencatatan log yang berbeda. Tetapkan grup parameter klaster DB yang sesuai ke masing-masing klaster DB. Untuk mengetahui informasi selengkapnya tentang parameter Aurora MySQL, lihat [Parameter konfigurasi Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md). # Mengakses log biner MySQL Anda dapat menggunakan utilitas mysqlbinlog untuk mengunduh atau mengalirkan log biner dari instans DB RDS for MySQL. Log biner diunduh ke komputer lokal, tempat Anda dapat melakukan tindakan seperti memutar ulang log menggunakan utilitas mysql. Untuk mengetahui informasi selengkapnya tentang cara menggunakan utilitas mysqlbinlog, lihat [Using mysqlbinlog to back up binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) dalam dokumentasi MySQL. Untuk menjalankan utilitas mysqlbinlog terhadap instans Amazon RDS, gunakan opsi berikut: + `--read-from-remote-server` – Wajib diisi. + `--host` – Nama DNS dari titik akhir instans. + `--port` – Port yang digunakan oleh instans. + `--user` – Pengguna MySQL yang telah diberi izin `REPLICATION SLAVE`. + `--password` – Kata sandi untuk pengguna MySQL, atau hapus nilai kata sandi agar utilitas meminta Anda memasukkan kata sandi. + `--raw` – Mengunduh file dalam format biner. + `--result-file` – File lokal untuk menerima output mentah. + `--stop-never` – Mengalirkan file log biner. + `--verbose` – Jika Anda menggunakan format binlog `ROW`, sertakan opsi ini untuk melihat peristiwa baris sebagai pernyataan pseudo-SQL. Untuk mengetahui informasi selengkapnya tentang opsi `--verbose`, lihat [mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) dalam dokumentasi MySQL. + Tentukan nama satu atau beberapa file log biner. Untuk mendapatkan daftar log yang tersedia, gunakan perintah SQL `SHOW BINARY LOGS`. Untuk mengetahui informasi selengkapnya tentang opsi mysqlbinlog, lihat [mysqlbinlog — Utility for processing binary log files](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) dalam dokumentasi MySQL. Contoh berikut menunjukkan cara menggunakan utilitas mysqlbinlog. Untuk Linux, macOS, atau Unix: ``` mysqlbinlog \ --read-from-remote-server \ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password \ --raw \ --verbose \ --result-file=/tmp/ \ binlog.00098 ``` Untuk Windows: ``` mysqlbinlog ^ --read-from-remote-server ^ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password ^ --raw ^ --verbose ^ --result-file=/tmp/ ^ binlog.00098 ``` Log biner harus tetap tersedia pada instance DB untuk utilitas mysqlbinlog untuk mengaksesnya. Untuk memastikan ketersediaannya, gunakan prosedur yang [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) disimpan dan tentukan periode dengan waktu yang cukup bagi Anda untuk mengunduh log. Jika konfigurasi ini tidak disetel, Amazon RDS membersihkan log biner sesegera mungkin, yang menyebabkan celah di log biner yang diambil oleh utilitas mysqlbinlog. Contoh berikut menetapkan periode retensi ke 1 hari. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` Untuk menampilkan pengaturan saat ini, gunakan prosedur tersimpan [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration). ``` call mysql.rds_show_configuration; ``` # Anda dapat memantau jenis file log Aurora PostgreSQL berikut: + Log PostgreSQL + Log contoh + Log kesalahan otentikasi basis data IAM **catatan** Untuk informasi selengkapnya tentang mengaktifkan autentikasi database IAM, lihat. [Mengaktifkan dan menonaktifkan autentikasi basis data IAM](UsingWithRDS.IAMDBAuth.Enabling.md) Aurora PostgreSQL mencatat aktivitas basis data ke file log PostgreSQL default. Untuk instans DB PostgreSQL on-premise, pesan ini disimpan secara titik waktu di `log/postgresql.log`. Untuk klaster DB Aurora PostgreSQL, file log tersedia di klaster Aurora. Log ini juga dapat diakses melalui Konsol Manajemen AWS, di mana Anda dapat melihat atau mengunduhnya. Tingkat pencatatan log default menangkap kegagalan masuk, kesalahan server fatal, kebuntuan, dan kegagalan kueri. Untuk mengetahui informasi selengkapnya tentang cara menampilkan, mengunduh, dan melihat log basis data berbasis file, lihat [Memantau log Amazon Aurora Amazon](USER_LogAccess.md). Untuk mempelajari selengkapnya tentang log PostgreSQL, lihat [Menggunakan log Amazon RDS dan Aurora PostgreSQL: Bagian 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) dan [Menggunakan log Amazon RDS dan Aurora PostgreSQL: Bagian 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/). Selain log PostgreSQL standar yang dibahas dalam topik ini, Aurora PostgreSQL juga mendukung ekstensi PostgreSQL Audit (`pgAudit`). Sebagian besar industri dan lembaga pemerintah yang teregulasi perlu mempertahankan log audit atau jejak audit perubahan yang dibuat pada data untuk memenuhi persyaratan hukum. Untuk mengetahui informasi tentang cara menginstal dan menggunakan pgAudit, lihat [Menggunakan pgAudit untuk mencatat aktivitas database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). Aurora membuat file log terpisah untuk instans DB yang mengaktifkan jeda otomatis. File instance.log ini mencatat alasan mengapa instance DB ini tidak dapat dijeda saat diharapkan. Untuk informasi selengkapnya tentang perilaku file log instance dan kemampuan jeda otomatis Aurora, lihat Memantau aktivitas jeda dan melanjutkan [Aurora Tanpa Server v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). **Topics** + [ # ](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md) + [ # ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) # Anda dapat menyesuaikan perilaku pencatatan log untuk klaster DB Aurora PostgreSQL dengan mengubah berbagai parameter. Dalam tabel berikut, Anda dapat menemukan parameter yang memengaruhi durasi penyimpanan log, waktu untuk memutar log, dan apakah akan menampilkan log sebagai format CSV (nilai yang dipisahkan koma). Anda juga dapat menemukan output teks yang dikirim ke STDERR, di antara pengaturan lainnya. Untuk mengubah pengaturan parameter yang dapat diubah, gunakan grup parameter klaster DB kustom untuk klaster DB Aurora PostgreSQL. Untuk mengetahui informasi selengkapnya, lihat [](USER_WorkingWithParamGroups.md). | Parameter | Default | Deskripsi | | --- | --- | --- | | log\$1destination | stderr | Menetapkan format output untuk log. Default-nya adalah `stderr`, tetapi Anda juga dapat menentukan nilai dipisahkan koma (CSV) dengan menambahkan `csvlog` ke pengaturan. Untuk informasi selengkapnya, lihat [Mengatur tujuan log (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). | | log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Menentukan pola untuk nama file log. Selain default, parameter ini mendukung `postgresql.log.%Y-%m-%d` dan `postgresql.log.%Y-%m-%d-%H` untuk pola nama file. Untuk Aurora PostgreSQL versi 17.4 dan yang lebih baru, Anda tidak dapat mengubah parameter ini. | | log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Mendefinisikan awalan untuk setiap baris log yang akan ditulis ke `stderr`, untuk mencatat waktu (%t), host jarak jauh (%r), pengguna (%u), basis data (%d), dan ID proses (%p). | | log\$1rotation\$1age | 60 | Menit setelah file log dirotasi secara otomatis. Anda dapat mengubah nilai ini dalam kisaran 1 dan 1440 menit. Untuk informasi selengkapnya, lihat [Mengatur rotasi file log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | log\$1rotation\$1size | – | Ukuran (kB) tempat log dirotasi secara otomatis. Anda dapat mengubah nilai ini dalam kisaran 50.000 hingga 1.000.000 kilobyte. Untuk mempelajari selengkapnya, lihat [Mengatur rotasi file log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | rds.log\$1retention\$1period | 4320 | Log PostgreSQL yang lebih lama dari jumlah menit yang ditentukan dihapus. Nilai default 4320 menit menghapus file log setelah 3 hari. Untuk informasi selengkapnya, lihat [Mengatur periode retensi log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). | Untuk mengidentifikasi masalah aplikasi, Anda dapat mencari kegagalan kueri, kegagalan masuk, kebuntuan, dan kesalahan server fatal di log. Misalnya, anggaplah Anda mengonversi aplikasi lama dari Oracle ke Aurora PostgreSQL, tetapi tidak semua kueri dikonversi dengan benar. Kueri yang salah format ini menghasilkan pesan kesalahan yang dapat Anda temukan di log untuk membantu mengidentifikasi masalah. Untuk mengetahui informasi selengkapnya tentang pencatatan log kueri, lihat [](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md). Dalam topik berikut, Anda dapat menemukan informasi tentang cara mengatur berbagai parameter yang mengontrol detail dasar untuk log PostgreSQL Anda. **Topics** + [ ## Mengatur periode retensi log ](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period) + [ ## Mengatur rotasi file log ](#USER_LogAccess.Concepts.PostgreSQL.log_rotation) + [ ## Mengatur tujuan log (`stderr`, `csvlog`) ](#USER_LogAccess.Concepts.PostgreSQL.Log_Format) + [ ## Memahami parameter log\$1line\$1prefix ](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix) ## Mengatur periode retensi log Parameter `rds.log_retention_period` menentukan berapa lama klaster DB Aurora PostgreSQL menyimpan file log-nya. Pengaturan default-nya adalah 3 hari (4.320 menit), tetapi Anda dapat mengatur nilai ini ke mana saja dari 1 hari (1.440 menit) hingga 7 hari (10.080 menit). Pastikan bahwa klaster DB Aurora PostgreSQL Anda memiliki penyimpanan yang cukup untuk menyimpan file log selama periode waktu tertentu. Kami menyarankan agar log Anda dipublikasikan secara rutin ke Amazon CloudWatch Logs sehingga Anda dapat melihat dan menganalisis data sistem lama setelah log dihapus dari cluster DB PostgreSQL Aurora Anda. Untuk mengetahui informasi selengkapnya, lihat [Menerbitkan log Aurora PostgreSQL ke Amazon Logs CloudWatch](AuroraPostgreSQL.CloudWatch.md). Setelah Anda mengatur CloudWatch penerbitan, Aurora tidak menghapus log sampai setelah diterbitkan ke CloudWatch Log. Amazon Aurora mengompresi log PostgreSQL lama ketika penyimpanan untuk instans DB mencapai ambang batas. Aurora mengompresi file menggunakan utilitas kompresi gzip. Untuk mengetahui informasi selengkapnya, lihat situs web [gzip](https://www.gzip.org). Saat penyimpanan instans DB rendah dan semua log yang tersedia dikompresi, Anda akan mendapatkan peringatan seperti berikut: ``` Warning: local storage for PostgreSQL log files is critically low for this Aurora PostgreSQL instance, and could lead to a database outage. ``` Jika tidak ada cukup penyimpanan, Aurora dapat menghapus log PostgreSQL yang terkompresi sebelum akhir periode retensi tertentu. Jika hal ini terjadi, Anda akan melihat pesan yang mirip dengan pesan berikut: ``` The oldest PostgreSQL log files were deleted due to local storage constraints. ``` ## Mengatur rotasi file log Aurora membuat file log baru setiap jam secara default. Waktu dikontrol oleh parameter `log_rotation_age`. Parameter ini memiliki nilai default 60 (menit), tetapi Anda dapat mengaturnya ke mana saja dari 1 menit hingga 24 jam (1.440 menit). Ketika tiba waktunya rotasi, file log baru yang berbeda akan dibuat. File ini diberi nama sesuai dengan pola yang ditentukan oleh parameter `log_filename`. File log juga dapat dirotasi sesuai dengan ukurannya, seperti yang ditentukan dalam parameter `log_rotation_size`. Parameter ini menentukan bahwa log harus dirotasi saat mencapai ukuran yang ditentukan (dalam kilobyte). Nilai default `log_rotation_size` adalah 100000 kB (kilobyte) untuk klaster DB Aurora PostgreSQL, tetapi Anda dapat mengatur nilai ini ke mana pun dari 50.000 hingga 1.000.000 kilobyte. Nama file log didasarkan pada pola nama file yang ditentukan dalam parameter `log_filename`. Pengaturan yang tersedia untuk parameter ini adalah sebagai berikut: + `postgresql.log.%Y-%m-%d` – Format default untuk nama file log. Termasuk tahun, bulan, dan tanggal dalam nama file log. + `postgresql.log.%Y-%m-%d-%H` – Termasuk jam dalam format nama file log. + `postgresql.log.%Y-%m-%d-%H%M` – Termasuk jam:menit dalam format nama file log. Jika Anda mengatur parameter `log_rotation_age` ke kurang dari 60 menit, atur parameter `log_filename` ke format menit. Untuk mengetahui informasi selengkapnya, lihat [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) dan [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) dalam dokumentasi PostgreSQL. ## Mengatur tujuan log (`stderr`, `csvlog`) Secara default, Aurora PostgreSQL menghasilkan log dalam format kesalahan standar (stderr). Format ini adalah pengaturan default untuk parameter `log_destination`. Setiap pesan diawali menggunakan pola yang ditentukan dalam parameter `log_line_prefix`. Untuk mengetahui informasi selengkapnya, lihat [Memahami parameter log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix). Aurora PostgreSQL juga dapat menghasilkan log dalam format `csvlog`. `csvlog` berguna untuk menganalisis data log sebagai data nilai yang dipisahkan koma (CSV). Misalnya, anggaplah Anda menggunakan ekstensi `log_fdw` untuk bekerja dengan log Anda sebagai tabel asing. Tabel asing yang dibuat pada file log `stderr` berisi satu kolom dengan data peristiwa log. Dengan menambahkan `csvlog` ke parameter `log_destination`, Anda mendapatkan file log dalam format CSV dengan demarkasi untuk beberapa kolom tabel asing. Anda kini dapat mengurutkan dan menganalisis log dengan lebih mudah. Jika Anda menentukan `csvlog` untuk parameter ini, perhatikan bahwa file `stderr` dan `csvlog` dihasilkan. Pastikan untuk memantau penyimpanan yang digunakan oleh log, dengan mempertimbangkan `rds.log_retention_period` dan pengaturan lain yang memengaruhi penyimpanan log dan omset. Menggunakan `stderr` dan `csvlog` lebih dari dua kali lipat penyimpanan yang digunakan oleh log. Jika Anda menambahkan `csvlog` ke `log_destination` dan ingin kembali ke `stderr` sendiri, Anda perlu mengatur ulang parameter. Untuk melakukannya, buka Konsol Amazon RDS, lalu buka grup parameter klaster DB untuk instans Anda. Pilih parameter `log_destination`, pilih **Edit parameter**, lalu pilih **Atur ulang**. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi pencatatan log, lihat [Menggunakan log Amazon RDS dan Aurora PostgreSQL: Bagian 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/). ## Memahami parameter log\$1line\$1prefix Format `stderr` log awalan setiap pesan log dengan rincian yang ditentukan oleh parameter. `log_line_prefix` Nilai defaultnya adalah: ``` %t:%r:%u@%d:[%p]:t ``` Mulai dari Aurora PostgreSQL versi 16, Anda juga dapat memilih: ``` %m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a ``` Setiap entri log yang dikirim ke stderr mencakup informasi berikut berdasarkan nilai yang dipilih: + `%t`— Waktu entri log tanpa milidetik + `%m`— Waktu entri log dengan milidetik + `%r` – Alamat host jarak jauh + `%u@%d` – Nama pengguna @ nama basis data + `[%p]` – ID Proses jika tersedia + `%l`— Nomor baris log per sesi + `%e`— Kode kesalahan SQL + `%s`— Stempel waktu mulai proses + `%v`— Id transaksi virtual + `%x`— ID Transaksi + `%c`— ID Sesi + `%q`— Terminator non-sesi + `%a`— Nama aplikasi # Anda dapat mengumpulkan informasi yang lebih mendetail tentang aktivitas basis data, termasuk kueri, kueri yang menunggu kunci, titik pemeriksaan, dan banyak detail lainnya dengan mengatur beberapa parameter yang tercantum dalam tabel berikut. Topik ini berfokus pada kueri pencatatan log. | Parameter | Default | Deskripsi | | --- | --- | --- | | log\$1connections | – | Mencatat log setiap koneksi yang berhasil. Untuk mempelajari cara menggunakan parameter ini dengan `log_disconnections` untuk mendeteksi churn koneksi, lihat[](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1disconnections | – | Mencatat log akhir setiap sesi dan durasinya. Untuk mempelajari cara menggunakan parameter ini dengan `log_connections` untuk mendeteksi churn koneksi, lihat[](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1checkpoints | — | Tidak berlaku untuk Aurora PostgreSQL | | log\$1lock\$1waits | – | Mencatat log waktu tunggu kunci yang panjang. Secara default, parameter ini tidak diatur. | | log\$1min\$1duration\$1sample | – | (md) Menetapkan waktu eksekusi minimum yang jika terlampaui akan membuat sampel pernyataan dicatat. Ukuran sampel diatur menggunakan parameter log\$1statement\$1sample\$1rate. | | log\$1min\$1duration\$1statement | – | Setiap pernyataan SQL yang berjalan setidaknya selama periode waktu tertentu atau lebih lama akan dicatat. Secara default, parameter ini tidak diatur. Mengaktifkan parameter ini dapat membantu Anda menemukan kueri yang belum dioptimalkan. | | log\$1statement | – | Mengatur jenis pernyataan yang dicatat. Secara default, parameter ini tidak diatur, tetapi Anda dapat mengubahnya ke `all`, `ddl`, atau `mod` untuk menentukan jenis pernyataan SQL yang ingin Anda catat. Jika menentukan apa pun selain `none` untuk parameter ini, Anda juga harus mengambil langkah-langkah tambahan untuk mencegah eksposur kata sandi dalam file log. Untuk informasi selengkapnya, lihat [Mengurangi risiko eksposur kata sandi saat menggunakan pencatatan log kueriMengurangi risiko eksposur kata sandi](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). | | log\$1statement\$1sample\$1rate | – | Persentase pernyataan melebihi waktu yang ditentukan dalam `log_min_duration_sample` untuk dicatat, yang dinyatakan sebagai nilai titik mengambang antara 0,0 dan 1,0. | | log\$1statement\$1stats | – | Menulis statistik performa kumulatif ke log server. | ## Menggunakan pencatatan log untuk menemukan kueri performa lambat Anda dapat mencatat pernyataan dan kueri SQL untuk membantu menemukan kueri performa lambat. Anda mengaktifkan kemampuan ini dengan memodifikasi pengaturan di `log_statement` dan parameter `log_min_duration` seperti yang diuraikan dalam bagian ini. Sebelum mengaktifkan pencatatan log kueri untuk klaster DB Aurora PostgreSQL, Anda harus mengetahui kemungkinan eksposur kata sandi di dalam log dan cara mengurangi risiko ini. Untuk informasi selengkapnya, lihat [Mengurangi risiko eksposur kata sandi saat menggunakan pencatatan log kueriMengurangi risiko eksposur kata sandi](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). Berikut ini, Anda dapat menemukan informasi referensi tentang parameter `log_statement` dan `log_min_duration`.log\$1statement Parameter ini menentukan jenis pernyataan SQL yang harus dikirim ke log. Nilai default-nya adalah `none`. Jika Anda mengubah parameter ini ke `all`, `ddl`, atau `mod`, pastikan untuk menerapkan tindakan yang disarankan untuk mengurangi risiko eksposur kata sandi di dalam log. Untuk informasi selengkapnya, lihat [Mengurangi risiko eksposur kata sandi saat menggunakan pencatatan log kueriMengurangi risiko eksposur kata sandi](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). **all** Mencatat log semua pernyataan. Pengaturan ini direkomendasikan untuk tujuan debugging. **ddl** Mencatat log semua pernyataan bahasa definisi data (DDL), seperti CREATE, ALTER, DROP, dan seterusnya. **mod** Mencatat log semua pernyataan DDL dan pernyataan bahasa manipulasi data (DL), seperti INSERT, UPDATE, dan DELETE, yang mengubah data. **none** Tidak ada pernyataan SQL yang dicatat. Kami merekomendasikan pengaturan ini untuk menghindari risiko eksposur kata sandi di dalam log.log\$1min\$1duration\$1statement Setiap pernyataan SQL yang berjalan setidaknya selama periode waktu tertentu atau lebih lama akan dicatat. Secara default, parameter ini tidak diatur. Mengaktifkan parameter ini dapat membantu Anda menemukan kueri yang belum dioptimalkan. **–1–2147483647** Jumlah milidetik (md) runtime di mana pernyataan dicatat. **Untuk menyiapkan pencatatan log kueri** Langkah-langkah ini mengasumsikan bahwa klaster DB Aurora PostgreSQL Anda menggunakan grup parameter klaster kustom. 1. Atur parameter `log_statement` ke `all`. Contoh berikut ini menunjukkan informasi yang ditulis ke file `postgresql.log` dengan pengaturan parameter ini. ``` 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats: ! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed ! [0.025146 s user, 0.000000 s system total] ! 36644 kB max resident size ! 0/8 [0/8] filesystem blocks in/out ! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 19/0 [27/0] voluntary/involuntary context switches 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC; ----------------------- END OF LOG ---------------------- ``` 1. Atur parameter `log_min_duration_statement`. Contoh berikut ini menunjukkan informasi yang ditulis ke file `postgresql.log` saat pengaturan parameter ini diatur ke `1`. Kueri yang melebihi durasi yang ditentukan dalam parameter `log_min_duration_statement` dicatat. Bagian berikut menunjukkan satu contoh. Anda dapat melihat file log untuk klaster DB Aurora PostgreSQL di Konsol Amazon RDS. ``` 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments; 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms 2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time 2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB ----------------------- END OF LOG ---------------------- ``` ### Mengurangi risiko eksposur kata sandi saat menggunakan pencatatan log kueri Sebaiknya Anda tetap mengatur `log_statement` ke `none` agar tidak mengekspos kata sandi. Jika Anda mengatur `log_statement` ke `all`, `ddl`, atau `mod`, sebaiknya Anda mengambil satu atau beberapa langkah berikut. + Untuk klien, enkripsi informasi sensitif. Untuk mengetahui informasi selengkapnya, lihat [Opsi Enkripsi](https://www.postgresql.org/docs/current/encryption-options.html) dalam dokumentasi PostgreSQL. Gunakan opsi `ENCRYPTED` (dan `UNENCRYPTED`) dari pernyataan `CREATE` dan `ALTER`. Untuk mengetahui informasi selengkapnya, lihat [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) dalam dokumentasi PostgreSQL. + Untuk klaster DB Aurora PostgreSQL, siapkan dan gunakan ekstensi PostgreSQL Audit (pgAaudit). Ekstensi ini menyunting informasi sensitif dalam pernyataan CREATE dan ALTER yang dikirim ke log. Untuk informasi selengkapnya, lihat [Menggunakan pgAudit untuk mencatat aktivitas database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). + Batasi akses ke CloudWatch log. + Gunakan mekanisme autentikasi yang lebih kuat seperti IAM.