O'tgan yil davomida men uchta jamoaga QueueMetrics'dan ko'chib chiqishda yordam berdim. Har safar sabab bir xil bo'ldi: jamoaga yangi odam qo'shildi, Tomcat konfiguratsiyasiga qaradi va "buni nima uchun ishlatib turibmiz?" deb so'radi.
Bu QueueMetrics'ni yerga urish emas. Bu mahsulot 2004-yildan beri Asterisk hamjamiyatiga xizmat qilib kelmoqda. Ammo yigirma yil davomida to'plangan Java bog'liqliklari, XML konfiguratsiya fayllari va polling asosidagi dashboardlar call-markaz rahbarlariga bugun kerak bo'lgan narsa bilan QueueMetrics jiddiy kuch sarflamasdan bera oladigan narsa o'rtasida tafovut hosil qildi.
Agar siz alternativalarni baholayotgan bo'lsangiz, mana men haqiqiy migratsiyalardan o'rgangan narsalarim — vendorlarning marketing bukletlaridan emas.
QueueMetrics aslida qayerda yetib bormaydi
Ko'pchilik taqqoslash maqolalari umumiy shikoyatlarni sanab o'tadi. Men migratsiyaga turtki beradigan aniq texnik cheklovlar haqida gapiraman.
Java muammosi haqiqiy
QueueMetrics Tomcat'da ishlaydi, ya'ni JDK, heap'ni ehtiyotkorlik bilan sozlash va garbage collection'ni muntazam kuzatib borish talab qilinadi. Analitika kerak bo'lgan call-markaz jamoasi uchun Java application server'ni saqlab turish — asosiy ishga hech qanday aloqasi bo'lmagan qo'shimcha yuk.
Odatdagi QueueMetrics server konfiguratsiyasi shunday ko'rinadi:
# /etc/default/tomcat9 - QueueMetrics xotirasini sozlash
JAVA_OPTS="-Djava.awt.headless=true -Xms512m -Xmx2048m -XX:+UseG1GC"QueueMetrics ajratilganidan ko'proq xotira iste'mol qila boshlaganda (va u boshlaydi — taxminan 80+ bir vaqtdagi operatorda), siz sekin dashboardlar, catalina.out'dagi OutOfMemoryError xatolari va "heap hajmini oshiring" degan javob bilan tugaydigan support ticket'ga ega bo'lasiz.
Mening fikrim: agar monitoring vositangizning o'ziga monitoring kerak bo'lsa, arxitekturada nimadir noto'g'ri ketgan. Call-markaz jamoasidan JVM bo'yicha ekspertiza talab qilinmasligi kerak.
Polling va real vaqt — bu marketing farqi emas
QueueMetrics queue_log jadvali yoki faylini sozlanadigan interval bilan o'qiydi — odatda har 5–30 soniyada. O'sha soniyalar davomida dashboardingiz eskirgan ma'lumotni ko'rsatib turadi.
Tarixiy hisobotlar uchun bu yetarli. Real vaqtdagi operativ qarorlar uchun esa yo'q.
30 soniyalik eskirgan ma'lumot amalda nimani anglatishini ko'ring:
| Vaziyat | 30 s kechikish oqibati |
|---|---|
| Navbat 2 tadan 15 ta qo'ng'iroqqa o'sdi | Supervizor o'sishni 30 s kech ko'radi, 4–5 mijoz allaqachon go'shakni qo'ygan |
| Operator tasodifan pauzada qolib ketdi | Wallboard'da ko'ringunicha 30 s jimlik |
| SLA belgilangan chegaradan pastga tushdi | Ogohlantirish buzilish boshlangandan 30 s keyin ishga tushadi |
| Navbatga VIP mijoz kirdi | Darhol bildirishnoma yo'q, mijoz umumiy navbatda kutadi |
WebSocket asosidagi real vaqt dashboardlarida bu hodisalar bir zumda ko'rinadi. Jonli navbatni boshqarayotganingizda 0 va 30 soniya o'rtasidagi farq muhim.
Narx og'riqli o'sadi
QueueMetrics har bir operator uchun haq oladi. 2026-yil holatiga ko'ra bu taxminan oyiga bitta operator uchun 8 CHF (ustiga Tomcat va server hosting xarajatlari).
Hisob-kitob:
| Jamoa hajmi | QueueMetrics yiliga | Server xarajatlari | Yiliga jami |
|---|---|---|---|
| 10 operator | CHF 960 ($1,080) | ~$300 | ~$1,380 |
| 25 operator | CHF 2,400 ($2,700) | ~$300 | ~$3,000 |
| 50 operator | CHF 4,800 ($5,400) | ~$600 | ~$6,000 |
| 100 operator | CHF 9,600 ($10,800) | ~$600 | ~$11,400 |
| 200 operator | CHF 19,200 ($21,600) | ~$1,200 | ~$22,800 |
50+ operatorda siz call-markaz hisobotlariga ko'p jamoalar butun PBX infratuzilmasiga sarflaganidan ham ko'proq pul sarflaysiz. Har bir operator uchun to'lov esa har bir yangi xodim monitoring xarajatlaringizni oshirishini anglatadi.
Mening fikrim: har bir operator uchun to'lov 2004-yilda mantiqiy edi — bozor kichik, infratuzilma qimmat edi. 2026-yilda esa bu o'sishga solinadigan soliq.
QueueMetrics alternativalari: halol baho
1. Astervis — zamonaviy real vaqt analitikasi
Ochig'ini aytaman: bu bizning mahsulotimiz. U qayerda mos kelishini va qayerda kelmasligini halol aytishga harakat qilaman.
Astervis aynan yuqoridagi muammolarni hal qilish uchun yaratilgan: Java bog'liqligi, polling kechikishlari, har bir operator hisobiga narxning o'sishi. U Asterisk'ga AMI orqali ulanib, haqiqiy real vaqt ma'lumotini oladi va joylashtirishni soddalashtirish uchun Docker'da ishlaydi.
QueueMetrics'dan haqiqatan ham yaxshiroq bo'lgan jihatlar:
- —WebSocket orqali real vaqt ma'lumotlari — polling intervali yo'q, hodisalar bir zumda ko'rinadi
- —O'rnatish:
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash— Tomcat/JDK'ni soatlab sozlash o'rniga - —30+ grafik turi, jumladan heatmap'lar, trunk analitikasi va QueueMetrics'da tayyor holda mavjud bo'lmagan samaradorlik trendlari
- —CRM integratsiyasi — Bitrix24 va AmoCRM tayyor holda (QueueMetrics'da buni alohida ishlab chiqish kerak)
- —Operatorlarni boshqarish — KPI'lar, liderbordlar va ish grafigi nazorati bir joyda
- —Narx: oyiga $119, $449 yoki $1,199 — belgilangan tariflar, operatorlar soni cheklanmagan, har bir operator uchun emas
QueueMetrics hali ham ustun bo'lgan jihatlar:
- —20 yillik chekka holatlar tajribasi va hamjamiyat bilimi
- —QueueMetrics scripting bilan kengaytirilgan maxsus hisobot dvigateli
- —Yigirma yil davomida yig'ilgan ayrim integratsiyalar
- —Muammolarni hal qilishda yordam beradigan kattaroq foydalanuvchi hamjamiyati
Moslik: Asterisk, FreePBX, Sangoma, Issabel, VitalPBX
Sinov muddati: 14 kun, barcha funksiyalar, karta talab qilinmaydi
2. Asternic — soddaroq tarixiy hisobot
Asternic — PHP asosidagi CDR va navbat statistikasi vositasi. U QueueMetrics'dan soddaroq, bu esa uning ham kuchi, ham cheklovi.
Kimga mos:
- —Oddiy qo'ng'iroq statistikasi kerak bo'lgan kichik jamoalar (15 operatorgacha)
- —Real vaqt talab qilinmaydigan tarixiy CDR tahlili
- —Byudjeti cheklangan, hatto oyiga $119 ham sezilarli bo'lgan loyihalar
Cheklovlar:
- —Real vaqt imkoniyatlari cheklangan
- —5 yil oldingiga qaraganda ancha kam faol qo'llab-quvvatlanadi
- —Ilg'or funksiyalar uchun tijoriy litsenziya kerak
- —Deyarli o'zgarmagan sodda interfeys
Mening fikrim: Asternic aniq bir nishani egallaydi — faqat oddiy statistika kerak bo'lgan kichik jamoalar. Agar siz Asternic'dan o'sib chiqayotgan bo'lsangiz, alohida cheklovga urilmasdan, undan butunlay o'sib chiqasiz.
To'liq taqqoslashni o'qing: Astervis vs Asternic
3. Grafana + maxsus exporter'lar — DIY yo'li
Agar sizda DevOps tajribasi bo'lsa, Asterisk monitoringini Grafana, Prometheus va maxsus exporter'lar yordamida o'zingiz qurishingiz mumkin.
# Odatdagi DIY stack uchun kerak bo'ladigan narsalar
# 1. Prometheus Asterisk exporter (o'zingizniki yoki hamjamiyatniki)
# 2. Grafana server
# 3. CDR ma'lumotlari uchun PostgreSQL yoki InfluxDB
# 4. Maxsus queue_log parser
# 5. Maxsus dashboardlar (30-50 panel rejalashtiring)Kimga mos:
- —Monitoringni mavjud Grafana infratuzilmasiga integratsiya qilmoqchi bo'lgan kuchli DevOps'ga ega jamoalar
- —Grafana'ni boshqa servislar uchun allaqachon ishlatayotgan tashkilotlar
- —Byudjet nolga teng, lekin muhandislik vaqti bor bo'lgan holatlar
Cheklovlar:
- —Dastlabki sozlash uchun 30–50 soat (80+ soat sarflagan jamoalarni ham ko'rganman)
- —Operatorlarni boshqarish, KPI va liderbordlar tayyor holda yo'q
- —Asterisk'ning har bir yangilanishi maxsus exporter'laringizni buzishi mumkin
- —Doimiy qo'llab-quvvatlash — kimdir buni abadiy o'z zimmasiga oladi
Mening fikrim: Grafana'dagi DIY yo'li qog'ozda bepul ko'rinadi. Amalda esa soatiga $75 dan 40 soat muhandislik vaqti $3,000 ni tashkil etadi — bu ko'pchilik tijoriy vositalarning bir yillik narxidan ko'p. Va bu faqat dastlabki qurilish. Men bu yo'lni ishtiyoq bilan boshlab, uni qurgan muhandis ketganidan keyin 3 oy o'tib tashlab yuborgan jamoalarni ko'rganman.
Navbatlarda nima sodir bo'layotganini taxmin qilishdan charchadingizmi?
Astervis sizning Asterisk PBX'ingiz uchun 30+ realtime grafik, operator KPI va CRM-integratsiya beradi. On-premise. 5 daqiqada o'rnatiladi. $119/oydan flat — operatorlar soni cheklanmagan.
4. CDR-Stats — ishlatmang
CDR-Stats Django asosidagi CDR tahlil vositasi edi. U amalda tashlab qo'yilgan. GitHub repozitoriysida yillar davomida jiddiy commit'lar bo'lmagan.
Agar Google qidiruvida CDR-Stats'ni uchratsangiz, pastga o'tkazib yuboravering. Ishlab turgan call-markaz uchun tashlab qo'yilgan analitika dasturidan foydalanish — bu ochiq xavf.
5. VoIPmonitor — boshqa masalalar doirasi
VoIPmonitor SIP paketlarini tahlil qilish, MOS baholash va tarmoq darajasida VoIP sifatini kuzatishda ajoyib. Lekin bu call-markaz analitikasi vositasi emas.
Agar muammoyingiz "nega qo'ng'iroqlar yomon eshitiladi" bo'lsa, VoIPmonitor to'g'ri tanlov. Agar muammo "call-markazim qanday ishlayapti" bo'lsa, unday emas.
Bu vositalar birga ishlashi mumkin. Qo'ng'iroq sifatini monitoring qilish uchun VoIPmonitor'dan, operatorlar samaradorligi va navbat analitikasi uchun esa maxsus call-markaz vositasidan foydalaning.
Funksiyalarni taqqoslash: QueueMetrics va Astervis
| Funksiya | QueueMetrics | Astervis |
|---|---|---|
| Real vaqt dashboardlari | Polling (5–30 s interval) | Haqiqiy real vaqt (WebSocket) |
| Grafik turlari | Standart grafiklar | 30+, jumladan heatmap'lar |
| O'rnatish vaqti | 2–4 soat (Java/Tomcat) | 10 daqiqadan kam (Docker) |
| Operatorlarni boshqarish | Oddiy hisob | KPI'lar, liderbordlar, ish grafiklari |
| CRM integratsiyasi | Alohida ishlab chiqish | Bitrix24, AmoCRM tayyor holda |
| Qo'ng'iroq yozuvlari | Tinglash | Tinglash + qidiruv + analitika |
| Wallboard / tablo | Tayyor holda | Tayyor holda, sozlanadigan maketlar bilan |
| Self-hosted | Ha | Ha |
| Narx (50 operator) | ~$450/oy | $119/oy |
| Bog'liqliklar | Java, Tomcat, JDK | Faqat Docker |
| Bepul sinov | Cheklangan demo | 14 kun, barcha funksiyalar |
QueueMetrics'dan migratsiya
Men QueueMetrics'dan Astervis'ga uchta migratsiyani boshqarganman. Mana to'xtovsiz ishlaydigan jarayon.
1-qadam: Parallel o'rnatish
Astervis'ni QueueMetrics bilan yonma-yon o'rnating. Ikkalasi ham Asterisk'dan AMI orqali ma'lumot oladi va bir-biriga xalaqit bermaydi.
# Astervis'ni xuddi shu serverga yoki alohida serverga o'rnating
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash
# Astervis AMI orqali ulanadi - xuddi QueueMetrics kabi
# AMI hisob ma'lumotlarini Astervis sozlash ustasida kiritingIkkala vosita bir vaqtning o'zida bitta Asterisk AMI'ga ulana oladi. Hech qanday ziddiyat yo'q.
2-qadam: Bir haftalik parallel ishlash
Ikkala tizimni kamida bir to'liq ish haftasi davomida birga ishlating. Taqqoslang:
- —Umumiy qo'ng'iroqlar soni (farq 1–2% doirasida bo'lishi kerak)
- —Operatorlarning tizimga kirish va chiqish vaqtlari
- —Navbatdagi kutish vaqti va tashlab yuborilgan qo'ng'iroqlar ulushi
- —SLA hisob-kitobi (metodika biroz farq qilishi mumkin)
Agar raqamlar jiddiy farq qilsa, davom etishdan oldin sababini aniqlang. Odatiy sabablar: vaqt mintaqasi sozlamalaridagi farqlar, queue_log'ni tahlil qilish mantiqining boshqacha bo'lishi yoki hisobdan chiqarilgan navbatlar.
3-qadam: Dashboardlarni o'tkazish
Ma'lumotlarga ishonch hosil qilganingizdan so'ng, jamoangizning kundalik dashboardlarini Astervis'ga o'tkazing. QueueMetrics ishlab tursin, lekin uni kundalik qarorlar uchun ishlatmang.
4-qadam: Ishdan chiqarish
Faqat Astervis'da 30 kun ishlaganingizdan keyin QueueMetrics'ni ishdan chiqaring. Tarixiy ma'lumot kerak bo'lib qolishi ehtimolini hisobga olib, Tomcat konfiguratsiyasi va ma'lumotlar bazasini arxivlang.
# O'chirishdan oldin QueueMetrics ma'lumotlarini arxivlang
mysqldump -u root queuemetrics > /backup/queuemetrics-archive-$(date +%Y%m%d).sql
systemctl stop tomcat9
systemctl disable tomcat9Migratsiya muddati: o'rnatishga 1 kun, parallel ishlashga 1 hafta, zaxira uchun 1 oy. Jami: boshlanishidan to'liq ishdan chiqarishgacha 5–6 hafta.
Qaysi alternativa sizning holatingizga mos keladi
Siz monitoringni birinchi marta sozlayapsiz: QueueMetrics'ni umuman o'tkazib yuboring. 2026-yilda Java asosidagi vositadan boshlashga sabab yo'q. DevOps imkoniyatlaringizga qarab Astervis yoki Grafana DIY bilan boshlang.
Sizda QueueMetrics bor va u yaxshi ishlayapti: Migratsiya uchun migratsiya qilmang. Agar jamoangiz samarali ishlayotgan bo'lsa va narx maqbul bo'lsa, qoling. Alternativalarni shartnoma yangilanganda yoki aniq bir cheklovga duch kelganingizda baholang.
Sizda QueueMetrics bor va u sizni bezovta qilyapti: Parallel sinov o'tkazing. Astervis'ni QueueMetrics bilan yonma-yon o'rnating, bir hafta taqqoslang va ma'lumotlarga asoslangan qaror qabul qiling. 14 kunlik bepul sinov buning uchun yetarli vaqt beradi.
Sizga xarajatlarni qisqartirish kerak: Katta hajmda narx farqi sezilarli. 100 operator: QueueMetrics bilan yiliga ~$11,400, Astervis bilan esa yiliga $7,188 (Business tarifi). 3 yil ichida bu $12,636 tejamkorlik — boshqa infratuzilma yaxshilanishlarini moliyalashtirishga yetadi.
Sizga jonli ish uchun real vaqt ma'lumotlari kerak: Farq eng aniq ko'rinadigan joy shu. Agar supervizorlaringiz jonli dashboardlarga qarab qaror qabul qilsa, polling asosidagi ma'lumot ko'r nuqta hosil qiladi. WebSocket orqali real vaqt ma'lumoti uni yo'q qiladi.
Tegishli materiallar:
- —Astervis vs QueueMetrics: to'liq taqqoslash — har bir funksiya bo'yicha batafsil tahlil
- —Astervis vs Asternic — soddaroq alternativalarni baholayotgan jamoalar uchun
- —Asterisk navbatlarini real vaqtda qanday monitoring qilish kerak — texnik asos
- —Call-markaz uchun KPI dashboard qurish — migratsiyadan keyin nimani kuzatish kerak
- —Operatorlar samaradorligini kuzatish bo'yicha qo'llanma — operator analitikasidan foyda olish
- —Call-markaz monitoringi bo'yicha to'liq qo'llanma — joriy etishning to'liq stsenariysi
Zamonaviy QueueMetrics alternativasini sinab ko'rishga tayyormisiz? 14 kunlik bepul sinovni boshlang — o'rnatish 10 daqiqadan kam, karta talab qilinmaydi.
Taxmin qilishni bas qiling. Ko'rishni boshlang.
Asterisk call-markazingizning haqiqiy ko'rinishi: navbatlardagi kutish vaqti, operatorlar faolligi, trunk yuklamasi va 30+ grafik. Sizning serveringizda on-premise. 5 daqiqada o'rnatish. Kartasiz.
$119/oydan flat. Operatorlar soni cheklanmagan. 14 kunlik triаl.