Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah penyerapan data Agen Operasional

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

Sebelum memulai

Sebelum mencoba memperbaiki masalah, periksa status health check agen.

Konsol Google Cloud menampilkan penginstalan Ops Agent yang macet di 'Tertunda'

Meskipun setelah berhasil menginstal Ops Agent, konsol Google Cloud mungkin masih menampilkan status 'Tertunda'. Gunakan gcpdiag untuk mengonfirmasi penginstalan Agen Operasional dan memverifikasi bahwa agen tersebut 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. Lampirkan akun layanan ke VM, lalu instal ulang Agen Operasional.
VM sudah memiliki salah satu agen lama yang diinstal, 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 informasi tentang cara memeriksa dan memperbarui cakupan akses, lihat Memverifikasi cakupan akses.
Logging API atau Monitoring API tidak diaktifkan.

Gunakan health check agen untuk mengidentifikasi akar masalah dan solusi yang sesuai.

Agen berjalan, tetapi data tidak diserap

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

Di konsol Google Cloud, buka halaman Metrics explorer:
Buka Metrics explorer

Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
Di tombol berlabel Builder Code, pilih Code, lalu tetapkan bahasa ke MQL.

Masukkan kueri berikut, lalu klik Run:

fetch gce_instance
| metric 'agent.googleapis.com/agent/uptime'
| align rate(1m)
| every 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"), 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 buffering dapat diakses dan disk VM tidak penuh, mulai ulang Ops Agent:

Linux

Untuk memulai ulang agen, jalankan perintah berikut di instance Anda:
```
sudo systemctl restart google-cloud-ops-agent
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan pastikan komponen "Metrics Agent" dan "Logging Agent" dimulai:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Hubungkan ke instance Anda menggunakan RDP atau alat serupa, lalu login ke Windows.
Buka terminal PowerShell dengan hak istimewa administrator dengan mengklik kanan ikon PowerShell dan memilih Run as Administrator
Untuk memulai ulang agen, jalankan perintah PowerShell berikut:
```
Restart-Service google-cloud-ops-agent -Force
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan verifikasi bahwa komponen "Metrics Agent" dan "Logging Agent" dimulai:
```
Get-Service google-cloud-ops-agent*
```

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 tindakan berikut:

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

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

Jika Anda mengubah konfigurasi logging, mulai ulang Ops Agent:

Linux

Untuk memulai ulang agen, jalankan perintah berikut di instance Anda:
```
sudo systemctl restart google-cloud-ops-agent
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan pastikan komponen "Metrics Agent" dan "Logging Agent" dimulai:
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Hubungkan ke instance Anda menggunakan RDP atau alat serupa, lalu login ke Windows.
Buka terminal PowerShell dengan hak istimewa administrator dengan mengklik kanan ikon PowerShell dan memilih Run as Administrator
Untuk memulai ulang agen, jalankan perintah PowerShell berikut:
```
Restart-Service google-cloud-ops-agent -Force
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan verifikasi bahwa komponen "Metrics Agent" dan "Logging Agent" dimulai:
```
Get-Service google-cloud-ops-agent*
```

Memeriksa 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 berjalan di aplikasi Task Manager.

Memeriksa 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 informasi tentang cara mengatasi masalah ini, lihat Memberikan Otorisasi Agen Operasional.

Apakah agen mengirim metrik ke Cloud Monitoring?

Memeriksa 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 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 untuk kuota Monitoring API apa pun. 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 informasi tentang cara mengatasi masalah ini, lihat Memberikan Otorisasi Agen Operasional.

Masalah konektivitas jaringan

Jika agen berjalan, tetapi tidak mengirim log atau metrik, Anda mungkin memiliki 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.

Agen Ops menjalankan health check yang mendeteksi error konektivitas jaringan. Lihat dokumentasi pemeriksaan kesehatan untuk mengetahui tindakan yang disarankan untuk dilakukan jika terjadi error konektivitas.

Mulai Ops Agent versi 2.28.0, Ops Agent membatasi jumlah ruang disk yang dapat digunakan untuk menyimpan potongan buffering. Agen Operasional membuat potongan buffering 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 pemadaman jaringan menyebabkan potongan buffer ditulis ke disk, Ops Agent menggunakan jumlah ruang disk khusus platform untuk menyimpan potongan tersebut. 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 VM Windows saat VM tidak dapat mengirim potongan buffering ke Cloud Logging API:

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

Saya hanya ingin mengumpulkan metrik atau log, bukan keduanya

Secara default, Agen Ops 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:

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 sepertinya ada yang salah

Agen mencatat "Ekspor gagal. Akan dicoba lagi"

Anda akan melihat entri log "Ekspor gagal" saat titik data pertama dari metrik kumulatif dihapus. 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 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 memulai ulang VM. Agen Ops dan Agen Pemantauan menghitung waktu mulai untuk metrik kumulatif secara berbeda, yang dapat menyebabkan 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 dengan masa berlaku singkat (60 menit) dan dalam jangka waktu yang wajar"

Jika Anda melihat pesan error berikut saat agen menulis metrik, hal ini menunjukkan bahwa jam 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 informasi tentang cara menyinkronkan jam sistem, lihat Mengonfigurasi NTP di VM.

Agen mencatat ke dalam log 'penerima metrik dengan jenis "nvml" tidak didukung'

Jika Anda mengumpulkan metrik GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) menggunakan penerima nvml, Anda telah menggunakan versi Agen Operasional 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 dalam 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 memiliki masalah konfigurasi atau tidak memiliki proses yang menggunakan GPU.

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

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

Jika driver tidak diinstal, lakukan hal berikut:

Instal driver GPU.
Mulai ulang Agen Operasional.

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

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

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 diinstal dan log Ops Agent menunjukkan bahwa Ops Agent berkomunikasi dengan driver, tetapi Anda tidak melihat metrik GPU apa pun, masalahnya mungkin ada pada 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 memiliki metrik processes —processes/max_bytes_used dan processes/utilization—berarti Anda tidak memiliki proses yang berjalan di GPU. Metrik processes GPU tidak dikumpulkan jika tidak ada proses yang berjalan di GPU.

Beberapa metrik tidak ada atau tidak konsisten

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

Tabel berikut menjelaskan perbedaan data yang diserap oleh Ops Agent dan agen Monitoring.

Jenis metrik, yang menghilangkan `agent.googleapis.com`	Agen Operasional (GA)^†	Agen Operasional (Pratinjau)^†	Agen pemantauan
`cpu_state`	Nilai yang mungkin untuk Windows adalah `idle`, `interrupt,` `system`, dan `user`.	Nilai yang mungkin untuk Windows adalah `idle`, `interrupt,` `system`, dan `user`.	Nilai yang mungkin untuk Windows adalah `idle` dan `used`.
`disk/bytes_used` dan `disk/percent_used`	Ditransfer dengan jalur lengkap di label `device`; misalnya, `/dev/sda15`. Tidak diserap untuk perangkat virtual seperti `tmpfs` dan `udev`.	Ditransfer tanpa `/dev` di jalur dalam label `device`; misalnya, `sda15`. Ditransfer untuk perangkat virtual seperti `tmpfs` dan `udev`.	Ditransfer tanpa `/dev` di jalur dalam label `device`; misalnya, `sda15`. Ditransfer untuk perangkat virtual seperti `tmpfs` dan `udev`.

^† Kolom GA merujuk pada Ops Agent versi 2.0.0 dan yang lebih tinggi. Kolom Pratinjau merujuk pada versi Agen Operasional yang kurang dari 2.0.0.

Masalah khusus Windows

Bagian berikut hanya berlaku untuk Ops Agent yang berjalan di Windows.

Penghitung performa 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 mengatasi error dengan membuat ulang penghitung performa. Di PowerShell sebagai administrator, jalankan:

cd C:\Windows\system32
lodctr /R

Perintah sebelumnya terkadang dapat gagal; dalam hal ini, 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 baru.

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 buffering lokal agen di disk:

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

Catatan: Direktori /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ berisi jenis file berikut:

File buffering: File ini adalah entri log buffering yang di-tail dan diproses oleh Ops Agent, tetapi belum dimasukkan ke Cloud Logging. Jika ada potongan yang rusak, Agen Operasi harus melewatinya dalam versi >= 2.15.0. Namun, dalam beberapa kasus, data tersebut perlu dibersihkan secara manual. File ini disimpan dalam folder bertingkat seperti: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
File posisi tailing file log: File ini mencatat lokasi di file log yang telah di-tailing oleh Ops Agent. Jika file ini dihapus, Ops Agent akan dimulai dari bagian atas file yang dikonfigurasi untuk di-tail. Menghapus file ini dapat menyebabkan duplikasi log jika log tersebut sebelumnya telah berhasil ditransfer. File ini disimpan langsung di direktori sebagai file seperti: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

Sintaksis .../buffers/*/ dalam perintah sebelumnya memastikan bahwa hanya file buffering yang dihapus. File posisi tidak dihapus.

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 buffering 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 buffering

Jika VM tidak memiliki potongan 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 buffering yang rusak, Anda harus menghapusnya. Opsi berikut menjelaskan berbagai cara untuk menangani buffering. Langkah-langkah lain yang dijelaskan dalam Mereset status agen sepenuhnya masih berlaku.

Opsi 1: Hapus seluruh direktori buffers. Ini adalah opsi termudah, tetapi dapat menyebabkan hilangnya log buffering 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 buffering dari direktori buffers, tetapi biarkan file posisi. Pendekatan ini dijelaskan dalam Mereset sepenuhnya status agen.

Opsi 3: Jika tidak ingin menghapus semua file buffering, Anda dapat mengekstrak nama file buffering yang rusak dari log mandiri agen dan hanya menghapus file buffering 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 buffering 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 telah berhasil diserap. Opsi ini hanya memproses ulang file log saat ini; opsi ini tidak memproses ulang file yang telah 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 Ops Agent terbaru

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

Looping error Agen Operasional versi 2.47.0, 2.48.0, atau 2.49.0

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

Masalah ini telah diatasi di Agen Operasional versi 2.50.0.

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

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

Jika memiliki diagram, dasbor, atau kebijakan pemberitahuan yang menggunakan label namespace, Anda mungkin harus memperbarui kueri setelah mengupgrade Ops Agent 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 Prometheus tanpa jenis mengubah jenis metrik mulai dari Ops Agent versi 2.39.0

Mulai versi 2.39.0, Agen Operasi 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 tanpa jenis diperlakukan sebagai pengukur dan penghitung. Akibatnya, pengguna kini dapat menggunakan operasi kumulatif pada metrik ini.

Jika memiliki diagram, dasbor, atau kebijakan pemberitahuan yang menggunakan MQL untuk mengkueri metrik Prometheus tanpa jenis, Anda harus memperbarui kueri MQL setelah mengupgrade Agen Operasi ke versi 2.39.0 atau yang lebih baru. Daripada membuat kueri untuk metrik tanpa jenis sebagai prometheus.googleapis.com/METRIC_NAME/gauge, ubah jenis metrik sebagai berikut:

Gunakan prometheus.googleapis.com/METRIC_NAME/unknown untuk versi pengukur metrik.
Gunakan prometheus.googleapis.com/METRIC_NAME/unknown:counter untuk versi penghitung metrik.

Anda tidak perlu melakukan perubahan apa pun saat membuat diagram, dasbor, atau kebijakan pemberitahuan yang menggunakan PromQL untuk membuat kueri metrik Prometheus yang tidak berjenis, tetapi Anda dapat menerapkan operasi kumulatif ke metrik tersebut setelah mengupgrade Ops Agent ke versi 2.39.0 atau yang lebih baru.

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

Di Windows pada Ops Agent versi 2.27.0 hingga 2.29.0, bug yang menyebabkan agen terkadang membocorkan soket menyebabkan peningkatan penggunaan memori dan jumlah handle yang besar yang disimpan oleh proses fluent-bit.exe.

Untuk mengurangi masalah ini, upgrade Ops Agent ke versi 2.30.0 atau yang lebih baru, dan mulai ulang agen.

Zona waktu Log Aktivitas 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 setidaknya Ops Agent 2.30.0 jika Anda mengalami masalah ini. Jika tidak dapat mengupgrade, Anda dapat mencoba salah satu solusi berikut.

Menggunakan 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 (semua versi 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 memori tinggi Windows yang diketahui, sebaiknya Anda mengupgrade ke setidaknya Ops Agent 2.30.0 jika mengalami masalah ini.

Masalah umum dalam rilis Agen Operasional lama

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

Log yang tidak berbahaya (versi 2.9.1 dan yang lebih lama)

Anda mungkin melihat error saat meng-scrap metrik dari pseudo-proses 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 menghabiskan terlalu banyak CPU, memori, dan ruang disk (versi 2.16.0 dan yang lebih lama)

Versi Agen Operasi sebelum 2.17.0 mungkin 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 potongan buffering yang rusak. Jika hal ini terjadi, Anda akan melihat pesan dalam jumlah besar 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 log mandiri agen dalam jumlah besar, pertimbangkan untuk menggunakan rotasi log. Untuk informasi selengkapnya, lihat Menyiapkan rotasi log.