ENetrebin (обсуждение | вклад) Нет описания правки |
Нет описания правки |
||
(не показана 1 промежуточная версия этого же участника) | |||
Строка 1: | Строка 1: | ||
'''''[[Применение | '''''[[Применение АппОптима]] / Алертинг / События метрик''''' | ||
На этой странице описывается подход, доступный в версии | На этой странице описывается подход, доступный в версии АппОптима 1.253+. Описание для более старой версии см. [[События метрик, вызывающих оповещения]] . | ||
ИИ | ИИ АппОптима автоматически анализирует нештатные ситуации в вашей ИТ-инфраструктуре и пытается выявить любые соответствующие последствия и первопричины. ИИ опирается на широкий спектр источников информации, таких как представление транзакций ваших служб и приложений, а также все события, возникающие на отдельных узлах в вашей топологии. Одним из источников событий в АппОптима являются события метрик, то есть события, основанные на данных метрик. Они настраиваются в глобальных настройках вашей среды и видны всем пользователям АппОптима в вашей среде. Существует два типа событий метрик в зависимости от того, как метрика запрашивается для оценки события: | ||
* Ключ метрик . Ключевые события метрики оценивают входящие меры одной метрики. С этим типом запроса можно использовать только статические пороги. | * Ключ метрик . Ключевые события метрики оценивают входящие меры одной метрики. С этим типом запроса можно использовать только статические пороги. | ||
* Селектор показателей . События селектора показателей оценивают сложность запроса, определенный селектором . Этот тип запроса может включать исторические данные и даже арифметические операции с несколькими метриками. | * Селектор показателей . События селектора показателей оценивают сложность запроса, определенный селектором . Этот тип запроса может включать исторические данные и даже арифметические операции с несколькими метриками. | ||
АппОптима использует три стратегии мониторинга таких событий: | |||
* Статический порог — порог, который не меняется во времени. | * Статический порог — порог, который не меняется во времени. | ||
* Автоадаптивное пороговое значение — | * Автоадаптивное пороговое значение — АппОптима автоматически вычисляет пороговое значение и динамически адаптирует его к поведению вашей метрики. | ||
* Сезонный базовый уровень — | * Сезонный базовый уровень — АппОптима вычисляет доверительный интервал для метрики с сезонными закономерностями. | ||
* Автоадаптивные пороговые значения и базовый сезонный уровень доступны только для событий селектора метрик. | * Автоадаптивные пороговые значения и базовый сезонный уровень доступны только для событий селектора метрик. | ||
Строка 18: | Строка 18: | ||
== Продолжительность события == | == Продолжительность события == | ||
В конфигурации события метрики вы указываете, сколько одноминутных выборок должно превышать пороговое значение в течение определенного периода (скользящее окно). Когда достигается указанное количество нарушений, | В конфигурации события метрики вы указываете, сколько одноминутных выборок должно превышать пороговое значение в течение определенного периода (скользящее окно). Когда достигается указанное количество нарушений, АппОптима создает событие. Цель состоит в том, чтобы избежать чрезмерно агрессивного оповещения об одиночных нарушениях, избегая ситуаций, в которых каждое измерение, нарушающее пороговое значение, вызывает событие. | ||
Событие остается открытым до тех пор, пока метрика не останется в пределах порогового значения для определенного количества одноминутных выборок в одном и том же скользящем окне, после чего | Событие остается открытым до тех пор, пока метрика не останется в пределах порогового значения для определенного количества одноминутных выборок в одном и том же скользящем окне, после чего АппОптима закрывает событие. Сохранение события открытым помогает избежать чрезмерного оповещения, добавляя новые нарушения пороговых значений к существующей проблеме вместо того, чтобы создавать новую. | ||
Вы можете найти настройки для скользящего окна в разделе Дополнительные свойства модели конфигурации события метрики. По умолчанию любые три одноминутных семпла из пяти должны превысить ваш порог, чтобы вызвать событие; и пять одноминутных выборок должны вернуться к нормальному состоянию, чтобы закрыть это событие. Вы можете установить скользящее окно до 60 минут. Рассмотрим случай статического порога 90% загрузки ЦП. | Вы можете найти настройки для скользящего окна в разделе Дополнительные свойства модели конфигурации события метрики. По умолчанию любые три одноминутных семпла из пяти должны превысить ваш порог, чтобы вызвать событие; и пять одноминутных выборок должны вернуться к нормальному состоянию, чтобы закрыть это событие. Вы можете установить скользящее окно до 60 минут. Рассмотрим случай статического порога 90% загрузки ЦП. | ||
[[Файл:metr1.jpg]] | [[Файл:metr1.jpg|1081x1081пкс]] | ||
Анализ событий начинается с первого образца нарушения в скользящем окне. Как только количество нарушающих выборок достигает определенного порога, анализ событий останавливается, и возникает проблема. Несмотря на то, что анализ событий остановлен, само событие остается открытым до тех пор, пока не будут выполнены критерии деактивации: | Анализ событий начинается с первого образца нарушения в скользящем окне. Как только количество нарушающих выборок достигает определенного порога, анализ событий останавливается, и возникает проблема. Несмотря на то, что анализ событий остановлен, само событие остается открытым до тех пор, пока не будут выполнены критерии деактивации: | ||
Строка 37: | Строка 37: | ||
Пример | Пример | ||
[[Файл:metr2.jpg]] | [[Файл:metr2.jpg|1081x1081пкс]] | ||
== Серьезность события == | == Серьезность события == | ||
Строка 80: | Строка 80: | ||
== Зоны управления в метрических событиях == | == Зоны управления в метрических событиях == | ||
АппОптима версии 1.261+ | |||
Если у вас есть разрешения на уровне зоны управления, вы можете создавать конфигурации событий метрик, привязанные к этим зонам управления. Такие конфигурации используют только данные, поступающие из указанной зоны управления. Вы также можете просмотреть все конфигурации зоны управления, в которых используется зона управления, к которой у вас есть доступ. | Если у вас есть разрешения на уровне зоны управления, вы можете создавать конфигурации событий метрик, привязанные к этим зонам управления. Такие конфигурации используют только данные, поступающие из указанной зоны управления. Вы также можете просмотреть все конфигурации зоны управления, в которых используется зона управления, к которой у вас есть доступ. | ||
Строка 89: | Строка 89: | ||
== Осведомленность о топологии == | == Осведомленность о топологии == | ||
Осведомленность о топологии и контекст — ключевые темы платформы наблюдения | Осведомленность о топологии и контекст — ключевые темы платформы наблюдения АппОптима. Данные, такие как метрики, трассировки, события и логи, не просто регистрируются и сохраняются на платформе. Такие данные изобилуют ссылками на топологию, в которой они возникли. Например, в метриках процессов каждое измерение ссылается на связанные хосты и процессы. ИИ использует эту топологическую информацию для автоматического обнаружения первопричин и анализа влияния обнаруженных аномалий. То же самое относится ко всем событиям метрик в вашей среде. | ||
Когда конфигурация обнаружения аномалий вызывает событие, | Когда конфигурация обнаружения аномалий вызывает событие, АппОптима автоматически определяет наиболее релевантную сущность для сопоставления события. Если обнаружено несколько ссылок на объекты, автоматически выбирается наиболее релевантная. Например, если метрика, относящаяся как к узлу, так и к процессу, приводит к событию, событие возникает в процессе. | ||
Прием метрик позволяет отправлять все типы измерений метрик, независимо от количества объектов, к которым они относятся. Существуют следующие сценарии: | Прием метрик позволяет отправлять все типы измерений метрик, независимо от количества объектов, к которым они относятся. Существуют следующие сценарии: | ||
=== Измерения не связаны с каким-либо объектом === | === Измерения не связаны с каким-либо объектом === | ||
Если вы определяете событие метрики для нетопологической метрики, результирующее событие будет вызвано в самой среде мониторинга, а не в конкретном объекте | Если вы определяете событие метрики для нетопологической метрики, результирующее событие будет вызвано в самой среде мониторинга, а не в конкретном объекте. | ||
Пример: показатели выручки, измеренные для всех розничных магазинов по географическому региону. | Пример: показатели выручки, измеренные для всех розничных магазинов по географическому региону. | ||
< | <business.revenue,shop=shop111,city=NewYork 234 | ||
business.revenue,shop=shop999,city=Atlanta 499 | business.revenue,shop=shop999,city=Atlanta 499 | ||
=== Измерения относятся к одному объекту === | === Измерения относятся к одному объекту === | ||
Строка 106: | Строка 106: | ||
Пример: выполнение пакетных заданий измеряется на отслеживаемом узле, где измерение связано с узлом. | Пример: выполнение пакетных заданий измеряется на отслеживаемом узле, где измерение связано с узлом. | ||
< | <batchjob.executions,dt.entity.host=HOST-1111111,hostname=hostA,ip=53.43.23.12 23 | ||
batchjob.executions,dt.entity.host=HOST-2222222,hostname=hostB,ip=53.43.23.12 23 | batchjob.executions,dt.entity.host=HOST-2222222,hostname=hostB,ip=53.43.23.12 23 | ||
=== Измерения связаны с несколькими объектами === | === Измерения связаны с несколькими объектами === | ||
Когда для каждого измерения указано несколько объектов, | Когда для каждого измерения указано несколько объектов, АппОптима выбирает наиболее подходящий объект, для которого следует инициировать событие. В случае узла и процесса измерение предположительно относится к процессу, а не к узлу, поэтому событие возникает в процессе. | ||
Пример: количество запусков пакетного задания, измеренное для процесса на отслеживаемом узле, где измерение относится как к процессу, так и к узлу. | Пример: количество запусков пакетного задания, измеренное для процесса на отслеживаемом узле, где измерение относится как к процессу, так и к узлу. | ||
< | <batchjob.executions,dt.entity.host=HOST-1,dt.entity.process_group_instance=PROCESS-GROUP-INSTANCE-1,hostname=hostA,ip=53.43.23.12 23 | ||
batchjob.executions,dt.entity.host=HOST-2222222,dt.entity.process_group_instance=PROCESS-GROUP-INSTANCE-2,hostname=hostB,ip=53.43.23.12 23 | batchjob.executions,dt.entity.host=HOST-2222222,dt.entity.process_group_instance=PROCESS-GROUP-INSTANCE-2,hostname=hostB,ip=53.43.23.12 23 | ||
== Обзор событий метрики == | == Обзор событий метрики == | ||
АппОптима предоставляет обзор всех ваших метрических событий с информацией об ограничениях и сбоях метрических событий за последние 24 часа. Чтобы получить доступ к обзору, в меню АппОптима выберите '''Настройки > Обнаружение аномалий > События метрик''' . | |||
Обзор лимитов показывает, сколько каждого типа лимита было израсходовано. Ссылка для просмотра приведет вас к обозревателю данных с предварительно заполненным набором запросов для отображения наиболее ресурсоемких конфигураций. | Обзор лимитов показывает, сколько каждого типа лимита было израсходовано. Ссылка для просмотра приведет вас к обозревателю данных с предварительно заполненным набором запросов для отображения наиболее ресурсоемких конфигураций. |
Текущая версия от 13:22, 17 декабря 2024
Применение АппОптима / Алертинг / События метрик
На этой странице описывается подход, доступный в версии АппОптима 1.253+. Описание для более старой версии см. События метрик, вызывающих оповещения .
ИИ АппОптима автоматически анализирует нештатные ситуации в вашей ИТ-инфраструктуре и пытается выявить любые соответствующие последствия и первопричины. ИИ опирается на широкий спектр источников информации, таких как представление транзакций ваших служб и приложений, а также все события, возникающие на отдельных узлах в вашей топологии. Одним из источников событий в АппОптима являются события метрик, то есть события, основанные на данных метрик. Они настраиваются в глобальных настройках вашей среды и видны всем пользователям АппОптима в вашей среде. Существует два типа событий метрик в зависимости от того, как метрика запрашивается для оценки события:
- Ключ метрик . Ключевые события метрики оценивают входящие меры одной метрики. С этим типом запроса можно использовать только статические пороги.
- Селектор показателей . События селектора показателей оценивают сложность запроса, определенный селектором . Этот тип запроса может включать исторические данные и даже арифметические операции с несколькими метриками.
АппОптима использует три стратегии мониторинга таких событий:
- Статический порог — порог, который не меняется во времени.
- Автоадаптивное пороговое значение — АппОптима автоматически вычисляет пороговое значение и динамически адаптирует его к поведению вашей метрики.
- Сезонный базовый уровень — АппОптима вычисляет доверительный интервал для метрики с сезонными закономерностями.
- Автоадаптивные пороговые значения и базовый сезонный уровень доступны только для событий селектора метрик.
- Количество конфигураций события метрики (как ключа метрики, так и селектора метрики) ограничено 10 000 .
Продолжительность события
В конфигурации события метрики вы указываете, сколько одноминутных выборок должно превышать пороговое значение в течение определенного периода (скользящее окно). Когда достигается указанное количество нарушений, АппОптима создает событие. Цель состоит в том, чтобы избежать чрезмерно агрессивного оповещения об одиночных нарушениях, избегая ситуаций, в которых каждое измерение, нарушающее пороговое значение, вызывает событие.
Событие остается открытым до тех пор, пока метрика не останется в пределах порогового значения для определенного количества одноминутных выборок в одном и том же скользящем окне, после чего АппОптима закрывает событие. Сохранение события открытым помогает избежать чрезмерного оповещения, добавляя новые нарушения пороговых значений к существующей проблеме вместо того, чтобы создавать новую.
Вы можете найти настройки для скользящего окна в разделе Дополнительные свойства модели конфигурации события метрики. По умолчанию любые три одноминутных семпла из пяти должны превысить ваш порог, чтобы вызвать событие; и пять одноминутных выборок должны вернуться к нормальному состоянию, чтобы закрыть это событие. Вы можете установить скользящее окно до 60 минут. Рассмотрим случай статического порога 90% загрузки ЦП.
Анализ событий начинается с первого образца нарушения в скользящем окне. Как только количество нарушающих выборок достигает определенного порога, анализ событий останавливается, и возникает проблема. Несмотря на то, что анализ событий остановлен, само событие остается открытым до тех пор, пока не будут выполнены критерии деактивации:
- Количество нарушающих выборок должно быть меньше, чем число, при котором возникает проблема.
- Количество «нормальных» выборок должно быть больше или равно количеству деактивирующих проб.
Оба критерия должны быть выполнены, чтобы закрыть событие.
Числа по умолчанию (3 образца нарушения в скользящем окне из 5 образцов для запуска проблемы, 5 образцов отмены оповещения для закрытия события) хорошо подходят для большинства событий метрик. Однако может потребоваться их обновление (например, из-за "шума" в измерениях). Предварительный просмотр события метрики обеспечивает визуальное представление поведения вашего события. Вы можете настроить параметры скользящего окна, чтобы увидеть, как они влияют на конфигурацию вашего мероприятия.
Пример
Серьезность события
Серьезность события определяет, следует ли поднимать проблему и должен ли ИИ определять основную причину данного события.
Строгость | Проблема поднята | Анализ ИИ | Семантически |
---|---|---|---|
Доступность | Да | Да | Сообщает о любых серьезных отказах компонентов. |
Ошибка | Да | Да | Сообщает о любом ухудшении работоспособности из-за ошибок. |
Замедление | Да | Да | Сообщает о замедлении работы ИТ-компонента. |
Ресурс | Да | Да | Сообщает о нехватке ресурсов или ситуации конфликта ресурсов. |
Информация | Нет | Да | Сообщает о любой интересной ситуации с компонентом, например об изменении развертывания. |
Пользовательское оповещение | Да | Нет | Запускает оповещение без причинно-следственной связи с участием искусственного интеллекта Дэвиса. |
Дополнительные сведения о встроенных событиях и их уровнях серьезности см. в разделе Типы событий .
Зоны управления в метрических событиях
АппОптима версии 1.261+
Если у вас есть разрешения на уровне зоны управления, вы можете создавать конфигурации событий метрик, привязанные к этим зонам управления. Такие конфигурации используют только данные, поступающие из указанной зоны управления. Вы также можете просмотреть все конфигурации зоны управления, в которых используется зона управления, к которой у вас есть доступ.
Для создания событий метрик без областей зоны управления вам необходим доступ администратора.
Зоны управления, настроенные с помощью правил многомерных данных , не поддерживаются для событий метрик.
Осведомленность о топологии
Осведомленность о топологии и контекст — ключевые темы платформы наблюдения АппОптима. Данные, такие как метрики, трассировки, события и логи, не просто регистрируются и сохраняются на платформе. Такие данные изобилуют ссылками на топологию, в которой они возникли. Например, в метриках процессов каждое измерение ссылается на связанные хосты и процессы. ИИ использует эту топологическую информацию для автоматического обнаружения первопричин и анализа влияния обнаруженных аномалий. То же самое относится ко всем событиям метрик в вашей среде.
Когда конфигурация обнаружения аномалий вызывает событие, АппОптима автоматически определяет наиболее релевантную сущность для сопоставления события. Если обнаружено несколько ссылок на объекты, автоматически выбирается наиболее релевантная. Например, если метрика, относящаяся как к узлу, так и к процессу, приводит к событию, событие возникает в процессе.
Прием метрик позволяет отправлять все типы измерений метрик, независимо от количества объектов, к которым они относятся. Существуют следующие сценарии:
Измерения не связаны с каким-либо объектом
Если вы определяете событие метрики для нетопологической метрики, результирующее событие будет вызвано в самой среде мониторинга, а не в конкретном объекте.
Пример: показатели выручки, измеренные для всех розничных магазинов по географическому региону.
<business.revenue,shop=shop111,city=NewYork 234 business.revenue,shop=shop999,city=Atlanta 499
Измерения относятся к одному объекту
Если вы определяете событие метрики для измерения, связанного с одним объектом, результирующее событие будет вызвано для этого объекта.
Пример: выполнение пакетных заданий измеряется на отслеживаемом узле, где измерение связано с узлом.
<batchjob.executions,dt.entity.host=HOST-1111111,hostname=hostA,ip=53.43.23.12 23 batchjob.executions,dt.entity.host=HOST-2222222,hostname=hostB,ip=53.43.23.12 23
Измерения связаны с несколькими объектами
Когда для каждого измерения указано несколько объектов, АппОптима выбирает наиболее подходящий объект, для которого следует инициировать событие. В случае узла и процесса измерение предположительно относится к процессу, а не к узлу, поэтому событие возникает в процессе.
Пример: количество запусков пакетного задания, измеренное для процесса на отслеживаемом узле, где измерение относится как к процессу, так и к узлу.
<batchjob.executions,dt.entity.host=HOST-1,dt.entity.process_group_instance=PROCESS-GROUP-INSTANCE-1,hostname=hostA,ip=53.43.23.12 23 batchjob.executions,dt.entity.host=HOST-2222222,dt.entity.process_group_instance=PROCESS-GROUP-INSTANCE-2,hostname=hostB,ip=53.43.23.12 23
Обзор событий метрики
АппОптима предоставляет обзор всех ваших метрических событий с информацией об ограничениях и сбоях метрических событий за последние 24 часа. Чтобы получить доступ к обзору, в меню АппОптима выберите Настройки > Обнаружение аномалий > События метрик .
Обзор лимитов показывает, сколько каждого типа лимита было израсходовано. Ссылка для просмотра приведет вас к обозревателю данных с предварительно заполненным набором запросов для отображения наиболее ресурсоемких конфигураций.
Обзор событий метрик включает конфигурации, в которых возникли проблемы за последние 24 часа. Отслеживаемые проблемы включают в себя:
THROTTLED
: Конфигурация достигла пределов запроса селектора показателей.QUERY_FAILED
: Ошибка запроса метрики конфигурации. Вот несколько возможных причин сбоя запроса:- Зоны управления или теги больше не доступны.
- Данные показателей больше не доступны.
- Запрошенные данные недоступны в 1-минутном разрешении.