Fleetrun
Hecterra
NimBus
Другие приложения
Wialon для Android/iOS
Logistics
Wialon Local
Wialon Hosting
WiaTag
Configurator
LeaseControl
Содержание
Возможные проблемы в работе Wialon Local
  • technical_consulting
  • administration_system
  • sms
  • backup

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

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

Ошибки системы администрирования

При входе в систему администрирования вы можете столкнуться с разными ошибками. Исходя из кода и имени ошибки, выберите один из следующих вариантов решения.

The site can't be reached / Unable to connect / Page not found

Недоступность сайта и вывод ошибок с таким текстом может быть связана с состоянием nginx.

 Решение

Сперва следует убедиться в том, что nginx работает:

service nginx restart
service nginx status #(проверка состояние сервиса)
nginx -t             #(проверка синтаксиса файлов, если сервис не запустился)

Пример вывода ответов на команды при правильной работе сервиса:

nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
Active: active (running) since Tue 2021-08-03 13:46:09 MSK; 2min 56s ago

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если в конфигурации nginx имеются ошибки синтаксиса или nginx не работает, то следует решать проблему на уровне специалистов, обслуживающих сервер.

404 Not Found

Если система администрирования недоступна и возвращает ошибку «404 Not Found», то, скорее всего, установка сервиса Wialon Local была произведена некорректно и файлы, необходимые для работы сервиса, просто отсутствуют.

 Решение

В такой ситуации следует:

  1. Проверить, есть ли в директории /home/wialon/wlocal папка «install».
    Если такой папки нет, то вероятно, что произошел сбой при установке Wialon Local. Если папка присутствует, попробуйте перезапустить процесс Wialon Local:

    service wlocal restart
  2. Попробуйте переустановить Wialon Local из официального образа, соблюдая при этом все необходимые требования:
    • Установка должна производиться в BIOS режиме, а для UEFI в Legacy режиме;
    • При установке OS нельзя пропускать шаг с указанием настроек подключения к сети;
    • Должны отсутствовать другие сетевые ограничения к серверу, которые не позволяют загрузить соответствующие пакеты для работы сервиса.

Если после переустановки Wialon Local результат не поменялся, то обратитесь на почту support@wialon.com для ручной установки сервиса.

502 Bad Gateway

Ошибка «502 Bad Gateway» при обращении к системе администрирования может быть связана со статусом процессов, связанных с работой Wialon Local.

 Решение

Проверка:

ps aux | grep -v grep | grep node
top | grep wialon

Пример ожидаемого списка активных процессов из первой команды при рабочем сервисе:

wialon 701 0.0 2.3 591208 47884 ? Ssl 12:27 0:00 /usr/bin/node /usr/lib/node_modules/forever/bin/monitor cron.js
wialon 713 1.3 36.4 1491260 745596 ? Sl 12:27 0:49 /usr/bin/node /home/wialon/wlocal/cron.js

Если для указанных команд приходит пустой ответ либо же отсутствует процесс cron.js из первой команды, то процессы Wialon Local не запущены. Попробуйте запустить сервис заново:

service wlocal restart
service wlocal status #(проверка запуска)

Если сервис не может запуститься, следует:

  1. Проверить версию пакетов, необходимых для работы Wialon Local, с помощью команд:

    node -v 
    nodejs -v
    npm -v
    npm -g list | grep forever

    Ответы на первые две команды должны соответствовать требованиям к версии Wialon Local, указанным в документации:

    Версии Wialon LocalВерсии DebianВерсии Node.js
    1504, 1604, 17048 (Jessie)0.10.x
    1704, 1804, 19049 (Stretch)6.x
    1904, 2004, 210410 (Buster)10.x

    Если версия Node.js не соответствует требуемой, следует ее обновить.
    Пустой ответ на третью и/или четвертую команду говорит об отсутствии пакета npm и его модуля forever. Для их установки обратитесь к инструкции из документации.

  2. Проанализировать логи сервиса Wialon Local в /home/wialon/wlocal/logs/lcm/ и, при наличии ошибок, связанных с Node.js, переустановить компоненты Wialon Local, необходимые для корректной работы, в соответствии с документацией. Пример подобных ошибок:

    Error: Most middleware (like json) is no longer bundled with Express and must be installed separately ...

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

Если после выполненных действий система администрирования по-прежнему недоступна, то напишите на почту support@wialon.com.

Ошибка «502 Bad Gateway» при выполнении отчета

Если при выполнении отчета в Wialon вы были перенаправлены на страницу с ошибкой «502 Bad Gateway» или она наблюдается в консоли браузера при выполнении отчета, то, скорее всего, запрашиваемый отчет пытается загрузить ресурсы, доступ к которому у вас ограничен.

 Решение

Это может происходить при выполнении отчета, для которого используются дорожные ограничения скорости, связанные с Gurtam Maps. В таком случае следует проверить, открыты ли у вас необходимые доступы к ресурсам Gurtam Maps: lic.gurtam.com 18611-18614

Если вы пользуетесь другими картами (Yandex, Google), то следует открывать соответствующие доступы к их серверам.

Проблемы с авторизацией в Fleetrun/Nimbus

Если с имеющимся у вас паролем для пользователя wialon вам не удается авторизоваться в приложениях Fleetrun или Nimbus, но при этом вы можете авторизоваться на сайте мониторинга, то следует проверить, выполнены ли требования к работе приложений.

 Решение

Требования для работы Fleetrun и Nimbus в Wialon Local описаны в документации:

  • Наличие отдельной DNS;
  • Наличие flespi token в панели администратора;
  • Активирована соответствующая услуга в учетной записи;
  • Наличие полной цепочки SSL-сертификатов для DNS, которая используется для приложения (приложение должно работать по HTTPS);
  • Для Nimbus: наличие подключенных карт Gurtam Maps;
  • Наличие прямых доступов к:
    apps.wialon.com 80/443
    mqtt.flespi.io 8883 (SSL) or 1883 (non-SSL)

Если все требования соблюдены, но проблема с авторизацией в приложения все еще осталась, обратитесь на support@wialon.com

Увеличение размера кэша синхронизации

При использовании модуля резервного копирования Wialon Local можно столкнуться с серьезным увеличением файлов кэша синхронизации с резервным сервером, что может привести к переполнению дискового пространства на основном сервере. Пример имени такого файла: /home/wialon/wlocal/storage/md/sync.cache.1983335884. Зачастую это происходит из-за сетевых проблем между основным и резервным серверами, из-за различия в скоростях записи данных на диски или из-за того, что скорости канала связи недостаточно для передачи поступающего объема данных.

 Решение

Прежде всего следует проверить, имеются ли какие-либо сетевые ограничения между резервным и основным серверами, и выполнить базовую проверку доступности резервного сервера по стандартному порту 32001, например, через telnet с основного сервера Wialon Local:

telnet <адрес_резервного_сервера> 32001 

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

Также следует проанализировать логи модуля резервного копирования в файле /home/wl_storage_backup/logs/trace.log на предмет ошибок. В частности, в логах могут быть ошибки следующего типа:

trace.log
2021/05/24 17:19:50:007: [INF:73907700] net_session::bg_task(2167042, '192.168.0.15:32001'): pipe not connected
2021/05/24 17:19:50:007: [INF:4CA1E700] messages_sync_server::sync_thread('192.168.0.15:32001:******'): invalid reply from synchronization server

Такие ошибки свидетельствуют о проблемах с доступом между серверами.

В случае длительной недоступности сервера резервного копирования, или если файлы кэша синхронизации занимают очень большой объём на диске, следует остановить модуль резервного копирования на резервном сервере с помощью команды:

service wlbackup stop

После этого необходимо решить проблемы с доступом между серверами и удалить резервную копию базы данных в директории /home/wl_storage_backup/storage

Далее в системе администрирования основного сервера следует остановить сервис Wialon, а затем выполнить команду «service wlocal stop» для остановки сайта системы администрирования, и только после этого удалить критически переполненные файлы кэша синхронизации, например, с помощью команды:

find /home/wialon/wlocal/storage -name sync.cache.* -type f -delete

При ручном удалении файлов кэша синхронизации учитывайте тот факт, что необходимые файлы лежат в разных папках директории /home/wialon/wlocal/storage и имеют названия такого формата: sync.cache.1983335884, где цифры в конце могут меняться.

Процесс синхронизации после выполнения всех процедур запускается в два этапа: сначала включается Wialon Local на основном сервере, затем на резервном. Для этого используются следующие команды:

На основном:
service wlocal start

На резервном:
service wlbackup start

Об окончании процесса синхронизации на резервном сервере свидетельствует запись вида «sync finished» в файле /home/wialon/wlocal/logs/trace.log. Также для дополнительной проверки вы можете сопоставить статистику по сообщениям на основном сервере в файле /home/wialon/wlocal/storage/ms/msgs_stats.txt и на резервном в /home/wl_storage_backup/storage/ms/msgs_stats.txt — при полной синхронизации цифры должны быть сопоставимы.

Проверка подключения модема к Wialon Local

При любых затруднениях с подключением модема к Wialon Local следует анализировать логи в /home/wialon/wlocal/logs

Передача SMS на отправку SMPP-шлюзом или GSM-модемом логируется в trace.log сервиса Wialon. Коммуникация со шлюзом или GSM устройством, а также отправка SMS, логируется в логах /home/wialon/wlocal/logs/ с названиями smpp_device_* / gsm_device_*.

 Решение

Примеры логов:

 SMPP-шлюз

После создания и включения SMPP-шлюза, создается отдельный лог-файл smpp_device_*.log , в который записываются все ошибки соединения и логируется факт соединения.
Также все взаимодействия со шлюзом будут отображены в trace.log.

Например при отсутствии соединения с SMPP-шлюзом в указанных логах будут фигурировать сообщения формата:

smpp_device_*.log
2021/07/16 15:50:52:031: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:52:12:289: [INF:C2B98700] Can`t connect to SMPP server
trace.log
2021/07/16 15:51:06:556: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server
 GSM/Network модемы

Взаимодействие с GSM- и сетевыми модемами до момента установления первого соединения будет фиксироваться только в trace.log.
Пример записей в логе при отсутствии соединения с модемом:

GSM trace.log
2021/07/16 15:55:16:332: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:55:16:332: [INF:C2B98700] remote_gsm_device::start(88)

И больше никаких сообщений общения с модемом.
Network trace.log
2021/07/16 15:56:23:400: [INF:AADC7700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0

И больше никаких сообщений общения с модемом.

Для диагностики соединения всегда проверяйте доступность удаленного хоста или шлюза, а также что модем смонтирован по указанному в панели администратора адресу и реагирует на команды (например через minicom).

Если согласно логам SMS-сообщения отправляются из сервиса Wialon, но не доходят до конечного адресата, то проблему следует решать на стороне получателя либо на стороне самого модема. Аналогичным образом следует поступать при отсутствии соединения с модемом или удаленным шлюзом: такие проблемы должны решаться на уровне собственной сети, модема или шлюза. В любых других ситуациях обращайтесь на support@wialon.com.

Перенос Wialon Local на новый сервер

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

 Решение

Процесс переноса (миграции) сервиса Wialon Local следует выполнять в описанной ниже последовательности:

  1. Сообщить о дате переноса вашему персональному менеджеру.

  2. Развернуть на новом сервере Wialon Local из официального образа, строго следуя официальной инструкции до шага 5 включительно (т.е. не авторизовываться в панели администратора). 
  3. Остановить сервис Wialon в системе администрирования старого сервера, а затем выполнить команду «service wlocal stop» для остановки сайта самой системы администрирования.
  4. Авторизоваться в системе администрирования нового сервера, дождаться установки основных модулей, необходимых для работы Wialon Local.
  5. Включить Wialon на новом сервере и убедиться в его стабильной работе.
  6. Остановить сервис Wialon в системе администрирования нового сервера, а затем выполнить команду «service wlocal stop» для остановки сайта системы администрирования.
  7. Произвести копирование содержимого директории /home/wialon/wlocal/storage со старого сервера на новый в ту же директорию. Предварительно удалить содержимое директории /storage на новом сервере. После переноса выполнить команду на новом сервере:

    chown -R wialon:wialon /home/wialon/
  8. Вновь запустить сервис Wialon Local (команда service wlocal start) и Wialon в системе администрирования на новом сервере для того, чтобы убедиться, что подстановка базы данных прошла успешно и сервис корректно работает.

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

Поврежденные файлы базы данных

Если после аварийной остановки или сбоя сервера Wialon не может запуститься и ссылается на поврежденные файлы базы данных, то в файле trace.log можно увидеть следующую запись:

trace.log
2021/08/17 12:50:26:649: [INF:FAB26740] storage_service_db::open_databases: opening database environment...
2021/08/17 12:50:26:713: [INF:FAB26740] storage_service_db::open_databases: opening databases...
2021/08/17 12:50:26:714: [INF:FAB26740] storage_messages_env::open_environment: opening database environment (cache: size: 12104 MB, chunks: 1)...
2021/08/17 12:50:28:049: [INF:FAB26740] storage_messages_env::open_environment: recovering environment: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
2021/08/17 12:50:28:841: [INF:FAB26740] adf_load_plugin('storage_server'). Error loading plugin. Error initializing storage subsystem as server.
2021/08/17 12:50:28:841: [INF:FAB26740] Error: couldn`t load ADF plugin: 'storage_server'.

В случае, когда сервис Wialon продолжает работать, и при этом в логе содержатся записи «Fatal error, run database recovery», следует немедленно остановить Wialon (сервис и сайт системы администрирования) и приступить к восстановительным процедурам.

 Решение 1

Прежде всего, если вы используете сервер резервного копирования, следует проверить файлы резервной копии вашей БД на резервном сервере в директориях /home/wl_storage_backup/storage/md и home/wl_storage_backup/storage/pd с помощью скрипта db_verfify , который следует создать в директории /home/wialon/wlocal . Его содержимое представлено ниже. Выполнять скрипт необходимо строго из этой же директории (home/wialon/wlocal) с помощью команды ./db_verify.sh

db_verify.sh
#! /bin/sh
export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0
db_verify /home/wialon/wlocal/storage/pd/*.db
db_verify /home/wialon/wlocal/storage/md/*.db

Если есть подозрения на повреждения каких-то конкретных db-файлов, то вместо *.db в последней строчке можно подставить название конкретно файла БД, например, m-00000001.db . Тогда строчка будет иметь вид:

db_verify /home/wialon/wlocal/storage/md/m-00000001.db

Пример результата работы скрипта:

Успешная проверка:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000001.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000002.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db succeeded.

Файл БД не прошел проверку:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db failed.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000004.db failed.

В случае, если в результате проверки не обнаружится ошибок, у вас есть 2 варианта действий:

  1. Прежде чем совершать какие-либо манипуляции с подстановкой базы данных, следует выключить Wialon из системы администрирования на основном сервере и сам сервис Wialon Local (service wlocal stop), а также на бэкап-сервере выключить сервис резервного копирования (service wlbackup stop). После этого заменить БД на основном сервере (директория /home/wialon/wlocal/storage) БД резервного сервера (директория /home/wl_storage_backup/storage) и запустить Wialon.
  2. Воспользоваться резервным сервером в качестве основного согласно инструкции Восстановление при сбое.

Если db-файлы на сервере резервного копирования тоже оказались повреждены, попробуйте удалить резервную БД и запустить процесс синхронизации еще раз. Как только он закончится, проверьте скопированную БД с помощью скрипта db_verify и, в случае его успешного выполнения, можете подставить ее на основной сервер. Подстановку базы следует проводить из директории /home/wl_storage_backup с резервного вместо директории /home/wialon/wlocal/storage на основном. При этом битую БД основного сервера рекомендуется сохранить в отдельном месте и не удалять до тех пор, пока не получится запустить Wialon без ошибок.

 Решение 2

Если решение с использованием сервера резервного копирования вам не помогло, то можно попробовать воспользоваться стандартными утилитами для восстановления отдельных файлов вручную. Рекомендуем также еще раз выполнить скрипт db_verify и локализовать все битые db-файлы перед дальнейшими действиями. Рассмотрим этот вариант на примере файла /home/wialon/wlocal/storage/md/m-00000007.db (если есть другие поврежденные файлы, то поступать с ними нужно аналогичным образом).

Остановите сервис Wialon в системе администрирования, а затем выполните команду «service wlocal stop» для остановки сайта системы администрирования. После этого в директории /home/wialon/wlocal выполните следующие команды:

export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0

После этого можно начать манипуляции с БД (скрипты ниже уже есть в Wialon, и их нужно просто выполнить в той же директории /home/wialon/wlocal):

db_dump -r /home/wialon/wlocal/storage/md/m-00000007.db | db_load /home/wialon/wlocal/storage/md/m-00000007.db.new

Потом в директории /home/wialon/wlocal/storage/md переименуйте новый и старый файл БД, с помощью команд:

 mv m-00000007.db m-00000007.db.old

 mv m-00000007.db.new m-00000007.db

Это стандартные утилиты для работы с БД, которые пересоздадут ваш db-файл заново.

После этого запустите Wialon и проверьте trace.log на наличие ошибок. Затем еще раз прогоните файл m-00000007.db и другие битые файлы через скрипт db_verify. при остановленном сервисе.

Если ни одна из указанных рекомендаций вам не помогла, то напишите на почту support@wialon.com и опишите все выполненные вами действия, а также проблемы, с которыми вы столкнулись при восстановлении файлов БД.

Проблемы с доставкой почты

Вы можете столкнуться с ситуацией, когда письма из Wialon не доходят до адресатов. При этом проблема может наблюдаться не во всех сервисах. Например, отправка писем из системы администрирования Wialon Local работает, а из самого Wialon — нет.

В Wialon Local существует два механизма отправки почтовых уведомлений. Знание их особенностей может быть полезно при диагностике потенциальных проблем.

 Отправка писем из системы администрирования

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

  1. Отправка с помощью SMTP-сервера, заданного в системе администрирования;
  2. Отправка посредством postfix, которая осуществляется, если настройки SMTP не заданы, либо если письмо не получается передать на отправку указанному почтовому шлюзу.

Логи с указанием способа и статуса отправки находятся в файле /home/wialon/wlocal/logs/lcm.log.*

При использовании собственного SMTP-сервера, логи отправки следует анализировать на стороне самого SMTP, где он развернут, а в случае с postfix логи можно посмотреть в /var/mail/ или в /var/log/mail.log.*

Также следует отметить, что Wialon Local поддерживает использование других почтовых сервисов помимо postfix, так как запрос на отправку письма передается на localhost. Таким образом, если вы решите, например, использовать exim вместо postfix, то следует убедиться, что он сможет обрабатывать все входящие почтовые запросы с localhost адреса сервера.

Начиная с Wialon Local 2104, в поле Логин для настроек SMTP-сервера в системе администрирования вы задаете не только логин для авторизации в вашем почтовом шлюзе, но еще и имя отправителя. В случае если из всех настроек SMTP-сервера у вас заполнено только поле Логин, то запрос на передачу письма уйдет к postfix под заданным логином. Если в postifix нет пользователя с таким логином, то письмо не отправится. Поэтому если вы не используете свой собственный SMTP-сервер, то все относящиеся к нему поля рекомендуем оставлять пустыми.

 Отправка писем из Wialon

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

  1. Отправка с помощью SMTP-сервера, заданного в тарифном плане (обратите внимание, что в тарифном плане адрес SMTP-сервера следует обозначать вместе с протоколом, например «smtps://smtp.gmail.com» );
  2. Если SMTP в тарифном плане не задан, то письмо будет отправлено с помощью SMTP, указанного в системе администрирования;
  3. Если ни один из SMTP-адресов не указан, то письмо будет отправлено с помощью postfix.

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

Логи того, какой службе было передано письмо, а также статус отправки можно найти в файле /home/wialon/wlocal/logs/trace.log по фильтру «email». Конечные логи отправки с помощью SMTP-сервера следует смотреть на стороне самого SMTP-сервера. Логи отправки через postfix все также следует смотреть в /var/mail/ или в /var/log/mail.log.*

В данном механизме тоже доступна возможность использования своего собственного почтового сервиса вместо postfix, если он аналогично привязан к localhost адресу сервера.

Диагностикой неполадок и конфигурацией отправки почты с помощью SMTP или postfix должен заниматься технический специалист, который обслуживает сервер Wialon Local. В рамках технической поддержки услуги по диагностике и конфигурации почтовой системы не предоставляются.

Большое использование RAM

При работе с Wialon Local можно заметить, что сервис постоянно потребляет почти все доступное количество оперативной памяти сервера. Это вполне ожидаемое поведение, так как сервис Wialon кэширует почти всю доступную оперативную память, но активно использует лишь некоторую ее часть.

 Решение

Wialon Local кэширует почти всю доступную для своей работы оперативную память вне зависимости от её количества на сервере. Сервис Wialon кэширует всю RAM для обработки запросов и задач, для быстрого доступа к страницам и для недопущения возможных задержек и проблем, связанных с отказов в доступе из-за использования RAM другими приложениями на сервере. Кэшированная RAM управляется балансировщиком нагрузки, который перераспределяет кэшированную RAM для WIalon или других приложений на сервере. Но по умолчанию приоритет отдается именно Wialon.

При этом вы можете проконтролировать использование оперативной памяти в системе администрирования на графике RAM. При наведении курсора на каждый участок графика вы можете увидеть запись о том, сколько памяти в данный момент активно используется, а сколько закэшировано.

При недостатке оперативной памяти для корректной работы сервиса Wialon, в логе /home/wialon/wlocal/logs/trace.log можно увидеть записи вида:

2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216

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

Проблемы с конфигурацией nginx

Все сайты сервиса Wialon Local работают с помощью веб-сервера nginx. Иногда при обновлении или переустановке веб-сервера nginx сайты перестают быть доступны по тем или иным причинам. В таких случаях следует вернуться к первоначальной конфигурации nginx которая была на сервере после установки из официального образа Wialon Local.

 Решение

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

Для последующей работы полезно понимать, какие конфигурационные файлы и настройки присутствуют на сервере сразу после установки Wialon Local. Все необходимые конфигурационные файлы будут находиться в директории /etc/nginx/conf.d/, а их стандартный вид после установки описан ниже.

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

    server {
            listen          80;
            server_name     <your_IP>;
            client_max_body_size 10000m;
            proxy_read_timeout 500;
            location /50x.html {
                    root /home/wialon/wlocal/nginx/www/nginx-default;
            }
            location / {
                    if ( $args ~* dns-test ) {
                            echo 1;
                    }
                    proxy_set_header Upgrade $http_upgrade;
                    proxy_set_header Connection "Upgrade";
                    proxy_pass         http://localhost:8080;
            }
    
            access_log /var/log/nginx/lcm.access.log;
    
    }
  2. cms.conf временный конфигурационный файл CMS Manager.

    server {
             listen 8024;
             server_name <your_IP>;
             proxy_set_header Host your.cms_manager.DNS.0:8024;
             proxy_set_header X-Forwarded-For $remote_addr;
             client_max_body_size 64m;
             access_log /var/log/nginx/wdc.access.log;
             location /50x.html {
                     root /home/wialon/wlocal/nginx/www/nginx-default;
             }
             location / {
                     proxy_pass http://localhost:8022;
             }
    }
  3. webmonitor.conf временный конфигурационный файл Wialon Web.

    server {
             listen 8025;
             server_name <your_IP>;
             proxy_set_header Host your.wialon_web.DNS.0:8025;
             proxy_set_header X-Forwarded-For $remote_addr;
             client_max_body_size 64m;
             access_log /var/log/nginx/wdc.access.log;
             location /50x.html {
                     root /home/wialon/wlocal/nginx/www/nginx-default;
             }
             location / {
                     proxy_pass http://localhost:8022;
             }
    }
  4. local.conf основной конфигурационный файл, который отражает все настройки сайтов, указанных в системе администрирования.
    Данный файл является символической ссылкой на файл, который автоматически формируется исходя из настроек сайтов в системе администрирования и находится по адресу /home/wialon/wlocal/nginx/conf/local.conf.

    Данный конфигурационный файл категорически запрещается редактировать, также не рекомендуется отвязывать символическую ссылку. Все необходимые настройки для ваших сайтов Wialon рекомендуется вносить в системе администрирования. Если вы используете собственный конфигурационный файл вместо автоматически созданного local.conf, вся ответственность за работоспособность сайтов возлагается на администратора сервера Wialon Local.

    Если по какой-либо причине символическая ссылка local.conf отвязалась, её следует вернуть с помощью команды:

    ln -s /home/wialon/wlocal/nginx/conf/local.conf /etc/nginx/conf.d/local.conf

В первых трех конфигурационных файлах параметр <your_IP> в пункте server_name обозначает локальный IP-адрес вашего сервера Wialon Local, к которому будут привязаны стандартные конфигурационные файлы. Этот IP-адрес потом можно изменить.

Следует понимать, что конфигурационные файлы webmonitor.conf и cms.conf являются временными исключительно потому, что используются для временного доступа к сайтам Wialon через IP-адрес и порт, а также для первичной проверки работоспособности сервиса до заведения отдельных DNS-записей для сайтов. Как только вы создадите отдельную DNS-запись для этих сайтов в системе администрирования, данные файлы уже будут неактуальны, и их рекомендуется удалить. До этого момента доступ к сайтам может осуществляться по следующим адресам: 

  • Система администрирования Wialon Local: http://<your_IP> или по loopback адресу самого сервера http://localhost:8080
  • Сайт CMS Manager: http://<your_IP>:8024 или по loopback адресу самого сервера http://localhost:8024
  • Cайт Wialon Web: http://<your_IP>:8025 или по loopback адресу самого сервера http://localhost:8025

Все необходимые логи веб-сервера и ошибки можно найти в /var/log/nginx/

Улучшение безопасности nginx

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

 Решение
  1. Расширить поддержку версий протокола TLS в /etc/nginx/common/default.conf:

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  2. Задать максимальный срок действия сертификатов SSL в /etc/nginx/common/default.conf:

    add_header Strict-Transport-Security "max-age=31536000;
    includeSubDomains" always;
  3. Изменить используемый список шифрований в /etc/nginx/common/default.conf (весь перечень шифрований можно найти здесь):

    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
  4. Вручную добавить SSL-сертификат для сайта системы администрирования в /etc/nginx/conf.d/lcm.conf:

    server {
           listen          443;
           ssl on;
           ssl_certificate /root/ssl_certificate.crt; # абсолютный путь к сертификату
           ssl_certificate_key /root/private.key; # абсолютный путь к приватному ключу
           server_name     <your_IP>;     
           ...

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


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

Владимир Мелекесцев,Инженер Customer Service

Если вы заметили ошибку в тексте, пожалуйста, выделите её и нажмите Ctrl+Enter.
Спасибо за ваш отзыв!
Сообщить об ошибке
Текст с ошибкой Комментарий
Максимум 500 символов