Как отслеживать и сохранять события от перехваченных исключений или зарегистрированных отклонений обработки данных? - PullRequest
Новая
       10

Как отслеживать и сохранять события от перехваченных исключений или зарегистрированных отклонений обработки данных?

0 голосов
/ 20 июля 2011

Допустим, есть события, которые могут произойти (менее вероятно), но они должны быть зарегистрированы.Это данные, которые просто необходимы для настройки ... чтобы увидеть, что произошло и что нужно изменить и улучшить.

Обычно это делается в блоках перехвата, когда генерируется исключение, или просто, если некоторые, если условие проходит,

Я не хочу писать сценарии оболочки и собирать данные из журналов, поэтому я могу использовать БД и создать таблицу для каждого контекста, что возможно в большинстве случаев, но это крайне неудобно для обслуживания и рефакторингав дальнейшем развитии.Тем более, что данные будут напечатаны как RDB.В основном, единственными общими данными являются userId, время, компонент и различные данные, такие как fileId, fileSize ||elementsCount, count deviance ||и т. д.

Или я могу использовать для этого какое-то хранилище nosql, что также немного излишне, потому что данные носят тип, свободный от типов, и я думаю, это было бы более удобно.

Не могли бы вы объяснить, как вы это делаете?Как это вообще называется?Я думаю, что JMX не справляется с этим сценарием.Spring AOP или AOP в целом имеют дело только с распределенным характером этого.

1 Ответ

1 голос
/ 20 июля 2011

Похоже, у вас есть два отдельных вопроса:

  1. Как мне запечатлеть определенные события?
  2. Что мне делать с событиями после их захвата?

Что касается 1, то AOP является довольно распространенным решением для захвата событий. Я не уверен, что вы подразумеваете под «АОП в целом имеет дело только с распределенной природой этого». Там нет ничего распространено о АОП. Вы недостаточно рассказали нам о своем приложении, чтобы кто-нибудь сказал, как максимально легко интегрировать AOP и т. Д., Но много информации доступно онлайн .

Относительно 2, о каком количестве данных мы говорим? Сколько информации вы хотите хранить на каждом мероприятии? Что похоже / отличается в каждом сообщении? Я бы, вероятно, выбрал следующий подход:

  • Определите, сколько данных вы собираетесь сохранить в течение любой заданной секунды, минуты, часа, дня и т. Д. Если он достаточно мал, чтобы поместиться в одну из ваших существующих баз данных, то не усложняйте свою среду, вводя новая технология.
  • Можно ли загружать данные синхронно? Если да, то это легко. В противном случае, я бы, вероятно, регистрировал данные и периодически их консолидировал с помощью простого сценария ETL. Это, вероятно, будет намного проще и дешевле, чем создание нового магазина nosql, которого у вас сейчас нет в производстве.
  • Решите, какие данные вы хотите сохранить. Вероятно, это будет выглядеть примерно так: идентификатор, тип, метка времени, источник (например, сервер или экземпляр приложения), подробности. Детали должны быть специфичными для типа.
  • Определите, какие типы запросов или отчетов вы хотите запускать для данных.
  • Вам нужно структурировать специфичные для типа вещи так, чтобы конкретные запросы были возможны? Можете ли вы хранить специфичные для типа вещи в документе XML или JSON и анализировать их только в отчетах для конкретных типов? Или вам нужно ссылаться на специфические для типа вещи в самих запросах? Детали, специфичные для типа, могут усложнять запросы, но база данных nosql, такая как mongodb, может действительно помочь здесь.
  • Определите вашу политику хранения данных. Вы, вероятно, должны очистить старые данные в какой-то момент. Это может повлиять на дизайн вашего хранилища.
...