Давайте напишем содержательные сообщения журнала, которые всем нравятся!
Журналы приложений содержат информацию как о внутренних, так и о внешних событиях, которые видны приложению во время его выполнения. Когда в развертывании программного обеспечения присутствует ошибка, нарушение безопасности или аномалия, журналы приложений являются наиболее полезным и надежным свидетельством для проведения надлежащего анализа первопричин инцидента.
В этой статье давайте разберемся, как писать содержательные сообщения журнала приложений, которые всем нравятся.
1. Что регистрировать
✅ Входящие и исходящие сообщения
Когда компоненты взаимодействуют друг с другом посредством передачи сообщений, как входящие, так и исходящие сообщения должны быть записаны с URL-адресами конечных точек API, параметрами запроса, исходными и промежуточными IP-адресами, заголовками запросов, информацией об аутентификации, телами запросов и ответов, бизнес-контекстом, отметками времени и внутренними этапы обработки. Наиболее важно то, что для отслеживания цикла / передачи сообщений между несколькими службами в системе каждому сообщению должен быть присвоен уникальный идентификатор (обычно создается на уровне диспетчера API / фасада службы).
✅ Вызовы служб и функций
Когда вызывается служба или функция, рекомендуется регистрировать ее контекст на более низком уровне журнала, в основном для целей отладки (используйте TRACE или DEBUG). Наличие этих журналов помогает нам легко исследовать проблемы, связанные с бизнес-логикой, особенно когда у нас нет привилегии подключать отладчик к нашему приложению (например, развертывание в тестовых, промежуточных средах, предпроизводственных средах).
✅ Взаимодействие с пользователем и бизнес-статистика
У каждого приложения есть свои уникальные бизнес-кейсы и пути пользователя, и они раскрывают множество идей для специалистов в области системы. Например, то, занимает ли определенная транзакция слишком много времени или конечные пользователи все время застревают в некоторых функциях, являются очень важной информацией с точки зрения взаимодействия с пользователем. Другая информация, связанная с бизнесом, такая как объемы транзакций, активные пользователи и их этапы, важна для получения бизнес-аналитики и даже может использоваться для целей бизнес-аналитики.
✅ Операции с данными (контрольный журнал)
В большинстве корпоративных приложений по соображениям безопасности и соответствия необходимо вести отдельный журнал операций, связанных с данными, со всей важной информацией, такой как идентификаторы доступа (пользователь / система), точные экземпляры служб и используемые привилегии ролей, временные метки, запросы уровня данных. , а также снимки предыдущего и нового состояний измененного набора данных (diff). Журнал аудита должен фиксировать все связанные с данными попытки (доступ, импорт, экспорт и т. Д.) И операции CRUD (создание, чтение, обновление, удаление), выполненные пользователями, а также другими системами и службами.
✅ Системные события
Системные события должны собирать информацию о поведенческих событиях (запусках, остановках, перезапусках, событиях безопасности), режимах переключения (холодный, теплый, горячий), межсервисном взаимодействии (рукопожатия, статусы построения соединений - подключение, отключение, повторное подключение, события повторной попытки), идентификаторы экземпляров службы, активно обслуживающие API, активно прослушивающие диапазоны IP-адресов и портов, загруженные конфигурации (начальная загрузка и динамические обновления), общее состояние службы и все, что помогает понять поведение системы.
✅ Статистика производительности
Прилежание - отличная черта вычислительных устройств, но они могут быть не такими совершенными, как нас учили в школе. Аномалии производительности или внезапное неожиданное ухудшение работы служб (в основном из-за необработанных ошибок и поврежденных данных) могут произойти в любой момент времени. Для их выявления всегда рекомендуется публиковать статистику общего состояния и производительности системы. Такая статистика может включать в себя такую информацию, как количество вызовов API (как успешно обслуженных, так и отдельное количество отказов), задержки в сети, среднее время приема-передачи, потребление памяти и другую информацию, зависящую от приложения (в основном определяемую бизнес-контекстом).
✅ Угрозы и уязвимости
Выявление угроз и уязвимостей с помощью времени выполнения приложений и сообщений журнала - это искусство, которому должен научиться каждый разработчик корпоративного программного обеспечения. Как правило, нарушения безопасности и катастрофические сбои в приложениях не происходят внезапно. В большинстве случаев есть некоторые подсказки, которые никто не замечает. Поэтому мы всегда должны регистрировать подозрительные действия человека (например, неудачные попытки аутентификации и проверки со всей низкоуровневой информацией, такой как используемые сети, источники запросов, а также прикрепленные роли и привилегии пользователей), а также поведение системы (например, увеличение всплесков ресурсов закономерности потребления, высокие нагрузки на веб-серверы, случайное подавление сервисов). При обнаружении подозрительного события убедитесь, что в журналах записана вся информация, связанная с ним, в идеале - трассировка всего стека, включая значения параметров и дополнительную информацию, доступную из контекста приложения.
2. Что не нужно регистрировать
❌ Информация, позволяющая установить личность (PII)
Почти все законы о конфиденциальности (например, GDPR, CCPA) четко рекомендуют разработчикам не допускать попадания PII в журналы. PII включает такую информацию, как имя, фамилия, имя пользователя, пол, день рождения, почтовый и платежный адреса, электронные письма, номера телефонов, номера социального страхования (SSN) и номера кредитных карт.
❌ Названия компаний и контактная информация
Убедитесь, что вы не записываете в журнал такую информацию, как названия компаний, соответствующий персонал (сотрудники, клиенты, поставщики и т. Д.), А также деловую и личную контактную информацию. Журналы никогда не должны открывать посторонним сведения о деловых отношениях и сделках со связанными сторонами. Чтобы отследить определенные транзакции, вместо использования реальных названий компаний и идентификаторов убедитесь, что вы используете идентификатор события, сгенерированный системой, и передаете его через другие службы.
❌ Финансовые данные (банковские счета, реквизиты карты, суммы транзакций и т. Д.)
По закону все финансовые данные должны быть полностью скрыты / замаскированы в журналах. Разглашение такой информации в журналах может легко привести к серьезным судебным искам (даже может быть истолковано как уголовное преступление). Поэтому всегда избегайте таких случаев.
❌ Пароли, электронные ключи и секреты, токены авторизации
Учетные данные безопасности и токены аутентификации считаются конфиденциальной информацией, и их отображение в журналах помогает злоумышленникам легко устранять нарушения безопасности в системе. Поэтому всегда помните о такой конфиденциальной информации и храните ее подальше от журналов.
Примечание. Указать, какую информацию скрывать из журналов будет легко, если вы можете прикрепить к каждому полю атрибут, определяющий его уровень видимости (например, показать, замаскировать, скрыть, зашифровать). Если у вас есть такой механизм, вы можете включать и отключать видимость полей, просто обновляя свойство в конфигурациях. Если у вас есть потребность в регистрации некоторых пользовательских данных в непроизводственных средах, особенно для целей тестирования и отладки, это правильный вариант. В качестве альтернативы вы можете написать синтаксические анализаторы для фильтрации сообщений журнала и обработки конфиденциальных полей в соответствии с заранее определенными инструкциями в зависимости от среды.
3. Передовой опыт
✅ Знайте, когда использовать каждый уровень журнала
Уровень журнала используется для обозначения серьезности каждого события в системе. В большинстве фреймворков ведения журнала доступны следующие уровни.
- FATAL: означает очень серьезную ошибку, которая предположительно приведет к прерыванию работы приложения. Обычно это может закончиться катастрофическим отказом.
- ОШИБКА: обозначает события ошибок, которые могут позволить приложению продолжить работу с ограниченными возможностями в затронутых путях.
- ПРЕДУПРЕЖДЕНИЕ: обозначает менее опасные события, чем ошибки. Обычно они не приводят к ухудшению возможностей или полному отказу приложения. Однако они по-прежнему являются тревожным сигналом и требуют расследования.
- ИНФОРМАЦИЯ: обозначает баннеры важных событий и информационные сообщения в поведении приложения.
- ОТЛАДКА: обозначает конкретную и подробную информацию, в основном используемую для отладки. Эти журналы помогают нам выполнять код.
- TRACE: обозначает наиболее низкоуровневую информацию, такую как трассировки стека кода, чтобы предоставить наибольшую информацию об определенном событии / контексте. Эти журналы помогают нам проверять значения переменных и полные стеки ошибок.
Если мы возьмем системный журнал Linux, там будет больше уровней серьезности, таких как Emergency, Alert, Critical, Error, Warning, Notice, Information и Debug.
Независимо от сложности и глубины реализации каждого уровня журнала, мы должны правильно установить их в нашем коде, чтобы обеспечить оптимальный уровень информации для каждого сценария. Например, вся информация, используемая разработчиками для отладки и технического анализа, должна находиться на уровнях DEBUG или TRACE, в то время как баннеры системного уровня могут находиться на уровне INFO.
✅ Используйте английский язык
Некоторые инструменты и терминальные консоли не поддерживают печать и сохранение сообщений журнала с определенными символами Unicode. Следовательно, локализация и другие расширенные функции могут быть сложными на уровне ведения журнала. Поэтому убедитесь, что вы придерживаетесь английского языка и всегда используете общепринятый набор символов для написания сообщений журнала.
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: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 2020-11-11 13:52:22 DEBUG 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 ERROR Users:34 - Failed to update DB (E: inactive user, RecordID: 5f5a0d594d17e22b848ee570)
✅ Ввести ссылочные идентификаторы / кодовое имя / упрощенные шаблоны для частых и длинных сообщений журнала
Вместо того, чтобы постоянно регистрировать полные описания, попробуйте ввести ссылочный идентификатор или упрощенный шаблон для представления длинных описаний, которые постоянно появляются в вашем журнале. Это уменьшает общее количество и длину сообщений журнала, обеспечивая гибкость, позволяющую скрыть выбранную информацию. Например, без публикации уязвимостей в подробном текстовом формате в файле журнала всегда безопасно использовать кодовое имя или общий ссылочный идентификатор для их представления, чтобы только эксперты в предметной области могли понять реальный сценарий.
2020-11-11 13:52:27 ERROR DB:22 - Failed to write (E:ORA-01017) // ORA-01017 denotes "invalid username/password; logon denied" error message
✅ Используйте правильные временные метки (UTC / часовой пояс скорректирован)
Метки времени позволяют нам понять последовательность событий журнала и необходимы для отладки и аналитики. При регистрации времени рекомендуется использовать максимально подробную детализацию (например, точность на уровне миллисекунды или микросекунды), чтобы было легче идентифицировать соседние события журнала. Кроме того, убедитесь, что метка времени размещена в начале сообщения журнала в формате гггг-мм-дд ЧЧ: мм: сс. Всегда указывайте часовой пояс, если вы не используете время по умолчанию на сервере (UTC).
// 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)
Упоминание источника журнала с журналами 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-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 2020-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 initialized 2020-11-11 13:52: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: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 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all
✅ Прикрепите отслеживаемый идентификатор / токен события к сообщениям
Обычно, когда событие / сообщение поступает в систему, этому событию / сообщению присваивается уникальный идентификатор. Этот идентификатор будет передаваться на следующих этапах обработки и помогает нам отслеживать поток событий по всей системе, особенно для отладки, обработки параллелизма и операций, связанных с данными. В идеале в одной системе должен быть только один уникальный идентификатор для события во всех модулях и сервисах.
[87d4s-a98d7-9a8742jsd] Request Body: {
"request_id": "87d4s-a98d7-9a8742jsd",
"app_id": "TX001",
"option_val": "IBM",
"req_type_id": "0013",
"data": {...........}
}
[87d4s-a98d7-9a8742jsd] Sending request to RefData: http://10.244.2.168:8280/v1
✅ Упоминание сопоставлений идентификаторов в точках перехода
В некоторых случаях, особенно когда событие передается из одной системы в другую, идентификаторы событий меняются в соответствии с соглашением каждой системы. В таких точках перехода мы должны четко указать соответствие между предыдущим идентификатором события и вновь назначенным идентификатором в отдельном сообщении журнала с требуемым контекстом.
[1000508] ***** Incoming request from 10.244.2.168:3000 ***** [1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508 [1000508] Transaction successfully 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)
✅ Настроить уровень активного журнала
В зависимости от среды развертывания уровень активного журнала также должен быть изменен. Рекомендуемым соглашением для производственных сред является печать журналов до уровня ИНФОРМАЦИЯ. В других средах журналы будут распечатаны до уровня DEBUG или TRACE в соответствии с уровнем детализации, предпочитаемым командами Dev и SysOps.
// Active Log Level = DEBUG 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-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 2020-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 initialized 2020-11-11 13:52:22 DEBUG Adapters:20 - Successfully loaded all 2020-11-11 13:52:31 INFO app - Started listening... // Active Log Level = INFO 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 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) 2020-11-11 13:52:31 INFO app - Started listening...
✅ Для ошибок и сбоев предоставьте достаточный контекст
Ошибки и отказы требуют тщательной проверки. Чтобы сделать это возможным, приложение должно предоставлять экспертам в области системы достаточную справочную информацию, а также контексты бизнеса и технологий. Например, если запрос или сообщение не обрабатываются, в дополнение к сообщению об ошибке очень полезно регистрировать тело неудавшегося запроса.
[1000508] ***** Incoming request from 10.244.2.168:3000 *****
[1000508] Origin Id: 87d4s-a98d7-9a8742jsd -> System ID: 1000508
[1000508] Failed to validate msg body (E: Uncaught ReferenceError: missing params - option_val)
[1000508] Failed Message: {
"request_id": "87d4s-a98d7-9a8742jsd",
"app_id": "TX001",
"req_type_id": "0013",
"data": {...........}
}
✅ Подтверждайте операции с данными доказательствами (никогда не предполагайте!)
Каждый раз, когда происходит операция, связанная с данными, без слепого подтверждения ее завершения, убедитесь, что вы всегда подтверждаете конечное состояние с доказательствами. Например, как правило, когда вы создаете / обновляете / удаляете запись в базе данных, она возвращает количество измененных записей вместе с обновленной записью. В таких случаях всегда выполняйте проверки ожидаемых подсчетов или результатов. Другой пример - когда вы вставляете запись в структуру данных (скажем, в очередь). Вместо того, чтобы слепо предполагать операцию вставки, всегда берите размер очереди и проверяйте, был ли он увеличен на единицу. (Предположим, ваша система работает одновременно, но соответствующая очередь не поддерживает параллельные операции. В таких сценариях вы можете фактически потерять некоторые записи, и наличие чего-то вроде проверки длины - единственный способ обнаружить такие скрытые ошибки в коде.)
DEBUG BatchWriter:28 - Successfully connected to DB. Trying to insert 24 accounts... 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
[1000508] Request Body: {
”user_id”:”XXXXXXXXXX”,
”personal_details”:{
”firstName”:”XXXXXXXXXX”,
”lastName”:”XXXXXXXXXX”,
”DOB”:”XXXXXXXXXX”,
”gender”:”Male”,
”proffessional”:”Software Architect”,
”industry”:”IT”,
”SSN”:”XXXXXXXXXX”
},
”address_history”:[
{”streetAdress”:”Street No 1″,”zipcode”:”XXXXX”,”state”:”CA”},
{”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”NY”},
{”streetAdress”:”Street No 2″,”zipcode”:”XXXXX”,”state”:”AL”}
],
”card_info”:[
{”type”:”amex″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”},
{”type”:”visa″,”card_number”:”XXXXXXXXX”,”credit_limit”:”XXXXX”}
]
}
✅ Настроить имена файлов журнала, политики ротации, размер хранилища и процедуры резервного копирования.
Если вы записываете журналы в файл, убедитесь, что они хранятся на отдельном диске, который не влияет на работающее приложение (например, вы можете взять выделенное место с отдельного сервера и подключить его к серверам приложений). Также следует понимать частоту журналирования и структуру роста файлов журналов. Убедитесь, что у вас есть политика ротации журналов с правильными соглашениями об именах файлов (например, добавляйте метку времени к имени файла при создании каждого файла журнала), чтобы файлы журнала имели точную длину и количество. Кроме того, должны быть механизмы для резервного копирования старых журналов в безопасные места и регулярной очистки хранилищ журналов. В зависимости от отрасли, в которой вы работаете, вы можете определить срок действия резервной копии (обычно несколько месяцев или лет) и по окончании этого периода уничтожить все прошлые файлы журналов.
[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. Расширенные рекомендации
✅ Используйте централизованный агрегатор логов
Наличие центрального, доступного сервера / места для агрегирования журналов - очень распространенная практика среди разработчиков корпоративного программного обеспечения. Обычно эти агрегаторы журналов отслеживают не только журналы приложений, но и другие данные журналов, такие как журналы устройства / ОС (например, системный журнал Linux), журналы сети / брандмауэра, журналы базы данных и т. Д. серверы приложений и позволяют нам хранить все данные журналов в более безопасных, организованных и эффективных форматах в течение более длительного периода времени. В некоторых отраслях (например, банковское дело и финансы) обязательно хранить эти журналы как локально, так и в центральном хранилище, чтобы злоумышленникам и киберпреступникам было сложно получить доступ к обоим местоположениям и одновременно удалить свидетельства своей деятельности. Из-за такой избыточности журналов несоответствие между двумя местоположениями может указывать на красные флажки и помогать нам не допустить, чтобы нарушения оставались незамеченными.
✅ Создание парсеров журналов и профилактический мониторинг журналов
Написание настраиваемых анализаторов журналов и фильтров - это функция, интегрированная в большинство инструментов мониторинга журналов, также известная как интеграция информации о безопасности и управления событиями (SIEM). Такие парсеры помогают нам хранить данные журнала в более организованных форматах, и запросы становятся намного проще и быстрее. Кроме того, правильно организованные данные журналов могут быть загружены в системы мониторинга журналов и обнаружения аномалий для упреждающего мониторинга системы и прогнозирования будущих событий. Эти инструменты настолько продвинуты, что обеспечивают отличный визуальный опыт с помощью интерактивных панелей мониторинга на основе временных рядов и анализа событий в реальном времени на основе данных журнала и других источников.
✅ Настройте оповещения и push-уведомления при возникновении критических инцидентов
Почти все инструменты мониторинга журналов включают функции для определения пользовательских пороговых значений на определенных уровнях. Когда система достигает этих уровней, инструмент мониторинга проактивно обнаруживает их с помощью данных журнала и уведомляет системных администраторов с помощью сигналов тревоги, API push-уведомлений (например, Slack Audit Logs API), электронной почты и т. Д. Кроме того, они могут быть предварительно настроены. для запуска автоматических процессов, таких как динамическое масштабирование, резервное копирование системы, переналадка и т. д. Однако, если вы инвестируете в коммерческое программное обеспечение для целей мониторинга журналов, убедитесь, что вы проводите правильный анализ, потому что для большинства малых и средних программных систем это может быть излишним.
5. Рекомендуемые инструменты
Платформы ведения журналов
JavaScript/TypeScript ---> Log4js 😍 / pino Java --------------------> Log4j 😍 Golang ------------------> Logrus 😐 Serverless Functions ----> aws-lambda-powertools-python / Build it yourself 🤔 ..... ... . 👉 Let me know your favorites. I'd love to list them here!
Инструменты проверки / агрегирования / мониторинга журналов
CLI Tools ----> less, vim Cloud Tools --> Fluentd, AWS CloudWatch SIEM Tools ---> SolarWinds, Splunk, McAfee ESM, DataDog, IBM QRadar Other --------> ELK Stack 😍 (ElasticSearch, Logstash, Kibana, Beats) , Loggly ..... ... . 👉 Let me know your favorites. I'd love to list them here!
Следите за новыми советами по программированию. А пока желаю удачи!
