Прозрачный прокси для сети Docker означает, что TCP сломан
Моя настройка ведения журнала - это один хост Docker с UDP 514, доступным для syslog. Порт контейнера nginx опубликован, поэтому, когда вы отправляете журналы на 10.1.1.100 (на изображении ниже), он сначала обращается к nginx, конфигурация которого для прозрачной балансировки нагрузки для контейнеров Logstash:
user root;
events {worker_connections 32768;}
stream {
upstream logstash_servers {
server logstash-collector-01:514;
server logstash-collector-02:514;
server logstash-collector-03:514;
}
listen 514 udp;
proxy_pass logstash_servers;
proxy_bind $remote_addr transparent;
}
}
Это прекрасно работает. Однако TCP 514 (или любой другой TCP, если на то пошло) этого не делает. Даже когда я добавляю правильный слушатель и конфигурации, я считаю, что рукопожатие TCP не завершается, потому что, когда nginx выполняет прозрачную балансировку нагрузки, его proxy_bind проходит, например 10.1.1.5 в качестве IP-адреса источника, например, 172.18.0.4 (экземпляр Logstash). Затем этот экземпляр пытается завершить рукопожатие, но 10.1.1.5 (и все маршрутизаторы по пути) не знает, как выполнить маршрутизацию в сеть Docker 172.18.0.0/16.
Есть ли здесь решение, позволяющее использовать TCP для ведения журнала?
Похоже, что nginx может быть не лучшим инструментом для этой работы - либо haproxy (если вам нужна простая балансировка нагрузки TCP / UDP), либо rsyslog (если вы хотите что-то немного более ориентированное на приложение), подойдут лучше и будут выполнять ту же функцию, что и nginx в настоящее время.
Глядя на вашу настройку, у вас может быть даже внешний прослушиватель logstash на 514, который может перенаправлять на другой экземпляр logstash для фактической обработки. Поскольку logstash не выполняет балансировку нагрузки AFAIK, вы можете вместо этого «маршрутизировать» события на основе некоторых тегов / типов, которые вы разместили.
Проверка https://www.nginx.com/resources/admin-guide/tcp-load-balancing/, чтобы иметь и TCP, и UDP, вам понадобится что-то вроде:
stream {
upstream logstash_servers {
server logstash-collector-01:514;
server logstash-collector-02:514;
server logstash-collector-03:514;
}
server {
listen 514;
...
}
server {
listen 514 udp;
...
}
}
Я не совсем понимаю, приведет ли использование logstash_servers в блоке UDP-сервера к тому, что nginx будет говорить с ними по UDP или TCP, поэтому вам может потребоваться сделать оба доступными.
Я бы немного сомневался, что проблема заключается в узле nginx, использующем `` неправильный '' IP-адрес в качестве источника при подключении к бэкэндам logstash - как правило, ваш внешний интерфейс nginx будет использовать любой `` правильный '' IP-адрес для этого, который в вашем случае это будет означать адрес в пределах 172.18 / 16. Это похоже на то, как nginx используется при обратном проксировании на localhost: в этой ситуации nginx будет взаимодействовать с приложением localhost, используя исходный IP-адрес 127.0.0.1 (или :: 1), а не IP-адрес, с которого nginx увидел запрос, исходящий от .
И есть также тот факт, что вы, кажется, говорите, что все это работает для UDP - что, как правило, означает, что маршрутизация не является проблемой как таковая, но что-то в вашей настройке TCP может быть.