Asterisk asosidagi call-markazlarning aksariyati monitoringni juda kech boshlaydi. Asterisk o'rnatiladi, navbatlar sozlanadi, operatorlar yollanadi, oradan olti oy o'tib esa kimdir so'rab qoladi: "Nega qo'ng'iroq qiluvchilarning 15 foizi go'shakni tashlab yuboryapti?"
O'sha paytga kelib muammo bir necha oydan beri pulni yeb kelayotgan bo'ladi.
Men 5 operatordan 200+ operatorgacha bo'lgan Asterisk tizimlari bilan ishlaganman. Manzara hamma joyda bir xil: monitoringni birinchi kundan yo'lga qo'ygan jamoalar smenani aniqroq rejalashtiradi, muammoni mijoz shikoyat qilguncha ushlaydi va hal qilingan har bir qo'ng'iroq uchun kamroq to'laydi.
Bu qo'llanmada nimani kuzatish kerakligi, buni Asterisk tomonida qanday yoqish va qaysi vositalar production'da haqiqatan ishlashi haqida gaplashamiz. Nazariyasiz: aniq konfiglar, SQL so'rovlar va real raqamlar.
Asterisk nimani ochib beradi (va nimani yashiradi)
Asterisk juda ko'p ma'lumot ishlab chiqaradi. Qiyinchilik yig'ishda emas — qaysi ma'lumot muhimligini tushunish va bo'laklarni bir-biriga bog'lashda.
Sizga kerak bo'ladigan uchta ma'lumot manbasi
1. AMI (Asterisk Manager Interface) — real vaqtdagi hodisalar
AMI hodisalarni sodir bo'lishi bilanoq uzatadi: qo'ng'iroq navbatga tushdi, operator javob berdi, mijoz go'shakni tashladi, operator pauzaga chiqdi. Bu real vaqtdagi monitoringingizning tayanch ustuni.
; /etc/asterisk/manager.conf
[monitoring]
secret = generate_a_strong_password_here
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.0/255.255.255.0
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000AMI navbat holatini soniyadan kam kechikish bilan ko'rsatadi. Har qanday tashqi monitoring vositasi real vaqt ma'lumotlari uchun aynan AMI orqali ulanadi.
2. queue_log — navbat hodisalari tarixi
Bu fayl navbat bilan bo'lgan har bir muloqotni yozib boradi: kim qo'ng'iroq qildi, qaysi operator javob berdi, qancha kutdi, aloqa nega uzildi.
# queue_log haqiqatan yozilayotganini tekshiramiz
tail -5 /var/log/asterisk/queue_log
# Kutilayotgan format:
# 1774000000|1774000001|sales|ENTERQUEUE||2125551234|1
# 1774000005|1774000001|sales|CONNECT|5|SIP/200|1774000005.42
# 1774000120|1774000001|sales|COMPLETECALLER|5|115||1Maydonlar: vaqt belgisi, unikal ID, navbat nomi, hodisa va hodisaga xos ma'lumotlar. data1/data2/data3 maydonlarining ma'nosi hodisa turiga qarab o'zgaradi — aynan shu joyda o'zi yozilgan hisobot loyihalarining ko'pchiligi qoqiladi.
Muhim: har bir navbatda to'liq logging'ni yoqing:
; /etc/asterisk/queues.conf (har bir navbat uchun)
[sales]
eventwhencalled = yes
eventmemberstatus = yes
queue-callswaiting = yeseventwhencalled = yes bo'lmasa, operator darajasidagi detallashtirishni yo'qotasiz. eventmemberstatus bo'lmasa, operator holatlarining o'zgarishini kuzata olmaysiz.
3. CDR (Call Detail Records) — qo'ng'iroq darajasidagi ma'lumot
CDR boshlanish vaqti, javob vaqti, tugash vaqti, davomiylik va disposition'ni qayd etadi. U qo'ng'iroq darajasida ishlaydi, navbat darajasida emas.
Keng tarqalgan xato: CDR'dagi duration chaqiruv vaqtini ham o'z ichiga oladi. billsec suhbat vaqtiga yaqinroq, lekin unda IVR bo'ylab harakat ham hisobga olinadi. Ikkalasi ham operator bilan mijoz o'rtasidagi haqiqiy suhbat vaqtini aks ettirmaydi. Aniq suhbat vaqti uchun queue_log'dagi CONNECT/COMPLETE hodisalaridan foydalaning.
Haqiqatan ahamiyatli metrikalar
Men 40 ta metrikali dashboard'larni ko'rganman, ularning 35 tasiga hech kim qaramaydi. Mana shu yettitadan boshlang. Yangilarini faqat ular javob beradigan aniq savol paydo bo'lgandagina qo'shing.
1-daraja: har soatda kuzating
1. Kutayotgan qo'ng'iroqlar (real vaqt)
Hozir navbatda nechta mijoz turibdi. Agar bu raqam bo'sh operatorlar sonidan uch baravar oshsa, sizda smena bandligi bilan bog'liq muammo bor — ertaga emas, hozir.
# CLI'dan tezkor tekshiruv
asterisk -rx "queue show sales" | grep -E "^ [0-9]+ has"2. Xizmat darajasi (SLA)
Maqsadli vaqt ichida javob berilgan qo'ng'iroqlar ulushi. Sohadagi standart qiymat — "80/20" (qo'ng'iroqlarning 80 foiziga 20 soniya ichida javob), lekin maqsad navbat turiga mos bo'lishi kerak:
| Navbat turi | SLA maqsadi | Nega shunday |
|---|---|---|
| Sotuv / kiruvchi | 15 s ichida 80% | Sotib olish niyatidagi mijoz tez ketadi |
| Texnik yordam | 30 s ichida 80% | Muammosi bor odam uzoqroq kutadi |
| VIP / korporativ | 10 s ichida 90% | Premium mijoz — premium SLA |
| Umumiy savollar | 45 s ichida 70% | Shoshilinchlik past, sabr yuqori |
-- Navbatlar bo'yicha suriluvchi SLA (oxirgi 24 soat)
SELECT
queuename,
COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 20 THEN 1 END) AS within_sla,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS total_answered,
ROUND(100.0 * COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 20 THEN 1 END) /
NULLIF(COUNT(CASE WHEN event = 'CONNECT' THEN 1 END), 0), 1) AS sla_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(NOW() - INTERVAL 24 HOUR)
GROUP BY queuename
ORDER BY sla_pct ASC;3. Tashlab yuborilgan qo'ng'iroqlar ulushi (abandon rate)
Operatorga yetib bormasdan go'shakni tashlagan mijozlar foizi. 5 foizdan past — sog'lom holat. 10 foizdan yuqori — bu daromad muammosi.
-- Soatlar bo'yicha tashlab yuborish ulushi (muammoli soatlarni topamiz)
SELECT
HOUR(FROM_UNIXTIME(time)) AS hour_of_day,
COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) AS abandoned,
COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END) AS total_attempts,
ROUND(100.0 * COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) /
NULLIF(COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END), 0), 1) AS abandon_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
GROUP BY HOUR(FROM_UNIXTIME(time))
ORDER BY abandon_pct DESC;Bu so'rovni bir marta bajarsangiz kifoya. Tashlab yuborish ulushi keskin ko'tariladigan 2-3 ta soatni topasiz. Ana shular sizning odam yetishmaydigan oynalaringiz.
2-daraja: har kuni ko'rib chiqing
4. Operatorlar bo'yicha o'rtacha ishlov berish vaqti (AHT)
AHT operatordan operatorga keskin farq qiladi. Savol shundaki, bu tafovut muammodan darak beryaptimi yoki shunchaki qo'ng'iroqlarning murakkabligi har xilmi.
-- Qo'ng'iroqlar soni bilan operatorlar bo'yicha AHT (oxirgi 7 kun)
SELECT
agent,
COUNT(*) AS calls,
ROUND(AVG(CAST(data2 AS UNSIGNED))) AS avg_talk_sec,
ROUND(AVG(CAST(data1 AS UNSIGNED))) AS avg_hold_sec,
ROUND(AVG(CAST(data2 AS UNSIGNED) + CAST(data1 AS UNSIGNED))) AS avg_total_sec
FROM queue_log
WHERE event IN ('COMPLETECALLER', 'COMPLETEAGENT')
AND time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
AND agent != 'NONE'
GROUP BY agent
HAVING calls >= 10
ORDER BY avg_total_sec DESC;Kuniga 50 ta qo'ng'iroqni 180 s AHT bilan bajaradigan operator 40 ta qo'ng'iroqni 120 s bilan bajaradiganidan albatta yomonroq degani emas. Tezroq degani yaxshiroq deb hisoblashdan oldin birinchi qo'ng'iroqda hal qilish ko'rsatkichlarini tekshiring.
5. Operator bandligi (occupancy)
Tizimda bo'lgan vaqtga nisbatan qo'ng'iroqlarga ishlov berishga ketgan vaqt ulushi. Sog'lom diapazon — 70-85%.
70 foizdan past: smenada odam ortiqcha yoki operatorlar navbatdan qochyapti. 85 foizdan yuqori: siz operator kuyib qolishiga qarab ketyapsiz. Qo'ng'iroqdan keyingi ishlov sifati tushadi, xatolar ko'payadi, ketidan kadrlar almashuvi keladi.
6. Kutish vaqtining taqsimoti (o'rtacha emas)
O'rtacha kutish vaqti chalg'itadi. O'rtacha 15 soniya kutiladigan navbatda qo'ng'iroqlarning 80 foiziga 5 soniyada javob berilib, 20 foizi 3 daqiqadan ko'proq kutayotgan bo'lishi mumkin. O'sha 20 foiz uchun tajriba dahshatli.
-- Kutish vaqtining taqsimoti (persentillar)
SELECT
queuename,
COUNT(*) AS total_calls,
ROUND(AVG(CAST(data1 AS UNSIGNED))) AS avg_wait,
-- Shartli agregatsiya orqali taxminiy persentillar
MAX(CASE WHEN rn <= total * 0.50 THEN wait_sec END) AS p50_wait,
MAX(CASE WHEN rn <= total * 0.90 THEN wait_sec END) AS p90_wait,
MAX(CASE WHEN rn <= total * 0.95 THEN wait_sec END) AS p95_wait
FROM (
SELECT
queuename,
CAST(data1 AS UNSIGNED) AS wait_sec,
ROW_NUMBER() OVER (PARTITION BY queuename ORDER BY CAST(data1 AS UNSIGNED)) AS rn,
COUNT(*) OVER (PARTITION BY queuename) AS total
FROM queue_log
WHERE event = 'CONNECT'
AND time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
) sub
GROUP BY queuename;Agar P50 8 soniya bo'lsa-yu, P95 180 soniya bo'lsa, sizda bimodal taqsimot bor. Buni odatda barcha smenalarga operator qo'shish emas, pik soatlarda smenani kuchaytirish hal qiladi.
3-daraja: har hafta ko'rib chiqing
7. Trunk'lardan foydalanish darajasi
SIP trunk'laringiz sig'im chegarasiga qanchalik yaqin? Pikda 80 foizdan pastda turing. Undan yuqorida sakrashlar paytida mijozlar "band" signalini eshitadi.
-- Trunk bo'yicha bir vaqtdagi qo'ng'iroqlar piki (oxirgi 7 kun)
SELECT
DATE(calldate) AS day,
HOUR(calldate) AS peak_hour,
SUBSTRING_INDEX(channel, '/', 2) AS trunk,
COUNT(*) AS concurrent_calls
FROM cdr
WHERE calldate > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND disposition = 'ANSWERED'
GROUP BY DATE(calldate), HOUR(calldate), SUBSTRING_INDEX(channel, '/', 2)
ORDER BY concurrent_calls DESC
LIMIT 10;Monitoringni yo'lga qo'yish: uchta yondashuv
1-yondashuv: CLI skriptlar (bepul, cheklangan)
Bir martalik tekshiruvlarga yaraydi. To'laqonli monitoring yechimi emas.
#!/bin/bash
# quick-queue-status.sh - har 5 daqiqada cron orqali ishga tushiring
QUEUES=$(asterisk -rx "queue show" | grep "^[a-zA-Z]" | awk '{print $1}')
for Q in $QUEUES; do
WAITING=$(asterisk -rx "queue show $Q" | grep "has [0-9]* calls" | awk '{print $3}')
AGENTS=$(asterisk -rx "queue show $Q" | grep -c "SIP/")
if [ "$WAITING" -gt 5 ] && [ "$AGENTS" -gt 0 ]; then
RATIO=$((WAITING / AGENTS))
if [ "$RATIO" -gt 3 ]; then
echo "ALERT: Queue $Q has $WAITING calls waiting with $AGENTS agents (ratio: $RATIO:1)"
# Ogohlantirishni email, Slack va h.k. orqali yuborish
fi
fi
doneBu sizga eng oddiy ogohlantirishni beradi. Lekin u har 5 daqiqada tekshiradi, 5 daqiqada esa juda ko'p narsa yuz berishi mumkin. Va u sizga trendlar, naqshlar yoki alohida operator ishi haqida hech nima aytmaydi.
2-yondashuv: Grafana + o'z pipeline'ingiz (bepul, 40-80 soat)
DevOps kompetensiyasi va vaqti bor jamoalar uchun:
- —Grafana + PostgreSQL o'rnatish (yoki vaqt qatorlarini optimallashtirish uchun TimescaleDB)
- —Hodisalarni bazaga yuklaydigan queue_log parser yozish
- —Real vaqtdagi hodisalar uchun AMI listener qurish
- —Yuqoridagi har bir metrika uchun dashboard yig'ish
- —Ogohlantirish qoidalarini sozlash
Xolis baho: dastlabki yig'ish SQL va Grafana bo'yicha tajribangizga qarab 40-80 soat oladi. Dashboard chiroyli chiqadi. Keyin esa:
- —Operatorlarning kirishi, chiqishi va pauzalari dashboard'ni yangilashni talab qiladi
- —Navbat konfiguratsiyasidagi o'zgarishlar so'rovlarni buzadi
- —Kimdir AMI listener'ni qo'llab-quvvatlashi kerak (u uziladi, Asterisk qayta ishga tushadi, tarmoq uziladi)
- —Tarixiy ma'lumotlarni saqlashni boshqarish kerak
Men ko'rgan "Asterisk ustidagi Grafana" loyihalarining aksariyati 6-12 oy ichida tashlab qo'yiladi — ularni qurgan muhandis ketganda. Buziladigan narsa dashboard emas: buziladigani ma'lumot pipeline'ini qo'llab-quvvatlash.
Batafsil tahlil uchun Grafana va Astervis to'liq taqqoslovimizni o'qing.
3-yondashuv: Astervis (maxsus yechim, 10 daqiqa)
Astervis aynan Asterisk call-markazlarini monitoring qilish uchun qurilgan. AMI ulanishi, queue_log tahlili, real vaqtdagi dashboard'lar, operatorlarni boshqarish va ogohlantirishlar quti ochilgan zahoti ishlaydi.
# Asterisk serveringizga yoki alohida mashinaga o'rnatish
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashKeyin dashboard'da:
- —Asterisk serveringizni qo'shasiz (AMI hisob ma'lumotlari)
- —Navbatlar avtomatik aniqlanadi
- —Monitoringni boshlaysiz
Nima olasiz:
- —30+ grafik, jumladan issiqlik xaritalari, trend taqqoslashlari va navbat analitikasi
- —Real vaqtdagi dashboard'lar (AMI hodisalariga soniyadan tez ishlov berish)
- —Operator ishini KPI va reytinglar bilan kuzatish
- —Har bir navbat uchun sozlanadigan chegaralar bilan SLA monitoringi
- —Smenalarni rejalashtirish va operatorlarni boshqarish
- —Suhbat yozuvlarini to'g'ridan-to'g'ri dashboard'dan tinglash
- —CRM integratsiyasi (Bitrix24, AmoCRM)
- —Self-hosted — ma'lumotlaringiz o'z tarmog'ingizda qoladi
Narxi: oyiga $119 dan boshlab, operatorlar soni cheklanmagan. 14 kunlik bepul sinov, karta talab qilinmaydi.
FreePBX, Sangoma, Issabel, VitalPBX bilan ishlaydi — ostida Asterisk turgan har qanday tizim bilan.
Monitoring uchun Asterisk konfiguratsiyasi
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.
To'liq hodisa logging'ini yoqish
Asterisk o'rnatmalarining ko'pchiligida logging to'liq emas. Avval shuni tuzating:
; /etc/asterisk/queues.conf - HAR BIR navbat bo'limiga qo'shing
[sales]
; ... mavjud konfiguratsiyangiz ...
eventwhencalled = yes ; Qo'ng'iroq qaysi operatorga taklif qilinganini yozish
eventmemberstatus = yes ; Operator holati o'zgarishini yozish (pauza, pauzadan chiqish, kirish)
monitor-type = MixMonitor ; Suhbat yozuvini yoqish
queue-callswaiting = yes ; Mijozga navbatdagi o'rnini e'lon qilish
queue-thankyou = beep ; Ulanganda tasdiq tovushi
; Unumdorlikni sozlash
wrapuptime = 30 ; Qo'ng'iroqlar orasida 30 s (kuyishdan saqlaydi, ACW hisobini yaxshilaydi)
timeout = 15 ; Operatorga 15 s chaqiruv, so'ng keyingisiga o'tish
retry = 5 ; Urinishlar orasida 5 s kutishwrapuptime haqida fikrim: standart qiymat 0, ya'ni operator go'shakni qo'yishi bilan keyingi qo'ng'iroq darhol keladi. Bu uch sababga ko'ra yomon: (1) operator qo'ng'iroqdan keyingi ishni tugatolmaydi va uni keyingi qo'ng'iroq davomida bajaradi, natijada AHT shishadi; (2) bu kuyib qolishga olib keladi — kuyishning oldini olish qo'llanmamizni o'qing; (3) AHT raqamlaringiz ma'nosini yo'qotadi, chunki qo'ng'iroqdan keyingi ish vaqti suhbat vaqti ichida yashirinib qoladi.
wrapuptime'ni kamida 15-30 soniyaga qo'ying. Dastlab AHT kattaroq ko'rinadi, lekin haqiqiy unumdorligingiz oshadi.
Tashqi vositalar uchun AMI'ni sozlash
; /etc/asterisk/manager.conf
[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0
[monitoring]
secret = use_a_strong_32_char_password
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.100/255.255.255.255 ; Faqat monitoring serveringiz IP manzili
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000Xavfsizlik: production'da hech qachon permit = 0.0.0.0/0.0.0.0 ishlatmang. AMI sizning ATSingiz ustidan to'liq nazoratga ega. Kirishni aniq IP manzillar bilan cheklang.
O'zgarishlardan keyin:
asterisk -rx "manager reload"
# Tekshirish: telnet your-asterisk-server 5038Navbat strategiyasini tanlash
Monitoring ma'lumotlaringiz navbat strategiyangiz qanchalik puxta bo'lsa, shunchalik foydali. Har xil strategiyalar har xil manzara beradi:
| Strategiya | Xatti-harakati | Kimga mos | Monitoringda ko'rinishi |
|---|---|---|---|
| ringall | Barcha operatorlarga birdan qo'ng'iroq | Kichik jamoalar (<5) | Bir tekis taqsimot, javob ulushi yuqori |
| leastrecent | Eng uzoq bo'sh turgan operatorga | Muvozanatli yuklama | Operatorlar bo'yicha bir xil metrikalar |
| fewestcalls | Qo'ng'irog'i eng kam operatorga | Adolatli taqsimot | O'xshash qo'ng'iroq sonlari |
| rrmemory | Eslab qoladigan round-robin | Bashorat qilinadigan | Ketma-ket operator naqshlari |
| random | Tasodifiy operator | Katta jamoalar | Statistik taqsimot |
| linear | Qat'iy ustuvorlik tartibi | Ko'nikmaga qarab taqsimlash | Eng yaxshi operatorlar ortiqcha yuklanadi |
linear eng bashorat qilinadigan sifatni beradi, lekin eng yaxshi operatorlaringizni kuydiradi. leastrecent — eng yaxshi universal strategiya: u yuklamani tabiiy ravishda tenglashtiradi, bu esa monitoring ma'lumotlaringizni mazmunliroq qiladi.
Monitoringdagi keng tarqalgan xatolar
1-xato: taqsimot o'rniga o'rtacha qiymatlarni kuzatish
O'rtacha 25 soniya kutish maqbul eshitiladi. Lekin taqsimot bunday bo'lishi mumkin:
- —qo'ng'iroqlarning 60 foizi: 10 soniyadan tez javob
- —qo'ng'iroqlarning 25 foizi: 30-60 soniyada javob
- —qo'ng'iroqlarning 15 foizi: 2-5 daqiqa kutish
O'sha 15 foiz — sizning mijoz yo'qotish xavfingiz. O'rtacha qiymat o'rniga P90 va P95 persentillaridan foydalaning. Yuqoridagi SQL so'rovlar ikkalasini ham hisoblaydi.
2-xato: navbat turlarini ajratmaslik
Sotuv navbati metrikalarini yordam navbati metrikalari bilan aralashtirib, ikkalasini ham foydasiz qilib qo'yasiz. Sotuv navbatidagi 30 soniya kutish daromadga tushadi. Qayta qo'ng'iroq navbatidagi 30 soniya kutish esa kutilgan holat. Har bir navbat uchun alohida SLA maqsadlarini sozlang.
3-xato: CDR'ni navbat analitikasi deb bilish
CDR qo'ng'iroqlarni qayd etadi. queue_log navbat bilan muloqotni qayd etadi. Bular turli savollarga javob beradigan turli ma'lumot manbalari.
CDR shuni aytadi: "Bu qo'ng'iroq 3 daqiqa davom etdi." queue_log shuni aytadi: "Bu mijoz 45 soniya kutdi, SIP/200 operatori javob berdi, suhbat 2 daqiqa 15 soniya davom etdi, go'shakni birinchi bo'lib mijoz qo'ydi."
Agar hisobotlarni faqat CDR ma'lumotlaridan qurayotgan bo'lsangiz, navbat kontekstini yo'qotasiz. Ikkala manbani samarali birlashtirish haqida CDR hisobotlari qo'llanmamizni ko'ring.
4-xato: ogohlantirishlardan charchash
Har bir mayda chegara uchun ogohlantirish qo'yish shovqin hosil qiladi. Odamlar barcha alert'larni, jumladan kritiklarini ham, e'tiborsiz qoldirishga o'rganib qoladi.
Faqat uchta ogohlantirishdan boshlang:
- —Navbat to'lib ketishi: 10 dan ortiq mijoz 2 daqiqadan uzoq kutmoqda
- —SLA buzilishi: xizmat darajasi 15+ daqiqa davomida 60 foizdan pastda
- —Trunk sig'imi: bir vaqtdagi qo'ng'iroqlar trunk sig'imining 80 foizidan oshdi
Yangi ogohlantirishlarni faqat mana shu uchtasiga izchil munosabat bildirayotganingizni isbotlaganingizdan keyin qo'shing.
5-xato: taqqoslash uchun tarixiy baza yo'q
Real vaqtdagi dashboard'lar kontekstsiz foydasiz. "Navbatda 47 qo'ng'iroq" degani, seshanba kuni soat 14:00 da odatda 50 ta bo'lishini bilmasangiz, hech nimani anglatmaydi. Real vaqtdagi dashboard foyda keltira boshlashi uchun kamida 30 kunlik tarix to'planishi kerak.
Monitoring cheklisti
Asterisk monitoringingiz to'liq sozlanganiga ishonch hosil qilish uchun shu ro'yxatdan o'ting:
Ma'lumot yig'ish:
- — AMI yoqilgan, monitoring uchun foydalanuvchi yaratilgan
- — queue_log barcha hodisalarni yozmoqda (eventwhencalled, eventmemberstatus)
- — CDR ma'lumotlar bazasiga yozilmoqda (faqat oddiy faylga emas)
- — wrapuptime har bir navbat uchun belgilangan (0 emas)
- — Suhbat yozuvi yoqilgan (MixMonitor)
Dashboard'lar:
- — Navbatning real vaqtdagi holati (kutayotgan qo'ng'iroqlar, bo'sh operatorlar)
- — Har bir navbat uchun SLA ko'rsatkichi (to'g'ri chegara bilan)
- — Soatlar bo'yicha tashlab yuborish ulushi (issiqlik xaritasi)
- — Operator ko'rsatkichlari jadvali (AHT, qo'ng'iroqlar, FCR)
- — Trunk'lardan foydalanish grafigi
Ogohlantirish:
- — Navbat to'lib ketishi ogohlantirishi sozlangan
- — SLA buzilishi ogohlantirishi sozlangan
- — Trunk sig'imi ogohlantirishi sozlangan
- — Ogohlantirish yetkazilishi sinovdan o'tkazilgan (email, Slack, webhook)
Hisobot:
- — Kunlik xulosa avtomatlashtirilgan
- — Haftalik trend hisoboti sozlangan
- — Oylik sig'im hisoboti rejalashtirilgan
Real vaqtdagi monitoring nimani o'zgartiradi
Monitoringni to'g'ri qurgan jamoalar barqaror yaxshilanishlarni ko'radi:
- —Tashlab yuborish ulushi 30-50 foizga tushadi birinchi oydayoq (chunki muammoni keyingi hafta emas, sodir bo'layotgan paytida ko'rasiz)
- —Operatorlarning bo'sh vaqti 15-20 foizga kamayadi (real vaqtda smena bo'yicha aniqroq qarorlar)
- —SLA bajarilishi 10-25 foizga yaxshilanadi (chegara ogohlantirishlari uzoq davom etadigan buzilishlarga yo'l qo'ymaydi)
- —Xodimlar xarajati 3 oyda 5-10 foizga kamayadi (issiqlik xaritalari odam ortiqcha bo'lgan oynalarni ko'rsatadi)
Bular faraz emas. Bu — jamoalar "vaqti-vaqti bilan CLI'ga qarash"dan uzluksiz monitoringga o'tganda men qayta-qayta ko'radigan manzara.
Yaxshi monitoring qilinadigan Asterisk call-markazi bilan monitoringsiz call-markaz o'rtasidagi farq texnik murakkablikda emas. Farq ko'rinuvchanlikda. Ko'rmagan narsangizni tuzata olmaysiz.
Asterisk call-markazini real vaqtdagi monitoringsiz yuritayapsizmi? Bepul 14 kunlik Astervis sinovini boshlang va 10 daqiqada 30+ dashboard oling.
Allaqachon Grafana yoki skriptlar bilan monitoring qilyapsizmi? Astervis ular fonida qanday ko'rinishini monitoring vositalari taqqoslovimizda ko'ring.
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.