В предыдущих главах Node.js в Scale мы узнали, как получить правильное тестирование Node.js и TDD и как использовать Nightwatch.js для сквозного тестирования.

В этой статье мы узнаем о запуске и мониторинге приложений Node.js в рабочей среде. Давайте обсудим следующие темы:

  • Что такое мониторинг?
  • Что нужно контролировать?
  • Решения для мониторинга с открытым исходным кодом
  • Предложения SaaS и локального мониторинга

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

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

Если у вас есть приложение Node.js в промежуточной или производственной среде, вы можете (и должны) выполнять мониторинг на разных уровнях:

Вы можете отслеживать

  • регионы,
  • зоны,
  • отдельные серверы и
  • конечно, программное обеспечение Node.js, которое на них работает.

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

Что нужно контролировать?

Каждое приложение, которое вы пишете на Node.js, предоставляет множество данных о своем поведении.

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

  • Уровень обслуживания
  • Уровень хоста
  • Уровень экземпляра (или процесса)

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

Проблема 1: простои обслуживания

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

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

Первоочередной задачей должно быть предотвращение сбоев и обеспечение 100% доступности вашего приложения.

Запуск рабочего приложения требует большой ответственности.

Node.js APM может легко помочь вам обнаружить и предотвратить простои, поскольку они обычно собирают метрики уровня обслуживания.

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

Чтобы обеспечить надлежащее покрытие времени простоя, мы также рекомендуем настроить пингер, который может имитировать поведение пользователя и предоставлять надежные данные о доступности. Если вы хотите охватить все, не забудьте указать другие такие регионы, как США, Европа и Азия.

Проблема 2: Медленное обслуживание, ужасное время отклика

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

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

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

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

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

Проблема 3. Устранение утечек памяти - непростая задача

Наш опыт консалтинга и разработки Node.js позволил нам создавать огромные корпоративные системы и помогать разработчикам делать их лучше.

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

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

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

Некоторые APM собирают данные об использовании памяти, которые можно использовать для распознавания утечки. Вы должны обратить внимание на постоянный рост использования памяти, который заканчивается сбоем службы и перезапуском (при запуске Node нехватка памяти через 1,4 гигабайта).

Если ваш APM также собирает данные на сборщике мусора, вы можете поискать тот же шаблон. По мере накопления дополнительных объектов в памяти приложения Node время, затрачиваемое на сборку мусора, увеличивается одновременно. Это отличный индикатор утечки памяти.

Выявив утечку, запросите дамп памяти и поищите лишние объекты!

В теории это звучит просто, но на практике может быть сложно.

Что вы можете сделать, так это запросить 2 дампа кучи из вашей производственной системы с помощью инструмента мониторинга и проанализировать эти дампы с помощью инструментов Chrome DevTools. Если вы посмотрите на лишние объекты в режиме сравнения, вы увидите, что скопилось в памяти вашего приложения.

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

Проблема 4. В зависимости от кода, написанного анонимусом

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

Примерно 76% магазинов Node используют уязвимые пакеты, в то время как проекты с открытым исходным кодом регулярно устаревают из-за пренебрежения исправлением недостатков безопасности.

Есть несколько возможных шагов для снижения рисков безопасности при использовании пакетов npm.

  1. Проверяйте свои модули с Node Security Platform CLI
  2. Ищите неиспользуемые зависимости с помощью инструмента depcheck
  3. Используйте API статистики npm или просмотрите историческую статистику на npm-stat.com, чтобы узнать, используют ли другие пакеты
  4. Используйте команду npm view <pkg> maintainers, чтобы избежать пакетов, поддерживаемых лишь несколькими
  5. Используйте команду npm outdated или Greenkeeper, чтобы узнать, используете ли вы последнюю версию пакета.

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

Проблема 6. Оповещения по электронной почте часто остаются незамеченными

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

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

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

Я предполагаю, что вы также не хотите наблюдать за панелями мониторинга на предмет потенциальных проблем 24/7. Вот почему так важно искать APM с отличными возможностями оповещения.

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

Несколько рекомендаций по оповещению, которым мы следуем в RisingStack:

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

Проблема 7. Выявление серьезных ошибок в коде

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

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

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

В следующей части статьи я покажу вам одно решение для мониторинга с открытым исходным кодом и одно SaaS / локальное решение для мониторинга Node.js, которые помогут вам управлять вашими приложениями.

Prometheus - универсальная платформа для мониторинга с открытым исходным кодом

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

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

В 2016 году Прометей присоединился к Cloud Native Computing Foundation сразу после Kubernetes.

Наиболее важные особенности Prometheus:

  • многомерная модель данных (временные ряды, идентифицируемые по названию показателя и парам "ключ-значение"),
  • гибкий язык запросов для использования этой размерности,
  • сбор временных рядов по умолчанию происходит через модель pull через HTTP,
  • передача временных рядов поддерживается через промежуточный шлюз.

Мониторинг Node.js с помощью prometheus

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

Посетите официальные Начальные страницы Prometheus, если хотите попробовать.

Прежде чем вы начнете отслеживать свои службы Node.js, вам необходимо добавить к ним инструментарий через одну из клиентских библиотек Prometheus.

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

По сути, все, что вам нужно сделать, это require клиент Prometheus, а затем предоставить его выходные данные в конечной точке:

const Prometheus = require('prom-client') const server = require('express')() server.get('/metrics', (req, res) => { res.end(Prometheus.register.metrics()) }) server.listen(process.env.PORT || 3000)

Эта конечная точка будет производить вывод, который может потреблять Прометей - примерно так:

# HELP process_start_time_seconds Start time of the process since unix epoch in seconds. # TYPE process_start_time_seconds gauge process_start_time_seconds 1490433285 # HELP process_resident_memory_bytes Resident memory size in bytes. # TYPE process_resident_memory_bytes gauge process_resident_memory_bytes 33046528 # HELP nodejs_eventloop_lag_seconds Lag of event loop in seconds. # TYPE nodejs_eventloop_lag_seconds gauge nodejs_eventloop_lag_seconds 0.000089751 # HELP nodejs_active_handles_total Number of active handles. # TYPE nodejs_active_handles_total gauge nodejs_active_handles_total 4 # HELP nodejs_active_requests_total Number of active requests. # TYPE nodejs_active_requests_total gauge nodejs_active_requests_total 0 # HELP nodejs_version_info Node.js version info. # TYPE nodejs_version_info gauge nodejs_version_info{version="v4.4.2",major="4",minor="4",patch="2"} 1

Конечно, это просто метрики по умолчанию, которые собирал модуль, который мы использовали - вы можете расширить их своими. В приведенном ниже примере мы собираем количество обслуженных запросов:

const Prometheus = require('prom-client') const server = require('express')() const PrometheusMetrics = { requestCounter: new Prometheus.Counter('throughput', 'The number of requests served') } server.use((req, res, next) => { PrometheusMetrics.requestCounter.inc() next() }) server.get('/metrics', (req, res) => { res.end(Prometheus.register.metrics()) }) server.listen(3000)

После его запуска конечная точка /metrics также будет включать метрики пропускной способности:

# HELP process_start_time_seconds Start time of the process since unix epoch in seconds. # TYPE process_start_time_seconds gauge process_start_time_seconds 1490433805 # HELP process_resident_memory_bytes Resident memory size in bytes. # TYPE process_resident_memory_bytes gauge process_resident_memory_bytes 25120768 # HELP nodejs_eventloop_lag_seconds Lag of event loop in seconds. # TYPE nodejs_eventloop_lag_seconds gauge nodejs_eventloop_lag_seconds 0.144927586 # HELP nodejs_active_handles_total Number of active handles. # TYPE nodejs_active_handles_total gauge nodejs_active_handles_total 0 # HELP nodejs_active_requests_total Number of active requests. # TYPE nodejs_active_requests_total gauge nodejs_active_requests_total 0 # HELP nodejs_version_info Node.js version info. # TYPE nodejs_version_info gauge nodejs_version_info{version="v4.4.2",major="4",minor="4",patch="2"} 1 # HELP throughput The number of requests served # TYPE throughput counter throughput 5

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

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

Если у вас есть время, чтобы углубиться в тему, вас это устроит.

Встречайте Trace - наш инструмент мониторинга SaaS и локального Node.js

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

Вот почему может иметь смысл использовать размещенное решение для мониторинга - будь то продукт SaaS или локальное предложение.

В RisingStack мы разрабатываем собственное решение для мониторинга Node.js, которое называется Trace. Мы встроили в Trace весь опыт, накопленный за годы предоставления профессиональных услуг Node.

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

require([email protected]/trace')

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

Вот несколько вещей, которые Trace может делать с вашим рабочим приложением Node:

  1. Отправлять оповещения о простоях, медленных услугах и кодах плохого состояния.
  2. Пингуйте свои веб-сайты и API с помощью внешней службы + показывайте показатели APDEX.
  3. Также собирайте данные об уровнях обслуживания, хоста и экземпляра.
  4. Автоматически создавать (длительностью 10 секунд) профиль ЦП в производственной среде в случае замедления.
  5. Собирать данные о потреблении памяти и сборке мусора.
  6. Автоматическое создание дампов памяти в случае утечки памяти в производственной среде.
  7. Показать ошибки и трассировки стека из вашего приложения.
  8. Визуализируйте целые цепочки вызовов транзакций в распределенной системе.
  9. Покажите, как ваши сервисы взаимодействуют друг с другом на живой карте.
  10. Автоматическое обнаружение пакетов npm с уязвимостями системы безопасности.
  11. Отметьте новые развертывания и оцените их эффективность.
  12. Интегрируйтесь со Slack, Pagerduty и Opsgenie, чтобы не пропустить ни одного предупреждения.

Хотя Trace в настоящее время является решением SaaS, мы скоро сделаем доступную локальную версию.

Он сможет делать то же самое, что и облачная версия, но будет работать в Amazon VPC или в вашем собственном центре обработки данных. Если тебе это интересно, давай поговорим!

Я надеюсь, что в этой главе Node.js at Scale я смог дать полезный совет по мониторингу вашего приложения Node.js. В следующей статье вы узнаете, как легко отлаживать приложения Node.js.

Первоначально опубликовано на blog.risingstack.com 28 марта 2017 г.