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 Operasional yang sedang berjalan. Jika Agen Operasional tidak berjalan, lihat Memecahkan masalah penginstalan dan memulai.

Sebelum memulai

Sebelum mencoba memperbaiki masalah, periksa status health check agen.

Agen sedang berjalan, tetapi data tidak diserap

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, menulis ke metrik.

Di panel navigasi Konsol Google Cloud, pilih Monitoring, lalu pilih Metrics Explorer:
Buka Metrics Explorer
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 Agen Operasional gagal"), subagen Logging mengalami masalah terkait penulisan log. Periksa kondisi berikut:

Verifikasi bahwa 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 menerapkan SSH ke VM.

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

Linux

Untuk memulai ulang agen, jalankan perintah berikut pada instance Anda:
```
sudo systemctl restart google-cloud-ops-agent
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan verifikasi bahwa 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 yang memiliki 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 ("Agen Operasional gagal mengurai log"), masalah yang kemungkinan besar ada pada konfigurasi pemroses logging. Untuk mengatasi masalah ini, lakukan hal 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 menerapkan SSH ke VM.

Jika Anda mengubah konfigurasi logging, mulai ulang Agen Operasional:

Linux

Untuk memulai ulang agen, jalankan perintah berikut pada instance Anda:
```
sudo systemctl restart google-cloud-ops-agent
```
Untuk mengonfirmasi bahwa agen dimulai ulang, jalankan perintah berikut dan verifikasi bahwa 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 yang memiliki 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 menerapkan SSH 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 Task Manager.

Memeriksa log modul logging

Langkah ini mengharuskan Anda untuk melakukan SSH 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, layanan agen tidak berjalan dengan benar. Buka bagian Agent is installed but not running 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, naikkan kuota atau kurangi throughput log.

Anda mungkin melihat error berikut dalam 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 menyelesaikan masalah ini, lihat Memberikan otorisasi kepada Agen Operasional.

Apakah agen mengirim metrik ke Cloud Monitoring?

Memeriksa log modul metrik

Langkah ini mengharuskan Anda untuk melakukan SSH ke VM.

Anda dapat menemukan log modul metrik di {i>syslog<i}. Jika tidak ada log, ini menunjukkan bahwa layanan agen tidak berjalan dengan benar. Buka bagian Agent is installed but not running terlebih dahulu untuk memperbaiki kondisi tersebut.

Anda mungkin melihat error PermissionDenied saat menulis ke Monitoring API. Error ini terjadi jika izin untuk Agen Operasional 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, naikkan kuota atau kurangi throughput metrik.

Anda mungkin melihat error berikut dalam 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 menyelesaikan masalah ini, lihat Memberikan otorisasi kepada Agen Operasional.

Masalah konektivitas jaringan

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

Penyebab umum masalah konektivitas mencakup 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 Operasional menjalankan health check yang mendeteksi error konektivitas jaringan. Lihat dokumentasi health check untuk mengetahui tindakan yang disarankan untuk menangani error konektivitas.

Mulai dari Agen Operasional versi 2.28.0, Agen Operasional membatasi jumlah ruang disk yang dapat digunakan untuk menyimpan bagian buffer. Agen Operasional membuat potongan buffer saat data logging tidak dapat dikirim ke Cloud Logging API. Tanpa batas, potongan ini mungkin menghabiskan semua ruang yang tersedia, sehingga mengganggu layanan lain di VM. Saat pemadaman jaringan menyebabkan potongan buffer ditulis ke disk, Agen Operasional akan menggunakan kapasitas disk spesifik per 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 mengirim potongan buffer 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 Operasional mengumpulkan metrik dan log. Untuk menonaktifkan pengumpulan metrik atau log, gunakan file config.yaml Agen Operasional untuk mengganti layanan logging atau metrics default sehingga pipeline default tidak memiliki penerima. Untuk informasi selengkapnya, lihat hal berikut:

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

Metrik sedang dikumpulkan, tetapi tampaknya ada yang salah

Agen mencatat "Ekspor gagal. Akan dicoba lagi"

Anda akan melihat entri log "Mengekspor 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 log pesan "TimeSeries could not be called: Points must be called in order."

Jika Anda telah melakukan upgrade ke Agen Operasional dari agen Monitoring lama dan melihat pesan error berikut saat menulis metrik kumulatif, solusinya adalah memulai ulang VM. Agen Operasional dan agen Monitoring menghitung waktu mulai untuk metrik kumulatif secara berbeda, yang dapat menyebabkan poin 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 log pesan "Token harus berupa token berumur singkat (60 menit) dan dalam jangka waktu yang wajar"

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

Agen mencatat 'penerima metrik dengan jenis "nvml" is not supported'

Jika Anda mengumpulkan metrik GPU NVIDIA Management Library (NVML) (agent.googleapis.com/gpu) menggunakan penerima nvml, berarti Anda telah menggunakan versi Agen Operasional dengan dukungan pratinjau untuk metrik NVML. Dukungan untuk metrik ini tersedia secara umum di Agen Operasional 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" is not supported' setelah menginstal Agen Operasional versi 2.38.0 atau yang lebih baru saat menggunakan penerima nvml pratinjau dan mengganti interval pengumpulan default dalam file konfigurasi yang ditentukan pengguna. Error ini terjadi karena penerima nvml sudah tidak ada, 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 pada penerima hostmetrics.

Beberapa metrik tidak ada atau tidak konsisten

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

Tabel berikut menjelaskan perbedaan data yang diserap oleh Agen Operasional dan agen Monitoring.

Jenis metrik, menghapus `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 memungkinkan untuk Windows adalah `idle` dan `used`.
`disk/bytes_used` dan `disk/percent_used`	Diserap dengan jalur lengkap dalam label `device`; misalnya, `/dev/sda15`. Tidak diserap untuk perangkat virtual seperti `tmpfs` dan `udev`.	Diserap tanpa `/dev` di jalur dalam label `device`; misalnya, `sda15`. Diserap untuk perangkat virtual seperti `tmpfs` dan `udev`.	Diserap tanpa `/dev` di jalur dalam label `device`; misalnya, `sda15`. Diserap untuk perangkat virtual seperti `tmpfs` dan `udev`.

^† Kolom GA mengacu pada Agen Operasional versi 2.0.0 dan yang lebih tinggi. Kolom Preview mengacu pada versi Agen Operasional di bawah 2.0.0.

Masalah khusus Windows

Bagian berikut hanya berlaku untuk Agen Operasional 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"

Kesalahan 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 buffer 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 buffer: File ini adalah entri log yang di-buffer, yang telah di-tail dan diproses oleh Agen Operasional, tetapi belum diserap ke dalam Cloud Logging. Jika ada bagian yang rusak, Agen Operasional harus melewatinya pada versi >= 2.15.0. Namun, dalam beberapa kasus, data 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 merekam di lokasi mana dalam file log yang telah di-tail oleh Agen Operasional. Jika file ini dihapus, Agen Operasional akan memulai dari bagian atas file yang dikonfigurasi untuk mengarahkan. Menghapus file ini dapat menyebabkan duplikasi log jika log tersebut sebelumnya berhasil diserap. File ini disimpan langsung dalam direktori sebagai file seperti: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

Sintaksis .../buffers/*/ pada perintah sebelumnya memastikan bahwa hanya file buffer 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 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"

Reset, tetapi simpan file buffer

Jika VM tidak memiliki potongan buffer yang rusak (yaitu, tidak ada pesan format check failed dalam file log mandiri Agen Operasi), 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 termudah, tetapi dapat mengakibatkan hilangnya log yang di-buffer dan duplikasi log yang tidak rusak 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 di Mereset status agen sepenuhnya.

Opsi 3: Jika tidak ingin menghapus semua file buffer, Anda dapat mengekstrak nama file buffer yang rusak dari log mandiri agen dan hanya menghapus 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 Agen Operasional per file log). Menghapus file posisi dapat menyebabkan duplikasi log untuk setiap log yang sudah berhasil diserap. 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 dalam 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 pada rilis Agen Operasional terbaru.

Namespace metrik Prometheus menyertakan nama instance selain ID instance mulai dari Agen Operasional versi 2.46.0

Mulai versi 2.46.0, Agen Operasional menyertakan nama VM sebagai bagian dari label namespace saat menyerap metrik dalam format penyerapan Prometheus. Dalam versi sebelumnya, metrik Prometheus hanya menggunakan ID instance VM sebagai bagian dari label namespace, tetapi dimulai dengan 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 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.

Jenis metrik perubahan metrik tanpa jenis Prometheus dimulai dengan Agen Operasional versi 2.39.0

Mulai versi 2.39.0, Agen Operasional mendukung penyerapan metrik Prometheus dengan jenis yang tidak diketahui. Pada versi sebelumnya, metrik ini diperlakukan oleh Agen Operasional sebagai alat pengukur, tetapi mulai versi 2.39.0, metrik tidak berjenis 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 Operasional ke versi 2.39.0 atau yang lebih baru. Daripada membuat kueri metrik yang tidak berjenis sebagai prometheus.googleapis.com/METRIC_NAME/gauge, ubah jenis metrik sebagai berikut:

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

Anda tidak perlu membuat perubahan apa pun terkait diagram, dasbor, atau kebijakan pemberitahuan yang menggunakan PromQL untuk membuat kueri metrik Prometheus tanpa jenis, tetapi Anda dapat menerapkan operasi kumulatif ke metrik tersebut 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)

Pada Windows di Agen Operasi versi 2.27.0 hingga 2.29.0, bug yang menyebabkan agen terkadang membocorkan soket yang menyebabkan peningkatan penggunaan memori dan jumlah handle yang tinggi yang dimiliki oleh proses fluent-bit.exe.

Untuk mengurangi masalah ini, upgrade Agen Operasi 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 Windows Event Logs di Cloud Logging mungkin salah jika Anda mengubah zona waktu VM dari UTC. Hal ini telah diperbaiki di Agen Operasi 2.27.0, tetapi karena masalah memori tinggi Windows yang umum, sebaiknya upgrade ke setidaknya Ops Agent 2.30.0 jika Anda mengalami masalah ini. Jika tidak dapat melakukan upgrade, 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 diurai pada 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. Hal ini telah diperbaiki di Ops Agent 2.27.0, tetapi karena masalah memori tinggi Windows yang umum, 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 umum terjadi pada rilis Agen Operasional lama.

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

Anda mungkin melihat error saat mengekstrak metrik dari proses pseudo atau proses yang dibatasi. Log berikut tidak berbahaya dan dapat diabaikan dengan aman. Untuk menghapus 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 kapasitas disk (versi 2.16.0 dan yang lebih lama)

Versi Agen Operasional sebelum 2.17.0 mungkin menggunakan banyak CPU, memori, dan kapasitas disk dengan file /var/log/google-cloud-ops-agent/subagents/logging-module.log pada VM Linux atau file C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log di VM Windows karena potongan buffer yang rusak. Jika hal ini terjadi, Anda akan melihat banyak pesan seperti berikut dalam 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 Agen Operasional 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 mengetahui informasi selengkapnya, lihat Menyiapkan rotasi log.