Jump to content
Калькуляторы

Скрипт изменения уровня сигнала c отправкой на почту.


Как это можно написать на языке программирования микротика?
Уверен что много кому будет полезно.

if (ccq<40%) then emaill(email;ccq;radioname)
if (TXsignalstrech>80) then emaill(email;txsignalstrech;radioname)

if (RXsignalstrech>80) then emaill(email;rxsignalstrech;radioname)


----------------------------------

И еще такой вариант с выборкой.

badstation:array[station1,station4] of ccqname;
goodstation:array[station2,station3] of ccqname;
for i:=1 to length(badstation) do
  if (badstation<40%) then emaill(email;ccq;radioname)
for i:=1 to length(goodstation) do
 if (goodstation<60%) then emaill(email;ccq;radioname)
 

Edited by malench

Share this post


Link to post
Share on other sites

Можно, когда устройств не много, а если их огого как много? тут сигнал на секунду провалился, там) Разорваться? Я отношусь к этому проще, пропал пинг к устройству, прилетела смска, понимаешь что это уже проблема. По вопросам тупит интернет, можно разобраться и выяснить что сам комп у абона засран непонятно чем, либо на стареньком андроиде wifi глючит пока не перезагрузишь. Хочешь изредка мониторить происходящее, дудка в помощь!

Edited by 777BLOODER777

Share this post


Link to post
Share on other sites

Если вам нужно следить за сетью, то достаточно проверкой пинга до всего оборудования и по задержке можно определить, есть проблема, или нет. При отсутствии проблем задержка 1-10мс (образно), если перегруз, упали сигналы и т.п., она подскакивает до 30-200 и выше. Вот тут можно уже искать где и что не так.

 

Другой вариант проводить опрос из центра по ssh, заодно можно и конфиги собирать. А делать скрипты на устройствах - ну когда штук 10 еще можно, а когда переваливает за 100 - придет 100 писем, половину из которых почтовый сервер за спам заблочит.

Share this post


Link to post
Share on other sites

ssh, о боже, а кто-то в соседней теме о новых технологиях писал...

у ммкротика вменяемый snmp, зачем грузить сеть ssh тоннелями?

скриптинг иногда полезен, ну и знать как и делать на боевую -- две разные вещи.

Share this post


Link to post
Share on other sites
2 часа назад, NewUse сказал:

у ммкротика вменяемый snmp, зачем грузить сеть ssh тоннелями?

А грузить микротик запросами через snmp лучше?

А все ли можно поменять или перенастроить через snmp?

А как конфигурацию через snmp снять?

А как работать с разными версиями микротиков, начиная с первых 5 ветки и заканчивая 6.43?

 

Гораздо проще через ssh раз в день подключаться и проверять все данные. А потом полученную информацию уже раскладывать по полочкам.

И самое важное скажу - весь этот контроль за оборудованием вообще не нужен, т.к. что толку, если сигналы упали? Проблема это когда абонент услугу не получает или нужная скорость не проходит. Но тут проще пусть сам абонент пожалуется, тогда и решать проблему. Весь этот контроль и обслуживание работают только в малых сетях. Когда сеть большая, например 10000 устройств, то все равно сил монтажников не хватит, устранять плановые неисправности. Или это будет стоить очень дорого по финансам, и провайдер не сможет это обеспечивать.

Share this post


Link to post
Share on other sites

@Saab95, не надо так категорично. Никто не говорит о контроле за активностью 10000 CPE, однако всегда есть важные узлы, о проблемах на которых важно оперативно (а желательно заранее) узнавать и, соответственно, принимать необходимые меры по устранению поломок.

Share this post


Link to post
Share on other sites
3 часа назад, Saab95 сказал:

устранять плановые неисправности

Хорошо сказано. Это видимо веяние современных микротиковских технологий.

Share this post


Link to post
Share on other sites

Плановые неисправности это те, которые нашли удаленно - например порт в 10М переключился, но у абонента тариф меньше и на работу не влияет. Или сигналы на мосту упали, но нужная скорость проходит и т.п. То есть их нужно не прямо сейчас устранять, а по мере возможности.

 

19 часов назад, letter сказал:

однако всегда есть важные узлы

Если узлы важные - можно посадить человека, который будет смотреть за мониторингом и определять что сломалось и что нужно сделать. Если сеть не настолько большая, то надо понимать, что там может случиться - отключиться питание, отключиться кабели и т.п. Опять же это все проверять можно внешней системой, а не скриптами на оборудовании.

Share this post


Link to post
Share on other sites

Вообще-то достаточно было перефразировать в «плановое устранение неисправностей».

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

Если порт переключился в 10М, то проблема тут не в том, что тариф абонента больше или меньше, а в том, что на физике авария. Но нет, это плановая неисправность.

Да, с таким подходом это действительно запланированная неисправность.

Share this post


Link to post
Share on other sites
52 минуты назад, alibek сказал:

Да, с таким подходом это действительно запланированная неисправность.

Да мужчина просто имел ввиду, что ремонт такой аварии можно поставить в график плановых работ.

А не срочно выезжать роняя трусы.

Как-то так.

 

 

23 часа назад, Saab95 сказал:

А как конфигурацию через snmp снять?

начало ветки не читал.

конфигурацию снимать и.т.п.  лучше ансимблем

вместо опросов можно в принципе сделать трапы, будет грузить меньше

ну плюс редкие опросы на случай утерянных трапов

 

 

Я такие вещи как изменения статусов интерфейсом нормально собираю zabbix.

Частый опрос там не нужен, так как достаточно последнее время подьема порта опрашивать. ( редко )

и видеть когда были флапы

 

Share this post


Link to post
Share on other sites

C скриптом сам разобрался уважаемые гуру, вот он. 

/interface wireless registration-table
:foreach i in=[ /interface wireless registration-table find ap=no] do={
   :if ([get $i tx-ccq] < "70" && [get $i rx-ccq] < "70") do={
           :log warning ([get $i radio-name] . " was disconnected due to low CCQ - Tx: " . [get $i tx-ccq] . "% / Rx: " . [get $i rx-ccq] . "%")
           :local a ([get $i radio-name] . " was disconnected due to low CCQ - Tx: " . [get $i tx-ccq] . "% / Rx: " . [get $i rx-ccq] . "%")
           /tool e-mail send  to="XXXXX@gmail.com"  subject=$a
           /interface wireless registration-table remove $i           
           :delay 5s 
        
  }
}

Пришлось самому пилять, все таки Delphi не так похож на язык Mikrotik.
По городу стоят камеры Dahua с Микротиками.
Из практики, отключили свет в одной части города, база забивает почту сообщениями что пропал пинг. И шлет не одно по одному узлу, а по 5-10. Потом включили, потом опять выключили. И т.д. Вся почта в сообщениях от базы.
Вариант с пингом плохой как не крути.
Вопрос стоит в ухудшении качества линка, вот его и надо решать на прямую, а не в обход.

Edited by malench

Share this post


Link to post
Share on other sites
15 часов назад, malench сказал:

Из практики, отключили свет в одной части города, база забивает почту сообщениями что пропал пинг. И шлет не одно по одному узлу, а по 5-10. Потом включили, потом опять выключили. И т.д. Вся почта в сообщениях от базы.
Вариант с пингом плохой как не крути.

Плохой если на почту отправлять с оборудования. А если мониторинг поставить, например Dude, он сам все проверит, все выходы из строя запомнит, карту сети нарисует. И, между прочим, сам умеет, если что, отправлять информацию на почту.

 

21 час назад, LostSoul сказал:

вместо опросов можно в принципе сделать трапы, будет грузить меньше

Микротик умеет рассылать логи по событиям, если на сети потерей больших нет, обычно ничего не теряется.

 

То есть если слушать логи, и пришло событие о падении порта, или переключении скорости, или по радио кто-то отключился, можно сделать запрос на устройство для уточнения. Например если клиент не вернется через минуту обратно. По сути нужна комплексная система, которая работает с оборудованием по разным каналам.

Share this post


Link to post
Share on other sites
31 минуту назад, Saab95 сказал:

То есть если слушать логи, и пришло событие о падении порта,

можно все что угодно.

но стандартно для этого служит snmp trap  , события которого определены по mib

а в логе могут в каждом релизе что-нибудь отвернуть по формату. я уже не говорю про локализацию

 

Share this post


Link to post
Share on other sites
Только что, LostSoul сказал:

можно все что угодно.

но стандартно для этого служит snmp trap  , события которого определены по mib

а в логе могут в каждом релизе что-нибудь отвернуть по формату. я уже не говорю про локализацию

 

snmp trap как будет работать, если 10 тысяч устройств шлет события?

А как snmp влияет на работу микротика?

В логах формат не меняется, что в 5 версии, что в последних 6 - все по той же схеме.

 

Вот и получается, что для решения задачи нужна полностью своя система обработки, а не брать что-то готовое бесплатно.

Share this post


Link to post
Share on other sites
47 минут назад, Saab95 сказал:

snmp trap как будет работать, если 10 тысяч устройств шлет события?

А как snmp влияет на работу микротика?

snmp trap с 10 тысяч устройств будет работать лучше, чем syslog с 10 тысяч устройств

( размер данных меньше , они нормализированы ) и мусора меньше, так как более четко определяется что слать.

snmp на работу микротика не влияет никак.

точно не сильнее, чем отладночный syslog в сеть

 

 

своя система не обязательна , мибы универсальны и подгружаются в разные нмс

 

 

а имена и статусы интерфейсов это вообще стандартные oid , универсальные не только для микротиков

то есть в любой nms корректно будут поняты эти трапы прямо из коробки

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now