Спасибо автору, как человек, много работавший с логами Nginx в Graylog, скажу, что это очень очень хороший гайд, который мог бы мне сэкономить кучу времени много лет назад. Так что смело можно её рекомендовать для старта.
И когда-то у меня действительно на руках была версия Nginx без поддержки JSON логов.
Сейчас я бы всё-таки использовал логи Nginx в JSON формате + разбор JSON на filebeat.
Разбор логов на самом Graylog это большой риск и геморрой, малейшая ошибка в регулярке на больших нагрузках приводит к необходимости отладки и профилирования, журнал растёт, работа стоит, надо рестартовать процесс и тд. и тп.
(Справедливости ради скажу, что у меня был гораздо более сложный формат и порядка 15K messages per second)
Даже на простейшем примере GROK шаблона в статье виден малоизвестный неочевидный нюанс: уточнение использованной регулярки до ^pattern$ улучшает её производительность вдвое
Дано: молодая симпатичная девушка без телефона, навигатора и катаны, в купальнике и шлёпках, незнакомый город бывшей союзной республики, зима, метель, мороз, волки воют, подземные черви-оборотни изгрызли асфальт, идёт третий день орбитальной бомбардировки.
Пробую на совсем простом стенде: никакого VRRP, первая нода — VS, вторая нода — RS, на ней на lo висит VIP, iptables везде пустые.
При запросе на VS виден только SYN, после чего нода-VS отвечает клиенту ICMP Destination Unreachable (Host Unreachable). На RS при этом вообще нет пакетов.
Куда ещё можно покопать?
2 сервера. Запросы приходят на VIP и должны баланситься и на себя и на того парня. Так как это локалка, то попробовал только очевидный вариант с DR, но не взлетело.
А где можно почитать про вариант с FWMARK(именно в контексте двух нод, для большего количества мануалов много, а две ноды даже в документации RedHat не считают за вариант)?
Есть ли современные истории успеха с поднятием keepalived на самих real_server'ах?
То есть когда нет отдельного балансировщика, а, условно говоря, есть всего 2 сервера, на них же и VIP висит и балансировка производится на самих же себя
Пока что обещания постепенно повышать производительность дистрибутива выполняются. Так, время загрузки новой версии Clear Linux по сравнению с предыдущей выросло сразу в 2,5 раза.
Это как бы сарказм такой или они реально замедлили загрузку?
А есть что-нибудь человеческое для аналитики с Clickhouse по типу ELK?
Юскейс: хочу посмотреть все логи с request_time больше 3 секунд. А потом посмотреть топ-10 клиентов сделавших такие запросы? Исключив из них конкретный User-Agent? И всё это в 3 клика мышкой
Благодарю, вот уж не думал что в 2021 смогу узнать что-то новое про отладку шелла, но вам это удалось :)
Что-то у меня уже несколько LADDA сдохло на ровном месте, после порядка 10 циклов. Зарядные устройства их просто не видят.
Поэтому конечно стоит тестировать альтернативы
Можно поподробнее про немного денег и шарообразность?
Спасибо автору, как человек, много работавший с логами Nginx в Graylog, скажу, что это очень очень хороший гайд, который мог бы мне сэкономить кучу времени много лет назад. Так что смело можно её рекомендовать для старта.
И когда-то у меня действительно на руках была версия Nginx без поддержки JSON логов.
Сейчас я бы всё-таки использовал логи Nginx в JSON формате + разбор JSON на filebeat.
Разбор логов на самом Graylog это большой риск и геморрой, малейшая ошибка в регулярке на больших нагрузках приводит к необходимости отладки и профилирования, журнал растёт, работа стоит, надо рестартовать процесс и тд. и тп.
(Справедливости ради скажу, что у меня был гораздо более сложный формат и порядка 15K messages per second)
Даже на простейшем примере GROK шаблона в статье виден малоизвестный неочевидный нюанс: уточнение использованной регулярки до ^pattern$ улучшает её производительность вдвое
На телефоне, при зуме двумя пальцами постоянно прыгает куда-то в сторону
Дано: молодая симпатичная девушка без телефона, навигатора и катаны, в купальнике и шлёпках, незнакомый город бывшей союзной республики, зима, метель, мороз, волки воют, подземные черви-оборотни изгрызли асфальт, идёт третий день орбитальной бомбардировки.
Внимание, вопрос
Было бы гораздо интереснее, если бы домики под музыку трансформировались, а так — скучновато
Пробую на совсем простом стенде: никакого VRRP, первая нода — VS, вторая нода — RS, на ней на lo висит VIP, iptables везде пустые.
При запросе на VS виден только SYN, после чего нода-VS отвечает клиенту ICMP Destination Unreachable (Host Unreachable). На RS при этом вообще нет пакетов.
Куда ещё можно покопать?
Я вешал на lo, по какому-то гайду лохматых годов(там ещё танцы с бубном sysctl практикуются) — http://kb.linuxvirtualserver.org/wiki/Building_Two-Node_Directors/Real_Servers_using_LVS_and_Keepalived
В итоге в tcpdump вижу только SYN от клиента и тишина, до real_server'ов ничего не доходит.
В какую сторону можно покопать?
2 сервера. Запросы приходят на VIP и должны баланситься и на себя и на того парня. Так как это локалка, то попробовал только очевидный вариант с DR, но не взлетело.
А где можно почитать про вариант с FWMARK(именно в контексте двух нод, для большего количества мануалов много, а две ноды даже в документации RedHat не считают за вариант)?
Мм… У меня всё в локалке и я так понимаю с NAT на DR так просто нельзя перейти?
Есть ли современные истории успеха с поднятием keepalived на самих real_server'ах?
То есть когда нет отдельного балансировщика, а, условно говоря, есть всего 2 сервера, на них же и VIP висит и балансировка производится на самих же себя
Я правильно понимаю, что фронтенда для кликхауса так и нет и сделать из него аналог ELK(чтоб в 2 клика делать всяческую аналитику) не получится?
Это как бы сарказм такой или они реально замедлили загрузку?
Когда в руках молоток, всё вокруг кажется гвоздями.
Вводный пример не очень удачен, всё решается без чат ботов
А есть что-нибудь человеческое для аналитики с Clickhouse по типу ELK?
Юскейс: хочу посмотреть все логи с request_time больше 3 секунд. А потом посмотреть топ-10 клиентов сделавших такие запросы? Исключив из них конкретный User-Agent? И всё это в 3 клика мышкой
"Хроники лаборатории" прям
Так то да, но top не может показать отдельно загрузку всех 54 ядер(ибо не влезают по вертикали), а htop может
А теперь о действительно важном: когда будут выдавать крабовые береты?
По сравнению с ELK/Graylog как-то очень всё сложно. Возможно за счёт узкой специализации оно быстрее/экономичнее эластика?