Чому більшість файлів журналу використовують звичайний текст, а не двійковий формат?

Ведення журналу - це те, що необхідно, але (відносно) використовується рідко. Як такий, його можна зробити набагато більш компактним в плані зберігання.

Наприклад, дані, які найчастіше реєструються як ip, дата, час та інші дані, які можуть бути представлені у вигляді цілого числа, зберігаються як текст.

Якщо журнал зберігався як двійкові дані, можна було б зберегти багато місця, що вимагало б меншого обертання та збільшення тривалості диска, особливо з SSD, де записи обмежені.

Деякі можуть сказати, що це така незначна проблема, що вона насправді не має значення, але враховуючи зусилля, необхідні для побудови такого механізму, немає сенсу цього не робити. Кожен може зробити це приблизно два дні у вільний час, чому люди не роблять цього?

systemdчудово зберігає свої файли журналів у двійковому форматі. Основні питання, які я чув із цим, це:

1. якщо журнал зіпсується, його важко відновити, оскільки йому потрібні спеціальні інструменти
2. вони не читається людина, так що ви не можете використовувати стандартні інструменти , такі як vi, grep, і tailт.д. , щоб проаналізувати їх

Основна причина використання двійкового формату (наскільки мені відомо) полягала в тому, що це було простіше створити індекси тощо, тобто трактувати його більше як файл бази даних.

Я заперечую, що перевага дискового простору на практиці порівняно невелика (і зменшується). Якщо ви хочете зберігати велику кількість лісозаготівлі, то блискання рулонних колод справді досить ефективно.

З іншого боку, переваги інструментальної роботи та знайомства, ймовірно, помиляються на стороні введення тексту в більшості випадків.

Чому більшість файлів журналу використовують звичайний текст, а не двійковий формат?

Шукайте слово "текст" у статті Wikipedia філософії Unix , наприклад, ви знайдете такі твердження, як:

МакІлрой, тодішній керівник CSRC Bell Labs (Науково-дослідний центр обчислювальних наук) та винахідник труби Unix, [9] узагальнив філософію Unix таким чином: [10]

Це філософія Unix: Пишіть програми, які роблять одне і роблять це добре. Напишіть програми для спільної роботи. Пишіть програми для обробки текстових потоків, тому що це універсальний інтерфейс.

Або, наприклад, з Основ філософії Unix ,

Правило складання: Дизайн програм, які мають бути пов'язані з іншими програмами.

Важко уникнути програмування надскладних монолітів, якщо жодна з ваших програм не може спілкуватися між собою.

Традиція Unix наполегливо заохочує писати програми, які читають і записують прості, текстові, орієнтовані на потоки, незалежні від пристрою формати. У класичному Unix якомога більше програм записуються як прості фільтри, які приймають простий текстовий потік при введенні та переробляють його в інший простий текстовий потік на виході.

Незважаючи на популярну міфологію, цю практику віддають перевагу не тому, що програмісти Unix ненавидять графічні інтерфейси користувачів. Це тому, що якщо ви не пишете програми, які приймають та випромінюють прості текстові потоки, набагато складніше підключити програми разом.

Текстові потоки призначені для інструментів Unix, оскільки повідомлення - об'єктам в об'єктно-орієнтованій обстановці. Простота інтерфейсу текстового потоку примушує інкапсуляцію інструментів. Більш досконалі форми міжпроцесорної комунікації, такі як виклики віддалених процедур, виявляють тенденцію занадто сильно залучати програми з внутрішніми системами.

Кожен може зробити це приблизно два дні у вільний час, чому люди не роблять цього?

Зберігання файлу журналу у двійковому форматі - це лише початок (і тривіальний). Тоді вам потрібно буде написати інструменти для:

• Показати весь файл журналу ( edit)
• Відображати кінець журналу, не читаючи початку його ( tail -f)
• Пошук матеріалів у файлі ( grep)
• Фільтр, щоб відображати лише вибрані / цікаві речі (використовуючи довільно складний вираз фільтра)
• Надішліть журнал електронною поштою іншому, хто не має вашого журналу-файлу-декодера-програмного забезпечення
• Скопіюйте та вставте фрагмент файлу журналу
• Прочитайте файл журналу, поки програма (яка створює файл журналу) ще розробляється та налагоджується
• Читайте файли журналів із старих версій програмного забезпечення (які розгорнуті на сайтах клієнтів та запущені).

Очевидно, що програмне забезпечення також може і використовувати бінарні формати файлів (наприклад, для реляційних баз даних), але це не варто (у сенсі YAGNI ), як правило, не варто робити це для файлів журналів.

Тут дуже багато дискусійних припущень.

Ведення журналу було невід’ємною частиною (майже) кожної роботи, яку я мав. Це важливо, якщо ви хочете отримати будь-яку видимість щодо здоров'я ваших додатків. Сумніваюся, що це "бахрома"; більшість організацій, з якими я брав участь, вважають журнали дуже важливими.

Зберігання журналів як двійкових означає, що ви повинні їх розшифрувати, перш ніж їх зможете прочитати. Текстові журнали мають доброту та простоту користування. Якщо ви розмірковуєте над бінарним маршрутом, ви можете замість цього зберігати журнали в базі даних, де ви можете їх допитувати та статистично аналізувати.

SSD-диски надійніші, ніж HDD, і аргументи проти багатьох записів значною мірою суперечать. Якщо ви дійсно переживаєте з цього приводу, зберігайте свої журнали на звичайному жорсткому диску.

Файли журналів є найважливішою частиною будь-якої серйозної програми: якщо вхід у додаток корисний, вони дозволяють вам бачити, які ключові події відбулися та коли; які помилки сталися; і загальне здоров'я додатків, яке виходить за межі будь-якого моніторингу, розробленого в ньому. Це звичайно почути про проблему, перевірити вбудовану діагностику програми (відкрити веб-консоль або скористатися діагностичним інструментом на зразок JMX), а потім вдатися до перевірки файли журналу.

Якщо ви використовуєте нетекстовий формат, то ви негайно стикаєтесь із перешкодою: як ви читаєте двійкові журнали? За допомогою інструмента для читання журналу, який відсутній на ваших виробничих серверах! Або це так, але о дорогий, ми додали нове поле, і це старий читач. Хіба ми цього не тестували? Так, але ніхто його тут не розгортав. Тим часом ваш екран починає світитися, коли користувачі обзивають вас.

Або, можливо, це не ваш додаток, але ви підтримуєте підтримку і думаєте, що знаєте, що це інша система та WTF? журнали у двійковому форматі? Гаразд, починайте читати сторінки вікі, а з чого ви починаєте? Тепер я скопіював їх на свою локальну машину, але - вони пошкоджені? Я зробив якусь небінарну передачу? Або зашкоджено засіб читання журналу?

Коротше кажучи, інструменти для читання тексту є багатоплановими та всюдисущими, а журнали часто довговічні та їх іноді потрібно читати поспіхом . Якщо ви винайдете двійковий формат, то ви відрізані від цілого світу добре зрозумілих і простих у використанні інструментів. Серйозна втрата функціональності саме тоді, коли це потрібно.

Більшість середовищ ведення журналу досягають компромісу: зберігайте поточні журнали читаними та наявними та стискайте старіші. Це означає, що ви отримуєте користь від стиснення - тим більше, що насправді тому, що двійковий формат не зменшить повідомлення журналу. У той же час, ви можете використовувати менше і grep тощо.

Отже, які можливі переваги можуть виникнути від використання двійкових? Невелика кількість ефективності простору - все більш неважлива. Менше (чи менше) пише? Ну, можливо - насправді кількість записів буде залежати від кількості диск-комітів, тому, якщо рядки журналу значно менші за розмір блоків дисків, то SSD призначатиме нові блоки знову і знову. Отже, двійкові дані є правильним вибором, якщо:

• ви пишете величезну кількість структурованих даних
• журнали повинні бути створені особливо швидко
• вам навряд чи знадобиться їх аналізувати в умовах "підтримки"

але це звучить не так, як реєстрація програм; це вихідні файли або записи про активність. Поміщення їх у файл, ймовірно, лише за крок від їх запису до бази даних.

EDIT

Я думаю, що тут існує загальна плутанина між "програмами журналів" (за рамками реєстрації) та "записами" (як у журналах доступу, записах входу тощо). Я підозрюю, що питання найбільше стосується останнього, і в цьому випадку питання є набагато менш чітким. Цілком прийнятно, щоб запис запису повідомлень або журнал активності був у компактному форматі, тим більше, що він, ймовірно, буде чітко визначений і використовується для аналізу, а не для усунення несправностей. Інструменти, які роблять це, включають tcpdumpмонітор системи Unix sar. Журнали програм з іншого боку, як правило, набагато більше спеціальні.

Приклад дещо двійкового журналу широко поширений: журнал подій Windows. З боку професіоналів, це дозволяє повідомленням журналу бути дуже виразним (і, таким чином, сподіваюся, корисним) практично без витрат, можливо, щось подібне

Попередження: Черга фоборів, яку потрібно зробити, зросла на 517 предметів за останні 90 секунд. Якщо це відбувається приблизно один раз на день, хвилюватися нема про що. Якщо це трапляється частіше або швидко, ви можете перевірити об'єм оперативної пам’яті, доступний для програми foobar. Однак, якщо це відбувається разом із подією 12345, ви, здається, використовуєте застарілу базу даних, і вам краще зателефонувати в службу підтримки за номером + 1-555-12345, щоб запобігти втраті даних.

Основна частина цього повідомлення існує лише один раз як ресурс, встановлений разом із програмою. Однак якщо цей ресурс встановлений неправильно (наприклад, тому, що тим часом була встановлена ​​новіша версія, яка більше не підтримує це застаріле повідомлення), все, що ви бачите в журналі подій, - це стандартне повідомлення, яке є просто химерним формулюванням для

Данно, щось із "517" і "90".

і більше не допомагає жодним чином.

Дві основні питання, які ви хочете задати, перш ніж вибрати між текстом і двійковим:

• Хто моя аудиторія?
• Який зміст мені потрібно передати?

Поширена думка, що аудиторія журнального повідомлення - це людина. Це, очевидно, не є ідеальним припущенням, оскільки там багато сценаріїв сканування журналів, але це звичайне. У цьому випадку має сенс передавати інформацію в середовищі, в якій людині комфортно. Текст має давню традицію бути цим засобом.

Щодо змісту, врахуйте, що двійковий журнал повинен мати чітко визначений формат. Формат повинен бути досить чітко визначений, щоб інші люди могли писати програмне забезпечення, яке працює на цих журналах. Деякі журнали досить добре структуровані (у вашому запитанні кілька). Інші журнали потребують можливості передавати вміст у менш чітко визначеній природній мовній формі. Такі випадки природної мови є поганою відповідністю для бінарних форматів.

Для журналів, які можна було б добре описати у двійковій формі, ви повинні зробити вибір. Оскільки текст працює для всіх, його часто сприймають як вибір за замовчуванням. Якщо ви реєструєте результати в тексті, люди можуть працювати з вашими журналами. Це було доведено тисячі разів. Бінарні файли складніші. Як результат, може бути, що розробники виводять текст просто тому, що всі знають, як саме так поводитись.

TL; DR: Розмір насправді не має значення, але зручність використання має

Перш за все, хоча порівняння відповідних переваг тексту та бінарних форматів для короткочасного зберігання журналу є важливим питанням, розмір насправді не має значення. Дві причини цього:

1. Журнали - це надмірна інформація, яка дуже добре стиснеться: на мій досвід, не рідко можна побачити стислі файли журналів, розмір яких становить 5% або менше від розміру вихідного файлу. Отже, використання тексту чи двійкового формату не повинно мати жодного вимірюваного впливу на тривале зберігання журналів.

2. Який би формат ми не вибрали, журнали швидко заповнять серверний диск, якщо ми не реалізуємо «протокол файлів журналів», який стискає та відправляє файли журналів на тривалу платформу зберігання. Використання бінарного формату це може трохи уповільнити, але навіть зміна в 10 разів не має великого значення.

Текст проти бінарних форматів журналу

Система Unix обіцяє, що, якщо ми навчимося використовувати стандартний набір інструментів, що працює над текстовими файлами, структурованими по рядках - наприклад, grep , сортування , приєднання , sed і awk - ми зможемо використовувати їх для швидкої збірки прототипів, виконуючи будь-яку роботу ми хочемо, хоч повільно і грубо. Після того, як прототип продемонстрував свою корисність, ми можемо вирішити перетворити його на дійсно розроблене програмне забезпечення для отримання продуктивності або додавання інших корисних функцій. Це, принаймні, на моє розуміння, суть філософії Unix.

Інакше кажучи, якщо нам, ймовірно, потрібно проводити лікування та аналізи, ми не можемо розібратися до сьогодні, якщо ми не знаємо, хто повинен реалізувати цей аналіз тощо. Тоді ми перебуваємо на стадії, коли слід використовувати прототипи та текстові формати для колоди, ймовірно, оптимальні. Якщо нам потрібно неодноразово виконувати невеликий набір чітко визначених обробок, то ми опинимось у ситуації, коли нам слід запроектувати багаторічну програмну систему для виконання цього аналізу та бінарних або структурованих форматів для журналів, таких як реляційні бази даних, ймовірно. оптимальні.

(Деякий час тому я писав про це в блозі .)

Файли журналу мають текстовий формат, оскільки їх можна легко прочитати за допомогою будь-якого типу текстового редактора або шляхом відображення вмісту за допомогою консольної команди.

Однак деякі файли журналів є у двійковому форматі, якщо є багато даних. Наприклад, продукт, над яким я працюю, зберігає максимум 15000 записів. Для того, щоб зберігати записи в найменшій кількості кімнат, вони зберігаються у двійковій. Однак для перегляду записів або перетворення їх у формат, який можна використовувати (наприклад, електронні таблиці), слід написати спеціальну програму.

Підсумовуючи, не всі файли журналу є текстовими. Текстовий формат має перевагу в тому, що спеціальні інструменти не потрібні для перегляду вмісту. Там, де є багато даних, файл може бути у двійковому форматі. Двійковий формат потребує (спеціальної) програми для зчитування даних та відображення у читаному для людини форматі. Більше даних можна упакувати у двійковий формат. Чи використовувати текстовий або двійковий формат - це рішення, яке ґрунтується на кількості даних та простоті перегляду вмісту.

У вбудованих системах, де у мене може не бути доступного вихідного каналу під час виконання, програма не може дозволити собі швидкість, накладена журналом, або ведення журналу змінило б або замаскує ефект, який я намагаюся записати, я часто вдаються до заповнення бінарних даних у масив чи буфер кільця, або друкують його (наприкінці тестового циклу), або скидають їх у сирому вигляді та записують інтерпретатор, щоб надрукувати їх як читабельні. Так чи інакше, я хочу закінчити читабельні дані.

Чому в системах, що мають більше ресурсів, навіщо винаходити схеми для оптимізації того, що не потребує оптимізації?

Файли журналу призначені для налагодження проблем. Зазвичай місце на жорсткому диску значно дешевше, ніж інженерний час. У файлах журналу використовується текст, оскільки існує багато інструментів для роботи з текстом (наприклад, tail -f). Навіть HTTP використовує звичайний текст (див. Також, чому ми не надсилаємо двійкові файли, а не текст на http ).

Крім того, дешевше розробити систему простого тексту та перевірити, чи вона працює, легше налагодити, якщо вона піде не так, і легше відновити будь-яку корисну інформацію, якщо система виходить з ладу та пошкоджує частину журналу.

Пошкоджений текстовий файл все ще читається навколо зіпсованої частини. Пошкоджений двійковий файл може бути відновлений, але його також не може бути. Навіть якщо вона відновлюється, це вимагатиме трохи більше роботи. Інша причина полягає в тому, що формат бінарного ведення журналу робить меншою ймовірність, що під час поспіху створити "тимчасовий виправлення" (він же "найстаріший з усіх виправлень") рішення для реєстрації використовуватиметься замість того, що можна створити швидше.

Ми розраховуємо на тестування одиниць для досягнення та підтримання надійності нашого програмного забезпечення. (Більшість нашого коду працює на сервері, без голови; аналіз після реєстрації файлів журналів є ключовою стратегією.) Майже кожен клас у нашій реалізації здійснює певний журнал. Важливою частиною нашого одиничного тестування є використання 'макетних' реєстраторів, які використовуються при тестуванні одиниць. Тест блоку створює макетний реєстратор та надає його тестуваному елементу. Потім (коли корисно / доцільно) аналізується те, що було зареєстровано (особливо помилки та попередження). Використання текстового формату журналу значно полегшує з тих самих причин, що й аналіз, проведений у "реальних" журналах: у вашому розпорядженні більше інструментів, які швидко використовувати та адаптувати.

Історично журнали були офіційними, рукописними та послідовними записами подій. Коли техніка стала здатною записувати події, вони записувались на пристрій виводу на копії, наприклад принтер телетайпи, який створював постійний послідовний запис, але який міг обробляти лише текст і час від часу дзвонити BELL ...

Ще в мої основні дні ми використовували створений на замовлення двійковий формат журналу. Основною причиною було не економія місця, це тому, що ми хотіли, щоб журнал займав обмежений простір, перезаписуючи старі записи новими; останнє, що ми хотіли, - це не в змозі діагностувати проблеми, спричинені повним завантаженням дисків (у 1980 році дисковий простір коштував 1000 доларів / Мб, тому люди не купували більше, ніж потрібно).

Тепер мені ще подобається ідея кругового файлу журналу, і якби операційні системи пропонували такого звіра, я б його використовував без вагань. Але бінарний був поганою ідеєю. Ви дійсно не хочете витрачати час на пошук правильних команд для розшифровки файлу журналу, коли у вас є вирішальна критична проблема.