כיצד לחבר Zabbix עם כוכבית מחוץ לקופסה

במאמר הקודם "זאביקס - הרחבת גבולות המאקרו" אמרתי לך איך לקבל הפעלת הרשאה ולהחליף אותה במאקרו מארח מקומי. במאמר זה אספר לכם כיצד לחבר את Zabbix עם Asterisk ללא סקריפטים ותוכנות חיצוניות.

הרעיון "להתיידד" של שתי המערכות הללו נולד לפני זמן רב, ללא התקנת תוכנות או סקריפטים נוספים. חיפוש בגוגל מהיר הניב הרבה פתרונות אפשריים, הכל הסתכם בעובדה להעלות את הסקריפטים (ב-Pyha, Bash, Python וכו') לשרת, ותשמחו. רציתי ליישם ניטור "מחוץ לקופסה" - ללא סקריפטים חיצוניים והתקנת תוכנה נוספת על השרת עם ניטור ומרכזיה.

ביליתי עם זה בסך הכל 4 ימי עבודה, אבל התוצאה הייתה שווה את זה. עבודה דרך ממשק AMI, זיהוי ברמה נמוכה, טריגרים, והכי חשוב, חיבור המרכזיה וכל שאר ההגדרות לוקח כעת כ-15 דקות.

Zabbix 4.4 זמין, בערך 100 חתיכות של כוכבית גרסה 13. חלק מהמרכזיות מגיעות עם ממשק האינטרנט של FreePBX, חלקן עם קונסולה חשופה, שלל טריקים ואינטגרציה באמצעות תוכנית חיוג.

קבלת נתונים מהמרכזייה

הנקודה הראשונה והעיקרית שצריך לפתור היא השגת נתונים על עמיתים ורישומי SIP. לצורך כך, למרכזייה יש ממשקי קונסולות AGI, AMI, ARI ו-SSH. מסיבות ברורות, לא שקלתי מודולים נוספים.

ראשית עלינו להבין מה הם ה-agi, ami, ari...

• AGI - שימוש בסקריפטים ב-dialplan. משמש בעיקר לניהול שיחות.
• AMI - יכול לספק את כל המידע הדרוש, עובד דרך יציאה 5038, בדומה ל-Telnet. מתאים לנו!
• ARI - מודרני, אופנתי, JSON. יש הרבה אפשרויות, פורמט הנתונים מובן עבור Zabbix, אבל מבחינתי אין עיקר: אי אפשר לשלוט ברישום הלגימה. חיסרון נוסף הוא שלעמיתים יש רק שתי מצבים מקוונים/לא מקוונים, אם כי יש יותר מצבים ושימושי לקחת אותם בחשבון בעת ​​האבחון.
• SSH יכול לעשות הכל, אבל לפעמים זה לא מותר בגלל "סיבות בטחוניות". השיקולים עשויים להיות שונים, אני לא אכנס אליהם.

עם זאת, עם כל החסרונות שלה, ARI מכסה 90% מכל צרכי הניטור.

זאביקס וטלנט - האכזבה שלי

אני מכיר את AMI היטב; פעם יישמתי מעקב אחר הפסדים בשיחות עם חטיבה על ידי משרדים מרוחקים, ניהול שיחות וכו'. עם Telnet, הכל גם מאוד ברור: פתח את החיבור, שלח את הפקודות וקרא את התגובה. זה מה שעשיתי, אבל התוצאה איכזבה אותי.

Telnet ב- Zabbix לא זהה לקונסולת לינוקס, היא קצת יותר פשוטה ומותאמת להרשאה סטנדרטית כמו כניסה/סיסמה. אם היגיון ההרשאה שונה, ואין בקשה לזוג כניסה/סיסמה, מתרחשת שגיאה. לאחר ניסיונות עקרים לעקוף את דרישת ההרשאה, היה שימושי להסתכל על קוד המקור של מודול Telnet.

הבנתי שעד שלא תהיה בקשת כניסה וסיסמה מסורתית, אני לא אתקדם. סתם בשביל הכיף, הסרתי את כל מה שקשור להרשאה מהקוד והרכבתי הכל מחדש. עובד! אבל זה לא עומד בדרישות. לך על זה…

נחזור לחיפוש

קראתי שוב את התיעוד של ARI, הפעלתי בדיקות נוספות - אין כאן רישומי לגימה. יש סעודות, יש שיחות, יש מכנסיים, אבל אין נרשמים. בשלב מסוים אפילו חשבתי, האם אנחנו באמת צריכים רישום נשרים?

בצירוף מקרים מצחיק, ברגע זה מגיעה בקשה נוספת מהמשתמש, עם בעיה בשיחות יוצאות. הבעיה הייתה שהרישום ללגימה קפא ונפתרה על ידי הפעלה מחדש של המודול.

asterisk -rx "sip reload"

זה יהיה נהדר לגשת ל-AMI דרך האינטרנט: זה יפתור את כל הבעיות, חשבתי. אני מתחיל לחפור בכיוון הזה, וממש שורת החיפוש הראשונה מובילה לתיעוד הרשמי של הכוכבית, שאומר שיש אפשרות למשימות שלי מופעלת באינטרנט בקובץ /etc/asterisk/manager.conf, שצריך להגדיר כ-YES, בקטע [כללי]

לאחר מכן, באמצעות בקשה אינטרנטית רגילה של הטופס http://ats:8089/mxml?action=SIPshowregistry אנו מקבלים את כל המידע הדרוש.

בעת שימוש בממשק FreePBX, אינך יכול להפעיל אפשרות זו דרך האינטרנט; עליך להפעיל אותה דרך המסוף על ידי ביצוע שינויים בקובץ manager.conf. FreePBX אינה מוחקת אותו כאשר מתבצעים שינויים בתצורה דרך האינטרנט.

עבדתי עם סוגים שונים של אינטגרציות של כוכבית במשך זמן רב, אך מעולם לא ראיתי תכונה זו מוזכרת בשום מקום. הופתעתי שאף אחד לא מתאר את השיטה הזו של אינטראקציה עם המרכזייה. זה אפילו היה שימושי במיוחד לחפש מידע על נושא זה: אין כמעט כלום או שהוא שימש למשימות שונות לחלוטין.

WEB AMI - איזו חיה?

הוספת אפשרות מופעלת באינטרנט לתייק manager.conf סיפקה גישה מלאה לניהול ATS דרך האינטרנט. כל הפקודות הזמינות דרך AMI רגיל נמצאות כעת באינטרנט, ניתן להאזין לאירועים מהמרכזייה דרך שקע. עקרון הפעולה אינו שונה מהקונסולה AMI. לאחר הפעלת אפשרות זו, תוכל ליצור קשר עם המרכזיה בכתובות הבאות:

https://ats:8089/manager - דף אינטרנט עם ממשק פשוט לבדיקה ושליחה ידנית של בקשות. כל התגובות מעוצבות ל-HTML קריא. לא מתאים במיוחד לניטור.
https://ats:8089/rawman - פלט טקסט בלבד, פורמט דומה ל-AMI של המסוף
https://ats:8089/mxml - פלט טקסט בלבד, בפורמט XML. מתאים לנו!

ואז חשבתי: "זה הפתרון! עכשיו הכל יהיה מוכן! סחיטת לימון קלה", אבל זה היה מוקדם מדי לשמוח. כדי לקבל את המידע הדרוש לנו, מספיק להשתמש בבקשת GET עם הפעולה הנדרשת פעולה, שבתגובה מחזירה xml עם רשימה של כל הרישומים והסטטוס שלהם. כל זה נהדר, אבל אתה צריך הרשאה כדי לזכור את הפגישה מהעוגייה. כשאתה בודק בדפדפן, אתה לא חושב על התהליך הזה.

תהליך הרשאה

ראשית אנו מתייחסים לכתובת http://ats:8089/mxml?action=login&username=zabbix&secret=zabbix, בתגובה, השרת שולח לנו קובץ Cookie עם הפעלת ההרשאה. כך נראית בקשת HTTP:

https://ats:8089/mxml?action=login&username=zabbix&secret=zabbix

Host: ats:8089
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

תשובה:

GET: HTTP/1.1 200 OK
Server: Asterisk/13.29.2
Date: Thu, 18 Jun 2020 17:41:19 GMT
Cache-Control: no-cache, no-store
Content-type: text/xml
Set-Cookie: mansession_id="6f5de42c"; Version=1; Max-Age=600
Pragma: SuppressEvents
Content-Length: 146

<ajax-response>
<response type="object" id="unknown">
<generic response="Success" message="Authentication accepted"/>
</response>
</ajax-response>

כדי לעבוד שם אתה צריך mansession_id="6f5de42c", כלומר קובץ ה-Cookie של ההרשאה עצמו.
תוכן שאתה רק צריך לבדוק את התשובה "האימות התקבל" לאחר מכן, עבור כל השיחות לשרת המרכזיה, נצטרך להוסיף קובץ Cookie של הרשאה לבקשה.

https://ats:8089/mxml?action=SIPpeers

Host: ats:8089
Connection: close
Cookie: mansession_id="6f5de42c"

קרא כיצד לקבל קובץ Cookie של הרשאה ולהשתמש בו בבקשות אחרות כאן: "Zabbix - הרחבת גבולות המאקרו»

כדי ליצור רכיבי מעקב ב- Zabbix אשתמש בזיהוי אוטומטי.

זיהוי אוטומטי

כדי לזהות באופן אוטומטי רישומים ולעקוב אחר מצבי עמיתים, עליך ליצור קשר עם הכתובת הבאה: https://ats:8089/mxml?action=SIPshowregistry או https://ats:8089/mxml?action=SIPpeers

בתגובה, המרכזיה מחזירה לנו תגובת XML:

<ajax-response>
<response type="object" id="unknown">
<generic response="Success" eventlist="start" message="Registrations will follow"/>
</response>
...
<response type="object" id="unknown">
<generic event="RegistryEntry" host="login.mtt.ru" port="5060" username="111111" domain="login.mtt.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
<response type="object" id="unknown">
<generic event="RegistryEntry" host="voip.uiscom.ru" port="5060" username="222222" domain="voip.uiscom.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
<response type="object" id="unknown">
<generic event="RegistryEntry" host="voip.uiscom.ru" port="5060" username="333333" domain="voip.uiscom.ru" domainport="5060" refresh="105" state="Registered" registrationtime="1592502142"/>
</response>
...
</ajax-response>

יש הרבה זבל בתגובה, אז בעיבוד מקדים אנחנו מסננים אותו לפי תבנית Xpath: //response/generic[@host]
ואז מתחיל הכיף. כדי לעבוד עם זיהוי וליצור באופן דינמי אלמנטים, התגובה חייבת להיות בפורמט JSON. XML אינו נתמך עבור זיהוי אוטומטי.

כדי להמיר XML ל-JSON, הייתי צריך לשחק קצת עם החלפה אוטומטית, בשביל זה עשיתי סקריפט ב-JS

נקודה מעניינת: בתגובת ATS, כל הפרמטרים מוקפים במרכאות בודדות, ולאחר החלת התבנית //response/generic[@host] הם מוחלפים בכפולים.

כדי ליצור אלמנטים, אנו משתמשים במשתנים מתגובת ה-XML (כיום JSON)​.

רישום SIP

עבור רישום לגימה אנו משתמשים בשלושה משתנים: שם משתמש, המארח, נמל. הייתי מרוצה מהשם של האלמנט [מוגן בדוא"ל]: 5060, לא מצאתי מצבים שבהם אתה צריך להשתמש בכל חמשת המשתנים.

האלמנט העיקרי שמקבל מידע על כל ההרשמות, כוכבית - AMI SIPshowregistry. פעם בדקה הוא שולח בקשת GET ל https://ats:8089/mxml?action=SIPshowregistry, ולאחר מכן נתוני ה-XML של התגובה מועברים לכל האלמנטים התלויים לצורך ניתוח. עבור כל רישום אני יוצר אלמנט התלוי בו. זה נוח מכיוון שאנו מקבלים מידע עדכני בבקשה אחת, ולא לכל בקשה בנפרד. ליישום הזה יש חיסרון משמעותי - העומס על המעבד.

כשבדקתי עד 100 אלמנטים תלויים, לא שמתי לב לעומס, אבל עם 1700 אלמנטים, זה נתן עומס ניכר של 15 שניות על המעבד. זכור זאת אם יש לך מספר רב של אלמנטים תלויים.

כאפשרות "לפזר" את העומס או להגדיר תדרי סקר שונים עבור אלמנט, ניתן להעביר את היגיון העיבוד לכל אלמנט בנפרד.

אני לא מאחסן את המידע שהתקבל באלמנט הראשי. ראשית, אני לא רואה צורך בכך, ושנית, אם התגובה היא יותר מ-64K, אז Zabbix מנתקת את זה.

מכיוון שאנו משתמשים בתגובת XML מלאה עבור האלמנט התלוי, עלינו לקבל את הערך של אלמנט זה בעיבוד מקדים. דרך Xpath זה נעשה כך:
string(//response/generic[@event="RegistryEntry"][@username="{#SIP_REGISTRY_USERNAME}"][@host="{#SIP_REGISTRY_HOST}"][@port="{#SIP_REGISTRY_PORT}"]/@ מדינה)
עבור סטטוסי רישום, לא השתמשתי בסטטוסי טקסט, אלא המרתי אותם לצורה מספרית באמצעות JavaScript:

switch(value) {
  case 'Registered':
    return 1;
  case 'Unregistered':
    return 0;
  default:
    return -1;
}

SIP Peers

באנלוגיה לרישומי SIP, ישנו מרכיב עיקרי של Asterisk - AMI SIPshowregistry, שאליו מתווספים תלויים.

זה יוצר שני אלמנטים תלויים:

• סטטוס עמית בצורת טקסט
• זמן תגובה של המכשיר - אם המצב בסדר, זמן התגובה של המכשיר נכתב, אחרת "-1"

הדרך אל האלמנט עצמו מעט יותר פשוטה Xpath:

string(//response/generic[@objectname="{#SIP_PEER_OBEJECTNAME}"]/@status)

עבור האלמנט השני השתמשתי ב-JavaScript כדי להפריד זמן תגובה מסטטוס עמית, מכיוון שהם מאוחסנים יחד:

if(value.substring(0,2) == 'OK'){
	return value.match(/(d+)/gm);
}
else {
	return -1;
}

מסקנה

פתרון מחוץ לקופסה יכול להיות מורכב ולא ברור מיד. מגביר את הגמישות והניידות בין מערכות שונות

השתלבות נעימה וקלה לכולם! תבנית והוראות להגדרה GitHub.

מקור: www.habr.com