Pull to refresh

Comments 36

Вопрос за «тюнинг ядра» на клиентах, ну понятно поигрались tcp, хотя используете udp, но зачем например увеличивать количество подключений по unix-сокетам? Также очень странно выглядит то, что вы отключаете icmp-reply, видимо для повышения безопасности, но в тоже время включаете форвардинг на клиентских нодах. Форвардинг необходим только на ноде с syslog-ng, поскольку там docker, ну и увеличение кол-ва подключений на unix-сокеты, хотя для запуска 4 контейнеров тоже не особо актуально.

Зачем использовать syslog-ng для форвардинга nginx логов на syslog-сервер, если он и сам может слать логи по сети напрямую на tcp/udp сокеты?

Да все верно, можно отключить ipforward. А по отправке логов напрямую я писал в статье, что словили баг на продакшен сервере, при отправке напрямую — начало появляться большое количество 500 ошибок, непонятно из-за чего. Долго выяснять причину не стал, в итоге решили проблему чтением и отправкой логов из файла, так как по крайней мере не создавала проблем.

Подскажите, а есть ли какая-нибудь адекватная механика экспорта данных из Kibana? Для задачи вида: есть у нас сохраненный поиск по индексу MyLogIndex с фильтром MySuperEvent и хочу я выгрузить все данные за вчера, например.

Нашел на форуме elastic


https://github.com/elastic/kibana/issues/1992


The X-Pack Basic includes CSV export feature, which is better than the patch: it is done server side and exports every document in CSV (not only the 500 first results available on browser).
So as the X-Pack feature (which is free) is better than the patch, I won't maintain the patch for Kibana 6.x

Как я понял, бесплатная базовая версия xpack предоставляет этот механизм.

Во, похоже оно мне и надо. Спасибо
Но на X-Pack Gold и далее планы у них конский ценник :) В прочем, Basic для CSV достаточно.
В Кибане пока нашел только ссылку для экспорта данных в *.csv (Row или Formatted).
Тоже нужно было из Кибаны настроенные визуализации получить извне — не нашел способа
Спасибо. Подход интересный, буду пробовать.
Пока столкнулся с тем, что не из всех визуализаций можно выдернуть описанным по ссылке способом текст запроса.
По моему проще использовать graylog2: проще развернуть, куча плагинов и тд.

Я не использовал graylog2. Скажите, чем он проще чем syslog-ng? Я пробовал в продакшене следующие системы — rsyslog,td-agent,logstash — самым удачным, быстрым и легко настраиваемым оказался syslog-ng.

Небольшое уточнение. jamm1985 предложил graylog2 как замену Elasticsearch+Kibana+Elasticalert, а не syslog-ng.

А разве graylog не использует elasticsearch как хранилище? Я не пользовался graylog2, и не могу сказать удобнее ли это нашей системы. В любом случае спасибо за совет, обязательно попробую graylog2.

graylog+mongo+elastic и там сложно говорить о configuration as a code. Как с вами связаться? хотел бы обсудить ваш логинг, сейчас склоняюсь к логстешу есть пара вопросов по сислог нг :)

Пишите на почту мне. a.v.galushko86@гмайл.ком. Отвечу на вопросы.

Да, все верно. Graylog2 использует Elasticsearch для хранения лог данных и MongoDB для хранения конфигурации. По сути это Kibana+аналог logstash+alerting+аутентификация/авторизация.
То есть Elasticsearch и MongoDB можно развернуть сбоку, в желаемой конфигурации.
Можно использовать elastic filebeat как агента, logstash-forwarder давно уже не используется

Да, всё верно, как вариант можно использовать filebeat, можно еще попытаться поюзать td-agent, неплохое решение, но прожорливое по ресурсам при некоторых операциях, например при парсинге большого файла начинать безудержно поедать цпу. Ruby. Главное не плодить зоопарк по возможности.

net.ipv4.tcp_tw_recycle = 1 — больше проблем чем пользы. Лучше пусть стоит в 0, тогда не будет проблем у клиентов которые через NAT ходят в и-нет. В современных ядрах параметр и вовсе выпилили из ядра
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4396e46187ca5070219b81773c4e65088dac50cc

Тоже самое касается и net.ipv4.tcp_tw_reuse = 1, лучше пусть будет выставлен в 0.

Очень полезное дополнение. Вы правы, прочитал статью, и правда выпилили.

Есть достаточно подробная статья по tw_reuse, tw_recycle, которая даёт четкое понимание что в их изменении может быть плохого или хорошего:
TCP Time-Wait state Linux
Недавно мне помогла, когда настраивал haproxy для одной задачи.
UFO just landed and posted this here
Я использую ноды по 4 cpu и 12 gb озу и 700 gb ssd.

А что порекомендуете если нет такой кучи под мониторинг? У меня условно 3 слабых сервака под 1.5 приложения, и хочется сделать полноценный мониторинг что там нгинксы бедокурят + какие-никакие профили нагрузки чисто для красивых графиков и оценки сезонности + запаса по производительности в пике. Думал попробовать поставить мастера эластика, но вы пишете что он загнётся, или всё таки от 3х серверов не то чтобы нагруженных он не загнётся?

Сделайте тогда хотя бы отдельно master и 2 слабеньких дата ноды и посмотрите что будет, возможно этого хватит.

Если запускать ELK на одной ноде, то ничего страшного не произойдет. Нужно только отключить репликацию для индексов, иначе статус эластика будет постоянно желтый. И конечно делать бэкапы.

Ещё не дочитал до конца, но зря вы так про rsyslog — в актуальных версиях (не из стабильных дебиан/рхелов) одумались и сделали человеческий rainer script, очень даже навеянный синтаксисом syslog-ng.


Тем более rsyslog почти везде по умолчанию — я делал аналогичную систему на нём и почти не пожалел.

Это хорошо если так. Можете привести пример конфига rsyslog'а, я бы хотел взглянуть и если этот так то действительно, то возможно, стоит посмотреть в его сторону, так как он изначально практически везде стоит по-умолчанию.

Это было на прошлой работе, увы, не старался утянуть конфиги. Помню, что по каким-то причинам пришлось на стороне rsyslog-а форматировать логи в json для отправки в логстэш и понял в какой-то момент, что надо сесть и прочитать актуальную официальную документацию с сайта. Оказалось что после некоторого въезжания её можно использовать как справочник (старые умляут-команды тоже приведены) и не зубрить особо.


Из проблем с rsyslog-ом запомнились две:
1) при длительном даунтайме центральной точки сборки логи с машин долго потом заливались и заметно грузили слабые виртуалки и EL (я делал протоколом обмена RELP и хранение логов в дисковых очередях при недоступности).


2) в какой-то версии (я тянул свежие пакеты из официальных реп) в старых рхелах сломали сбор данных из внешних файлов так, что rsyslog наотрез отказывался запускаться и приходилось чистить файлы состояния опроса внешних файлов. Не знаю, почили ли.

Скажите, а какую роль в этой связке играет grafana?

Позже допишу как прикрутить эластик к grafana и построить красивые графики)

В прошлом году внедрял аналогичную систему, изначально пытались использовать стек ELK, не понравилось, требования были авторизация пользователей из AD, разграничение доступа к логам по пользователям и группам, рассылка алертов. Всё это можно организовать, но не удобно. В итоге остановился на Graylog2 с клиентами Filebeat и Winlogbeat. В итоге имеем разграничение доступа к логам, удобную настройку, алерты на почту и в телеграм, смс, имеется куча плагинов с дополнительным функционалом. Отдельно упомяну клиентов сбора и отправки логов Filebeat, с их помощью получаем очень удобный парсинг многострочных логов, а главная фишка в том что этот клиент понимает на каком месте он остановил сбор и отправку логов, что гарантирует отсутствие потерянных логов при обрыве связи либо других пролемах.
unnforgiven Спасибо за статью!
Увидел что вы написали «logstash в качестве агентов». Но рассматривали/тестировали ли вы logstash как замену syslog-ng севрера?
Какие могут быть плюсы/минусы у logstash по сравнению syslog-ng?
Спасибо

Syslog-ng меньше потребляет, сейчас я вообще ушел от него в сторону rsyslog на клиентах, центральный сервер на td-agent >>> в elasticsearch/

Добрый день! У вас сейчас также td-agent центральный? Или схема поменялась?

Добрый день. td-agent центральный, всё верно. Только я ушел с syslog-ng на rsyslog

Sign up to leave a comment.

Articles