Как стать автором
Обновить

Комментарии 19

Прочитал как детектив, хотя и не все понял
scribe или flume тебе в помощь. отправляет сообщения пачками. если он не может отправить сообщение, то оно накапливается в очереди. такие ситуации как у тебя сведены к минимуму.
А как они с netconsole помогут? Или предполагается прокси между logstash и отправителем? За названия спасибо, почитаю.
Верно, как прокси должно помочь.
А зачем ещё один сервер в разрыве, когда можно просто увеличить размер буфера со стороны принимающего? В общем случае, у прокси будут ровно те же проблемы — ядро пишет так быстро, как может, а принимающему всё-таки что-то с пакетом делать надо (хотя бы заголовки сетевого/транспортных уровней разобрать, да в userspace передать).
Оно не только это умеет, flume может взять на себя роль балансировщика, плюс один агент может выполнять несколько задач. Со скоростью разбора пакетов у него проблем нет. Также в нем можно настроить длину очереди и правила ее записи (трешолды по количеству сообщений, размеру данных), делать первичную обработку и т.д.

И не обязательно на отдельный сервер, ставьте там же где logstash.
Ну, если увеличение буфера не поможет, будем смотреть в сторону специальных решений. За совет спасибо.
Как вариант, можно попробовать Serial-over-lan — в современных IPMI такое есть.
Ну, или написать свой netconsole:)
Serial over lan отличная штука и в некоторых случаях работает даже круче, чем impi. Например, когда у меня (на предыдущей работе) были очень тонкие и трудноуловимые глюки зена, именно логгинг на последовательный порт (который SOL) помог локализовать источник проблем.

С SOL проблема другая: он очень медленный. И тут возникает два варианта:

1) Асинхронный вывод. В этом случае оно сначала ломается и начинает трейситься, а потом уныло из буффера кормит SOL данными. Всё работает быстро, но если всё виснет, то буфер теряется.
2) Синхронный вывод. В этом случае когда проблема (или просто INFO) возникает, то оно синхронно пишется в SOL до победного конца. В это время всё замирает. То есть буквально всё — ядро ЗАНЯТО ОНО ЛОГИ ПИШЕТ. В это время не обрабатываются прерывания, не идёт сетевой трафик, не работает консоль и т.д. Если это отладка любой ценой — всё ок, мы получаем самую последнуюю предсмертную записку самым надёжным способом. Но в продакшен так нельзя.

Так что для мониторинга продакшена чуть менее надёжный, зато быстрый netconsole оказывается лучше. Если начинаются странные процессы, ведущие к зависанию, то вероятность, что большой кусок лога уйдёт с сервера через асинхронный netconsole выше, чем через асинхронный последовательный порт (например, с момента начала трейса до момента полного зависания 10мс — на гигабитной сети это резерв для примерно 10 тысяч udp-пакетов, а на SOL на скорости в 112 килобод — меньше 200).

Оно то конечно так, но SOL незаменим, когда косяки в сетевой части(например в драйвере сетевой карты).
Ну, и 12.5Кб = 100 Кбод ~= 1c передачи, так что могло и отправить — в Вашем случае.
В нашем конкретном случае сервер остался жив (велика потеря — апача завалили), и более того, сообщение дошло в полном комплекте через syslog (куда kernel messages тоже идут), то есть любой метод доставки сработал бы. Я выше писал про более тяжкие случаи, когда, например, ядро решает поубивать всех и пишет про то, что убивает init (это означает panic). Чем быстрее утаскивается трейс, тем выше вероятность утащить в нём важное для разбирательств.
Понятно, спасибо!
А можно узнать, в каком режиме работает бондинг? Это 802.3ad или что-то другое (active-backup, какой-то из режимов балансировки)?

Получилось ли воспроизвести ситуацию, в которой отправка сообщений вызывала видимое увеличение количества dropped (предполагается, что в остальных случаях данная величина не изменяется)?
Bonding Mode: fault-tolerance (active-backup)

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

В принципе, воспроизвести легко можно — hping3/nping на порт, который logstash слушает, думаю, --flood ни одна софтика не переживёт (хотя бедный эластик при этом жалко).
Есть смысл посмотреть, какое количество dropped-пакетов на slave-интерфейсе и на master-интерфейсе. Если эта величина на slave-интерфейсе совпадает со значением на bond-интерфейсе (а на мастере при этом 0), скорее всего, причина обсуждаемой проблемы в чем-то другом.

Сразу скажу, что я не сумел нагуглить или определить точную причину возникновения dropped-пакетов, но встречал упоминания, что это особенность реализации bonding в Linux.

Буду рад, если кто-то подскажет какую-либо информацию по теме.
Очень, очень любопытно.

На одном сервере:

bond0: dropped:146630
eth0: 0
eth1: 21

На другом сервере:
bond0: dropped:93304
eth0: 0
eth1: 93304

Спасибо за наводку, буду копать дальше.
Этому нетконсолю бы ещё dot1.q-тег. Не понимаю ядерщиков с их 'netconsole is very very log level'. Если мы всё равно формируем кадр и отсылаем его в сеть, что мешает заполнить его указанным тегом…
Я смотрел на эту тему, насколько я понял, там нужны изменения для самих виланов (поддержка netpoll). Хотя да, я не понимаю, почему нельзя в ethernet-frame дописать ещё одно поле «вслепую» (например, выставляя тег, которого на местных интерфейсах ородясь не было).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.