У нашому стрімкому світі, де щодня обсипає нас інформацією та завданнями, журналування стає ключовим інструментом самопізнання та саморефлексії. Я бачу у цьому процесі як спосіб фіксації думок і подій, а й потужний метод психологічної роботи із собою. Журналування – це регулярне ведення записів про свої думки, почуття, переживання та події життя. Це інструмент самопізнання, який допомагає впорядкувати свої думки, осмислити власні переживання та краще зрозуміти свої внутрішні процеси. Журналування – це не просто ведення щоденника, це шлях до глибокого самопізнання та особистісного зростання. Воно допомагає нам бути більш усвідомленими, зібраними та емоційно стійкими. Почніть свій шлях до самопізнання сьогодні, і ви побачите, як зміниться ваше життя на краще. У тебе складнощі з побудовою стосунків? Ти відчуваєш емоційну залежність від партнера, а він усувається? Тоді тобі допоможе мій телеграм канал Журнал - це процес запису в хронологічному порядку подій, що відбуваються з якимсь об'єктом. В інформаційних технологіях як такий об'єкт може представлятися файлова система, операційна система або окрема програма. Запис може здійснюватися у файл або базу даних. За цими записами можна зрозуміти, що зараз відбувається з об'єктом, що спостерігається, або ж відновити, що з ним відбувалося в якийсь цікавий для нас момент часу. Завдяки записам в журналах можна дізнатися про те, що якийсь інцидент відбувається прямо зараз, або ж розслідувати вже інцидент, знайти передумови до нього, відновити хід подій, що передує його виникненню, і виявити ті елементи, взаємодія з якими зробило його можливим. Припустимо, перестав відповідати сервер, на якому працює певний веб-додаток. У відповідь на запити сервер повертає код 404 або 500 (а то взагалі мовчить) і належним чином працювати не бажає.У такому випадку можна переглянути журнали реєстрації подій цього сервера, які зазвичай являють собою всі одержувані сервером запити. Крім одержуваних веб-сервером запитів можна журналювати події в операційній системі, на серверах баз даних, у різних засобах безпеки, в програмах користувача, на зовнішньому проксі-сервері та інші. то й події нас цікавитимуть лише його. різних її вузлах, а також на мережевому обладнанні. Це дозволить відстежувати більш складні взаємодії всередині системи. можна зрозуміти, з якого пристрою. Приклади подій, що журналюються: Очевидно, може відбуватися багато подій різного роду, особливо якщо мова йде про велику інформаційну систему. веб-сайту – це нормально.Якщо ж за одну секунду користувач звернувся до головної сторінки того ж сайту 100 разів — це вже підозріло. речей. Фільтрацією таких подій, а також моніторингом та пошуком кореляцій між подіями з різних джерел займаються, наприклад, рішення класу SIEM та SOC. Отже, події журналюються, інциденти детектуються та/або розслідуються. А тепер припустимо, що у нас є веб-сервер і якийсь зловмисник залив на нього веб-шелл. т. п.), видалив з журналу запис про POST-запит з відправкою веб-шелла та про всіх своїх діях, після чого видалив шелл і втік. Коли наслідки його дій будуть помічені, відповідних записів у журналі ми не знайдемо. місця в системі. Саме тому журнали необхідно захищати. журналу такий самий сумнів піддається вся одержувана з нього інформація. Відповідно, ставиться під питання використання журналу як достовірного джерела. Ні для кого не повинно бути можливо редагувати або видаляти записи в ньому. Зазвичай це вирішується призначенням прав доступу, що не дозволяють запис і редагування нікому крім системи. на віддаленому сервері або на тому ж, але в зашифрованому вигляді та, можливо, в іншій директорії.Крім цього, іноді журналами може користуватися зловмисник у своїх цілях навіть у режимі читання, тому дані в них, які приходять з боку користувача та на які він може вплинути, рекомендується екранувати. Журнали додатків розкривають інформацію про зовнішні та внутрішні події, які бачить додаток під час виконання. Коли при депло виникає баг, злом або аномалія, журнали - найкорисніший і надійний доказ для проведення аналізу причин інциденту. Давайте розберемося, як писати до журналу корисні повідомлення, які всім сподобаються. Якщо компоненти взаємодіють один з одним за допомогою повідомлень, то потрібно записувати вхідні та вихідні повідомлення із зазначенням URL'ів кінцевих точок API, параметри запитів, вихідні та проміжні IP запитів, заголовки запитів, інформацію про автора, тіла запитів та відповідей, бізнес-контекст , тимчасові мітки та етапи внутрішньої обробки. Дуже важливо, щоб кожному повідомленню було присвоєно унікальний ідентифікатор (який зазвичай генерується на рівні менеджера API або сервісу). Це необхідно для відстеження обміну повідомленнями між сервісами у системі. При виклику сервісу або функції бажано докладніше журналувати їх контекст, переважно для налагодження (використовуйте TRACE або DEBUG). Ці журнали допоможуть у розслідуванні проблем, пов'язаних з бізнес-логікою, особливо за відсутності привілеїв щодо прикріплення відладчика до програми (наприклад, при розгортанні в тестове, staging або pre-prod-оточення). У кожного додатка є унікальні бізнес-сценарії та маршрути користувача (user journey), які дають багато інформації профільним фахівцям.Наприклад, чи не надто довго виконувалася певна транзакція, чи не застряють чи користувачі на якійсь функціональності — все це дуже важливі дані з погляду досвіду користувача. Інша інформація, що стосується бізнесу, — кількість транзакцій та активних користувачів, а також їхні етапи — важлива для пошуку причинно-наслідкових зв'язків, і навіть може застосовуватися у бізнес-аналізі. З міркувань безпеки та дотримання вимог регулятора в більшості enterprise-додатків потрібно вести окремі журнали по операціях з усією важливою інформацією, такою як ідентифікатори доступу (користувачів та систем), точні екземпляри сервісів та використані привілеї ролей, тимчасові мітки, запити на дані, зліпки та нового стану змінених даних (diff). Журнал аудиту повинен фіксувати всі операції з даними (доступ, імпорт, експорт тощо), а також CRUD-операції (створення, читання, оновлення, видалення), виконані користувачами, іншими системами та сервісами. До них відноситься інформація про поведінку (запуски, зупинки, перезапуски та події, пов'язані з безпекою), перехідні режими (холодний, розігрів, гарячий), міжсервісну взаємодію (handshake, статуси установки з'єднання — підключено, відключено, перепідключено, повторні спроби), ідентифікатори екземплярів сервісів, що активно обслуговують API, активно прослуховують діапазони IP та портів, завантажені конфігурації (початкові завантаження та динамічні оновлення), загальний стан сервісів, а також все, що допоможе зрозуміти поведінку системи. Старанність - чудова характеристика обчислювальних пристроїв, але вони можуть працювати не ідеально.У будь-який час можуть виникнути проблеми з продуктивністю або раптові несподівані погіршення обслуговування (в основному через необроблені помилки та пошкоджені дані). Щоб їх визначити, завжди рекомендується публікувати статистику загального стану та продуктивності системи. Вона може містити інформацію на кшталт лічильників викликів API (успішно обслуговуваних та збійних), мережну затримку, середню тривалість roundtrip'ів, споживання пам'яті та іншу специфічну для програми інформацію (зазвичай визначається бізнес-контекстом). Розкриття погроз та вразливостей за допомогою runtime'a додатка та журналу – це мистецтво, яким має опанувати будь-який розробник enterprise-ПО. Зазвичай зломи та збої не відбуваються раптово. Найчастіше є ознаки, які спочатку ніхто не помічає. Тому потрібно завжди журналувати підозрілу людську активність (наприклад, помилкові спроби аутентифікації та верифікації з додатком усієї низькорівневої інформації на кшталт використаних мереж, джерел запитів, користувальницьких ролей та привілеїв), а також поведінку системи (наприклад, зростання піків у патернах споживання ресурсів, високе навантаження на веб-сервери, довільні збої сервісів). Коли ви помічаєте підозрілу подію, переконайтеся, що журнали містять всю пов'язану з нею інформацію. В ідеалі, щоб це було full-stack-трасування зі значеннями параметрів та додатковою інформацією, отриманою з контексту програми. Майже всі закони, що регулюють питання приватності (наприклад, GDPR, CCPA), прямо рекомендують розробникам не журналювати інформацію, що дозволяє встановити особистість. Сюди відносяться ПІБ, ніки, стать, день народження, поштова адреса, електронна пошта, телефонні номери, номер соціального страхування та номери кредитних карток. Переконайтеся, що ви не записуєте імена компаній, інформацію про співробітників, клієнтів, постачальників, а також контактну інформацію компанії та окремих людей. Журнал ніколи не повинен розкривати ділові взаємозв'язки та операції з третіми сторонами. Для відстеження конкретних транзакцій використовуйте замість справжніх назв ідентифікатори подій, згенеровані системою, та передавайте їх іншим сервісам. За законом всі фінансові дані мають бути повністю прибрані або замасковані. Розкриття такої інформації в журналах може призвести до серйозного судового позову (аж до кримінальної відповідальності). Уникайте цього всіма способами. Облікові дані та токени автентифікації вважаються конфіденційною інформацією, тому їхня наявність у журналах допоможе зловмисникам легко знайти проломи в системі. Тому не допускайте ці дані до журналів. Примітка: вам легко буде визначати, яку інформацію потрібно приховати від журналів, якщо ви додасте в кожне поле атрибут, який визначає рівень видимості (наприклад, show, mask, hide, encrypt). Якщо у вас є такий механізм, ви зможете змінювати видимість полів, просто оновлюючи властивості в конфігурації. Це гарне рішення в тих випадках, коли потрібно журналувати якусь інформацію в небойових оточеннях, особливо для тестування та налагодження. Або можна написати парсери, які фільтрують журнали та обробляють конфіденційні поля відповідно до заздалегідь прописаних для цього оточення інструкцій. Рівень журналу використовується для позначення серйозності кожного елемента системи. У більшості фреймворків для журналування є такі рівні: Незалежно від складності та глибини кожного рівня журналування, ми повинні коректно налаштовувати їх у своєму коді, щоб надавати оптимальну кількість інформації в кожному сценарії. банери із системними даними опускаються нижче INFO. Деякі інструменти та консолі не підтримують виведення та збереження журналів з певними символами Unicode. Якщо журналувати занадто мало, але ми не зможемо отримати потрібну інформацію для відтворення контексту кожної події. А якщо журналувати занадто багато, це погіршить продуктивність: запис величезного файлу журналу збільшить операції вводу-виводу і споживання ресурсів дискового сховища. Якщо файлова система не підтримує його, це зменшить загальну продуктивність системи. Для оптимізації повідомлень вам необхідно чітке розуміння функціональних та нефункціональних очікувань від системи та планування потрібної якості та кількості повідомлень. Кожен журнал має бути змістовним та відповідним контексту: завжди пишіть коротко та у справі. Замість того, щоб кожен раз записувати повний опис, спробуйте створити довідкові ідентифікатори або спрощені шаблони, щоб представляти в журналі довгі описи, що повторюються. Це зменшує загальну кількість та довжину повідомлень, а також підвищує гнучкість у приховуванні певної інформації. Наприклад, замість того, щоб описувати в текстовому журналі опис уразливості, краще використовувати псевдонім або ідентифікатор, щоб тільки профільні фахівці могли розібратися в актуальному сценарії. Тимчасові мітки дозволяють зрозуміти послідовність подій, вони необхідні для налагодження та аналізу. При фіксуванні часу рекомендується використовувати найдокладніші значення (наприклад, на рівні мілі- або мікросекунд), щоб легше було визначати суміжні події.Також переконайтеся, що тимчасові мітки стоять на початку повідомлення у форматі yyyy-mm-dd HH:mm:ss. Завжди вказуйте часовий пояс, якщо не використовуєте на сервері стандартний час (UTC). Це дуже корисно для точного визначення місця, яке призвело до відповідного повідомлення. Деякі фреймворки для журналювання дозволяють вказувати джерела на докладному рівні (аж до назва файлів з номерами рядків), але найчастіше достатньо згадки лише класу, функції або назви файлу. Більшість новачків роблять одну й ту саму помилку - копіпастять зразок повідомлення в різних файлах, збираючи фінальний журнал з однакових рядків, що надходять з різних частин системи. В цьому випадку важко відстежити конкретне місце, яке викликало цю подію. Якщо набір слів не можна змінювати, то хоча б згадайте джерело, щоб рядки у фінальному файлі відрізнялися один від одного. Крім того, якщо журналування обробляється батьківським класом, то відправляйте при ініціалізації ідентифікатор та застосовуйте його для запису повідомлень про поведінку дочірніх класів. Коли подія чи повідомлення потрапляє до системи, їй зазвичай надається унікальний ідентифікатор. Його можна передавати на інші етапи обробки, щоб відстежувати рух події по системі, це корисно для налагодження, конкурентної обробки та операцій, пов'язаних із даними. В ідеалі, у системі має бути унікальний ідентифікатор події у рамках усіх модулів та сервісів. Більшість enterprise-систем є розподіленими обчислювальними платформами, в яких присутнє багато примірників тих самих сервісів з різноманітними конфігураціями програми, ресурсами, версіями та мережевими властивостями. Рекомендується присвоїти примірникам ідентифікатори та використовувати їх при міжсервісній взаємодії. Активний рівень журналування необхідно змінювати залежно від оточення розгортання. Для виробництва рекомендується виводити журнали до рівня INFO. В інших оточеннях журнали виводяться до рівня DEBUG або TRACE, залежно від ступеня подробиці, яка потрібна командам розробки та експлуатації. Помилки та збої вимагають найретельнішого розслідування. Для цього додаток повинен надавати профільним фахівцям необхідну інформацію, а також технологічний та бізнес-контекст. Наприклад, якщо запит або повідомлення не вдалося обробити, на додаток до помилки дуже корисно журналувати і тіло збійного запиту. При кожній операції з даними не беріть на віру успішність її виконання. Завжди перевіряйте стан за допомогою доказів. Наприклад, коли ви створюєте, оновлюєте або видаляєте запис у базі даних, вона повертає лічильник змінених записів і самий оновлений запис. Завжди виконуйте перевірку очікуваного лічильника чи результату. Інший приклад: коли ви вставляєте запис до структури даних (наприклад, у чергу), то перевіряйте, чи збільшився її розмір. Припустимо, у вашій системі використовуються конкурентні операції, але черга їх не підтримує. Тоді ви можете втрачати якісь записи, і єдиний спосіб виявити такі приховані помилки у коді – це перевірка довжини. Зазвичай закон вимагає маскувати та/або шифрувати конфіденційну інформацію користувачів та внутрішніх систем. Залежно від вашої галузі та місця роботи можуть змінюватись і вимоги регуляторів. З'ясуйте всі нюанси та реалізуйте у додатку коректні процедури. У деяких випадках перед початком експлуатації вам може знадобитися надати стратегію журналування службі безпеки та отримати їх затвердження або сертифікат. Якщо ви пишете журнали у файли, переконайтеся, що вони зберігаються на окремому диску, який ніяк не впливає на працюючу програму (наприклад, можна виділити том на віддаленому сервері та прикріпити його до сервера додатків). Також з'ясуйте частоту журналу та характер збільшення файлів. Переконайтеся, що у вас є політика ротації журналів з коректними угодами за найменуваннями (наприклад, до назви додається тимчасова мітка), щоб підтримувати ідеальний розмір і кількість файлів. Також у вас повинен бути механізм резервного копіювання старих журналів у безпечне місце та механізм регулярного очищення сховищ.Залежно від вашої галузі можна налаштувати резервне копіювання за часом (зазвичай кожні кілька місяців або років), зі знищенням усіх попередніх файлів наприкінці періоду. Найпоширеніша практика серед розробників enterprise-додатків — створення центрального доступного сервера або місця для збирання журналів. Зазвичай такі агрегатори відстежують журнали не тільки додатків, але також пристроїв та операційних систем (наприклад, Linux Syslog), мережі, мережевих екранів, баз даних тощо. До того ж вони відокремлюють файли журналів від серверів додатків і дозволяють зберігати журнали в більш захищених, упорядкованих та ефективних форматах більш тривалий час. У деяких галузях (наприклад, банківській та фінансовій) необхідно зберігати журнали як у локальному, так і в центральному сховищі, щоб зловмисники не могли отримати доступ до обох місць та одночасно видалити докази своєї діяльності. Отже надмірність даних та їх невідповідність між двома сховищами можуть допомогти помітити проникнення. Можливість написання парсерів та фільтрів вбудована у більшість інструментів для моніторингу журналів – так звана SIEM-інтеграція (security information and event management). Парсери допомагають зберігати журнали в більш упорядкованих форматах, а запитувати дані стає набагато простіше та швидше.Також правильно організовані дані можна передавати системам моніторингу та пошуку аномалій для профілактичного моніторингу та прогнозування майбутніх подій. Ці інструменти мають дуже широкі можливості з графічного відображення даних на основі тимчасових послідовностей і в реальному часі. Майже всі інструменти моніторингу журналів дозволяють задавати певним рівням свої граничні значення. Коли система досягає таких значень, інструмент заздалегідь виявляє їх, допомагає журналювати дані та повідомляє сисадмінів за допомогою оповіщень, API push-повідомлень (наприклад, Slack Audit Logs API), електронних листів тощо. буд. Також їх можна заздалегідь налаштувати на ініціювання автоматичних процесів на кшталт динамічного масштабування, резервного копіювання системи, перекидання навантаження тощо. буд. Але якщо ви вкладаєтеся в комерційне програмне забезпечення для моніторингу журналів, уважно його вивчіть, тому що такі інструменти можуть бути надмірними для невеликих та середніх програмних систем. JavaScript/TypeScript: Log4js / pino Журналування як засіб самопізнання: усвідомлений шлях на краще Я.
Що таке журнал?
Чому журналування є ефективним?
Як розпочати журналування?
Техніки журналування
Подолання труднощів у журналуванні
Висновок
Для чого потрібне журналування
Найкращі методики журналування enterprise-додатків (з погляду інженера підтримки)
1. Що журналувати
Вхідні та вихідні повідомлення
Виклик сервісів та функцій
Дії користувачів та бізнес-статистика
Операції з даними (журнал аудиту)
Системні події
Статистика продуктивності
Загрози та вразливості
2. Що не потрібно журналувати
Інформацію особистого порядку
Назви компаній та контактну інформацію
Фінансові дані (банківські рахунки, реквізити банківських карток, суми, що пересилаються, і т. д.)
Паролі, ключі безпеки та секрети, токени аутентифікації
3. Найкращі методики
Знайте, коли потрібно використовувати той чи інший рівень журналування
Використовуйте англійську мову
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:2 Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 Adapters:20 - Successfully loaded all
Додайте зручні для розробників повідомлення (короткі та змістовні)
2020-11-11 13:52:27 DEBUG Users:18 - Successfully created new user (RecordID: 5f5a0d594d17e22b848ee570)2020-11-11 13:52:27 ERRORUser inactive user, RecordID: 5f5a0d594d17e22b848ee570)
Створіть довідкові ідентифікатори, псевдоніми та спрощені шаблони для часто використовуваних та довгих повідомлень
2020-11-11 13:52:27 ERROR DB:22 - Захищений до реєстрації (E:ORA-01017)// ORA-01017 denotes "invalid username/password; logon denied"
Використовуйте коректні тимчасові мітки
// with default server time (UTC)2020-11-11 13:52:12 INFO XYZ Integration API Manager v2.0.0// with timezone (e.g. PST - Pacific Standard Time)2020-11-11 13:52:12PST INFO XYZ Integration API Manager v2.0.0
Вказуйте джерело або походження журнальних даних (для DEBUG, TRACE, ERROR)
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app - *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 2020-11 -11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services.. 2020-3 :52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2520- 22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening.
Кожен журнал має бути унікальним у рамках системи
2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 2020-11-11 13:52:2 Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter initialized 2020-11-11 Adapters:20 - Successfully loaded all
Додайте в повідомлення ідентифікатор або токен повідомлення, що відстежується.
[87d4s-a98d7-9a8742jsd] Request Body: <"request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "option_val": "IBM", "req_type_id": "00 : [87d4s-a98d7-9a8742jsd] Посилання на RefData: href plaintext">[1000508] ***** Incoming request from 10.244.2.168:3000 ***** [1000508] Origin Id: 88d4 System ID: 1000508 [1000508] Transaction успішно added to Rabbit Queue
Вказуйте ідентифікатори всіх екземплярів сервісу
2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13:52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app - *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG)
Налаштуйте активний рівень журналування
// Active Log Level = DEBUG2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13: 52:18 INFO app - *** InstanceID APIM_V2_I02 2020-11-11 13:52:18 INFO app - *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 05 (DEBUG) 11-11 13:52:12 DEBUG App:22 - Initializing Swagger UI.. 2020-11-11 13:52:14 DEBUG App:28 - Generating schemata.. 2020-11-11 13:52:14 DEBUG App:30 - Initializing REST services. -11-11 13:52:15 DEBUG App:32 - Generating documentation.. 2020-11-11 13:52:18 DEBUG App:36 - Loading adapters.. 2020-11-11 13:52:21 DEBUG Adapters:10 - Loading adapter docs/v1 20 11-11 13:52:22 DEBUG Adapters:16 - Loading adapter mongo/v1 2020-11-11 13:52:26 DEBUG Docs:38 - docs adapter initialized 2020-11-11 13:52:27 DEBUG Mongo:38 - mongo adapter-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening.// Active Log Level = INFO2020-11-11 13:52:12 INFO app - XYZ Integration API Manager v2.0.0 2020-11-11 13:52:15 INFO app - Loading configurations.. 2020-11-11 13: 52:18 INFO app - *** InstanceID API_V2_I02 2020-11-11 13:52:18 INFO app - *** BaseURL http://10.244.2.168:3000 2020-11-11 13:52:19 INFO app - *** LogLevel 04 (INFO) 20 11-11 13:52:31 INFO app - Started listening.
Надайте достатній контекст для помилок та збоїв
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 1000508 [1000508] ReferenceError: missing params - option_val)[1000508] Помилка повідомлення: < "request_id": "87d4s-a98d7-9a8742jsd", "app_id": "TX001", "req_type_id": "0013", "data": >
Підтверджуйте доказами операції з даними (не передбачайте!)
DEBUG BatchWriter:28 - Очевидно, підключений до DB. Trying to insert 24 облікових записів. DEBUG BatchWriter:35 - Successfully inserted 24 accounts. Total DB rows affected: 24
Шифруйте або маскуйте конфіденційні дані
[1000508] ***** Incoming request from 10.244.2.168:3000 *****[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508 XXXXXXXXXX”, ”personal_details”:< ”firstName”:”XXXXXXXXXX”, ”lastName”:”XXXXXXXXXX”, ”DOB”:”XXXXXXXXXX”, ”gender”:”Male”, ”proffessional”:”Software Architect”, ”industry”: ”IT”, ”SSN”:”XXXXXXXXXX” >, ”address_history”:[ , , ], ”card_info”:[ , ] >
Налаштуйте назву файлів журналів, політики ротації, розмір сховищ та процедури резервного копіювання
[ec2-user@ip-XXX-XX-X-XXX logs]$ ls .. APIM_V2_I02-2020-11-20_04:38:43.log APIM_V2_I02-2020-11-23_02:05:35.log APIM_V2_I02-2020-11-24_04:38:17.log APIM_V2_I02-2020-11-27_03:28:37.log APIM_V2_I02-2020-11-27_12:06:45.log .
4. Додаткові рекомендації
Використовуйте центральний агрегатор журналів
Пишіть парсери та передбачливо відстежуйте журнали
Налаштуйте оповіщення та push-сповіщення для критичних інцидентів
5. Рекомендовані інструменти
Фреймворки для журналування
Java: Log4j
Golang: Logrus
Serverless-функції: aws-lambda-powertools-python / СамописнеВивчення, агрегування та моніторинг журналів
CLI-інструменти: less, vim
Хмарні інструменти: Fluentd, AWS CloudWatch
SIEM-інструменти: SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar
Інші: ELK Stack (ElasticSearch, Logstash, Kibana, Beats), Loggly