Comments 22
Только сегодня занимались написанием регулярок под logstash. Совпадение? Не думаю.
Хотя мысль об отправке логов напрямую в эластик была, но отказались от такого варианта.
Подход с регулярками нам нравится тем, что:
1. Все сервисы умеют писать на диск. Значит, что логи можно читать из любого источника. Например, сегодня подцепились к access и error логам nginx, а также к логам одного из наших приложений. Так же планируем читать логи множества сторонних сервисов, которые мы используем, и которые могут писать логи только на диск или иное unix устройство.
2. Смущает возможная деградация производительности при записи приложением напрямую в эластик. У нас сложное приложение и достаточно много логов, и мы переживаем за время отклика.
3. Нас регулярками не запугать :)
Хотя мысль об отправке логов напрямую в эластик была, но отказались от такого варианта.
Подход с регулярками нам нравится тем, что:
1. Все сервисы умеют писать на диск. Значит, что логи можно читать из любого источника. Например, сегодня подцепились к access и error логам nginx, а также к логам одного из наших приложений. Так же планируем читать логи множества сторонних сервисов, которые мы используем, и которые могут писать логи только на диск или иное unix устройство.
2. Смущает возможная деградация производительности при записи приложением напрямую в эластик. У нас сложное приложение и достаточно много логов, и мы переживаем за время отклика.
3. Нас регулярками не запугать :)
С первым пунктом не поспоришь — универсальнее не бывает, если читать человеку
Пункт 2 основан на реальных опасениях… Можно решить за счет асинхронной публикации. И ведь активно используют в проектах syslog ng и т.п.
Я вас отлично понимаю) по поводу пункта 3.
Пункт 2 основан на реальных опасениях… Можно решить за счет асинхронной публикации. И ведь активно используют в проектах syslog ng и т.п.
Я вас отлично понимаю) по поводу пункта 3.
Я имел в виду, что читать будет logstash, чтобы передать в elasticsearch. Человек будет применяться уже непосредственно для работы с красивой kibana :).
Насчет асинхронности соглашусь, можно решить, навскидку, через простую очередь в памяти процесса с периодической bulk отсылкой в эластик. Но это же надо кодить, а логи на диске уже лежат готовые и ждут своего часа. В общем, у нас пока такой быстрый старт получился, с регулярками и минимальными затратами. (Если честно, я пока в некоторой эйфории пребываю от новых для меня и неожиданно крутых инструментов) Может быть, потом случится настроение убрать лишнее звено и запилить elasticsearch адаптер для log4net. Скорее всего даже готовый есть.
За видео спасибо, поглядим на досуге.
Еще вопрос есть: почему решили применить аспекты, а не написать реализацию логера для записи в эластик и ее указать в приложении?
Насчет асинхронности соглашусь, можно решить, навскидку, через простую очередь в памяти процесса с периодической bulk отсылкой в эластик. Но это же надо кодить, а логи на диске уже лежат готовые и ждут своего часа. В общем, у нас пока такой быстрый старт получился, с регулярками и минимальными затратами. (Если честно, я пока в некоторой эйфории пребываю от новых для меня и неожиданно крутых инструментов) Может быть, потом случится настроение убрать лишнее звено и запилить elasticsearch адаптер для log4net. Скорее всего даже готовый есть.
За видео спасибо, поглядим на досуге.
Еще вопрос есть: почему решили применить аспекты, а не написать реализацию логера для записи в эластик и ее указать в приложении?
Удачи вам в интересной технологии и теме!
Вопрос с аспектами в точку) Подобное решение могу порекомендовать только если нет доступа к исходному проекту, но есть доступ к JAVA_OPTS процесса для передачи агента и конфигурации. Т.е. ни исходное приложение, ни его конфигурация специально не изменяются для публикации логов в elasticsearch
Вопрос с аспектами в точку) Подобное решение могу порекомендовать только если нет доступа к исходному проекту, но есть доступ к JAVA_OPTS процесса для передачи агента и конфигурации. Т.е. ни исходное приложение, ни его конфигурация специально не изменяются для публикации логов в elasticsearch
Разворачивал я систему логирования logstash+elasticsearch, куда сыпалось много разношёрстых логов. На большом промежутке времени оно стабильно так и не работало. То logstash в ступор уйдёт, то elasticsearch. Logstash приходилось просто перегружать, elasticsearch чистить базу логов, иначе система деградирует. Собирал логи, по наивности используя tcp, в том числе и с веб-серверов — в результате, при ступоре logstash, в ступор впадали и все, кто пытались отправить логи по tcp. Пришлось всё переделывать на udp. Пробовал разные варианты настройки и того и другого, с сжатием и без.
В общем, как-то стабильности и уверенности в работе связка не внушила.
Если есть положительный пример использования, с десятками источников логов и базой в десятки гигабайт поделитесь опытом.
В общем, как-то стабильности и уверенности в работе связка не внушила.
Если есть положительный пример использования, с десятками источников логов и базой в десятки гигабайт поделитесь опытом.
У нас все стабильно работало на logstash+es. Elasticsearch работал в кластере на 6 хостах и индекс был шардирован — самое большое преимущество ES «из коробки». Индексы просто не хранил больше чем за последние N дней ( реализовал как свой CleanupRiver тогда — описано на слайде «Удаление индексов старше заданной даты», стр.21 )
С logstash и регулярками были проблемы с тем что ПО постоянно менялось и конфиг logstash надо было постоянно поддерживать в актуальном состоянии, а еще досаждало multiline не послылал последнее событие из файла, пока не приходила новая строчка лога.
Главная проблема, которая была — иногда заканчивалось место на диске, если приложение генерировало нетипично много логов в какой либо из последних дней и саппорт комманда не реагировала на это.
С logstash и регулярками были проблемы с тем что ПО постоянно менялось и конфиг logstash надо было постоянно поддерживать в актуальном состоянии, а еще досаждало multiline не послылал последнее событие из файла, пока не приходила новая строчка лога.
Главная проблема, которая была — иногда заканчивалось место на диске, если приложение генерировало нетипично много логов в какой либо из последних дней и саппорт комманда не реагировала на это.
У нас 6 машин, на каждой запущено несколько десятков микросервисов. Сервисы пишут в stdout, который перенаправляется в log-courier, который отправляет логи на центральный logstash, который пишет в elasticsearch.
Были проблемы с тем, что на центральном сервере кончалось место, но это решилось очисткой старых индексов по крону.
Индексы, кстати, лучше всего по часам: logstash-%{+YYYY.MM.dd.HH}
Были проблемы с тем, что на центральном сервере кончалось место, но это решилось очисткой старых индексов по крону.
Индексы, кстати, лучше всего по часам: logstash-%{+YYYY.MM.dd.HH}
Интересное решение!
Вы рассматривали использование lumberjack?
Видимо у вас очень много записей, раз партиционируете по часам
Вы рассматривали использование lumberjack?
Видимо у вас очень много записей, раз партиционируете по часам
Почему выбрали схему с log-courier и централизованным logstash? Смущает единая точка отказа, как следствие централизации.
мимо… удалил…
Будем перехватывать вызовы методов error, warn, info, debug, trace логера и отправлять данные сразу в elasticsearch.
Делали так. Бывали случаи, когда приложение падало еще до загрузки такого отправляльщика. Или даже до загрузки Java — например, один раз Java снесли случайно.
Сейчас все логи пишем прямо в stdout, и на каждое приложение запускаем log-courier, который по сети отправляет логи на центральный сервер.
Как вы отлаживаете код, написанный в XML для aspectj-scripting?
Добрый вечер! Это то еще развлечение. MVEL отлаживается так же как и OGNL — почти никак. Можно делать print, можно делать локально небольшие тесты для выражений.
Но отлично дебажится про что говорил в Отладка Groovy скриптов с Grape на основе maven aether и
Java вместо Groovy. Если воскрешу агент — пойду этим путем.
Но отлично дебажится про что говорил в Отладка Groovy скриптов с Grape на основе maven aether и
Java вместо Groovy. Если воскрешу агент — пойду этим путем.
Groovy сам по себе отлаживать не проблема совершенно. Интересует как отлаживать то что мы внедрили таким изощрённым способом. Даже если подключиться дебаггером, там будет evaluate (execute) т.к. это фактически строка. Есть ли способ остановиться брэкпоинтом в коде?
Суть в том что если я внедряю в приложение логгинг подобным образом, вероятно у меня нет контроля над его исходным кодом (купленное проприетарное). То есть я не могу всё запустить в любимой IDE.
Второй вопрос здесь же — по примеру сделать скрипт легко, а если я пишу свой скрипт разбора и логгирование, а приложение стартует пару минут — поседеть можно отлаживать скрипт каждый раз перезапуская полностью. Есть ли возможность скрипт менять в рантайме?
Суть в том что если я внедряю в приложение логгинг подобным образом, вероятно у меня нет контроля над его исходным кодом (купленное проприетарное). То есть я не могу всё запустить в любимой IDE.
Второй вопрос здесь же — по примеру сделать скрипт легко, а если я пишу свой скрипт разбора и логгирование, а приложение стартует пару минут — поседеть можно отлаживать скрипт каждый раз перезапуская полностью. Есть ли возможность скрипт менять в рантайме?
Менять aspectj scripting скрипт в рантайм возможности нет и продолжать развивать версию с MVEL я не планирую. Если и воскрешу проект то с динамической компиляцией на java или groovy. Код есть на github, любой может форкнуть и «допилить» под свои потребности. Наши задачи на момент разработки aspectj scripting решал. Тем более что инструментировал им, в том числе распределенное IMDG приложение на Oracle Coherence. А Oracle Coherence купленое проприетарное и исходных кодов нет — только декомпиляция байткода может помочь. Остановиться брекпоинтов в MVEL возможности нет. Но можете почитать Drools Eclipse Tooling and breakpoints это производное от MVEL, вдруг все же можно…
Sign up to leave a comment.
Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash