Відлагоджувальний лог
Добридень. За бажанням замовника для скрипту я повинен зробити налагоджувальний лог. Але якось так вийшло, що я ніколи не дав подібне через непотрібність. Підкажіть, можливо є якісь базові принципи побудови даного лога? Що туди потрібно записувати? Дякую.
Відповіли: 18
try catch => exception записати у файл.txt
тобто. в принципі, якщо немає жодного винятку, то й записувати нічого не треба?
А що можна записувати в балку те, чого немає?
ось, наприклад - Посилання на запис: налагоджувальний лог
Ну, в логі ще можна записувати не тільки винятки, але хід роботи, може warning-і
Хід роботи, тільки лог такий зазвичай для ним виходить.
Тут правильно людина сказала, що залежить від того, що потрібно в цьому лозі бачити замовнику. Але бувають такі варіанти.
Якщо балка робиться за бажанням замовника - краще уточнити його побажання. Взагалі, ідеальний лог логує кожну точку розгалуження програми, роздруковуючи дані, що вплинули на вибір гілки + повідомляє про всі зовнішні події. У житті ідеал доводиться скорочувати, бо виходить дуже багато.
В ідеалі щось на кшталт: $pid:$tid $time $filename:$line $filtername $myaction var1=$var1 var2=$var2 var3=$var3
У житті часто: "tut2 $var1>$var2 . \n"
дивлячись що буде потрібно від лога надалі. може, потрібно записувати дані на виклик, типу хто, коли, з якими параметрами викликав скрипт. можна писати якісь ключові параметри та процес їх зміни. писати помилки, виключення, спрацювання захистів
"Коли, з якими параметрами викликав скрипт" - це робочий лог, а про налагоджувальний я теж зрозумів, дякую
Якось тут не згадано, скажу про всяк випадок.
1) Будь-який розумний лог може приймати повідомленнякількох рівнів важливості. Скажімо, найнижчий рівень - налагоджувальні, потім інформаційні, і т. д. до критичних помилок. Відповідно, будь-яка функція запису в балку викликається із зазначенням рівня повідомлення.
2) При старті програми (а в ідеалі - і в її роботі) можна задати мінімальний рівень, який ще потрапляє в балку. Відповідно, при налагоджувальних пусках це найнижчий рівень, а при стабільній експлуатації - найвищий.
3) Розумно не прибирати з програми (скажімо, умовною компіляцією) код запису в лог навіть у production версії. Завжди може знадобитися відловити важливу помилку, яка сталася вже після встановлення замовника. (Для цього зручна і можливість змінювати рівень реакції лога на льоту, якщо програма працює сервером.)
Взагалі, якщо питання цікаве, можна почитати, як концептуально влаштований log4j та численні його варіації для інших мов. Там багато здорових думок. (Але й щодо складний пристрій).
1) Будь-який розумний лог може приймати повідомлення кількох рівнів важливості. Скажімо, найнижчий рівень - налагоджувальні, потім інформаційні, і т. д. до критичних помилок. Відповідно, будь-яка функція запису в балку викликається із зазначенням рівня повідомлення.
Правильніше та зручніше робити фільтри, а не рівні. Наприклад, "мережевий налагоджувальний", "бізнес-логіка критичний".
Згоден; фільтрувати можна не тільки за рівнем, а й підсистемою. Врешті-решт можна дійти повноцінної конструкції підписки на події типу JMS :) Все залежить від складності розв'язуваного завдання. У програмі на 1000 рядків зазвичай вистачає найпростіших трьох рівнів, у системі з мільйона-другого рядків без описаних вами фільтрів лихо.
levels, subsystems, . nefiga velosiped izobretat' - syslog forever :)