Memecahkan masalah agen Logging

Halaman ini memberikan petunjuk untuk memecahkan masalah umum yang ditemukan saat menginstal atau berinteraksi dengan agen Logging.

Checklist

Jika Anda mengalami masalah saat menginstal atau menggunakan agen Logging, berikut beberapa hal yang perlu diperiksa:

  • Jika perintah penginstalan Linux menghasilkan error, pastikan Anda menambahkan awalan sudo ke perintah penginstalan.

  • Pastikan layanan agen berjalan di instance VM Anda:

    • Untuk VM Windows, gunakan perintah PowerShell berikut:

      Get-Service -Name StackdriverLogging

      Telusuri layanan bernama Stackdriver Logging. Jika agen tidak berjalan, Anda mungkin perlu memulai ulang.

    • Untuk VM Linux, gunakan perintah berikut:

      sudo service google-fluentd status

      Jika agen tidak berjalan, Anda mungkin perlu memulai ulang menggunakan perintah berikut:

      sudo service google-fluentd restart

      Jika mulai ulang gagal, dan output log menampilkan "Dinonaktifkan melalui metadata", Anda mungkin menjalankan image dari Google Cloud Marketplace, tempat agen Logging dinonaktifkan secara default. Kunci metadata instance google-logging-enable mengendalikan status pengaktifan agen Logging, dengan nilai 0 menonaktifkan agen. Untuk mengaktifkan kembali agen, hapus kunci google-logging-enable atau tetapkan nilainya ke 1. Untuk mengetahui informasi selengkapnya, lihat Membuat instance dengan agen logging dinonaktifkan).

      Jika agen tidak dinonaktifkan melalui metadata, instal ulang agen. Lihat bagian berikut, Menginstal ulang agen Logging.

  • Lihat apakah agen telah menulis pesan error ke log.

    • Di Windows, mulai versi v1-9, agen Logging menyimpan lognya di C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

      Tidak ada cara untuk mendapatkan log untuk versi agen sebelumnya.

    • Di Linux, Agen logging adalah paket fluentd dan mencatat pesan ke /var/log/google-fluentd/google-fluentd.log:

      • Jika Anda melihat error HTTP 429, Anda mungkin telah melampaui kuota Logging API. Anda dapat melihat kuota yang tersedia dengan memilih API & layanan > Dasbor di konsol Google Cloud. Pilih Logging API.

      • Jika Anda melihat masalah akses atau otorisasi API, buka Memverifikasi kredensial Compute Engine.

  • Jika agen tampaknya berjalan normal, tetapi Anda tidak mendapatkan data, Anda harus memeriksa apakah agen mengirimkan data ke project yang benar. Lihat bagian berikut, Memverifikasi kredensial Compute Engine.

  • Jika agen gagal memberikan otorisasi, periksa apakah kredensial untuk kunci pribadi Anda tidak ada atau tidak valid.

Memverifikasi penginstalan agen

Untuk memeriksa apakah penginstalan berhasil, cari entri log pengujian agen di Logs Explorer.

  1. Di konsol Google Cloud, buka halaman Logs Explorer:

    Buka Logs Explorer

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Logging.

  2. Di bagian atas halaman, pilih project yang berisi instance VM Anda:

    • Untuk instance VM Compute Engine, pilih project Google Cloud yang berisi instance VM.
    • Untuk instance VM Amazon EC2, pilih project Google Cloud tempat Anda mengirim log.

  3. Di tab jendela, pilih resource untuk instance VM Anda:

    • Untuk Compute Engine, pilih Instance VM GCE.
    • Untuk Amazon EC2, pilih AWS EC2 Instance.
    • Pilih syslog (Linux), fluent.info (Windows), atau Semua log.

Jika Anda melihat entri log, "Berhasil mengirim gRPC ke Logging API", penginstalan agen telah selesai. Pesan ini dibuat satu kali saat agen diinstal dan juga setiap kali agen dimulai ulang.

Untuk mengetahui informasi selengkapnya tentang Logs Explorer, lihat Menggunakan Logs Explorer.

Menguji agen

Jika Anda mencurigai bahwa agen tidak berfungsi, pastikan agen tersebut berjalan dan coba kirim pesan pengujian ke Logging:

Instance Linux

Prosedur berikut berfungsi di instance VM Compute Engine dan Amazon EC2 yang menjalankan Linux:

  1. Pastikan agen Logging berjalan dengan menjalankan perintah berikut di instance VM Anda:

    ps ax | grep fluentd

    Anda akan melihat output yang mirip dengan berikut ini:

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
 2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]

  2. Kirim pesan log pengujian dengan menjalankan perintah berikut pada instance VM Anda:

    logger "Some test message"

Instance Windows

Agen Logging memiliki dua nama layanan Windows:

  • StackdriverLogging untuk versi v1-5 dan yang lebih baru
  • fluentdwinsvc untuk versi sebelumnya

Anda harus menjalankan satu layanan agen. Jalankan perintah berikut di instance VM Anda menggunakan PowerShell:

  1. Tanyakan status kedua layanan tersebut. Jika mengetahui layanan yang harus berjalan, Anda dapat menggunakan nama layanan tersebut saja:

    Get-Service StackdriverLogging,fluentdwinsvc

  2. Jika layanan tidak berjalan, Anda akan melihat pesan error. Jika sedang berjalan, Anda akan melihat output seperti berikut:

    Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging

  3. Jika membuat kueri untuk kedua layanan tersebut, Anda akan melihat satu pesan error dan satu status Running:

    • Jika Anda tidak melihat status Running, berarti agen Logging tidak berjalan.
    • Jika Anda melihat bahwa StackdriverLogging sedang berjalan, berarti Anda menjalankan versi agen terbaru. Untuk menentukan versi tertentu, lihat Mendapatkan versi.
    • Jika Anda melihat bahwa fluentdwinsvc sedang berjalan, Anda harus mengupgrade agen ke versi terbaru.

  4. Memerlukan hak istimewa Administrator: Jika ada versi agen yang berjalan, kirim pesan log pengujian dengan menjalankan perintah PowerShell berikut:

    New-EventLog   -LogName Application -Source "Test Source"
Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."

Menemukan pesan pengujian

Setelah mengirim pesan pengujian, cari pesan tersebut di Logs Explorer:

  1. Di konsol Google Cloud, buka halaman Logs Explorer:

    Buka Logs Explorer

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Logging.

  2. Di bagian atas halaman, pilih project yang berisi instance VM Anda:

    • Untuk instance VM Compute Engine, pilih project Google Cloud yang berisi instance VM.
    • Untuk instance VM Amazon EC2, pilih project Google Cloud tempat Anda mengirim log.

  3. Di tab jendela, pilih resource untuk instance VM Anda:

    • Untuk Compute Engine, pilih Instance VM GCE.
    • Untuk Amazon EC2, pilih AWS EC2 Instance.
    • Pilih syslog (Linux), fluent.info (Windows), atau Semua log.

  4. Anda akan melihat entri log dengan pesan pengujian Anda. Jika demikian, agen logging beroperasi dengan benar.

Memverifikasi kredensial Compute Engine

Agar instance VM Compute Engine dapat menjalankan agen tanpa kredensial kunci pribadi, instance harus memiliki cakupan akses yang sesuai dan identitas akun layanan yang digunakan oleh instance harus memiliki izin IAM yang sesuai.

Saat Anda membuat instance VM, setelan akun layanan dan cakupan default sudah memadai untuk menjalankan agen. Instance yang sangat lama, atau instance yang setelan defaultnya telah Anda ubah, mungkin tidak memiliki kredensial yang sesuai.

Gagal memuat kredensial default

Jika ada kegagalan Could not load the default credentials dalam file log Logging, hal ini menyiratkan bahwa agen mungkin gagal terhubung ke Server Metadata Compute Engine.

Log error terlihat seperti berikut:

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

Salah satu kemungkinan penyebabnya adalah jika VM memiliki penyiapan proxy kustom. Untuk memperbaikinya, baca Petunjuk penyiapan proxy untuk mengecualikan Server Metadata Compute Engine (metadata.google.internal, atau 169.254.169.254) agar tidak melewati proxy. Jika error berlanjut, hapus akun layanan Compute Engine default dari VM, lalu tambahkan kembali.

Memverifikasi cakupan akses

Untuk memverifikasi cakupan akses, lakukan hal berikut:

  1. Di Konsol Google Cloud, buka halaman Instance VM:

    Buka instance VM

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Compute Engine.

  2. Klik nama instance VM Anda. Halaman detail untuk instance Anda akan muncul.

  3. Di bagian Cakupan akses Cloud API, klik Detail untuk melihat daftar API. Cari entri berikut:

    1. Jika Anda melihat "Instance ini memiliki akses API penuh ke semua Layanan Google Cloud", cakupan akses Anda sudah memadai.
    2. Jika Anda melihat di samping Stackdriver Logging API, nama lama untuk Cloud Logging API, bahwa Anda memiliki izin Hanya Tulis atau Penuh, berarti cakupan akses instance Anda memadai untuk agen Cloud Logging.
    3. Jika Anda melihat di samping Stackdriver Monitoring API, nama lama untuk Cloud Monitoring API, bahwa Anda memiliki izin Hanya Tulis atau Penuh, berarti cakupan akses instance Anda memadai untuk agen Cloud Monitoring.

Memperbaiki masalah

Jika Anda tidak memiliki cakupan akses yang sesuai di instance Compute Engine, tambahkan cakupan akses yang diperlukan ke instance Anda.

Tabel berikut menunjukkan cakupan yang relevan dengan agen Logging dan Pemantauan:

Cakupan akses Izin agen
https://www.googleapis.com/auth/logging.write Cukup untuk agen Logging
https://www.googleapis.com/auth/monitoring.write Cukup untuk agen Monitoring

Memverifikasi izin akun layanan default

Meskipun cakupan akses instance VM Compute Engine Anda memadai, akun layanan default instance Anda mungkin tidak memberikan izin IAM yang tepat untuk agen.

Untuk memverifikasi izin akun layanan default, mulailah dengan menemukan akun layanan default:

  1. Di Konsol Google Cloud, buka halaman Instance VM:

    Buka instance VM

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Compute Engine.

  2. Klik nama instance VM Anda. Halaman detail untuk instance Anda akan muncul.

  3. Cari judul Service account di halaman. Akun layanan default untuk instance tercantum. Tampilannya mungkin seperti berikut:

    [ID]-compute@

  4. Di konsol Google Cloud, buka halaman IAM:

    Buka IAM

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah IAM & Admin.

  5. Pilih Lihat Menurut: Prinsipal. Anda akan melihat daftar orang, grup, dan akun layanan. Di kolom Role adalah peran yang dimiliki setiap akun utama dalam project Anda.

  6. Di baris untuk akun layanan default instance, Anda akan melihat satu atau beberapa peran:

    • Jika Anda melihat Editor, peran tersebut sudah memadai untuk semua agen. Peran Editor mungkin otomatis diberikan ke akun layanan default, bergantung pada konfigurasi kebijakan organisasi Anda.
    • Jika Anda melihat Logs Writer, peran tersebut sudah cukup untuk agen logging. Untuk peran Logging lainnya yang menyertakan izin tulis, lihat Kontrol Akses untuk Cloud Logging.
    • Jika Anda melihat Monitoring Metric Writer, peran tersebut sudah cukup untuk Agen Pemantauan. Untuk peran Monitoring lainnya yang menyertakan izin tulis, lihat Kontrol Akses untuk Cloud Monitoring.

Memperbaiki masalah

Jika akun layanan default Anda tidak memiliki peran yang memadai, coba edit peran untuk akun layanan Anda di halaman IAM & admin > IAM. Tambahkan peran Logging atau Monitoring yang sesuai untuk memberikan otorisasi kepada agen: Logging > Logs Writer atau Monitoring > Monitoring Metric Writer.

Memverifikasi kredensial kunci pribadi

Pada instance VM Compute Engine, Anda dapat mengonfigurasi agen untuk menggunakan akun layanan non-default yang memiliki otorisasi yang tepat. Di Instance VM AWS EC2, Anda harus mengonfigurasi agen untuk menggunakan akun layanan tersebut.

Untuk mengonfigurasi agen dengan cara ini, Anda harus membuat kredensial kunci pribadi untuk akun layanan yang ditetapkan dan memberikan kredensial tersebut kepada agen.

  1. Agen mencari variabel lingkungan, GOOGLE_APPLICATION_CREDENTIALS, yang menyimpan nama file yang berisi kredensial kunci pribadi.

  2. Jika variabel lingkungan tidak ada, agen akan mencari kredensial di lokasi default:

    Linux

    /etc/google/auth/application_default_credentials.json

    Windows

    C:\ProgramData\Google\Auth\application_default_credentials.json

  3. Jika lokasi default tidak berisi kredensial, agen akan menggunakan kredensial default aplikasi dari server metadata.

Informasi berikut membantu Anda mendiagnosis masalah kredensial kunci pribadi:

  1. Apakah kunci pribadi sudah ada?
  2. Apakah kunci pribadi masih valid untuk akun layanan?
  3. Apakah akun layanan memiliki peran yang diperlukan untuk agen?

Untuk memverifikasi bahwa kredensial kunci pribadi yang valid diinstal di instance VM Anda, verifikasi terlebih dahulu bahwa file kredensial ada di lokasi yang diharapkan, lalu verifikasi bahwa informasi dalam file kredensial valid.

Apakah kredensial tersedia?

Untuk melihat apakah kredensial akun layanan kunci pribadi ada di instance Anda, jalankan perintah Linux berikut di instance Anda:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Jika salah satu perintah menampilkan file seperti yang ditampilkan di bawah, instance Anda mungkin memiliki kredensial kunci pribadi yang valid. Jika kedua perintah menampilkan file, maka file yang dilambangkan dengan GOOGLE_APPLICATION_CREDENTIALS akan digunakan.

{
  "type": "service_account",
  "project_id": "[YOUR-PROJECT-ID]",
  "private_key_id": "[YOUR-PRIVATE-KEY-ID]",
  "private_key": "[YOUR-PRIVATE-KEY]",
  "client_email": "[YOUR-PROJECT-NUMBER]-[YOUR-KEY]@",
  "client_id": "[YOUR-CLIENT-ID]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Perbedaan antara konfigurasi kredensial dapat menyebabkan agen menggunakan kredensial yang berbeda dengan yang diperlukan layanan Anda. Misalnya, jika Anda menetapkan lokasi kredensial kustom di GOOGLE_APPLICATION_CREDENTIALS di shell login, tetapi tidak menetapkan variabel tersebut dalam konfigurasi layanan agen, layanan akan mencari di lokasi default, bukan lokasi kustom Anda.

Untuk meninjau atau mengubah variabel lingkungan kredensial, akses atau tetapkan GOOGLE_APPLICATION_CREDENTIALS di /etc/default/google-fluentd.

Jika tidak ada file kredensial, lihat Menambahkan kredensial.

Apakah kredensial valid?

Dalam file kredensial, project_id adalah project Google Cloud Anda, client_email mengidentifikasi akun layanan dalam project, dan private_key_id mengidentifikasi kunci pribadi di akun layanan. Cocokkan informasi ini dengan informasi yang ditampilkan di bagian IAM & Admin > Service accounts di konsol Google Cloud.

File kredensial tidak valid jika salah satu hal berikut berlaku:

  • Anda memeriksa instance Compute Engine, tetapi project Google Cloud dalam file kredensial bukan project yang berisi instance Anda.
  • Anda memeriksa instance Amazon EC2, tetapi project Google Cloud dalam file kredensial bukan project Google Cloud tempat Anda mengirim log.
  • Akun layanan yang tercantum tidak ada. Mungkin telah dihapus.
  • Akun layanan yang tercantum tidak mengaktifkan peran yang tepat: Logs Writer untuk agen Cloud Logging dan Monitoring Metric Writer untuk agen Cloud Monitoring.
  • Kunci pribadi tidak ada. Izin tersebut mungkin telah dicabut.

Kredensial dapat dicabut menggunakan bagian IAM & Admin > Service accounts di konsol Google Cloud. Jika tidak ada kredensial yang valid, lihat Menambahkan kredensial untuk mengganti kredensial yang ada atau menambahkan kredensial baru.

Jika akun layanan sudah benar, tetapi kunci pribadi telah dicabut, Anda dapat membuat kunci pribadi baru dan menyalinnya ke instance. Lihat Membuat kunci akun layanan.

Jika tidak, Anda harus membuat akun layanan baru seperti yang dijelaskan di bagian Menambahkan kredensial.

Memverifikasi kueri Pengecualian Log

Lihat kueri pengecualian saat ini untuk memastikan bahwa log yang Anda cari tidak dikecualikan secara tidak sengaja.

Memverifikasi Firewall

Untuk melihat apakah instance Anda memiliki akses ke logging.googleapis.com, jalankan perintah Linux berikut pada instance Anda:

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

Perintah ini dapat memerlukan waktu beberapa saat untuk selesai jika firewall memblokir traffic keluar. Contoh output yang menunjukkan masalah firewall:

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

Buka Aturan Firewall untuk mengetahui informasi tentang cara menyiapkan aturan untuk traffic keluar.

Menginstal ulang agen

Menginstal agen versi terbaru dapat menyelesaikan banyak masalah:

Masalah umum lainnya

Tabel berikut mencantumkan beberapa masalah umum yang mungkin Anda temui dengan agen Cloud Logging dan memberi tahu Anda cara memperbaikinya.

Di Linux, agen Logging mencatat error di /var/log/google-fluentd/google-fluentd.log. Di Windows, agen Logging mencatat error di C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log (mulai dari versi v1-9). Class error Google::APIClient::ClientError menunjukkan ada masalah dengan izin atau akses API.

Anda mungkin mulai melihat error setelah agen berhasil berjalan. Misalnya, seseorang mungkin telah mencabut izin yang diperlukan dari project atau instance VM Anda.

Error Penyebab Solusi
Installer agen di Windows gagal dijalankan Anda mungkin telah mendownload penginstal ke direktori sistem. Pindahkan penginstal ke direktori non-sistem, seperti C:\Users\[USERID]\.
Project belum mengaktifkan API Anda belum mengaktifkan Cloud Logging API di project. Buka konsol API dan ubah status Cloud Logging API menjadi AKTIF.
Permintaan memiliki kredensial yang tidak valid
atau
Tidak dapat mengambil token akses (tidak ada cakupan yang dikonfigurasi?)		 Instance VM Anda tidak memiliki kredensial yang sesuai. Jika menggunakan Amazon EC2, Anda harus menginstal kredensial di instance VM sebelum menginstal agen. Lihat Memberi otorisasi pada agen Logging untuk menginstal kredensial.
Otorisasi gagal Kredensial otorisasi kunci pribadi Anda untuk agen Logging tidak dikonfigurasi dengan benar. Lihat Memverifikasi kredensial kunci pribadi.
Pemanggil tidak memiliki izin Akun layanan yang digunakan untuk otorisasi di project Anda tidak memiliki izin yang memadai. Akun layanan ini mungkin akun layanan default yang digunakan dalam Compute Engine atau App Engine, atau mungkin akun layanan yang ditentukan pengguna yang digunakan untuk otorisasi kunci pribadi. Akun tersebut harus memiliki peran Editor. Ubah izin akun layanan di halaman IAM project Anda. Jika perlu, Anda dapat mengubah cakupan akses untuk VM yang ada menggunakan Mengubah akun layanan dan cakupan akses untuk instance.
Tidak dapat memperoleh project ID Agen Cloud Logging gagal mendapatkan project ID dari file kredensial kunci pribadi akun layanan. Untuk menambahkan atau mengganti project ID untuk agen, edit file konfigurasi agen, /etc/google-fluentd/google-fluentd.conf, di instance VM Anda. Di bagian <match **>, tambahkan baris berikut:
project_id [YOUR_PROJECT_ID]
Jika tidak, lihat Memberi otorisasi ke agen Logging untuk memperbaiki atau mengganti kredensial.
Agen Logging Jendela berhenti menyerap log peristiwa dari beberapa saluran Agen Logging mungkin gagal secara diam-diam dalam menyerap log peristiwa dari saluran tertentu, meskipun masih berjalan dan menyerap log agen dan log peristiwa dari saluran lain. Alasannya adalah plugin windows_eventlog memiliki beberapa masalah seperti yang disebutkan dalam presentasi ini. Menggunakan windows_eventlog2 akan menyelesaikan masalah ini. Catatan: Format data plugin windows_eventlog2 tidak kompatibel dengan plugin windows_eventlog. Jika ada pipeline ekspor BigQuery atau Google Cloud Storage yang disiapkan untuk log ini, pipeline tersebut perlu disesuaikan. Lihat perbandingan entri log ini yang disediakan oleh windows_eventlog dan windows_eventlog2. Untuk menggunakan windows_eventlog2, Anda harus menghentikan agen Logging terlebih dahulu, lalu mengganti file konfigurasi dengan file yang mirip dengan contoh file konfigurasi ini. Terakhir, mulai agen Logging.
Agen logging berhenti menyerap log jika ada logrotate Agen Logging mungkin kehilangan jejak lokasinya dalam file input saat logrotate disiapkan dengan setelan copytruncate. Sebaiknya gunakan setelan nocopytruncate untuk memastikan logrotate memindahkan file, bukan memotongnya. Jika Anda ingin mempertahankan setelan copytruncate, solusinya adalah dengan memulai ulang agen secara berkala. Atau, Anda dapat menggunakan setelan postrotate untuk memulai ulang agen.
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" Ada beberapa instance agen Logging yang berjalan di VM. Menggunakan ps -aux | grep "/usr/sbin/google-fluentd" untuk menampilkan proses agen yang berjalan (hanya boleh ada dua: satu supervisor dan satu pekerja), dan sudo netstat -nltp | grep :24231 untuk menampilkan proses yang berjalan yang menempati port. Menghentikan instance lama sesuai kebutuhan.
Agen logging gagal dimulai karena error dari lib/fluent/config/types.rb Konfigurasi agen Logging menggunakan bagian parser ekspresi reguler yang memiliki ekspresi reguler yang salah format, sehingga menyebabkan panggilan subexp yang tidak valid dan error seperti Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call. Temukan dan perbaiki ekspresi reguler yang salah format dalam file konfigurasi agen. Tips: telusuri regex atau parse.

Batasan pada throughput log

Throughput log maksimum yang dapat diproses oleh agen Logging dibatasi oleh CPU. Penggunaan CPU cenderung meningkat saat throughput log meningkat. Namun, agen, dengan konfigurasi default, hanya dapat menggunakan maksimal satu core CPU. Jadi, saat throughput log melonjak, agen mungkin mencapai batas penggunaan CPU. Jika lonjakan ini hanya bersifat sementara, agen Logging akan buffering log dan kemudian mengejar untuk memprosesnya. Jika throughput log secara konsisten tetap tinggi, log mungkin akan melampaui buffer dan akhirnya hilang.

Biasanya, jika setiap entri log adalah teks mentah 1.000 byte dan tidak berisi pemrosesan format tambahan, agen Logging akan mencapai batas satu core CPU pada sekitar 5.500 entri log per detik. Jika entri log memerlukan pemrosesan lanjutan, misalnya penguraian JSON atau Regex, entri log maksimum per detik mungkin lebih rendah.

Jika memerlukan throughput log yang lebih tinggi, Anda dapat mempertimbangkan untuk menggunakan Ops Agent. Di Linux, untuk entri log yang berupa teks mentah 1.000 byte dan tidak memerlukan pemrosesan tambahan, Ops Agent dapat memproses sekitar 160.000 entri log per detik.

Ukuran log maksimum terlampaui

Jika satu atau beberapa entri log melebihi batas ukuran maksimum, Anda mungkin menemukan entri dalam log fluentd yang mirip dengan berikut:

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"


atau

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

Untuk mengatasi error ini, pangkas entri log Anda agar tidak melebihi batas ukuran maksimum. Misalnya, kode contoh berikut memangkas log dengan tag mytag, dengan data di kolom message:

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

Log diduplikasi

LogEntry.insertID ditambahkan dalam pipeline pemrosesan dalam agen. Jika insertID berbeda di antara log duplikat, ini menunjukkan bahwa log di-tail dari file log beberapa kali. Hal ini dapat terjadi jika ada rotasi log, atau saat file pos hilang atau rusak. Untuk mengurangi kemungkinan masalah ini, pastikan file posisi untuk input in_tail tidak dikonfigurasi agar berada di folder /var/log atau folder lain yang mungkin mengaktifkan rotasi log.

Pipeline logging juga mengandalkan kolom LogEntry.timestamp untuk menghapus duplikat log. Pastikan stempel waktu sebenarnya dari entri log diurai dengan benar. Jika Fluentd tidak disiapkan untuk menguraikan stempel waktu asli dari entri log, Fluentd akan menggunakan waktu saat memproses entri log. Jadi, jika input dibaca beberapa kali, meskipun stempel waktu di baris log sama, Fluentd dapat memperlakukannya sebagai entri log yang berbeda dengan stempel waktu yang berbeda.

Error Log audit berulang: Data points cannot be written more than 24h in the past

Ada masalah umum yang memengaruhi versi 1.8.5 hingga 1.9.3 (inklusif) yang menyebabkan log seperti berikut muncul berulang kali di log audit Akses Data, saat agen telah berjalan selama lebih dari 24 jam:

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

Solusinya adalah mengupgrade agen ke 1.9.4 atau yang lebih baru.

Karakter Unicode dalam log diganti dengan spasi atau '�'

Secara default, input in_tail mengharapkan file input dienkode ASCII, sehingga mengganti karakter non-ASCII dengan spasi. Untuk benar-benar menyerap file yang dienkode UTF-8, Anda harus memberikan dua opsi dalam konfigurasi in_tail:

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

Kedua opsi tersebut diperlukan. Jika hanya opsi encoding yang diberikan, karakter non-ASCII dalam log yang diserap akan diganti dengan '�'.

Agen yang dihapus dilaporkan oleh konsol Google Cloud sebagai terinstal

Setelah Anda meng-uninstal agen, konsol Google Cloud mungkin memerlukan waktu hingga satu jam untuk melaporkan perubahan ini.

Agen logging tidak muncul di daftar Uninstal program Windows

Untuk meng-uninstal agen Logging jika tidak tercantum dalam daftar Uninstall a program di Control Panel Windows, jalankan uninstall.exe dari direktori tempat Anda menginstalnya.