логи discovery для начала смотри

что там у тебя

вруби debug в discovery

Дим.

2016-04-13 16:34:41,645 [discovery] ************************************************************************ 2016-04-13 16:34:41,740 [discovery] Loading config from etc/noc.yml 2016-04-13 16:34:41,808 [discovery] Running service discovery (pool: default) 2016-04-13 16:34:41,809 [discovery] Activating service

2016-04-13 16:45:47,539 [script] [Cisco.IOS.get_fqdn|10.111.0.8] Running. Input arguments: {}, timeout 120

где здесь 6000 секунд ?

оно сразу после старта начало ломиться на железки

как мне запретить это ?

я тбе об этом повторял 100500 раз уже

дебаг на discovery поставь

и посмотри

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

посмотри, что именно у нее не получается

получается

все получается

где в логах discovery запись, что задача отработала?

впилил nsq в плейбук

отестирован только под rhel

дjлжен взлететь под дебиан тоже

сейчас пойду его доверять

2016-04-13 16:45:59,215 [scheduler.discovery] [3] [discovery|box|C3560-8] Completed. Status: SUCCESS (21140.10ms) 2016-04-13 16:45:59,215 [scheduler.discovery] [3] [discovery|box|C3560-8] Timings: profile = 61.65ms, version = 243.40ms, caps = 1949.18ms, interface = 5285.88ms, id = 1855.18ms, caps = 3873.03ms, asset = 1985.63ms, vlan = 1846.02ms, lldp = 1799.34ms, cdp = 169.99ms, stp = 1973.33ms

поотключал "is managed" на железках. буду включать по одной и смотреть

@dvolodin можно ли сделать, чтобы если стоит max-scripts 1, то таймаут между запусками скриптов был где-то секунд 10 ?

а лучше минута или две

данунах

15к железок, представь

да даже 1к

имеется ввиду для одной железки

сейчас такая картина:

2016-04-13 16:45:45,846 [script] [Cisco.IOS.get_chassis_id|10.111.0.8] Running. Input arguments: {}, timeout 120 2016-04-13 16:45:47,537 [script] [Cisco.IOS.get_chassis_id|10.111.0.8] Complete (1690.58ms) 2016-04-13 16:45:47,537 [noc.core.script.loader] Loading script Cisco.IOS.get_fqdn 2016-04-13 16:45:47,539 [script] [Cisco.IOS.get_fqdn|10.111.0.8] Running. Input arguments: {}, timeout 120

как мы видим, время между запусками двух скриптов - аж целых 2 миллисекунды

железка тупо не успевает завершить ssh сессию

а не в рамках ли одной ssh сессии выполняются скрипты? @dvolodin

нет, не в одной

он просто шустрый стал

RP/0/RSP0/CPU0:Apr 13 10:51:48.861 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:52:00.455 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:52:38.881 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:52:50.369 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:52:58.834 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:53:10.353 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:53:28.836 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:53:40.341 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:53:48.839 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:54:00.280 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:54:11.844 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:54:23.317 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:54:32.839 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:54:44.330 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:54:52.878 : exec[65782]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:55:09.216 : exec[65782]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:55:10.041 : exec[65766]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:55:11.114 : exec[65766]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out RP/0/RSP0/CPU0:Apr 13 10:55:11.939 : exec[65766]: %SECURITY-LOGIN-6-AUTHEN_SUCCESS : Successfully authenticated user 'nocproject' from '10.50.64.64' on 'vty0' RP/0/RSP0/CPU0:Apr 13 10:55:14.369 : exec[65766]: %SECURITY-LOGIN-6-CLOSE : User 'nocproject' logged out

только Juniper не успевает за ним :(

Меня это тоже немного раздражает :)

@dvolodin смотри

@dvolodin http://pastebin.com/CE6h8cui

закончилась дисковери

спустя секунд 20 после этого

last pid:   973;  load averages:  9.51,  5.56,  2.72   up 202+02:09:45 18:05:34 113 processes: 10 running, 103 sleeping CPU states: 40.0% user,  0.0% nice, 56.5% system,  3.4% interrupt,  0.0% idle Mem: 1246M Active, 79M Inact, 175M Wired, 376M Cache, 112M Buf, 108M Free Swap: 2837M Total, 2837M Free   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND  1692 root        1  99    0 47580K 31964K select  19.4H 23.10% pfed   922 root        1 132    0 43116K  7344K RUN      0:11  5.66% ifinfo   895 root        1 132    0 43116K  7344K select   0:13  5.66% ifinfo   949 root        1 132    0 43116K  7344K RUN      0:09  4.00% ifinfo   868 root        1 132    0 43116K  7344K RUN      0:13  3.76% ifinfo   841 root        1  -8    0 43116K  7344K pipewr   0:16  3.71% ifinfo   871 mitya       1 132    0 51796K 40876K RUN      0:09  3.17% cli   898 mitya       1 132    0 51796K 40872K select   0:08  2.98% cli   844 mitya       1 132    0 51796K 40876K select   0:10  2.49% cli   925 mitya       1 132    0 51796K 40876K RUN      0:07  2.39% cli   817 mitya       1 132    0 51796K 40876K RUN      0:12  2.00% cli

продолжает колбасить Juniper

и в это же время, потому как сбросился max-scripts

2016-04-13 18:00:31,892 [scheduler.discovery] [5] [periodic] Starting 2016-04-13 18:00:31,899 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|uptime] Checking uptime 2016-04-13 18:00:32,069 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|uptime] Received uptime: None 2016-04-13 18:00:32,070 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|metrics] Collecting metrics 2016-04-13 18:00:32,189 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|metrics] No metrics found 2016-04-13 18:00:32,189 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T] Completed. Status: SUCCESS (297.06ms) 2016-04-13 18:00:32,189 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T] Timings: uptime = 170.23ms, metrics = 119.33ms

начинает ломиться периодик

какие тебе еще дебаги показать ?

ну так это нормально

дальше-то тихо?

нет, конечно

2016-04-13 18:04:53,470 [scheduler.discovery] [5] [discovery|box|Juniper MX5-T|interface] Using noc.solutions.noc.default.discovery.interface.get_interface_profile for interface classification 2016-04-13 18:04:53,470 [scheduler.discovery] [5] [discovery|box|Juniper MX5-T|interface] Checking interfaces

мы же не смогли выгрести get_interfaces

и пошло по кругу

дебаг включи

в etc/noc.yml

и дерни его

там покажет, как оно обновляет расписания

ДИМ !!!!!!!!!!!!!!!

2016-04-13 18:00:32,069 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|uptime] Received uptime: None 2016-04-13 18:00:32,070 [scheduler.discovery] [5] [discovery|periodic|Juniper MX5-T|metrics] Collecting metrics

еще раз

если хочешь разобраться, включай дебаг

невооруженным глазом видно, что следующий скрипт начинает ломиться через миллисекунду после завершения предыдущего

это нормально

А в это время загрузка CPU 100%

на железке

от аптайма-то?

начнем с того, что он по snmp его получает

ты притворяешься, что не понимаешь ?

Я тот же самый срач читал год назад

2016-04-13 18:08:11,870 [scheduler.discovery] [5] [discovery|box|Juniper MX5-T] Timings: profile = 1582.48ms, version = 5096.34ms, caps = 1393.30ms, interface = 185632.73ms, id = 2345.76ms, caps = 7095.29ms, asset = 3317.28ms, oam = 1.04ms, lldp = 0.83ms, cdp = 0.17ms, stp = 0.17ms

ищи там update(.....)

Теперь он в телеграмм?

last pid:  1221;  load averages:  9.12,  6.41,  4.11   up 202+02:21:11 18:17:00 109 processes: 7 running, 101 sleeping, 1 zombie CPU states: 47.0% user,  0.0% nice, 50.1% system,  2.9% interrupt,  0.0% idle Mem: 1226M Active, 79M Inact, 175M Wired, 377M Cache, 112M Buf, 126M Free Swap: 2837M Total, 2837M Free   PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND  1692 root        1  99    0 47580K 31964K select  19.4H 11.23% pfed  1166 root        1 132    0 43116K  7344K RUN      0:13  8.45% ifinfo  1139 root        1 132    0 43116K  7344K RUN      0:13  6.69% ifinfo  1193 root        1 132    0 43116K  7344K RUN      0:12  5.08% ifinfo  1142 mitya       1 131    0 51796K 40872K select   0:09  4.54% cli  1085 root        1  -8    0 43116K  7344K pipewr   0:16  3.76% ifinfo  1115 mitya       1 131    0 51796K 40872K select   0:10  3.52% cli  1169 mitya       1 132    0 51796K 40872K RUN      0:08  2.59% cli  1143 root        1 131    0 52928K  4416K select   0:05  1.61% mgd  1061 mitya       1 132    0 51796K 40872K RUN      0:12  1.37% cli

чем же таким занимается железка, если все скрипты завершились ?

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

есть 2 типа job'ов

каждый запускает по несколько скриптов по очереди

что тебя смущает?

еще раз повторюсь

скрипт грузит CPU на 100%

Загрузка CPU не успевает уменьшится,, как уже запускается другой скрипт

слушай, даже твои любимые dlink'и от этого не мрут

В результате скрипт отрабатываее "криво", попадает в Failed, и начинается все по новой

вот как оно начинает по новой - ты не показал

выше было

отработал box discovery

загрузка CPU 100%

начинает работать periodic discovery

и я на pastebin кидал

обрати внимание на время:

2016-04-13 18:07:59,102 [scheduler.discovery] [5] [discovery|box|Juniper MX5-T|interface] UNHANDLED EXCEPTION (2016-04-13 18:07:59.096234)

END OF TRACEBACK 2016-04-13 18:07:59,103 [scheduler.discovery] [5] [discovery|box|Juniper MX5-T|id] Checking chassis id

роутер колбасит, а в это время туда лезет NOC со скриптом get_chassis_id

вот у тебя трейсик есть

покажи

http://pastebin.com/CE6h8cui