Создание пользовательских панелей мониторинга для служб без серверов

Бессерверные вычисления изменили то, как команды создают и развертывают приложения, предлагая почти бесконечные масштабируемость и ценообразование с оплатой за выполнение. Но те же характеристики, которые делают бессерверные привлекательными - кратковременные среды выполнения, автоматическое масштабирование и сильно распределенная архитектура - создают значительные слепые пятна мониторинга. Без специально построенной панели мониторинга команды изо всех сил пытаются соотнести один пользовательский запрос с десятками вызовов функций, обнаружить задержку холодного запуска или понять драйверы затрат. Стандартные панели облачных консолей обеспечивают высокоуровневый вид, но они редко удовлетворяют конкретные операционные потребности каждой команды. Вот почему создание пользовательских панелей мониторинга для бессерверных служб стало важной практикой для поддержания надежности, оптимизации производительности и контроля расходов на облако.

Уникальные проблемы мониторинга бессерверных вычислений

Функции без сервера не имеют состояния и эфемерны. Функция AWS Lambda может работать в течение нескольких сотен миллисекунд, а затем исчезать. Эта преходящая природа затрудняет агрегирование показателей по вызовам, особенно когда функции вызваны событиями из нескольких источников. Среда выполнения также разделена, что означает, что холодные запуски - задержка, когда новый экземпляр функции вращается - может ввести непредсказуемую задержку. Традиционный мониторинг сервера, который опирается на длительные процессы и фиксированную инфраструктуру, просто не применяется.

Кроме того, безсерверные архитектуры часто включают в себя множество небольших, слабо связанных сервисов. Отслеживание транзакции через API Gateway, Lambda, DynamoDB и Step Functions требует распределенных инструментов отслеживания. Без консолидированной панели мониторинга инженеры тратят время на переход между отдельными интерфейсами мониторинга. Пользовательская панель решает эту проблему, извлекая метрики из нескольких облачных сервисов, сторонних инструментов мониторинга и приложений в одном согласованном виде.

Почему общие панели инструментов падают

Облачные провайдеры, такие как AWS, Azure и Google Cloud, предлагают предварительно построенные панели мониторинга для своих бессерверных сервисов. Например, AWS CloudWatch предоставляет панель вызовов Lambda с подсчетом вызовов, частотой ошибок и процентилями продолжительности. Хотя они полезны для быстрой проверки здоровья, эти общие панели мониторинга имеют несколько ограничений:

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

Основные метрики Каждая бессерверная панель мониторинга должна отслеживать

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

Строительные блоки пользовательской панели мониторинга

Надежная пользовательская панель приборов опирается на четыре столпа: сбор данных, хранение, визуализация и оповещение. Каждый блок должен быть тщательно выбран и настроен для поддержки рабочих нагрузок без сервера.

Сбор данных

Бессерверные функции выдают метрики и журналы через собственные службы мониторинга облачного провайдера (CloudWatch, Azure Monitor, Google Cloud Monitoring). Кроме того, вы можете использовать свои собственные функции для выдачи пользовательских метрик с использованием SDK-провайдеров или библиотек с открытым исходным кодом. Например, в пакете Node.js Lambda вы можете использовать пакет для асинхронной отправки пользовательских метрик CloudWatch. Для сбора данных от нескольких поставщиков в гибридной или многооблачной среде рассмотрите возможность использования агента на основе коллектора, такого как экспортеры Prometheus или Telegraf.

Хранение и запрос

Базы данных временных рядов являются естественным выбором для мониторинга метрик. Prometheus — это популярный вариант с открытым исходным кодом, который хорошо работает без сервера, если вы настраиваете удаленную конечную точку записи или используете управляемый сервис Prometheus от своего облачного провайдера. Альтернативно, вы можете использовать базу данных общего назначения, такую как Elasticsearch, для журналов и метрик вместе. Слой хранения должен обрабатывать высокую кардинальность (многие уникальные комбинации меток) и высокую пропускную способность записи во время пиков трафика.

визуализация

Слой визуализации потребляет данные из базы данных временных рядов и отображает интерактивные панели приборов. Графана является фактическим стандартом для этого, поддерживая Prometheus, CloudWatch, Elasticsearch и десятки других источников данных. Его богатая панельная библиотека — от графических панелей до тепловых карт и панелей статистики — позволяет создавать панели инструментов, которые являются информативными и легко интерпретируются с первого взгляда.

предупреждение

Панели мониторинга предназначены не только для пассивного просмотра; они должны запускать уведомления, когда показатели пересекают заранее определенные пороги. И Prometheus, и Grafana имеют встроенные системы оповещения. Установите оповещения о высоких показателях ошибок, аномальной задержке p99, повышенных процентах холодного запуска и приближающихся ограничениях параллелизма. Маршрутные оповещения для Slack, PagerDuty, электронной почты или пользовательских веб-хуков, в зависимости от тяжести.

Выбор правильных инструментов для вашей панели инструментов

Инструментарий для бессерверного мониторинга широк. Ваш выбор зависит от существующей инфраструктуры, опыта команды и бюджета. Вот наиболее распространенные комбинации:

Пошаговое руководство: Создание пользовательской панели инструментов с Grafana и Prometheus

В этом руководстве рассматривается создание полноценной панели мониторинга для AWS Lambda с использованием Grafana и Prometheus с экспортером CloudWatch. Такой же подход может быть адаптирован для функций Azure или Google Cloud Functions.

1.Настройка Prometheus и экспортера CloudWatch

Установите Prometheus на сервер (или используйте управляемую службу, такую как Amazon Managed Service for Prometheus). Затем запустите , который скрещивает метрики CloudWatch и выставляет их в формате Prometheus. Настройте экспортера для сбора ключевых метрик Lambda: , , , и . Например, конфигурация экспортера может включать:

metrics:
 - aws_namespace: AWS/Lambda
 aws_metric_name: Invocations
 aws_dimensions: [FunctionName]
 aws_statistics: [Sum]
 - aws_namespace: AWS/Lambda
 aws_metric_name: Duration
 aws_dimensions: [FunctionName]
 aws_statistics: [Average, p95, p99]

Когда экспортер работает, он показывает конечную точку, которую Прометей может скрестить.

2.Настройте Прометея, чтобы сломать экспортера

Добавьте в файл скребковую работу, которая указывает на конечную точку экспортера. Установите интервал скребков 30–60 секунд — безсерверные метрики часто объединяются в одноминутные интервалы CloudWatch, поэтому более быстрая скребковка не нужна.

3.Установка и подключение Grafana

Разверните Grafana (облако или локально) и добавьте Prometheus в качестве источника данных. Предоставьте URL-адрес сервера Prometheus. Проверьте соединение, чтобы убедиться, что показатели текут.

4.Создать панель инструментов для функционального здоровья

В Grafana создайте новую панель приборов и начните добавлять панели. Для панели обзора используйте запрос PromQL , чтобы показать общую скорость вызова. Добавьте панель для частоты ошибок: . Используйте панель временных рядов с цветовыми порогами (зеленый ниже 1%, желтый между 1% и 5%, красный выше 5%).

5. Добавить панель для длительных процентилей

Процентили длительности запроса с использованием , если вы экспортируете гистограмму. В противном случае используйте статистику экспортера CloudWatch p95. Отобразите p50, p95 и p99 в виде отдельных серий на одном графике. Эта панель помогает вам сразу заметить деградацию задержки.

6. Создайте панель с фокусировкой на холодном старте

Если вы экспортируете пользовательский показатель для холодных запусков (с помощью инструментария вашей функции для записи значения 1 на холодном старте и 0 на теплом), вы можете рассчитать скорость холодного запуска: . Используйте панель датчика, чтобы показать процент. Альтернативно, выведите холодные запуски из поля в журналах CloudWatch, но это требует дополнительного анализа.

7. Установите оповещения в Графане

Grafana v8 и более поздние версии имеют унифицированную систему оповещения. Создайте правило оповещения для высоких показателей ошибок (например, >5% в течение 5 минут) и для повышенной продолжительности p99 (например, >3 секунды). Настройте каналы уведомлений для Slack и электронной почты. Проверьте оповещение с помощью запроса образца, чтобы убедиться, что оно работает правильно.

Оригинальное название: Going Beyond Basic Metrics

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

Корреляция логов и метрик

Многие проблемы без сервера требуют просмотра журналов вместе с метриками. Например, всплеск ошибок может быть вызван конкретной полезной нагрузкой ввода. Добавьте панель журналов на свою панель управления Grafana с использованием источника данных, такого как Loki (для Prometheus) или Elasticsearch. Создайте корреляцию, которая позволяет нажать на метрический всплеск и увидеть соответствующие записи журнала в контексте.

Обнаружение аномалий с помощью машинного обучения

Статические пороги работают для известных шаблонов, но безсерверный трафик может быть сезонным или взрывным. Используйте такие сервисы, как AWS CloudWatch Anomaly Detection или специальный инструмент мониторинга на основе ML для обнаружения необычного поведения. Вы можете подавать показатели Prometheus в механизм обнаружения аномалий, а затем наносить аномалии поверхности в качестве аннотаций предупреждения на панели приборов.

Платформы оптимизации затрат

Бессерверные затраты обусловлены вызовами функций, продолжительностью и распределением памяти. Создайте отдельную панель инструментов, которая показывает стоимость одной функции, стоимость одной среды и предполагаемые ежемесячные расходы. Объедините метрики выставления счетов CloudWatch с метриками использования Lambda. Например, используйте метрику от AWS / Billing и сопоставьте ее с резюме функций. Эта панель инструментов помогает командам идентифицировать дорогие функции, которые могут нуждаться в настройке памяти или оптимизации кода.

Пользовательские бизнес-метрические панели

Инструменты для ваших функций, чтобы издавать пользовательские показатели, которые отражают бизнес-результаты: количество заказов, неудавшиеся транзакции, регистрации пользователей и т. Д. Вставьте их в свою операционную панель, чтобы при техническом отключении вы могли сразу увидеть влияние бизнеса.

Лучшие практики для текущего обслуживания панели управления

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

Заключение

Бессерверные вычисления устраняют операционные накладные расходы на управление серверами, но они вводят новые сложности мониторинга, которые общие облачные панели управления не могут решить. Создавая пользовательские панели мониторинга, адаптированные к вашим функциям, шаблонам трафика и бизнес-метрикам, вы получаете видимость в реальном времени в производительности, стоимости и надежности. Сочетание инструментов с открытым исходным кодом, таких как Prometheus и Grafana, с облачными службами мониторинга обеспечивает гибкий, мощный стек, который масштабируется с вашей средой. Начните с небольшого набора основных показателей - вызовов, ошибок, продолжительности, холодных запусков - и постепенно расширяйтесь по мере углубления понимания вашего поведения без сервера. С хорошо продуманной панелью мониторинга вы можете обнаруживать проблемы, прежде чем они повлияют на пользователей, оптимизировать использование ресурсов и поддерживать гибкость, которую обещает безсервер.