Validasi dan Troubleshooting Telemetry

Halaman ini untuk dua hal: memvalidasi bahwa instance On Premise klien mengirim telemetry ke License Admin, dan mencari penyebabnya bila data tidak masuk. Pemasangan lisensi hanya membuktikan instance bisa membaca lisensinya; telemetry membuktikan arah sebaliknya — data dari instance klien sampai ke kita.

Alur data

1. Saat lisensi aktif, tenant-management-service (service onprem-tenant di compose) mendaftar ke server lisensi dan menerima instance token. Instance lalu tampil di menu Instances dan melakukan phone home secara rutin.
2. Telemetry memakai token yang sama untuk mengirim. Tanpa lisensi yang aktif dan terdaftar, tidak ada token — dan tidak ada telemetry yang terkirim, apa pun nilai TELEMETRY_ENABLED.
3. Setiap TELEMETRY_INTERVAL (bawaan 5 jam) instance mengirim snapshot hari ini (tanggal UTC) dan tanggal-tanggal yang terlewat, paling jauh 30 hari ke belakang. Snapshot tanggal yang sama ditimpa, bukan ditambah.

Syarat di instance klien

Cara memvalidasi data masuk

1. Instance terdaftar. Buka Lisensi → Instances, cari dengan instance_uuid atau slug klien (dicatat di task generate lisensi). Status Online dengan Phone Home Terakhir yang baru berarti pendaftaran dan token berjalan.

   

2. Detail instance. Klik ikon mata. Pastikan UUID sama dengan yang diterbitkan, Phone Home Terakhir baru, dan tidak ada banner Aktivitas Mencurigakan (lihat Satu lisensi, dua instalasi). Catat ID di URL / breadcrumb halaman ini — itulah yang dipakai menu Telemetry.

   

3. Telemetry masuk. Buka Telemetry. Instance muncul setelah snapshot pertamanya diterima, dengan Terakhir Dikirim hari ini atau kemarin.

   
   Instance ID bukan instance_uuid

   Kolom Instance ID di menu Telemetry adalah ID internal License Admin — sama dengan ID di URL detail instance (langkah 2), bukan instance_uuid lisensi. Cocokkan lewat slug, atau lewat detail instance.

4. Isi masuk akal. Klik ikon mata pada baris Telemetry, lalu periksa (penjelasan tiap metrik ada di Telemetry):

   • registered_counts — jumlah workspace dan user mendekati angka di Console klien, bukan nol, dan tidak melebihi kuota lisensi.
   • distinct_active_users dan request_volume terisi — tanda instance memang dipakai.
   • Access log mode sesuai yang dideklarasikan ops (lihat Membaca angka yang janggal).

Bila data tidak masuk

Periksa berurutan — tiap langkah bergantung pada langkah sebelumnya.

1. Sudah lewat satu interval? Lihat kapan onprem-tenant terakhir start (docker compose ps onprem-tenant). Kurang dari 5 jam → tunggu.

2. Versi dan env. Dari folder instalasi klien:

   docker compose exec onprem-tenant env | grep -E '^(TELEMETRY_|LICENSE_SERVER_URL|LICENSE_ENABLED|STATE_FILE_PATH)'

   Bandingkan dengan tabel Syarat di instance klien. Perintah ini sengaja tidak menampilkan LICENSE_KEY.

3. Lisensi aktif dan terdaftar? Console → Licence harus Active, dan instance harus Online di menu Instances. Bila instance tidak ada atau Belum Terhubung, masalahnya ada di pendaftaran lisensi, bukan telemetry.

4. Jaringan. Dari server klien:

   curl -s https://be-admin.alurkerja.com/api/instances/ready

   Jawaban {"error":"invalid token"} berarti server lisensi terjangkau (401 memang diharapkan tanpa token). Timeout, Could not resolve host, atau halaman HTML berarti jaringan, DNS, atau proxy keluar yang bermasalah.

5. Baca log. Log telemetry selalu diawali telemetry:

   docker compose logs --since 24h onprem-tenant | grep -iE 'telemetry|license register|registered with license'

   Artinya ada di tabel berikut.

Arti baris log

Log di instance klien (onprem-tenant):

Jawaban server lisensi yang tercatat di baris response status=…:

Semua kiriman yang gagal diulang otomatis pada tick berikutnya — tidak ada data yang dibuang selama masih dalam jendela 30 hari.

Satu lisensi, dua instalasi

Bila detail instance menampilkan banner Aktivitas Mencurigakan Terdeteksi dengan anomali instance_uuid mismatch atau superseded token reuse — possible clone, server lisensi melihat lebih dari satu instalasi memakai identitas yang sama — misalnya VM hasil clone, instalasi uji yang memakai lisensi produksi, atau state.json yang disalin ke server lain. Telemetry dari salah satunya akan ditolak dengan instance_uuid mismatch.

Pastikan setiap instalasi punya lisensinya sendiri. Klik Lihat log mencurigakan untuk melihat IP asal tiap kejadian.

Membaca angka yang janggal

• Kategori 1 dan 2 bernilai nol — periksa Access log mode lebih dulu. off berarti proxy-service instance itu tidak mencatat akses, jadi nol bukan berarti sepi. Penjelasan lengkap di Membaca angka nol.
• Access log mode unknown — TELEMETRY_ACCESS_LOG_MODE belum di-set di onprem-tenant. Ini hanya label; isi agar sama dengan GATEWAY_ACCESS_LOG_MODE proxy-service (bawaan api).
• Terakhir Dikirim berhenti di tanggal lama — pengiriman berhenti sejak tanggal itu. Mulai dari langkah Bila data tidak masuk.
• Jumlah workspace atau user berbeda dari kenyataan — bandingkan dengan Overview di Console klien pada hari yang sama. Snapshot hari ini terus diperbarui tiap 5 jam, jadi angka hari berjalan bisa tertinggal beberapa jam.