nocproject.org

Alguna mujer

Живые есть?

мне всё таки удалось запустить MONGO3

но процессы python, которые не могли с ним соединиться всё ещё загружают процессор на 100%

при попытке зайти в dbshell выдаёт следующее

http://pastebin.com/CK7VDZNF

Кто-нибудь встречался с подобным?

http://pastebin.com/2qBNxavs

исправил порт в настройках postgresql

всё запустилось

всем спасибо

только теперь когда пытаешься в dbshell зайти, требует пароль

fumufu86, и нормально, пароль это правильно, это безопасность

так чего у тебя с монгой?

я вижу только проблемы с постгресом

что за проблемы?

монга огказалась пустой

NOC стал больше грузить процессор

и активаторы почему то не запустил

В итоге

Web запустить удалось, но там пусто

а написал что запустилось

вестимо он к монге не может подключиться

там порт совпадает?

ты посмотри внимательней

или -f start сделай

написал когда увидел что веб запустился

ubuntu@ubuntu ~ % mongo noc

MongoDB shell version: 3.0.1

connecting to: noc

Server has startup warnings:

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten]

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten] ** We suggest setting it to 'never'

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten]

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten] ** WARNING: soft rlimits too low. rlimits set to 31452 processes, 64000 files. Number of processes should be at least 32000 : 0.5 times number of files.

2015-03-21T15:26:05.435+0300 I CONTROL [initandlisten]

>

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

сейчас проверю

bind_ip = 0.0.0.0

#port = 27017

вот из монги

я импортировал в NOC старую базу оборудования через csv импорт

после перезагрузки он эти же устройства показал

где он мог их сохранить если не в монге?

значит норм

fumufu86, мо в постгресе лежат

инвентори и фм в монге

ну раз показывает, значит работает

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

и почему активаторы не запускаются

ну определнно что-то случилось

просто так не угадаешь

надо разбираться

мо должны остаться в постгресе

а вот данные в моенге остались во второй, а третья ессно пустая

все тормозит вестимо из-за того что крешится

а ты логи прячешь

кто проц жрет

там и смотри в лог

http://pastebin.com/PJqYcCNm

процессор жрут процессы которые называются PYTHON

они запускаются noc-launcher.py

из папки opt/noc/script

поставь htop

2015-03-21 17:00:34,722 [root] Authentication failed: Authencication failed for activator 'default'

ну вот видишь

это то я вижу

хотя он может по таймауту просто отваливается потому что у тебя все тормозит

отключи в лаунчере все кроме noc-web

после того как монга и постгрес с вебом поднялись, тормозить стало гораздо меньше

попробуй его одного запустить

и по одному добавляй

в том и дело что они все жрут по немногу

появляются загружаю на 6-11% и исчезают

если исчезают значит падают

или у тебя сортировка такая?

все с расширением .py, и все из папки scripts

раньше падали

теперь нет

больше всего грузит discovery

затем noc-sae.py

просто раньше всё было забито под потолок

а сейчас скачками от 0% до 100%

дисковери и активаторы не работают,

думаю именно они пытаются запуститься постоянно и грузят

2015-03-21 17:14:22,503 [noc.lib.scheduler.scheduler] [inv.discovery] Job ip_discovery("Gorkogo_17") is failed

2015-03-21 17:14:22,504 [noc.lib.scheduler.scheduler] [inv.discovery] Rescheduling job ip_discovery(505) to 2015-03-21 17:24:22.503991 status=W

2015-03-21 17:14:22,559 [noc.lib.scheduler.scheduler] [inv.discovery] Job version_inventory("gorkogo_82a") is failed

2015-03-21 17:14:22,559 [noc.lib.scheduler.scheduler] [inv.discovery] Rescheduling job version_inventory(506) to 2015-03-21 17:24:22.559571 status=W

а влогах лаунчера видно?

что он их постоянно запускаект

может просто подождать

нок при старте весь проц съедает

сейчас проверю, это результат как раз noc-discovery -f start

2015-03-21 17:20:11,950 [root] Authentication failed: Authencication failed for activator 'default'

2015-03-21 17:20:12,951 [noc.sa.activator.activator] Negotiation protocol 'NOC SAE PROTOCOL (http://nocproject.org/)' version '1.0'

2015-03-21 17:20:12,980 [noc.sa.activator.activator] Protocol version negotiated

2015-03-21 17:20:12,994 [noc.sa.activator.activator] Registering as 'default'

2015-03-21 17:20:13,007 [noc.sa.activator.activator] Registration accepted

2015-03-21 17:20:13,008 [noc.sa.activator.activator] Authenticating as default

2015-03-21 17:20:13,012 [root] Authentication failed: Authencication failed for activator 'default'

снова пароль

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

но это не должно так грузить

но все равно чини

nfr

так

исправил

активаторы есть

а нагрузка

вроде увеличилась

шикарно

а почему

хз

но

теперь горы стали уже и чаще

в графе загрузки процессора

я думаю что дисковери, дисковерит, все коммутаторы теперь

я же их csv afqkjv lj,fdbk

csv файлом добавил

и теперь он их все проверяет

иногда discovery.py один съедает до 25%

не, дискавери только шедулит задачи

а отрабатывает их сае

совместно с активаторами

но ты в логи то посмотри

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

или херней мается

написано команда запуска opt/noc/python ./scripts/noc-discovery.py launch -c etc/noc-discovery.conf -i 0

'nj ghjwtccrf rjnjhsq uhepbn ghjw

это из процесса, который грузит проц

логи шелудера или активатора?

дискавери

он же грузит

надо понять что он делает

лог весит 3 гига

я до конца этого лога врятли доберусь

его удалить можно?

да

[main]

logfile = /var/log/noc/noc-discovery.log

loglevel = info

logsize = 50000000

logfiles = 1

удалил

мне пустой создать самостоятельно?

2015-03-21 18:07:04,966 [noc.lib.scheduler.job] [inv.discovery][ip_discovery][944] Running job

2015-03-21 18:07:04,967 [noc.lib.scheduler.job] [inv.discovery][ip_discovery][944] Running script get_ip_discovery

2015-03-21 18:07:05,100 [noc.lib.scheduler.job] [inv.discovery][caps_discovery][488] Running job

2015-03-21 18:07:05,127 [noc.lib.scheduler.job] [inv.discovery][caps_discovery][488] Running script get_capabilities

2015-03-21 18:07:05,200 [noc.lib.scheduler.job] [inv.discovery][id_discovery][490] Running job

2015-03-21 18:07:05,201 [noc.lib.scheduler.job] [inv.discovery][id_discovery][490] Running script get_discovery_id

2015-03-21 18:07:05,254 [noc.lib.scheduler.job] [inv.discovery][config_discovery][485] Running job

2015-03-21 18:07:05,256 [noc.lib.scheduler.job] [inv.discovery][config_discovery][485] Running script get_config

2015-03-21 18:07:05,376 [noc.lib.scheduler.job] [inv.discovery][version_inventory][509] Running job

2015-03-21 18:07:05,378 [noc.lib.scheduler.job] [inv.discovery][version_inventory][509] Running script get_version

2015-03-21 18:07:05,413 [noc.lib.scheduler.job] [inv.discovery][interface_discovery][494] Running job

2015-03-21 18:07:05,414 [noc.lib.scheduler.job] [inv.discovery][interface_discovery][494] Running script get_interfaces

вот содержание файла discovery

ну значит работает

дай ему делать его дело

кстати посмотри в failed scripts

чтобы ничего не падало

если ты о sa>report>failed scripts

то там полно всякого

но дело скорее в том что я базу mo старую туда запихнул

nfv vyjuj xtuj yt nfr

nfv много чего не так

*там

кстати что за странность, когда в MO делаешь refresh, в нём пусто пока не прокрутишь до самого низа

это глюк экста, это не только мо, это повсеместно и уже подзадрало, если честно

вроде в default ветке этого не было

что значит экста?

ext

не было

недавно сломали

есть ещё один вопрос, который я постоянно задавал и меня после него начинали игнорировать. Куда делось удаление помеченных коммутаторов, и почему теперь помеченным коммутаторам нельзя сменить profile object.

./noc wipe

делось потому что не реализовали

так было и работало же ведь

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

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

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

было его в новом интерфейсе

если мне склероз не изменяет

к сожалению не могу преджоставить скриншотов, но default ветка, которая была в середине февраля 2015 точно имела