About Forum Blogs NOC Docs Downloads KB Issues Code CI Registration

nocproject.org

#nocproject.org at irc.freenode.net log.
Back to nocproject.org Back to IRC log index
Date: 08.08.2011
lexus-omsk #
01:45
всем привет!
01:45
а кто-нибудь наступал уже на грабли, что mongo ругается на нехватку 32 бит под адресацию? типа давайте 64 :)
01:53
вроде и девайсов-то меньше 800, события даже не со всех идут, база около 2.5 гигов на диске
02:29
засада, теперь на любую попытку что-то сделать в mongo получаю ответ: can't map file memory - mongo requires 64 bit build for larger datasets
02:30
так даже записи не почистить лишние...
zi_rus #
05:26
lexus-omsk, это очень прекрасный прецедент, я на работе уже устал доказывать, что надо ставить 64битные системы и софт, а мне контраргументируют, что РАЕ работает нормально значит хватит и обычных х86, а все остальное типа 64бит это баловство и никому не надо
lexus-omsk #
05:28
это подстава на самом деле... предупредили бы хоть, что так быстро кончится... а теперь ищи новую машинку, где всё поднимать, начиная с системы... пришлось базу тупо грохнуть, иначе noc вообще встал...
05:29
А так у нас тоже не используется 64 нигде...
gnu-linux #
05:34
Хочу занятся поддержкой национального производителя :) Написал правила ивентов для Alentis NetPing и завёл профиль..
05:35
Alentis поддерживает управление только по SNMPv1 и HTML...
05:36
Давайсы интересны но пока они не осилят SNMPv2 и telnet/ssh сервер в своих прошивках толку с них никакого не будет...
05:38
Также держу в руках Eltex RG-1404G-W они более продвинуты имеют telnet/ssh и возможно хорошо будут управлятся ноком :)
lexus-omsk #
05:44
это как я 3Com-ы старые пытался в noc добавить - у них тоже snmp v1 и телнет... ну и тормозной web
gnu-linux #
05:46
У старых 3com хоть telnet есть.. У девайсов Alentis даже его пока нет....
05:47
А вот девайсы Новосибирцев http://eltex.nsk.ru/ вполне можно будет в нок добавить...
zi_rus #
05:47
lexus-omsk, я поверю что 32бита остались с древних времен, но ставить на новую машину 32бита - это <очень плохое слово>. преимущество 64бит это как с ipv6 самое заметное - увеличение адресного пространства, но все обычно забывают что ipv6 это не только 128битные адре
05:47
са, так и 64битной архитектурой, там не только много памяти можно использовать, есть и другие преимущества, с таким случаем вы и столкнулись, надеюсь теперь, хотя бы для серверов будете использовать именно 64битные ОС
lexus-omsk #
05:49
да там бага была, oracle клиент под freebsd не работал в 64 битной версии, вот и вошло в привычку ставить i386
dvolodin #
05:55
lexus-omsk: да, у 32-битной версии монго ограничение на размер базы
06:09
Перед релизом обновим доку
Dmitry1 #
06:19
zi_rus: а чем тебя 32 бита не устраивают?
zi_rus #
06:20
это архитектура прошлого века, у 64бит есть явные преимущества, почему их не использовать?
Dmitry1 #
06:21
какие преимущества, если не секрет ?
dvolodin #
06:21
Dmitry1: регистры дополнительные :)
Dmitry1 #
06:21
Если про расширение адресного пространства, то PAE их решает
dvolodin #
06:22
В 64 битах тупо больше регистров
06:23
больше регистров - меньше дергается стек
Dmitry1 #
06:23
Дополнительных регистры? Откуда? Если вдумчиво читать спецификацию, то мы увидим, что абсолютно все операции идут через 64-х разрядный регистр ax.
dvolodin #
06:23
и меньше всякого барахла вроде срыва стека
gnu-linux #
06:24
dvolodin: есть наброски eventclasses и alarmclasses для SENSORS, а также профиль и правила для Alentis/NetPing... Куда сбросить?
Dmitry1 #
06:24
Т.е. все остальные 64-х битные аналоги регистров bx, cx, dx и т.п. только могут пересылать данные из регистра в регистр
06:24
А с данными работает только 64-х битный аналог ax
dvolodin #
06:24
gnu-linux: отдельными issue на сайте
gnu-linux #
06:25
патч или тарбол?
dvolodin #
06:25
Пересылка из регистра в регистр дешевле, чем поход в память
06:25
патч лучше
zi_rus #
06:26
Dmitry1, РАЕ - костыль который придумали в стародавние времена, как в сое время придумали nat. для начала, некоторые реализации РАЕ отличались нестабильностью работы хотя конечно это постепенно устранили. во-вторых, более высокая производительность 64бит
06:26
ных систем на задачах математического расчета. и так далее и тому подобное, лучше расскажет тот кто занимается архитектурами компьютерных систем и программированием, но общая тенденция такова, переход с 32 на 64 как в свое время перешли с 16 на 32
Dmitry1 #
06:27
я повторюсь. работает с 64-х битными адресами только регистр rax, все остальные регистры работают с 32-х битными адресами
dvolodin #
06:27
zi_rus: на самом деле все еще проще
06:27
32-битная система команд x86 - косая как незнамо что
06:27
в первую очередь из-за мизерного количества регистров, по сравнению с RISC'ами
06:28
с адресами там все сложнее, у 368 и выше все-таки сегментная адресация
Dmitry1 #
06:28
Но в обычных ситуациях, если не считать большие числа, она почти на 20% быстрее, чем amd64
dvolodin #
06:29
386
06:29
Dmitry1: ты посмотри, как компилятор раскладывает параметры при вызове функции
06:30
и локальные переменные
06:30
А что касается mongodb и 64 бит все просто
06:31
в 70-80-90-е годы считалось, что приложение лучше знает свою структуру данных и работает оптимальнее, если ему не мешает OS
06:32
оттуда и ползли хитрые алгоритмы кеширование, те же raw devices и прочая нечисть
06:32
кто с ораклом в это время имелся - хорошо помнят
wad_ #
06:32
dvolodin а что всетаки делать с тунелями? их нету в описании iget_interface
dvolodin #
06:33
а потом поперли всякие SMP, NUMA, хитрые SAN'ы и прочее и как-то так получилось, что от этих оптимизаций вреда больше, чем пользы
06:33
и начали наоборот делать - типа OS умная, пусть делает свое дело
06:34
вот монго тупо делает mmap на файл базы и дает OS возможность самой морочиться с paging'ом
06:34
wad_: туннели добавлять будем
06:35
вопрос только в том, как их описывать
wad_ #
06:35
на данном этапе интересует только факт тунеля, тип, и ип если есть
dvolodin #
06:36
как сказать
06:36
туннель - это хитрый скотский хак над топологией
wad_ #
06:37
обычное короткое замыкание меджу двумя хрен где знает находящимися точками
dvolodin #
06:38
а вот тут сложный вопрос - приплетать ли сюда MPLS'ные pseudowire
wad_ #
06:38
ой мама..
06:39
может пока без них?
dvolodin #
06:40
куда же без них?
Dmitry1 #
06:40
ага, а птом еще вспомним ppp и прочие туннели
dvolodin #
06:43
именно
06:43
:)
06:43
pppoe, l2tp
06:43
а еще у меня был страшный зверь STUN
06:44
это который serial tunnel в старых IOS'ах
06:45
Проблема даже не в том, что туннели есть, а в том, что аварии на туннелях тесно скоррелированы с авариями на сети
06:47
и коррелятор надо научить распознавать, что туннель грохнулся не сам по себе а связан с падением линка где-то
zi_rus #
07:04
будет ли классификатор устанавливать различные уровни серьезности для аварий которые были вызваны проблемами в сети и которые вызваны действиями администратора
07:05
пример, падение линка из-за обрыва оптики или из-за interface shutdown
dvolodin #
07:07
классификатор - нет
07:07
коррелятор - должен
zi_rus #
07:08
мне казалось классификатор определяет проблему
dvolodin #
07:08
только серьезность аварии зависит от последствий
07:08
а не от причин
07:08
нет, классификатор по исходному событию устанавливает класс и считает переменные
07:08
вся аварийная логика считается коррелятором
zi_rus #
07:10
вот и устанавливал бы пониженный уровень, а если коррелятор обнаруживает серьезные последствия, то пусть повышает. внимание администратора надо привлекать к проблемам о которых он не знает, а не причиной которых он сам является
dvolodin #
07:11
часто бывает, что администратор сам недооценил последствия
07:11
если проблема известна, он всегда может понизить ей приоритет
07:12
хотя опять же - если рухнуло пол-сети, то не важно, само оно упало или уронили
zi_rus #
07:13
а еще будут ли учитываться такие фишки у циски как gracefull shutdown/restart и non-stop forwarding
dvolodin #
07:14
GRES это как бы не кисковская вещь :)
zi_rus #
07:15
если я кладу линк, чтобы разорвать кольцо, мне не хочется видеть алармы, как-будто все плохо, достаточно уровня info
dvolodin #
07:15
это опять же - учить коррелятор
07:15
на самом деле он сам справился
zi_rus #
07:16
dvolodin, говорю с точки зрения eigrp а он только у циски. еще оно есть у БГП, но тут могу судить только со стороны циски
dvolodin #
07:16
так как фолтов только два будет - упавший линк с обоих сторон
zi_rus #
07:16
а должен как бы быть один
dvolodin #
07:16
zi_rus: graceful restart на основных протоколах есть почти у всех
07:16
ну да
07:17
по этим алармам коррелятор просечет - что упал линк и вызвал две аварии
07:17
и свернет их в одил аларм
zi_rus #
07:18
а как на счет NSF, пир down, но он все еще может маршрутизировать пакеты. такое коррелятор прожует?
dvolodin #
07:18
А зачем ему жевать
07:18
авария есть в любом случае
07:18
другое дело, что наведенных аварий будет меньше
07:19
те же хосты за ним будут пинговаться
zi_rus #
07:19
надо правильно определить последствия, он сможет правильно определить, что хосты доступны
dvolodin #
07:19
так что приоритет взлетит не так высоко
07:19
определит, естетсвенно
07:19
разница вот в чем будет
zi_rus #
07:20
т.е. он будет пинговать все железки, а не по известной ему топологии рассчитывать?
dvolodin #
07:20
zi_rus: да, конечно
07:20
он будет продолжать пропинговывать все железки
zi_rus #
07:20
мне кажется, это замедлит повышение уровня
dvolodin #
07:20
наоборот
07:20
наведенные аварии будут поднимать приоритет руту
zi_rus #
07:22
если система хранит всю топологию, зачем ей пытаться пинговать явно недоступные железки, а не просто процессором рассчитать кто оказался недоступен
dvolodin #
07:23
сведения о топологии могут оказаться неполными или ложными
07:23
например, мы потеряли железки из-за аварии
07:23
но потом зацепили их через аварийные каналы по GPRS
07:24
data plane и control plane все-таки разные вещи
zi_rus #
07:25
но они взаимосвязаны
07:26
если зацепили через аварийный канал, значит он записан в конфиге железки и его можно учесть, а если поднят админом, то админа надо еще предупредить что возникла проблема
07:27
для этого и нужен НОК
dvolodin #
07:30
zi_rus: внешняя железка вроде NSG700
zi_rus #
07:31
и?
gnu-linux #
07:32
#182 Добавил в FM клас SENSORS и события для NetPing...
dvolodin #
07:35
zi_rus: нет ее в конфиге
07:38
gnu-linux: да, видел
07:38
лучше, конечно, двумя патчами
07:38
для SA и для FM
zi_rus #
07:39
dvolodin, это можно было бы учитывать в свойствах объекта, у нас например на сети такого нет, и редко у кого может быть, все же это нюанс, а не обычное явление
dvolodin #
07:42
zi_rus: usage pattern'ов очень много
07:42
не надо зажиматься строго на один
07:42
иначе можно влететь капитально
07:43
за примерами ходить далеко не надо
zi_rus #
07:43
можно исходить из самого распространенного и опционально поддерживать все остальное
dvolodin #
07:43
у коллег из одной весьма известной компании был реализован функционал зонтика в service desk
07:44
типа падает DSLAM - накрываем всех клиентов на нем зонтиком и не отрываем заявки от них
07:44
в один прекрасный день отвалился от сети тот интерфейс, через который эта штука мониторила сеть
zi_rus #
07:45
иначе можно зажать себя самыми невероятными ситуациями
dvolodin #
07:45
и она благополучно накрыло зонтовм все
07:45
после чего была оторвана нафиг
07:46
zi_rus: fault management на 99% состоит как раз из экспертизы
07:46
и предыдущего опыта разгребания самых нелепых ситуаций
zi_rus #
07:50
dvolodin, эта история еще раз подтверждает что пинговать неправильно
dvolodin #
07:51
zi_rus: эта история еще раз подтверждает, что предположения, которые когда-то показались правильными, могут быть в корне ошибочными
07:52
пинг - один из простых и тупых способов определения наличия связности
07:52
завязывать все на пинг нельзя, иначе получится nagios
07:53
но и делать apriori предположение о нужности или ненужности пинга - не стоит
gnu-linux #
07:53
dvolodin: 182 патч разделил на два, один для нового профиля Alentis, а другой для FM...
dvolodin #
07:53
gnu-linux: ok
zi_rus #
07:55
и нагиос и кактус выполняют определенные и довольно востребованные функции, в них использованы решения для определенных задач, почему бы это не использовать, не понимаю откуда столько неприятия к этим системам
`kk #
07:57
http://redmine.nocproject.org/boards/3/topics/2428
zi_rus #
07:59
интересная идея
`kk #
08:00
ага\
dvolodin #
08:02
про гис отпишу сегодня
08:03
zi_rus: никакого неприятия. Конкретно в nagios и кактусе мне не нравится подмена понятий
08:03
к мониторингу они имеют отдаленное отношение
08:03
скорее - тупые пробы
zi_rus #
08:04
тупые - это да
dvolodin #
08:04
это даже не мониторинг - а небольшой кусок из performance managemnet
08:04
а проблема в том, что люди, которые их разворачивают, не осознают ограничений этих систем
08:05
и свято уверены, что у них все под контролем
08:05
а это уже опасно
selivanov #
08:06
привет
dvolodin #
08:06
http://redmine.nocproject.org/documents/2
08:06
это ранний драфт
zi_rus #
08:06
читал вчера
dvolodin #
08:06
но во вступлении я постарался описать проблему
08:10
А проблема действительно есть
08:11
и нагиосы ее не решают в принципе, а только усугубляют
08:12
поэтому делать NAGIOS из NOC мы не будем, как бы привлекательно это не выглядело
zi_rus #
08:15
dvolodin, нагиос это отдельная песня, нок уже его превосходит
08:15
но кактус
08:17
увидеть динамику загруженности каналов для оценки перспектив и необходимости модернизации - нок это сможет?
_4ePTeHok #
08:25
zi_rus, это уже есть
08:25
не так удобно как в кактусе том же, но графики строить можно
zi_rus #
08:29
_4ePTeHok, оно сейчас в таком виде что лучше держать кактус чем пользоваться реализацией НОК
_4ePTeHok #
08:30
дык держи
08:30
чем плохо то
zi_rus #
08:30
дык держим
_4ePTeHok #
08:30
кактус удобен для графиков, спору нет
08:30
просто не забывай что noc тянет один Володин
08:31
и все сразу с интерфейсом в стиле vista не будет написано.
selivanov #
08:32
может проще графики брать у кактуса? например сделать в SA у объекта дополнительно поля элемент:линк на график в кактусе?
zi_rus #
08:33
но единая система всегда лучше, плюс доп возможности нока.
selivanov #
08:33
кому надо заполнит, кому не надо проигнорируеи
zi_rus #
08:35
нок мог бы сам рисовать, на сколько я знаю кактус лишь оболочка к rrdtool, выход на него лучше напрямую чем через кактус
dvolodin #
08:35
zi_rus: NOC нормально умеет мониторить интерфейсы и строит графики
08:35
на то даже jquery plugin написал
zi_rus #
08:35
хотел бы оценить результат, но КАК?
dvolodin #
08:35
noc-probe.conf
08:36
но пока не решен ряд вопросов, не хочу это в широкое плавание выпускать
_4ePTeHok #
08:36
dvolodin, тут речь шла по видимому об удобстве настройки, добавления интерфейса и т д.
08:37
как по мне - лучше закончить с фаултом, инвентори развить и уже оттуда отталкиваясь делать графики по параметрам которые нужны
08:37
вот тогда оно будет логично и удобно
dvolodin #
08:37
именно
zi_rus #
08:37
_4ePTeHok, это самое главное, а еще в кактусе графики красивые
dvolodin #
08:37
так и хочу
_4ePTeHok #
08:37
ну вот, собственно я ту же точку зрения и поддерживаю
dvolodin #
08:37
через фолт, каталог сервисов и inventory переползать к графиками и контролю за аномалиями
_4ePTeHok #
08:37
zi_rus, будет все, но со вреиенем
dvolodin #
08:38
все что раньше этого будет сделано - от лукавого и повторение кактуса
08:40
дергать счетчики по SNMP - ума много не надо
08:41
а вот не сделать из них информационный могильник - задача посерьезнее
_4ePTeHok #
08:51
в какти лезешь по 2м причинам - либо прогнозировать увеличение пропускной, либо когда что то случилось и ищещь визуально на графике это
dvolodin #
08:54
_4ePTeHok: и это тоже
08:54
в момент жопы полезно посмотреть, что было рядом
_4ePTeHok #
08:57
а вообще было бы клево, если все в одном комбайне было. Вот сделал в FM мониторинг температуры железяки на выносе, тыкнул - график построился, создал триггер soft alarm на 60С - на графике появилась граница желтая этих 60С. Перевалил ее - алярм и тут же графи
08:57
к в дашборде
dvolodin #
08:58
_4ePTeHok: примерно так и хочу
zi_rus #
09:01
dvolodin, тогда это прекрасно, я тоже так хочу
Dmitry1 #
10:11
Есть предложение сделать два класса: IP Flap (по аналогии с ARP Flap) и ARP lookup failed
10:11
Опечатка. (по аналогии MAC Flap)
dvolodin_ #
10:12
да, мы малость запутались, как это обозвать
Dmitry1 #
10:14
Ивент на эту вещь выглядит так:
10:14
arp: 193.34.20.5 is on em0 but got reply from 00:e0:81:b8:62:db on em1
10:38
Ошибка в документации. Профиль Cisco.IOSXR обозван как Cisco.IOS
dvolodin_ #
12:13
Весь вопрос в том, как это обозвать :)
13:11
Коллеги, а у кого под рукой есть Brocade, которые foundry в девичестве
13:12
последняя серьезная платформа, которую мы не поддерживаем еще
13:12
и Arista не помешала бы, но их в России вроде ни одной не было
_4ePTeHok #
13:16
фаундри у нас есть но старое, похожее на hp
13:17
свежего нет
dvolodin_ #
13:17
точнее hp похожа на foundry
13:17
:)
_4ePTeHok #
13:17
угу
13:17
точнее хп и есть фаундри, просто с другим значком и чуть другим софтом
dvolodin_ #
13:18
наиболее интересны платформы RX и MLX
13:18
HP9000 у нас профиль
13:18
прокурвы это все-таки отдельный зверь
_4ePTeHok #
13:18
там синтаксически отличия есть
13:18
я не смотрел переделывал ли кто под фаундри, у самого пока времени не было
dvolodin_ #
13:28
коллеги предложили хорошее практическое применение FM + SA
13:28
в случае возникновления определенных alarm'мов собирать информацию для support'а
13:28
чтобы потом на TAC выслылать
_4ePTeHok #
13:28
тоже хорошо, ага
dvolodin_ #
13:28
пока я себе это так вижу
13:29
в alarm class указываем, что авария требует открытия кейса на TAC вендора
13:29
делаем интерфейс IGetTech и скрипты get_tech
_4ePTeHok #
13:29
ох там портянки..)
dvolodin_ #
13:29
если барахло случается то делаем следующее
13:30
пытаемся дернуть get_tech на железке
13:30
не исключено, что она уже ребутится, так что надо проявить выдержку и терпение
13:30
выдираем tech-support
13:31
подшиваем все события, которые у нас накопились в течении часа
13:31
и шлем письмом
13:31
портянка да, конкретная
13:32
есть какие-нибудь мысли, соображения или дополнения?
13:45
В общем - TAC negotiations - очень забавное расширение NOC
zi_rus #
13:50
может как-нибудь потом. основные функции еще не до конца отработаны
`kk #
15:15
кто жив ?
15:15
посмотрите плз у себя сколько памяти жрёт correlator.py
Tweet
Share this page
Share this page: Tweet