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 leaderboard 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\
- Linux:
- 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
atauparse_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, menghapusagent.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 dandisk/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 . |
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/*/
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 direktoribuffers
,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.