Jika proxy digunakan dalam produksi — untuk parsing, otomatisasi akun SMM, atau multi-akuntansi skala besar — cepat atau lambat akan tiba saatnya ketika "sepertinya berfungsi" tidak lagi menjadi jawaban yang cukup. Angka-angka dibutuhkan: berapa banyak permintaan yang gagal dengan kesalahan, seberapa besar latensi meningkat setelah mengganti kumpulan IP, apakah batas lalu lintas dari penyedia sudah habis. Mari kita bahas 7 metrik yang perlu dikumpulkan di Prometheus dan divisualisasikan di Grafana, agar dapat melihat masalah lebih awal sebelum pengguna atau akun yang diblokir menyadarinya.
Mengapa perlu memantau proxy dalam produksi
Proxy bukanlah infrastruktur statis seperti server dengan IP tetap. Ini adalah kumpulan alamat yang terus berubah, perilakunya tergantung pada penyedia, beban, wilayah, dan bahkan waktu dalam sehari. Tanpa pemantauan, Anda hanya akan mengetahui masalah ketika parser Wildberries atau Ozon berhenti memberikan data, akun Facebook Ads diblokir, atau skrip otomatisasi Instagram mulai mengeluarkan captcha.
Tugas pemantauan adalah mengubah "ada yang tidak beres" yang subjektif menjadi angka konkret: proporsi kesalahan meningkat dari 2% menjadi 15% dalam satu jam terakhir, latensi rata-rata meningkat tiga kali lipat, lalu lintas melalui satu proxy melebihi batas. Ini memungkinkan untuk merespons sebelum masalah menjadi kritis — secara otomatis beralih ke kumpulan lain, mengganti penyedia, atau mengurangi frekuensi permintaan.
Untuk mengumpulkan metrik, kita menggunakan kombinasi Prometheus (penyimpanan deret waktu) + Grafana (visualisasi dan peringatan). Ini adalah tumpukan standar dalam DevOps yang mudah diintegrasikan dengan bahasa apa pun — Python, Node.js, Go. Di bawah ini adalah contoh dalam Python dengan pustaka prometheus_client, tetapi prinsipnya bersifat universal.
Metrik 1: Tingkat Keberhasilan — proporsi permintaan yang berhasil
Ini adalah metrik dasar yang pertama kali memberi sinyal tentang masalah dengan kumpulan proxy. Dihitung sebagai rasio permintaan dengan kode respons 200-299 terhadap total jumlah permintaan dalam periode waktu tertentu. Penurunan tingkat keberhasilan di bawah 90% biasanya berarti bahwa sebagian IP dalam kumpulan diblokir oleh situs target atau penyedia memberikan alamat yang tidak stabil.
Contoh instrumentasi dalam Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Total permintaan melalui proxy',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # endpoint untuk Prometheus scrape
Kuery PromQL untuk menghitung tingkat keberhasilan dalam 5 menit terakhir:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Jika Anda bekerja dengan beberapa jenis proxy secara bersamaan — misalnya, proxy residensial untuk media sosial dan proxy pusat data untuk parsing — ada baiknya memecah tingkat keberhasilan berdasarkan label proxy_pool, untuk melihat kumpulan mana yang mengalami penurunan.
Metrik 2: Latensi — keterlambatan respons
Latensi menunjukkan seberapa cepat proxy memberikan respons. Lonjakan latensi yang tajam sering kali mendahului penurunan tingkat keberhasilan — penyedia kelebihan beban, atau IP sudah dekat dengan pemblokiran dan server target mulai sengaja memperlambat respons. Untuk latensi, penting untuk mengumpulkan tidak hanya nilai rata-rata, tetapi juga persentil — p50, p95, p99, karena rata-rata menyembunyikan latensi ekor yang benar-benar mengganggu kinerja.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Durasi permintaan melalui proxy',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
PromQL untuk p95 latensi:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Untuk tugas di mana kecepatan sangat penting — misalnya, saat otomatisasi TikTok Ads, di mana setiap detik untuk memuat halaman meningkatkan risiko timeout di browser anti-deteksi — sebaiknya atur peringatan jika p95 lebih dari 3-4 detik.
Metrik 3: Tingkat Kesalahan berdasarkan jenis kesalahan
Sukses/gagal saja tidak cukup untuk diagnosis. Perlu memisahkan kesalahan berdasarkan jenis: 407 (Proxy Authentication Required) berarti masalah dengan otorisasi, 429 (Too Many Requests) — melebihi batas permintaan, timeout — masalah jaringan, 403 — pemblokiran oleh perlindungan anti-bot situs target. Setiap jenis kesalahan memerlukan respons yang berbeda.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Kesalahan proxy berdasarkan jenis',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
Tabel kesalahan umum dan penyebabnya:
| Kode/jenis | Penyebab yang mungkin | Apa yang perlu diperiksa |
|---|---|---|
| 407 | Kredensial salah atau sesi telah kedaluwarsa | Login/kata sandi proxy, format string koneksi |
| 429 | Batas permintaan pada IP terlampaui | Frekuensi permintaan, ukuran kumpulan |
| 403 | Perlindungan anti-bot situs target | User-Agent, sidik jari, jenis proxy |
| timeout | Kelebihan beban penyedia atau jaringan | Beban pada kumpulan, pengaturan timeout klien |
Metrik 4: Kecepatan rotasi dan ketahanan IP
Jika Anda menggunakan proxy yang berputar, penting untuk mengetahui seberapa sering IP berubah dan berapa banyak permintaan yang dapat dilakukan sebelum alamat "hangus" (diblokir oleh situs target). Metrik ini sangat kritis untuk multi-akuntansi — misalnya, saat mengelola akun Facebook Ads melalui Dolphin Anty atau AdsPower, di mana perubahan IP yang prematur dapat memutus sesi dan memicu pemeriksaan keamanan.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Waktu hidup IP sebelum rotasi',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Berapa banyak permintaan yang dilakukan sebelum IP diblokir',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Untuk proxy seluler, metrik ini berperilaku berbeda dibandingkan dengan proxy residensial — rotasi melalui perubahan stasiun dasar operator memberikan IP yang lebih "bersih" dengan kemungkinan pemblokiran yang lebih rendah. Jika tugas Anda adalah otomatisasi SMM dengan sensitivitas tinggi terhadap pemblokiran, sebaiknya bandingkan indikator ketahanan IP antara proxy seluler dan residensial berdasarkan data nyata dari dasbor Anda, bukan hanya mengandalkan rekomendasi umum.
Metrik 5: Bandwidth — konsumsi lalu lintas
Sebagian besar tarif untuk proxy dihitung berdasarkan volume lalu lintas, bukan jumlah permintaan. Tanpa pemantauan, mudah untuk melewatkan saat batas hampir habis — terutama jika tugas melibatkan pengunduhan gambar atau video, misalnya saat parsing kartu produk Wildberries dengan banyak foto.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Lalu lintas yang digunakan melalui proxy',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
Di dasbor Grafana, berguna untuk membangun bukan nilai absolut dari lalu lintas, tetapi kecepatan pengeluarannya (rate) — ini membantu memprediksi kapan batas akan habis, dan merencanakan pembelian tambahan atau beralih ke kumpulan lain.
Metrik 6: Geo-distribusi dan kesesuaian dengan wilayah
Bagi pemasar yang menguji iklan dari berbagai negara, dan bagi arbitrase yang bekerja dengan geo-targeting di Google Ads atau TikTok Ads, sangat penting agar IP benar-benar sesuai dengan wilayah yang dinyatakan. Kesalahan geolokasi dapat menyebabkan iklan ditampilkan kepada audiens yang salah atau pemblokiran akun karena ketidakcocokan pengaturan geo.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Kasus ketidakcocokan antara geo yang dinyatakan dan yang sebenarnya',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
Disarankan untuk memeriksa geo tidak pada setiap permintaan (ini mahal dalam hal lalu lintas dan waktu), tetapi secara berkala — sekali per jam pada sampel IP dari kumpulan yang cukup untuk keyakinan statistik.
Metrik 7: Koneksi Bersamaan — sesi paralel
Jumlah koneksi bersamaan melalui proxy menunjukkan beban nyata pada kumpulan. Jika sesi paralel lebih banyak daripada IP dalam kumpulan yang dapat diproses tanpa penurunan, ini secara langsung menyebabkan peningkatan latensi dan tingkat kesalahan dari poin sebelumnya. Metrik ini sangat penting saat melakukan skala — ketika agensi SMM meningkatkan jumlah akun klien yang aktif dari 10 menjadi 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Koneksi aktif saat ini melalui proxy',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
Memadukan metrik ini dengan tingkat kesalahan pada satu grafik di Grafana dengan cepat menunjukkan korelasi: begitu jumlah sesi paralel melebihi ambang batas tertentu, kesalahan mulai meningkat secara non-linear.
Pengaturan dasbor di Grafana: langkah demi langkah
Setelah metrik diinstrumentasi dan Prometheus mengumpulkannya, perlu untuk memvisualisasikan data di Grafana. Urutan langkah-langkahnya:
- Tambahkan Prometheus sebagai sumber data: Konfigurasi → Sumber Data → Tambah sumber data → Prometheus, masukkan URL server Prometheus Anda (biasanya
http://localhost:9090). - Buat dasbor baru: Buat → Dasbor → Tambah panel baru.
- Untuk panel Tingkat Keberhasilan, gunakan kuery PromQL dari bagian tentang metrik 1, jenis visualisasi — Gauge atau Time series.
- Untuk Latensi, buat panel dengan jenis Heatmap, untuk melihat distribusi p50/p95/p99 seiring waktu.
- Untuk Tingkat Kesalahan, buat Stacked Bar Chart dengan pemecahan berdasarkan label
error_type— ini akan menunjukkan dengan jelas jenis kesalahan mana yang mendominasi. - Tambahkan variabel dasbor (Pengaturan Dasbor → Variabel) untuk
proxy_pool, untuk beralih antara kumpulan tanpa membuat dasbor terpisah. - Simpan dasbor dan atur pembaruan otomatis setiap 30 detik untuk pemantauan hampir waktu nyata.
JSON dasbor yang siap pakai dapat diekspor melalui Share → Ekspor → Simpan ke file dan digunakan kembali untuk berbagai kumpulan proxy — residensial, seluler, dan pusat data, hanya mengubah nilai variabel.
Peringatan: kapan saatnya bertindak
Dasbor tidak berguna jika tidak ada yang melihatnya saat insiden terjadi. Oleh karena itu, sangat penting untuk mengatur peringatan di Grafana (Peringatan → Aturan Peringatan) dengan nilai ambang berikut, yang dipilih untuk sebagian besar skenario produksi:
| Metrik | Ambang Peringatan | Tindakan |
|---|---|---|
| Tingkat Keberhasilan | di bawah 85% dalam 5 menit | Periksa kumpulan, beralih ke cadangan |
| p95 Latensi | di atas 5 detik | Kurangi paralelisme, periksa penyedia |
| Tingkat 429 | di atas 10% permintaan | Kurangi frekuensi permintaan, tingkatkan kumpulan IP |
| Tingkat Bandwidth | peramalan kehabisan batas dalam 24 jam | Beli lebih banyak lalu lintas atau optimalkan permintaan |
Peringatan sebaiknya diarahkan ke Telegram atau Slack melalui webhook — ini memastikan respons instan, bukan pemeriksaan dasbor sekali sehari.
Kesimpulan
Tujuh metrik — tingkat keberhasilan, latensi, tingkat kesalahan berdasarkan jenis, ketahanan IP, lalu lintas, kesesuaian geo, dan koneksi bersamaan — memberikan gambaran lengkap tentang kesehatan infrastruktur proxy dalam produksi. Kombinasi Prometheus + Grafana memungkinkan tidak hanya untuk mencatat masalah setelah fakta, tetapi juga untuk melihat tren dan merespons sebelum penurunan kumpulan menyebabkan pemblokiran akun atau penghentian parsing.
Pemilihan jenis proxy secara langsung mempengaruhi metrik mana yang akan diprioritaskan: untuk tugas dengan sensitivitas tinggi terhadap pemblokiran, seperti multi-akuntansi di Instagram atau TikTok, sebaiknya memantau ketahanan IP dan tingkat keberhasilan terlebih dahulu, menggunakan proxy residensial untuk kesamaan maksimum dengan lalu lintas nyata pengguna. Untuk tugas di mana kecepatan dan volume penting — parsing massal Ozon, Avito, atau Yandex.Market — latensi dan bandwidth menjadi prioritas, dan di sini seringkali proxy pusat data bekerja lebih efektif karena kapasitas yang lebih tinggi.