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

• Pastikan layanan agen berjalan pada instance VM Anda:

  • Untuk VM Windows, gunakan perintah PowerShell berikut:

    Get-Service -Name StackdriverLogging
    

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

  • Untuk VM Linux, gunakan perintah berikut:

    sudo service google-fluentd status
    

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

    sudo service google-fluentd restart
    

    Jika mulai ulang gagal, dan output log menampilkan "Disabled melalui metadata", Anda mungkin menjalankan image dari Google Cloud Marketplace, yang agen Logging dinonaktifkan secara default. Kunci metadata instance google-logging-enable mengontrol status pengaktifan agen Logging, dengan nilai 0 akan 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 log-nya di C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log.

    Tidak ada cara untuk mendapatkan log dari 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 akses atau otorisasi API, buka Memverifikasi kredensial Compute Engine.

• Jika agen tampaknya berjalan normal, tetapi Anda tidak mendapatkan data, Anda harus memeriksa apakah agen mengirim 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. Pada panel navigasi Google Cloud Console, pilih Logging, lalu pilih Logs Explorer:

   Buka Logs Explorer

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 konektor AWS yang menautkan akun AWS Anda ke layanan Google Cloud.

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

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

Jika Anda melihat entri log, "Berhasil mengirim gRPC to Logging API", berarti penginstalan agen selesai. Pesan ini dihasilkan satu kali ketika agen diinstal dan setiap agen dimulai ulang.

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

Menguji agen

Jika Anda menduga agen tidak berfungsi, pastikan agen sedang berjalan dan coba kirim pesan uji coba ke Logging:

Menemukan pesan pengujian Anda

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

1. Pada panel navigasi Google Cloud Console, pilih Logging, lalu pilih Logs Explorer:

   Buka Logs Explorer

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 konektor AWS yang menautkan akun AWS Anda ke layanan Google Cloud.

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

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

4. Anda akan melihat entri log dengan pesan pengujian. Jika ya, berarti 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, cakupan default dan setelan akun layanan sudah cukup untuk menjalankan agen. Instance yang sangat lama, atau instance yang setelan defaultnya telah Anda ubah, mungkin tidak memiliki kredensial yang sesuai.

Kegagalan memuat kredensial default

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

Log error akan 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 memperbaiki masalah ini, lihat Petunjuk penyiapan proxy untuk mengecualikan Server Metadata Compute Engine (metadata.google.internal, atau 169.254.169.254) agar tidak melewati proxy. Jika error tetap berlanjut, hapus akun layanan Compute Engine default dari VM, lalu tambahkan kembali.

Memverifikasi cakupan akses

Untuk memverifikasi cakupan akses, lakukan hal berikut:

1. Pada panel navigasi Konsol Google Cloud, pilih Compute Engine, lalu pilih VM instances:

   Buka instance VM

2. Klik nama instance VM Anda. Halaman detail 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", berarti cakupan akses Anda sudah memadai.
   2. Jika Anda melihat di sebelah Stackdriver Logging API, nama lama untuk Cloud Logging API, bahwa Anda memiliki izin Hanya Tulis atau Lengkap, berarti cakupan akses instance Anda sudah 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 sudah memadai untuk agen Cloud Monitoring.

Perbaiki masalah

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

Tabel berikut menunjukkan cakupan yang relevan dengan agen Logging dan 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. Pada panel navigasi Konsol Google Cloud, pilih Compute Engine, lalu pilih VM instances:

   Buka instance VM

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

3. Cari judul Akun layanan di halaman. Akun layanan default untuk instance akan dicantumkan. Tampilannya mungkin terlihat seperti berikut:

   [ID]-compute@developer.gserviceaccount.com
   

4. Pada panel navigasi Konsol Google Cloud, pilih IAM:

   Buka IAM

5. Pilih Lihat Menurut: Kepala Sekolah. Anda akan melihat daftar orang, grup, dan akun layanan. Di kolom Peran, terdapat 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. Editor adalah peran default yang ditetapkan ke akun layanan untuk Compute Engine.
   • Jika Anda melihat Logs Writer, peran tersebut sudah cukup untuk agen Logging. Untuk peran Logging lain yang menyertakan izin tulis, lihat Access Control for Cloud Logging.
   • Jika Anda melihat Monitoring Metric Writer, peran tersebut sudah cukup untuk Agen Monitoring. Untuk peran Monitoring lain yang menyertakan izin tulis, lihat Access Control for Cloud Monitoring.

Perbaiki 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 tepat untuk memberikan otorisasi kepada agen: Logging > Logs Writer atau Monitoring > Monitoring Metric Writer.

Memverifikasi kredensial kunci pribadi

Di instance VM Compute Engine, Anda dapat mengonfigurasi agen untuk menggunakan akun layanan non-default yang memiliki otorisasi yang tepat. Pada 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 diterapkan?
2. Apakah kunci pribadi masih valid untuk akun layanan?
3. Apakah akun layanan memiliki peran yang diperlukan untuk agen?

Untuk memastikan 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 sudah valid.

Apakah kredensial ada?

Untuk melihat apakah kredensial akun layanan kunci pribadi ada di instance Anda, jalankan perintah Linux berikut pada 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 ini, instance Anda mungkin memiliki kredensial kunci pribadi yang valid. Jika kedua perintah menampilkan file, 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 di 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 dalam shell login, tetapi tidak menetapkan variabel tersebut dalam konfigurasi layanan agen, layanan akan terlihat 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 tersebut, dan private_key_id mengidentifikasi kunci pribadi dalam akun layanan tersebut. Cocokkan informasi ini dengan yang ditampilkan di bagian IAM & Admin > Service accounts pada Google Cloud Console.

File kredensial tidak valid jika salah satu kondisi berikut terpenuhi:

• Anda memeriksa instance Compute Engine, tetapi project Google Cloud yang ada dalam file kredensial bukan project yang berisi instance Anda.
• Anda sedang memeriksa instance Amazon EC2, tetapi project Google Cloud yang ada dalam file kredensial bukan project konektor (bernama AWS Link...) untuk akun AWS Anda.
• Akun layanan yang tercantum tidak ada. Mungkin saja sudah 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. Klaim tersebut dapat dicabut.

Kredensial dapat dicabut menggunakan bagian IAM & Admin > Akun layanan di Google Cloud Console. Jika tidak ada kredensial yang valid, lihat Menambahkan kredensial untuk mengganti kredensial yang ada atau menambahkan yang 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 Anda saat ini untuk memastikan log yang Anda cari tidak dikecualikan secara tidak sengaja.

Verifikasi 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

Penyelesaian perintah ini dapat memerlukan waktu beberapa saat 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:

• Jika yakin bahwa masalahnya tidak terkait dengan kredensial, Anda dapat langsung melanjutkan ke bagian Menginstal di Linux dan Windows.

• Untuk mengetahui cara menginstal agen secara lengkap dan kredensial yang diperlukan, lihat Menginstal agen Logging.

Masalah umum lainnya

Tabel berikut berisi beberapa masalah umum yang mungkin Anda temui dengan agen Cloud Logging dan memberitahukan 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 versi v1-9). Class error Google::APIClient::ClientError menunjukkan adanya masalah dengan izin atau akses API.

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

Batasan throughput log

Throughput log maksimum yang dapat diproses agen Logging dibatasi oleh CPU. Penggunaan CPU cenderung meningkat ketika throughput log tumbuh. Namun, agen, dengan konfigurasi default, hanya dapat menggunakan hingga satu core CPU. Jadi, ketika throughput log melonjak, agen mungkin mencapai batas penggunaan CPU. Jika lonjakan ini hanya bersifat sementara, agen Logging akan mem-buffer log, lalu segera mengejarnya untuk memprosesnya. Jika throughput log tetap tinggi, log mungkin melewati buffer dan pada akhirnya akan hilang.

Biasanya, jika setiap entri log adalah teks mentah 1.000 byte dan tidak berisi pemrosesan format tambahan, agen Logging akan mencapai batas satu CPU inti 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 Agen Operasional. Di Linux, untuk entri log yang berupa teks mentah 1.000 byte dan tidak memerlukan pemrosesan tambahan, Agen Operasional dapat memproses sekitar 160.000 entri log per detik.

Melebihi ukuran log maksimum

Jika satu atau beberapa entri log melampaui batas ukuran maksimum, Anda mungkin akan menemukan entri dalam log fluentd seperti 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, potong 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 di pipeline pemrosesan dalam agen. Jika insertID berbeda di antara log duplikat, hal ini menunjukkan bahwa log di-tail dari file log beberapa kali. Hal ini dapat terjadi jika ada rotasi log, atau jika file pos hilang atau rusak. Untuk mengurangi kemungkinan terjadinya masalah ini, pastikan file posisi untuk input in_tail tidak dikonfigurasi untuk 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 yang sebenarnya dari entri log diurai 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 di baris log sama, Fluentd dapat memperlakukannya sebagai entri log 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 versi 1.9.4 atau yang lebih baru.

Karakter unicode dalam log diganti dengan spasi atau ' '

Secara default, input in_tail mengharapkan file input dienkode dengan ASCII, sehingga karakter non-ASCII diganti dengan spasi. Untuk menyerap file yang berenkode UTF-8, Anda harus menyediakan 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 disediakan, karakter non-ASCII dalam log yang diserap akan diganti dengan ' '.

Agen yang dihapus dilaporkan oleh konsol Google Cloud saat diinstal

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

Agen {i>logging<i} tidak muncul di daftar Windows {i>Uninstall a program<i}

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.