Memecahkan masalah agen Monitoring

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

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 menambahkan awalan sudo ke perintah penginstalan.

  • Pastikan layanan agen berjalan di instance VM Anda:

    • Untuk VM Windows, gunakan perintah PowerShell berikut:

      Get-Service -Name StackdriverMonitoring

      Telusuri layanan bernama Stackdriver Monitoring. Jika agen tidak berjalan, Anda mungkin perlu memulai ulang agen.

    • Untuk VM Linux, gunakan perintah berikut:

      sudo service stackdriver-agent status

      Jika agen tidak berjalan, Anda mungkin perlu memulai ulang menggunakan perintah berikut:

      sudo service stackdriver-agent restart

      Jika mulai ulang gagal, dan output log menampilkan "Disabled via metadata", Anda mungkin menjalankan image dari Google Cloud Marketplace, tempat Agen pemantauan 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 Menginstal ulang agen Monitoring.

  • Lihat apakah agen telah menulis pesan error ke log.

    • Di Windows, agen Pemantauan menulis pesan ke log Aktivitas Windows.

    • Di Linux, Agen pemantauan adalah paket collectd dan mencatat pesan ke /var/log/syslog atau /var/log/messages. Pesan log diawali dengan collectd atau stackdriver-agent:

      • Jika Anda melihat error HTTP 429, Anda mungkin telah melampaui kuota Monitoring API. Anda dapat melihat kuota yang tersedia dengan memilih API & layanan > Dasbor di konsol Google Cloud. Pilih Monitoring API.

      • Jika Anda melihat masalah proxy, pastikan 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 "Kombinasi plugin/jenis collectd tidak didukung" atau "ID collectd tidak didukung" dalam log, Anda mungkin mengirim metrik agen yang tidak didukung. Hal ini dapat terjadi dalam skenario berikut:

        • Anda mengubah salah satu konfigurasi aplikasi pihak ketiga agen. Untuk mengembalikan perubahan, Anda dapat menginstal ulang konfigurasi untuk plugin 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 dikaitkan.

  • Jika agen tampaknya berjalan normal, tetapi Anda tidak mendapatkan data atau kebijakan pemberitahuan tidak berfungsi seperti yang Anda harapkan, Anda harus memeriksa apakah agen mengirim 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), data kemungkinan tidak akan masuk ke project yang salah, tetapi kredensial Anda mungkin masih kurang. Untuk mengetahui 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 informasi tentang kredensial, lihat Memberi otorisasi ke 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 VM instances 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 dari semua instance VM Compute Engine baru, tetapi Anda dapat menimpa default tersebut saat membuat instance.

Di Konsol Google Cloud, buka halaman Instance VM:

Buka instance VM

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

  1. Jika perlu, ubah project Google Cloud saat ini menjadi project yang terkait dengan instance VM Compute Engine Anda. Misalnya, jika Anda diminta untuk Mengaktifkan penagihan, berarti project saat ini tidak memiliki instance VM Compute Engine.
  2. Di halaman VM Instances, klik nama instance VM Anda. Halaman detail untuk instance VM Anda akan muncul.
  3. Di halaman VM instance details, lihat di bagian judul Cloud API access scopes:
    • Jika Anda melihat "Allow full access to all Cloud APIs", berarti Anda memiliki kredensial yang memadai.
    • Jika Anda melihat, di samping Stackdriver Monitoring API, nama 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 di 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 tidak ada kredensial yang valid, lihat Menambahkan kredensial untuk mengganti kredensial yang ada atau menambahkan kredensial baru.

Apakah kredensial tersedia?

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, 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 di akun layanan. Cocokkan informasi ini dengan informasi yang ditampilkan di bagian IAM & Admin > Service accounts di konsol Google Cloud.

File kredensial tidak valid jika salah satu hal berikut berlaku:

  • Anda memeriksa instance VM Compute Engine, tetapi project Google Cloud dalam file kredensial bukan project yang berisi instance Anda.
  • Anda memeriksa instance Amazon EC2, tetapi project Google Cloud dalam file kredensial bukanlah project Google Cloud tempat Anda mengirim metrik dari akun AWS.
  • Akun layanan yang tercantum tidak ada. Mungkin telah dihapus.
  • Akun layanan yang tercantum tidak mengaktifkan 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 tersebut mungkin telah dicabut.

Jika akun layanan tidak masalah, tetapi kunci pribadi telah dicabut, Anda dapat membuat kunci pribadi baru dan menyalinnya ke instance. 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:

  1. 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  Settings:

      Buka Setelan

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

    2. Pilih tab Cakupan metrik.
    3. Identifikasi project yang berisi resource Compute Engine yang dimaksud 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 Buat akun layanan:

        Buka Akun Layanan IAM

      • Klik tombol berikut, lalu pilih project Google Cloud Anda:

        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 ini juga akan membuat akun layanan yang diperlukan dan memastikan bahwa akun layanan 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:

        Banner yang memberi tahu pengguna bahwa akun layanan dan kunci telah dibuat.

  2. Ganti kunci pribadi pada instance yang sesuai dengan akun layanan yang dimaksud.

    • Di Linux, ganti kunci pribadi yang berada di /etc/google/auth/application_default_credentials.json.
    • Di Windows, ganti kunci pribadi yang terletak di C:\ProgramData\Google\Auth\application_default_credentials.json. Untuk informasi selengkapnya, lihat Menyalin kunci pribadi ke instance Anda.

  3. 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 buat 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 adalah petunjuk mendetail untuk menggunakan metode timeSeries.list:

  1. Tentukan ID instance 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 ini adalah angka 19 digit.

    • Instance Amazon EC2: ID untuk setiap instance ditampilkan dalam daftar instance. ID-nya terlihat seperti i-1a2b3c4d.

  2. Buka halaman dokumentasi untuk metode timeSeries.list.

  3. Isi formulir API 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 dalam API 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 ke sekitar lima menit sebelum waktu berakhir, menggunakan format yang sama.

    4. Biarkan semua kolom lain kosong.

  4. 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. Pastikan kolom APIs Explorer diisi dengan benar:

    • Error "Argumen tidak valid" mungkin menunjukkan masalah pada ejaan dan format project ID, 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 waktu berakhir diperlukan, dan waktu berakhir harus lebih lambat dari waktu mulai. Jenis metrik ini mencatat perubahan yang diukur dari waktu ke waktu, sehingga waktu mulai dan akhir harus menentukan interval yang bukan nol.

    • Error "Not authorized" dapat berarti Anda salah mengeja project ID.

    • Error "Tidak ditemukan" dapat menunjukkan bahwa Anda telah menghapus 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 mengakibatkan 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 mungkin menunjukkan masalah kredensial; lihat Memverifikasi kredensial kunci pribadi.

Menginstal ulang agen Monitoring

Menginstal agen versi terbaru dapat menyelesaikan banyak masalah:

Menentukan VM Linux mana yang telah menginstal agen

  • Jalankan salah satu kueri berikut untuk melihat VM Linux mana yang menjalankan agen:

    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 berjalan, lalu memulai ulang agen jika mengalami 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 oleh agen Monitoring.

Masalah akses data proses (Windows)

Anda mungkin melihat pesan error agen di Log Aktivitas 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 untuk proses dan layanan yang tercantum dalam pesan error. Jika 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 mirip dengan berikut:

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 merupakan indikasi kehilangan data. Pesan ini dihasilkan oleh implementasi plugin proses saat ini saat ada ketidakcocokan stempel waktu.

Masalah titik data nilai tak terbatas 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 mirip dengan berikut:

write_gcm: can not take infinite value

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

Masalah throttle 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 mirip dengan berikut:

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 pembaruan status throttling memori gagal satu kali. Hal ini biasanya tidak berbahaya, tetapi dapat menjadi tanda bahwa agen kehabisan memori, terutama jika sering terjadi.

Masalah kuota Cloud Monitoring API habis (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 mirip dengan berikut:

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

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

Penggunaan memori tinggi karena COLLECTD_INTERVAL rendah (Linux)

Anda mungkin melihat penggunaan memori agen yang tinggi saat COLLECTD_INTERVAL dikonfigurasi agar lebih pendek dari 60 seconds default, misalnya, 10 seconds. Ini adalah batasan yang diketahui dari agen karena mengirim permintaan secara serial dari satu thread. Untuk mengurangi hal ini, pertimbangkan untuk mengurangi COLLECTD_INTERVAL hanya untuk subset metrik yang diperlukan, dan biarkan metrik lainnya pada interval default.

Masalah overflow buffering token (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 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 Debian/Ubuntu Linux:

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 menyimpang dari sumbernya. Untuk mengatasinya, jalankan perintah berikut:

apt-get --allow-releaseinfo-change update

Kemudian, jalankan upgrade atau instal lagi.

Agen yang dihapus dilaporkan oleh konsol Google Cloud sebagai terinstal

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

Agen pemantauan tidak muncul di daftar Uninstall a program di Windows

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