Я ніколи не писав програм, які суттєво використовують журнал. Найбільше, що я робив, - це фіксувати сліди стека, коли трапляються винятки.
Мені було цікаво, скільки реєструють інші люди? Чи залежить це, про яку заяву ви пишете? Чи вважаєте Ви журнали справді корисними?
Відповіді:
Для роботи я зробив багато вбудованих додатків, увійшовши в безцінний інструмент. Як мінімум помилок потрібно ввійти з достатньою кількістю інформації, щоб вказати на рядок коду. Далі, будуть основними функціональними пунктами у додатку. Такі речі, як адміністратор, отримували доступ до машини. Ми використовуємо систему, яка дозволяє нам більш детально вести журнал. Зазвичай це специфічно для розробника. Він може бути використаний для допомоги розробнику під час тестування функції, або може допомогти у діагностуванні проблеми із клієнтом.
Я особисто використовував журнал у всіх розроблених програмах. Це завжди призводило до кращого розуміння потоку програми. Особливо, коли в руках замовника. Вони ніколи (рідко) обмежують випадки використання лише тими, на кого ви тестуєте.
Я не думаю, що це залежить від типу програми: журнал корисний у всіх (нетривіальних) програмах. Звичайно, я думаю, це може бути більш корисним в деяких додатках , ніж інші, але я не думаю , що це коли - небудь марно .
Зокрема, у випадку помилки, слід стека повідомляє вам про стан програми в точній точці відмови, але у вас є дуже мало поняття про стан безпосередньо перед помилкою. Ця інформація може бути дуже корисною для відстеження проблеми, і ведення журналу може дати корисну інформацію про це. Я думаю, що від цього можуть отримати користь усі, крім самих тривіальних програм.
Ще одне використання журналів, яке може бути корисним не для всіх програм, полягає в аналізі статистики. Наприклад, ваш веб-сервер зазвичай реєструє кожен запит, що надходить, і тоді існує багато інструментів, які можуть аналізувати ці журнали та створювати графіки ваших найзайнятіших часів, найпопулярніших сторінок тощо. Ви можете використовувати ці дані для планування потужностей ("чи потрібен мені більший сервер?") Тощо.
Існує дві причини проведення журналу:
Діагностичний журнал обговорювались уже іншими, і я більше не буду вважати це питання. Я просто скажу, що вам слід сильно подумати про те, що станеться, якщо стався збій журналу? Вам достатньо подбати, щоб викинути виняток через додаток чи керувати ним іншим способом? Це "це залежить", але реєстрацію повідомлень рівня інформації, ймовірно, слід пропустити.
Журнал аудиту - бізнес-вимога. Журнал аудиту фіксує значні події в системі, і те, чим цікавлять менеджмент та законні орли. Це такі речі, як хтось на щось підписався, хто робив редагування і т. Д. Як системний адміністратор чи розробник усуває проблеми з системою, ви, ймовірно, лише м'яко їх зацікавив. Однак у багатьох випадках подібний журнал є абсолютно частиною транзакції і повинен завершити роботу всієї транзакції, якщо її неможливо виконати.
Думати про ці два окремо для мене корисно не лише тому, що одне є "необов’язковим", а інше обов'язковим, а тому, що залежно від вимог, я можу насправді потребувати їх виконання окремо. Іноді може траплятися так, що вони обидва фрукти, але один - яблука, а інший - апельсини. Зазвичай одна рамка ведення журналу може обробляти і те, і інше.
У більшості серверних завдань реєстрація має вирішальне значення, оскільки адміністратора зазвичай немає, коли це відбувається, тому він повинен перевіряти фактичні факти.
Але один раз хлопець з Google сказав мені, що їхні серверні процеси не проводять ведення журналів; натомість вони "інструментальні"; це означає, що кожен процес має гачки або порти (він не вказував механіку), де інші процеси можуть фіксуватися, щоб запитати параметри та статистику. Це ті процеси моніторингу, які зберігають у журналах багато речей, перевага полягає в тому, що інформація, яку вони отримують, не є "відкрити файл", "написати це", "отримати це"; вони отримують такі речі, як "45453 файли відкриті", "653 клієнтів служби X", "середня відповідь на запит Y" 344 мс "
Звичайно, це інший підхід, який я маю на увазі, коли я няню свої системи, навіть якщо вони на порядок менші.
Я прийшов із програми N-Tiered winforms, яка реєструвала все.
Це було не дуже корисно.
Звичайно, винятки з реєстрації даних великі; але навіщо записувати їх на клієнтську машину, коли ви можете просто надіслати електронний лист виключенню команді розробників?
Реєстрація інформації легко перетворюється на залежність, значення якої рідко виправдовується. Для кожної ситуації, коли ви можете безперешкодно входити в систему, краще зібрати цільову інформацію та надіслати її там, де вам потрібно.
Захоплення інформації про виключення є обов'язковою, оскільки вона може бути дуже корисною до певної міри. Але іноді інформації про виключення недостатньо, особливо якщо користувач / клієнт програми не може повідомити про помилку з належною інформацією.
Чи журнал обмежений лише захопленням інформації про помилки?
У моєму випадку (веб-додаток) я завжди реєструю, яку сторінку відвідують, коли, що вони клацають, де ip & браузер тощо. Я навіть реєструю загальний час завантаження для кожного відвідування сторінки, щоб я міг знати, які сторінки повільні і потрібна оптимізація. тому я можу сказати, що я входжу якомога більше.
спочатку я не мав уявлення, наскільки це буде значущим. але, мабуть, це дуже корисно у багатьох речах (крім налагодження):
Я думаю, що реєстрація може стати більш значущою, якщо ми любимо викопувати в ній статистичну інформацію.
Я розробник у компанії, продукція якої розгорнута за кордоном. Коли служба підтримки запитує про визначення проблеми, єдиним моїм інструментом для діагностики є мої файли журналів та копія бази даних клієнта. Використовуючи базу даних та моє середовище розробки, я маю можливість відтворити помилковий випадок, оскільки я реєструю вхідні дані у свій модуль та пов'язані з цим дії. Якщо я можу відтворити помилку за допомогою зібраних даних, я можу виправити її налагодженням. Якби у мене не було файлів журналів, я повинен був би залежати від опису замовника або групи підтримки, що відбувається в такому випадку (що має великі шанси ввести в оману).
По-друге, ведення журналу дає мені можливість виявити вузькі місця мого модуля на розгорнутому сайті, оскільки я реєструю дату та час певних дій, і тоді я можу ознайомитись із тим, яка дія вимагає скільки часу.
На додаток до цього, припустимо, наше рішення складається з 6 модулів, і я бачу журнали помилок у своїх файлах журналів про час очікування бази даних. Якщо ці помилки також входять у 5 інших модулів, збільшується ймовірність того, що це проблема, пов’язана з сервером SQL. Якщо це записується лише в моєму модулі, то ймовірність того, що мої запити баггі, збільшується. Я думаю, що такі речі є корисними показниками.
Від того, які дані я бачу в своїх журнальних файлах, залежить конфігурація рівня журналу. Якщо це новий продукт, ми встановлюємо рівень журналу на "Усі", щоб зібрати якомога більше даних. Але коли ми вдосконалюємо продукт, ми можемо вважати за краще тримати рівень журналу на "Помилка", щоб записувати лише помилку, але не журнали рівня інформації тощо.
Журнал корисний для інформації, яку ви не можете отримати іншими програмами:
Примітка. Ви хочете принаймні ДВІ файли журналу.
INFO один завжди увімкнено. ДЕБУГ увімкнено, коли це потрібно.
Напишіть код реєстрації, передбачивши, що одного разу, можливо, доведеться налагоджувати ситуацію, коли ВСЕ у вас є файл журналу, і все це правильно, можливо, буде різниця між звільненням та отриманням підвищення.
Для додаткової милі всі виклики функцій додають свої параметри до будь-якого сліду стека, в Java з
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
Цей підхід істотно покращує стек викликів за допомогою значень параметрів, і може дозволяти вам аналізувати ситуацію лише за допомогою сліду стека та не потрібно бачити файли журналу.
Я також рекомендую всім нетривіальним додаткам використовувати багаторівневий журнал.
З причин, які інші заявили, це неоціненний інструмент для вирішення проблем із додатком.
У деяких випадках реєстрація є важливою, наприклад, у фінансових програмах та інших областях, які потребують журналів діяльності, для безпеки, показників використання та аудиту.
Це, безумовно, залежить від типу системи, яку ви будуєте.
Якщо ви пишете автономну програму для настільних ПК, наприклад текстовий процесор, вам, ймовірно, не потрібні ніякі журнали.
Якщо ви пишете вбудовану систему, ви не можете жити без реєстрації. Інакше, коли ваш вбудований пристрій замерзне, ви не знаєте, чому. Також вам потрібно вести журнал, коли ваша система передбачає безліч процесів або декілька фізичних машин, що спілкуються між собою. Знову ж таки, коли система висить, потрібно знати, яка частина її загинула, коли і чому. Потрібно мати можливість порівнювати журнали, щоб визначити, чи дані переносили їх від одного процесу до іншого. Таким же чином, вам потрібно вести журнал щоразу, коли ваша система запускається протягом тривалого періоду часу без особливої прямої взаємодії з користувачем.
Ведення журналів завжди корисне. Але при впровадженні будьте в курсі, не обов’язково ви, хто збирається читати журнали. Можливо, це якийсь адміністратор, кінцевий користувач, клієнт, команда підтримки, ...
Тому не лише записуйте стек траксів, але й додаткову інформацію, яку можна інтерпретувати не розробниками. Коли ваша програма підтримується деякими іншими групами, також корисно написати кілька унікальних кодів помилок у свої журнали. Це може полегшити підтримку, автоматизацію, ...
Ще один момент з точки зору адміністратора: Подумайте про обертання журналу.