[denis21]

Сабж. Возможно ли? Или кто какие решения для этого использует?

[s.lobanov]

а вы наличие хотите мониторить или же какие конкретные характеристики потоков?

[denis21]

Наличие звука, изображения. Думаю это самое основное.

[Negator]

ну наверное можно пробовать делать tcpdump в файл, потом скармливать все это Нагиосу.

Типа файл пустой -все плохо.

[s.lobanov]

ну наверное можно пробовать делать tcpdump в файл, потом скармливать все это Нагиосу.

Типа файл пустой -все плохо.

 

Ну так это мониторинг наличия потока, а не проверка того, что есть звук и видео. Просто наличие можно с некоторых коммутаторов/маршрутизаторов снять по SNMP.

[agr]

Есть парочка проектов на эту тему

http://www.iptv-analyzer.org/wiki/index.php/Main_Page

http://www.netup.tv/ru-RU/iptvprobe.php

 

они могут мониторить наличие потока, дропы, некоторые параметры mpeg потока. Интеллектуально мониторить наличие картинки и звука не умеют.

[roysbike]

Сабж. Возможно ли? Или кто какие решения для этого использует?

В статье упоминают про хавание видео и звука, для проверки потока. http://habrahabr.ru/post/66351/

[denis21]

Сабж. Возможно ли? Или кто какие решения для этого использует?

В статье упоминают про хавание видео и звука, для проверки потока. http://habrahabr.ru/post/66351/

Cпасибо. Попробую.

[anix]

Есть парочка проектов на эту тему

http://www.iptv-anal...x.php/Main_Page

http://www.netup.tv/...U/iptvprobe.php

 

они могут мониторить наличие потока, дропы, некоторые параметры mpeg потока. Интеллектуально мониторить наличие картинки и звука не умеют.

iptvprobe на убунте 12.04 падает коллектор при попытке подать поток на сенсор. iptv-analyzer работает из коробки, единственное не считает битрейт (у автора это в плане), но битрейт можно считать самим. после запуска модуля iptables, модуль ведет статистику в которой есть вся нужная для подсчета битрейта информация.

[LostSoul]

Сабж. Возможно ли? Или кто какие решения для этого использует?

В статье упоминают про хавание видео и звука, для проверки потока. http://habrahabr.ru/post/66351/

 

Там просто проверяют наличие данных. А то что в картинке "квадрат малевича" а в звуке "белый шум" - не проверяется.

 

Мне думается что для нормальной проверки и видео и звук нужно пытатся сжать каким-нибудь ffmpeg и потом посмотреть какой коофициент сжатия получается. В случае "Белого шума" коофициент сжатия будет слишком низок, в случае "чёрного экрана" или иной статической картинки сожмется слишком хорошо. Вот и сигнал о наличии проблем.

[peksus]

ну наверное можно пробовать делать tcpdump в файл, потом скармливать все это Нагиосу.

Типа файл пустой -все плохо.

 

Вот, от нефиг делать сделал плагин check_iptv, мониторящий трафик через udp proxy, показывает бит-рейт! :)

wget'ает в теч. заданного времени ссылку "http://{HOST}/udp/{UDP}", определяет размер wget-нутого файла и определяет средний бит-рейт

Если wget-нутый файл нулевой, то стрима нет.

Мне более и не надо, и оч. наглядно оказалось.

Канал если на стримере упал, то он и не вещается в сеть. А если картинки или звука нет, то у меня такое за 3-года если и было, то не по вине стримеров - а именно так вещали источники.

 

в services прописываем check_iptv!{HOST}!{UDP}!, например check_iptv!10.10.10.10:14444!239.1.1.1:1234!

 

#!/bin/sh
#!/bin/sh

### CHECK HTTP STREAM through UDPXY###
if [ -z $1 ] || [ -z $2 ]; then
       echo "Check IPTV stream through UDP PROXY for Nagios"
       echo "Downloaded URL with WGET during defined TIME, analyse SIZE downloaded file and calculate bitrate"
       echo "URL have next form: 'http://<UDP_PROXY_HOST:PORT>/udp/<MULTICAST_GROUP:PORT>'"
       echo "Syntax: check_iptv <UDP_PROXY_HOST:PORT> <MULTICAST_GROUP:PORT> <THRESHOLD_MAX> <THRESHOLD_MIN> <TIME>"
       echo "  <UDP_PROXY_HOST:PORT>   - UDP Proxy host (required)"
       echo "  <MULTICAST_GROUP:PORT>  - Multicast group (required)"
       echo "  <THRESHOLD_MAX>         - Threshold MAX, Mbit/s, for WARNING code in Nagios, default 6Mbit/s (optional)"
       echo "  <THRESHOLD_MIN>         - Threshold Min, Kbit/s, for WARNING code in Nagios, default 500Kbit/s (optional)"
       echo "  <TIME>                  - Downloaded time, second, default 5 seconds (optional)"
       exit 3
fi
host=$1
udp_host=$2
url="http://$host/udp/$udp_host"
#echo $url
tmp_file="/tmp/check_$udp_host"
#command="/usr/bin/curl $url | head -100 > $tmp_file"
if [ -z $5 ]; then 
       time=5
else
       time=$5
fi
if [ -z $3 ]; then
       threshold_max_mbit=6
else
       threshold_max_mbit=$3
fi
if [ -z $4 ]; then
       threshold_min_kbit=500
else
       threshold_min_kbit=$4
fi
let threshold_bytes_max=($threshold_max_mbit*1024*1024)/8*$time
let threshold_bytes_min=($threshold_min_kbit*1024)/8*$time
#echo $threshold_bytes_min
command="/usr/bin/wget -O $tmp_file $url"


STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

#echo "/usr/bin/curl $url | head -100 > $tmp_file"
($command > /dev/null)&
pid=$!
sleep $time
kill -9 $pid
s=`stat -c %s $tmp_file`
#let s=$s*8/1024/1024/$time
s_mbit=`expr \( $s \* 8 \) \* 100 / 1024 / 1024 / $time | sed 's/..$/.&/'`
if [ $s = 0 ]; then 
       echo $s_mbit"Mbit/s - http://$host/udp/$udp_host"
       exit $STATE_CRITICAL
fi
if [ $s -gt $threshold_bytes_max ] || [ $s -lt $threshold_bytes_min ]; then
       echo $s_mbit"Mbit/s - http://$host/udp/$udp_host"
       exit $STATE_WARNING
fi
if [ $s -gt 0 ]; then
       echo $s_mbit"Mbit/s - http://$host/udp/$udp_host"
       exit $STATE_OK
else
       echo "$s - UNKNOWN"
       exit $STATE_UNKNOWN
fi
rm -Rf $tmp_file

Изменено 18 октября, 2013 пользователем peksus

[vurd]

Вообще наличие потока не показатель.

 

У нас сделано так:

VLC берет поток, пишет его в файл, через 10 секунд проверяется размер этого файла, если не нулевой, то всё ок.

Таким образом отлично ловятся малевичи, поток которых идёт и не будет пойман способом в предыдущем посте.

[Negator]

Спасибо за плагин, нужно попробовать, пока руки не доходили до подобных проверок.

[Ivan_83]

Проблема мониторинга IPTV в головах.

IPTV это поток, непрерывный как река, а его пытаются классифицировать по принципу: пациент жив/мёртв.

Хотите мониторить - снимайте поток на постоянку, считайте СС, хотя бы.

[vurd]

Проблема мониторинга IPTV в головах.

IPTV это поток, непрерывный как река, а его пытаются классифицировать по принципу: пациент жив/мёртв.

Хотите мониторить - снимайте поток на постоянку, считайте СС, хотя бы.

 

Проблема мониторинга в объемах трафика. Отмониторьте мне пожалуйста хотя бы 500 мбит мальтикаста с детальными графиками по каждому потоку.

[s.lobanov]

Проблема мониторинга IPTV в головах.

IPTV это поток, непрерывный как река, а его пытаются классифицировать по принципу: пациент жив/мёртв.

Хотите мониторить - снимайте поток на постоянку, считайте СС, хотя бы.

 

Проблема мониторинга в объемах трафика. Отмониторьте мне пожалуйста хотя бы 500 мбит мальтикаста с детальными графиками по каждому потоку.

 

ну а в чём собственно проблема? посмотрите сколько vlc кушает CPU на декодирование одного канала, посчитайте сколько серверов для этого потребуется, окажется, что не так уж и много, если CPU будет современный и vlc не древний

 

несколько сложнее мониторить поток, если он к вам шифрованный приходит

[maxlapshin]

вообще-то на процессоре декодировать H.264 затратнее, чем его кодировать.

 

libx264 писался гениальными людьми, а декодер писали по принципу «лишь бы завелось, всё равно все смотрят на видюхе»

[Ivan_83]

Проблема мониторинга в объемах трафика. Отмониторьте мне пожалуйста хотя бы 500 мбит мальтикаста с детальными графиками по каждому потоку.

А там и не нужно декодировать до состояния показа. Достаточно разобрать mpeg2-ts заголовки и немного инфы от туда. При этом основная нагрузка будет в ядре ОС.

На 500 мегабит хватит одного ядра проца уровня коредуо.

[Negator]

а его пытаются классифицировать по принципу: пациент жив/мёртв.

Да, а что тут такого?

Во первых у меня поток кодированный приходит -это раз.

Во вторых знать работает ли вообще хоть что то тоже надо. Потому что львиная часть проблем говорит о том, что потока вообще нет.

А про качество - разговор отдельный.

[Ivan_83]

Да, а что тут такого? Во первых у меня поток кодированный приходит -это раз. Во вторых знать работает ли вообще хоть что то тоже надо. Потому что львиная часть проблем говорит о том, что потока вообще нет. А про качество - разговор отдельный.

Бывает так, что вместо 200-500 килобайт/сек льётся 10-100 и мониторилка покажет что пациент скорее жив, а по факту он мёртв.

Или льётся примерно как нужно, а вот СС зашкаливает и смотреть не возможно.

Те нельзя полагаться на только битрейт, нужно и в сам потом заглядывать, и делать это не эпизодически а постоянно, потому что СС даже пару раз в минуту уже сильно портит удовольствие от просмотра.

Наличие шифрования в mpeg2-ts указывает всего 2 бита в заголовке, всё остальное не меняется, те на разбор и анализ потока никак не влияет.

Там система такая: mpeg2-ts - это контейнер, типа как IP, внутри него уже может быть мпег2, мпег4, аац и что угодно ещё. Вот содержимое выборочно шифруется, а сам mpeg2-ts (его заголовки) - нет.

 

Ситуация когда mpeg2-ts полностью валиден а внутри него мусор в принципе возможна, но маловероятна.