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 menggunakan awalan sudo pada perintah penginstalan.

  • Pastikan layanan agen berjalan di instance VM Anda:

    • Untuk VM Windows, gunakan perintah PowerShell berikut:

      Get-Service -Name StackdriverLogging

      Cari layanan bernama Stackdriver Logging. Jika agen tidak berjalan, Anda mungkin perlu memulainya ulang.

    • Untuk VM Linux, gunakan perintah berikut:

      sudo service google-fluentd status

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

      sudo service google-fluentd restart

      Jika memulai ulang gagal, dan output log menampilkan "Disabled via metadata", Anda kemungkinan menjalankan image dari Google Cloud Marketplace, tempat agen Logging dinonaktifkan secara default. Kunci metadata instance google-logging-enable mengontrol status pengaktifan agen Logging, dengan nilai 0 menonaktifkan agen. Untuk mengaktifkan kembali agen, hapus tombol 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.

  • Periksa 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 melihat error HTTP 429, Anda mungkin telah melampaui kuota Logging API. Anda dapat melihat kuota yang tersedia dengan memilih APIs & services > Dashboard di konsol Google Cloud . Pilih Logging API.

      • Jika Anda melihat masalah otorisasi atau akses 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 melakukan 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 Google Cloud project yang berisi instance VM.

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

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

Jika Anda melihat entri log, "Successfully sent gRPC to Logging API", berarti 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 menduga bahwa agen tidak berfungsi, periksa apakah agen sedang berjalan dan coba kirim pesan pengujian ke Logging:

Instance Linux

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

    ps ax | grep fluentd

    Anda akan melihat output yang mirip dengan yang berikut:

     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 pada instance VM menggunakan PowerShell:

  1. Tanyakan status kedua layanan. Jika Anda tahu layanan mana 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 Anda mengkueri kedua layanan, 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 Anda 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 Anda

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 Google Cloud project yang berisi instance VM.

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

    • Untuk Compute Engine, pilih GCE VM 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.

Verifikasi 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 cukup 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 menunjukkan 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, lihat petunjuk penyiapan Proxy untuk mengecualikan Server Metadata Compute Engine (metadata.google.internal, atau 169.254.169.254) agar tidak melalui proxy. Jika error berlanjut, hapus akun layanan Compute Engine default dari VM dan tambahkan kembali.

Memverifikasi cakupan akses

Untuk memverifikasi cakupan akses, lakukan hal berikut:

  1. Di konsol Google Cloud , buka halaman VM instances:

    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 Cloud API access scopes, klik Details untuk melihat daftar API. Cari entri berikut:

    1. Jika Anda melihat "Instance ini memiliki akses API penuh ke semua Layanan Google Cloud", berarti 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, maka 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 Write Only atau Full, maka 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 Monitoring:

Cakupan akses Izin agen
https://www.googleapis.com/auth/logging.write Memadai untuk agen Logging
https://www.googleapis.com/auth/monitoring.write Memadai 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, mulai dengan menemukan akun layanan default:

  1. Di konsol Google Cloud , buka halaman VM instances:

    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 heading Service account di halaman. Akun layanan default untuk instance tersebut akan dicantumkan. Tampilannya mungkin seperti berikut:

    [ID]-compute@developer.gserviceaccount.com

  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 Berdasarkan: Pemilik. Anda akan melihat daftar orang, grup, dan akun layanan. Di kolom Peran terdapat peran yang dimiliki setiap prinsipal 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 Penulis Log, peran tersebut sudah cukup untuk agen Logging. Untuk peran Logging lainnya yang mencakup izin tulis, lihat Kontrol Akses untuk Cloud Logging.
    • Jika Anda melihat Monitoring Metric Writer, peran tersebut sudah cukup untuk Agen Monitoring. Untuk peran Monitoring lainnya yang mencakup izin penulisan, 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.

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 pada instance VM Anda, verifikasi terlebih dahulu bahwa file kredensial ada di lokasi yang diharapkan, lalu verifikasi bahwa informasi dalam file kredensial valid.

Apakah kredensial ada?

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 ditunjukkan di bawah, berarti instance Anda mungkin memiliki kredensial kunci pribadi yang valid. Jika kedua perintah menampilkan file, maka file yang ditunjukkan oleh 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]@developer.gserviceaccount.com",
  "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 dari 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 Anda, 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 dalam akun layanan. Cocokkan informasi ini dengan yang ditampilkan di bagian IAM & Admin > Service accounts di konsolGoogle Cloud .

File kredensial tidak valid jika salah satu hal berikut terpenuhi:

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

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

Jika akun layanan sudah benar, tetapi kunci pribadinya telah dicabut, Anda dapat membuat kunci pribadi baru dan menyalinnya ke instance Anda. 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 di instance Anda:

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

Perintah 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 terkait 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 (dimulai dari versi v1-9). Class error Google::APIClient::ClientError menunjukkan bahwa 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
Penginstal 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 Anda. 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. 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 memiliki izin yang tidak memadai. Akun tersebut mungkin merupakan akun layanan default yang digunakan dalam Compute Engine atau App Engine, atau mungkin merupakan akun layanan yang ditentukan pengguna yang digunakan untuk otorisasi kunci pribadi. Akun 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 prosedur.
Tidak dapat memperoleh project ID Agen Cloud Logging gagal mendapatkan ID project dari file kredensial kunci pribadi akun layanan. Untuk menambahkan atau mengganti ID project 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 Mengizinkan agen Logging untuk memperbaiki atau mengganti kredensial.
Agen Logging Jendela berhenti menyerap log peristiwa dari beberapa channel Agen Logging mungkin gagal secara diam-diam dalam menyerap log peristiwa dari saluran tertentu, meskipun agen tersebut 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 menyelesaikan masalah ini. Catatan: Format data plugin windows_eventlog2 tidak kompatibel dengan versi lama plugin windows_eventlog. Jika ada pipeline ekspor BigQuery atau Google Cloud Storage yang disiapkan untuk log ini, pipeline tersebut harus disesuaikan dengan tepat. 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 serupa dengan file konfigurasi contoh ini. Terakhir, mulai agen Logging.
Agen logging berhenti menyerap log jika ada logrotate Agen Logging dapat kehilangan jejak posisinya dalam file input saat logrotate disiapkan dengan setelan copytruncate. Sebaiknya gunakan setelan nocopytruncate untuk memastikan bahwa logrotate memindahkan file, bukan memangkasnya. Jika Anda ingin mempertahankan setelan copytruncate, solusinya adalah 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 sedang berjalan (hanya boleh ada dua: satu supervisor dan satu pekerja), dan sudo netstat -nltp | grep :24231 untuk menampilkan proses yang sedang berjalan yang menggunakan port. Hentikan instance lama sesuai kebutuhan.
Agen logging gagal dimulai karena error dari lib/fluent/config/types.rb Konfigurasi agen Logging menggunakan bagian parser regex yang memiliki regex yang salah format, sehingga menghasilkan 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 regex yang salah format di 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 hingga satu core CPU. Jadi, saat throughput log melonjak, agen mungkin mencapai batas penggunaan CPU. Jika lonjakan ini hanya bersifat sementara, agen Logging akan mem-buffer log dan kemudian memprosesnya. Jika throughput log terus-menerus tetap tinggi, log dapat meluap dari 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 CPU satu core pada sekitar 5.500 entri log per detik. Jika entri log memerlukan pemrosesan lanjutan, misalnya parsing JSON atau Regex, entri log maksimum per detik mungkin lebih rendah.

Jika Anda 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 melibatkan pemrosesan tambahan, Agen Operasi 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 di 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 agar tidak melebihi batas ukuran maksimum. Misalnya, contoh kode 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 di pipeline pemrosesan dalam agen. Jika insertID berbeda di antara log duplikat, hal ini menunjukkan bahwa log tersebut dibaca 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 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 di-parsing dengan benar. Jika Fluentd tidak disiapkan untuk mengurai stempel waktu asli dari entri log, Fluentd akan menggunakan waktu saat memproses entri log. Jadi, jika input dibaca beberapa kali, meskipun stempel waktu dalam 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 Anda 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 file tersebut 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 diperlukan. Jika hanya opsi encoding yang diberikan, karakter non-ASCII dalam log yang di-ingest akan diganti dengan '�'.

Agen yang dihapus dilaporkan oleh konsol Google Cloud sebagai terinstal

Setelah Anda meng-uninstal agen, Google Cloud konsol 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 Panel Kontrol Windows, jalankan uninstall.exe dari direktori tempat Anda menginstalnya.