Sesi 34: Beli Mata atau Rakit Sendiri (Dynatrace vs Jalur DIY)

1. Bayangkan Jika: Dua Cara Punya Mata

Bayangkan dua pabrik dengan masalah identik: mesin nomor tujuh bergetar tidak normal.

Pabrik pertama punya tim yang memasang sendiri sensor di setiap mesin, menyambungkannya ke dashboard buatan sendiri, dan menulis aturan alarm. Butuh enam bulan pemasangan. Tapi begitu jalan, setiap orang di pabrik paham cara membacanya, dan tidak ada tagihan vendor.

Pabrik kedua memanggil satu perusahaan. Tim perusahaan itu datang, memasang sensor ke dalam setiap mesin tanpa membongkar apa pun, dan menyambungkannya ke sistem mereka sendiri. Dua hari selesai. Begitu ada mesin bergetar aneh, sistemnya tidak cuma bunyi — dia langsung menunjuk: "bantalan nomor tiga, mulai aus sejak 14:22, sisa umur sekitar 40 jam".

Sekarang pertanyaan yang jujur: yang mana lebih benar? Jawabannya tergantung pada apa yang lebih langka di perusahaan itu — waktu engineer atau uang.

---

2. Apa yang Sebenarnya Terjadi

2.1 Dua Jalur, Bukan Dua Produk

Bab ini tidak membandingkan dua merek. Dia membandingkan dua jalur strategi observability, yang diwakili oleh dua contoh:

• Jalur beli: Dynatrace (wakil dari kelas platform observability komersial terintegrasi).
• Jalur rakit: OpenTelemetry + Prometheus + Loki + Tempo + Grafana (wakil dari kelas yang dibangun dan dikelola sendiri).

Keduanya bisa menang. Yang salah adalah memilih tanpa sadar sedang membeli apa.

2.2 Jalur Beli: Dynatrace

OneAgent adalah inti modelnya: satu agen yang dipasang di host/container menyuntikkan instrumentasi ke dalam aplikasi secara otomatis. Engineer tidak menambah baris kode. Nol perubahan aplikasi, nol rilis ulang. Inilah alasan ekonomi terbesarnya — bukan fitur, tapi tidak adanya pekerjaan instrumentasi manual.

Beberapa kemampuan yang jadi ciri khas:

Biayanya berbasis per host dan per volume data — sehingga setiap node baru dan setiap lonjakan log terasa langsung di tagihan. Inilah trade-off intinya: makin besar skalanya, makin besar biayanya, secara linear mengikuti jumlah host.

Risiko terbesarnya bukan harga, tapi vendor lock-in dalam dua arah: 1. Keahlian tim berpindah ke alat itu, bukan ke konsepnya. 2. Data dan konfigurasi sulit dipindahkan. Keluar dari platform menjadi proyek besar.

2.3 Jalur Rakit: OTel + Prometheus + Loki + Tempo + Grafana

Di sisi lain ada jalur terbuka:

Kelebihannya konkret: biaya infrastruktur umumnya jauh lebih rendah pada skala besar, data tetap milikmu, dan keahlian yang didapat tim adalah keahlian konsep observability — yang berlaku di mana pun.

Biayanya juga konkret dan sering diremehkan:

• Beban operasional menumpuk di timmu. Upgrade, scaling penyimpanan, tuning retention, memperbaiki alert yang berisik — semuanya pekerjaan internal.
• Instrumentasi manual. Kamu harus menyentuh kode atau pustaka untuk memberi nama span, memilih atribut, menyebarkan traceparent. Cakupan jadi selebar apa yang kamu kerjakan, bukan otomatis.
• Sampling hampir wajib. Menyimpan semuanya terlalu mahal, jadi kamu harus memutuskan: rekam 1%, 10%, atau semuanya dengan biaya tinggi. Setiap keputusan sampling adalah kompromi yang bisa menyembunyikan bug langka.
• Kamu membangun korelasi sendiri. Menyatukan metrik → trace → log supaya bisa mengklik dari "p99 naik" ke "query ini" itu pekerjaan integrasi, bukan bawaan.

2.4 Tiga Sumbu Trade-off yang Nyata

Perbandingan jujur bukan "cepat vs murah", tapi tiga sumbu:

Sumbu 1 — Auto-instrumentation vs instrumentasi manual. Otomatis: cakupan luas sejak hari pertama, tanpa menyentuh kode. Manual: kontrol penuh atas apa yang diukur, tanpa ketergantungan vendor. Yang pertama menang kalau waktu engineer langka; yang kedua menang kalau butuh kontrol presisi dan ingin tetap portabel.

Sumbu 2 — Capture penuh vs sampling. Capture penuh: bug langka tetap terekam, tapi biaya penyimpanan bisa meledak saat trafik naik. Sampling: biaya terkendali, tapi kamu berjudi bahwa bug yang penting bukan bagian dari sampel yang dibuang. Ini pilihan kebijakan, bukan pilihan teknis.

Sumbu 3 — Dukungan vendor vs kemandirian tim. Vendor: ada pihak yang bisa dihubungi pukul tiga pagi, ada SLA, ada rilis fitur. Kemandirian: tidak ada tagihan mengejutkan dan tidak ada lock-in, tapi kalau pipa observability-mu rusak, tidak ada tiket yang bisa dinaikkan — kamu sendiri yang memperbaiki.

2.5 Kenapa Level 4 Ada Sebagai Level Terpisah

Level 3 (Sesi 22–31) berbicara soal kegagalan: retry storm, circuit breaker, cascading failure, dan observability sebagai konsep. Level 4 berbicara soal cara melihat: siapa mengangkut, berapa harganya, siapa menampilkan.

Perbedaan itu penting bagi performance tester, karena pipa observability sendiri bisa jadi sumber insiden:

• Agent yang kehabisan memori di node produksi.
• Buffer log yang penuh, lalu dibuang diam-diam (Sesi 32).
• Index log yang jadi read-only dan menjatuhkan aplikasi (Sesi 33).
• Vendor yang mengirim tagihan mengikuti volume insiden.
• Query dashboard yang membebani cluster untuk semua orang.

Ciri tim yang sudah matang: pipa observability mereka punya metrik, alarm, dan load test seperti layanan produksi lainnya.

---

3. Bagaimana Jika Kita Coba... (Solusi Naif)

"Pakai yang gratis saja, pasti lebih murah."

Gratis dalam lisensi, bukan gratis dalam waktu. Setiap jam tim menghabiskan waktu merawat pipeline adalah jam yang tidak dipakai menguji sistem. Pada skala kecil, jalur rakit jelas menang. Pada skala besar dengan tim kecil, perhitungannya bisa berbalik.

"Pakai platform komersial saja, semua beres."

Semua beres sampai instrumen tagihan berdetak dengan volume. Platform komersial juga tidak menghapus kebutuhan memahami konsep: kalau kamu tidak tahu apa itu p99 atau trace, dashboard yang indah tidak menolong siapa pun.

"Pakai keduanya."

Ini justru strategi yang masuk akal di banyak perusahaan: platform komersial untuk tim yang butuh jawaban cepat, dan OTel sebagai lapisan instrumentasi portabel supaya data tidak sepenuhnya terikat pada satu vendor. Yang harus dihindari adalah menjalankan keduanya penuh tanpa disengaja — membayar dua kali untuk cakupan yang sama.

---

4. Nama Resminya

---

5. Di Dunia Kita

Pertanyaan yang harus dijawab sebelum memilih jalur:

1. Siapa yang jaga jam tiga pagi? Kalau ada pihak yang bisa dihubungi, itu bernilai dan harganya wajar. Kalau timmu memang sudah kuat operasionalnya, jalur rakit sah.
2. Berapa lama waktu engineer untuk memasang instrumentasi manual di 40 layanan? Kalau jawabannya enam bulan dan proyeknya butuh observabilitas bulan depan, otomatisasi adalah fitur termahal yang layak dibeli.
3. Berapa pertumbuhan volume log tiga tahun ke depan? Ini yang menentukan apakah model biaya per-host-per-GB masih masuk akal.
4. Apakah ada regulasi yang melarang data keluar dari lingkunganmu? Ini sering memaksa jalur rakit tanpa bisa ditawar.
5. Apakah data bisa diekspor dengan mudah? Minta jawaban tertulis sebelum masuk, bukan saat mau keluar.

---

6. Lensa Performance Tester

Ini sesi yang paling langsung menyentuh pekerjaan performance tester, karena jalur observability adalah beban tambahan pada sistem yang sedang diuji.

1. Overhead agent di bawah beban. Ukur konsumsi CPU, memori, dan dampak latensi agen saat sistem berjalan pada beban puncak, bukan saat idle. Ini angka yang paling sering diminta dan paling jarang tersedia.
2. Trace propagation completeness. Verifikasi bahwa traceparent bertahan di 100% layanan, tanpa span yang terputus. Satu hop yang putus menghilangkan visibilitas pada bagian paling penting.
3. Observability overhead under load. Pastikan collector/agent tetap di bawah ambang yang disepakati (contoh target: <2% CPU, memori terbatas) bahkan saat trafik 20.000 QPS.
4. Drop rate dan buffer drain time. Berapa lama pipa bertahan saat backend observability mati total sebelum membuang data?
5. MTTD & MTTR sebelum vs sesudah. Ini metrik pembenaran investasinya. Tanpa angka pembanding, klaim "observability mempercepat pemulihan" hanya pendapat.
6. Uji negatif yang wajib: matikan backend observability saat load test berjalan; injeksi disk penuh pada cluster log; bombardir query dashboard yang mahal. Ketiganya menguji apakah pipa observability akan menjatuhkan sistem produksi — atau hanya kehilangan data.

---

7. Pertanyaan untuk Ronde Berikutnya

"Sekarang kita bisa melihat semua yang terjadi. Pertanyaan terakhir bukan soal alat, tapi soal orang: kita punya 31 sesi pengetahuan, dan tim yang berbeda-beda tingkatnya. Bagaimana caranya ini semua benar-benar melekat — dan pertanyaan baku apa yang harus diajukan seorang performance tester setiap kali ada design doc baru mendarat di mejanya?"

(Sesi 30 sudah menyiapkan daftar pertanyaan bakunya — inilah tempat seluruh Level 0–4 disatukan kembali.)