Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Мониторинг удаленных лог-файлов на сервере через SSH, во время выполнения тестов.

ssh
logs
junit
testng
java
Теги: #<Tag:0x00007f7b6d57df60> #<Tag:0x00007f7b6d57de20> #<Tag:0x00007f7b6d57dce0> #<Tag:0x00007f7b6d57dba0> #<Tag:0x00007f7b6d57da60>

(Иван Приходько) #1

Добрый день коллеги! Нужен совет как лучше сделать мониторинг логов. Кто как делал и делал ли кто ни будь что-то такое?
Цель:

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

Текущая реализация: Написан некий MessageWaiter который с заданным интервалом грепает заданный лог-файл и отбрасывает результаты по таймстемпу, отличающемуся от времени старта теста.
Недостатки:

  • Необходимость использовать Thread.sleep для синхронизации, так как иногда случается появление сообщений с разницей в несколько секунд до даты старта теста. Как итог - сообщения о завершении операции попадают в фильтр как случившиеся до времени запуска теста.

Какие есть идеи:

  • Идея 1
  1. При старте теста делать нечто вроде > tail -f logfile,log>> /qa_home/testExecTimeStamp/testname/logfile.log &
  2. При завершении теста - грохать

kill $(ps aux|grep “/qa_home/testExecTimeStamp/testname/logfile.log” |grep -v| awk ‘{print $2}’) и удалять файлы после завершения теста.

  1. Ожидаемые сообщения по тесту - грепать исключительно из нагенеренных файликов.
  • Идея 2
  1. При старте теста указывать список файлов для монитринга и запускать его в отдельных потоках. Все новые строчки класть например в мапу.
  2. Искать ожидаемые сообщения по этой мапе.
  • Идея 3
  1. Расставить после записи времени старта теста большие Thread.sleep что приведет к увеличении времени прогона авто-тестов, но с определенной гарантией отсечет проблемы появления сообщений с таймстемпом ДО старта самого теста.


(Sergey Pirogov) #2

shoogr https://github.com/aestasit/sshoogr


(Иван Приходько) #3

За информацию о данном фреймворке - спасибо! Интересный вариант работы с консолью из коробки.
Но немножко не по теме. У нас еще на заре была написана обертка над jsc, которая прекрасно работает и выполняет все задачи которые от нее требовались. Вопрос о том как подключится - не стоит.
Тут вопрос идеологический - как лучше мониторить лог?


(Artur Korobeynyk) #4

Засуньте в конструктор и деструктор тестов подсчет колличества строк в файле лога. В деструкторе сохраняйте разницу строк куда вам надо.


(Иван Приходько) #5

Good Idea! Подумаю.


(Artur Korobeynyk) #6

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


(Иван Приходько) #7

Производительность не важна - wc -l и sed -n from,top вполне хватает. Большие логи у нас в архивы уезжают. А тесты гоняем на обрезанных энвах на которых только автотесты и крутятся. Могут возникнуть проблемы с параллельным выполнением, так что вариант с отловом сообщений по номеру строки в этом случае может накосячить, но такие тесты я не планирую запускать параллельно. Спасибо за идею! Попробую организовать грепалку по этому принципу.


(Михаил Братухин) #8

А есть идеи как подобное можно было бы реализовать на виндовой машине? Думаю, может для себя в тестах добавить дополнительные проверки по логам приложения. Оно правда на виндовой машине работает.


(Иван Приходько) #9

Мне кажется Следует смотреть в сторону оболочки Cygwin с никсовыми пакетами tail, grep, awk или на любой другой скриптовый язык. В принципе мне кажется это вполне реализуемо и на powershell и на vbs. По сути в этом случае задача состоит из создания механизма периодического чтения файла. В первом прогоне считаем количество строк. Во втором прогоне уже смотрим сообщения. Можно прогнать текст через регулярном. Тут ещё вопрос - локально ли расположен данный файл или на шаре. Когда то мы делали такой механизм на c#. Но там задача немного другая была.


(Михаил Братухин) #10

Лежит на шаре в сети. Не локально.
Файлов несколько. Причем при достижении некоторого объема начинает вестись запись в новый файл с индексом + 1. Теоретически возможно работа с несколькими нодами, у каждой свой локальный лог. Причем одна операция может состоять из пары-тройки связных вызовов сервисов, и один пойти в одну ноду, а второй в другую.

При этом хотелось бы, чтобы если будет такая проверка добавлена, то её влияние на время исполнения теста было бы минимально… :unamused:


(Иван Приходько) #11

А на каком языке у вас авто-тесты крутятся? Samba это конечно почти всегда медленно. В вашем случае я бы рекомендовал заморочиться с внедрением
Logstash - он будет агрегировать логи с разных серверов и складывать их в noSql базу данных. Ваши же тесты будут проверять появление событий через поисковые rest запросы к elasticSearch. В этом случае ваши автотесты будут опрашивать единый endpoint логов всех ваших серверов. Единственное это потребует машину на которой будет развернуты компоненты Логстэша. В любом случае развернуть такую систему для вашего приложения будет полезно, так как это очень удобный способ агрегировать и анализировать логи с кластера. Плюс понадобиться разобраться с его API для того чтобы подружить его с вашими авто-тестами.
Я в свое время отказался от подхода делать ассерты по поисковым запросам в elasticsearch, так как я в принципе всегда знаю какие события, на каком из серверов отлавливать, да и лень было разбираться с его API. И использую его исключительно когда ручками надо что то в логах найти или какие ни будь графики построить(Он у нас еще и метрики собирает).
Удачной автоматизации!


(Михаил Братухин) #12

О! Спасибо огромное! Есть теперь над чем подумать.

P.S. язык Java, поэтому сюда и написал. Плюс хотел посоветоваться о том какие есть подходы и может кто уже решал подобные задачи. Для нас эта задача пока не критичная/важная и на уровне “было бы неплохо, если…”, но идея работы в лоб с файлами и подсчетом строк мне не очень нравилась, вот и подумал, что могут быть обходные пути и как оказалось был прав. Еще раз спасибо!