Наблюдаемость системы предоставляет инструменты для выполнения следующих типов задач:
Регистрация информации о событиях, происходящих в системе
Получение метрик производительности системы как в один момент времени, так и за определённый период времени
Отслеживание запросов по мере их прохождения через систему
Информирование операторов системы о состоянии системы
Прогнозирование будущей производительности системы
Обнаружение первопричины наблюдаемых проблем в системе
Телеметрические решения позволяют собирать журналы, метрики и трассировки. Решения для мониторинга повышают осведомлённость о телеметрических данных, предоставляя панели управления и оповещая администраторов, когда система работает вне заранее установленных порогов. Полная наблюдаемость системы расширяет решения для телеметрии и мониторинга, позволяя осуществлять прогнозирование и анализ первопричин.
Прогнозирование включает использование имеющейся информации о прошлой и текущей производительности системы для определения её вероятной будущей производительности. Прогнозирование поможет вам принимать решения об изменениях в вашей системе. Например, если вы прогнозируете значительное увеличение числа запросов к сервисам карты, вы можете решить добавить дополнительную машину на ваш сайт ArcGIS Server до того, как пользователи увидят снижение производительности из-за ограничений ресурсов.
Наблюдение за закономерностями или тенденциями в телеметрических данных помогает делать прогнозы. Например, циклические закономерности для метрик позволяют предсказывать моменты, когда будут наступать пики и падения этих метрик. Сильные восходящие или нисходящие тенденции позволяют прогнозировать будущие значения при предположении, что тренд продолжится.
Предиктивный анализ может выполняться администраторами, но всё более совершенные возможности искусственного интеллекта (ИИ) создают возможность системы, способной анализировать себя и адекватно реагировать. Агенты ИИ с доступом к телеметрии, разрешением на изменение системы и надёжной моделью обучения для определения соответствующих действий могут поддерживать стабильность системы с минимальным прямым вмешательством человека. Как и с любым типом ИИ, будьте осторожны при внедрении автоматизированной системы реагирования, чтобы убедиться, что она соответствует вашим приоритетам и ценностям.
Если ваша система неисправна, вам нужно знать первопричину, чтобы реализовать подходящее решение. Например, увеличение задержки сервиса может потребовать дорогостоящего обновления инфраструктуры для разрешения проблемы, или это может быть исправлено простой реконфигурацией сервиса.
Анализ первопричин состоит из шести этапов:
Обнаружить проблему. Например, ваше решение для мониторинга может предупредить вас, что время отклика сервиса превысило заранее установленный порог. Для проблем, которые ваше решение мониторинга не предвидело, вы можете получать сообщения от пользователей о том, что система работает неправильно.
Провести первичную оценку проблемы. Определите, касается ли проблема только одного сервиса или это системная проблема, затрагивающая несколько сервисов. Инструменты мониторинга, такие как операционные панели, карты сервисов и проверки работоспособности, полезны на данном этапе для определения масштаба проблемы.
Исследовать проблему с помощью телеметрических данных.
Метрики могут помочь выявить аномалии или нарушения порогов, такие как внезапный скачок ошибок 500 или снижение пропускной способности.
Ищите в журналах сообщения об error , трассировки стеков и предупреждения. Структурированное журналирование помогает сопоставлять записи журнала с конкретными идентификаторами запросов или временными метками, что помогает сузить поиск релевантных сообщений журнала.
Трассировки могут точно определить, где запросы испытывали задержку или сбои. Например, трассировка может показывать медленный запрос к базе данных или неудачный вызов API.
Сопоставить и добавить контекст к данным. Комбинируйте метрики, журналы и трассировки для построения хронологии наблюдаемых событий. Например, может быть, медленный запрос к базе данных, показанный в трассировке, произошёл одновременно с резким скачком метрики загрузки CPU на машине, где находится база данных. Сторонние инструменты, такие как OpenTelemetry, Jaeger или Datadog APM, могут быть полезны для корреляции различных источников данных.
Определить первопричину. Ищите изменения в вашей системе, которые могут объяснить наблюдаемые корреляции. Некоторые распространённые причины включают:
Недавние изменения в развертывании или конфигурации
Истощение ресурсов, например, утечка памяти
Сбои внешних зависимостей, например, неудачный ответ от стороннего API
Сетевые проблемы, такие как изменение правил межсетевого экрана
Решить проблему. Внедрите подходящее решение, исходя из того, что вы определили первопричиной. Например, вам может понадобиться откатить недавние изменения конфигурации, обновить программное обеспечение или масштабировать сервисы. Однако просто исправить текущую проблему недостаточно. Документируйте проблему, свой анализ и решение, чтобы другие могли легче решать подобные вопросы в будущем. Добавьте оповещения, операционные панели или автоматические тесты, чтобы предотвратить повторение проблемы.