Здравствуйте, Sharov, Вы писали:
S>Чем подробнее логгирование, тем лучше. Как минимум логгировать вход и выход ф-ии, желательно с параметрами. Особенно если речь идет об обработке данных с 3-ей стороны.
Лишь бы логгирование не было уязвимой точкой для дос-атаки.
А то найдётся какой-нибудь урод, который начнёт бомбить сервис мега-запросами (заведомо неправильными) и загадит лог.
Если лог резиновый, то выжрет дисковую квоту на сервере.
Если лог с ротацией, то это можно использовать для сокрытия следов: выполнить злодейское действие и затем мусорить до удаления старых записей.
И в любом случае, это нагрузка на процессор. Если сервер выделенный, то забьёт канал. Если общий, то можно выжрать процессорную квоту.
Как минимум, напрашивается ведение многоуровневого журнала: краткие записи, которых много, и дампы, количество которых ограничено (и которые нужны только для отладки).
Здравствуйте,
Типичное веб приложение: веб сервисы, которые получают пользовательские данные, как-то обрабатывают и сохраняют результат в бд.
Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки?
Обычно, случается какая-то проблема, пусть напр. клиент посылает какие-то данные, а они не ответствуют формату данных, который принимает веб сервис. И если такое случается часто(пусть клиент пишут 3е лица), что бы решить проблему, мы логирует все HTTP requese|responce данные(User Agent, request json data, responce json data).
Или пусть, напр. серверное приложение вообще может где-то кинуть exception, если пользователь пошлет неправильные данные/или баги в самом сервисе — тоже логируем(сохраняем весь call stack).
В принципе, остальных проблем нет и больше ничего не надо логировать? Добавлять логирование только по мере поступления проблем? Какая информация еще часто нужна при разборе полетов?
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, J>Типичное веб приложение: веб сервисы, которые получают пользовательские данные, как-то обрабатывают и сохраняют результат в бд. J>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки? J>Обычно, случается какая-то проблема, пусть напр. клиент посылает какие-то данные, а они не ответствуют формату данных, который принимает веб сервис. И если такое случается часто(пусть клиент пишут 3е лица), что бы решить проблему, мы логирует все HTTP requese|responce данные(User Agent, request json data, responce json data). J>Или пусть, напр. серверное приложение вообще может где-то кинуть exception, если пользователь пошлет неправильные данные/или баги в самом сервисе — тоже логируем(сохраняем весь call stack). J>В принципе, остальных проблем нет и больше ничего не надо логировать? Добавлять логирование только по мере поступления проблем? Какая информация еще часто нужна при разборе полетов?
Чем подробнее логгирование, тем лучше. Как минимум логгировать вход и выход ф-ии, желательно с параметрами. Особенно если речь идет об обработке данных с 3-ей стороны.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, J>Типичное веб приложение: веб сервисы, которые получают пользовательские данные, как-то обрабатывают и сохраняют результат в бд. J>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки? J>Обычно, случается какая-то проблема, пусть напр. клиент посылает какие-то данные, а они не ответствуют формату данных, который принимает веб сервис. И если такое случается часто(пусть клиент пишут 3е лица), что бы решить проблему, мы логирует все HTTP requese|responce данные(User Agent, request json data, responce json data). J>Или пусть, напр. серверное приложение вообще может где-то кинуть exception, если пользователь пошлет неправильные данные/или баги в самом сервисе — тоже логируем(сохраняем весь call stack). J>В принципе, остальных проблем нет и больше ничего не надо логировать? Добавлять логирование только по мере поступления проблем? Какая информация еще часто нужна при разборе полетов?
Обычно хватает логирования exception.
>>> Добавлять логирование только по мере поступления проблем?
Да, по мере накопления экспертизы, добавлять данные под конкретные кейсы.
>>>Какая информация еще часто нужна при разборе полетов?
Время и автор сигнала, при обработке которого возникла ошибка.
J>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки?
Если сервисов много и/или несколько машин, то удобно использовать какой-то внешний агрегатор сообщений. Чтобы потом делать в нём уже запросы для получения конкретных кусков логов или вообще по поиску чего-то. Через него можно в том числе сделать и уведомлялку о проблемах, например если посыпалось много эксепшнов или ещё какие-то особые случаи.
Здравствуйте, Banch, Вы писали:
J>>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки?
B>Если сервисов много и/или несколько машин, то удобно использовать какой-то внешний агрегатор сообщений.
Логи пишутся в с:\logs\project_name\market\ ... ; можно их писать просто на отдельный сетевой диск.
>> Чтобы потом делать в нём уже запросы для получения конкретных кусков логов или вообще по поиску чего-то.
Для этого юзаю стандартные утилиты из cygwin: grep,vim,sed
>>Через него можно в том числе сделать и уведомлялку о проблемах, например если посыпалось много эксепшнов или ещё какие-то особые случаи.
Для этого юзаю виндовые таски, sh скрипты и утилиту `email` из cygwin, как-то так:
$ email -f "report$(smtp_tail)" -n "" -s"----" -r "$(smtp_host)" -p $(smtp_port) -a "$(filename)" -m login -u "$(smtp_login)" -i "$(smtp_password)" $(smtp_report_to) <<< "see exceptions in file" ;
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, #John, Вы писали:
J>В принципе, остальных проблем нет и больше ничего не надо логировать? Добавлять логирование только по мере поступления проблем? Какая информация еще часто нужна при разборе полетов?
В логи надо писать всё. В том числе и текст запросов и ответов. Ошибочные ответы дублировать в отдельный лог. Каждую запись в логе помечать уникальным ID запроса, который хранить в thread-local переменной.
От исчерпания диска спасаться настройками логгера, чтобы он при низком уровне свободного места прекращал писать низкоприоритетные логи. Параллельно, настроить оповещение на почту/Slack/SMS/пейджер о критически низком дисковом пространстве.
Здравствуйте, #John, Вы писали:
J>Здравствуйте, J>Типичное веб приложение: веб сервисы, которые получают пользовательские данные, как-то обрабатывают и сохраняют результат в бд. J>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки? J>Обычно, случается какая-то проблема, пусть напр. клиент посылает какие-то данные, а они не ответствуют формату данных, который принимает веб сервис. И если такое случается часто(пусть клиент пишут 3е лица), что бы решить проблему, мы логирует все HTTP requese|responce данные(User Agent, request json data, responce json data). J>Или пусть, напр. серверное приложение вообще может где-то кинуть exception, если пользователь пошлет неправильные данные/или баги в самом сервисе — тоже логируем(сохраняем весь call stack). J>В принципе, остальных проблем нет и больше ничего не надо логировать? Добавлять логирование только по мере поступления проблем? Какая информация еще часто нужна при разборе полетов?
Продумывать логгирование следует исходя из потребностей. Типичные применения логгирования — это:
— аудит. однострочные логи на каждое действие клиента — время/юзер/действие/параметры действия
— трафик. логгирование запросов и ответов крайне полезно для последующего разбора проблем
— тайминги. время выполнения запроса целиком и отдельных кусков кода, к примеру, обращений к базе. По таймингам можно строить разнообразные графики
— статистика. как правило, это большой json, который пишется на диск раз в минуту и содержит агрегированные тайминги (среднее, максимальное, персентили) и параметры приложения — характеристики GC например. Еще по статистике можно выдавать предупреждения и ошибки.
— предупреждения. это ошибки, не требующие немедленной реакции, но которые желательно время от времени просматривать
— ошибки, требующие немедленного вмешательства админа
— инфо — логи, не связанные с конкретным запросом. Как правило, логи инициализации приложения
— отладочные логи — это всё остальное. Как правило, должны быть выключены на проде, т.к. занимают много места и для нагруженных приложений могут просадить производительность
Вообще тема очень обширная и малоосвещенная, буду благодарен за ссылки на хорошие статьи (или даже книги) по теме.
J>Как лучше всего реализовать логгирование? Что стоит логировать, что потом поможет вычислить/исправить какие-то ошибки?
Лучше всего иметь очередь в которой хранится последние N записей. Пишешь в нее вообще всё. Если возникает проблема вытаскиваешь из нее все последние события и пишешь в постоянный лог.
Перекуём баги на фичи!
