Система журналирования в программировании — это комплекс инструментов, направленных на хронологическую запись событий, происходящих с какой-то программой, сервером, файловой системой. Все события записываются в отдельный файл и могут быть рассмотрены разработчиком. Разработчик может посмотреть в файле, что происходило с его программой в определенный момент времени.
Журналирование событий несет в себе главную задачу — туда записывается все, что указал разработчик, поэтому в случае возникновения ошибки в программе разработчик может открыть журнал событий и увидеть, что и когда сработало не по плану. То есть в журнале событий он увидит:
когда произошло событие,
что происходило до события,
какие компоненты повлияли на событие,
и др.
С такой информацией разработчик может определить, что можно предпринять, чтобы исправить ситуацию и чтобы негативные события больше не происходили. Однако система журналирования нужна не только для записей ошибок, ее возможности намного шире.
Система журналирования в программировании
Система журналирования для каждого приложения, сервера, программы настраивается индивидуально. То есть можно вообще ничего не журналировать, а можно журналировать все подряд. Присутствует или не присутствует журнал событий — это никак не влияет на работоспособность и производительность программного продукта. Журналирование событий нужно разработчику. Это как «черный ящик» в самолетах, который в случае аварии помогает восстановить произошедшие события.
Журналировать все события подряд не имеет смысла, так как в результате появятся миллионы сообщений, а полезными из них будут лишь сотни. Отыскать эти «сотни» среди миллионов других — задача трудоемкая, поэтому давайте посмотрим, какие события можно журналировать, а какие не стоит.
Система журналирования полезных событий
Чуть ниже мы приведем список происходящих событий, которые стоит журналировать, так как они могут оказаться полезными:
Входящие и исходящие события. В случае, если ваш программный продукт состоит из нескольких компонентов, которые общаются между собой сообщениями, нужно журналировать эти сообщения. Если работа продукта будет нарушена, по сообщениям вы сможете определить, что пошло не так.
Вызов сервисов и функций. Этот пункт важен при отладке сообщений. Когда в программе присутствует много сервисов и функций, может случиться так, что будет нарушена логика отношений между ними. Если вызовы сервисов и функций будут записываться, тогда будет возможность быстрее найти нарушения.
Действия пользователей. Каждый продукт обладает собственным «маршрутом пользователя». Это путь, который проходит пользователь до совершения желаемого результата. Чтобы понять, где пользователи испытывают трудности и что заставляет их покидать «маршрут», нужно записывать действия пользователей в журнале.
Операции с данными. С точки зрения безопасности во многих приложениях налажено журналирование операций с важной информацией. Журналироваться может следующая информация: идентификаторы доступа к программе, распределение привилегий ролей, метки по отдельным пользователям, запросы пользователей, состояния информации до и после ее изменения, операции с информацией (импорт и экспорт, обновление) и др.
Системные события. Журналирование этих событий позволяет получать свежие данные о состоянии системы. К таким событиям относятся: запуск, остановка, перезагрузка системы, а также использование различных режимов, межсервисное взаимодействие, идентификаторы сервисов и API, изменения конфигураций и др. В общем, все, что поможет вам узнать о состоянии системы вашего программного продукта, подлежит журналированию.
Статистические данные производительности. Даже отлаженное и хорошо работающее приложение может дать сбой из-за внезапного ухудшения производительности программы, поэтому важно наладить сбор статистической информации о производительности системы, чтобы была возможность вовремя среагировать. Что именно должно входить в собираемые данные — зависит от конкретной программы.
Угрозы безопасности. Целенаправленный взлом программ происходит внезапно, а потому предугадать его будет достаточно сложно. Однако, если записывать в журнал признаки, предшествующие взлому, тогда есть шанс его предвидеть. К таким признакам относятся: подозрительная активность пользователей и подозрительное поведение системы. В основном к подозрительной активности относят многократную ошибочную аутентификацию и верификацию. А к подозрительному поведению системы относят: резкий прирост потребления ресурсов устройства, прирост нагрузки на серверы, периодические сбои на серверах и др.
Конечно, определять области журналирования нужно самостоятельно, отталкиваясь от уровня и возможностей вашего программного продукта, но есть ряд областей, которые нет смысла журналировать.
Система журналирования бесполезных событий
События, о которых пойдет речь чуть ниже, не несут никакой полезности при их журналировании. Они будут просто захламлять журналы и мешать определению действительно важных событий. Поэтому о них нужно знать и исключать их из журналов. Например:
Информация персонального характера. Этот пункт запрещен законами приватности и конфиденциальности (GDPR, CCPA), поэтому не стоит журналировать личные данные пользователей вашей программы. Например: логин, фамилии и имена, дату рождения, адрес проживания, пол, электронный адрес, номера телефонов, налоговые номера, номера банковских карт и др.
Наименование компаний и их контактная информация. Такую информацию относят к деловой. Для изучения работоспособности программы она бесполезна, а ее раскрытие в журнале может привести к лишним проблемам. Чтобы отслеживать ту или иную компанию в своем приложении, обычно используют идентификаторы компаний и событий, связанных с ними.
Финансовая информация. Данная информация, также защищена законом, и в случае ее раскрытия в журнале на вас может быть подан судебный иск. К этой информации относят: номера банковских счетов, реквизиты банковских карт, информацию о транзакциях и др.
Информация доступа. Такой род информации также считается конфиденциальным и не подлежит раскрытию в журнале. К этому виду информации относятся: пароль, ключ безопасности, секретные вопросы и ответы, секретные слова, токены аутентификации и др.
Уровни журналирования
Допустим, вы определили, что будете журналировать, а что нет. Если не придать журналируемой информации специальные уровни, тогда вы получите просто огромный список сообщений, в котором трудно будет разобраться. Уровни нужны для того, чтобы структурировать журналируемые сообщения и облегчить дальнейшую работу с ними.
Различают следующие структурные уровни журналирования:
Уровень «FATAL». Указывает на очень серьезные ошибки, которые могут привести к критическому завершению работы программы.
Уровень «ERROR». Указывает на ошибки, которые ухудшают работу и производительность программы, но работать с ними она может.
Уровень «WARNING». Указывает на события, которые представляют потенциальную опасность для программы. Они не ухудшают ее работоспособность и производительность и не приводят к критической остановке программы, но это события, которые в будущем могут перейти в статус «ERROR».
Уровень «INFO». Это сообщения информационного характера, на которые просто нужно обратить внимание.
Уровень «DEBUG». Это специфический уровень сообщений, который применяется при отладке программы.
Уровень «TRACE». Это самый «узкий» уровень сообщений, который содержит информацию о конкретном событии, переменной, стеке и др.
Заключение
Правильная организация системы страхования — это залог контроля работоспособности вашей программы. В журнале можно зафиксировать и посмотреть все, что вы хотите знать о собственной программе. Как использовать этот инструмент — зависит только от ваших предпочтений.
Другое
