שימוש ב-TSDuck לניטור זרימות IP(TS).

כיום ישנם פתרונות מוכנים (קנייניים) לניטור זרימות IP(TS), למשל VB и iQ, יש להם מערך די עשיר של פונקציות ובדרך כלל למפעילים גדולים העוסקים בשירותי טלוויזיה יש פתרונות דומים. מאמר זה מתאר פתרון המבוסס על פרויקט קוד פתוח TSDuck, מיועד לשליטה מינימלית של זרימות IP(TS) באמצעות מונה CC (מונה המשכיות) וקצב סיביות. יישום אפשרי הוא ניטור אובדן מנות או כל הזרימה דרך ערוץ L2 מושכר (שלא ניתן לנטר אותו באופן רגיל, למשל, על ידי קריאת מוני אובדן בתורים).

בקצרה מאוד על TSDuck

TSDuck היא תוכנת קוד פתוח (רישיון BSD 2-סעיפים) (סט של כלי עזר לקונסולות וספרייה לפיתוח כלי עזר או תוספים משלך) לתפעול זרמי TS. כקלט, זה יכול לעבוד עם IP (multicast/unicast), http, hls, dvb tuners, dektec dvb-asi demodulator, יש מחולל זרם TS פנימי וקריאה מקבצים. הפלט יכול להיות הקלטה לקובץ, IP (multicast/unicast), hls, dektec dvb-asi ו- HiDes מאפננים, נגנים (mplayer, vlc, xine) ו-Drop. בין הקלט לפלט, אתה יכול לאפשר מעבדי תעבורה שונים, למשל, מיפוי מחדש של PIDs, ביצוע ערבול/פירוק, ניתוח מוני CC, חישוב קצב הסיביות ופעולות אחרות אופייניות לזרמי TS.

במאמר זה ישמשו זרמי IP (multicast) כקלט, מעבדי bitrate_monitor (מהשם ברור מה זה) ומעבדי המשכיות (CC counter analysis). ללא כל בעיה, אתה יכול להחליף ריבוי שידור IP בסוג קלט אחר הנתמך על ידי TSDuck.

זמינים בונים/חבילות רשמיים TSDuck עבור רוב מערכת ההפעלה העדכנית. אין כאלה עבור דביאן, אבל הצלחנו להרכיב אותם עבור דביאן 8 ודביאן 10 ללא בעיות.

לאחר מכן, נעשה שימוש ב-TSDuck גרסה 3.19-1520, לינוקס משמשת כמערכת ההפעלה (דביאן 10 שימשה להכנת הפתרון, CentOS 7 שימש לשימוש בפועל)

הכנת TSDuck ומערכת הפעלה

לפני ניטור זרימות אמיתיות, עליך לוודא ש-TSDuck פועל כהלכה ושלא יתרחשו נפילות ברמת כרטיס הרשת או מערכת ההפעלה (שקע). זה נדרש כדי שלא תצטרך לנחש מאוחר יותר היכן התרחשו הנפילות - ברשת או "בתוך השרת". ניתן לבדוק נפילות ברמת כרטיס הרשת עם הפקודה ethtool -S ethX, הכוונון נעשה על ידי אותו ethtool (בדרך כלל צריך להגדיל את מאגר ה-RX (-G) ולעיתים לנטרל כמה ניתוקים (-K)). כהמלצה כללית, רצוי להשתמש בפורט נפרד לקליטת התעבורה המנותחת, במידת האפשר, הדבר ימזער תוצאות חיוביות שגויות בשל העובדה שהירידה התרחשה בו זמנית ביציאת הנתח עקב נוכחות תעבורה אחרת. אם זה לא אפשרי (אתם משתמשים במיני מחשב/NUC עם יציאה אחת), אז כדאי מאוד להגדיר את העדיפות של התעבורה המנותחת ביחס לשאר במכשיר שאליו מחובר המנתח. לגבי סביבות וירטואליות, כאן אתה צריך להיות זהיר ולהיות מסוגל למצוא טיפות מנות החל מהיציאה הפיזית וכלה באפליקציה בתוך המכונה הוירטואלית.

יצירה וקבלה של זרם בתוך המארח

כשלב ראשון בהכנת TSDuck, ניצור ונקבל תעבורה בתוך מארח אחד באמצעות netns.

הכנת הסביבה:

ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0

הסביבה מוכנה. הפעל את מנתח התנועה:

ip netns exec P tsp --realtime -t 
 -I ip 239.0.0.1:1234 
 -P continuity 
 -P bitrate_monitor -p 1 -t 1 
 -O drop

כאשר "-p 1 -t 1" אומר שאתה צריך לחשב את קצב הסיביות בכל שנייה ולהציג מידע על קצב הסיביות בכל שנייה
אנו משיקים מחולל תנועה במהירות של 10 Mbit/s:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

כאשר "-p 7 -e" אומר שאתה צריך לארוז 7 מנות TS לתוך חבילת IP אחת ולעשות את זה קשה (-e), כלומר. תמיד המתן ל-1 מנות TS מהמעבד האחרון לפני שליחת היווצרות של חבילת IP.

המנתח מתחיל להציג את ההודעות הצפויות:

* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/s

עכשיו בואו נוסיף כמה טיפות:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

והודעות כמו זה מופיעות:

* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets 

מה שצפוי. אנו משביתים אובדן מנות (ip netns exec P iptables -F) ומנסים להגדיל את קצב הסיביות של המחולל ל-100 Mbit/s. המנתח מדווח על צרור שגיאות CC ועל 75 Mbit/s במקום 100. אנחנו מנסים להבין מי אשם - המחולל לא עומד בקצב או שהבעיה לא בו, כדי לעשות זאת אנחנו מתחילים לייצר מספר קבוע של מנות (700000 מנות TS = 100000 מנות IP):

# ifconfig veth0 | grep TX
       TX packets 151825460  bytes 205725459268 (191.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID    0 (0x0000):    700,000 packets
# ifconfig veth0 | grep TX
        TX packets 151925460  bytes 205861259268 (191.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

כפי שאתה יכול לראות, נוצרו בדיוק 100000 מנות IP (151925460-151825460). אז אנחנו מבינים מה קורה עם הנתח, כדי לעשות זאת אנחנו בודקים עם מונה ה-RX ב-veth1, הוא שווה בהחלט למונה ה-TX ב-veth0, ואז אנחנו מסתכלים על מה שקורה ברמת השקע:

# ip netns exec P cat /proc/net/udp                                                                                                           
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
  133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 72338 2 00000000e0a441df 24355 

כאן אתה יכול לראות את מספר הטיפות = 24355. בחבילות TS זה 170485 או 24.36% מ-700000, אז אנחנו רואים שאותם 25% מקצב הסיביות האבוד הן נפילות בשקע UDP. נפילות על שקע UDP מתרחשות בדרך כלל עקב מחסור במאגר, ראה מה גודל מאגר השקע המוגדר כברירת מחדל וגודל מאגר השקע המרבי:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

לפיכך, אם יישומים לא מבקשים במפורש את גודל המאגר, נוצרים שקעים עם מאגר של 208 KB, אך אם הם מבקשים יותר, הם עדיין לא יקבלו את מה שביקשו. מכיוון שב-tsp אתה יכול להגדיר את גודל המאגר עבור קלט IP (--buffer-size), לא ניגע בגודל השקע ברירת המחדל, אלא רק נגדיר את גודל המאגר המקסימלי של השקע ונציין את גודל המאגר במפורש דרך הארגומנטים tsp:

sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O drop

עם כוונון זה של מאגר השקע, קצב הסיביות המדווח הוא כעת כ-100Mbps, אין שגיאות CC.

מבוסס על צריכת CPU על ידי יישום tsp עצמו. לגבי מעבד ליבה אחד של i5-4260U @ 1.40GHz, כדי לנתח זרימה של 10Mbit/s, יידרש 3-4% מהמעבד, 100Mbit/s - 25%, 200Mbit/s - 46%. כאשר מגדירים % אובדן מנות, עומס המעבד כמעט אינו עולה (אך עשוי לרדת).

בחומרה פרודוקטיבית יותר, ניתן היה ליצור ולנתח זרמים של יותר מ-1Gb/s ללא בעיות.

בדיקה על כרטיסי רשת אמיתיים

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

שימוש בנתונים שהתקבלו על ידי מערכת הניטור (Zabbix)

ל-tsp אין שום API קריא במכונה כמו SNMP או דומה. הודעות CC צריכות להצטבר לפחות שנייה אחת בכל פעם (עם אחוז גבוה של אובדן מנות, יכולות להיות מאות/אלפים/עשרות אלפים בשנייה, תלוי בקצב הסיביות).

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

1. נתח ואגד (באמצעות CC) את הפלט tsp, כלומר. להפוך אותו לצורה הרצויה.
2. הוסף את ה-tsp עצמו ו/או את התוספים bitrate_monitor ומעבד המשכיות כך שהתוצאה תוצא בצורה קריא מכונה המתאימה למערכת הניטור.
3. כתוב את הבקשה שלך על גבי ספריית tsduck.

ברור שמבחינת עלויות העבודה, אפשרות 1 היא הפשוטה ביותר, במיוחד בהתחשב בכך ש-tsduck עצמו כתוב בשפה נמוכה (בסטנדרטים מודרניים) (C++)

אב טיפוס פשוט של מנתח + אגרגטור ב-bash הראה שבזרימה של 10 Mbit/s ו-50% אובדן מנות (המקרה הגרוע), תהליך ה-bash צרך פי 3-4 יותר CPU מאשר תהליך ה-tsp עצמו. תרחיש זה אינו מתקבל על הדעת. למעשה חלק מאב הטיפוס הזה נמצא למטה

אטריות על באשה

#!/usr/bin/env bash

missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""

ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1  -P continuity 2>&1 | 
while read i
do
    #line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
    #line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
    if [[ "$i" == *continuity:* ]] 
    then
        if [[ "$i" =~ $regexMissPackets ]]
        then
            missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
            if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
            then
                ((ccErrorSeconds += 1))
            fi
            missingPacketsTime=$missingPacketsTimeNew
            packets=${BASH_REMATCH[2]} #TS missing packets
            ((missingPackets += packets))
        fi
    elif [[ "$i" == *bitrate_monitor:* ]]
    then
        : #...
    fi
done

בנוסף לעובדה שזה עובד לאט בצורה בלתי מתקבלת על הדעת, אין שרשורים רגילים ב-bash, משימות bash הן תהליכים עצמאיים והייתי צריך לכתוב את הערך missingPackets פעם בשנייה על תופעת הלוואי (כשמקבלים הודעות bitrate שמגיעות כל שנייה). כתוצאה מכך, bash נותר לבדו והוחלט לכתוב עטיפה (מנתח + אגרגטור) בגולנג. צריכת המעבד של קוד דומה בגולנג היא פי 4-5 פחות מתהליך ה-tsp עצמו. האצת העטיפה על ידי החלפת bash בגולנג הייתה בערך פי 16 ובסך הכל התוצאה מקובלת (תקורה של CPU ב-25% במקרה הגרוע). קובץ המקור של Golang נמצא כאן.

משגר את העטיפה

כדי להפעיל את המעטפת, נוצרה תבנית שירות פשוטה עבור systemd (כאן). ההנחה היא שהמעטפת עצמה מורכבת לקובץ בינארי (עבור לבנות tsduck-stat.go), הממוקם ב-/opt/tsduck-stat/. ההנחה היא שגולאנג משמש עם תמיכה בשעון מונוטוני (>=1.9).

כדי ליצור מופע שירות עליך להפעיל את הפקודה systemctl enable [מוגן בדוא"ל]:1234, ואז הפעל עם systemctl start [מוגן בדוא"ל]: 1234.

תגלית מ-Zabix

כדי ש-zabbix תוכל לגלות הפעלת שירותים, מחולל רשימות קבוצות (discovery.sh), בפורמט הנדרש לגילוי Zabbix, ההנחה היא שהוא ממוקם באותו מקום - ב- /opt/tsduck-stat. כדי להפעיל גילוי באמצעות zabbix-agent, עליך להוסיף קובץ .conf לספרייה עם תצורות zabbix-agent כדי להוסיף פרמטר משתמש.

תבנית Zabbix

נוצר תבנית (tsduck_stat_template.xml) מכיל את כלל הגילוי האוטומטי, אלמנט, גרף ואבות טיפוס של טריגר.

רשימת בדיקה קצרה (מה יקרה אם מישהו יחליט להשתמש בה)

1. ודא ש-tsp לא יפיל מנות בתנאים "אידיאליים" (הגנרטור והאנליזטור מחוברים ישירות), אם יש נפילות, ראה סעיף 2 או טקסט המאמר בנושא זה.
2. בצע כוונון של מאגר השקע המרבי (net.core.rmem_max=8388608).
3. קומפיל את tsduck-stat.go (לכו לבנות tsduck-stat.go).
4. מקם את תבנית השירות ב-/lib/systemd/system.
5. התחל שירותים באמצעות systemctl, בדוק שהמונים החלו להופיע (grep "" /dev/shm/tsduck-stat/*). מספר שירותים לפי מספר זרמים מרובי שידור. כאן ייתכן שיהיה עליך ליצור מסלול לקבוצת ה-multicast, אולי לבטל את rp_filter או ליצור מסלול ל-IP המקור.
6. הפעל את discovery.sh, וודא שהוא מייצר json.
7. הצב את תצורת ה-zabbix agent, הפעל מחדש את ה-zabbix agent.
8. העלה את התבנית ל-zabbix, החל אותה על המארח שעליו מתבצע הניטור ומותקן zabbix-agent, המתן כ-5 דקות, ראה שהופיעו רכיבי נתונים, גרפים וטריגרים חדשים.

תוצאה

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

למעשה, "הפסדים" של CC יכולים להתרחש בעת שחבור קטעי וידאו (עד כמה שידוע לי, כך מתבצעות הוספות במרכזי טלוויזיה מקומיים בפדרציה הרוסית, כלומר מבלי לחשב מחדש את מונה ה-CC), יש לזכור זאת. בפתרונות קנייניים, בעיה זו עוקפת חלקית על ידי זיהוי תגי SCTE-35 (אם הם מתווספים על ידי מחולל הזרם).

מנקודת מבט של ניטור איכות התחבורה, ניטור ריצוד (IAT) אינו מספיק, כי לציוד טלוויזיה (בין אם מאפננים או מכשירי קצה) יש דרישות לפרמטר זה ולא תמיד ניתן לנפח את הג'יטבאפר ללא הגבלת זמן. וריצוף יכול לצוף כאשר המעבר משתמש בציוד עם מאגרים גדולים ו-QoS אינו מוגדר או אינו מוגדר היטב כדי להעביר תעבורה כזו בזמן אמת.

מקור: www.habr.com