Руководство по системному администрированию#

Аннотация#

Настоящий документ представляет собой руководство по системному администрированию программного компонента Веб-сервер и обратный прокси-сервер SynGX (SNGX) из состава программного продукта Platform V SynGX (SNX). Программный компонент Веб-сервер и обратный прокси-сервер SynGX (далее - SynGX) является системным программным обеспечением (СПО).

Руководство содержит сценарии администрирования SynGX, а также описание событий системного журнала и мониторинга.

Термины и определения#

Термин/Аббревиатура

Определение

Сервис

Комплекс программных и аппаратных средств, обеспечивающих выполнение ограниченного набора функций

АС

Автоматизированная система

ОС

Операционная система

ЦОД

Центр обработки данных - специализированное здание или помещение, в котором размещается серверное и сетевое оборудование

Платформа, Platform V

Набор продуктов Platform V, правообладателем которых является АО «СберТех». Перечень таких продуктов обозначен в документации на конкретный продукт

Продукт, SynGX

Продукт Platform V SynGX (SNX), в состав которого входит компонент Веб-сервер и обратный прокси-сервер SynGX (SNGX)

ПО

Программное обеспечение

СПО

Системное программное обеспечение

ЦПУ

Центральное процессорное устройство

Веб-сервер

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

Обратный прокси-сервер (reverse proxy)

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

Nginx

Веб-сервер и обратный прокси-сервер

Клиент (с точки зрения SynGX)

Пользователь или сервис, делающий сетевой запрос к SynGX для получения ответа

Приложение (с точки зрения SynGX)

программный компонент, который предоставляет ответы на сетевые запросы клиентов

HTTP-запрос

Запрос по протоколу HTTP

HTTPS-запрос

Запрос по протоколу HTTPS

VM

Virtual machine - виртуальная машина

Администратор SynGX

Администратор SynGX, который устанавливает и настраивает SynGX на VM и обеспечивает его работоспособность

Сценарии администрирования#

Администрирование

Подключение к VM (VM - виртуальная машина), на которых установлен Продукт SynGX, для выполнения действий администрирования, должно осуществляться по протоколу SSH с использованием SSH-ключей.

Перечень доступных стандартных сценариев администрирования SynGX:

  • Запуск SynGX;

  • Остановка SynGX;

  • Перезапуск SynGX;

  • Изменение конфигурации SynGX;

  • Проверка корректности конфигурации с точки зрения SynGX;

  • Обновление версии SynGX (см. Руководство по установке);

  • Удаление SynGX (см. Руководство по установке).

Ряд действий, связанных с сопровождением SynGX администраторы АС могут выполнять с помощью самостоятельно подготовленных сценариев, при наличии технической возможности (например, с помощью сценариев RLM - Release Lifecycle Management).

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

Описание основных сценариев администрирования

В данном разделе будут описаны основные сценарии администрирования - запуск, остановка и перезагрузка конфигурации Продукта.

Предполагается, что SynGX уже установлен на сервере и произведена первичная настройка конфигурации Продукта.

Чтобы запустить SynGX, нужно выполнить исполняемый файл. Когда SynGX запущен, им можно управлять, вызывая исполняемый файл с параметром -s. Ниже показан базовый синтаксис:

syngx -s сигнал

Флаг -s отправляет сигнал главному процессу SynGX.

Вместо «сигнал» нужно подставить одно из следующих значений для управления процессом SynGX:

  • stop — быстрое завершение процесса: немедленно прекращает процесс SynGX - останавливает обслуживание полученных запросов;

  • quit — плавное завершение процесса: останавливает процесс SynGX после завершения обработки полученных до команды запросов;

  • reload — перезагрузка конфигурационного файла.

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

Подключение динамических модулей SynGX

В SynGX часть модулей подключается динамически. Это означает, что для их включения требуется произвести дополнительные действия после установки SynGX.

Ниже представлен список модулей с динамическим подключением:

Наименование модуля (названия динамических модулей SynGX)

Функционал модуля

ngx_devel_kit (ndk_http_module)

Модуль предназначен для расширения основных функциональных возможностей NGINX

lua-nginx-module (ngx_http_lua_module)

Модуль позволяет добавить логику обработки запросов с использованием языка программирования Lua

stream-lua-nginx-module (ngx_stream_lua_module)

Модуль позволяет добавить логику обработки запросов с использованием языка программирования Lua для протоколов TCP и UDP

njs/nginx (ngx_http_js_module, ngx_stream_js_module)

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

nginx-sslkeylog (ngx_http_sslkeylog_module)

Модуль добавляет переменные для логгирования данных SSL сессий

ngx_brotli (ngx_http_brotli_filter_module, ngx_http_brotli_static_module)

Модуль позволяет добавить алгоритм сжатия данных без потерь. Используется для сжатия ответов на лету либо для отдачи предварительно сжатых файлов

Необходимые действия для подключения динамического модуля:

  1. (опционально; пройти этот шаг 1, если требуется установка динамических модулей ngx_http_lua_module либо ngx_stream_lua_module) Установить и добавить в конфигурационный файл SynGX (файл с расширением .conf) модуль ndk_http_module (контекст main). Без него подключить модуль ngx_http_lua_module либо ngx_stream_lua_module будет нельзя!

    • Для установки модуля ndk_http_module в командной строке необходимо выполнить команду (пример команды): $sudo yum install ndk_http_module.rpm .

    • После чего в конфигурационном файле SynGX (файл с расширением .conf) требуется добавить директиву с указанием пути к файлу ndk_http_module.so (контекст main). Пример задания директивы: load_module /opt/syngx/modules/ndk_http_module.so .

  2. Установить модуль(-и) из RPM-пакета(-в) и добавить в конфигурационный файл (файл с расширением .conf) директиву(-ы) подключения модуля(-ей) (контекст main):

    • установить требуемый(-ые) динамический(-ие) модуль(-и). Для этого нужно для каждого модуля выполнить команду $sudo yum install {module_name}.rpm. Где {module_name} - название модуля (см. в таблице выше, названия динамических модулей SynGX даны в скобках);

    • после чего в конфигурационном файле SynGX (файл с расширением .conf) требуется добавить директиву(-ы) с указанием пути(-ей) к файлу(-ам) динамических модулей (контекст main). Пример задания директивы: load_module /opt/syngx/modules/{module_name}.so .

  3. После выполнения действий в шаге 2 необходимо выполнить перезагрузку конфигурационного файла SynGX сигналом reload.

Пример указания динамических модулей в конфигурационном файле SynGX (часть конфигурации SynGX):

syngx_dynamic_modules

Мониторинг работы SynGX

Администратору SynGX необходимо периодически производить проверку и осуществлять просмотр:

  • системных метрик сервера и SynGX (подробнее - см. ниже в разделе События мониторинга);

  • метрик работоспособности и статистики обработки запросов (подробнее - см. ниже в разделе События мониторинга);

  • журналов событий - error.log и access.log (подробнее - см. ниже в разделе События системного журнала).

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

При превышении пороговых значений, администратору нужно оперативно выявить причину повышенной нагрузки путем анализа значений различных системных метрик, метрик мониторинга SynGX, логов компонента SNGX, и предпринять необходимые действия для решения проблемы в соответствии с порядком разбора инцидентов АС (руководствоваться внутренним регламентом, порядком и нормами эксплуатирующей организации).

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

События системного журнала#

SynGX, как и Nginx, имеет возможность вести два вида журналов. В первый журнал, который называется error.log, SynGX записывает информацию о своей собственной работе. Количество информации, которая записывается в error.log, определяется в конфигурации SynGX, при этом формат журнала изменять нельзя. Во второй журнал, который называется access.log, SynGX записывает информацию об обработанных запросах клиентов. Формат сообщений, которые записываются в данный журнал, определяется в конфигурации SynGX.

Логгирование можно настроить в конфигурационном файле SynGX с расширением .conf, который по умолчанию располагается в директории /opt/syngx/conf. Конфигурацию задает администратор SynGX самостоятельно, согласно требованиям эксплуатирующей организации.

Журнал error log

В error log записываются сообщения об ошибках, возникающих в процессе работы сервиса, предупреждения, информационные сообщения, отладочные сообщения - в зависимости от выставленного уровня логгирования. Запись производится по следующей маске: время события, уровень события, номер процесса, сообщение по событию.

Настройка error log производится директивой error_log в конфигурационном файле с расширением .conf (по умолчанию syngx.conf).

Синтаксис:	error_log файл [уровень];

,где [уровень] - это выставляемый уровень логгирования журнала.

Основные типы (уровни) событий системного журнала:

  • Error — ошибки, возникающие в процессе работы сервиса;

  • Warn — предупреждения, возникающие в процессе работы сервиса;

  • Info — информационные сообщения, возникающие в процессе работы сервиса;

  • Debug — отладочные сообщения (детали взаимодействия с внешними системами), возникающие в процессе работы сервиса.

Подробнее про настройку директивы error log можно изучить на странице сайта Nginx: https://nginx.org/ru/docs/ngx_core_module.html#error_log .

Пример сообщения об ошибке:

2022/10/30 16:29:36 [error] 3923#3923: *63024022 connect() failed (111: Connection refused) while connecting to upstream, client: <ip-адрес клиента>, server: , request: "POST /hc_proxy/healthcheck/service-healthcheck/ufs-delivery-proxy HTTP/1.0", upstream: "https://<ip-адрес узла>:<port>/healthcheck/service-healthcheck/ufs-delivery-proxy"

Поскольку в SynGX события типа error записывает Nginx, подробнее про события данного типа, записываемые в error log, можно изучить по ссылке сайта Nginx: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ .

Журнал access log

В access.log ведется запись логов запросов в указанном формате. Логи записываются в контексте location’а, где заканчивается обработка.

Настройка access.log производится директивой access_log в конфигурационном файле с расширением .conf (по умолчанию syngx.conf).

Подробнее про настройку директивы access_log можно изучить на странице сайта Nginx: https://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log .

Дополнительная информация по системному журналу

По умолчанию, настроенные администратором события журнала локально записываются в директорию /opt/syngx/logs/ :

  • error.log;

  • access.log.

SynGX позволяет писать журналы в файлы на VM, а также отправлять их по протоколу syslog, что также определяется в конфигурации SynGX. При записи журналов в файлы на VM, необходимо иметь ввиду, что в ходе работы SynGX размер журналов постоянно увеличивается, поэтому необходимо предусмотреть способ ограничения размера логов, например, с помощью ротирования логов с помощью log rotate.

При необходимости отправлять журналы на другие VM, можно использовать различные схемы с использованием дополнительного ПО, например, RSYSLOG или fluetbit. Описание настройки этих компонентов можно посмотреть в документации на указанные сторонние компоненты.

В SynGX нет функционала отправки логов по протоколу Kafka, однако прикладной разработчик может донастроить SynGX, чтобы он мог отправлять логи по данному протоколу. Например, для этих целей можно использовать RSYSLOG.

События мониторинга#

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

При работе SynGX необходимо отслеживать два вида метрик:

  • системные метрики, к которым относятся потребление ЦПУ, использование оперативной памяти, наличие доступного дискового пространства и т.д. на VM. Системные метрики показывают, достаточно ли всем процессам, работающим в ОС на VM, ресурсов для корректной работы. Если какой-либо процесс или приложение (необязательно SynGX) в случае сбоя или ошибки начинает потреблять все доступные ресурсы, это начинает влиять на работу других процессов и приложений. С точки зрения SynGX негативное влияние будет приводить к увеличению времени обработки сетевых запросов, возникновению ошибок при установлении соединений и т.д. За получение и мониторинг системных метрик отвечают администраторы VM, на которых установлен SynGX, в соответствии с принятыми стандартами и практиками.

  • метрик работоспособности и статистики обработки запросов, к которым относятся количество установленных на текущий момент соединений, количество принятых запросов, количество обработанных HTTP запросов с кодами ответов 2xx, 3xx и т.д. Эти метрики показывают, насколько успешно обрабатываются запросы клиентов SynGX с течением времени. Например, в нормальном режиме количество обработанных HTTP запросов с кодами ответов 4xx и 5xx должно быть минимальным. Если их количество начинает расти, это признак того, что в цепочке обработки запросов возникли какие-то проблемы, которые требуют устранения. Количество установленных на текущий момент соединений характеризует текущий уровень нагрузки на SynGX. Если это количество начинает расти, это может быть признаком DoS атаки. Если это количество сильно снижается, это может означать наличие сетевых проблем при обращении к серверу SynGX (например, сбой DNS сервера).

Для мониторинга своей работы SynGX предоставляет метрики работоспособности и статистику обработки запросов в ответ на HTTP REST запрос. Адрес, на который необходимо отправлять запрос, а также формат ответа (в виде JSON-структуры или текстовом виде в формате Prometheus) настраиваются в конфигурации SynGX. Пример настройки такого рода приведен в предустановленной конфигурации SynGX.

При настройке адресов, по которым будут доступны метрики, необходимо использовать существующие в SynGX механизмы обеспечения безопасности (описанные в Руководстве по безопасности):

  • Настроить доступ только с использованием протокола TLS не ниже версии 1.2.

  • Настроить доступ с проверкой имени и пароля пользователя.

  • Настроить доступ с определенных сетевых адресов.

Возможность настроить SynGX, чтобы он самостоятельно отправлял метрики в какую-либо систему, не предусмотрена. Дополнительные метрики могут быть настроены администратором самостоятельно в конфигурации SynGX (конфигурационный файл с расширением .conf).

Полный перечень доступных метрик SynGX и способов их настройки описан ниже.

Перечень доступных метрик

Метрики предоставляют подключенные модули SynGX - nginx-module-vts, ngx_http_extstatus_module, nginx_upstream_check_module. Для доступа к конкретной группе метрик необходимо через командную строку отправить GET-запрос типа (запрос к модулю SynGX):

{ip-адрес сервера либо 127.0.0.1}/{location address}

, где {location address} - адрес, по которому можно получить метрики из конкретного модуля SynGX. Адрес настраивается в конфигурации SynGX.

Пример GET-запроса:

localhost:80/status_json

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

Модуль nginx-module-vts

Данный модуль предоставляет возможность получения статистики по запросам в разрезе виртуальных серверов в формате html-страницы, а также можно настроить выдачу в форматах json и prometheus. Помимо этого, рассматриваемый модуль может выдавать статистику по использованию кеша для статистического содержимого в форматах json и prometheus. Модуль обеспечивает предоставление следующих видов метрик:

  • main:

    • время безотказной работы ((nowMsec - loadMsec)/1000); nowMsec, loadMsec - в миллисекундах;

  • connections:

    • всего подключений и запросов (аналогично stub_status_module в NGINX);

  • sharedZones:

    • информация об объеме общей памяти, используемой модулем nginx-module-vts;

  • serverZones:

    • объем трафика (входящий/исходящий), количество запросов и ответов и коэффициент попадания в кеш на каждую зону сервера;

    • объем общего трафика (входящий/исходящий), количество запросов и ответов (имя зоны) и коэффициент совпадений;

  • filterZones:

    • объем трафика (входящий/исходящий), количество запросов и ответов, а также коэффициент попадания в кеш для каждой зоны сервера, отфильтрованной с помощью vhost_traffic_status_filter_by_set_key директивы;

    • общий объем трафика (входящий / исходящий), количество запросов и ответов (имя зоны *) и коэффициент совпадений, отфильтрованные с помощью vhost_traffic_status_filter_by_set_key директивы .

  • upstreamZones:

    • объем трафика (входящий/исходящий) и количество запросов и ответов на сервер в каждой вышестоящей группе;

    • текущие настройки (weight, maxfails, failtimeout…) в synx.conf

  • cacheZones:

    • объем трафика (входящий/исходящий), размер (capacity/used) и коэффициент попаданий на каждую зону кэша при использовании директивы proxy_cache.

Пример конфигурации для получения метрик приведен ниже:

server {
 ⁣ ⁣ ⁣ ⁣listen 80;

...

 ⁣ ⁣ ⁣ ⁣⁣location /vts {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣vhost_traffic_status_display;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣vhost_traffic_status_display_format html;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣error_log ⁣ ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣access_log ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣}
 ⁣ ⁣ ⁣ ⁣}

Модуль ngx_http_extstatus_module

Данный модуль предоставляет возможность получения детальной статистики по HTTP-запросам в разрезе кодов HTTP-ответов в форматах json и prometheus (нужна настройка в конфигурации SynGX). Помимо этого, он может выдавать статистику по использованию TLS-соединений в форматах json и prometheus (нужна настройка в конфигурации SynGX).

Название метрики

Описание метрики

active_connection

количество активных соединений

accepts

количество принятых запросов

handled

количество обработанных запросов

requests

количество запросов

reading

Текущее число соединений, в которых SynGX в настоящий момент читает заголовок запроса

writing

Текущее число соединений, в которых SynGX в настоящий момент отвечает клиенту

waiting

Текущее число соединений, по которым SynGX в настоящий момент ожидает ответа

syngx_uptime

Время запуска (старта) SynGX

syngx_time

Текущее время получения метрики

responses / 2xx

Количество 2XX HTTP-ответов

responses / 3xx

Количество 3XX HTTP-ответов

responses / 4xx

Количество 4XX HTTP-ответов

responses / 5xx

Количество 5XX HTTP-ответов

responses / codes / 200

Количество 200 HTTP-ответов

responses / codes / 403

Количество 403 HTTP-ответов

responses / total

Общее количество ответов, всего

ssl / handshakes

Количество TLS Handshake

ssl / ⁣handshakes_failed

Количество неудавшихся TLS Handshake

ssl / session_reuses

Количество переиспользованных сессий

Ниже приведен пример метрик в json-формате, которые выдаются при обращении к данному модулю.

{
 ⁣ ⁣"active_connection" : "2",
 ⁣ ⁣"accepts" : "6",
 ⁣ ⁣"handled" : "6",
 ⁣ ⁣"requests" : "5",
 ⁣ ⁣"reading" : "0",
 ⁣ ⁣"writing" : "1",
 ⁣ ⁣"waiting" : "1",
 ⁣ ⁣"syngx_uptime" : "67635",
 ⁣ ⁣"syngx_time" : "1664952670",
 ⁣ ⁣"responses" : {
 ⁣ ⁣ ⁣ ⁣"2xx": "2",
 ⁣ ⁣ ⁣ ⁣"3xx": "0",
 ⁣ ⁣ ⁣ ⁣"4xx": "2",
 ⁣ ⁣ ⁣ ⁣"5xx": "0",
 ⁣ ⁣ ⁣ ⁣"codes" : {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣"200": "2",
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣"403": "2"
 ⁣ ⁣ ⁣ ⁣},
 ⁣ ⁣ ⁣ ⁣"total": 4
 ⁣ ⁣},
 ⁣ ⁣"ssl" : {
 ⁣ ⁣ ⁣ ⁣"handshakes" : 0,
 ⁣ ⁣ ⁣ ⁣"handshakes_failed" : 0,
 ⁣ ⁣ ⁣ ⁣"session_reuses" : 0
 ⁣ ⁣}
}

Пример конфигурации для получения метрик приведен ниже:

server {
 ⁣ ⁣ ⁣ ⁣listen 80;

...

 ⁣ ⁣ ⁣ ⁣location /status_prometheus {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣snx_http_extstatus_prometheus on;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣allow ⁣ ⁣all;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣deny ⁣ ⁣all;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣error_log ⁣ ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣access_log ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣}

 ⁣ ⁣ ⁣ ⁣location /status_json {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣snx_http_extstatus_json on;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣allow ⁣ ⁣all;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣deny ⁣ ⁣all;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣error_log ⁣ ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣access_log ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣}
 ⁣ ⁣ ⁣ ⁣}

Модуль nginx_upstream_check_module

Данный модуль предоставляет возможность учета текущего состояния вычислительного узла в группе балансировки при распределении запросов. При базовой настройке конфигурации, он будет выдавать метрики в виде HTML-страницы. Однако, администратор может настроить выдачу в формате json или prometeus.

Данный модуль может отображать статусы по разным видам протоколов соединений healthcheck - HTTP, TCP, SSL-Helo.

Пример вывода при обращении к метрикам данного модуля:

syngx_upstream

Пример конфигурации для получения метрик приведен ниже:

server {
 ⁣ ⁣ ⁣ ⁣listen 80;

...

 ⁣ ⁣ ⁣ ⁣location /monitor_html {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣check_status html;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣error_log ⁣ ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣access_log ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣}

 ⁣ ⁣ ⁣ ⁣location /monitor_json {
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣check_status json;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣error_log ⁣ ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣access_log ⁣ ⁣ ⁣off;
 ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣ ⁣}
 ⁣ ⁣ ⁣ ⁣}

Часто встречающиеся проблемы и пути их устранения#

Невозможность запуска SynGX

Возможные причины:

  • наличие синтаксических ошибок в конфигурации SynGX

    • рекомендация: в данном случае администратору необходимо убедиться, что в конфигурационном файле SynGX нет синтаксических ошибок. После чего произвести запуск SynGX.

  • отсутствие необходимых файлов:

    • рекомендация: администратору необходимо пройти чек-лист руководства по установке SynGX. В случае отсутствия указанных в чек-листе файлов, требуется заново пройти инструкцию по подготовке сервера и инструкцию по установке SynGX;

Зависший процесс на сервере

Рекомендация: перезапустить процесс SynGX.

Зависший процесс может привести к невозможности штатной остановки SynGX. В таком случае, потребуется применить системную команду для прекращения процессов SynGX.

Некорректная логика обработки запросов

Рекомендация: администратору необходимо проверить конфигурационный файл на предмет наличия логических ошибок в конфигурации: корректность указанных директорий, путей (locations), а также настройка выставленных директив. Также нужно убедиться, что на сервере в указанных директориях присутствуют необходимые файлы.

Проблемы (ошибки) при подключении динамических модулей

Проблема: сообщение unknown directive при запуске/при перезагрузке/при проверке конфигурационного файла SynGX.

Возможные причины:

  1. отсутствие установленного и корректно добавленного в конфигурационный файл требуемого динамического модуля;

  2. отсутствие библиотеки libluajit при подключении динамического модуля ngx_http_lua_module либо ngx_stream_lua_module;

  3. отсутствие установленного и добавленного в конфигурационный файл модуля ndk_http_module при подключении динамического модуля ngx_http_lua_module либо ngx_stream_lua_module.

Рекомендации:

  1. проверить, к какому модулю относится директива, и убедиться, что модуль установлен и корректно подключен (см. подраздел Подключение динамических модулей SynGX данного Руководства по системному администрированию);

  2. при использовании динамического модуля ngx_http_lua_module либо ngx_stream_lua_module необходимо проверить наличие библиотеки libluajit. При отсутствии, ее необходимо установить согласно Руководству по установке документации SynGX;

  3. при использовании динамического модуля ngx_http_lua_module либо ngx_stream_lua_module необходимо проверить установку и добавление в конфигурационный файл SynGX модуля ndk_http_module (см. подраздел Подключение динамических модулей SynGX данного Руководства по системному администрированию).