|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Имеется таблица в БД, в которую пишутся последовательно различные события некоторого сервиса, в том числе "парные" типа "Ошибка" - "Нет ошибки". Необходимо выполнить поиск всех ошибок и продолжительности их существования. Задача усложняется тем, что событие "Ошибка" может появляться несколько раз по факту обращения к сервису. service_idtimestampstatus12015-01-01 00:00:00Error22015-01-02 00:00:14Error12015-01-01 00:01:50Error12015-01-01 00:03:20Ok22015-01-02 00:05:00Ok В приведенной выше таблице для сервиса с service_id = "1" в 2015-01-01 00:00:00 произошло событие Error, далее в 2015-01-01 00:01:50 было обращение к тому же сервису, и так как ошибка еще не устранена, в таблицу вновь внесена запись об ошибке. В 2015-01-01 00:03:20 ошибка была устранена. Итого мы имеем по сервису с service_id = "1" одну проблему, которая возникла в 2015-01-01 00:00:00 и была устранена в 2015-01-01 00:03:20. Простой, соответственно 3 минуты 20 секунд. Я задался целью написать универсальный алгоритм, так как ничего готового не нашел. Возможно,я плохо искал, и кто-то знает где велосипед "зарыт"? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 11:07 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
версия сервера какая? так-то с 12-й можно и всякие там LEAD/LAG/ROW_NUMBER-а прикрутить... если же сильно древнее, то только старомодными not exists + first ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 12:21 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
если сервер не поддерживает OLAP-функции, то решение (схематично, ибо сервера и данных под рукой нет) будет примерно таким (с возможными "вариациями на тему"): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
если же сервер вполне себе современнен, то решение будет сильно проще: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 12:50 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
оу, кажись даты кончал немного неправильно будут считаться... нужно же брать первую дату после смены статуса, а не последнюю дату текущего статуса... но, думаю, сам исправить сможешь при желании. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 12:58 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эх, Да я потому версию и не приводил, чтобы алгоритм написать универсальный. У меня live-система на Oracle, архивные данные сливаются на Informix 11. В зависимости от ситуации, приходится выбирать данные либо из боевой системы, либо с архива. Пока получилось написать только с помощью вложенного запроса и связывать таблицу саму с собой. Бился долго, но есть сомнения, что можно написать более удачный алгоритм. Хотя этот тоже работает, может кому и пригодится.. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Содержимое таблицы service_idtimestampstatus126/02/2015Error127/02/2015Error228/02/2015Error102/03/2015Ok203/03/2015Ok Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Результат service_idstart_timefinish_time126/02/201502/03/2015 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 13:01 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эхоу, кажись даты кончал немного неправильно будут считаться... нужно же брать первую дату после смены статуса, а не последнюю дату текущего статуса... но, думаю, сам исправить сможешь при желании. :) Насколько я понимаю, ваш вариант ищет начала и кончала как первое и последнее время каждого типа события. Т.е. для Error начало = первое время для Error и кончало = последнее время для Error и аналигично для "Ок". Поправьте, если я не прав. Моя же цель - найти первое время "плохого" события и первое после него время "хорошего" события. Т.е. первый Error и первый после него "Ок". ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 13:22 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
sir.ilgizНасколько я понимаю, ваш вариант ищет начала и кончала как первое и последнее время каждого типа событиявс ё верно. так оно и есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 13:25 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эх, спасибо за работу. Вопрос еще актуален ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 15:50 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эхsir.ilgizНасколько я понимаю, ваш вариант ищет начала и кончала как первое и последнее время каждого типа событиявс ё верно. так оно и есть.но оба варианта можно допилить под требования автора... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 16:01 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
sir.ilgizВопрос еще актуаленСформулируй его ещё раз. А то я потерял нить твоей мысли... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 16:03 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эх, Извини, я, наверное, запутал. Итак, у меня есть несколько сервисов, которые пишут логи в одну таблицу. Если упростить, при ошибке пишется "Error", при ее устранении пишется "Ok". При этом, если после возникновения ошибки был повторный запрос к сервису, он отправит в ответ ошибку и в логи запишет еще одно событие "Error". Таким образом, последовательность событий может быть "Error" - "Error" - "Error" - "Ok". В этом случае с момента первого "Error" и до первого "Ok" сервис простаивает. Таблица лога в этом случае следующая: service_idtimestampstatus126/02/2015Error127/02/2015Error228/02/2015Error102/03/2015Ok203/03/2015Ok Для каждого сервиса надо найти момент возникновения ошибки и момент ее устранения. Здесь: а) для сервиса service_id=1 была одна ошибка, которая возникла 26/02/2015 и была устранена 02/03/2015 б) для сервиса service_id=2 была одна ошибка, которая возникла 28/02/2015 и была устранена 03/03/2015. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 18:45 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
sir.ilgiz, И запрос не должен содержать серверно-зависимых решений, так как работать запрос будет и в оракле, и в информиксе? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 19:41 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
sir.ilgiz Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Дык вполне рабочий запрос, в чём вопрос... Через подзапросы будет не лучше... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 20:00 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
Добрый Э - Эхsir.ilgiz, И запрос не должен содержать серверно-зависимых решений, так как работать запрос будет и в оракле, и в информиксе? В точку :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 22:11 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
АнатоЛойДык вполне рабочий запрос, в чём вопрос... Через подзапросы будет не лучше... Та я просто не так опытен, потому, естественно, меня гложат сомнения в оптимальности. Может изобрёл велосипед, а может есть более "правильное" решение. Так как подразумевается анализ логов, объем данных будет большой (over 1000 сервисов, что даёт до 10-15 млн записей каждый месяц). Да и алгоритм может пригодиться для других задач, которые сейчас никто не хочет решать именно по причине больших объёмов данных и отсутствия простого решения ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2015, 22:18 |
|
Поиск "открывающих" и "закрывающих" событий в логах
|
|||
---|---|---|---|
#18+
sir.ilgizАнатоЛойДык вполне рабочий запрос, в чём вопрос... Через подзапросы будет не лучше... Та я просто не так опытен, потому, естественно, меня гложат сомнения в оптимальности. Может изобрёл велосипед, а может есть более "правильное" решение. Так как подразумевается анализ логов, объем данных будет большой (over 1000 сервисов, что даёт до 10-15 млн записей каждый месяц). Да и алгоритм может пригодиться для других задач, которые сейчас никто не хочет решать именно по причине больших объёмов данных и отсутствия простого решения Если оптимизатор не облажается, эффективнее не сделаешь. Ну и индексы если сам не провтыкаешь. Эффективнее будет только не универсальное решение с однопроходной хранимкой на курсоре будет... ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2015, 00:26 |
|
|
start [/forum/topic.php?fid=44&msg=38894211&tid=1606894]: |
0ms |
get settings: |
17ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
35ms |
get topic data: |
2ms |
get forum data: |
1ms |
get page messages: |
288ms |
get tp. blocked users: |
1ms |
others: | 375ms |
total: | 727ms |
0 / 0 |