Телеграмм чат группы nginx

Anton Noginov

Это не так.
Но - если вам удобно - то и отлично :)

Хм, не спора ради, но можно услышать вашу точку зрения?

21:15пожаловаться #1

AN

nginx - /dev/log - rsyslog - elastic/КХ

Опционально - между локальным сислогом и конечным хранилищем - агрегирующий сислог для датацентра, с записью избирательных потоков в холодное хранилище.

21:17пожаловаться #2

k

kbks in nginx_ru

Подскажите, а зачем так делать?

к примеру, апи с хелсчеком на хостах из этих апстримов на других портах, и если указывать в апстриме порт, то хелсчек уже не проходит.
ну и в зависимости от запроса может проксировать на разные порты. не хочется плодить апстримы отличающиеся только портом

21:17пожаловаться #3

AN

(вообще, там по дороге ещё и риман может быть, для алертов и метрик)

21:18пожаловаться #4

k

kbks in nginx_ru

kiosaku

раз более одного апстрима, то указывать в proxy_pass уже никак

хм, не знал. спасибо

21:19пожаловаться #5

AY

Anton Noginov

nginx - /dev/log - rsyslog - elastic/КХ

Опционально - между локальным сислогом и конечным хранилищем - агрегирующий сислог для датацентра, с записью избирательных потоков в холодное хранилище.

Так я почти так и делаю) Для чего beats? Банально надежность. Не более. Сливаю я тоже в /dev/log, только в центосе это journald (но не суть, никто не мешает сливать в сокет rsyslog). В целом я понял к чему вы :) На самом деле тема логов - сложная тема, без логстеша я никак) Спасибо за мнение

21:20пожаловаться #6

AY

kbks

к примеру, апи с хелсчеком на хостах из этих апстримов на других портах, и если указывать в апстриме порт, то хелсчек уже не проходит.
ну и в зависимости от запроса может проксировать на разные порты. не хочется плодить апстримы отличающиеся только портом

А это очень плохая идея. Прям очень. Лучше плодить апстримы. Был печальный опыт, когда масса проектов использовала один апстрим. Кодер допустил ошибку в одном проекте - выключились все. А все потому что nginx выключил эти сервера из-за ошибок.

21:21пожаловаться #7

AN

Так я почти так и делаю) Для чего beats? Банально надежность. Не более. Сливаю я тоже в /dev/log, только в центосе это journald (но не суть, никто не мешает сливать в сокет rsyslog). В целом я понял к чему вы :) На самом деле тема логов - сложная тема, без логстеша я никак) Спасибо за мнение

Да, это реально одна из самых сложных тем.

Самая большая претензия к рецептам со so - включая все эти биты - файловые операции.

21:21пожаловаться #8

AY

Anton Noginov

Да, это реально одна из самых сложных тем.

Самая большая претензия к рецептам со so - включая все эти биты - файловые операции.

Просто, если честно, я не нашел адекватного способа сделать гарантированную доставку логов. Нет, можно конечно заюзать rabbitmq... Но что выйдет дешевле, beats или rabbitmq?)))

21:22пожаловаться #9

Y

Yuri in nginx_ru

Блин. Я всего 100 грамм выпил, а уже ничего не понимаю. Чертова старость

21:23пожаловаться #10

k

kbks in nginx_ru

А это очень плохая идея. Прям очень. Лучше плодить апстримы. Был печальный опыт, когда масса проектов использовала один апстрим. Кодер допустил ошибку в одном проекте - выключились все. А все потому что nginx выключил эти сервера из-за ошибок.

Хорошо. Тогда вопрос как лучше реализовать когда проксировать должен на один порт, а хелсчек на хостах апстрима на другом порту?

21:24пожаловаться #11

Y

Yuri in nginx_ru

kbks

Хорошо. Тогда вопрос как лучше реализовать когда проксировать должен на один порт, а хелсчек на хостах апстрима на другом порту?

Мне кажется, тут service discovery пора использовать

21:25пожаловаться #12

Y

Yuri in nginx_ru

Хелсчекать сервис и при недоступности выключать его из каталога.

21:26пожаловаться #13

AN

Просто, если честно, я не нашел адекватного способа сделать гарантированную доставку логов. Нет, можно конечно заюзать rabbitmq... Но что выйдет дешевле, beats или rabbitmq?)))

Сислог с двумя синками.
Он синхронизирует поток, и умеет буферизировать и гарантировать целостность

21:26пожаловаться #14

AY