ΙΤ
Просто настроили логирование через gelf
Size: a a a
2020 June 07
ΙΤ
И шлем в Грейлог
ΙΤ
Наше решение выложено в шаблоне
ΙΤ
Сейчас graylog у нас сворачивают в пользу общего решения, и там по ELK все будет, сделаем заливку логов в elk
ВС
Кстати, есть удобные способы анализировать ошибки, проявившиеся в ходе теста Jmeter?
Что есть: в Grafana вижу, что завалились 15% операций.
А причины - не вижу. То, что Jmeter передаёт через backendListner - бесполезная фигня.
Можно анализировать лог жметра, но если нам нужны ответы с сообщениями об ошибках - лог должен быть в xml, а вы знаете, как это классно - читать xml на пару мегабайт.
у Серпутко есть jsr223-листнер, который, вроде, умеет передавать в influx сами ошибки, но он требует установленной галочки "Create parent sempler", а с ней увеличивается расход памяти. Но я уже думаю перейти на этот вариант.
Чего хочется:
Что бы к логи тоже складывались в хранилище, откуда можно было читать информацию в Grafana, фильтруя по $TimeFilter или тредгруппам / транзакциям.
Вроде напрашивается передача логов в Elastic или парсинг их и передача в графану.
Но может уже есть готовые решения, что бы не пилить свои велосипеды?
Что есть: в Grafana вижу, что завалились 15% операций.
А причины - не вижу. То, что Jmeter передаёт через backendListner - бесполезная фигня.
Можно анализировать лог жметра, но если нам нужны ответы с сообщениями об ошибках - лог должен быть в xml, а вы знаете, как это классно - читать xml на пару мегабайт.
у Серпутко есть jsr223-листнер, который, вроде, умеет передавать в influx сами ошибки, но он требует установленной галочки "Create parent sempler", а с ней увеличивается расход памяти. Но я уже думаю перейти на этот вариант.
Чего хочется:
Что бы к логи тоже складывались в хранилище, откуда можно было читать информацию в Grafana, фильтруя по $TimeFilter или тредгруппам / транзакциям.
Вроде напрашивается передача логов в Elastic или парсинг их и передача в графану.
Но может уже есть готовые решения, что бы не пилить свои велосипеды?
Мы когда-то так делали:
https://habr.com/ru/post/308098/
Плагин записывает только для ошибок тела ответов в CSV-лог.
Далее анализировали с помощью Pandas, группируя по
Имени семплера / Коду ответа / Телу ответа
https://habr.com/ru/post/308098/
Плагин записывает только для ошибок тела ответов в CSV-лог.
Далее анализировали с помощью Pandas, группируя по
Имени семплера / Коду ответа / Телу ответа
ВС
Формат CSV выбран ради Pandas
ΙΤ
Мы когда-то так делали:
https://habr.com/ru/post/308098/
Плагин записывает только для ошибок тела ответов в CSV-лог.
Далее анализировали с помощью Pandas, группируя по
Имени семплера / Коду ответа / Телу ответа
https://habr.com/ru/post/308098/
Плагин записывает только для ошибок тела ответов в CSV-лог.
Далее анализировали с помощью Pandas, группируя по
Имени семплера / Коду ответа / Телу ответа
Основная проблема что как раз нет возможности большое сообщение написать
ΙΤ
Подробное
ВС
Основная проблема что как раз нет возможности большое сообщение написать
Я может не в контексте. В статье описан плагин, который как раз записывает тело ответа целиком, в csv. И это примерно в 100 раз быстрее (в 107), чем запись в XML-лог. В статье опечатка, написали, что в 10 раз быстрее. И лог получается меньше.
ΙΤ
Я может не в контексте. В статье описан плагин, который как раз записывает тело ответа целиком, в csv. И это примерно в 100 раз быстрее (в 107), чем запись в XML-лог. В статье опечатка, написали, что в 10 раз быстрее. И лог получается меньше.
Да это все весело только потом это все надо ещё анализировать как-то агрегировать
ВС
Поэтому CSV
ΙΤ
Всякие системы для логов позволяют это делать удобнее
VG
Я может не в контексте. В статье описан плагин, который как раз записывает тело ответа целиком, в csv. И это примерно в 100 раз быстрее (в 107), чем запись в XML-лог. В статье опечатка, написали, что в 10 раз быстрее. И лог получается меньше.
а дальше, как я понимаю, можно результаты телеграфом сунуть в influx и смотреть в графане?
ВС
Мне нравится подход разбирать логи приложения, вместо логов теста производительности. Ведь многие системы не отдают текст ошибки в ответе. Для IIS и стека Microsoft это, например, считается антипаттерном снижающим производительность и защищенность.
VG
Мне нравится подход разбирать логи приложения, вместо логов теста производительности. Ведь многие системы не отдают текст ошибки в ответе. Для IIS и стека Microsoft это, например, считается антипаттерном снижающим производительность и защищенность.
я согласен. Но это же не значит, что логи тестов разбирать не нужно :)
ВС
а дальше, как я понимаю, можно результаты телеграфом сунуть в influx и смотреть в графане?
Тогда мы ещё не использовали Grafana, использовали Pandas и Python.
ВС
Если результат аггрегации с помощью Pandas класть в InfluxDB, то будет здорово. А сырые тела ответов класть - плохая идея.
ВС
В GrayLog, как Иоанн советует, можно класть тела ответов, он разбухнет, но переварит. А InfluxDB разбухнет и зависнет.
ΙΤ
а дальше, как я понимаю, можно результаты телеграфом сунуть в influx и смотреть в графане?
Нет, для логов в инфлаксе нужно смотреть в сторону Loki + Promtail