Комментарии 19
Прочитал как детектив, хотя и не все понял
scribe или flume тебе в помощь. отправляет сообщения пачками. если он не может отправить сообщение, то оно накапливается в очереди. такие ситуации как у тебя сведены к минимуму.
А как они с netconsole помогут? Или предполагается прокси между logstash и отправителем? За названия спасибо, почитаю.
Верно, как прокси должно помочь.
А зачем ещё один сервер в разрыве, когда можно просто увеличить размер буфера со стороны принимающего? В общем случае, у прокси будут ровно те же проблемы — ядро пишет так быстро, как может, а принимающему всё-таки что-то с пакетом делать надо (хотя бы заголовки сетевого/транспортных уровней разобрать, да в userspace передать).
Оно не только это умеет, flume может взять на себя роль балансировщика, плюс один агент может выполнять несколько задач. Со скоростью разбора пакетов у него проблем нет. Также в нем можно настроить длину очереди и правила ее записи (трешолды по количеству сообщений, размеру данных), делать первичную обработку и т.д.
И не обязательно на отдельный сервер, ставьте там же где logstash.
И не обязательно на отдельный сервер, ставьте там же где logstash.
Но да, к сожалению, scribe никто еще в ядро не встроил.
НЛО прилетело и опубликовало эту надпись здесь
Serial over lan отличная штука и в некоторых случаях работает даже круче, чем impi. Например, когда у меня (на предыдущей работе) были очень тонкие и трудноуловимые глюки зена, именно логгинг на последовательный порт (который SOL) помог локализовать источник проблем.
С SOL проблема другая: он очень медленный. И тут возникает два варианта:
1) Асинхронный вывод. В этом случае оно сначала ломается и начинает трейситься, а потом уныло из буффера кормит SOL данными. Всё работает быстро, но если всё виснет, то буфер теряется.
2) Синхронный вывод. В этом случае когда проблема (или просто INFO) возникает, то оно синхронно пишется в SOL до победного конца. В это время всё замирает. То есть буквально всё — ядро ЗАНЯТО ОНО ЛОГИ ПИШЕТ. В это время не обрабатываются прерывания, не идёт сетевой трафик, не работает консоль и т.д. Если это отладка любой ценой — всё ок, мы получаем самую последнуюю предсмертную записку самым надёжным способом. Но в продакшен так нельзя.
Так что для мониторинга продакшена чуть менее надёжный, зато быстрый netconsole оказывается лучше. Если начинаются странные процессы, ведущие к зависанию, то вероятность, что большой кусок лога уйдёт с сервера через асинхронный netconsole выше, чем через асинхронный последовательный порт (например, с момента начала трейса до момента полного зависания 10мс — на гигабитной сети это резерв для примерно 10 тысяч udp-пакетов, а на SOL на скорости в 112 килобод — меньше 200).
С SOL проблема другая: он очень медленный. И тут возникает два варианта:
1) Асинхронный вывод. В этом случае оно сначала ломается и начинает трейситься, а потом уныло из буффера кормит SOL данными. Всё работает быстро, но если всё виснет, то буфер теряется.
2) Синхронный вывод. В этом случае когда проблема (или просто INFO) возникает, то оно синхронно пишется в SOL до победного конца. В это время всё замирает. То есть буквально всё — ядро ЗАНЯТО ОНО ЛОГИ ПИШЕТ. В это время не обрабатываются прерывания, не идёт сетевой трафик, не работает консоль и т.д. Если это отладка любой ценой — всё ок, мы получаем самую последнуюю предсмертную записку самым надёжным способом. Но в продакшен так нельзя.
Так что для мониторинга продакшена чуть менее надёжный, зато быстрый netconsole оказывается лучше. Если начинаются странные процессы, ведущие к зависанию, то вероятность, что большой кусок лога уйдёт с сервера через асинхронный netconsole выше, чем через асинхронный последовательный порт (например, с момента начала трейса до момента полного зависания 10мс — на гигабитной сети это резерв для примерно 10 тысяч udp-пакетов, а на SOL на скорости в 112 килобод — меньше 200).
НЛО прилетело и опубликовало эту надпись здесь
В нашем конкретном случае сервер остался жив (велика потеря — апача завалили), и более того, сообщение дошло в полном комплекте через syslog (куда kernel messages тоже идут), то есть любой метод доставки сработал бы. Я выше писал про более тяжкие случаи, когда, например, ядро решает поубивать всех и пишет про то, что убивает init (это означает panic). Чем быстрее утаскивается трейс, тем выше вероятность утащить в нём важное для разбирательств.
А можно узнать, в каком режиме работает бондинг? Это 802.3ad или что-то другое (active-backup, какой-то из режимов балансировки)?
Получилось ли воспроизвести ситуацию, в которой отправка сообщений вызывала видимое увеличение количества dropped (предполагается, что в остальных случаях данная величина не изменяется)?
Получилось ли воспроизвести ситуацию, в которой отправка сообщений вызывала видимое увеличение количества dropped (предполагается, что в остальных случаях данная величина не изменяется)?
Bonding Mode: fault-tolerance (active-backup)
Воспроизводить не пробовали, поскольку есть строгая уверенность, что потеря логов вызывает рост dropped, мониторинг (теперь) скажет, если что не так.
В принципе, воспроизвести легко можно — hping3/nping на порт, который logstash слушает, думаю, --flood ни одна софтика не переживёт (хотя бедный эластик при этом жалко).
Воспроизводить не пробовали, поскольку есть строгая уверенность, что потеря логов вызывает рост dropped, мониторинг (теперь) скажет, если что не так.
В принципе, воспроизвести легко можно — hping3/nping на порт, который logstash слушает, думаю, --flood ни одна софтика не переживёт (хотя бедный эластик при этом жалко).
Есть смысл посмотреть, какое количество dropped-пакетов на slave-интерфейсе и на master-интерфейсе. Если эта величина на slave-интерфейсе совпадает со значением на bond-интерфейсе (а на мастере при этом 0), скорее всего, причина обсуждаемой проблемы в чем-то другом.
Сразу скажу, что я не сумел нагуглить или определить точную причину возникновения dropped-пакетов, но встречал упоминания, что это особенность реализации bonding в Linux.
Буду рад, если кто-то подскажет какую-либо информацию по теме.
Сразу скажу, что я не сумел нагуглить или определить точную причину возникновения dropped-пакетов, но встречал упоминания, что это особенность реализации bonding в Linux.
Буду рад, если кто-то подскажет какую-либо информацию по теме.
Этому нетконсолю бы ещё dot1.q-тег. Не понимаю ядерщиков с их 'netconsole is very very log level'. Если мы всё равно формируем кадр и отсылаем его в сеть, что мешает заполнить его указанным тегом…
Я смотрел на эту тему, насколько я понял, там нужны изменения для самих виланов (поддержка netpoll). Хотя да, я не понимаю, почему нельзя в ethernet-frame дописать ещё одно поле «вслепую» (например, выставляя тег, которого на местных интерфейсах ородясь не было).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Маленькая админская история: как поймать OOM