как правильно организовать логи?
то этот лог из памяти пишется на винт. Дальше этот лог проигрывается типа видеозаписи.Прога этих сообщений много генерирует? Может просто всё писать, а чистить после определённого промежутка времени?
ну или так, хранить последние 10 минут. Генерировать может в пик, скажем, пару десятков тысяч в секунду
Тогда это оптимизировать как-то надо, действительно, если только в память писать.
Ещё мысль: если есть предположение, что проблема в синхронизации потоков, можно построить модель программы и верифицировать её 
Не знаю как в сишарп (может это у вас есть по дефолту, как это есть в джаве для монитора живой мультитредной проги очень удобен тред дамп - список тредов со стектрейсом и указанием состояния (ждем, чего ждем, етц).
Полезно мониторить банальные вещи - heap usage, mem usage, cpu.
По поводу писания логов - хз по поводу литературы, могу дать несколько домашних советов.
- не глотать ексепшены не логируя их
- не терять стектрейсы к ексепшенам, в том числе стектрейсы root cause
- не срать понапрасну в warn/error
- если приложенька живет на многих компах - подумать о централизованном хранилище логов. подобие сислога там, или писать логи в смбшару
Идея по поводу хранения подробных логов за последние 10 минут интересная, но применимость конечно ограничена. Во-первых, за эти 10 минут надо успеть среагировать. Во-вторых, собственно причина может не попасть в этот интервал (приложенька долго умирает).
Если вы уверены, что это не станет проблемой, то можно и так оставить. Иначе я бы лучше заморочился буферизацией логов, или еще чем-то. Пару десятков тысяч событий в секунду пусть даже и в пике выглядит как-то многовато, скорей всего конкретно это место можно оптимизировать, и писать меньше логов без потери информативности. ну и интереснее сколько поток в мегах в секунду в пике / в среднем. пара десятков тысяч событий - очевидно плохой показатель.
Полезно мониторить банальные вещи - heap usage, mem usage, cpu.
По поводу писания логов - хз по поводу литературы, могу дать несколько домашних советов.
- не глотать ексепшены не логируя их
- не терять стектрейсы к ексепшенам, в том числе стектрейсы root cause
- не срать понапрасну в warn/error
- если приложенька живет на многих компах - подумать о централизованном хранилище логов. подобие сислога там, или писать логи в смбшару
Идея по поводу хранения подробных логов за последние 10 минут интересная, но применимость конечно ограничена. Во-первых, за эти 10 минут надо успеть среагировать. Во-вторых, собственно причина может не попасть в этот интервал (приложенька долго умирает).
Если вы уверены, что это не станет проблемой, то можно и так оставить. Иначе я бы лучше заморочился буферизацией логов, или еще чем-то. Пару десятков тысяч событий в секунду пусть даже и в пике выглядит как-то многовато, скорей всего конкретно это место можно оптимизировать, и писать меньше логов без потери информативности. ну и интереснее сколько поток в мегах в секунду в пике / в среднем. пара десятков тысяч событий - очевидно плохой показатель.
Для отладки есть parallel stacks в vs2010, для верификации, например, MoonWalker, но я им не пользовался.
Вообще, я не могу представить, как можно по логу (который пишется абы как, там может не соблюдаться порядок возникновения сообщений во времени) можно восстановить, из-за чего происходит ошибка. Хотя где она возникла, конечно, определить можно. Лог — это не трасса, всё же.
2 : а какого рода вообще могут быть ошибки? Почему можно получить либо ошибку в конце, либо тысячи сообщений в секунду? Предполагается, что ошибка может быть где угодно?
Вообще, я не могу представить, как можно по логу (который пишется абы как, там может не соблюдаться порядок возникновения сообщений во времени) можно восстановить, из-за чего происходит ошибка. Хотя где она возникла, конечно, определить можно. Лог — это не трасса, всё же.
2 : а какого рода вообще могут быть ошибки? Почему можно получить либо ошибку в конце, либо тысячи сообщений в секунду? Предполагается, что ошибка может быть где угодно?
Для отладки есть parallel stacks в vs2010вот что то типа такого, только поиметь на продакшеновой системе
верификация круто конечно, я правда тоже не пользовался, но есть у меня подозрение что на сложной системе, если она разрабатывалась без поддержания чистоты по этому самому мунволкеру, ты задолбаешься/принципиально не сможешь пофиксить то, что она там понаходит
(отвечу за себя) из логов обычно удается получить информацию о том, что вообще в приложеньке в этот момент происходило, а это дает возможность потом в дебаге запуститься, и конкретно уже репродьюсить/профайлить проблему
>2 : а какого рода вообще могут быть ошибки? Почему можно получить либо ошибку в конце, либо тысячи сообщений в секунду? Предполагается, что ошибка может быть где угодно?
насколько я понял, у топикстартера нет конкретной ошибки, а есть что сервис через некоторое время перестает вести себя нормально.
и в такой ситуации обычно и приходиться логировать все подряд, чтобы хотя бы просто понять, что именно пошло не так.
насколько я понял, у топикстартера нет конкретной ошибки, а есть что сервис через некоторое время перестает вести себя нормально.
и в такой ситуации обычно и приходиться логировать все подряд, чтобы хотя бы просто понять, что именно пошло не так.
да, цель такая - понять, что именно и когда пошло не так, на какой операции, так сказать.
10 минут - это вот зачем. Прога работает на другом компе, вообще в США, и когда что-то идет не так, то мне говорят "товарищ, что-то тут не то". Тогда я должен расспрашивать, что и как делали (а прога, по сути, сервер, на котором висит масса клиентов и диких юзверей вручную собирать различную инфу, потом пытаться воспроизвести ситуацию и т.д. Хочется же иметь некое подобие "видеозаписи", по возможности, чтобы при возникновении глюка мне присылали эту "видеозапись" и при наличии соотв. "проигрывателя", я бы мог воспроизвести ситуацию и все понять. Типа, как логи у сниффера. Во всяком случае (я понимаю, что решение описано идеальное хочется заметно упростить сбор необходимой инфы.
ладно, мой код - я с ним сам разберусь... Но ведь есть же еще сторонние компоненты! Которые глючат. И мне нужно обосновывать, почему и когда они сглючат. Потом нужно писать письма тем разработчикам, они тоже будут чесать в затылке и т.д.
10 минут - это вот зачем. Прога работает на другом компе, вообще в США, и когда что-то идет не так, то мне говорят "товарищ, что-то тут не то". Тогда я должен расспрашивать, что и как делали (а прога, по сути, сервер, на котором висит масса клиентов и диких юзверей вручную собирать различную инфу, потом пытаться воспроизвести ситуацию и т.д. Хочется же иметь некое подобие "видеозаписи", по возможности, чтобы при возникновении глюка мне присылали эту "видеозапись" и при наличии соотв. "проигрывателя", я бы мог воспроизвести ситуацию и все понять. Типа, как логи у сниффера. Во всяком случае (я понимаю, что решение описано идеальное хочется заметно упростить сбор необходимой инфы.
ладно, мой код - я с ним сам разберусь... Но ведь есть же еще сторонние компоненты! Которые глючат. И мне нужно обосновывать, почему и когда они сглючат. Потом нужно писать письма тем разработчикам, они тоже будут чесать в затылке и т.д.
Тогда это оптимизировать как-то надо, действительно, если только в память писать.Вроде запись в файл и так сначала в память происходит, а уже потом в свободное время на диск.
Оставить комментарий
NataNata
ситуацияЕсть прога, здоровенная, работающая со сторонними компонентами. Сама прога написана на .net, а вот компоненты - на си\си++ и исходного кода компонентов нет. С некоторой вероятностью, периодически, в проге могут происходить какие-то глюки, непонятно, то ли в проге что-то не то, то ли компоненты мудрят. Причем, воспроизвести ситуацию, при которой сглючило, может быть весьма проблематичным.
Насколько правильно органировать систему логов следующим образом:
1) есть лог, который пишется в файл. В него отмечаются комментарии в стиле "операция начата" или "операция успешно завершена".
2) есть внутренний лог в памяти, который хранит последние несколько тысяч или десятков тысяч каких-нибудь внутренних отладочных сообщений, в которых написано вообще ВСЕ касательно процедуры, которая инициировала добавление отладочного сообщения. Если вдруг некто, занимающийся администрированием проги, увидел какую-то нездоровую ситуацию (или прога сама "учуяла", что что-то не так то этот лог из памяти пишется на винт. Дальше этот лог проигрывается типа видеозаписи.
Что значит правильно? В первую очередь, правильно - это иметь возможность отследить, как при каких условиях система сглючила.
Дополнительные сведения - прога многопоточная, много семафоро-подобных объектов, работает на 8-ядерной машине, винты быстрые.
Заодно, если не сложно, подскажите правильные тексты о том, как дОлжно организовать систему логов с точки зрения именно того, как она должна быть встроена в фундамент системы. Рассуждения про try\catch\finally и прочее, которые я встречал, на данном этапе развития проги как-то маловато...