Моя задача напрямую к забиксу отношения не имеет, прощу прощения, но в какой то мере она очень близка к оценке качества чего-либо, поэтому решил спросить совета.
Требуется определить "моргание" по статусу сервиса. Статус это просто 0 или 1. Сложность в том что бы детектировать именно периодический процесс. Проще описать на примере:
для начала возьмем некий интервал времени, допустим 60 секунд
если сервис пропадал на 5, 15, 25, 35, 55 секундах, то это периодика, с сервисом проблемы
если сервис пропадал на 5, 7, 9, 10, 14, 15 секундах, то пока дергаться рано, надо оценивать больший интервал времени, так как возможно проблема была единичной и в дальнейшем сервис пропадать не будет.
Если кто то знает некую методику просьба подсказать. Алгоритмы-костыли я могу и сам придумать, только в моем случае вероятность ложных срабатываний должна быть минимальной. Может есть какие то "оценки" вроде mos/icpif с некоторой инертностью?
P.s. Для тех кто решил дочитать и возможно что то предложить я еще немного поясню пример. Допустим у меня было несколько пропаданий сервиса по 1 секунде в течении 60 секунд: на 10, 25, 35, 55 секундах - это не совсем проблема. Ну в моем случае, это плохо, но сервис будет в этом случае работать. Если же интервалы "нулей" увеличить: с 10 по 12 секунды, с 25 по 28, с 35 по 36, с 55 по 57, то это означает что сервис рухнул и по сути все 60 секунд сервиса не было, надо переходить на резерв. Как я писал уже выше, если пропадания сервиса были в некий "компактный промежуток" времени, то ждем дальше, а следовательно алгоритм должен в такой ситуации перейти в режим оценки большего интервала времени. Что бы было понятно, "переход на резерв" в моей задаче процесс сложный, долгий и не факт что резерв в данный момент вообще доступен, а следовательно при ложных срабатываниях алгоритма я могу плохо работающий сервис превратить в полное его отсутствие, попутно еще и лишившись удаленного доступа.
Требуется определить "моргание" по статусу сервиса. Статус это просто 0 или 1. Сложность в том что бы детектировать именно периодический процесс. Проще описать на примере:
для начала возьмем некий интервал времени, допустим 60 секунд
если сервис пропадал на 5, 15, 25, 35, 55 секундах, то это периодика, с сервисом проблемы
если сервис пропадал на 5, 7, 9, 10, 14, 15 секундах, то пока дергаться рано, надо оценивать больший интервал времени, так как возможно проблема была единичной и в дальнейшем сервис пропадать не будет.
Если кто то знает некую методику просьба подсказать. Алгоритмы-костыли я могу и сам придумать, только в моем случае вероятность ложных срабатываний должна быть минимальной. Может есть какие то "оценки" вроде mos/icpif с некоторой инертностью?
P.s. Для тех кто решил дочитать и возможно что то предложить я еще немного поясню пример. Допустим у меня было несколько пропаданий сервиса по 1 секунде в течении 60 секунд: на 10, 25, 35, 55 секундах - это не совсем проблема. Ну в моем случае, это плохо, но сервис будет в этом случае работать. Если же интервалы "нулей" увеличить: с 10 по 12 секунды, с 25 по 28, с 35 по 36, с 55 по 57, то это означает что сервис рухнул и по сути все 60 секунд сервиса не было, надо переходить на резерв. Как я писал уже выше, если пропадания сервиса были в некий "компактный промежуток" времени, то ждем дальше, а следовательно алгоритм должен в такой ситуации перейти в режим оценки большего интервала времени. Что бы было понятно, "переход на резерв" в моей задаче процесс сложный, долгий и не факт что резерв в данный момент вообще доступен, а следовательно при ложных срабатываниях алгоритма я могу плохо работающий сервис превратить в полное его отсутствие, попутно еще и лишившись удаленного доступа.
Comment