Кстати ИБМ предоставляет доступ к своим МФ для студентов. Пожалуйста заходите, что хакеру прикинуться студентом? не вопрос.
Не МФ, но "для начала" можно попробовать "что попроще" - регистрируемся на PUB400, получаем валидный профайл, заходим и пробуем сломать его изнутри. Для начала хотя бы увеличить себе лимит дискового пространства и лимит на количество личных библиотек.
Да, именно так. Мы работаем с IBM i (AS/400). Там 5 уровней защиты на уровне ОС Мы работаем на 40-м уровне. Выше только 50-й уровень по классу С2
Министерство обороны США определяет уровень защиты класса С2, как обеспечивающий «селективную защиту и, путем включения возможностей аудита, ответственность субъектов за их действия»
Правительством США определены уровни защиты от А до D, где А — наивысший уровень защиты, а D — самый низкий. Классы B и С имеют несколько подуровней. Уровень защиты С2 — уровень, наивысший из обычно используемых в бизнесе.
Но этим надо одумляться и заниматься. И, естественно, более высокий уровень защиты доставляет пользователям (а иногда и разработчикам) больше "неудобств" за счет большего количества разных ограничений.
Совершенно необязательно чтобы что-то там торчало в интернет.
Есть внутренняя сеть. В ней есть виртуальные рабочие места (через VDI) И вот на этом рабочем месте уже можно запустить терминал к тестовому серверу. В нашем случае - софтверный эмулятор терминала 5250.
Чтобы со всем этим работать хватает самого слабенького компа. У меня под это выделен отдельный старый ноут Samsung NP300 с древним двухядерным Celeron B820 1.7ГГц, 8 Гб памяти и 512Гб SSD. Работает под Linux Mint. Там, собственно, на нем нужно запускать только VMWare Horizon Client и все.
Есть еще второй ноут, помощнее, под виндой. Там через VPN есть доступ до внутренних Jira/Confluence/Bitbucket/Jenkins/Artifactory/KTalk/RocketChat/CiscoJabber. Но к серверу - только с виртуалки через VDI (на ней, в принципе, можно полноценно работать, но мне удобнее на основном, а с виртуалки только то, что требует работы непосредственно с сервером).
Скорее кто не будет посажен т.к. все данные по операционной деятельности и том, куда ушли госсубсидии, уничтожены "злыми хакерами". Никакая проверка теперь не страшна :-)
Я это каждый день вижу. Доступ к тестовому серверу только из внутренней сети (т.е. даже через VPN корпоративный нет, только с компа в офисе или с виртуального рабочего места через VDI). К проду реальный доступ у нескольких десятков человек (при том, что IT подразделение порядка 5т человек) - дежурная смена сопровождения + несколько человек с административными правами. У остальных - только возможность посылать конкретные запросы и получать ответы в рамках своих должностных обязанностей.
У разработчиков и аналитиков доступа к прому нет. Только к тесту, да и то там все по ролям расписано (уровни доступа). И многие команды заблокированы. И на доступ к конкретному юниту на тесте нужно права получать с обоснованием зачем.
И все пароли меняются не реже чем раз в три месяца. И не менее 12 символов "3 группы из 4-х". И три неправильных попытки - блокировка профайла с разблокировкой по отдельной заявке.
Поговорил с ребятами, аудировавших Аэрофлот. То, что случилось вчера вызывает огромное количество вопросов. Главный — зачем тратить столько усилий (по словам группировки, пролезали год), чтобы всего на 10 часов вызвать легкие (скорее некритичные) для пассажиров неудобства. Зачем стирать все данные учета, отчета, корп-почты, но при этом оставлять данные бронирований, баллов систем лояльности и пользовательских данных? Не логично, не так ли?
У ребят, кажется, мнение солидарное — кажется, есть прямая закономерность: проверки в Мин.Трансе → «самоубийство» Министра — > стирание всех данных операционной деятельности Аэрофлота (напомню, один из главных получатель гос.субсидий). Тогда объяснимо, почему в заявлении так глупо и не уместно подсвечивается «Глава не менял пароль от компьютера уже 3 года».
Быть во внутренней сети офиса это всё равно что быть в офисе.
Да. Но центральный сервер может быть сильно изолирован от внешнего мира. Доступ к нему только из внутренней сети. Причем, доступ авторизованый, в регулярной сменой паролей. Это для тестов.
Доступ к проду еще более ограничен. Даже из внутренней сети.
Доступ к данным на проде - только через очереди или WS в режиме конкретных ответов на конкретные запросы. Прямой доступ имеет только служба сопровождения (несколько десятков человек). Доступ с админскими правами - вообще у нескольких человек.
Плюс система автоматически журналирует все действия по изменению объектов - кто, что, когда. Плюс джоблоги. Все это системное, неотключаемое.
Слишком длинные имена, тем более те, где различие идет в конце, визуально все равно плохо воспринимаются и различаются при быстром просмотре.
Особенность восприятия человека в том, что он слово (а часто и фразу) воспринимает как образ (ну если это не первоклассник который толко-только учится читать). Причем, с совпадением не на 100%, а до некоторой степени похожести. Поэтому часто слова, написанные с ошибкой (опечаткой) в одной-двух буквах воспринимаются правильно (а часто эта ошибка (опечатка) вообще проскакивает незамеченной до тех пор, пока ее не начинают специально искать, анализируя каждое слово по буквам (но это медленно).
С этой точки зрения такое вот длинные однотипные имена не улучшают, но наоборот ухудшают восприятие когда при быстром просмотре, навязывая необходимость каждое имя по буквам читать.
Это как параметры вложенных циклов - i и j или n и m легко путаются. А вот i и m намного проще различить.
Т.е. имена переменных и функций должны быть не просто информативными, но и визуально легко различимыми. Особенно там, где они в коде идут рядом.
И все равно, если вас заранее предупредили что последующий блок кода "делает вот это", он воспринимается намного легче чем когда вы сами пытаетесь по коду догадаться что он делает. Безотносительно нейминга (который тоже важен - с этим никто не спорит).
Возможно, я неправильно понимаю вашу претензию к предложенным @Rsa97 именам, но я вообще не вижу, как они могут способствовать превращению кода в дремучее легаси. По-моему, с этими именами всё в порядке, в особенности в сравнении с A, B, C, D.
A, B, C, D - это условно. реальные имена, конечно, более осмысленные.
Код без комментариев - это легаси уже через год. Даже с "правильными" именами. Устрицы. Насмотрелся по самое нехочу.
Там есть еще момент. Имена типа checkPotentialForRequestClerntsUL и checkPotentialForRequestClerntsFL - казалось бы очень осмысленно. Но когда у вас пара десятков вызовов тех и этих, различать их при быстром просмотре крайне сложно - длинные имена, отличающиеся только одной буквой.
И опять (в который раз) - имя может сказать "что", но ничего не говорит "как". А это важно когда это самое "как" надо изменить через год или два.
Так что комментарии в ключевых местах все-таки полезны для тех, кто потом туда полезет. Ну и актуализировать их нужно если что-то сильно меняется.
Как ни называйте, но чужой код со сложной логикой намного проще читается и понимается если вы заранее знаете что он делает.
А то что вы предлагаете - прямой путь к превращению кода в дремучее легаси уже через год-два. В долгоживущих (5-10 и более лет) и постоянно развивающихся и адаптирующихся под изменение внешних условий проектах такое недопустимо.
Такое работает в случае когда быстро делал, спихнул заказчику, деньги получил и свалил в даль светлую. А что там дальше с проектом будет - да хоть трава не расти. Не мои проблемы.
Если для автора кода очевидно, что делает функция enableGradientClipping(model), то для меня не очевидно ни что она делает, ни как она реализована, что часто тоже важно
Да. Именно так. И в ряде ситуация множество уровней абстракции только запутывают. Т.е. с одной стороны они как бы должны упрощать понимание "в общем", но на самом деле усложняют понимание деталей и поиск ошибок в реализации логики конкретных деталей.
Я всегда всем объясняю так: если ты пишешь комментарий, который отвечает на вопрос "как?" Или "что?", то вместо этого перепиши код, чтобы было понятно что он делает без комментариев.
И еще раз. При решении вот этой задачи без описания "как" вы очень долго будет ковырять код в попытках понять зачем именно там происходят хитрые манипуляции с массивами. Т.е. вы можете понять что там зачем-то сначала заполняется массив, а потом почему-то из него удаляются какие-то элементы.
Если будет краткое описание идеи, то код начнет "говорить сама за себя". Но только в том случае, когда вы на входе в блок кода уже понимаете как и что он должен делать. Это просто сэкономит время тем, кому придется этот код дорабатывать через 3-5 лет.
Есть и другие примеры. Как то - заполняется (причем, само заполнение там нетривиальное) два массива (A и B), а потом создаются еще два - С = A - B и D = B - A.
Зачем?
А когда вы напишете кратко что массив A - то, что есть в БД сейчас, массив B - то, что там должно быть. И тогда C - то, что нужно удалить, а D - то, что нужно добавить, то сразу все становится понятно.
Это все понятно. Но я привел пример когда порядок вызовов в принципе не важен. Но есть один вызов который или неважно в каком порядке вызывается (логика внутри более сложная т.к. есть некоторые дополнительные проверки уже существующих в списке элементов), или всегда должен идти первым (логика внутри более простая т.к. предполагается что на момент вызова список пуст).
А в целом все вызовы одноранговые - заполнение некоторого списка из разных источников по разным условиям.
вот этих самых getUsers() несколько штук разных. А getUsersPermissions(users) применяется уже ко всему списку, заполненному цепочкой getUsers(). И порядок вызовов в цепочке может быть важен. Или не важен.
Раз в два часа - это то, что залогировалось когда все хорошо и ошибок мало.
А если что-то случается ("дефект промсреды"), то там может быт сразу тысячи записей. Или если трейс потребовалось включить. Когда трейсится все подряд практически чтобы понимать где именно что пошло не так (в штатном режиме это не нужно - только производительность снижает - я потому и спрашивал - поддерживаются ли уровни логирования и управление ими в реальном времени).
JSON - это вообще для тех приложений где не требуется высокая производительность. Слишком большие накладные расходы на кодирование-декодирование. У нас практически не используется в принципе.
А если надо - есть таблица допинфо куда можно просто сбросить образ записи или какой-то дамп as is. Правда, извлекать его оттуда уже потребуется специальным образом - это фактически BLOB. Но это в особо тяжелых случаях используется. В 99% случаев для расследований инцидентов хватает текста.
А для повышения производительности есть в модуле логирования AllowLog которая проверяет разрешен ли данный уровень для данного узла - нужно ли тратить время на формирование сложного текста.
Как альтернатива еще есть возможность выводить трейсы в очередь сообщений (*msgq - есть у нас на платформе такие системные объекты). Там вообще в реальном времени видно что происходит. В одном задании работает модуль, в другом мониторим соответствующую очередь сообщений и сразу видим что туда летит. Но это скорее отладочное, когда отладчиком сложно или невозможно подлезть (например, не доступа для отладки в нужном юните или есть какие-то таймауты которые под отладчиком не соблюдаются).
Вообще, принципы логирования которые используем, формировались не один год методом проб и ошибок. Есть общие требования, но формат логов в разных случаях может быть разный. Где-то хватает общего, а где-то приходится делать что-то особенное т.к. общий уже не подходит.
И глубина хранения для разных типов сообщений может быть разная. Тут еще требования бизнеса могут быть. Сталкивался с тем, что бизнес говорит что им какая-то история по какому-то конкретному модулю нужна год. В том и дело, что лог - это не только ошибки.
По ошибкам с прода идет рассылка ежедневная типа:
Но бывают ситуации когда нужно попросить сопровождение чтобы на короткий период времени для какого-то узла включили трейсинг, а потом сделали выгрузку (или сами на тестах можем использовать трейсинг, а в пром выкатывать с уровнем логирования "только ошибки"). Чтобы понять что там происходит (если вдруг происходит что-то не то). А потом выключили обратно чтобы не раздувать лог (чем больше таблица, тем выше накладные расходы на поддержание ее индексов - неоправданно большие таблицы могут производительность системы в целом снижать).
И ошибка - это не обязательно падение всего и вся. И не обязательно ошибка в коде.
Это может быть ошибка в данных вследствие которой они не проходят через соответствующий модуль валидации. Например. Это тоже требует внимания.
И каждая команда обычно делает свой лог, со структурой, соответствующей своей специфике того, с чем они работают. Когда-то была идея универсального сервиса логирования, но изжила себя когда попытались свести воедино требования всех команд (которых не один десяток).
Вы не работаете с БД? Текстовые файлы парсить чтобы что-то там найти... Ну такое себе.
Есть ли у вас уровни логирования?
У нас есть отдельный сервис логирования. Поскольку вся работа у нас идет с БД, то и лог - это отдельная таблица в БД.
Каждая запись содержит
т.н. "узел логирования" - некий литерал, означающий к какому модулю (или части модуля) относится эта строка,
временную метку,
служебную информацию (это уже платформо-специфическое - номер задания, пользователь задания...)
уровень логирования (сейчас три уровня - ошибка, бизнес-сообщение, трейс)
ключ - произвольная информация для быстрого поиска. Например, идентификатор клиента - можно сделать выборку по узлу логирования и идентификатору клиента чтобы понять что было при его обработке
точка вызова - произвольный литерал, позволяющий идентифицировать в каком именно месте случилось событие.
собственно блок логируемой информации
Это основная таблица. Есть еще дополнительная таблица дополнительной информации для каких-то объемных данных. Она не обязательная, но, к примеру, если нужно скинуть в лог полный образ записи, то в основную таблицу пойдет запись с ключевой информацией, а полный образ обрабатываемой записи где случилась ошибка пойдет в дополнительную таблицу.
Плюс есть настроечная таблица где каждому узлу логирования сопоставляется допустимый уровень. Например, если для узла 'ABC' прописан уровень 'E', то в лог будут записываться только сообщения с уровнем 'E' - ошибки. Все остальное будет игнорироваться. А если поменять 'E' на 'T', то будут писаться все сообщения - ошибки, бизнес-сообщения, трейсы... Это позволяет "на лету" включать или выключать вывод в лог нужной информации. Т.е. когда в коде прописано логирование и ошибок, и бизнес-сообщений и трейсов, через настройки можно управлять что реально будет писаться в лог, а что нет.
Там же в настройках хранится глубина хранения для каждого узла логирования и каждого типа сообщений. Скажем, для узла 'ABC' ошибки хранятся неделю, бизнес - три дня, трейсы один день. Это для модуля прочистки логов который запускается раз в сутки.
Ну и поскольку все это хранится в БД, то не нужен никакой парсер - вся работа с логами делается скулем.
И лог - не на один какой-то модуль, а на "проект" содержащий сотни если не тысячи модулей (выборка нужной информации делается по узлу логирования, времени, полю ключевой информации...). И выборку можно сразу делать как по основной, так и по дополнительной таблице.
Не МФ, но "для начала" можно попробовать "что попроще" - регистрируемся на PUB400, получаем валидный профайл, заходим и пробуем сломать его изнутри. Для начала хотя бы увеличить себе лимит дискового пространства и лимит на количество личных библиотек.
Не совсем понятно что дизайнеру с макбуком делать на мейнфрейме... Он не для дизайнеров, он для других задач.
А для программиста не проблема - запустил терминал (или его программный эмулятор), подключился к серверу и делай что тебе надо.
Если говорить о разработке, то весь код пишется на десктопе. Потом забрасывается на сервер и там запускается сборка.
Ну я не говорю что все менять надо. Я говорю что все это вполне реально. И у нас так сделано изначально было.
А дураков учить надо. И если он не понимает иначе как дубиной по лбу - значит учить дубиной по лбу.
Да, именно так. Мы работаем с IBM i (AS/400). Там 5 уровней защиты на уровне ОС Мы работаем на 40-м уровне. Выше только 50-й уровень по классу С2
Но этим надо одумляться и заниматься. И, естественно, более высокий уровень защиты доставляет пользователям (а иногда и разработчикам) больше "неудобств" за счет большего количества разных ограничений.
Совершенно необязательно чтобы что-то там торчало в интернет.
Есть внутренняя сеть. В ней есть виртуальные рабочие места (через VDI) И вот на этом рабочем месте уже можно запустить терминал к тестовому серверу. В нашем случае - софтверный эмулятор терминала 5250.
Чтобы со всем этим работать хватает самого слабенького компа. У меня под это выделен отдельный старый ноут Samsung NP300 с древним двухядерным Celeron B820 1.7ГГц, 8 Гб памяти и 512Гб SSD. Работает под Linux Mint. Там, собственно, на нем нужно запускать только VMWare Horizon Client и все.
Есть еще второй ноут, помощнее, под виндой. Там через VPN есть доступ до внутренних Jira/Confluence/Bitbucket/Jenkins/Artifactory/KTalk/RocketChat/CiscoJabber. Но к серверу - только с виртуалки через VDI (на ней, в принципе, можно полноценно работать, но мне удобнее на основном, а с виртуалки только то, что требует работы непосредственно с сервером).
Скорее кто не будет посажен т.к. все данные по операционной деятельности и том, куда ушли госсубсидии, уничтожены "злыми хакерами". Никакая проверка теперь не страшна :-)
Я это каждый день вижу. Доступ к тестовому серверу только из внутренней сети (т.е. даже через VPN корпоративный нет, только с компа в офисе или с виртуального рабочего места через VDI). К проду реальный доступ у нескольких десятков человек (при том, что IT подразделение порядка 5т человек) - дежурная смена сопровождения + несколько человек с административными правами. У остальных - только возможность посылать конкретные запросы и получать ответы в рамках своих должностных обязанностей.
У разработчиков и аналитиков доступа к прому нет. Только к тесту, да и то там все по ролям расписано (уровни доступа). И многие команды заблокированы. И на доступ к конкретному юниту на тесте нужно права получать с обоснованием зачем.
И все пароли меняются не реже чем раз в три месяца. И не менее 12 символов "3 группы из 4-х". И три неправильных попытки - блокировка профайла с разблокировкой по отдельной заявке.
Ну среди диванных экспертов есть такое мнение:
Да. Но центральный сервер может быть сильно изолирован от внешнего мира. Доступ к нему только из внутренней сети. Причем, доступ авторизованый, в регулярной сменой паролей. Это для тестов.
Доступ к проду еще более ограничен. Даже из внутренней сети.
Доступ к данным на проде - только через очереди или WS в режиме конкретных ответов на конкретные запросы. Прямой доступ имеет только служба сопровождения (несколько десятков человек). Доступ с админскими правами - вообще у нескольких человек.
Плюс система автоматически журналирует все действия по изменению объектов - кто, что, когда. Плюс джоблоги. Все это системное, неотключаемое.
Слишком длинные имена, тем более те, где различие идет в конце, визуально все равно плохо воспринимаются и различаются при быстром просмотре.
Особенность восприятия человека в том, что он слово (а часто и фразу) воспринимает как образ (ну если это не первоклассник который толко-только учится читать). Причем, с совпадением не на 100%, а до некоторой степени похожести. Поэтому часто слова, написанные с ошибкой (опечаткой) в одной-двух буквах воспринимаются правильно (а часто эта ошибка (опечатка) вообще проскакивает незамеченной до тех пор, пока ее не начинают специально искать, анализируя каждое слово по буквам (но это медленно).
С этой точки зрения такое вот длинные однотипные имена не улучшают, но наоборот ухудшают восприятие когда при быстром просмотре, навязывая необходимость каждое имя по буквам читать.
Это как параметры вложенных циклов - i и j или n и m легко путаются. А вот i и m намного проще различить.
Т.е. имена переменных и функций должны быть не просто информативными, но и визуально легко различимыми. Особенно там, где они в коде идут рядом.
И все равно, если вас заранее предупредили что последующий блок кода "делает вот это", он воспринимается намного легче чем когда вы сами пытаетесь по коду догадаться что он делает. Безотносительно нейминга (который тоже важен - с этим никто не спорит).
Лучший маркер - это когда вы можете легко читать код со сложной логикой через год-два после его написания.
A, B, C, D - это условно. реальные имена, конечно, более осмысленные.
Код без комментариев - это легаси уже через год. Даже с "правильными" именами. Устрицы. Насмотрелся по самое нехочу.
Там есть еще момент. Имена типа checkPotentialForRequestClerntsUL и checkPotentialForRequestClerntsFL - казалось бы очень осмысленно. Но когда у вас пара десятков вызовов тех и этих, различать их при быстром просмотре крайне сложно - длинные имена, отличающиеся только одной буквой.
И опять (в который раз) - имя может сказать "что", но ничего не говорит "как". А это важно когда это самое "как" надо изменить через год или два.
Так что комментарии в ключевых местах все-таки полезны для тех, кто потом туда полезет. Ну и актуализировать их нужно если что-то сильно меняется.
А если имена и смысл разъезжаются? Ровно тоже самое. Необходимость синхронизировать.
Как ни называйте, но чужой код со сложной логикой намного проще читается и понимается если вы заранее знаете что он делает.
А то что вы предлагаете - прямой путь к превращению кода в дремучее легаси уже через год-два. В долгоживущих (5-10 и более лет) и постоянно развивающихся и адаптирующихся под изменение внешних условий проектах такое недопустимо.
Такое работает в случае когда быстро делал, спихнул заказчику, деньги получил и свалил в даль светлую. А что там дальше с проектом будет - да хоть трава не расти. Не мои проблемы.
Да. Именно так. И в ряде ситуация множество уровней абстракции только запутывают. Т.е. с одной стороны они как бы должны упрощать понимание "в общем", но на самом деле усложняют понимание деталей и поиск ошибок в реализации логики конкретных деталей.
И еще раз. При решении вот этой задачи без описания "как" вы очень долго будет ковырять код в попытках понять зачем именно там происходят хитрые манипуляции с массивами. Т.е. вы можете понять что там зачем-то сначала заполняется массив, а потом почему-то из него удаляются какие-то элементы.
Если будет краткое описание идеи, то код начнет "говорить сама за себя". Но только в том случае, когда вы на входе в блок кода уже понимаете как и что он должен делать. Это просто сэкономит время тем, кому придется этот код дорабатывать через 3-5 лет.
Есть и другие примеры. Как то - заполняется (причем, само заполнение там нетривиальное) два массива (A и B), а потом создаются еще два - С = A - B и D = B - A.
Зачем?
А когда вы напишете кратко что массив A - то, что есть в БД сейчас, массив B - то, что там должно быть. И тогда C - то, что нужно удалить, а D - то, что нужно добавить, то сразу все становится понятно.
В реальной жизни такое сплошь и рядом.
Это все понятно. Но я привел пример когда порядок вызовов в принципе не важен. Но есть один вызов который или неважно в каком порядке вызывается (логика внутри более сложная т.к. есть некоторые дополнительные проверки уже существующих в списке элементов), или всегда должен идти первым (логика внутри более простая т.к. предполагается что на момент вызова список пуст).
А в целом все вызовы одноранговые - заполнение некоторого списка из разных источников по разным условиям.
Т.е. в случае
вот этих самых getUsers() несколько штук разных. А getUsersPermissions(users) применяется уже ко всему списку, заполненному цепочкой getUsers(). И порядок вызовов в цепочке может быть важен. Или не важен.
Раз в два часа - это то, что залогировалось когда все хорошо и ошибок мало.
А если что-то случается ("дефект промсреды"), то там может быт сразу тысячи записей. Или если трейс потребовалось включить. Когда трейсится все подряд практически чтобы понимать где именно что пошло не так (в штатном режиме это не нужно - только производительность снижает - я потому и спрашивал - поддерживаются ли уровни логирования и управление ими в реальном времени).
JSON - это вообще для тех приложений где не требуется высокая производительность. Слишком большие накладные расходы на кодирование-декодирование. У нас практически не используется в принципе.
А если надо - есть таблица допинфо куда можно просто сбросить образ записи или какой-то дамп as is. Правда, извлекать его оттуда уже потребуется специальным образом - это фактически BLOB. Но это в особо тяжелых случаях используется. В 99% случаев для расследований инцидентов хватает текста.
А для повышения производительности есть в модуле логирования AllowLog которая проверяет разрешен ли данный уровень для данного узла - нужно ли тратить время на формирование сложного текста.
Как альтернатива еще есть возможность выводить трейсы в очередь сообщений (*msgq - есть у нас на платформе такие системные объекты). Там вообще в реальном времени видно что происходит. В одном задании работает модуль, в другом мониторим соответствующую очередь сообщений и сразу видим что туда летит. Но это скорее отладочное, когда отладчиком сложно или невозможно подлезть (например, не доступа для отладки в нужном юните или есть какие-то таймауты которые под отладчиком не соблюдаются).
Вообще, принципы логирования которые используем, формировались не один год методом проб и ошибок. Есть общие требования, но формат логов в разных случаях может быть разный. Где-то хватает общего, а где-то приходится делать что-то особенное т.к. общий уже не подходит.
Ага. Сколько может стоить 400Tb SSD Array?
И где его можно купить?
И глубина хранения для разных типов сообщений может быть разная. Тут еще требования бизнеса могут быть. Сталкивался с тем, что бизнес говорит что им какая-то история по какому-то конкретному модулю нужна год. В том и дело, что лог - это не только ошибки.
По ошибкам с прода идет рассылка ежедневная типа:
Но бывают ситуации когда нужно попросить сопровождение чтобы на короткий период времени для какого-то узла включили трейсинг, а потом сделали выгрузку (или сами на тестах можем использовать трейсинг, а в пром выкатывать с уровнем логирования "только ошибки"). Чтобы понять что там происходит (если вдруг происходит что-то не то). А потом выключили обратно чтобы не раздувать лог (чем больше таблица, тем выше накладные расходы на поддержание ее индексов - неоправданно большие таблицы могут производительность системы в целом снижать).
И ошибка - это не обязательно падение всего и вся. И не обязательно ошибка в коде.
Это может быть ошибка в данных вследствие которой они не проходят через соответствующий модуль валидации. Например. Это тоже требует внимания.
И каждая команда обычно делает свой лог, со структурой, соответствующей своей специфике того, с чем они работают. Когда-то была идея универсального сервиса логирования, но изжила себя когда попытались свести воедино требования всех команд (которых не один десяток).
Вы не работаете с БД? Текстовые файлы парсить чтобы что-то там найти... Ну такое себе.
Есть ли у вас уровни логирования?
У нас есть отдельный сервис логирования. Поскольку вся работа у нас идет с БД, то и лог - это отдельная таблица в БД.
Каждая запись содержит
т.н. "узел логирования" - некий литерал, означающий к какому модулю (или части модуля) относится эта строка,
временную метку,
служебную информацию (это уже платформо-специфическое - номер задания, пользователь задания...)
уровень логирования (сейчас три уровня - ошибка, бизнес-сообщение, трейс)
ключ - произвольная информация для быстрого поиска. Например, идентификатор клиента - можно сделать выборку по узлу логирования и идентификатору клиента чтобы понять что было при его обработке
точка вызова - произвольный литерал, позволяющий идентифицировать в каком именно месте случилось событие.
собственно блок логируемой информации
Это основная таблица. Есть еще дополнительная таблица дополнительной информации для каких-то объемных данных. Она не обязательная, но, к примеру, если нужно скинуть в лог полный образ записи, то в основную таблицу пойдет запись с ключевой информацией, а полный образ обрабатываемой записи где случилась ошибка пойдет в дополнительную таблицу.
Плюс есть настроечная таблица где каждому узлу логирования сопоставляется допустимый уровень. Например, если для узла 'ABC' прописан уровень 'E', то в лог будут записываться только сообщения с уровнем 'E' - ошибки. Все остальное будет игнорироваться. А если поменять 'E' на 'T', то будут писаться все сообщения - ошибки, бизнес-сообщения, трейсы... Это позволяет "на лету" включать или выключать вывод в лог нужной информации. Т.е. когда в коде прописано логирование и ошибок, и бизнес-сообщений и трейсов, через настройки можно управлять что реально будет писаться в лог, а что нет.
Там же в настройках хранится глубина хранения для каждого узла логирования и каждого типа сообщений. Скажем, для узла 'ABC' ошибки хранятся неделю, бизнес - три дня, трейсы один день. Это для модуля прочистки логов который запускается раз в сутки.
Ну и поскольку все это хранится в БД, то не нужен никакой парсер - вся работа с логами делается скулем.
И лог - не на один какой-то модуль, а на "проект" содержащий сотни если не тысячи модулей (выборка нужной информации делается по узлу логирования, времени, полю ключевой информации...). И выборку можно сразу делать как по основной, так и по дополнительной таблице.