Comments 4
В показанной системе не хватает гибкости настройки логгирования: как уровня детализации, так и места, куда их выводить. Можно было позаимствовать функциональность из широко известных систем логгирования а-ля java.util.logging (SLF4j, log4j и его вариации для других языков/систем, и тд), гибкую настройку для какого кода с какого уровня сообщений и куда их сохранять. Например, в том же log4plsql можно настроить вывод и в alert.log, и в trace file (с помощью `dbms_system.ksdwrt()`)
Могу лишь вас заверить, что представленная модель логирования это результат написания более 5 БД с активным логированием ошибок. Изначально, в нашем логировании были уровни детализации, было логирование как в таблицу так и в лог-файл. За основы брались упомянутые вами системы. И все они так или иначе видоизменились до того состояния, что вы видели в описанных статьях. Описанная модель логирования совсем простая (примитивная, и я с этим согласен) и это тоже не просто так. Чем проще система логирования, тем более читаемый и предсказуемый результат вы получите на выходе (к этому мы пришли не сразу). Мной представлен способ логирования с помощью одной таблицы + 3 процедуры для создания записей в ней, куда же проще. Всё что вы описали оно все работает хорошо на демонстрационных примерах, а в реально действующей БД это не нужно. Опять же это мое личное мнение, но убежден, что в действующей БД при возникновении ошибки нам необходимо уметь:
1) Выявить факт возникновения ошибки максимально быстро для это необходимо знать: место возникновения ошибки; код + текст ошибки; параметры при которых возникла ошибка.
2) Максимально быстро воспроизвести эту ошибку для того, чтобы исправить её. Для того чтобы воспроизвести ошибку у нас есть все данные.
Представленная модель логирования это делает, а нужно ли больше? Это риторический вопрос.
К сожалению, это только мой опыт и моё суждение, но большинство разработчиков БД не станут писать логирование ошибок в своих БД если им об этом не сказать, к сожалению большинство из них не понимает зачем это делать. Комментарии к моим статьям это доказывают.
Если же вам удалось убедить своих коллег вести логирование ошибок в БД с помощью представленных вами SLF4j, log4j и его вариации для других языков/систем, и тд или Logger, то результат логирования с течением времени превращается в «свалку» различных записей. В таких системах лога наверное стоит работать DBA и разработчикам, а как быть тестировщикам и пользователям? В представленном вами «трейсфайле» много «воды», нужна конкретика: что сломалось, где и с какими параметрами. И когда представленными вами системами логирования будут активно пользоваться разработчики + тестировщики + пользователи, то убежден, что рано или поздно эти системы логирования видоизменятся до самой простой формы.
Могу лишь вас заверить, что представленная модель логирования это результат написания более 5 БД с активным логированием ошибок.
Что за базы? У каких клиентов я могу их увидеть? Какая из них самая нагруженная?
За основы брались упомянутые вами системы.
Ну вы же сами пишете, что не знали:
Спасибо за подсказку, если честно даже и не знал, что есть такой готовый продукт
тем более читаемый и предсказуемый результат вы получите на выходе (к этому мы пришли не сразу)
Что же такого нечитаемого и непредсказуемого вы делали до этого? Чем непредсказуемы или нечитаемы log4plsql или logger и куча других логгинг систем?
Представленная модель логирования это делает, а нужно ли больше? Это риторический вопрос.
По роду работы, мне приходится встречать самые разные ошибки, включая баги самого оракла. Например, могут быть проблемы даже с запуском автономной транзакции или записью в таблицу лога или аудита — в таких случаях ваша система ничего не запишет, хотя это критические ошибки. Не говоря уже о "плавающих" багах оракла, которые не воспроизводятся при тех же самых параметрах, и нужно получать processtate dump или даже systemstatedump.
К сожалению, это только мой опыт и моё суждение, но большинство разработчиков БД не станут писать логирование ошибок в своих БД если им об этом не сказать, к сожалению большинство из них не понимает зачем это делать.
Всё что вы описали оно все работает хорошо на демонстрационных примерах, а в реально действующей БД это не нужно.
Ну, право слово, я видел много разных больших систем, и еще пока не видел ни одной, где не было бы логгинга.
Комментарии к моим статьям это доказывают.
Не вижу, но вижу советы, на которые вы либо говорите, что это только пример, а в жизни у вас там все есть, либо что это не нужно. В целом же видно, что ваша система еще только развивается, код еще прилично сырой: куча хардкода, собственные нестандартные неинтуитивные именования, и тд. И не забудьте перейти на systimestamp, как вам уже посоветовали, т.к. sysdate — это слишком неточно. В крупных OLTP системах в секунду происходит огромное количество разных операций.
с помощью представленных вами SLF4j, log4j и его вариации для других языков/систем, и тд или Logger, то результат логирования с течением времени превращается в «свалку» различных записей.
Это как это вы сделали такой вывод? Пока я вижу потенциальную свалку как раз у вас, т.к. у вас на проде будет генерироваться все те же сообщения, что и на /dev/qa/etc. В то время как на проде сообщения trace/debug/info не нужны, кроме как для точечного траблшутинга.
В представленном вами «трейсфайле» много «воды», нужна конкретика: что сломалось, где и с какими параметрами.
каком трейсфайле? вы про "stack is: ..."? Это далеко не вода, это событийная система оракла, позволяющая вывести, что угодно, вплоть всех открытых курсоров, блокировок, латчей и мьютексов, внутренних переменных, дампов памяти, и тд. Более того, как было показано, это работает не только для ошибок, а вообще для всех Kernel events. Это совсем другой уровень и даже заголовок говорит "3. Что же делать в случае незалоггированных ошибок".
И в целом, резюмируя: я совсем не против ваших начинаний и даже одобряю — это этап, который надо пройти, поэтому не надо настраиваться негативно и отвергать советы, даже не взглянув и не изучив их. Например, вам посоветовали реализовать ротации логов: у промышленных систем он уже документированный и настраиваемый. Развивайте, совершенствуйте, учитывайте советы и пожелания, и, возможно, потом уже вашу систему будут рекомендовать другим.
поэтому не надо настраиваться негативно и отвергать советы
Я стараюсь отвечать на каждое сообщение и излагать свою точку зрения, да она может не совпадать с вашей (или другой). Суть всех статей не в том, чтобы выдать на всеобщее обозрение готовый продукт, который «скачал — установил — и в путь». Так не бывает, каждый проект, команда разработчиков, тимлиды, компания и т.д. все в совокупности дает индивидуальную реализацию. Иногда это качественный лог ошибок с многоуровневым логированием, а иногда его вовсе нет т.к. тимлид «не понимает зачем ему хранить тексты ошибок».
По мере развития своего видения модели логирования событий и пришел к выводу, чтоб «рабочая» модель логирования это максимально простой в использовании функционал как для разработчиков, так и для пользователей (тестировщиков). Именно его я и описал в статьях. В текущей модели есть проблемы и я их стараюсь учитывать «от проекта к проекту» и если однажды появится возможность написать новое логирование «с нуля» на каком-нибудь проекте, то он будет более совершенный чем предыдущие версии. Помимо простого функционала необходимо устанавливать определенные правила логирования ошибок (их я тоже постарался раскрыть). Говоря по простому, не важно каким логированием вы пользуетесь важно то, как его будут использовать в работе ваши коллеги.
Приведенные вами примеры логирования хорошо и удобны при точечном устранении ошибки. Использовать это в повседневной работе трудно. Лично я сомневаюсь, что кто-нибудь из читающих эту статью сможет реализовать описанное вами логирование в своем проекте.
А так в целом спасибо за советы.
Troubleshooting в Oracle