Skip to content

Latest commit

 

History

History
123 lines (77 loc) · 7.52 KB

readme.md

File metadata and controls

123 lines (77 loc) · 7.52 KB
Raw

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

На сервере 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, выводить все, что там есть.