Nginx - как решить nginx - нет прямых апстримов при подключении к восходящему клиенту?

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

Установка CentOS 8.
Настройка CentOS 8.
Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

Установка Debian 10.
Базовая настройка Debian.
Установка и настройка zabbix на debian.

Я буду в своем примере настраивать все на CentOS 7, но в данном случае дистрибутив не имеет принципиального значения, все так же настраивается и на других linux системах с учетом их особенностей в установке пакетов и путей для конфигов и программ.

Мы будем использовать в качестве источника информации штатные возможности nginx, apache и php-fpm, затем передавать данные в zabbix сервер и там анализировать. Я подразумеваю, что nginx или apache вы уже настроили и имеете некое представление о работе его компонентов, поэтому некоторые вещи я не разжевываю, а просто говорю, что делать.

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

В предыдущем примере мы на самом деле передаем реальный ip адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий ip адрес клиента. Теперь нам нужно на принимающей стороне, то есть blog_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP. Добавляем в секцию server следующие параметры:

Полностью секция server на blog_srv в самом простом варианте получается следующей:

Сохраняем конфиг, перечитываем его и снова проверяем http://blog.zeroxzed.ru/myip.php. Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе web сервера на blog_srv.

Дальше рассмотрим более сложные конфигурации.

Streaming Live Video and Storing Videos with NGINX Open Source

Our solution for streaming video takes advantage of the Real‑Time Messaging Protocol (RTMP) module for NGINX. In this video, James goes through the process step by step:

So that you don’t have to take notes while watching the James’s demo, we’ve captured all of the commands and configuration in the following sections.

An Important Note: Don’t Forget Security!

The NGINX configurations presented in this blog do not include security measures to restrict who can watch your video stream. There are a variety of ways to secure your streams with the front‑end application your viewers use to watch the video, such as allowing access only from certain IP addresses or requiring viewers to authenticate.

Installing the Build Tools

Before compiling NGINX, you need to have some basic build tools installed: , , , and . To download and install them, run the command for your operating system (if it’s not included here, consult the OS vendor documentation).

For Debian and Ubuntu:
For CentOS, Oracle Linux, and RHEL:

Installing Dependencies

The NGINX build also requires several dependencies: Perl Compatible Regular Expressions (PCRE), OpenSSL, and zlib for compression.

Installing Dependencies with a Package Manager

The easier way to download and install the dependencies is with a package manager. Run the command for your operating system (if it’s not included here, consult the OS vendor documentation).

For Debian and Ubuntu:
For CentOS, Oracle Linux, and RHEL:

Installing Dependencies from Source

If you instead want to build and install the dependencies from source, see our .

Compiling NGINX with the RTMP Module

To complete the build, you clone the GitHub repositories for RTMP and NGINX, run the NGINX command, and then compile NGINX.

Configuring NGINX

You can configure NGINX to stream video using one or both of the HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) protocols. The protocols provide the same functionality, so choosing between them is really a matter of preference. If you’re not familiar with them, see HLS vs DASH on the Vidbeo blog.

HLS Configuration

For HLS, the configuration is as follows. In the demo (at time point 5:10), James explains the purpose of these directives.

DASH Configuration

For DASH, the configuration is as follows. In the demo, James combines HLS and DASH in a single configuration, as many directives are the same for both protocols.

Validating the Configuration and Starting NGINX

It’s always a good idea to validate your NGINX configuration to make sure there are no syntactic errors. Run this command:

Then run this command to start NGINX:

Testing the Playback Methods

Start your video stream. OBS Studio is a commonly used open source tool that allows you to livestream from your workstation to your NGINX server by configuring a custom RTMP server. Configure OBS to stream to rtmp://NGINX_server/tv/tv2, where NGINX_server is the IP address or hostname of your NGINX server. No stream key is required.

James doesn’t use OBS in the demo because he is streaming video from a file rather than live. He starts the video stream (at 9:30) by running the stream.sh script, which has these contents:

The video he is streaming (specified with the argument) is the open source Big Buck Bunny video from blender.org. For details about the other arguments, see the documentation.

Once video is streaming, you can test that NGINX is correctly serving it using the protocols you have configured. James opens three instances of the VLC media player and accesses the appropriate URL for each playback method. In the URLs, NGINX_server is the IP address or hostname of his NGINX server:

RTMP – rtmp://NGINX_server/live/bbb
HLS – http://NGINX_server/live/bbb.m3u8
DASH – http://NGINX_server/live/bbb.mpd

Объяснение таймаутов восходящего потока серверной части Nginx

502 ошибка неверного шлюза отображается при переключении между страницами сайта, а иногда и на домашней странице, но не для первого запроса на домашней странице, а только при перенаправлении на нее другой страницы. и это происходит с некоторыми файлами javascript

балансировка нагрузки настроена на двух восходящих php1 php2, оба являются сервером apache.

и это конфигурация сервера балансировки нагрузки

Я искал часами, но ничего полезного не обнаружил, мои потоки активны и никаких проблем с ними.

Ваши апстрим-серверы (php01, php02) работают? Не могли бы вы подключиться к ним по телнету с машины ngnix?
Они связаны.
Вы проверили, достаточно ли запущенных процессов на вышестоящих серверах для обработки трафика? Вы должны проверить журналы восходящего сервера, если они по какой-то причине отклоняют запросы.
У меня не было проблем с журналом ошибок восходящего потока и журналом доступа для неверных запросов шлюза.
Вы нашли решение этой проблемы?

Это не проблема Nginx, проблема заключается в том, что ваши PHP-серверы не отвечают вовремя. Вы можете добавить логирование в Nginx, чтобы подтвердить это.

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

Если вас устраивают очень медленные ответы PHP, вы можете попросить Nginx подождать дольше, прежде чем сдаваться:

Изучив журналы с информацией о времени, указанной выше, вы сможете определить, какие запросы обрабатываются PHP медленно.

Чтобы сузить проблему, отправьте эти запросы непосредственно в серверную часть PHP.

В зависимости от того, что происходит, вы также можете включить кеширование некоторых запросов в Nginx, избегая некоторых медленных запросов.

Не знаю, точно ли это то же самое, но для меня сработало добавить max_fails = 0 в конец имени сервера

восходящий sm_url {сервер LOAD_BALANCER_DOMAIN_NAME: max_fails = 0; }

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

Переименуйте восходящий поток на up_example.com и измените

быть

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

Tweet
Share
Link
Plus
Send
Send
Pin

Мониторинг php-fpm в zabbix

Теперь настраиваем мониторинг php-fpm на сервере zabbix. Действуем по аналогии с мониторингом nginx. Забираем страницу состояния php-fpm на сервер мониторинга и там его парсим в зависимых элементах данных.

С php-fpm будет один нюанс. Нам все-таки придется менять параметры zabbix agent. Настраивать мониторинг php-fpm очень легко, потому что он из коробки умеет отдавать все свои метрики в формате json. Это очень удобно, так как его не надо парсить регулярками. Достаточно только указать JSONpath для получения необходимой метрики.

Нам нужно добавить один UserParameter следующего содержания.

UserParameter=phpfpm.json,curl -s 'http://localhost/phpfpm-status?json' | tr ' ' _

Перезапускаем zabbix-agent и проверяем, что он корректно возвращает необходимые данные.

# systemctl restart zabbix-agent
# zabbix_agentd -t phpfpm.json
phpfpm.json

Дальше как и в случае с nginx, идем в веб интерфейс и импортируем шаблон zabbix-phpfpm-template.xml. Добавляем этот шаблон к серверу и ждем обновления данных. Проверяем их поступление, как обычно, в Monitoring -> Latest Data:

Если все в порядке, то проверяйте графики, создавайте необходимые дашборды. Я свой покажу в самом конце.

В шаблоне php-fpm настроен только один триггер, который следит за тем, чтобы хотя бы один процесс php-fpm был запущен. Раньше я использовал больше триггеров, но потом решил, что они не очень нужны. Состояние работы сайта лучше оценивать по финальным метрикам, таким как скорость загрузки страниц, доступность сайта и коды ответов. Об этом я подобно написал в статье про мониторинг сайта в zabbix. Если с этими метриками проблемы, нужно идти в мониторинг, смотреть графики и решать, что нужно изменить в конфигурации. Это мое личное мнение, с ним можно поспорить. Для этого есть комментарии, буду рад замечаниям и обсуждениям по существу.

Подготовка nginx к мониторингу

Я планирую мониторить следующие параметры nginx:

Параметры мониторинга nginx
accepts per second	Число принятых соединений в секунду
active connections	Текущие активные соединения
handled per second	Число обработанных соединений в секунду
latency	Время ответа сервера в миллисекундах
memory allocated	Занимаемая память
process count	Число запущенных процессов
reading state connection count	Текущее число соединений, в которых nginx в настоящий момент читает заголовок запроса
requests per second	Число запросов в секунду
waiting state connection count	Текущее число бездействующих соединений в ожидании запроса
writing state connection count	Текущее число соединений, в которых nginx в настоящий момент отвечает
memory allocated	Сколько памяти занимают все worker process

Сервер nginx умеет отдавать часть необходимой нам информации о своем состоянии. Для этого его надо соответствующим образом подготовить. Открываем конфиг сервера и добавляем туда следующую конструкцию:

server {
    listen localhost;
    server_name localhost;
    keepalive_timeout	0;
    allow	127.0.0.1;
    allow	::1;
    deny	all;
    access_log	off;

        location /nginx-status {
	stub_status	on;
        }

Я обычно добавляю в самый конец основного конфига nginx.conf. Сохраняем и перечитываем конфигурацию, перед этим проверив его конфиг на ошибки:

# nginx -t
# nginx -s reload

Проверяем, можем ли мы получить необходимую информацию для настройки мониторинга:

# curl http://localhost/nginx-status
Active connections: 89 
server accepts handled requests
 1374661 1374661 9511381 
Reading: 0 Writing: 1 Waiting: 87

Теперь проверим, сможет ли zabbix получать эту страницу.

# zabbix_agentd -t web.page.get

Если у вас так же, то все в порядке, можно двигаться дальше. Если что-то не получается, то проверяйте конфиги, смотрите логи. Это штатный функционал, он должен без проблем настраиваться и работать.

Сразу обращаю внимание на один важный момент, на котором я застрял на приличное время. Через curl я без проблем забирал страничку со статусом nginx, а вот через zabbix никак не получалось

Была ошибка:

 :80]:  Connection refused]

Я всю голову сломал, 10 раз перепроверил конфиги, никак не мог понять, почему не работает. Оказалось, дело было вот в чем. Zabbix-agent обращался к серверу Nginx по протоколу ipv6. Это при том, что как агент, так и nginx работали по ipv4. Я принудительно отключаю у служб ipv6, если он не используется.

Обнаружил это случайно, когда от безысходности запустил Nginx на всех интерфейсах и снял ограничения allow/deny в конфиге. Тогда запрос прошел нормально. Я посмотрел access лог и увидел, что zabbix-agent обращается с адреса ::1. И все стало ясно. Я так и не понял, как заставить агента ходить по ipv4. В итоге запустил nginx на обоих протоколах и разрешил забирать страницу статуса с адреса ::1. После этого заработало.

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

Короткая предыстория

Главная проблема веб-сервера Apache, про который мы говорили прошлый раз, — это падение производительности с ростом трафика. Чем больше людей заходят на сайт, тем хуже он справляется. Решения на тот момент были такие:

устанавливать в серверы более мощное оборудование;
добавлять новые серверы.

И то и другое — дорого. Чтобы решить эту проблему, в 2002 году системный администратор Игорь Сысоев начал разрабатывать собственный веб-сервер, который сможет решить проблему с проседанием под нагрузкой. Тогда Игорь работал в «Рамблере».

Через два года вышел первый релиз его веб-сервера Nginx. Сейчас это самый популярный веб-сервер в России и в тройке самых известных — в мире.

5: Настройка контейнера HAProxy

Теперь нужно настроить контейнер обратного прокси-сервера HAProxy.

Направьте трафик в контейнеры с помощью доменных имен.

Примечание: В руководстве используются условные домены. Первый веб-сайт доступен по доменам example.com и www.example.com, а второй сайт – по www2.example.com.

Войдите в контейнер haproxy:

Обновите список пакетов и установите HAProxy:

Затем нужно настроить HAProxy. Конфигурационный файл HAProxy находится в /etc/haproxy/haproxy.cfg.

Внесите пару поправок в раздел defaults. Добавьте опцию forwardfor, чтобы сохранить исходный IP клиента. Опция http-server-close позволяет повторно использовать сессии и уменьшить задержку.

Затем нужно направить фронтэнд на контейнеры бэкэнда. Добавьте раздел www_frontend:

Команды acl указывают имена хостов веб-серверов и перенаправляют запросы в соответствующий раздел backend.

Затем добавьте разделы backend для веб-серверов (они будут называться web1_cluster и web2_cluster).

Параметр balance определяет стратегию балансировки нагрузки. В этом случае выбрано наименьшее количество подключений. Опция http-request устанавливает HTTP-заголовок с реальным IP-адресом веб-клиента. Без этого заголовка веб-сервер записывал бы IP-адрес HAProxy в качестве исходного IP всех соединений, что затрудняло бы анализ происхождения трафик. Опция server задает имя сервера (web1), за которым следует имя хоста и порт сервера.

LXD предоставляет DNS-сервер для контейнеров. Потому web1.lxd разрешается на IP-адрес, связанный с контейнером web1. У других контейнеров есть свои имена хостов (web2.lxd и haproxy.lxd).

С помощью параметра check HAPRoxy поддерживает проверки состояния веб-серверов.

Убедитесь, что настройка работает должным образом:

Команда должна вернуть:

Перезапустите HAProxy:

Закройте контейнер и вернитесь в среду хоста.

Теперь HAProxy работает как обратный прокси-сервер, который передаёт соединения, поступающие на порт 80, соответствующему контейнеру. Убедитесь, что haproxy может перенаправлять соединения.

Эта команда создаст запрос HAProxy и установит HTTP-заголовок host, который HAProxy должен использовать для перенаправления соединения на соответствующий веб-сервер.

Команда должна вернуть:

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

Безопасность

Помимо уменьшения времени отклика веб-сервера, необходимо позаботиться о безопасности. Разберем основные http заголовки, которые могут представлять угрозу.

X-XSS-Protection

Заголовок может предотвратить некоторые XSS-атаки.

Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.

Это полностью отключит фильтр
Это включает фильтр, но очищает только потенциально вредоносные скрипты
Это включает фильтр и полностью блокирует страницу.

X-Frame-Options

Заголовок позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.

Настроить X-Frame-Options можно тремя способами:

: это полностью отключит функции iframe.
: iframe может использоваться только кем-то из того же источника.
: Это позволит размещать страницы в окнах iframe только с определенных URL-адресов.

X-Permitted-Cross-Domain-Policies

Аналогично механизму браузеров блокировки стороннего контента Adobe Flash имеет свой. Он регулируется файлами crossdomain.xml сайта, начиная с корневого каталога. Проблема с механизмом в том, что на любом уровне вложенности корневой регулирующий файл (политика безопасности) может быть переопределен. Чтобы избежать таких ситуаций, необходимо задать этот HTTP-заголовок.

Доступно несколько вариантов настройки:

— никакая политика не допускается
— разрешить только главную политику
— все позволено
— Разрешить только определенный тип контента. Пример — XML
— применимо только для FTP-сервера

Strict-Transport-Security

Заголовок Strict-Transport-Security запрещает использование незащищенного HTTP соединения на сайте, если есть защищенное HTTPS.

X-Content-Type-Options

Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.

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

Таким образом, обычные текстовые файлы могут быть интерпретированы как JavaScript со всеми вытекающими последствиями. Например, если у вас на сайте запрещена загрузка текстовых файлов с расширениями .js пользователями, то они могут загрузить в виде картинок текстовый файл, содержащий JavaScript-код, который может быть исполнен браузером.

Nginx + Apache = ❤️

Может показаться, что Nginx и Apache воюют друг с другом за долю рынка, но на самом деле они отлично работают вместе:

Ставим Nginx и Apache на один сервер.
Настраиваем Apache на обработку запросов на динамические страницы. Самый частый пример такого запроса — отдать страницу на PHP-движке Водрпресса.
Настраиваем Nginx, чтобы он обрабатывал все простые запросы и отдавал уже готовые статические страницы, которые запрашивают чаще всего.
Также говорим, чтобы Nginx обрабатывал всю остальную статику: отдавал, если нужно, отдельно файлы, картинки, музыку и прочее, что имеет постоянный адрес и содержимое.
А всё остальное, что нужно собирать динамически, — перенаправляем на Apache.

4 ответа

Решение

2019 обновление:

Это стабильные и зрелые продукты. HAProxy предназначен для балансировки нагрузки и лучше в этом, тогда как nginx является веб-сервером, который может выступать в качестве балансировщика нагрузки.

И то и другое:

Поддержка HTTPS
Поддержка веб-сокетов
Стабильные, зрелые и очень эффективные продукты
Может обрабатывать 10 тыс. Соединений с минимальной настройкой или без настройки

HAProxy:

Балансировка нагрузки TCP, TCP-SSL, HTTP и HTTPS
Больше гибкости при проверках работоспособности и условиях отработки отказа
Базовое кеширование (v1.8 — 2017)
Настраиваемый формат журнала, чтобы импортировать журналы доступа в kibana/splunk/graylog
Подробная страница состояния, чтобы увидеть активные запросы и состояние серверов
Экспортируемые метрики для интеграции с решениями для мониторинга (графит / прометей / данные)
Более ориентированный на высокую производительность. Лучше указывать на обработку 100 тыс. Соединений или 40 GbE-интерфейсов.

Nginx:

Балансировка нагрузки HTTP и HTTPS (TCP — UDP в платной версии)
Больше гибкости при кэшировании
Настраиваемый формат журнала, чтобы импортировать журналы доступа в kibana/splunk/graylog
Нет страницы статуса (только платная версия)
Нет экспортируемых метрик (только платная версия)
Может обслуживать локальные файлы
Может обслуживать приложения FastCGI (не CGI)

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

Nginx является открытым ядром, и многие функции доступны только в платной версии. Примечательно, что ему не хватает страницы состояния и показателей мониторинга, что является большим НЕТ НЕТ для работы балансировщика нагрузки.

2019-03-13 01:08

HAProxy — это просто балансировщик нагрузки / обратный прокси. Nginx — это веб-сервер, который также может работать как обратный прокси-сервер.

Вот некоторые отличия:

HAProxy:

Поддерживает ли TCP и HTTP-прокси (SSL добавлен с 1.5-dev12)
Больше вариантов ограничения скорости
Автор отвечает на вопросы здесь о сбое сервера;-)

Nginx:

Поддерживает SSL напрямую
Также есть кеширующий сервер

В Stack Overflow мы в основном используем HAProxy с nginx для разгрузки SSL, поэтому HAProxy — моя рекомендация.

2011-02-03 15:23

Я использую nginx для внешнего интерфейса HAProxy, но только для завершения SSL.

HAProxy — гораздо более настраиваемый и управляемый балансировщик нагрузки (по моему опыту).

Я также включил Varnish для кэширования статических объектов. (как специфический бэкэнд HAProxy)

Смотрите этот вопрос о сбое сервера для получения дополнительной информации. Заказ nginx/ лака /haproxy

2011-02-03 05:49

При необходимости только для балансировки нагрузки лучше прокси HA. Но сочетание nginix и HA-прокси может быть более полезным, поскольку nginix быстро предоставляет статический контент, он будет обслуживать все запросы статических данных, а затем отправлять все запросы HA-прокси, которые служат для балансировки нагрузки, и отправлять запросы на веб-сервер для обслуживания. запрос по балансировке нагрузки.

2012-10-16 15:40

Заключение

Я прилично заморочился с темой редиректов в nginx. Раньше никогда не обращал на них пристального внимания. Да и у других не видел акцента на этом. В интернете полно готовых вариантов перенаправлений на все случаи жизни, но рассмотрены они в отдельности. А вот так комплексно взглянуть на полный конфиг со всеми нюансами не приходилось.

В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему

А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx

Онлайн курс «SRE практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «SRE практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и Linux. Обучение длится 3 месяц, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

На курсе вы узнаете как:

Внедрить SRE практики в своей организации
Управлять надежностью, доступностью и эффективностью сервисов
Управлять изменениями
Осуществлять мониторинг
Реагировать на инциденты и производительность
Работать со следующим технологическим стеком: Linux, AWS, GCP, Kubernetes, Ansible, Terraform, Prometheus, Go, Python.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .