Добрый день коллеги! Нужен совет как лучше сделать мониторинг логов. Кто как делал и делал ли кто ни будь что-то такое?
Цель:
Легко получать доступ к информации о старте или завершении операций на сервере, во время выполнения тестов.
По завершению теста, получать срез логов, записанных во время выполнения этого теста для отчета.
Текущая реализация: Написан некий MessageWaiter который с заданным интервалом грепает заданный лог-файл и отбрасывает результаты по таймстемпу, отличающемуся от времени старта теста.
Недостатки:
Необходимость использовать Thread.sleep для синхронизации, так как иногда случается появление сообщений с разницей в несколько секунд до даты старта теста. Как итог - сообщения о завершении операции попадают в фильтр как случившиеся до времени запуска теста.
Какие есть идеи:
Идея 1
При старте теста делать нечто вроде > tail -f logfile,log>> /qa_home/testExecTimeStamp/testname/logfile.log &
При завершении теста - грохать
kill $(ps aux|grep “/qa_home/testExecTimeStamp/testname/logfile.log” |grep -v| awk ‘{print $2}’) и удалять файлы после завершения теста.
Ожидаемые сообщения по тесту - грепать исключительно из нагенеренных файликов.
Идея 2
При старте теста указывать список файлов для монитринга и запускать его в отдельных потоках. Все новые строчки класть например в мапу.
Искать ожидаемые сообщения по этой мапе.
Идея 3
Расставить после записи времени старта теста большие Thread.sleep что приведет к увеличении времени прогона авто-тестов, но с определенной гарантией отсечет проблемы появления сообщений с таймстемпом ДО старта самого теста.
За информацию о данном фреймворке - спасибо! Интересный вариант работы с консолью из коробки.
Но немножко не по теме. У нас еще на заре была написана обертка над jsc, которая прекрасно работает и выполняет все задачи которые от нее требовались. Вопрос о том как подключится - не стоит.
Тут вопрос идеологический - как лучше мониторить лог?
Если производительность важна или логи большие - вместо строк используйте ОС апи чтобы определить размер файла логов (он ведь просто текстовый), в деструкторе читайте файл потоком в позициях начиная с размера в конструкторе, заканчивая размером файла в деструкторе. Тогда программе не придется постоянно по всему файлу символы конца строки подсчитывать.
Производительность не важна - wc -l и sed -n from,top вполне хватает. Большие логи у нас в архивы уезжают. А тесты гоняем на обрезанных энвах на которых только автотесты и крутятся. Могут возникнуть проблемы с параллельным выполнением, так что вариант с отловом сообщений по номеру строки в этом случае может накосячить, но такие тесты я не планирую запускать параллельно. Спасибо за идею! Попробую организовать грепалку по этому принципу.
А есть идеи как подобное можно было бы реализовать на виндовой машине? Думаю, может для себя в тестах добавить дополнительные проверки по логам приложения. Оно правда на виндовой машине работает.
Мне кажется Следует смотреть в сторону оболочки Cygwin с никсовыми пакетами tail, grep, awk или на любой другой скриптовый язык. В принципе мне кажется это вполне реализуемо и на powershell и на vbs. По сути в этом случае задача состоит из создания механизма периодического чтения файла. В первом прогоне считаем количество строк. Во втором прогоне уже смотрим сообщения. Можно прогнать текст через регулярном. Тут ещё вопрос - локально ли расположен данный файл или на шаре. Когда то мы делали такой механизм на c#. Но там задача немного другая была.
Лежит на шаре в сети. Не локально.
Файлов несколько. Причем при достижении некоторого объема начинает вестись запись в новый файл с индексом + 1. Теоретически возможно работа с несколькими нодами, у каждой свой локальный лог. Причем одна операция может состоять из пары-тройки связных вызовов сервисов, и один пойти в одну ноду, а второй в другую.
При этом хотелось бы, чтобы если будет такая проверка добавлена, то её влияние на время исполнения теста было бы минимально…
А на каком языке у вас авто-тесты крутятся? Samba это конечно почти всегда медленно. В вашем случае я бы рекомендовал заморочиться с внедрением Logstash - он будет агрегировать логи с разных серверов и складывать их в noSql базу данных. Ваши же тесты будут проверять появление событий через поисковые rest запросы к elasticSearch. В этом случае ваши автотесты будут опрашивать единый endpoint логов всех ваших серверов. Единственное это потребует машину на которой будет развернуты компоненты Логстэша. В любом случае развернуть такую систему для вашего приложения будет полезно, так как это очень удобный способ агрегировать и анализировать логи с кластера. Плюс понадобиться разобраться с его API для того чтобы подружить его с вашими авто-тестами.
Я в свое время отказался от подхода делать ассерты по поисковым запросам в elasticsearch, так как я в принципе всегда знаю какие события, на каком из серверов отлавливать, да и лень было разбираться с его API. И использую его исключительно когда ручками надо что то в логах найти или какие ни будь графики построить(Он у нас еще и метрики собирает).
Удачной автоматизации!
О! Спасибо огромное! Есть теперь над чем подумать.
P.S. язык Java, поэтому сюда и написал. Плюс хотел посоветоваться о том какие есть подходы и может кто уже решал подобные задачи. Для нас эта задача пока не критичная/важная и на уровне “было бы неплохо, если…”, но идея работы в лоб с файлами и подсчетом строк мне не очень нравилась, вот и подумал, что могут быть обходные пути и как оказалось был прав. Еще раз спасибо!
testomat.io управление авто тестами
