Comments 30
Уже много лет проводим тесты по вопросу как быстрее парсить логи регэкспом. И много лет побеждает perl. Он создан для регулярок все таки. У нас объем меньше вашего, но и парсим мы только логи nginx.
Ansible проследит что бы везде был одинаковый формат. Syslog-ng направит поток из файла логов nginx на stdin парсера.
150 тысяч записей лога в минуту (многострочные данные мы считаем за одну запись) — в сумме со всех серверов дает <10%CPU нагрузки.
Ansible проследит что бы везде был одинаковый формат. Syslog-ng направит поток из файла логов nginx на stdin парсера.
150 тысяч записей лога в минуту (многострочные данные мы считаем за одну запись) — в сумме со всех серверов дает <10%CPU нагрузки.
Я смотрю на пример конфигурации Heka, и я считаю что сплиттер строк нужно было назвать не RegexSplitter, а как-нибудь типа JavaLogSplitter.
А то RegexpSplitter не говорит нам ни о чём. Дла это сплиттер, да он работает на регулярках — но в имя лучше вынести специфику применения, а не специфику реализации.
Каноничная форма описания сплиттера такая:
И в боевых конфигах мы используем имена реальных сервисов в заголовках всех блоков, для удобочитаемости. Но для статьи пришлось их поменять на нейтральные названия.
[SplitterName]
type = "RegexSplitter"
delimiter = ‘here_is_delimeter’
delimiter_eol = true/false
И в боевых конфигах мы используем имена реальных сервисов в заголовках всех блоков, для удобочитаемости. Но для статьи пришлось их поменять на нейтральные названия.
То, что logstash тормозной и тяжёлый уже и самим разработчикам ELK понятно, и ему есть более шустрые альтернативы.
В HEKA, всё-же, смущает, что она deprecated и не развивается — вместо неё Мозилла начала новый проект Hindsight, по их бенчмаркам в 7-10 раз шустрее и легче, чем HEKA. Но насколько он готов, стабилен и как долго его будут сопровождать — трудно сказать.
Рассматривался ли вами во многом похожий на HEKA движок от Триваго — Gollum. Из статьи неясно, когда ваш проект был начат, но по довольно старым бенчмаркам Gollum в сравнении с LogStash и HEKA смотрится вполне достойно и по-прежнему жив, в отличие от HEKA.
А чем, всё-таки, kafka не устроила? Вроде как многие её активно в production используют и не особо жалуются…
На данный момент Heka отвечает нашим требованиям по простоте администрирования, надежности, функциональности и производительности. Для работы с логами мы выбрали Heka прежде всего потому, что он уже успешно работал у нас в системе для доставки событий из сервисов в Graphite.
С Gollum мы не экспериментировали, но как видно из описанного в статье исходногозоопарка набора инструментов, который у нас был, процесс не стоит на месте и мы регулярно пробуем новые технологии. Сейчас рассматриваем Filebeat как вариант для замены Heka.
Kafka мощный инструмент, но его не просто готовить, появляется промежуточный слой, добавляется точка отказа, появляется Zookiper и т.д. Люди регулярно борются с Kafka «из коробки», например, тут Bubuku. Скорее всего, придется бороться и нам, но уже для других целей. У нас основые проблемы возникли с Flume, перестроение кластера останавливало всю систему до полной перезагрузки. Потратив несколько дней, мы поняли, что можно проще, что Kafka не нужен, и наши усилия по налаживанию кластера лучше направить в другое русло. В итоге, получилось проще и дешевле по админским затратам.
С Gollum мы не экспериментировали, но как видно из описанного в статье исходного
Kafka мощный инструмент, но его не просто готовить, появляется промежуточный слой, добавляется точка отказа, появляется Zookiper и т.д. Люди регулярно борются с Kafka «из коробки», например, тут Bubuku. Скорее всего, придется бороться и нам, но уже для других целей. У нас основые проблемы возникли с Flume, перестроение кластера останавливало всю систему до полной перезагрузки. Потратив несколько дней, мы поняли, что можно проще, что Kafka не нужен, и наши усилия по налаживанию кластера лучше направить в другое русло. В итоге, получилось проще и дешевле по админским затратам.
Уточню про flume: под нагрузкой зависала связка kafka -> flume. Симптомы: все ядра под 100%, память утекает неизвестно куда, в логах пусто. Как в данных условиях лечить — непонятно, поэтому пришлось ампутировать.
А у Вас уже есть какие-то сравнительные данные по текущей Вашей конфигурации и по конфигурации с использованием Filebeat? Я сейчас решаю похожую проблему централизованного сбора логов в компании с большим потоком трафика, и пока что использование Filebeat на хостах + отдельных нод logstash + кластера ES — видится более чем адекватным. Тем более, что связка Filebeat + Logstash умеет между собой договариваться о том, чтобы данные передавались с какой надо скоростью, и при этом не терялись.
все красиво расписали, спасибо.
а как логируете и храните сообщения при работе с МПСами?
как PA\PCI DSS по всем этим проходите?
а как логируете и храните сообщения при работе с МПСами?
как PA\PCI DSS по всем этим проходите?
Хороший и актуальный для нас вопрос! Сертификацию мы проходим каждый год, приложения в периметре контролируют (фильтруют) наличие карточных данных перед записью в лог, а сами логи мы НЕ пишем в «общий» ELS. Сейчас в работе внедрение поверх выделенного ELS инструмента для ограничения прав доступа на основании настроек в LDAP. Плюс думаем вместо уровня приложений использовать Lua в Heka для маскирования чуствительных данных, которые могут попасть в лог. Ну и конечно, если вдруг такое нам понадобится, то отправку даже очищенных логов из периметра PCI DSS в «общий» ELS мы будем делать только после её успешного прохождении сертификационного аудита.
Не смотрели в сторону fluentd (td-agent)?
Он быстрее logstash (и потребляет меньше ресурсов) и он развивается.
Он быстрее logstash (и потребляет меньше ресурсов) и он развивается.
Не смотрели. Спасибо, записал в книжечку. Пригодится, когда будем думать на что съезжать с хеки, если она перестанет справляться.
Из опыта, с ним проблемы:
если есть сетевые проблемы (у вас, вроде, с сетью все ok) -> ведет себя плохо
проблемы с плагином для elasticsearch (вроде не сложно их исправить, но нужно время) -> ведет себя плохо
были проблемы с vmware (баги были в версии 5.0 или около того, не помню точно, хотя и сейчас всплывают, но они глобальные и все касаются сети), но это не про вас, если я не ошибаюсь :)
если есть сетевые проблемы (у вас, вроде, с сетью все ok) -> ведет себя плохо
проблемы с плагином для elasticsearch (вроде не сложно их исправить, но нужно время) -> ведет себя плохо
были проблемы с vmware (баги были в версии 5.0 или около того, не помню точно, хотя и сейчас всплывают, но они глобальные и все касаются сети), но это не про вас, если я не ошибаюсь :)
Он тоже на Ruby.
Параметр es_index_from_timestamp нужен для указания, что дата и время для формирования имени индекса берутся не из приходящих данных, а из локального времени сервера. Позволяет избежать бардака, когда серверы работают в разных временных зонах и кто-то пишет в логи время в UTC, а кто-то в MSK.— «при обрыве соединения или деградации канала», получится, что данные будут писаться в ES с временем, серьёзно отличающимся от реального?
Этот параметр влияет только на то, когда создаётся индекс. Позволяет избежать создания индексов, когда, например на сервере эластика ещё сегодня, а логи шлют уже из завтра. Эластик сам вычисляет таймстамп записи из даты и времени пришедших в логах. Поэтому, кстати, очень важно, чтобы в логах были указаны таймзоны. Потому что если их нет — Эластик будет считать по UTC и логи поплывут.
А вы не рассматривали Splunk как альтернативу?
Если — да, то было бы интересно послушать ваше мнение относительно выбора.
Если — да, то было бы интересно послушать ваше мнение относительно выбора.
У нас есть опыт использования Splunk, отзыва положительные)
Выбор в пользу ELS был сделан из-за стоимости, нам нужно обрабатывать большие объемы логов.
Выбор в пользу ELS был сделан из-за стоимости, нам нужно обрабатывать большие объемы логов.
А сколько примерно в деньгах вам выходит ELS суммарно, если не секрет? И какой объем Гб в день вы обрабатываете?
Поскольку хостинг и техподдержку мы осуществляем сами — ES нам не стоит ничего. В день система прокачивает около 3Тб логов. Под такие объёмы нужна лицензия Splunk Enerprise. Посчитайте — сколько это будет стоить за индексирование 3Тб/сутки.
Почти все они работали неидеально: кластер Kafka был ненадежен, Flume периодически вис, отчего ES впадал в ступор
а можно как-то поподробнее? как другие-то работают?
по Kafka — какие именно были проблемы? и пытались ли вы их решить?
Есть ли какой-то смысл в разных таймзонах на разных серверах?
Если добрая часть приложений на Java/log4j, не рассматривали вариант с log4j custom appender?
Интересно было бы посмотреть на метрики по логам и создание инцидентов.
Думаю рассказать, как мы его виртуализировали, как переезжали с версии 2.2 на 5.3 и перевозили с собой 24 миллиарда записей, не потеряв при этом веру в человечество.
Мне довелось переносить более 20 миллиардов записей с 1.x на 2.x, потом с 2.x на 5.x, но ресурсов было гораздо меньше… будет интересно почитать как это делается «в нормальных условиях» ;)
Если память не изменяет, в рассылках Rob и товарищи советовали не использовать RegexSplitter, т.к. он медленный.
А вместо него сделать сплиттер на LPEG.
Но они к производительности подходили очень серьезно — лишнюю инструкцию в цикле в фильтре не вставляли, чтобы скорость не падала.
И еще, возможно вам, или еще кому-то пригодится: https://github.com/timurb/heka_mock
Это мокер, чтобы можно было тесты к фильтрам писать.
А вместо него сделать сплиттер на LPEG.
Но они к производительности подходили очень серьезно — лишнюю инструкцию в цикле в фильтре не вставляли, чтобы скорость не падала.
И еще, возможно вам, или еще кому-то пригодится: https://github.com/timurb/heka_mock
Это мокер, чтобы можно было тесты к фильтрам писать.
Sign up to leave a comment.
Работа с потоком логов в реальном времени с помощью Heka. Опыт Яндекс.Денег