Comments 13
А какие проблемы были с использованием логов syslog? В том плане что по идеетот же rsyslog способен обрабатывать тысячи записей в секунду и особо не возникать. У вас задача что логи с 99.99% вероятностью должны быть записаны? или допускается потеря части записей?
Честно говоря, впервые слышу об rsyslog. Судя по обещанной производительности, может быть в этом плане оно бы нам и подошло. Правда, все равно остается вопрос о том, как оно себя будет вести в случае, когда какие-то скрипты «флудят» на порядок больше других — оно умеет что-то аналогичное «вытесняющей многозадачности»? Мы пробовали syslog-ng, и он нам по каким-то причинам не подошел (это было несколько лет назад, может быть админы, например banuchka подскажут). Мы его заменили на scribe, но у него есть проблемы со стабильностью и, конкретно для доставки логов, с возможность записать туда намного больше, чем может «прожевать» сервер-получатель.
Обычно, у нас, как и во многих других крупных компаниях, большие инсталляции серверов и серьезные требования к надежности, производительности, и, что самое важное, удобстве настройки и отладки системы. Мы тратим очень много ресурсов на поддержку существующих систем, и для нас не слишком дорого написать свое решение (особенно если оно пишется за неделю, как в случае с системой сборки логов). Наличие своего решения позволяет иметь локальную компетенцию и решать уникальные для нас проблемы, которые актуальны только на наших объемах и в наших условиях. В данном случае нам нужно максимально легко иметь возможность доставить и посмотреть логи «руками», чтобы один скрипт не мог зафлудить всю систему, и желателен real-time streaming, и чтобы оно при этом не падало и не жрало процессор. Упомянутые далее в комментариях визуализация и даже полнотекстовый поиск нам не нужны — это дебаг-логи, доставка которых критична, но нужна очень редко и даже простой less+grep нам подходит, как средство диагностики и поиска проблем. На самом деле, у нас есть еще и саой индексатор этих логов, но он заточен под наш формат и под наш внутренний PHP-фреймворк, поэтому его выложить довольно сложно.
В общем, резюмируя — для нас очень важна поддержка и управляемость системы, поэтому мы стараемся выбирать те решения, с которыми кто-то работал до этого, или есть достаточное количество человек, которые готовы эту систему поддерживать и чинить ночью, если что-то сломается. Поэтому мы часто выбираем написание своих систем, если это позволяет нам сэкономить на поддержке и решить наши проблемы без «костылей».
Обычно, у нас, как и во многих других крупных компаниях, большие инсталляции серверов и серьезные требования к надежности, производительности, и, что самое важное, удобстве настройки и отладки системы. Мы тратим очень много ресурсов на поддержку существующих систем, и для нас не слишком дорого написать свое решение (особенно если оно пишется за неделю, как в случае с системой сборки логов). Наличие своего решения позволяет иметь локальную компетенцию и решать уникальные для нас проблемы, которые актуальны только на наших объемах и в наших условиях. В данном случае нам нужно максимально легко иметь возможность доставить и посмотреть логи «руками», чтобы один скрипт не мог зафлудить всю систему, и желателен real-time streaming, и чтобы оно при этом не падало и не жрало процессор. Упомянутые далее в комментариях визуализация и даже полнотекстовый поиск нам не нужны — это дебаг-логи, доставка которых критична, но нужна очень редко и даже простой less+grep нам подходит, как средство диагностики и поиска проблем. На самом деле, у нас есть еще и саой индексатор этих логов, но он заточен под наш формат и под наш внутренний PHP-фреймворк, поэтому его выложить довольно сложно.
В общем, резюмируя — для нас очень важна поддержка и управляемость системы, поэтому мы стараемся выбирать те решения, с которыми кто-то работал до этого, или есть достаточное количество человек, которые готовы эту систему поддерживать и чинить ночью, если что-то сломается. Поэтому мы часто выбираем написание своих систем, если это позволяет нам сэкономить на поддержке и решить наши проблемы без «костылей».
Экосистема для сбора логов вокруг Elasticsearch сейчас выглядит более «матерой»: kibana для визуализации, logstash и lumberjack для стриминга логов.
Зачем еще одно решение? Только из-за Go?
Зачем еще одно решение? Только из-за Go?
Эластик начинает плохо работать, если в него запихать больше 20 нод. А логстэш — вообще фигня полная, в режиме приёмника UDP пакетов может терять и четверть всех логов при нескольких тысячах сообщений в секунду.
Если пихать 20 нод бездумно, то да, наверное плохо будет работать. А вообще рекомендации по планированию описаны в ЭТОЙ главе.
Автору советую посмотреть на это решение https://www.graylog.org/
Автору советую посмотреть на это решение https://www.graylog.org/
А если пихать не бездумно, то уже на 20 нодах начнут проявляться всякие неприятные спецэффекты, когда из-за временного вылета одной ноды плохет всему кластеру, хотя не должно. Скажем, перезапуск одной ноды может привести к деградации кластера минут на 20. А перезапуски нужны, потому что случаются дедлоки и null pointer exception.
Вы это говорите с учётом своего печального опыта? Если да, то не могли бы Вы более подробно рассказать?
Пытаюсь сымитировать ситуацию на своей тестовой площадке, но до сих пор не получилось добиться деградации кластера. Максимум 5 минут, и то, я не назвал бы это деградацией (деградация наблюдается только при запросах на именно те индексы, которые восстанавливаются). Поделитесь, может быть даже в рамках новой статьи.
Пытаюсь сымитировать ситуацию на своей тестовой площадке, но до сих пор не получилось добиться деградации кластера. Максимум 5 минут, и то, я не назвал бы это деградацией (деградация наблюдается только при запросах на именно те индексы, которые восстанавливаются). Поделитесь, может быть даже в рамках новой статьи.
К сожалению, сильно больше подробностей рассказать не могу, потому как занимаюсь эластиком не я сам, а коллега. Возможно, тут играет роль нагрузка, у нас порядка 100к записей в секунду пишется, мелкими батчами, через rsyslog.
Это не та нагрузка, которой можно положить Elastic в правильной комплектации и настройке. Самым узким местом может быть приём записей без потерь, но RabbitMQ решает этот вопрос, поэтому доставка гарантирована. Другой вопрос, если поднимать всё «из коробки» без тонкого тюннинга: тогда с некоторой вероятностью всё грохнется и на 1к записей.
И…
Без знания сути говорить, что что-то плохо работает не есть правильно.
И…
К сожалению, сильно больше подробностей рассказать не могу, потому как занимаюсь эластиком не я сам, а коллега.
Без знания сути говорить, что что-то плохо работает не есть правильно.
Без знания сути говорить, что что-то плохо работает не есть правильно.
Вынужден не согласиться. Коллега — профессионал, уже не первый год этот эластик готовит, кучу подводных камней знает, так что его мнению я доверяю. То, что деградация есть, видно по графикам времён ответа, тут очевидно, когда работает плохо, а когда — хорошо.
Если вы действительно готовы дать дельный совет или хотите попытаться разобраться, что же происходит, то я могу свести вас в почте, например.
Вынужден не согласиться. Коллега — профессионал....
Вы наверное меня не так поняли. Я за то, чтобы тот, кто «готовит», тот и критикует. Без «это решение г...! почему? мне так сказали.»
А насчёт свести в почте — идея хорошая. Если у вашего коллеги есть время и желание рассказать подробнее о подводных камнях, то я только за. Мне даже интересно, в чём загвоздка.
Сколько у вас ушло ресурсов на написание и внедрение самописной системы? Любопытно сравнить со стоимостью проприетарного решения вроде splunk.
Как я отвечал в комментах выше, система была написана примерно за неделю рабочего времени, включая внедрение и мониторинг. Сложно сказать, сколько для splunk стоила бы записьоколо 1 Тб логов в день (мы столько пишем), но порядок вы и сами можете прикинуть :). Splunk у нас используется в биллинге и у админов, но там объемы на порядки меньше
Sign up to leave a comment.
Эволюция сборки логов «облака» и сборщик логов в open source