Настройка обнаружения сбоев в работе сервиса
Настройка обнаружения сбоев в работе сервиса
Система обнаружения ошибок Ключ-АСТРОМ автоматически выявляет подавляющее большинство ошибок в вашей среде, включая их первопричины. Благодаря такому подходу Ключ-АСТРОМ может предоставить вам ответы, когда возникают проблемы или когда снижается производительность вашего приложения.
Когда Ключ-АСТРОМ обнаруживает ошибку в работе сервиса, это не обязательно означает, что вы хотите пометить запрос как неудачный. Если настройки обнаружения ошибок сервиса по умолчанию вам не подходят, вы можете настроить параметры обнаружения сбоев, как описано на этой странице.
По умолчанию Ключ-АСТРОМ обнаруживает:
- В качестве причины сбоев запросов, приводящих к прерыванию вызовов сервиса, указываются программные исключения (Java, .NET, Node.js и PHP).
- Страницы ошибок, предоставляемые многими веб-контейнерами для обработанных исключений.
- HTTP
500–599коды ошибок для веб-запросов, интерпретируемые как ошибки на стороне сервера. - HTTP
400–599коды ошибок для веб-запросов, интерпретируемые как ошибки на стороне клиента.
Обнаруженные коды ошибок зависят от точки зрения:
- С точки зрения сервера,
5xxошибкой является только код ошибки, поскольку4xxкод означает ошибку на стороне клиента. - С точки зрения клиента, это
5xxвсе равно означает наличие ошибки, даже если она произошла не по вине клиента.
Настройки обнаружения сбоев
Вы можете настроить обнаружение сбоев глобально или для отдельных служб.
- При настройке параметров обнаружения сбоев на уровне сервиса они переопределяют глобальные настройки.
- Правила обнаружения сбоев оцениваются сверху вниз; применяется первое соответствующее правило. Если несколько правил обнаружения сбоев имеют одинаковые условия, применяется только первое соответствующее правило.
Следующие правила обнаружения сбоев не применяются к типам услуг:
- Сервис по обслуживанию трубопроводов
- Единая служба
Чтобы узнать больше об унифицированном обнаружении сбоев в работе сервисов, см. раздел «Унифицированные сервисы».
Глобальные настройки
Для глобальной настройки обнаружения сбоев в работе сервиса:
- Перейдите в Настройки и разверните раздел Мониторинг серверных служб.
- Чтобы добавить новое правило обнаружения сбоев, перейдите в раздел Правила обнаружения сбоев > Добавить правило обнаружения сбоев.
- Каждое правило может содержать несколько условий, основанных на заданных параметрах обнаружения сбоев. Вы можете использовать существующие параметры обнаружения сбоев для правил обнаружения сбоев или создавать новые.
- Чтобы добавить новый параметр обнаружения ошибок, перейдите в раздел Параметры обнаружения ошибок > Добавить параметры обнаружения ошибок. Для получения дополнительной информации см. разделы «Параметры», «Параметры HTTP» и «Общие параметры» ниже.
- Используйте переключатель Включено, чтобы включить или выключить правило.
- Ключ-АСТРОМ пересчитывает глобальные правила сопоставления каждые 10 минут.
Настройки уровня обслуживания
Вы также можете настроить обнаружение сбоев для отдельной службы. Для этого:
- Перейдите в раздел Сервисы Классика.
- Выберите сервис, для которого необходимо адаптировать систему обнаружения сбоев.
- Выберите Дополнительно (…) > Настройки.
- Выберите Обнаружение сбоев > Общие параметры или HTTP-параметры.
- Настройте нужные параметры.
Параметры
Параметры обнаружения ошибок включают в себя параметры, специфичные для HTTP, и общие параметры (связанные с исключениями, пользовательскими ошибками и обнаружением ошибок в протоколах). Хотя вы всегда можете получить доступ к общим параметрам как на глобальном уровне, так и на уровне сервиса, параметры обнаружения ошибок HTTP могут не отображаться на уровне сервиса, поскольку они видны только для определенных сервисов, таких как веб-запросы и веб-сервисы. Вы можете настроить их после включения параметра Переопределить глобальные параметры обнаружения ошибок, и даже если ни одно глобальное правило не соответствует сервису.
HTTP-параметры
| Параметр | Описание |
|---|---|
| коды ответов HTTP | HTTP-4XX коды ответов обычно указывают на ошибки на стороне клиента, а не на стороне сервера. Вы можете указать, какие отсутствующие коды ответов HTTP следует рассматривать как ошибки на стороне сервера, а какие — как ошибки на стороне клиента. Вы можете определить несколько диапазонов, разделенных запятыми (например, 400-402, 405-417).
В зависимости от вашего приложения, отсутствие кодов ответа может указывать на вызов типа «выполнить и забыть», который вообще не вернул ответ, на тайм-аут или на ошибку. Ключ-АСТРОМ рассматривает отсутствие кодов ответа как особый случай и не сообщает о них по умолчанию. Вы можете изменить это, включив параметр Обрабатывать отсутствие кода ответа HTTP как ошибки на стороне сервера или Обрабатывать отсутствие кода ответа HTTP как ошибки на стороне клиента. |
| HTTP 404 - неработающая ссылка (конфигурация) | Когда веб-сервер не может найти определенную страницу, он возвращает HTTP 404 код ответа. Обычно это указывает на проблему на стороне вызывающего сервера. Если вызывающая сторона принадлежит тому же веб-сайту, это будет считаться неработающей ссылкой.
Поскольку большинство клиентов не считают неработающие ссылки проблемой на своем сервере, Ключ-АСТРОМ классифицирует их как проблемы на стороне клиента, а не автоматически как сбои на стороне сервера. Однако вы можете включить параметр Рассматривать коды ответов HTTP 404 как сбои, чтобы классифицировать неработающие ссылки как сбои на стороне сервера. После этого вы можете связать дополнительные хосты в других доменах с вашим приложением, добавив имя хоста в разделе Добавить другой домен приложения. |
Общие параметры
| Параметр | Описание |
|---|---|
| Успех в создании исключений | Эти исключения указывают на то, что вызов сервиса не следует считать неудачным, например, потому что клиент прервал операцию. Хотя это технические ошибки, в принципе они не считаются неудачными запросами, поскольку не вызваны сбоями в работе сервиса. Если запрос встречает такое исключение в корневом вызове сервиса, Ключ-АСТРОМ считает запрос успешным, независимо от кода ошибки HTTP или любой другой информации. Вы можете выбрать Добавить исключение, чтобы добавить классы исключений, указывающие на такие ситуации. |
| Игнорируемые исключения | Бывают ситуации, когда ваш код (или код стороннего разработчика, который вы не контролируете) возвращает исключения, указывающие на определенный ответ, а не на ошибку. Например, клиент Thrift для Cassandra возвращает ответ NotFoundException, когда строка не найдена. Это не ошибка, а просто код ответа.
Вы можете выбрать Добавить исключение, чтобы настроить Ключ-АСТРОМ таким образом, чтобы он не рассматривал такие исключения как индикаторы неудачного запроса. Кроме того, вы можете определить строку, которая должна присутствовать в сообщении об исключении, чтобы оно было проигнорировано. Если код ответа HTTP для того же вызова показывает ошибку, Ключ-АСТРОМ считает запрос неудачным. Чтобы считать запрос успешным независимо от кода ошибки HTTP или любой другой информации, см. раздел «Успех: принудительное создание исключений». |
| Пользовательская обработка исключений | В некоторых ситуациях код приложения корректно обрабатывает исключения, но Ключ-АСТРОМ автоматически это не обнаруживает. В таких случаях Ключ-АСТРОМ не обнаруживает неудачные запросы и не оповещает об ошибках.
Подобные ситуации можно исправить, указав класс исключения, который должен привести к сбою запроса. При желании можно определить строку, которая должна присутствовать в сообщении об исключении. Если эта строка не найдена, исключение не приведет к сбою запроса. Если Ключ-АСТРОМ обнаружит определенное исключение (и, при желании, определенное сообщение об исключении) в запросе, Ключ-АСТРОМ пометит запрос как сбойный. Обратите внимание, что это не работает, если вы исключите класс исключения из отслеживания в настройках глубокого мониторинга процессов. |
| Игнорировать все исключения | Если включена опция Игнорировать все исключения, Ключ-АСТРОМ игнорирует исключения, связанные с принудительным выполнением, игнорированные исключения и пользовательские обработанные исключения для служб, к которым применяются параметры — для конкретной службы, если переключатель включен на уровне службы, или для служб, соответствующих глобальному правилу. Поскольку исключения по-прежнему отслеживаются, они отображаются в распределенных трассировках, но вы не получаете оповещения о них, и запросы не помечаются как неудачные. |
| Пользовательские ошибки через атрибуты запроса | Пользовательские ситуации с ошибками могут быть вызваны исключениями, но некоторые из них можно обнаружить только по возвращаемому значению или другими способами. Для поддержки таких случаев можно определить атрибут запроса, который собирает необходимые данные. Затем можно определить пользовательское правило обработки ошибок на основе атрибута запроса, которое проверяет значение атрибута запроса, чтобы определить, завершился ли запрос с ошибкой или нет. |
Пример: Использование атрибутов запроса для обнаружения ошибок, связанных с бизнес-логикой
Запросы могут завершаться с ошибкой по причинам, связанным с бизнес-логикой. Такие ситуации часто не обнаруживаются с помощью исключений или кодов ответа HTTP. Тем не менее, они указывают на проблемы и могут быть даже более важными, чем ситуации, обнаруженные с помощью исключений и кодов ответа. Например, в вашем Java-коде может быть бизнес-функция, которая указывает на ошибку с помощью возвращаемого значения, или у вас может быть собственная функция обработки ошибок, которая при вызове указывает на функциональную бизнес-ошибку.
Подобные ситуации можно зафиксировать с помощью атрибутов запроса, которые можно использовать в качестве индикаторов ошибок.
Для создания пользовательского правила обработки ошибок:
- Перейдите в раздел Сервисы Классика.
- Выберите сервис, для которого необходимо адаптировать систему обнаружения сбоев.
- Выберите Дополнительно (…) > Настройки.
- Выберите Обнаружение сбоев > Общие параметры.
- В разделе Пользовательские правила обработки ошибок выберите Добавить пользовательское правило обработки ошибок.
- Выберите атрибут запроса из отображаемого списка.
- Определите условие для правила, например,
содержити значение. - В приведенном ниже примере значение
-1атрибутаAmount of recommendationsуказывает на ошибку. Следуя этому правилу, если Ключ-АСТРОМ обнаружит такую ошибку, он пометит соответствующий запрос к сервису как неудачный и объяснит, что причиной сбоя является соответствие правилу.
Разрыв пролета
Функция обнаружения сбоев в трассировке портов специфична для OpenTelemetry. Ключ-АСТРОМ по умолчанию обнаруживает сбои в трассировке портов, но в некоторых случаях может потребоваться изменить эти настройки. Чтобы игнорировать обнаружение сбоев в трассировке портов, включите параметр Игнорировать обнаружение сбоев в трассировке портов.
Информация о схеме
На уровне сервиса вы можете просмотреть идентификатор схемы, выбрав Дополнительно (…) > Информация о схеме в правом верхнем углу страницы параметров HTTP или Общие параметры.
Справочник по API настроек
Вы также можете настроить параметры обнаружения сбоев через API Settings 2.0. Используйте следующие два идентификатора схемы:
| Идентификатор схемы | Описание |
|---|---|
builtin:failure-detection.environment.parameters |
Определяет наборы параметров обнаружения сбоев (коды HTTP-ответа, неработающие ссылки, правила обработки исключений). |
builtin:failure-detection.environment.rules |
Определяет правила, которые назначают наборы параметров сервисам на основе условий. |
Аутентификация
Вам потребуется токен доступа со следующими областями действия:
| Область | Операции |
|---|---|
settings.read |
Отображение списка и просмотр объектов настроек. |
settings.write |
Создавайте, обновляйте и удаляйте объекты настроек. |
Чтобы узнать, как получить и использовать токен доступа, см. раздел «API Ключ-АСТРОМ — Токены и аутентификация».
Наборы параметров обнаружения сбоев
API Settings 2.0 поддерживает четыре типа операций для наборов параметров обнаружения сбоев: GET, POST, PUT, и DELETE.
Перечислите все наборы параметров
Чтобы получить полный список всех определенных наборов параметров, используйте следующий запрос.
GET /api/v2/settings/objects?schemaIds=builtin:failure-detection.environment.parameters&scopes=environment
Просмотреть набор параметров
Для чтения содержимого отдельного набора параметров используйте GET запрос вместе с его уникальным значением objectId.
GET /api/v2/settings/objects/{objectId}
Идентификатор должен совпадать с UUID RFC 4122, присвоенным объекту настроек этого набора параметров.
Создайте набор параметров
Добавить новый набор параметров можно с помощью POST запроса, в теле которого указаны необходимые значения.
POST /api/v2/settings/objects
Пример тела запроса:
[
{
"schemaId": "builtin:failure-detection.environment.parameters",
"scope": "environment",
"value": {
"name": "Ignore known database errors",
"httpResponseCodes": {
"serverSideErrors": "500-599",
"failOnMissingResponseCodeServerSide": false,
"clientSideErrors": "401-402,405-499",
"failOnMissingResponseCodeClientSide": false
},
"brokenLinks": {
"http404NotFoundFailures": false
},
"exceptionRules": {
"ignoreAllExceptions": false,
"successForcingExceptions": [],
"ignoredExceptions": [
{
"classPattern": "psycopg2.errors.UniqueViolation",
"messagePattern": "duplicate key value violates unique constraint \"run_once_at_unique_identifier_and_timestamp\""
}
],
"customHandledExceptions": [],
"customErrorRules": [],
"ignoreSpanFailureDetection": false
}
}
}
]
|
Для пользовательских правил обработки ошибок каждая запись включает атрибут запроса и следующее условие:
{
"requestAttribute": "<request-attribute-object-id>",
"condition": {
"compareOperationType": "STRING_EQUALS",
"textValue": "error",
"caseSensitive": false
}
}
|
В ответе возвращается новый объект objectId, который может выглядеть следующим образом:
[
{
"code": 200,
"objectId": "vu9U3hXa3q0AAAABADBidWlsdGluOmZhaWx1cmUtZGV0ZWN0aW9uLmVudmlyb25tZW50LnBhcmFtZXRlcnMABnRlbmFudAAGdGVuYW50ACRlNWEwYjAyYi0zMDNlLTM2ZTEtOTMyNS0wMjM1YWNhMDc5MmO-71TeFdrerQ"
}
]
|
Затем вы можете использовать этот идентификатор напрямую для создания или обновления правила обнаружения сбоев.
Обновить набор параметров
Для изменения существующего набора параметров используйте тело запроса, аналогичное показанному в разделе «Создание». В URL-адресе укажите допустимый идентификатор объекта настроек.
PUT /api/v2/settings/objects/{objectId}
Используйте ту же структуру value, что и в разделе «Создать».
Удаление набора параметров
Чтобы удалить существующий набор параметров, сначала получите его идентификатор objectId, а затем выполните DELETE запрос, указав этот идентификатор.
DELETE /api/v2/settings/objects/{objectId}
Для получения информации о необязательных и обязательных параметрах, а также подробных сведений о типах, см. таблицу схемы параметров обнаружения сбоев в API настроек.
правила обнаружения сбоев
Правила обнаружения сбоев оцениваются сверху вниз; применяется первое совпадающее правило.
Перечислите все правила
Чтобы получить все определенные в данный момент правила обнаружения сбоев, используйте следующий запрос.
GET /api/v2/settings/objects?schemaIds=builtin:failure-detection.environment.rules&scopes=environment
Просмотреть правило
Для чтения одного правила обнаружения ошибок используйте GET запрос с правилом в качестве параметра пути objectId.
GET /api/v2/settings/objects/{objectId}
Создать правило
Добавить новое правило обнаружения ошибок можно с помощью POST запроса, в теле которого указаны необходимые атрибуты.
POST /api/v2/settings/objects
Поле parameterId должно содержать идентификатор объекта существующего набора параметров. По умолчанию новые правила добавляются в конец списка правил. Чтобы вставить правило в определенную позицию, укажите insertAfter идентификатор объекта предыдущего правила или пустую строку, чтобы поместить его в начало списка правил.
Пример тела запроса:
[
{
"schemaId": "builtin:failure-detection.environment.rules",
"scope": "environment",
"value": {
"name": "Ignore known database errors for automation-server",
"enabled": true,
"parameterId": "<object-id-of-parameter-set>",
"conditions": [
{
"attribute": "SERVICE_NAME",
"predicate": {
"predicateType": "STRING_EQUALS",
"textValues": [
"automation-server"
],
"caseSensitive": true
}
}
]
}
}
]
|
Обновить правило
Чтобы изменить существующее правило, используйте ту же структуру тела запроса, что и в разделе «Создать», и укажите идентификатор объекта настроек в URL-адресе.
PUT /api/v2/settings/objects/{objectId}
Используйте ту же структуру value, что и в разделе «Создать».
Удалить правило
Чтобы удалить существующее правило, сначала получите его идентификатор objectId; затем используйте DELETE запрос, указывающий этот идентификатор.
DELETE /api/v2/settings/objects/{objectId}
Правила переупорядочивания
Чтобы изменить порядок оценки правил обнаружения ошибок, обновите каждое правило, установив для поля insertAfter или insertBefore идентификатор объекта правила, которое должно предшествовать или следовать за ним. Чтобы поместить правило в начало списка правил, оставьте поле insertAfter пустым. Чтобы переместить его в конец списка правил, добавьте пустой атрибут insertBefore.
[
{
"schemaId": "builtin:failure-detection.environment.rules",
"scope": "environment",
"value": {
"name": "New top rule",
"...": "...",
"parameterId": "<object-id-of-a-parameter-set>",
"...": "..."
},
"insertAfter": ""
}
]
|
Для получения более подробной информации о допустимых типах и доступных параметрах, таких как поддерживаемые атрибуты условий, см. таблицу схемы правил обнаружения сбоев в API настроек.
Атрибуты условия
Каждое правило обнаружения ошибок содержит список условий. Для того чтобы правило сработало, должны быть выполнены все условия. Каждое условие проверяет атрибут группы служб или процессов с помощью предиката.
| Атрибут | Описание | Типы предикатов |
|---|---|---|
SERVICE_NAME |
Соответствует обнаруженному имени службы. | STRING_EQUALS, STARTS_WITH, ENDS_WITH, CONTAINS
|
SERVICE_TYPE |
Соответствует типу услуги. | SERVICE_TYPE_EQUALS
|
PG_NAME |
Соответствует имени группы процессов. | STRING_EQUALS, STARTS_WITH, ENDS_WITH, CONTAINS
|
PG_TAG |
Сопоставляет теги групп процессов. | TAG_EQUALS, TAG_KEY_EQUALS
|
SERVICE_MANAGEMENT_ZONE |
Соответствует зонам управления услугами. | MANAGEMENT_ZONES_CONTAINS_ALL
|
SERVICE_TAG |
Соответствует сервисным меткам. | TAG_EQUALS, TAG_KEY_EQUALS
|
В средах с последней версией Ключ-АСТРОМ SaaS атрибуты условий SERVICE_MANAGEMENT_ZONE и SERVICE_TAG больше недоступны, и правила обнаружения ошибок, использующие их, игнорируются во время выполнения.
Кроме того, атрибут условия PG_TAG больше не оценивается. Вместо этого вы можете использовать это поле для сопоставления на основе основных тегов, определенных при развертывании вашего приложения. Входные данные, начинающиеся с определенного префикса primary_tags., сопоставляются с основными тегами во входных данных.