Комментарии 20
Есть ли сравнение ELK и Clickhouse (+clicktail) ?
При запуске в винды
ошибка:
Exiting: error loading config file: config file ("filebeat.yml") can only be writable by the owner but the permissions are "-rwxrwxrwx" (to fix the permissions use: 'chmod go-w /usr/share/filebeat/filebeat.yml')
лечится
https://discuss.elastic.co/t/volume-mapped-filebeat-yml-permissions-from-docker-on-windows-host/91893
добавлением строки
command: filebeat -e -strict.perms=false
в docker-compose.yml для компонента beats
beats:
image: elastic/filebeat:7.16.2
command: filebeat -e -strict.perms=false
volumes:
- ./configs/filebeat/config.yml:/usr/share/filebeat/filebeat.yml:ro
- ./host_metrics_app/:/host_metrics_app/:ro
networks:
- elk
depends_on:
- elasticsearch
Эм, очень странная статья. Непонятно зачем. Во-первых, сюрприз, но запросто может оказаться, что в пересчете на ресурсы поиск grep'ом, или ripgrep'ом быстрее и дешевле, чем хранить данные в эластике и искать там. Тем более, когда речь идет о сотнях гигов или терабайтах данных - просто подумайте сколько придется под сам эластик отдать ресурсов.
Во-вторых, компоуз. Ну, в 2022 это уже очень странно. Прикольно разворачивать в облаке, или брать kubernetes + eck оператор (там реально 3 манифеста для установки эластик стека)
В третьих, logstash не нужен. Filebeat прекрасно умеет слать в сам эластик и какие-то базовые преобразования он умеет. А если делать совсем надежно - то это помимо логстэша кафку еще притаскивать. В общем, космолет получается. Ну, или наоборот - биты завсегда можно логстэшом заменить. Здесь скорее вопрос ресурсов ))) потому что биты обычно кушают сильно меньше, чем полноценная установка logstash.
В четвертых, без того, чтобы само приложение написать так, чтобы оно писало структурированные логи - ценность в эластике в районе нуля. Тут главное не удариться в другую историю - когда вроде как мы логи в json завернули, но все равно все пишем в поле message.
В любом случае автору за попытку спасибо
Наверное, но иногда есть нужда красиво и удобно смотреть логи. Особенно, если есть необходимость давать доступ заказчику/аналитикам/тех.поду к некоторым логам.
Ну, тут на вкус и цвет. Не вижу ничего плохого в docker compose. За свой скромный опыт кубер был лишь на одном месте работы (но инфра была на аутсорсе), а где-то еще до сих пор rpm пакеты (прекрасно работало, кстати).
Согласен, но хотелось и самому разобраться и другим хоть как-то показать.
Этот пункт не совсем понял. JSON в поле message - костыль? Что вы подразумеваете под структурированными логами (я подумал про uuid пользователя, операции, контекста)?
Спасибо за комментарий)
Поддержу коллегу по п.3 — связка "*beat > logstash > elasticsearch" в 2022 свою актуальность совсем и полностью исчерпала. А именно Logstash — неудобный в эксплуатации, ресурсоемкий, ограниченный в отладке. Было бы круто и полезно новичкам, на кого очевидно и рассчитана статья, даже исходя из заголовка, увидеть примеры про актуальный и практичный Ingest Pipelines на удобной связке "*beat > elasticsearch" или перспективные Data Streams.
Ну и оставлю это тут как идею для дальнейшего углубления в изучение централизованной работы с лога и на базе продуктов Elastic Stack.
Можно ELK заменить на graylog (тоже на эластике) в настройке попроще чем кибана.
Есть ощущение, что ELK и логи расходятся в разные стороны - слишком тяжелая конструкция выходит. И ресурсов требует много (в том числе административных), а открываешь Кибану - и как в кабине самолета. И это при том, что исходная задача поиска по логам в общем-то несложная, не зря многие решают ее простым grep'ом.
ELK хорош, например, в случае, когда у тебя 100500 серверов и нужно искать логи по каждому из них. А еще в взаимосвязи друг с другом. Но такую же задачу можно решить так - взять отдельный сервер, сделать на нем файлопомойку. Вгружать на него логи с серверов-источников rsyslog'ом. Профит. Да, при этом не будет красивой гуйни. Зато и оверхеда не будет...
Именно - когда объемы логов и сложность поиска по ним превышают некий болевой порог админов. А для простых вещей недавно рекомендовали Loki через promtail. GUI минималистичный, но вот полнотекстового поиска уже нет, увы.
а полнотекст обычно и не нужен... полнотекст переоценен. Обычно ты ищешь что-то конкретное - потому что логи каждой программы выглядят как набор некий вполне определенных строк с некими плейсхолдерами. Кстати, ВНЕЗАПНО, для такой задачи опять же https://sentry.io лучше подходит, но в случае возможности инструментации программы.
Для удобства работы с grep в журнале должна быть в идеале 1 строка на 1 событие, которое вас интересует. Многие программы обладают параметрами по типу Nmap (-oG : Grepable format), чтобы их вывод легче было фильтровать. Сложности начинают возникать, когда событие "размазано" в журнале по разным строкам, которые могут быть "разбавлены" другими строками.
Благодаря мощности всего стека ELK можно красиво парсить даже multiline журналы, для примера Postfix. Лично я начал отказываться от grep текстовых журналов и вначале на базе ELK сделал единый remote syslog. Если вывод какой-то службы особо важен и интересен, то его выделяю в отдельный индекс и не ленюсь написать grok парсер для разбивки по полям: журнал bind9 запросов, postfix(SMTP), dovecot(POP3, IMAP), kaspersky linux mail server.
http://vasilisc.com/postfix-logs-2-elasticsearch
http://vasilisc.com/grok-pattern-kaspersky-linux-mail-server
Сложности начинают возникать, когда событие "размазано" в журнале по разным строкам, которые могут быть "разбавлены" другими строками.
мультилайн - это рак, я полностью согласен. И если в случае самописных программ это решается просто стандартом на логирование или, например, отправкой стектрейсов в sentry (!), то в случае старых легаси штук типа postfix, postgres, не знаю - подставьте свое название, то там придется выкручиваться. В идеале все-таки тоже переработать формат логов... Как хороший пример - nginx. Он умеет в нормальный json лог, а не в свой штатный...
можно красиво парсить даже multiline журналы, для примера Postfix
можно? да. Красиво? Нет! И более того - это лишняя нагрузка на процессор и память (потому что точно будете регекспами искать начало и конец мультилайна + кольцевой буфер нужен)...
Это делается в ELK не регулярными выражениями, а агрегирующим фильтром
https://www.elastic.co/guide/en/logstash/current/plugins-filters-aggregate.html
Он умеет в нормальный json лог, а не в свой штатный...
Полтора года назад еще не умел, отовсюду торчали уши его нутрянки: то внезапный массив в строке, то "-" вместо IP, то какая-то фигня вместо UTF-8 в строках (а это, на минутку, данные с клиента — там совсем лютая жесть может быть).
Пришлось оборачивать в lua.
Да, что-то такое. Все-таки в конечном счете ваше решение как выглядело?
Повесил обработчик на стадию логирования:
log_by_lua_file conf.d/include/log_by_lua_json.lua;Он отправляет данные в сокет, где их ловит питоновский сервис, чья задача декодировать строку, выкинув ошибки — у нас реализован ellipsis для слишком длинных строк, а lua не умеет в юникод и обрезает прямо посреди мультибайтового символа, поэтому требуется дополнительная валидация.
Затем данные попадают в redis (работает буфером), откуда их забирает logstash, присваивает мету и складывает в elasticsearch.
Из дополнительных бибилиотек — cjson.
Если не использовать ellipsis, то можно сразу отправлять в redis, только ввиду специфики nginx надо будет сперва инициализировать подключение при старте воркера, а потом уже его использовать в log_by_lua.
Как попробовать ELK-стек за один вечер и наконец-то перестать grep'ать логи