Комментарии 13
Имя хоста отличное в примере в конце статьи.
А как насчет протестировать всю цепочку целиком? Попробуйте
echo «ioc0: attempting task abort!» > /dev/kmsg
из-под рута.
echo «ioc0: attempting task abort!» > /dev/kmsg
из-под рута.
Тут всё сложно — для того, чтобы тестировать «с помощью kmsg», нужно иметь поднятую связку dmesg->netconsole->logstash<-dns<-chief. А это много двигающихся частей, и сложная «тестовая конфигурация», которую поднимать только ради проверки «регэкспы не попортились» смысла нет.
Да и в чём смысл пересылать сообщение через ядро, когда stdin то же самое даёт, только с меньшими сайд-эффектами? (Да и netconsole есть только на linux, а часть сотрудников маками пользуется — там как быть?).
Да и в чём смысл пересылать сообщение через ядро, когда stdin то же самое даёт, только с меньшими сайд-эффектами? (Да и netconsole есть только на linux, а часть сотрудников маками пользуется — там как быть?).
Ну я имел в виду скорее полноценное интеграционное тестирование. Проверить регексы — это хорошо. И их надо проверять при каждом изменении. Это юнит-тестирование.
Но ведь надо иногда проверять и всю цепочку целиком, что быть уверенным что ты действительно получишь алерт при таком вот конкретном сообщении от ядра.
Но ведь надо иногда проверять и всю цепочку целиком, что быть уверенным что ты действительно получишь алерт при таком вот конкретном сообщении от ядра.
" nova-compute (написана на python) не отвечает на heartbeat'ы. "
Вот поэтому мы и стали писать свое а не использовать опенстек — ввиду того что данный продукт фундаментально крив, а если какие-то проблемы выплывут — будут в первую очередь претензии к нам.
IBM как-бы наш конкурент, но очень правильно сами пишут
• OpenStack remains an emerging technology
• It is not mature yet
• Error handling not robust
• Understanding the flow of calls and messages is needed
• Large volume of message based rpc calls
• Logging is not optimal (either too much or too little)
• You must be willing to look at code
• Networking (nova-network) is complicated
• Multiple bridges
• IPTables configuration not straight forward
© IBM Corporation
Вот поэтому мы и стали писать свое а не использовать опенстек — ввиду того что данный продукт фундаментально крив, а если какие-то проблемы выплывут — будут в первую очередь претензии к нам.
IBM как-бы наш конкурент, но очень правильно сами пишут
• OpenStack remains an emerging technology
• It is not mature yet
• Error handling not robust
• Understanding the flow of calls and messages is needed
• Large volume of message based rpc calls
• Logging is not optimal (either too much or too little)
• You must be willing to look at code
• Networking (nova-network) is complicated
• Multiple bridges
• IPTables configuration not straight forward
© IBM Corporation
О да, вы нашли фатальный недостаток в чужом продукте. И только вы его можете устранить.
Nova используется в продакшене не менее чем парой сотен компаний (я за продакшен считаю только public self-serving) уже минимум три года.
Ту вы приходите и говорите, что вы сделаете лучше.
okay.jpg
Nova используется в продакшене не менее чем парой сотен компаний (я за продакшен считаю только public self-serving) уже минимум три года.
Ту вы приходите и говорите, что вы сделаете лучше.
okay.jpg
Недостаток далеко не один к сожалению, и даже не 100.
OpenStack сегодня это как Apache Web Server.
Жутко перегружен, крив до безобразия. Ситуация с сотнями / тысячами разработчиков (и компаний которые очень хотят денег) — рак / лебедь /щука.
Потом пришел Сысоев и сделал все (nginx) как надо.
Насчет «сделаете» — сделали уже. Статья была тут на хабре но пришлось ненадолго выключить по ряду политических причин.
OpenStack сегодня это как Apache Web Server.
Жутко перегружен, крив до безобразия. Ситуация с сотнями / тысячами разработчиков (и компаний которые очень хотят денег) — рак / лебедь /щука.
Потом пришел Сысоев и сделал все (nginx) как надо.
Насчет «сделаете» — сделали уже. Статья была тут на хабре но пришлось ненадолго выключить по ряду политических причин.
Скажите, вы его дальше маркетинга смотрели? Из всего опенстека keystone и nova — самые сильные компоненты (свифт не знаю, им другие люди занимаются), neutron тащится в отдалении.
К nova (при правильном планировании инфраструктуры) у меня лично комплект претензий микроскопический, в основном связанный либо с багами в edge cases (да, разумеется, баги в чужом ПО — это Фатальный Недостаток), либо с желанием как нибудь так исхитриться, чтобы и на ёлку влезть и ресурсов не потратить.
Насчёт «You must be willing to look at code» — я не верю в существование крупного проекта без этого.
А ваше исправление Фатального Недостатка подразумевает, что никому на этот код смотретьлучше не надо не придётся?
К nova (при правильном планировании инфраструктуры) у меня лично комплект претензий микроскопический, в основном связанный либо с багами в edge cases (да, разумеется, баги в чужом ПО — это Фатальный Недостаток), либо с желанием как нибудь так исхитриться, чтобы и на ёлку влезть и ресурсов не потратить.
Насчёт «You must be willing to look at code» — я не верю в существование крупного проекта без этого.
А ваше исправление Фатального Недостатка подразумевает, что никому на этот код смотреть
Уважаемый автор
а можно как нибудь увидеть список вот этих волшебных строк ЦЕЛИКОМ?
[message] =~ /ioc0: attempting task abort!/ or
[message] =~ /mptbase: ioc0:.+Code=\{Abort\}/ or
[message] =~ /Device offlined/ or
ну и с разбором кейсов… что откуда взялось?
а можно как нибудь увидеть список вот этих волшебных строк ЦЕЛИКОМ?
[message] =~ /ioc0: attempting task abort!/ or
[message] =~ /mptbase: ioc0:.+Code=\{Abort\}/ or
[message] =~ /Device offlined/ or
ну и с разбором кейсов… что откуда взялось?
Я попробую собрать. Начиная с определённого момента у нас для каждого сообщения полная строка и линк в багтрекере, но комплекты более ранних просто добавлялись по возникшим ситуациям.
Знаете это было бы офигенно даже хотя бы просто сам список куда нибудь на gist.github.com скопипастить =)
а если с разбором кейсов, то вообще очень круто
а если с разбором кейсов, то вообще очень круто
Ну, тут надо понимать, что делаем мы их под себя — чуть-чуть меняется железо, и комплект сообщений от других драйверов и совсем другой. А реакция на все сообщения с приоритетом ERROR/critical — откровенный перебор. На dell'овых серверах, например, можно получить «ошибку чтения» с CD-привода (виртуального, через IPMI) — и всем на неё пофигу. А у кого-то это может быть бизнес-критикал сообщение.
Например, kvm пишет как ошибку действия гостей: kvm [12599]: vcpu0 unhandled wrmsr: 0x682 data 0, хотя ничего такого это не означает. Просто реагировать на все error от ядра не стоит. Более того, местами имеет смысл реагировать на debug/info (флап интерфейса, который не должен флапать), и всё это исключительно business specific.
Так что имеет смысл это всё делать под конкретную инсталляцию.
Например, kvm пишет как ошибку действия гостей: kvm [12599]: vcpu0 unhandled wrmsr: 0x682 data 0, хотя ничего такого это не означает. Просто реагировать на все error от ядра не стоит. Более того, местами имеет смысл реагировать на debug/info (флап интерфейса, который не должен флапать), и всё это исключительно business specific.
Так что имеет смысл это всё делать под конкретную инсталляцию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обработка сообщений ядра