Эта статья поможет вам понять, что нужно отслеживать, если у вас есть приложение Node.js в рабочей среде, и как использовать Prometheus - решение с открытым исходным кодом, которое обеспечивает эффективное сжатие данных и быстрое получение данных. запрос данных временных рядов - для мониторинга Node.js.

Что такое мониторинг Node.js?

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

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

Чтобы проанализировать данные, во-первых, вам необходимо извлечь метрики из вашей системы - например, использование памяти конкретным экземпляром приложения. Мы называем это приспособлением для извлечения.

Мы используем термин мониторинг белого ящика, когда показатели предоставляются самой работающей системой. Это вид мониторинга Node.js, в который мы углубимся.

Четыре сигнала, которые нужно знать

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

Мы рекомендуем вам следить за этими сигналами для всех ваших сервисов:

  • Частота ошибок: потому что ошибки возникают у пользователей и сразу же влияют на ваших клиентов.
  • Время ответа: потому что задержка напрямую влияет на ваших клиентов и бизнес.
  • Пропускная способность: трафик помогает понять контекст увеличения количества ошибок и задержки.
  • Насыщенность: показывает, насколько «заполнен» ваш сервис. Если загрузка ЦП составляет 90%, сможет ли ваша система обрабатывать больше трафика?

Приборы

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

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

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

Риск инструментария вашего кода

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

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

Скачать здесь: https://trace.risingstack.com/monitoring-ebook

Выбор инструмента мониторинга Node.js

Когда ваша команда выбирает инструмент мониторинга, вы должны учитывать следующие аспекты:

  • Опыт. У вас есть опыт? Создать инструмент мониторинга, написать высококачественный инструментарий и извлечь нужные метрики непросто. Вам нужно знать, что вы делаете.
  • Создайте или купите. Создание надлежащего решения для мониторинга требует большого опыта, времени и денег, в то время как получение существующего решения может быть проще и дешевле.
  • SaaS или локально: вы хотите разместить свое решение для мониторинга? Можете ли вы использовать решение SaaS, какова ваша политика соответствия и защиты данных? Использование SaaS-решения может быть хорошим выбором, например, если вы хотите сосредоточиться на своем продукте, а не на инструментах. Как решения с открытым исходным кодом, так и коммерческие решения обычно доступны как локальные, так и локальные.
  • Лицензирование. Хотите ли вы поставлять свой набор инструментов для мониторинга вместе с продуктом? Вы можете использовать коммерческое решение? Вы всегда должны проверять лицензирование.
  • Интеграции. Поддерживает ли он мои внешние зависимости, такие как базы данных, систему оркестровки и библиотеки npm?
  • Инструменты. Предоставляет ли он автоматические инструменты? Нужно ли мне вручную инструментировать свой код? Сколько времени нужно, чтобы сделать это самостоятельно?
  • Микросервисы: вы строите монолитную или распределенную систему? Микросервисам нужны особые инструменты и философия для их эффективной отладки и мониторинга. Вам нужно распространять отслеживание или проверки безопасности?

Исходя из нашего опыта, в большинстве случаев готовое решение SaaS или локального мониторинга, такое как Trace, обеспечивает необходимый уровень видимости и набора инструментов для мониторинга и отладки ваших приложений Node.js.

Но что делать, если по какой-то причине вы не можете выбрать коммерческое решение и хотите создать свой собственный пакет мониторинга?

Это тот случай, когда на сцене появляется Прометей!

Мониторинг узлов с помощью Prometheus

Prometheus - это решение с открытым исходным кодом для мониторинга и оповещений на Node.js. Он обеспечивает мощное сжатие данных и быстрый запрос данных для данных временных рядов.

Основная концепция Prometheus заключается в том, что он хранит все данные в формате временных рядов.

Временной ряд - это поток неизменяемых значений с метками времени, принадлежащих одной метрике и одним и тем же меткам. Ярлыки делают показатели многомерными.

Вы можете узнать больше о том, как Prometheus оптимизирует свой механизм хранения, в статье Написание базы данных временных рядов с нуля.

FunFact: Prometheus изначально создавался в SoundCloud, в 2016 году он присоединился к Cloud Native Computing Foundation в качестве второго размещенного проекта после Kubernetes.

Типы сбора данных и показателей

Prometheus использует HTTP-модель pull, что означает, что каждое приложение должно предоставлять GET /metrics конечную точку, которая может периодически извлекаться экземпляром Prometheus.

У Prometheus есть четыре типа метрик:

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

В следующем фрагменте вы можете увидеть пример ответа для конечной точки /metrics. Он содержит как счетчик (nodejs_heap_space_size_total_bytes), так и гистограмму (http_request_duration_ms_bucket) типов показателей:

# HELP nodejs_heap_space_size_total_bytes Process heap space size total from node.js in bytes.
# TYPE nodejs_heap_space_size_total_bytes gauge
nodejs_heap_space_size_total_bytes{space="new"} 1048576 1497945862862  
nodejs_heap_space_size_total_bytes{space="old"} 9818112 1497945862862  
nodejs_heap_space_size_total_bytes{space="code"} 3784704 1497945862862  
nodejs_heap_space_size_total_bytes{space="map"} 1069056 1497945862862  
nodejs_heap_space_size_total_bytes{space="large_object"} 0 1497945862862
# HELP http_request_duration_ms Duration of HTTP requests in ms
# TYPE http_request_duration_ms histogram
http_request_duration_ms_bucket{le="10",code="200",route="/",method="GET"} 58  
http_request_duration_ms_bucket{le="100",code="200",route="/",method="GET"} 1476  
http_request_duration_ms_bucket{le="250",code="200",route="/",method="GET"} 3001  
http_request_duration_ms_bucket{le="500",code="200",route="/",method="GET"} 3001  
http_request_duration_ms_bucket{le="+Inf",code="200",route="/",method="GET"} 3001

Prometheus предлагает альтернативу, называемую Pushgateway, для мониторинга компонентов, которые нельзя выбросить, так как они находятся за брандмауэром или выполняются недолго.

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

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

Мониторинг приложения Node.js

Когда мы хотим отслеживать наше приложение Node.js с помощью Prometheus, нам необходимо решить следующие задачи:

  • Инструментарий: безопасное инструментирование нашего кода с минимальными затратами на производительность
  • Отображение показателей: представление наших показателей для Prometheus с помощью конечной точки HTTP.
  • Хостинг Prometheus: правильно настроенный Prometheus работает
  • Извлечение значения: написание статистически правильных запросов.
  • Визуализация: создание информационных панелей и визуализация наших запросов.
  • Оповещения: настройка эффективных оповещений.
  • Пейджинг: получайте уведомления об оповещениях с применением политик эскалации для пейджинга.

Скачать здесь: https://trace.risingstack.com/monitoring-ebook

Node.js Metrics Exporter

Чтобы собрать метрики из нашего приложения Node.js и предоставить их Prometheus, мы можем использовать библиотеку npm prom-client.

В следующем примере мы создаем метрики типа гистограммы для сбора времени отклика наших API по маршрутам. Взгляните на предварительно определенные размеры сегментов и нашу метку маршрута:

// Init
const Prometheus = require('prom-client')  
const httpRequestDurationMicroseconds = new Prometheus.Histogram({  
  name: 'http_request_duration_ms',
  help: 'Duration of HTTP requests in ms',
  labelNames: ['route'],
  // buckets for response time from 0.1ms to 500ms
  buckets: [0.10, 5, 15, 50, 100, 200, 300, 400, 500]
})

Нам нужно собирать время ответа после каждого запроса и сообщать об этом с меткой маршрута.

// After each response
httpRequestDurationMicroseconds  
  .labels(req.route.path)
  .observe(responseTimeInMs)

Мы можем зарегистрировать маршрут GET /metrics конечной точкой, чтобы предоставлять наши метрики в правильном формате для Prometheus.

// Metrics endpoint
app.get('/metrics', (req, res) => {  
  res.set('Content-Type', Prometheus.register.contentType)
  res.end(Prometheus.register.metrics())
})

Запросы

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

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

В дашборде Prometheus есть встроенный инструмент запросов и визуализации:

Панель управления Prometheus

Давайте посмотрим на несколько примеров запросов о времени отклика и использовании памяти.

Запрос: 95-е время ответа

Мы можем определить 95-й процентиль нашего времени отклика на основе показателей нашей гистограммы. Используя время отклика 95-го процентиля, мы можем отфильтровать пики, и это обычно дает лучшее понимание среднего пользовательского опыта.

histogram_quantile(0.95, sum(rate(http_request_duration_ms_bucket[1m])) by (le, service, route, method))

Запрос: среднее время ответа

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

avg(rate(http_request_duration_ms_sum[1m]) / rate(http_request_duration_ms_count[1m])) by (service, route, method, code)

Для более сложных запросов, таких как частота ошибок и оценка Apdex, обратитесь к нашему репозиторию Prometheus с Node.js.

Оповещение

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

Давайте посмотрим, как настроить оповещение о среднем времени отклика приложений. В этом случае мы хотим активировать оповещение, когда среднее время ответа превышает 100 мс.

# APIHighMedianResponseTime
ALERT APIHighMedianResponseTime  
  IF histogram_quantile(0.5, sum(rate(http_request_duration_ms_bucket[1m])) by (le, service, route, method)) > 100
  FOR 60s
  ANNOTATIONS {
    summary = "High median response time on {{ $labels.service }} and {{ $labels.method }} {{ $labels.route }}",
    description = "{{ $labels.service }}, {{ $labels.method }} {{ $labels.route }} has a median response time above 100ms (current value: {{ $value }}ms)",
  }

Активное оповещение Prometheus в состоянии ожидания

Интеграция Kubernetes

Prometheus предлагает встроенную интеграцию Kubernetes. Он способен обнаруживать ресурсы Kubernetes, такие как узлы, сервисы и поды, и при этом извлекать из них метрики.

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

Вы также можете легко настроить Prometheus с помощью Kubernetes и Helm. Для этого потребуется всего пара шагов. В первую очередь нам нужен работающий кластер Kubernetes!

Поскольку Служба контейнеров Azure предоставляет размещенный Kubernetes, я могу быстро подготовить его:

# Provision a new Kubernetes cluster
az acs create -n myClusterName -d myDNSPrefix -g myResourceGroup --generate-ssh-keys --orchestrator-type kubernetes
# Configure kubectl with the new cluster
az acs kubernetes get-credentials --resource-group=myResourceGroup --name=myClusterName

Через пару минут, когда наш кластер Kubernetes будет готов, мы можем инициализировать Helm и установить Prometheus:

helm init  
helm install stable/prometheus

Для получения дополнительной информации о настройке Prometheus с Kubernetes ознакомьтесь с диаграммой Prometheus Helm.

Графана

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

Поскольку у Prometheus есть API для выполнения запросов и получения данных, вы можете использовать множество внешних решений для создания информационных панелей. Один из моих любимых - Графана.

Grafana - это подключаемая платформа визуализации с открытым исходным кодом. Он может обрабатывать метрики из многих типов систем и имеет встроенную поддержку источников данных Prometheus.

В Grafana вы можете импортировать существующую панель управления или создать собственную.

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

Заключение

Prometheus - это мощный инструмент с открытым исходным кодом для мониторинга вашего приложения, но, как видите, он не работает из коробки.

Используя Prometheus, вам нужен опыт, чтобы инструментировать ваше приложение, наблюдать за вашими данными, а затем запрашивать и визуализировать ваши показатели.

Если вы ищете простой, но мощный готовый к работе инструмент для отладки и мониторинга приложения Node.js, ознакомьтесь с нашим решением под названием Trace.

Ниже вы можете найти наш репозиторий с примерами, который может помочь вам с более подробными советами, если вы выберете этот способ мониторинга своего приложения Node.js.

Пример репозитория: RisingStack / example-prometheus-nodejs

Первоначально опубликовано на blog.risingstack.com 27 июня 2017 г.