Настройка обнаружения сбоев сервисов

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

Когда Dynatrace обнаруживает ошибку сервиса, это не обязательно означает, что вы хотите пометить запрос как неуспешный. Если настройки обнаружения ошибок сервисов по умолчанию не соответствуют вашим потребностям, вы можете настроить параметры обнаружения сбоев, как описано на этой странице.

По умолчанию Dynatrace обнаруживает:

• Программные исключения (Java, .NET, Node.js и PHP) как причину неуспешных запросов, когда исключения приводят к прерыванию вызовов сервиса.
• Страницы ошибок, предоставляемые многими веб-контейнерами для обработанных исключений.
• Коды ошибок HTTP 500–599 для веб-запросов, интерпретируемые как ошибки на стороне сервера.
• Коды ошибок HTTP 400–599 для веб-запросов, интерпретируемые как ошибки на стороне клиента.

Почему коды 5xx включены в клиентскую сторону?

Обнаруженные коды ошибок зависят от перспективы:

• С точки зрения сервера только код 5xx является ошибкой, поскольку код 4xx означает ошибку клиента.
• С точки зрения клиента код 5xx по-прежнему означает наличие ошибки, даже если она произошла не по вине клиента.

Настройки обнаружения сбоев

Вы можете настроить обнаружение сбоев глобально или для отдельных сервисов.

• При настройке обнаружения сбоев на уровне сервиса эти настройки переопределяют глобальную конфигурацию.
• Правила обнаружения сбоев оцениваются сверху вниз; применяется первое совпавшее правило. Если несколько правил обнаружения сбоев имеют одинаковые условия, применяется только первое совпавшее правило.

Следующие правила обнаружения сбоев не применяются к типам сервисов:

• Span service
• Unified service

Чтобы узнать больше об обнаружении сбоев для unified service, см. Unified services.

Глобальные настройки

Настройки на уровне сервиса

Настройка глобального обнаружения сбоев сервисов

1. Перейдите в Settings и разверните Server-side service monitoring.
2. Чтобы добавить новое правило обнаружения сбоев, перейдите в Failure detection rules > Add failure detection rule.

Каждое правило может иметь несколько условий, основанных на определённых параметрах обнаружения сбоев. Вы можете использовать существующие параметры обнаружения сбоев для правил или создать новые.

• Чтобы добавить новый параметр обнаружения сбоев, перейдите в Failure detection parameters > Add failure detection parameters. Подробнее см. разделы Параметры, HTTP-параметры и Общие параметры ниже.
• Используйте переключатель Enabled для включения или выключения правила.
• Dynatrace пересчитывает совпадение глобальных правил каждые 10 минут.

Настройка обнаружения сбоев для конкретного сервиса

1. Перейдите в Services Classic и выберите сервис, для которого необходимо настроить обнаружение сбоев.
2. Выберите More (…) > Settings.
3. Выберите Failure detection, затем HTTP parameters или General parameters в зависимости от параметров, которые вы хотите настроить.
4. Включите Override global failure detection settings (см. 1 на рисунке). Если применяется правило обнаружения сбоев, отсюда вы можете перейти как к правилу (см. 3 на рисунке), так и к параметрам (см. 2 на рисунке).

Параметры

Параметры обнаружения сбоев включают HTTP-специфичные параметры и общие параметры (связанные с исключениями, пользовательскими ошибками и обнаружением сбоев span). Общие параметры всегда доступны как глобально, так и на уровне сервиса, однако HTTP-параметры обнаружения сбоев могут быть не видны на уровне сервиса, так как они отображаются только для определённых сервисов, таких как веб-запросы и веб-сервисы. Вы можете настроить их после включения Override global failure detection settings (1 на рисунке), даже если ни одно глобальное правило не соответствует сервису.

HTTP-параметры

• Коды ответов HTTP

Коды ответов HTTP-4XX обычно указывают на ошибки на стороне клиента, а не на стороне сервера. Вы можете указать, какие отсутствующие коды ответов HTTP следует считать ошибками на стороне сервера, а какие — на стороне клиента. Вы можете определить несколько диапазонов, разделённых запятыми (например, 400-402, 405-417).

В зависимости от вашего приложения отсутствующие коды ответов могут указывать на вызов типа «отправил и забыл», который вообще не вернул ответ, на тайм-аут или на ошибку. Dynatrace рассматривает отсутствующие коды ответов как особые случаи и не сообщает о них по умолчанию. Вы можете изменить это поведение, включив Treat missing HTTP response code as server side errors или Treat missing HTTP response code as client side errors. * HTTP 404 — настройка битых ссылок

Когда веб-сервер не может найти определённую страницу, он возвращает код ответа HTTP 404. Обычно это указывает на проблему на стороне вызывающей стороны. Если вызывающая сторона принадлежит тому же веб-сайту, это считается битой ссылкой.

Поскольку большинство клиентов не считают битые ссылки проблемой на своём сервере, Dynatrace классифицирует битые ссылки как проблемы на стороне клиента и не рассматривает их автоматически как сбои на стороне сервера. Однако вы можете включить переключатель Consider 404 HTTP response codes as failures, чтобы классифицировать битые ссылки как сбои на стороне сервера. После этого вы можете связать дополнительные хосты других доменов с вашим приложением, добавив имя хоста в разделе Add other application domain.

Общие параметры

• Исключения, принудительно указывающие на успех (Success forcing exceptions)

Эти исключения указывают на то, что вызов сервиса не должен считаться неуспешным, например потому что клиент прервал операцию. Хотя они являются техническими ошибками, по сути они не считаются неуспешными запросами, поскольку не вызваны сбоями в работе сервиса. Если запрос сталкивается с таким исключением в корневом вызове сервиса, Dynatrace считает запрос успешным, независимо от кода ошибки HTTP или любой другой информации. Вы можете выбрать Add exception для добавления классов исключений, указывающих на такие ситуации. * Игнорируемые исключения

Существуют ситуации, когда ваш код (или сторонний код, который вы не контролируете) возвращает исключения, которые указывают на определённый ответ, а не на ошибку. Например, клиент Thrift для Cassandra возвращает NotFoundException, когда строка не найдена. Это не ошибка, а просто код ответа.

Вы можете выбрать Add exception, чтобы настроить Dynatrace не считать такие исключения индикаторами неуспешных запросов. Кроме того, вы можете определить строку, которая должна присутствовать в сообщении об исключении, чтобы исключение было проигнорировано. Если код ответа HTTP для того же вызова указывает на ошибку, Dynatrace считает запрос неуспешным. Чтобы считать запрос успешным независимо от кода ошибки HTTP или любой другой информации, см. Исключения, принудительно указывающие на успех (Success forcing exceptions). * Пользовательские обработанные исключения

Существуют ситуации, когда код приложения корректно обрабатывает исключения способом, который не обнаруживается автоматически Dynatrace. В этом случае Dynatrace не обнаруживает неуспешные запросы и не предупреждает вас об ошибках.

Вы можете исправить такие ситуации, указав класс исключения, который должен приводить к неуспешному запросу. При желании вы можете определить строку, которая должна присутствовать в сообщении об исключении. Если эта строка не найдена, исключение не приведёт к неуспешному запросу. Если Dynatrace находит определённое исключение (и опционально определённое сообщение об исключении) в запросе, Dynatrace помечает запрос как неуспешный. Обратите внимание, что это не работает, если вы исключили класс исключения из захвата в настройках глубокого мониторинга процессов. * Игнорирование всех исключений

Когда включена опция Ignore all exceptions, Dynatrace игнорирует Success forcing exceptions, Ignored Exceptions и Custom handled exceptions для сервисов, к которым применяются эти параметры — конкретного сервиса, если переключатель включён на уровне сервиса, или сервисов, соответствующих глобальному правилу. Поскольку исключения по-прежнему отслеживаются, они отображаются в распределённых трассировках, но вы не получаете оповещения о них, и запросы не помечаются как неуспешные. * Пользовательские ошибки через атрибуты запросов

Пользовательские ситуации ошибок могут быть вызваны исключениями, но некоторые из них обнаруживаются только по возвращаемому значению или другими способами. Для поддержки таких случаев вы можете определить атрибут запроса, который захватывает необходимые данные. Затем вы можете определить пользовательское правило ошибки на основе атрибута запроса, которое проверяет значение атрибута запроса для определения, является ли запрос неуспешным.

Пример: Использование атрибутов запросов для обнаружения ошибок бизнес-логики

Запросы могут завершаться неуспешно по причинам, связанным с бизнес-логикой. Такие ситуации часто не обнаруживаются через исключения или коды ответов HTTP. Тем не менее они указывают на проблемы и могут быть даже более важными, чем ситуации, обнаруженные через исключения и коды ответов. Например, у вас может быть бизнес-функция в вашем Java-коде, которая сигнализирует об ошибке через возвращаемое значение, или у вас может быть собственная функциональность обработки ошибок, которая при вызове указывает на функциональную бизнес-ошибку.

Такие ситуации могут быть захвачены через атрибуты запросов, которые вы можете использовать как индикаторы ошибочных ситуаций.

Создание пользовательского правила ошибки

1. Перейдите в Services Classic.
2. Выберите сервис, для которого необходимо настроить обнаружение сбоев.
3. Выберите More (…) > Settings.
4. Выберите Failure detection > General parameters.
5. В разделе Custom error rules выберите Add custom error rule.
6. Выберите атрибут запроса из отображаемого списка.
7. Определите условие для правила, например contains и значение.

В примере ниже значение -1 в атрибуте Amount of recommendations указывает на ошибку. Согласно этому правилу, если Dynatrace обнаруживает такую ошибку, он пометит соответствующий запрос сервиса как неуспешный и укажет совпадение правила как причину сбоя.

* Сбой span

Обнаружение сбоев span специфично для OpenTelemetry. По умолчанию Dynatrace обнаруживает сбои span, но существуют отдельные случаи, когда вы можете захотеть изменить эти настройки. Чтобы игнорировать обнаружение сбоев span, включите Ignore span failure detection.

Информация о схеме

На уровне сервиса вы можете отобразить Schema ID, выбрав More (…) > Schema info в верхнем правом углу страницы HTTP parameters или General parameters.

Связанные темы

• Атрибуты запросов
• Концепции анализа корневых причин
• API обнаружения сбоев