Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah agen Monitoring

Halaman ini membantu Anda mendiagnosis masalah dalam penginstalan atau menjalankan agen Monitoring.

Catatan: Jika Anda melihat pesan berikut di virtual machine (VM) Linux, Anda dapat mengabaikannya dengan aman:

Need to set
  STACKDRIVER_API_KEY in /etc/sysconfig/stackdriver Not starting. Configuration
  error.

Pesan ini dikeluarkan oleh layanan lama yang secara bertahap diganti. Pesan ini tidak berbahaya dan pada akhirnya akan hilang.

Checklist

Jika Anda mengalami masalah saat menginstal atau menggunakan Agen pemantauan, berikut beberapa hal yang perlu diperiksa:

Jika perintah penginstalan Linux menghasilkan error, pastikan Anda menggunakan awalan sudo pada perintah penginstalan.
Pastikan layanan agen berjalan di instance VM Anda:
- Untuk VM Windows, gunakan perintah PowerShell berikut:
```
Get-Service -Name StackdriverMonitoring
```
  Telusuri layanan yang disebut Stackdriver Monitoring. Jika agen tidak berjalan, Anda mungkin perlu memulainya ulang.
- Untuk VM Linux, gunakan perintah berikut:
```
sudo service stackdriver-agent status
```
  Jika agen tidak berjalan, Anda mungkin perlu memulainya ulang menggunakan perintah berikut:
```
sudo service stackdriver-agent restart
```
  Jika memulai ulang gagal, dan output log menampilkan "Disabled via metadata", Anda kemungkinan menjalankan image dari Google Cloud Marketplace, tempat agen Monitoring dinonaktifkan secara default. Hal ini dikontrol oleh kunci metadata instance google-monitoring-enable (dengan nilai 0). Untuk mengaktifkan kembali agen, hapus kunci tersebut atau tetapkan nilai ke 1 (lihat Menetapkan metadata instance).
  
  Jika agen tidak dinonaktifkan melalui metadata, instal ulang agen. Untuk mengetahui informasi tentang proses ini, lihat bagian Menginstal ulang agen Monitoring.
Periksa apakah agen telah menulis pesan error ke log.
- Di Windows, agen Monitoring menulis pesan ke log Windows Event.
- Di Linux, agen Monitoring adalah paket collectd dan mencatat pesan ke /var/log/syslog atau /var/log/messages. Pesan log diawali dengan collectd atau stackdriver-agent:
  - Jika melihat error HTTP 429, Anda mungkin telah melampaui kuota Monitoring API. Anda dapat melihat kuota yang tersedia dengan memilih APIs & services > Dashboard di konsolGoogle Cloud . Pilih Monitoring API.
  - Jika Anda melihat masalah proxy, periksa apakah Anda telah mengonfigurasi proxy HTTP dengan benar. Petunjuk ini adalah bagian dari Menginstal di Linux dan Windows.
  - Jika Anda melihat masalah akses atau otorisasi API, atau pesan error seperti "Unable to determine collectd endpoint", lihat bagian berikut, Memverifikasi project dan kredensial.
  - Jika Anda melihat error "Unsupported collectd plugin/type combination" atau "Unsupported collectd id" di log, Anda mungkin mengirimkan metrik agen yang tidak didukung. Hal ini dapat terjadi dalam skenario berikut:
    - Anda mengubah salah satu konfigurasi aplikasi pihak ketiga agen. Untuk mengurungkan perubahan, Anda dapat menginstal ulang konfigurasi untuk plug-in tertentu dengan mengikuti petunjuk di halaman dokumentasi yang relevan. Jika Anda ingin menggunakan agen untuk mengirim metrik tersebut ke Monitoring, pertimbangkan untuk mengonversinya menjadi metrik yang ditentukan pengguna.
    - Salah satu plugin aplikasi pihak ketiga mengirimkan metrik baru yang tidak diketahui oleh Monitoring. Lihat halaman dukungan untuk mengetahui detail tentang cara mengirimkan permintaan agar metrik ini ditinjau dan dikategorikan.
Jika agen tampaknya berjalan normal, tetapi Anda tidak mendapatkan data atau kebijakan pemberitahuan tidak berfungsi seperti yang Anda harapkan, Anda harus memeriksa apakah agen mengirimkan data ke project yang benar. Lihat bagian berikut, Memverifikasi project dan kredensial.

Memverifikasi project dan kredensial

Jika agen Monitoring melaporkan error akses atau otorisasi, atau jika agen tampaknya berjalan normal tetapi tidak ada data atau kebijakan pemberitahuan Anda tidak berfungsi seperti yang diharapkan, periksa apakah kredensial instance VM Anda sudah benar, termasuk apakah kredensial tersebut menentukan project yang benar:

Jika Anda menggunakan instance VM Compute Engine dengan kredensial standar (bukan kunci pribadi), kemungkinan data tidak akan dikirim ke project yang salah, tetapi kredensial Anda mungkin masih kurang. Untuk informasi tentang kredensial, lihat Memberikan otorisasi kepada agen Monitoring. Untuk memverifikasi kredensial Anda, lihat Memverifikasi kredensial Compute Engine.
Jika Anda menggunakan instance VM Amazon EC2, atau jika Anda menggunakan kredensial kunci pribadi di instance Compute Engine, kredensial tersebut mungkin tidak valid atau berasal dari project yang salah. Untuk akun AWS, project yang digunakan oleh agen harus berupa project Google Cloud tempat Anda mengirim metrik. Untuk mengetahui informasi tentang kredensial, lihat Mengizinkan agen Monitoring. Untuk memverifikasi kredensial Anda, lihat Memverifikasi kredensial kunci pribadi.

Jika Anda masih belum menyelesaikan masalah, lihat Menginstal ulang Agen pemantauan.

Memverifikasi kredensial Compute Engine

Gunakan halaman instance VM Compute Engine di konsol Google Cloud untuk memverifikasi bahwa instance VM Compute Engine Anda memiliki kredensial yang memadai untuk agen Monitoring. Kredensial biasanya ditambahkan di akun layanan default semua instance VM Compute Engine baru, tetapi Anda dapat mengganti setelan default tersebut saat membuat instance.

Di konsol Google Cloud , buka halaman VM instances:

Buka instance VM

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

Jika perlu, ubah project saat ini menjadi project yang terkait dengan instance VM Compute Engine Anda. Google Cloud Misalnya, jika Anda diminta untuk Aktifkan penagihan, berarti project saat ini tidak memiliki instance VM Compute Engine.
Di halaman VM Instances, klik nama instance VM Anda. Halaman detail untuk instance VM Anda akan muncul.
Di halaman VM instance details, lihat di bagian heading Cloud API access scopes:
- Jika Anda melihat "Izinkan akses penuh ke semua Cloud API", berarti Anda memiliki kredensial yang memadai.
- Jika Anda melihat, di samping Stackdriver Monitoring API, nama yang lebih lama untuk Cloud Monitoring API, bahwa Anda memiliki izin Hanya Tulis atau Penuh, berarti Anda memiliki kredensial yang memadai.
- Jika tidak, akun layanan default instance Anda tidak memiliki kredensial yang diperlukan oleh agen. Untuk menggunakan agen di instance, Anda harus menambahkan kredensial akun layanan kunci pribadi. Untuk mengetahui petunjuknya, lihat Menambahkan kredensial.

Jika Anda memiliki kredensial default yang benar, lanjutkan ke Menginstal di Linux dan Windows.

Memverifikasi kredensial kunci pribadi

Untuk memverifikasi bahwa kredensial kunci pribadi yang valid diinstal pada instance VM Anda, verifikasi terlebih dahulu bahwa file kredensial ada di lokasi yang diharapkan, lalu verifikasi bahwa informasi dalam file kredensial valid. Kredensial yang sebelumnya valid dapat dicabut menggunakan bagian IAM & Admin > Service accounts di konsol Google Cloud . Jika kredensial yang valid tidak ada, lihat Menambahkan kredensial untuk mengganti kredensial yang ada atau menambahkan kredensial baru.

Apakah kredensial ada?

Untuk melihat apakah kredensial akun layanan kunci pribadi ada di instance Anda, jalankan perintah Linux berikut di instance Anda:

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

Jika salah satu perintah menampilkan file seperti yang ditunjukkan di bawah, berarti instance Anda mungkin memiliki kredensial kunci pribadi yang valid. Jika kedua perintah menampilkan file, maka file yang ditunjukkan oleh GOOGLE_APPLICATION_CREDENTIALS akan digunakan.

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

Jika tidak ada file kredensial, lihat Menambahkan kredensial.

Apakah kredensial valid?

Dalam file kredensial, kolom project_id adalah project Google Cloud Anda, client_email mengidentifikasi akun layanan dalam project, dan private_key_id mengidentifikasi kunci pribadi dalam akun layanan. Cocokkan informasi ini dengan yang ditampilkan di bagian IAM & Admin > Service accounts di konsolGoogle Cloud .

File kredensial tidak valid jika salah satu hal berikut berlaku:

Anda memeriksa instance VM Compute Engine, tetapi Google Cloud project dalam file kredensial bukan project yang berisi instance Anda.
Anda sedang memeriksa instance Amazon EC2, tetapi project Google Cloud dalam file kredensial Google Cloud bukan project yang Anda gunakan untuk mengirim metrik dari akun AWS Anda.
Akun layanan yang tercantum tidak ada. Foto mungkin telah dihapus.
Akun layanan yang tercantum tidak memiliki peran yang tepat. Akun tersebut harus memiliki setidaknya roles/monitoring.metricWriter (Monitoring Metric Writer) untuk pengumpulan metrik dan roles/logging.logWriter (Logs Writer) untuk menulis log.
Kunci pribadi tidak ada. Izin mungkin telah dicabut.

Jika akun layanan tidak bermasalah, tetapi kunci pribadinya telah dicabut, Anda dapat membuat kunci pribadi baru dan menyalinnya ke instance Anda. Jika tidak, Anda harus membuat akun layanan baru seperti yang dijelaskan di bagian berikut, Menambahkan kredensial.

Membuat kredensial baru

Jika kredensial tidak valid, lakukan langkah-langkah berikut:

Untuk setiap project terhubung yang berisi instance yang perlu diberi otorisasi dengan kunci pribadi — setiap project yang berisi instance Compute Engine yang dibuat tanpa menyertakan cakupan akses https://www.googleapis.com/auth/monitoring.write — buat akun layanan dan buat kunci pribadi, jika belum ada. Ikuti langkah-langkah di bawah ini:
1. Di konsol Google Cloud , buka halaman Setelan:
  Buka Setelan
  
  Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.
2. Pilih tab Cakupan Netric.
3. Identifikasi project yang berisi resource Compute Engine yang dipermasalahkan dan buka konsol Google Cloud .
4. Buka halaman IAM Service Accounts di konsol Google Cloud , pilih project Google Cloud Anda, buat akun layanan baru, lalu buat kunci pribadi baru untuk akun layanan tersebut.
  Untuk melakukan langkah-langkah ini, lakukan salah satu hal berikut:
  - Buka halaman IAM Service Accounts, pilih project Google Cloud Anda, lalu ikuti langkah-langkah di Membuat akun layanan:
    
    Buka Akun Layanan IAM
  - Klik tombol berikut, lalu pilih project Google Cloud :
    
    Membuat akun layanan dan mendownload kunci
    
    Tombol sebelumnya mengotomatiskan proses pembuatan dan mendownload kunci ke sistem lokal Anda untuk akun layanan khusus agen. Jika perlu, proses juga membuat akun layanan yang diperlukan dan memastikan bahwa akun layanan tersebut memiliki izin yang benar. Akun layanan khusus agen memiliki nama yang mirip dengan stackdriver-1234@PROJECT_ID.. Anda akan diberi tahu tentang penyelesaian tindakan ini dengan dialog yang mirip dengan berikut ini:
  Catatan: Akun layanan dapat memiliki maksimum 10 kunci. Untuk mengetahui informasi selengkapnya, lihat Batas.
Ganti kunci pribadi pada instance yang sesuai dengan akun layanan yang dimaksud.
- Di Linux, ganti kunci pribadi yang ada di /etc/google/auth/application_default_credentials.json.
- Di Windows, ganti kunci pribadi yang ada di C:\ProgramData\Google\Auth\application_default_credentials.json. Untuk mengetahui informasi selengkapnya, lihat Menyalin kunci pribadi ke instance Anda.
Memulai ulang agen
- Di Linux, jalankan sudo service stackdriver-agent restart
- Di Windows, buka konsol pengelolaan layanan dan mulai ulang layanan Cloud Monitoring.

Jika Anda memiliki beberapa project yang memerlukan kunci pribadi baru, ulangi prosedur ini untuk setiap project.

Untuk memverifikasi bahwa kunci pribadi sudah benar, lihat Apakah kredensial ada?. Secara khusus:

Baca file JSON kunci pribadi di instance, misalnya (di Linux): sudo cat /etc/google/auth/application_default_credentials.json
Pastikan nilai kolom project_id cocok dengan nilai project yang dipantau yang baru saja Anda buatkan kredensialnya.

Memverifikasi data agen

Untuk memverifikasi bahwa agen mengirimkan metrik dengan benar, gunakan metode timeSeries.list Monitoring API untuk mencari data deret waktu terbaru dari instance VM. Anda dapat memanggil metode menggunakan APIs Explorer di halaman dokumentasi metode. Jika Anda tidak melihat data apa pun, mungkin agen mengirim data ke project yang salah. Untuk memeriksa hal tersebut, lihat Memverifikasi project dan kredensial.

Berikut petunjuk mendetail untuk menggunakan metode timeSeries.list:

Tentukan ID instance dari instance VM tempat Anda menginstal agen:
- Instance Compute Engine: Buka halaman detail Compute Engine untuk instance Anda. Di bagian bawah halaman, klik REST yang Setara. ID tersebut adalah angka 19 digit.
- Instance Amazon EC2: ID untuk setiap instance ditampilkan dalam daftar instance. ID-nya terlihat seperti i-1a2b3c4d.
Buka halaman dokumentasi untuk metode timeSeries.list.
Isi formulir APIs Explorer:
1. Tetapkan name ke project yang berisi instance VM Anda, dengan awalan projects/. Misalnya, projects/[YOUR_PROJECT_ID].
2. Tetapkan filter ke baris berikut untuk memilih metrik agen dari instance VM Anda. Salin dan tempel ke APIs Explorer, lalu ubah ID instance VM:
```
metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"
```
3. Tetapkan interval waktu penelusuran. Anda menginginkan interval sekitar lima menit:
  - Tetapkan interval.endTime ke waktu GMT saat ini, yang dapat Anda temukan di time.is/GMT. Waktu harus diformat seperti contoh berikut. Jangan sertakan waktu dalam tanda kutip:
```
2016-10-31T14:10:00Z
```
  - Tetapkan interval.startTime sekitar lima menit sebelum waktu berakhir, menggunakan format yang sama.
4. Biarkan semua kolom lainnya kosong.
Klik Jalankan.

Anda akan melihat output seperti berikut:

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

Jika panggilan API menampilkan data deret waktu dari instance VM Anda, seperti yang ditunjukkan di atas, berarti agen Anda berfungsi dengan baik dan Anda telah selesai.

Jika Anda tidak melihat data deret waktu, periksa hal berikut:

Jika panggilan API Anda menghasilkan pesan error, hal ini tidak menunjukkan masalah agen. Periksa apakah kolom APIs Explorer telah diisi dengan benar:
- Error "Argumen tidak valid" mungkin menunjukkan masalah pada ejaan dan format ID project, filter, atau dua stempel waktu.
  
  Persyaratan untuk argumen stempel waktu bergantung pada jenis metrik yang Anda tentukan. Jenis metrik mencatat data GAUGE, DELTA, atau CUMULATIVE. Lihat MetricKind untuk mengetahui informasi selengkapnya.
  
  Untuk metrik DELTA dan CUMULATIVE, waktu mulai dan berakhir diperlukan, dan waktu berakhir harus setelah waktu mulai. Jenis metrik ini mencatat perubahan yang diukur dari waktu ke waktu, sehingga waktu mulai dan berakhir harus menentukan interval yang tidak nol.
- Error "Not authorized" dapat berarti Anda salah mengeja ID project.
- Error "Tidak ditemukan" dapat menunjukkan bahwa Anda telah menghilangkan awalan projects/ yang diperlukan di kolom "name".
Perbaiki masalahnya, lalu coba lagi panggilan API.
Jika panggilan API berhasil, tetapi Anda hanya melihat respons kosong, { }, maka pastikan filter dan interval waktu Anda sudah benar. Error dalam memformat stempel waktu dapat menyebabkan tidak ada data yang ditampilkan. Jika semuanya tampak benar, tetapi Anda tidak mendapatkan data, berarti agen tidak mengirim data metrik, atau setidaknya tidak ke project yang Anda harapkan. Hal ini dapat menunjukkan masalah kredensial; lihat Memverifikasi kredensial kunci pribadi.

Menginstal ulang agen Monitoring

Menginstal agen versi terbaru dapat menyelesaikan banyak masalah:

Jika Anda yakin bahwa masalahnya tidak terkait dengan kredensial, Anda dapat langsung membaca bagian Menginstal di Linux dan Windows.
Untuk penginstalan agen secara penuh dan kredensial yang diperlukan, lihat Menginstal agen Monitoring.

Menentukan VM Linux mana yang telah menginstal agen

Jalankan salah satu kueri berikut untuk melihat VM Linux mana yang menjalankan agen:
- APIs Explorer
- Metrics Explorer
Perhatikan bahwa untuk setiap kueri, Anda harus memasukkan nama project dan menyesuaikan batas waktu.

Memulai ulang agen secara otomatis

Anda dapat menyiapkan skrip untuk memeriksa apakah agen sedang berjalan, lalu memulai ulang agen jika terjadi error.

Misalnya, di Linux, Anda dapat membuat entri crontab berikut untuk memeriksa status agen setiap 5 menit:

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

Masalah umum

Bagian berikut menjelaskan masalah yang diketahui pada agen Monitoring.

Masalah akses data proses (Windows)

Anda mungkin melihat pesan error agen di Log Peristiwa Windows yang mirip dengan berikut:

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

Pesan ini menunjukkan bahwa agen tidak memiliki akses ke data ini di sistem Anda. Untuk berhenti melihat pesan ini, Anda dapat memberikan izin yang memadai kepada pengguna SYSTEM untuk membaca data proses bagi proses dan layanan yang tercantum dalam pesan error. Jika Anda tidak memerlukan data ini, Anda dapat mengabaikan pesan informasi ini dengan aman.

Masalah cache metadata (Linux)

Anda mungkin melihat pesan error dalam file log sistem Linux (/var/log/syslog di Debian / Ubuntu atau /var/log/messages di Red Hat / CentOS / SLES) yang serupa dengan berikut ini:

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

Pesan ini adalah peringatan yang tidak berbahaya dan bukan indikasi kehilangan data. Pesan ini dibuat oleh penerapan plugin proses saat ini jika ada ketidakcocokan stempel waktu.

Masalah titik data dengan nilai tak terhingga yang dihapus (Linux)

Anda mungkin melihat pesan error dalam file log sistem Linux (/var/log/syslog di Debian / Ubuntu atau /var/log/messages di Red Hat / CentOS / SLES) yang serupa dengan berikut ini:

write_gcm: can not take infinite value

Pesan ini menunjukkan bahwa satu titik data yang salah format telah dihapus. Hal ini biasanya tidak berbahaya dan dapat diabaikan.

Masalah pembatasan kunci metadata (Linux)

Anda mungkin melihat pesan error dalam file log sistem Linux (/var/log/syslog di Debian / Ubuntu atau /var/log/messages di Red Hat / CentOS / SLES) yang serupa dengan berikut ini:

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

Pesan ini menunjukkan bahwa update status pembatasan memori gagal satu kali. Hal ini biasanya tidak berbahaya, tetapi bisa menjadi tanda bahwa agen kehabisan memori, terutama jika sering terjadi.

Masalah kehabisan kuota Cloud Monitoring API (Linux)

Anda mungkin melihat pesan error dalam file log sistem Linux (/var/log/syslog di Debian / Ubuntu atau /var/log/messages di Red Hat / CentOS / SLES) yang serupa dengan berikut ini:

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

Pesan ini menunjukkan bahwa batas kuota Cloud Monitoring API telah tercapai. Ikuti panduan Quota untuk mengetahui informasi tentang cara mengelola batas kuota Anda.

Penggunaan memori tinggi karena `COLLECTD_INTERVAL` rendah (Linux)

Anda mungkin melihat penggunaan memori yang tinggi pada agen saat COLLECTD_INTERVAL dikonfigurasi lebih pendek daripada 60 seconds default, misalnya, 10 seconds. Hal ini merupakan batasan yang diketahui dari agen karena agen mengirim permintaan secara berurutan dari satu thread. Untuk mengurangi dampak ini, pertimbangkan untuk mengurangi COLLECTD_INTERVAL hanya untuk sebagian kecil metrik yang diperlukan, dan biarkan metrik lainnya pada interval default.

Masalah buffer overflow token (Linux)

Anda mungkin melihat pesan error di file log sistem Linux (/var/log/syslog di Debian / Ubuntu atau /var/log/messages di Red Hat / CentOS / SLES) yang mirip dengan berikut ini:

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

Pesan ini menunjukkan bahwa agen pemantauan perlu diupgrade ke versi 6.1.2 atau yang lebih tinggi.

Repositori mengubah nilai 'Origin'-nya (Linux)

Anda mungkin melihat pesan error yang mirip dengan berikut saat mengupgrade agen, menginstal agen, atau menjalankan apt-get update di Linux Debian/Ubuntu:

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

Pesan ini menunjukkan bahwa cache repositori paket mungkin telah berbeda dari sumbernya. Untuk mengatasinya, jalankan perintah berikut:

apt-get --allow-releaseinfo-change update

Kemudian, jalankan upgrade atau penginstalan lagi.

Agen yang dihapus dilaporkan oleh konsol Google Cloud sebagai terinstal

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

Agen pemantauan tidak muncul di daftar Uninstall a program Windows

Untuk meng-uninstal Agen pemantauan saat tidak tercantum dalam daftar Uninstall a program di Panel Kontrol Windows, jalankan uninstall.exe dari direktori tempat Anda menginstalnya.

Memecahkan masalah agen Monitoring Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Checklist

Memverifikasi project dan kredensial

Memverifikasi kredensial Compute Engine

Memverifikasi kredensial kunci pribadi

Apakah kredensial ada?

Apakah kredensial valid?

Membuat kredensial baru

Memverifikasi data agen

Menginstal ulang agen Monitoring

Menentukan VM Linux mana yang telah menginstal agen

Memulai ulang agen secara otomatis

Masalah umum

Masalah akses data proses (Windows)

Masalah cache metadata (Linux)

Masalah titik data dengan nilai tak terhingga yang dihapus (Linux)

Masalah pembatasan kunci metadata (Linux)

Masalah kehabisan kuota Cloud Monitoring API (Linux)

Penggunaan memori tinggi karena COLLECTD_INTERVAL rendah (Linux)

Masalah buffer overflow token (Linux)

Repositori mengubah nilai 'Origin'-nya (Linux)

Agen yang dihapus dilaporkan oleh konsol Google Cloud sebagai terinstal

Agen pemantauan tidak muncul di daftar Uninstall a program Windows

Memecahkan masalah agen Monitoring

Penggunaan memori tinggi karena `COLLECTD_INTERVAL` rendah (Linux)