Ketersediaan API dari Berbagai Negara: 5 Metrik yang Hanya Terlihat oleh IP Eksternal

Jika pemantauan API Anda berjalan di server di satu pusat data, Anda hanya melihat sebagian dari gambaran. Pengguna dari Brasil mungkin menerima kesalahan 500, sementara dasbor Anda di Moskow menunjukkan status hijau "semua berfungsi". Mari kita bahas 5 metrik ketersediaan yang tidak dapat diukur tanpa permintaan melalui IP eksternal nyata dari negara lain, dan bagaimana melakukannya tanpa infrastruktur yang rumit.

Mengapa pemantauan lokal menipu

Sebagian besar tim mengatur pemantauan API melalui UptimeRobot, Pingdom, atau skrip cron mereka sendiri yang mengakses endpoint setiap menit. Masalahnya adalah bahwa permintaan ini hampir selalu berasal dari satu atau dua wilayah — biasanya dari AS atau Eropa, di mana server layanan pemantauan berada. Jika audiens Anda berada di India, Brasil, atau Asia Tenggara, penyedia lokal mungkin memotong lalu lintas, node CDN mungkin mengalami kelebihan beban, dan DNS mungkin meresolusi ke IP yang sudah usang.

Skenario umum lainnya adalah geo-blocking di tingkat CDN atau WAF (Cloudflare, Akamai). Beberapa aturan keamanan memblokir seluruh rentang IP dari negara tertentu, dan API Anda secara fisik tidak dapat diakses oleh sebagian pengguna, meskipun dari IP kantor Anda semuanya berfungsi dengan baik. Masalah semacam ini tidak dapat didiagnosis jika hanya menguji dari satu titik.

Skenario ketiga adalah penyeimbangan beban melalui Anycast atau edge CDN regional. Permintaan dari Jerman dapat masuk ke satu node, sementara dari Singapura — ke node yang sama sekali berbeda, dengan versi cache atau konfigurasi yang berbeda. Perbedaan perilaku API antara wilayah adalah kenyataan, bukan teori, dan ini adalah hal yang sering dihadapi oleh tim yang memiliki pengguna tersebar di seluruh dunia.

5 metrik ketersediaan yang hanya terlihat melalui IP eksternal

Berikut adalah lima metrik yang menunjukkan gambaran nyata ketersediaan hanya ketika permintaan dilakukan dari alamat IP yang secara fisik berada di negara target atau setidaknya dirouting melalui jaringannya.

1. Waktu respons (Latency / RTT)

Round-Trip Time — waktu dari pengiriman permintaan hingga penerimaan paket pertama dari respons. Dari satu server di Eropa, latensi ke API Anda bisa 20 ms, sementara pengguna dari Asia Tenggara akan menunggu 400-600 ms karena jarak geografis dan jumlah node perantara (hops). Jika tidak mengukur latensi dari berbagai wilayah, mudah untuk melewatkan saat ketika layanan menjadi hampir tidak dapat digunakan untuk sebagian audiens — terutama kritis untuk API yang terikat pada operasi real-time: bidding dalam iklan, obrolan, transaksi fintech.

2. TTFB (Time To First Byte)

TTFB menunjukkan berapa lama server memproses permintaan sebelum mulai mengirim respons. Metrik ini bergantung tidak hanya pada jaringan, tetapi juga pada node CDN atau load balancer mana yang melayani wilayah tertentu. Seringkali, server edge di satu negara meng-cache respons dan mengirimkannya dalam 50 ms, sementara di negara lain permintaan setiap kali mencapai server origin dan diproses ulang, memakan waktu 800 ms atau lebih. Perbedaan dalam TTFB antara wilayah adalah tanda pasti masalah dengan konfigurasi CDN atau kurangnya cakupan node edge.

3. Waktu resolusi DNS

Resolusi DNS adalah sumber keterlambatan dan kesalahan yang terpisah, yang sepenuhnya bergantung pada resolver lokal pengguna. Jika Anda telah mengatur GeoDNS (catatan A yang berbeda tergantung pada wilayah permintaan), kesalahan dalam konfigurasi dapat menyebabkan pengguna dari satu negara meresolusi ke pusat data di benua lain — dengan keterlambatan yang besar. Masalah ini hanya terlihat saat permintaan resolusi DNS dilakukan dari IP nyata di negara target, pengujian lokal selalu akan meresolusi "dengan benar" relatif terhadap posisi geografis Anda sendiri.

4. Persentase permintaan yang berhasil (Uptime) berdasarkan wilayah

Uptime 99.9% di dasbor pemantauan yang mengakses dari satu titik tidak menjamin 99.9% untuk pengguna di negara lain. Penyedia lokal mungkin mengalami masalah dengan peering khusus ke penyedia hosting Anda, sehingga sebagian permintaan dari negara X akan timeout, sementara sisa dunia tidak menyadari masalah tersebut. Untuk melihat uptime yang sebenarnya, perlu menghitung permintaan yang berhasil dan tidak berhasil secara terpisah untuk setiap wilayah, bukan secara agregat.

5. Perbedaan dalam konten dan kode status (geo-blocking dan personalisasi)

Metrik kelima bukan tentang kecepatan, tetapi tentang konten respons itu sendiri. API dapat mengembalikan 403 Forbidden untuk negara tertentu karena aturan WAF, mengembalikan kumpulan data yang dipotong karena batasan lisensi, atau menunjukkan versi konten yang berbeda karena A/B testing yang terikat pada geo. Jika menguji API hanya dari IP Anda sendiri, perbedaan semacam ini akan tetap sepenuhnya tidak terdeteksi — dan inilah yang sering menjadi penyebab keluhan dari pengguna di wilayah tertentu.

Cara mengatur pemantauan dari berbagai negara

Logika pengaturannya sederhana: Anda mengirimkan permintaan HTTP yang sama ke API Anda dari beberapa titik secara bersamaan, mencatat semua lima metrik dan membandingkan hasilnya. Langkah-langkahnya terlihat seperti ini:

1. Buat daftar negara prioritas — biasanya ini adalah 5 negara teratas berdasarkan volume lalu lintas atau pendapatan.
2. Untuk setiap negara, siapkan titik keluar dengan IP nyata dari negara tersebut (proxy server atau server fisik).
3. Atur skrip atau layanan yang mengirimkan permintaan identik melalui setiap titik dengan interval yang ditentukan (misalnya, setiap 5 menit).
4. Log semua 5 metrik secara terpisah untuk setiap negara ke database atau sistem metrik (Grafana, Prometheus, ClickHouse).
5. Atur alert untuk penyimpangan metrik dari level dasar — misalnya, jika latensi dari negara tertentu meningkat 3 kali lipat dalam satu jam.

Poin kunci adalah tepat di langkah 2. Tanpa keluar nyata ke negara yang diinginkan, semua langkah lainnya menjadi tidak berarti, karena metrik akan mengukur bukan apa yang dilihat pengguna, tetapi apa yang dilihat oleh server pemantauan Anda sendiri.

Jenis proxy mana yang harus dipilih untuk pemantauan

Untuk membangun pemantauan yang terdistribusi secara geografis, biasanya digunakan proxy server — ini lebih murah dan lebih cepat daripada menyewa server fisik atau VPS di setiap negara yang diperlukan. Pilihan jenis proxy tergantung pada apa yang ingin Anda ukur.

Jenis Proxy	Kapan digunakan	Fitur
Proxy pusat data	Pemeriksaan dasar ketersediaan dan latensi, ketika tidak perlu meniru pengguna nyata	Kecepatan tinggi, harga rendah, tetapi IP mudah dikenali sebagai IP pusat data — tidak cocok untuk pengujian geo-blocking berdasarkan penyedia
Proxy residensial	Memeriksa apa yang dilihat pengguna nyata dengan penyedia rumah	IP milik penyedia nyata di negara tertentu, lebih akurat mencerminkan routing dan aturan WAF
Proxy seluler	Uji ketersediaan API untuk aplikasi seluler dan lalu lintas seluler	IP dari jaringan operator seluler, menunjukkan latensi dan pemblokiran yang spesifik untuk lalu lintas seluler

Jika API Anda sebagian besar melayani lalu lintas web dari desktop dan server, untuk membangun pemantauan dasar, cukup gunakan proxy pusat data — mereka memberikan kecepatan yang stabil dan latensi yang dapat diprediksi. Namun, jika Anda perlu memeriksa apa yang dihadapi pengguna nyata — termasuk aturan geo-blocking yang diatur berdasarkan ASN penyedia — sebaiknya gunakan proxy residensial, karena mereka dirouting melalui jaringan penyedia internet biasa di negara yang sama. Untuk aplikasi seluler dan SDK yang melakukan permintaan ke API, masuk akal untuk menambahkan pemeriksaan melalui proxy seluler, karena operator seluler sering menggunakan NAT dan aturan routing mereka sendiri yang berbeda dari internet rumah.

Skrip siap pakai dalam Python untuk mengumpulkan metrik

Berikut adalah contoh skrip sederhana yang mengirimkan permintaan melalui proxy di negara yang ditentukan dan mengumpulkan empat dari lima metrik (perbedaan konten perlu dibandingkan secara terpisah, mencocokkan respons). Skrip ini menggunakan pustaka requests dan modul socket untuk mengukur waktu resolusi DNS.

import time
import socket
import requests

def measure_api(url, proxy, country_label):
    hostname = url.split("//")[1].split("/")[0]

    # 1. Waktu resolusi DNS
    dns_start = time.time()
    try:
        socket.gethostbyname(hostname)
    except socket.gaierror:
        pass
    dns_time = time.time() - dns_start

    proxies = {
        "http": proxy,
        "https": proxy,
    }

    try:
        start = time.time()
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10,
            stream=True
        )
        ttfb = time.time() - start  # TTFB yang mendekati

        full_load_time = time.time() - start
        status_code = response.status_code
        success = status_code == 200

        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": round(ttfb * 1000, 2),
            "total_time_ms": round(full_load_time * 1000, 2),
            "status_code": status_code,
            "success": success,
        }
    except requests.exceptions.RequestException as e:
        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": None,
            "total_time_ms": None,
            "status_code": None,
            "success": False,
            "error": str(e),
        }

    return result


# Contoh penggunaan dengan proxy dari berbagai negara
endpoints = [
    {"label": "Germany", "proxy": "http://user:[email protected]:port"},
    {"label": "Brazil", "proxy": "http://user:[email protected]:port"},
    {"label": "Singapore", "proxy": "http://user:[email protected]:port"},
]

API_URL = "https://api.yourservice.com/health"

for ep in endpoints:
    data = measure_api(API_URL, ep["proxy"], ep["label"])
    print(data)

Untuk versi produksi dari skrip semacam ini, sebaiknya tambahkan pencatatan hasil ke database (misalnya, ClickHouse atau InfluxDB), visualisasi melalui Grafana, dan alert melalui bot Telegram atau webhook Slack saat nilai ambang terlampaui. Jalankan skrip lebih baik melalui cron atau penjadwal tugas dengan interval 5-15 menit untuk setiap negara.

Jika Anda memerlukan pemeriksaan cepat tanpa menulis kode, permintaan serupa dapat dilakukan melalui cURL dengan pengukuran waktu:

curl -x http://user:[email protected]:port \
  -o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
  https://api.yourservice.com/health

Cara menginterpretasikan hasil

Setelah mengumpulkan data dari semua negara selama setidaknya seminggu, akan muncul level dasar (baseline) untuk setiap wilayah. Selanjutnya, Anda perlu melihat bukan pada angka absolut, tetapi pada penyimpangan dari baseline ini. Jika latensi dari Brasil stabil di level 350 ms — itu normal untuk geografi, dan alarm harus dibangkitkan jika nilai tiba-tiba meningkat menjadi 1500 ms. Hal yang sama berlaku untuk uptime: 99.5% untuk wilayah yang sulit dengan internet yang tidak stabil bisa menjadi norma yang dapat diterima, sementara penurunan hingga 95% sudah menjadi sinyal masalah di pihak penyedia atau CDN.

Perhatian khusus harus diberikan pada kode status 403 dan 451 — mereka hampir selalu menunjukkan adanya geo-blocking dari WAF atau CDN, bukan masalah dengan API itu sendiri. Jika kode semacam ini muncul hanya dari negara tertentu dan hanya saat menggunakan proxy dari jenis tertentu (misalnya, pusat data), ini bisa berarti bahwa pemblokiran diatur berdasarkan kriteria "IP mirip dengan pusat data", bukan berdasarkan geolokasi yang sebenarnya — dalam hal ini, pengujian dengan proxy residensial akan memberikan gambaran yang lebih jujur.

Layanan siap pakai vs solusi buatan sendiri

Jika Anda tidak ingin mendukung skrip sendiri, ada layanan pemantauan sintetis siap pakai di pasar dengan titik kehadiran di berbagai negara: Pingdom, Uptrends, Site24x7, Checkly. Mereka menghilangkan kebutuhan untuk mengatur infrastruktur, tetapi biasanya dibatasi pada set lokasi tetap dan tidak memberikan fleksibilitas dalam memilih jenis IP (residensial, seluler, pusat data) untuk pengujian tertentu.

Solusi buatan sendiri berbasis proxy memberikan lebih banyak kontrol: Anda dapat menguji negara yang benar-benar penting untuk bisnis Anda, beralih antara jenis IP untuk mendiagnosis masalah tertentu (misalnya, geo-blocking berdasarkan ASN), dan mengintegrasikan metrik langsung ke dalam sistem pemantauan Anda tanpa perantara yang tidak perlu. Kombinasi kedua pendekatan ini adalah keseimbangan yang bijak: layanan siap pakai untuk pemantauan SLA dasar, skrip buatan sendiri dengan proxy untuk diagnosis masalah yang tepat di wilayah tertentu.

Kesimpulan

Pemantauan lokal dari satu titik hanya menunjukkan sebagian dari kebenaran tentang ketersediaan API. Untuk melihat gambaran nyata, perlu mengukur latensi, TTFB, waktu resolusi DNS, uptime, dan perbedaan konten secara terpisah untuk setiap negara — dan melakukannya melalui IP yang benar-benar dirouting melalui jaringan wilayah target. Tanpa ini, mudah untuk melewatkan masalah yang menghalangi sebagian pengguna menggunakan layanan, sementara dasbor menunjukkan "semua hijau".

Untuk membangun pemantauan semacam ini, proxy residensial adalah yang terbaik jika penting untuk melihat apa yang dilihat pengguna nyata dengan internet rumah di negara tertentu. Untuk pemeriksaan ketersediaan dasar yang lebih murah dan lebih cepat, proxy pusat data sudah cukup, dan untuk diagnosis masalah yang dihadapi audiens seluler, sebaiknya tambahkan pemeriksaan melalui proxy seluler. Pendekatan kombinasi ini memberikan gambaran lengkap tentang bagaimana API Anda terlihat dari mana saja di dunia, bukan hanya dari server tempat ia dihosting.