





Phintraco Technology is recognized as a certified partner of global IT and communication leaders. These partnerships give it access to best-in-class solutions, which it has combined with its own in-depth industry experience to offer its many clients a complete suite of IT solutions and services.


Phintraco Technology is recognized as the certified partner of global IT and communication leaders such as Avaya, Dell Technologies, Verint, Thales (formerly Gemalto), OneSpan (formerly Vasco), and many more. These partnerships give it access to best in class solutions which it has combined with its own in depth industry experience to offer a complete suite of IT solutions and services to its many clients.

Performa aplikasi perlu dijaga agar tetap sesuai dengan kebutuhan pengguna dan kebutuhan bisnis. Service Level Objective monitoring membantu tim memantau target reliability berdasarkan indikator layanan yang terukur.
Target tersebut dapat berkaitan dengan availability, latency, error rate, atau keberhasilan transaksi. Monitoring membantu tim mengetahui apakah performa masih memenuhi batas yang telah ditentukan. Artikel ini akan membahas lebih lanjut mengenai SLO Monitoring, cara kerjanya, dan cara menentukan SLO untuk aplikasi.
SLO atau Service Level Objective adalah target terukur yang menggambarkan tingkat performa atau reliability layanan. Target ini kemudian menjadi acuan internal bagi tim engineering dan operasional. Biasanya SLO ditetapkan untuk periode tertentu. Contohnya adalah target availability atau persentase transaksi yang berhasil.
Berbeda dari sekadar angka monitoring, target SLO harus menggambarkan kondisi layanan yang penting bagi pengguna. Target ini dapat menggunakan metrik seperti latency, error, availability, dan transaksi yang berhasil.
SLO juga berkaitan dengan error budget. Konsep ini menunjukkan tingkat ketidakandalan yang masih dapat ditoleransi dalam periode tertentu. Oleh karena itu, SLO management perlu dilakukan secara berkelanjutan. Tim perlu meninjau target, memantau pencapaian, dan mengevaluasi perubahan kebutuhan layanan.
Service Level Objective (SLO) merupakan target yang ditetapkan berdasarkan SLI. Misalnya, perusahaan menetapkan target 99,9% request berhasil dalam periode tertentu.
Sementara SLI (Service Level Indicator) adalah indikator yang mengukur performa layanan secara aktual. Contohnya adalah response time, error rate, request success rate, dan availability.
Selain itu, ada juga SLA (Service Level Agreement), yang merupakan kesepakatan layanan antara penyedia dan pelanggan. SLA dapat mencantumkan target layanan serta konsekuensi jika target tertentu tidak terpenuhi.
Hubungan ketiganya dapat dipahami secara sederhana. SLI mengukur kondisi aktualnya, SLO menetapkan targetnya, dan SLA mengatur komitmen layanannya.
SLO juga membantu perusahaan memenuhi SLA dengan lebih terukur. Tim dapat memantau target internal sebelum terjadi pelanggaran terhadap kesepakatan eksternal. Selain itu, error budget membantu tim menentukan toleransi terhadap kegagalan. Data tersebut dapat digunakan untuk pengambilan keputusan terkait perubahan, rilis, dan prioritas perbaikan.
Baca Juga: Observability: Definisi, Cara Kerja, dan Cara MeningkatkannyaPenentuan SLO sebaiknya dimulai dari kebutuhan pengguna dan tujuan bisnis. Berikut adalah beberapa hal yang bisa diperhatikan sebelum menentukan SLO:
Pertama, tentukan aplikasi atau layanan yang paling penting. Prioritaskan layanan yang memiliki pengaruh besar terhadap pengguna dan pendapatan.
Setelah menentukan aplikasi dan layanan, pilih SLI yang relevan. Lalu gunakan indikator seperti availability, latency, error rate, atau keberhasilan transaksi.
Gunakan data historis sebagai dasar penentuan target. Data tersebut bisa membantu menentukan target yang lebih realistis dan dapat dicapai.
Tetapkan nilai target dan periode evaluasi. Target dapat dibuat berdasarkan jam, minggu, atau bulan.
Batas dalam error budget tersebut menunjukkan seberapa besar kegagalan yang masih dapat ditoleransi.
Target tersebut kemudian perlu disepakati dengan tim terkait. Tim Engineering, operasional, SRE, dan bisnis perlu memahami tanggung jawab masing-masing. SLO juga perlu ditinjau secara berkala. Perubahan arsitektur, jumlah pengguna, dan pola trafik dapat mengubah kebutuhan reliability.
Baca Juga: Mean Time to Repair (MTTR): Cara Menghitung dan MenguranginyaPlatform monitoring bekerja dengan mengambil data dari aplikasi dan layanan yang dipantau. Data tersebut kemudian digunakan sebagai dasar pengukuran SLI. Sistem membandingkan nilai aktual dengan target SLO. Hasilnya dapat ditampilkan dalam dashboard untuk membantu tim melihat kondisi layanan.
Platform juga bisa memantau error budget dan burn rate. Burn rate menunjukkan seberapa cepat toleransi kegagalan digunakan. Ketika konsumsi error budget meningkat terlalu cepat, sistem bisa menghasilkan alert. Pendekatan ini membantu tim menangani risiko sebelum target benar-benar dilanggar.
Selain itu, SLO monitoring juga dapat dikaitkan dengan masalah aplikasi. Tim dapat menghubungkan penurunan SLO dengan insiden, service, atau dependency yang terdampak.
Pencapaian SLO membutuhkan visibilitas terhadap kondisi aplikasi secara aktual. Application Performance Monitoring dapat membantu tim memantau performa aplikasi dan menemukan masalah sebelum berdampak lebih luas.
Phintraco Technology menyediakan solusi application performance monitoring untuk memantau performa aplikasi secara real-time. Platform ini dapat membantu tim Anda mengidentifikasi dan menyelesaikan masalah sebelum memengaruhi pengguna.
Solusi kami juga mendukung SLO melalui evaluasi otomatis, visualisasi SLI, error budget, dan burn rate. Data ini dapat membantu tim Anda memahami kondisi reliability dalam konteks layanan yang sebenarnya.
Untuk informasi selengkapnya, hubungi marketing@phintraco.com sekarang!
Editor: Trie Ayu Feminin dan Irnadia Fardila

Penggunaan Kubernetes semakin luas untuk menjalankan aplikasi berbasis container. Kubernetes monitoring membantu tim IT memantau kesehatan, performa, dan penggunaan resource dalam cluster.
Lingkungan Kubernetes bersifat dinamis dan terdiri dari banyak komponen. Pod dapat dibuat, dihentikan, atau dipindahkan antar-node. Kondisi tersebut membuat visibilitas menjadi penting untuk menjaga performa dan availability aplikasi. Artikel ini akan membahas pemantauan Kubernetes, indikator-indikatornya, cara kerjanya, dan manfaatnya.
Kubernetes Monitoring adalah proses mengumpulkan dan menganalisis data dari lingkungan Kubernetes. Data tersebut mencakup kesehatan cluster, performa aplikasi, dan penggunaan resource. Monitoring dapat mencakup node, pod, container, dan aplikasi. Tim IT juga dapat memantau komponen control plane serta komunikasi antar-service.
Penggunaan Kubernetes monitoring tools juga membantu mengumpulkan dan menampilkan data tersebut. Tools dapat berupa Kubernetes Dashboard, Prometheus, Grafana, atau platform observability lainnya.
Data monitoring kemudian dapat ditampilkan melalui Kubernetes monitoring dashboard. Dashboard membantu tim melihat kondisi cluster, penggunaan resource, status workload, dan alert.
Monitoring juga membantu menemukan masalah lebih awal. Contohnya adalah pod yang gagal berjalan, penggunaan memory berlebihan, atau node yang tidak tersedia. Namun, monitoring tidak berhenti pada status komponen. Data dari aplikasi dan infrastructure juga perlu dilihat dalam satu konteks.
Lingkungan Kubernetes memiliki berbagai lapisan yang saling berkaitan. Setiap lapisan membutuhkan indikator yang sesuai. Berikut adalah masing-masing penjelasannya:
Tim IT perlu memantau availability dan kondisi setiap node. CPU, memory, storage, bandwidth, dan kapasitas juga perlu diperhatikan. Komponen control plane juga penting untuk dipantau. API server, kubelet, kube-proxy, etcd, dan controller manager mendukung operasional cluster.
Status pod dapat menunjukkan kondisi workload. Perhatikan jumlah pod, status, serta frekuensi restart. Pod yang sering restart dapat menunjukkan masalah aplikasi atau resource. Status pending atau failed juga perlu segera diperiksa.
Container monitoring memantau penggunaan CPU dan memory setiap container. CPU throttling dan penggunaan memory berlebih dapat memengaruhi stabilitas workload.
Network monitoring membantu melihat trafik dan error antar-service. Gangguan jaringan dapat memengaruhi komunikasi antar-container dan performa aplikasi.
Metrik aplikasi mencakup latency, response time, error rate, dan responsiveness. Data ini membantu menghubungkan kondisi Kubernetes dengan performa yang dirasakan oleh pengguna.
Logs dan events memberikan konteks mengenai kejadian dalam cluster. Traces membantu mengikuti transaksi pada aplikasi terdistribusi. Beberapa layanan monitoring dapat menggabungkan metrics, logs, dan traces dalam satu platform untuk memberikan visibilitas end-to-end.
Proses dimulai dengan mengumpulkan data dari berbagai komponen Kubernetes. Agent atau integrasi dapat mengambil data dari node, pod, container, dan aplikasi. Data kemudian dikumpulkan dan dianalisis. Metadata serta label yang konsisten membantu tim menemukan workload tertentu dengan lebih mudah.
Sistem monitoring dapat menjalankan alert berdasarkan kondisi tertentu. Contohnya adalah penggunaan CPU atau memory yang melewati batas. Intelligent alerting dapat membantu mengurangi alert fatigue. Setelah alert muncul, tim melakukan investigasi. Metrik, logs, events, dan traces dapat digunakan untuk mencari sumber masalah. Platform modern juga dapat menggunakan AI untuk membantu analisis.
Tahap berikutnya adalah respons dan optimasi. Tim dapat melakukan scaling, memperbaiki konfigurasi, atau menjalankan tindakan otomatis.
Monitoring Kubernetes memberikan manfaat pada performa, reliability, dan efisiensi operasional. Berikut adalah beberapa manfaat utamanya untuk bisnis:
Monitoring membantu menemukan pod, node, atau resource yang bermasalah. Deteksi lebih awal dapat mengurangi dampak terhadap layanan.
Data CPU, memory, storage, dan network membantu menemukan resource yang kurang atau berlebihan. Informasi ini mendukung keputusan scaling dan capacity planning.
Korelasi data membantu tim melihat hubungan antara infrastruktur dan aplikasi. Investigasi menjadi lebih terarah ketika berbagai sinyal tersedia dalam satu konteks.
Alert membantu tim mengetahui masalah sebelum berkembang menjadi gangguan besar. Respons lebih cepat dapat membantu menjaga kontinuitas layanan.
Data historis membantu perusahaan memahami pola penggunaan resource. Informasi ini dapat digunakan untuk merencanakan kapasitas cluster.
Monitoring memberikan visibilitas dari cluster hingga aplikasi. Platform dapat menggabungkan telemetry untuk membantu tim memahami performa dan dependency.
Phintraco Technology menyediakan solusi application performance monitoring untuk melihat performa aplikasi, transaksi, infrastructure, dan cloud dalam satu konteks. Platform kami juga dapat menemukan dependency secara otomatis dan melacak transaksi lintas berbagai layer.
Untuk Kubernetes, solusi monitoring kami menggabungkan metrics, logs, traces, topology, dan analisis berbasis AI. Pendekatan ini membantu tim Anda menemukan masalah dan memahami dampaknya terhadap aplikasi.
Dengan observability yang terintegrasi, Anda dapat memantau workload Kubernetes secara menyeluruh. Tim juga dapat mempercepat troubleshooting dan mendukung optimasi performa aplikasi.
Untuk informasi selengkapnya, hubungi marketing@phintraco.com sekarang!
Editor: Trie Ayu Feminin dan Irnadia Fardila

Aplikasi modern banyak menggunakan microservices, API, container, dan layanan cloud. Distributed tracing membantu tim mengikuti perjalanan satu request melalui berbagai komponen aplikasi.
Arsitektur yang terdistribusi membuat pencarian sumber masalah semakin kompleks. Satu permintaan dapat melewati banyak layanan sebelum menghasilkan respons. Tracing membantu menemukan layanan yang menyebabkan latency, error, atau bottleneck. Artikel ini akan membahas distributed tracing beserta cara kerja dan manfaatnya.
Distributed tracing adalah teknik untuk melacak perjalanan request dalam sistem terdistribusi. Setiap transaksi dapat diberi identitas agar perjalanannya dapat diikuti dari awal hingga akhir. Pendekatan ini sangat berguna dalam arsitektur microservices. Setiap layanan dapat menjalankan fungsi tertentu dan berkomunikasi melalui API.
Dalam lingkungan seperti ini, distributed tracing services membantu tim melihat hubungan antar-service. Tim dapat mengetahui layanan mana yang menerima request dan waktu yang digunakan untuk setiap proses.
Trace menggambarkan keseluruhan perjalanan sebuah request. Sementara itu, span menunjukkan satu aktivitas selama perjalanan tersebut. Contohnya adalah pemanggilan API atau query database.
Setiap request dapat memiliki trace ID yang sama. ID tersebut diteruskan ketika permintaan berpindah antar-service. Mekanisme ini menjaga hubungan antarspan tetap terhubung.
Dengan demikian, tim dapat melihat perjalanan transaksi secara end-to-end. Data tracing juga dapat dikombinasikan dengan metrik dan log untuk memperoleh konteks yang lebih lengkap.
Proses dimulai dengan instrumentation pada aplikasi. Instrumentasi memungkinkan sistem menangkap aktivitas request yang melewati berbagai layanan. Ketika pengguna mengirim request, sistem membuat atau menerima trace ID. ID tersebut diteruskan ke layanan berikutnya selama transaksi berlangsung.
Setiap layanan kemudian menghasilkan span. Span mencatat informasi seperti waktu mulai, durasi, status, dan metadata tertentu. Semua span dikumpulkan dan disusun menjadi satu trace. Tim kemudian dapat melihat urutan layanan yang dilalui oleh sebuah permintaan.
Jika transaksi berjalan lambat, tim dapat memeriksa durasi setiap span. Bagian dengan durasi tinggi dapat menjadi indikasi adanya bottleneck.
Distributed tracing system juga dapat menghubungkan trace dengan metrik dan log. Korelasi tersebut membantu tim melihat konteks masalah secara lebih menyeluruh. Namun, instrumentasi perlu diterapkan secara konsisten. Inkonsistensi dapat menyebabkan sebagian perjalanan transaksi tidak terlacak.
Application monitoring memiliki cakupan yang lebih luas. APM digunakan untuk memantau performa aplikasi, availability, response time, dan berbagai data telemetri.
Distributed tracing memiliki fokus yang lebih spesifik. Teknologi ini mengikuti satu request saat melewati beberapa service atau komponen. Sementara itu, APM dapat menjawab pertanyaan tentang kondisi aplikasi secara umum. Contohnya, apakah response time meningkat atau error rate bertambah.
Distributed tracing membantu menjawab penyebab masalah tersebut, sehingga tim dapat melihat service mana yang memperlambat atau menggagalkan transaksi.
Keduanya dapat digunakan secara bersamaan. APM bisa memberi gambaran dari atas, sedangkan tracing memberikan detail perjalanan transaksi.
Baca Juga: Root Cause Analysis: Metode Efisien Pecahkan Masalah Sistem ITDistributed tracing dapat memberikan manfaat terutama pada aplikasi yang memiliki banyak service dan dependency. Berikut adalah beberapa manfaat utamanya:
Tracing menunjukkan layanan yang membutuhkan waktu paling lama. Tim dapat menentukan bagian yang perlu diperiksa lebih lanjut.
Tim dapat mengikuti satu transaksi dari awal hingga akhir. Proses ini membantu mempersempit sumber error tanpa perlu memeriksa semua komponen secara manual sehingga mempercepat MTTR.
Tracing menunjukkan hubungan antara service, API, database, dan komponen lainnya. Informasi tersebut membantu memahami dampak gangguan pada satu layanan.
Tim dapat melihat perjalanan request secara menyeluruh. Pendekatan ini memberikan konteks yang sulit diperoleh melalui monitoring komponen secara terpisah.
Trace memberikan detail mengenai durasi dan status setiap span. Data tersebut membantu tim menemukan lokasi masalah dengan lebih cepat.
Data historis dapat menunjukkan pola latency dan error. Tim dapat menggunakan informasi tersebut untuk menentukan prioritas optimasi.
Tracing dapat dikombinasikan dengan log dan metrik. Korelasi tersebut memberikan konteks tambahan untuk investigasi observabilitas performa.
Phintraco Technology menyediakan solusi Application Performance Monitoring untuk memantau performa aplikasi menggunakan berbagai data telemetri. Platform ini mencakup aplikasi, service, host, jaringan, log, dan komponen pendukung lainnya.
Solusi kami juga mendukung distributed tracing untuk mengikuti transaksi pada aplikasi terdistribusi. Kemampuan tersebut membantu tim memahami dependency dan lokasi masalah dalam perjalanan request.
Untuk informasi selengkapnya, hubungi marketing@phintraco.com sekarang!
Editor: Trie Ayu Feminin dan Irnadia Fardila