Как быстро запустить всё и посмотреть.

На сервере 10.8.0.22 уже запущен сервер логов. Вам нужно

• открыть консоль,

• зайти в директорию client

• Запустить команду ./run-ta-logs-client.sh

В этом скрипте используется js конфиг для 22 го сервера: client-config-no-git-22.js.

Вы можете откопипастить конфиг в любой свой js файл, откопипастить ./run-ta-logs-client.sh и подправить свою копию, чтобы она подгружала ваш конфиг.

Замечание о пользовательских конфигах.

По умолчанию конфиги берутся из cfg/default-server-cfg.js и cfg/default-client-cfg.js. Вы можете своим конфигом перегружать какие хотите опции из дефолтного конфига. Все, что вы не определили в своём конфиге, возьмется из дефолтного.

Как запустить просмотрщик логов.

• Если нужно - создаем на сервере файл с конфигами сервера, см. default-server-cfg.js (возможно его и хватит). Там интересен только blackList, т.е. перечисление, какие логи не нужно смотреть. Если default-server-cfg.js вас не устроил, то полный путь к своему конфигу нужно прописать в системную переменную TA_SERVER_CFG.

• Запускаем на сервере ta-logs-server.js (для 22й машины запускается автоматом при деплое, для других когда примем PR будет запускаться).

• Создаем файл с конфигами клиента, см. default-client-cfg.js (возможно его и хватит). Там вас может заинтересовать адрес сервера, с которого клиент будет стягивать логи. Прописываем путь к вашему конфигу клиента в системную переменную TA_CLIENT_CFG

• Запускаем у себя локально ta-logs-client.js.

И вы будете видеть все warn и error сообщения, и все, что сыпется в stderr от всех процессов под pm2 (пока кроме коллектора).

Переменные окружения

• TA_SERVER_CFG - путь к JS файлу с конфигом для сервера. По умолчанию юзается default-server-cfg.js, см. его для примера.

• TA_CLIENT_CFG - путь к JS файлу с конфигом для клиента. См. default-client-cfg.js для примера.

TODO's

• Сделать систему сборки и распределения по серверам. На нашем bamboo уже забиты все слоты под билд проекты. Выбрать сервер. Время от времени пытаться подтянуть сорцы из репозитория. Если там есть что-то новое, подтянуть, сделать npm i, зазиповать. Раскидать по машинам. И на каждой машине запустить всё через pm2. Причем с фильтрами.

Выкладывать последнюю версию консольного клиента в архив куда-то. + Changelog.

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

А раскидывать по машинам нужно только ta-logs-server.

Посылать результаты в slack и на почту.

• Проследить за кэш заголовками, чтобы страница каждый раз обновлялась.

• Добавить старт веб сервера в автостарт при загрузке системы.

• Более умное определение уровня из строки. Надо чтобы строка info: error: считалась info. Для этого нужно перебрать все уровни, и определить, какой встретился раньше.

• Вынести общие куски кода для клиента и сервера в директорию common.

• GUI, с логином и паролем, и хранимыми настройками для каждого логина.

• Поддержать альясы для разных машин, например ta-logs-client.js 22 будет запускать клиент с перегрузкой адреса из конфига (заданного TA_CLIENT_CFG) на 10.8.0.22.

• В клиенте, сделать hotkey для очистки экрана.

• В клиенте сделать hotkey для хелпа по конфигурации и хоткеям.

• Поддержать и другие логи системы, например postgresql.

• Поддержать браузерные логи.

• Сделать в клиенте hotkeys для переключения уровня логирования.

• sails.log походу хреначит дебаг в stderr. Из-за этого показываются debug логи от криптования.

• Посмотреть как работают кластерные логи.

• Строка лога, не содержащая строки verbose, silly, debug, info и идущая после строки, содержащей error или warn, считается относящейся к последней error или warn. Но это не всегда так. Сторонний софт может спамить свои сообщения, миную нашу систему логирования. И тогда, если эти сообщения идут после наших строк c warn или error они будут показываться.

• При возникновении чего-то в ошибках или в stderr - хорошо бы писать об этом в slack.

TODO под вопросом.

• Занести запуск в общий processes.json.

• Поддержать логи вида *-10.log.

• Что сделать если в data будет строка разорванная. Т.е. кусочек. Есть ли гарантия, что строки будут всегда кончаться EOL и не разрываться посередине. Последить за артефактами в логах.

• Хранить все логи со всех серверов с авторотацией? Подумать над нужностью этого (я пока не понимаю пользы этого) и юз кейсами использования. Потребуется приведение логов в порядок, сейчас у нас штатные ситуации бывает в error сыпется. Какого уровня хранить?

Экспериментальные фичи (посмотреть как себя ведут).

• Не фильтровать stderr, выводить все, что там есть.