Memecahkan masalah penyerapan data Agen Operasional

Dokumen ini memberikan informasi untuk membantu Anda mendiagnosis dan menyelesaikan masalah penyerapan data, untuk log dan metrik, di Agen Operasi yang sedang berjalan. Jika Agen Operasi tidak berjalan, lihat Memecahkan masalah penginstalan dan pengaktifan.

Sebelum memulai

Sebelum mencoba memperbaiki masalah, periksa status pemeriksaan kondisi agen.

KonsolGoogle Cloud menampilkan penginstalan Agen Operasional yang macet di 'Tertunda'

Meskipun setelah berhasil menginstal Agen Operasional, konsol Google Cloud mungkin masih menampilkan status 'Tertunda'. Gunakan gcpdiag untuk mengonfirmasi penginstalan Agen Operasional dan untuk memverifikasi bahwa agen mengirimkan log dan metrik dari instance VM Anda.

Alasan umum kegagalan penginstalan

Penginstalan Agen Operasional mungkin gagal karena alasan berikut:

• VM tidak memiliki akun layanan terlampir. Sertakan akun layanan ke VM, lalu instal ulang Agen Operasional.

• VM sudah menginstal salah satu agen lama, yang mencegah penginstalan Agen Operasional. Uninstal agen lama, lalu instal ulang Agen Operasional.

Alasan umum kegagalan transmisi telemetri

Agen Operasional yang diinstal dan berjalan dapat gagal mengirim log, metrik, atau keduanya dari VM karena alasan berikut:

• Akun layanan yang terpasang ke VM tidak memiliki peran roles/logging.logWriter atau roles/monitoring.metricWriter.
• Cakupan akses logging atau pemantauan tidak diaktifkan. Untuk mengetahui informasi tentang cara memeriksa dan memperbarui cakupan akses, lihat Memverifikasi cakupan akses Anda.
• Logging API atau Monitoring API tidak diaktifkan.

Gunakan pemeriksaan kondisi agen untuk mengidentifikasi penyebab utama dan solusi yang sesuai.

Agen berjalan, tetapi data tidak di-ingest

Gunakan Metrics Explorer untuk membuat kueri metrik uptime agen, dan verifikasi bahwa komponen agen, google-cloud-ops-agent-metrics atau google-cloud-ops-agent-logging, sedang menulis ke metrik.

1. Di konsol Google Cloud , buka halaman leaderboard Metrics explorer:

   Buka Metrics explorer

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

2. Pada tombol berlabel Kode Builder, pilih Kode, lalu tetapkan bahasa ke PromQL.

3. Masukkan kueri berikut, lalu klik Run:

   rate({"agent.googleapis.com/agent/uptime", monitored_resource="gce_instance"}[1m])
   

Apakah agen mengirim log ke Cloud Logging?

Jika agen berjalan tetapi tidak mengirim log, periksa status health check runtime agen.

Error pipeline

Jika Anda melihat error runtime LogPipelineErr ("Pipeline logging Ops Agent gagal"), berarti subagen Logging mengalami masalah saat menulis log. Periksa kondisi berikut:

• Pastikan file penyimpanan subagen Logging dapat diakses. File ini ditemukan di lokasi berikut:
  • Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
  • Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
• Pastikan disk VM tidak penuh.
• Pastikan konfigurasi logging sudah benar.

Langkah-langkah ini mengharuskan Anda menggunakan SSH untuk terhubung ke VM.

Jika Anda mengubah konfigurasi logging, atau jika file buffer dapat diakses dan disk VM tidak penuh, mulai ulang Agen Operasi:

Error penguraian log

Jika Anda melihat error runtime LogParseErr ("Ops Agent failed to parse logs"), kemungkinan besar masalahnya ada pada konfigurasi pemroses logging. Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:

• Pastikan konfigurasi parse_json prosesor sudah benar.
• Pastikan konfigurasi parse_regex prosesor sudah benar.
• Jika Anda tidak memiliki pemroses parse_json atau parse_regex, periksa konfigurasi pemroses pencatatan log lainnya.

Langkah-langkah ini mengharuskan Anda menggunakan SSH untuk terhubung ke VM.

Jika Anda mengubah konfigurasi logging, mulai ulang Agen Operasional:

Periksa metrik lokal

Langkah-langkah ini mengharuskan Anda menggunakan SSH untuk terhubung ke VM.

• Apakah modul logging berjalan? Gunakan perintah berikut untuk memeriksa:

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

Buka Windows PowerShell sebagai administrator dan jalankan:

Get-Service google-cloud-ops-agent

Anda juga dapat memeriksa status layanan di aplikasi Layanan dan memeriksa proses yang sedang berjalan di aplikasi Pengelola Tugas.

Periksa log modul logging

Langkah ini mengharuskan Anda menggunakan SSH untuk terhubung ke VM.

Anda dapat menemukan log modul logging di /var/log/google-cloud-ops-agent/subagents/*.log untuk Linux dan C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log untuk Windows. Jika tidak ada log, berarti layanan agen tidak berjalan dengan benar. Buka bagian Agen diinstal, tetapi tidak berjalan terlebih dahulu untuk memperbaiki kondisi tersebut.

• Anda mungkin melihat error izin 403 saat menulis ke Logging API. Contoh:

  [2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
  {
  "error": {
    "code": 403,
    "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google developers console API activation",
            "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
          }
        ]
      }
    ]
  }
  }
  

  Untuk memperbaiki error ini, aktifkan Logging API dan tetapkan peran Logs Writer.

• Anda mungkin melihat masalah kuota untuk Logging API. Contoh:

  error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"
  

  Untuk memperbaiki error ini, tingkatkan kuota atau kurangi throughput log.

• Anda mungkin melihat error berikut di log modul:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  atau

  can't fetch token from the metadata server
  

  Error ini mungkin menunjukkan bahwa Anda men-deploy agen tanpa akun layanan atau kredensial yang ditentukan. Untuk mengetahui informasi tentang cara mengatasi masalah ini, lihat Memberikan otorisasi Agen Operasional.

Apakah agen mengirim metrik ke Cloud Monitoring?

Periksa log modul metrik

Langkah ini mengharuskan Anda menggunakan SSH untuk terhubung ke VM.

Anda dapat menemukan log modul metrik di syslog. Jika tidak ada log, hal ini menunjukkan bahwa layanan agen tidak berjalan dengan benar. Buka bagian Agen telah diinstal, tetapi tidak berjalan terlebih dahulu untuk memperbaiki kondisi tersebut.

• Anda mungkin melihat error PermissionDenied saat menulis ke Monitoring API. Error ini terjadi jika izin untuk Ops Agent tidak dikonfigurasi dengan benar. Contoh:

  Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}
  

  Untuk memperbaiki error ini, aktifkan Monitoring API dan tetapkan peran Monitoring Metric Writer.

• Anda mungkin melihat error ResourceExhausted saat menulis ke Monitoring API. Error ini terjadi jika project mencapai batas kuota Monitoring API. Contoh:

  Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}
  

  Untuk memperbaiki error ini, tingkatkan kuota atau kurangi throughput metrik.

• Anda mungkin melihat error berikut di log modul:

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  atau

  can't fetch token from the metadata server
  

  Error ini mungkin menunjukkan bahwa Anda men-deploy agen tanpa akun layanan atau kredensial yang ditentukan. Untuk mengetahui informasi tentang cara mengatasi masalah ini, lihat Memberikan otorisasi Agen Operasional.

Masalah konektivitas jaringan

Jika agen berjalan tetapi tidak mengirim log maupun metrik, Anda mungkin mengalami masalah jaringan. Jenis masalah konektivitas jaringan yang mungkin Anda alami bervariasi dengan topologi aplikasi Anda. Untuk mengetahui ringkasan jaringan Compute Engine, lihat Ringkasan jaringan untuk VM.

Penyebab umum masalah konektivitas meliputi hal-hal berikut:

• Aturan firewall yang mengganggu traffic masuk. Untuk mengetahui informasi tentang aturan firewall, lihat Menggunakan aturan firewall VPC.
• Masalah dalam konfigurasi proxy HTTP.
• Konfigurasi DNS.

Ops Agent menjalankan health check yang mendeteksi error konektivitas jaringan. Lihat dokumentasi health check untuk mengetahui tindakan yang disarankan untuk mengatasi error konektivitas.

Memahami pesan error "gagal menghapus chunk"

Mulai dari Agen Operasional versi 2.28.0, Agen Operasional membatasi jumlah ruang disk yang dapat digunakannya untuk menyimpan potongan buffer. Agen Operasional membuat potongan buffer saat data logging tidak dapat dikirim ke Cloud Logging API. Tanpa batas, potongan ini dapat menggunakan semua ruang yang tersedia, sehingga mengganggu layanan lain di VM. Saat gangguan jaringan menyebabkan potongan buffer ditulis ke disk, Agen Operasi menggunakan jumlah ruang disk khusus platform untuk menyimpan potongan. Pesan seperti contoh berikut juga muncul di /var/log/google-cloud-ops-agent/subagents/logging-module.log pada VM Linux atau C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log pada VM Windows saat VM tidak dapat mengirimkan potongan buffer ke Cloud Logging API:

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

Masalah di proxy HTTP

Masalah pada konfigurasi proxy HTTP dapat menyebabkan error. Misalnya, error dari flb_upstream dengan istilah context menunjukkan masalah pada konfigurasi proxy:

[2024/03/25 12:21:51] [error] [C:\work\submodules\fluent-bit\src\flb_upstream.c:281 errno=2] No such file or directory
[2024/03/25 12:21:51] [error] [upstream] error creating context from URL: https://oauth2.googleapis.com/token
[2024/03/25 12:21:51] [error] [oauth2] error creating upstream context

Untuk memperbaiki masalah ini, pastikan proxy HTTP telah dikonfigurasi dengan benar. Untuk mengetahui petunjuk cara menyiapkan proxy HTTP, lihat Mengonfigurasi proxy HTTP.

Untuk spesifikasi format proxy HTTP, lihat manual resmi Fluent Bit.

Saya hanya ingin mengumpulkan metrik atau log, bukan keduanya

Secara default, Agen Operasional mengumpulkan metrik dan log. Untuk menonaktifkan pengumpulan metrik atau log, gunakan file config.yaml Ops Agent untuk mengganti layanan logging atau metrics default sehingga pipeline default tidak memiliki penerima. Untuk informasi selengkapnya, lihat referensi berikut:

• Contoh konfigurasi service logging.
• Contoh konfigurasi service metrik.

Menghentikan penyerapan data dengan menonaktifkan layanan sub-agen Ops Agent "Logging Agent" atau "Monitoring Agent" akan menghasilkan konfigurasi yang tidak valid dan tidak didukung.

Metrik sedang dikumpulkan, tetapi ada yang tidak beres

Agen mencatat "Ekspor gagal. Akan dicoba lagi"

Anda melihat entri log "Ekspor gagal" saat titik data pertama dari metrik kumulatif dihilangkan. Log berikut tidak berbahaya dan dapat diabaikan dengan aman:

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}
  

Agen mencatat pesan "TimeSeries could not be written: Points must be written in order" (TimeSeries tidak dapat ditulis: Titik harus ditulis secara berurutan).

Jika Anda telah mengupgrade ke Ops Agent dari agen Monitoring lama dan melihat pesan error berikut saat menulis metrik kumulatif, solusinya adalah me-reboot VM Anda. Ops Agent dan agen Monitoring menghitung waktu mulai untuk metrik kumulatif secara berbeda, yang dapat menyebabkan titik-titik muncul tidak berurutan. Memulai ulang VM akan mereset waktu mulai dan memperbaiki masalah ini.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}
  

Agen mencatat pesan "Token harus berupa token berumur pendek (60 menit) dan dalam jangka waktu yang wajar"

Jika Anda melihat pesan error berikut saat agen menulis metrik, hal ini menunjukkan bahwa clock sistem tidak disinkronkan dengan benar:

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.
  

Untuk mengetahui informasi tentang cara menyinkronkan clock sistem, lihat Mengonfigurasi NTP di VM.

Agen mencatat 'penerima metrik dengan jenis "nvml" tidak didukung'

Jika Anda mengumpulkan metrik GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) menggunakan penerima nvml, maka Anda telah menggunakan Agen Operasional versi dengan dukungan pratinjau untuk metrik NVML. Dukungan untuk metrik ini tersedia secara umum di Ops Agent versi 2.38.0. Pada versi GA, pengumpulan metrik yang dilakukan oleh penerima nvml digabungkan ke penerima hostmetrics, dan penerima nvml dihapus.

Anda melihat pesan error 'penerima metrik dengan jenis "nvml" tidak didukung' setelah menginstal Ops Agent versi 2.38.0 atau yang lebih baru saat Anda menggunakan penerima nvml pratinjau dan mengganti interval pengumpulan default dalam file konfigurasi yang ditentukan pengguna. Error terjadi karena penerima nvml tidak ada lagi, tetapi file konfigurasi yang ditentukan pengguna masih merujuk ke penerima tersebut.

Untuk memperbaiki masalah ini, perbarui file konfigurasi yang ditentukan pengguna untuk mengganti interval pengumpulan di penerima hostmetrics.

Metrik GPU tidak ada

Jika Agen Operasional mengumpulkan beberapa metrik, tetapi beberapa atau semua metrik GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) tidak ada, Anda mungkin mengalami masalah konfigurasi atau tidak ada proses yang menggunakan GPU.

Jika Anda tidak mengumpulkan metrik GPU apa pun, periksa driver GPU. Untuk mengumpulkan metrik GPU, Agen Operasional memerlukan driver GPU untuk diinstal dan dikonfigurasi di VM. Untuk memeriksa driver, lakukan hal berikut:

1. Untuk memverifikasi bahwa driver telah diinstal dan berjalan dengan benar, ikuti langkah-langkah untuk memverifikasi penginstalan driver GPU.

2. Jika driver tidak diinstal, lakukan hal berikut:

   1. Instal driver GPU.

   2. Mulai ulang Agen Operasional.

      Anda harus memulai ulang Agen Operasional setelah menginstal atau mengupgrade driver GPU.

   3. Periksa log Ops Agent untuk memverifikasi bahwa komunikasi telah berhasil dimulai. Pesan log menyerupai berikut ini:

      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
      Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.
      

Jika driver GPU telah diinstal dan log Agen Operasional menunjukkan bahwa Agen Operasional berkomunikasi dengan driver, tetapi Anda tidak melihat metrik GPU apa pun, masalahnya mungkin terkait dengan diagram yang Anda gunakan. Untuk informasi tentang pemecahan masalah diagram, lihat Diagram tidak menampilkan data apa pun.

Jika Anda mengumpulkan beberapa metrik GPU, tetapi tidak ada metrik processes —processes/max_bytes_used dan processes/utilization—maka tidak ada proses yang berjalan di GPU. Metrik GPU processes tidak dikumpulkan jika tidak ada proses yang berjalan di GPU.

Beberapa metrik tidak ada atau tidak konsisten

Ada sejumlah kecil metrik yang ditangani secara berbeda oleh Ops Agent versi 2.0.0 dan yang lebih baru dibandingkan dengan versi "pratinjau" Ops Agent (versi kurang dari 2.0.0) atau agen Monitoring.

Masalah khusus Windows

Bagian berikut hanya berlaku untuk Agen Operasi yang berjalan di Windows.

Penghitung performa yang rusak di Windows

Jika sub-agen metrik gagal dimulai, Anda mungkin melihat salah satu error berikut di Cloud Logging:

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

Error ini dapat terjadi jika penghitung performa sistem Anda rusak. Anda dapat menyelesaikan error dengan membangun kembali penghitung performa. Di PowerShell sebagai administrator, jalankan:

cd C:\Windows\system32
lodctr /R

Perintah sebelumnya terkadang dapat gagal; jika demikian, muat ulang PowerShell dan coba lagi hingga berhasil.

Setelah perintah berhasil, mulai ulang Agen Operasional:

Restart-Service -Name google-cloud-ops-agent -Force

Mereset status agen sepenuhnya

Jika agen memasuki status yang tidak dapat dipulihkan, ikuti langkah-langkah berikut untuk memulihkan agen ke status awal.

Linux

Hentikan layanan agen:

sudo service google-cloud-ops-agent stop

Hapus paket agen:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

Hapus log mandiri agen di disk:

sudo rm -rf /var/log/google-cloud-ops-agent

Hapus buffer lokal agen di disk:

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

Instal ulang dan mulai ulang agen:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

Hentikan layanan agen:

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

Hapus paket agen:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

Hapus log mandiri agen di disk:

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

Hapus buffer lokal agen di disk:

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

Instal ulang dan mulai ulang agen:

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

Mereset, tetapi menyimpan file buffer

Jika VM tidak memiliki chunk buffer yang rusak (yaitu, tidak ada pesan format check failed dalam file log mandiri Ops Agent), Anda dapat melewati perintah sebelumnya yang menghapus buffer lokal saat mereset status agen.

Jika VM memiliki potongan buffer yang rusak, Anda harus menghapusnya. Opsi berikut menjelaskan berbagai cara untuk menangani buffer. Langkah-langkah lain yang dijelaskan dalam Mereset status agen sepenuhnya masih berlaku.

• Opsi 1: Hapus seluruh direktori buffers. Ini adalah opsi yang paling mudah, tetapi dapat menyebabkan hilangnya log yang di-buffer yang tidak rusak atau duplikasi log karena hilangnya file posisi.

  Linux

  sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
  

  Windows

  rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
  

• Opsi 2: Hapus subdirektori buffer dari direktori buffers, tetapi biarkan file posisi. Pendekatan ini dijelaskan dalam Mereset status agen sepenuhnya.

• Opsi 3: Jika Anda tidak ingin menghapus semua file buffer, Anda dapat mengekstrak nama file buffer yang rusak dari log mandiri agen dan menghapus hanya file buffer yang rusak.

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  

• Opsi 4: Jika ada banyak buffer yang rusak dan Anda ingin memproses ulang semua file log, Anda dapat menggunakan perintah dari Opsi 3 dan juga menghapus file posisi (yang menyimpan progres Ops Agent per file log). Menghapus file posisi dapat menyebabkan duplikasi log untuk log apa pun yang sudah berhasil diproses. Opsi ini hanya memproses ulang file log saat ini; opsi ini tidak memproses ulang file yang sudah dirotasi atau log dari sumber lain seperti port TCP. File posisi disimpan di direktori buffers, tetapi disimpan sebagai file. Buffer lokal disimpan sebagai subdirektori di direktori buffers,

  Linux

  grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
  sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete
  

  Windows

  $oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
  if (Test-Path $oalogspath) {
    Select-String "format check failed" $oalogspath |
    %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
    %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
  };
  Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}
  

Masalah umum dalam rilis Agen Operasional terbaru

Bagian berikut menjelaskan masalah yang diketahui dalam rilis Ops Agent terbaru.

Agen Operasional versi 2.56.0 gagal mengirim metrik Prometheus

Jika Anda menggunakan Agen Operasional versi 2.56.0 bersama dengan penerima Prometheus dan jika target pengambilan data Anda memancarkan metrik dengan metrik *_created tambahan untuk penghitung (untuk mendukung fitur Stempel Waktu Pembuatan eksperimental baru), maka agen mungkin gagal menulis metrik dan melaporkan error bahwa waktu mulai harus positif. Pesan log menyerupai berikut ini:

Field points[0].interval.start_time had an invalid value of \"1781-05-03T21:46:07.592596-07:52\": The start time must be positive.;

Ini adalah masalah pada OpenTelemetry upstream. Untuk mengatasi error hingga dapat diperbaiki dalam rilis Ops Agent baru, gunakan versi 2.55.0, yang tidak terpengaruh. Jika menggunakan Kebijakan Agen, Anda juga dapat menyematkan versi ke 2.55.0 untuk mencegah upgrade. Untuk mengetahui informasi selengkapnya, lihat Menginstal agen versi tertentu.

Ops Agent versi 2.47.0, 2.48.0, atau 2.49.0 mengalami loop error

Versi 2.47.0, 2.48.0, dan 2.49.0 menyertakan komponen FluentBit yang rusak untuk pencatatan log. Komponen ini gagal pada baris log tertentu dan menyebabkan Ops Agent mengalami loop error.

Masalah ini telah diselesaikan di Agen Operasional versi 2.50.0.

Namespace metrik Prometheus mencakup nama instance selain ID instance mulai dari Ops Agent versi 2.46.0

Mulai dari versi 2.46.0, Agen Operasional menyertakan nama VM sebagai bagian dari label namespace saat memproses metrik dalam format pemrosesan Prometheus. Pada versi sebelumnya, metrik Prometheus hanya menggunakan ID instance VM sebagai bagian dari label namespace, tetapi mulai dari versi 2.46.0, namespace ditetapkan ke INSTANCE_ID/INSTANCE_NAME.

Jika Anda memiliki diagram, dasbor, atau kebijakan pemberitahuan yang menggunakan label namespace, Anda mungkin harus memperbarui kueri setelah mengupgrade Agen Operasional ke versi 2.46.0 atau yang lebih baru. Misalnya, jika kueri PromQL Anda terlihat seperti: http_requests_total{namespace="123456789"}, Anda harus mengubahnya menjadi http_requests_total{namespace=~"123456789.*"}, karena label namespace memiliki format INSTANCE_ID/INSTANCE_NAME.

Metrik tidak bertipe Prometheus mengubah jenis metrik mulai dari Agen Operasional versi 2.39.0

Mulai dari versi 2.39.0, Agen Operasional mendukung penyerapan metrik Prometheus dengan jenis yang tidak diketahui. Pada versi sebelumnya, metrik ini diperlakukan oleh Ops Agent sebagai pengukur, tetapi mulai versi 2.39.0, metrik yang tidak diketik diperlakukan sebagai pengukur dan penghitung. Pengguna kini dapat menggunakan operasi kumulatif pada metrik ini sebagai hasilnya.

Jika Anda menggunakan PromQL, Anda dapat menerapkan operasi kumulatif ke metrik Prometheus yang tidak memiliki jenis setelah mengupgrade Agen Operasional ke versi 2.39.0 atau yang lebih baru.

Penggunaan memori tinggi pada VM Windows (versi 2.27.0 hingga 2.29.0)

Di Windows dalam Agen Operasional versi 2.27.0 hingga 2.29.0, bug yang menyebabkan agen terkadang mengalami kebocoran soket menyebabkan peningkatan penggunaan memori dan tingginya jumlah handle yang dipegang oleh proses fluent-bit.exe.

Untuk memitigasi masalah ini, upgrade Agen Operasional ke versi 2.30.0 atau yang lebih baru, dan mulai ulang agen.

Zona waktu Log Peristiwa salah di Windows (versi 2.15.0 hingga 2.26.0)

Stempel waktu yang terkait dengan Log Peristiwa Windows di Cloud Logging mungkin salah jika Anda mengubah zona waktu VM dari UTC. Masalah ini telah diperbaiki di Ops Agent 2.27.0, tetapi karena masalah memori tinggi Windows yang diketahui, sebaiknya upgrade ke Ops Agent 2.30.0 atau yang lebih baru jika Anda mengalami masalah ini. Jika tidak dapat melakukan upgrade, Anda dapat mencoba salah satu solusi berikut.

Gunakan zona waktu UTC

Di PowerShell, jalankan perintah berikut sebagai administrator:

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Mengganti setelan zona waktu hanya untuk layanan sub-agen logging

Di PowerShell, jalankan perintah berikut sebagai administrator:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Stempel waktu yang diuraikan di Windows memiliki zona waktu yang salah (versi apa pun sebelum 2.27.0)

Jika Anda menggunakan pemroses log yang mengurai stempel waktu, nilai zona waktu tidak akan diurai dengan benar di Windows. Masalah ini telah diperbaiki di Ops Agent 2.27.0, tetapi karena masalah penggunaan memori tinggi di Windows yang diketahui, sebaiknya upgrade ke setidaknya Ops Agent 2.30.0 jika Anda mengalami masalah ini.

Masalah umum dalam rilis Agen Operasional yang lebih lama

Bagian berikut menjelaskan masalah yang diketahui terjadi pada rilis Ops Agent yang lebih lama.

Log tidak berbahaya (versi 2.9.1 dan yang lebih lama)

Anda mungkin melihat error saat meng-scraping metrik dari proses semu atau proses yang dibatasi. Log berikut tidak berbahaya dan dapat diabaikan dengan aman. Untuk menghilangkan pesan ini, upgrade Agen Operasional ke versi 2.10.0 atau yang lebih baru.

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186
  

Log mandiri agen menggunakan terlalu banyak CPU, memori, dan ruang disk (versi 2.16.0 dan yang lebih lama)

Versi Agen Operasional sebelum 2.17.0 dapat menggunakan banyak CPU, memori, dan ruang disk dengan file /var/log/google-cloud-ops-agent/subagents/logging-module.log di VM Linux atau file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log di VM Windows karena chunk buffer yang rusak. Jika hal ini terjadi, Anda akan melihat sejumlah besar pesan seperti berikut di file logging-module.log.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb
  

Untuk mengatasi masalah ini, upgrade Ops Agent ke versi 2.17.0 atau yang lebih baru, dan Reset status agen sepenuhnya.

Jika sistem Anda masih menghasilkan volume besar log mandiri agen, pertimbangkan untuk menggunakan rotasi log. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan rotasi log.