Отладка с помощью Render: два эффективных метода
17 декабря 2022 г.Render — это универсальное решение для инфраструктуры веб-приложений, упрощающее размещение статического контента, баз данных, микросервисов и многого другого. Независимо от того, поддерживаете ли вы монолитное приложение или внедрили шаблон микрослужбы — и вы еще не готовы создать целую команду SRE — Render — это хороший выбор для вашей инфраструктуры и потребностей в хостинге.
В этой статье мы сосредоточимся на отладке в Render. Мы создадим простой микросервис Node.js с базой данных PostgreSQL. Мы развернем эти два компонента с помощью Render, а затем продемонстрируем два разных способа отладки нашего сервиса и базы данных. Мы будем использовать Log Streams для доступа к системным журналам и Datadog для показателей наблюдаемости и предупреждений.
Вы готовы? Давайте углубимся.
Размещение приложения Node.js с рендерингом
Целью этой статьи является неt глубокое погружение в создание приложения микрослужбы Node.js. Однако если у вас есть опыт работы с Node.js, TypeScript, Express и PostgreSQL, вы, вероятно, найдете дополнительную ценность в представленном здесь коде.
Наше демонстрационное мини-приложение представляет собой API управления пользователями с несколькими типичными конечными точками для получения, создания, обновления или удаления пользователей. За кулисами служба выполняет операции запросов к базе данных PostgreSQL. Полный код приложения можно найти здесь.
Настройка учетной записи Datadog
Прежде чем мы сможем настроить наш экземпляр PostgreSQL, нам нужно получить ключ API Datadog. Вы можете зарегистрировать бесплатную пробную учетную запись, а затем подписаться на эти инструкции для получения ключа API. Вскоре мы обсудим Datadog более подробно.
Развертывание экземпляра PostgreSQL
Мы начнем с экземпляра PostgreSQL, так как нам потребуются учетные данные базы данных, прежде чем мы сможем использовать нашу службу Users. Чтобы создать экземпляр для своего проекта, войдите в Render и нажмите кнопку Создать + в правом верхнем углу. угол. Затем нажмите PostgreSQL, чтобы начать процесс. Вы попадаете в форму для настройки вашей базы данных:
Укажите имя для своего экземпляра, а также имя базы данных и имя пользователя для доступа. Для поля «Ключ API Datadog» важно добавить его сейчас, потому что его сложно добавить после создания базы данных. Вставьте ключ API, созданный на предыдущем шаге.
Нажмите Создать базу данных и дождитесь завершения инициализации. Render отобразит учетные данные для вашей новой базы данных. Они понадобятся вам позже при настройке службы пользователей.
Инициализировать схему базы данных
Обратите внимание, что нам потребуется инициализировать схему в этой новой базе данных, создав пользовательскую таблицу с соответствующими столбцами. Мы сделаем это с помощью пакета node-pg-migrate. Инструкции по инициализации базы данных находятся в файле README репозитория кода. Однако мы включим этот шаг в команду запуска нашего приложения в Render.
Развертывание микрослужбы пользователей
Развернуть микросервис с помощью Render несложно, особенно если вы размещаете свой код в GitLab или GitHub. После подключения учетной записи хостинга кода к Render вернитесь на панель инструментов Render. Нажмите кнопку Создать + и выберите Веб-служба. Выберите репозиторий кода с вашим микросервисом.
Каждое поле ввода хорошо документировано на этой странице. Для нашего примера службы Node.js мы хотим обеспечить следующее:
* «Среда» должна быть установлена на Node.
* «Команда сборки» должна быть yarn install && yarn build, чтобы были установлены все зависимости и собрана окончательная система.
* «Команда запуска» (не показана) для этого конкретного продукта запустит миграцию базы данных и запустит наше приложение. Это должно быть: yarn migrate up --no-reject-unauthorized && начало пряжи:производство
Кроме того, в меню «Дополнительно» есть дополнительные поля, которые нам нужно будет заполнить для этого проекта.
Нам нужно установить пять переменных среды для подключения к базе данных:
DB_HOSTИМЯ_БДDB_USERDB_PASSWORDDATABASE_URL— Это строка подключения к базе данных, используемаяnode-pg-migrate. Его значение равноpostgres://DB_USER:DB_PASSWORD@DB_HOST:5432/DB_NAMEс фактическими значениями этих заполнителей. Например:postgres://john:Ue473C@dpg- 1g50-a.oregon-postgres.render.com:5432/mydb
Эти учетные данные должны исходить от экземпляра PostgreSQL, созданного на предыдущем шаге.
Наконец, убедитесь, что для параметра «Путь проверки работоспособности» задано значение /health, чтобы упростить развертывание без простоев и мониторинг работоспособности в Render.
Нажмите Создать веб-службу. Рендер сотворит свое волшебство и развернет этот сервис из вашего репозитория!
Отладка с помощью Datadog
Datadog — это облачная модель SaaS, предоставляющая расширенные инструменты сбора и поиска журналов, а также функции мониторинга и оповещения. Независимо от того, работаете ли вы с одной службой или десятью тысячами, Datadog — это полезный инструмент для более глубокого понимания того, как работают ваши ресурсы.
Мы уже подключили наш экземпляр PostgreSQL к Datadog, включив ключ API Datadog во время его создания. Это обеспечивает возможности мониторинга множества различных показателей в этом экземпляре базы данных. Полный список поддерживаемых метрик для PostgreSQL доступен здесь. Давайте посмотрим, как использовать эти показатели для мониторинга и оповещения.
Изучение показателей
Войдите в свою учетную запись Datadog и перейдите на страницу Метрики.
В верхней строке Metrics Explorer отображается панель инструментов запрос метрики с различными раскрывающимися списками и полями ввода для фильтрации показателей, отображаемых на диаграмме. Показана метрика по умолчанию system.cpu.user. Если ваша база данных была правильно настроена с помощью ключа API, вы должны увидеть линейный график, показывающий процент времени, затраченного ЦП на выполнение процессов пользовательского пространства.
Когда вы нажмете раскрывающееся меню «из», вы увидите два потенциальных источника показателей вашей базы данных:
Показатели могут отображаться на основе конкретной базы данных на хосте или на всем хосте. В нашем примере на хосте работает только один экземпляр базы данных. Таким образом, с этой конкретной метрикой нет никакой разницы между метрикой, относящейся к базе данных, и метрикой, относящейся к хосту.
Если вы хотите изучить другую метрику, выберите первое поле ввода и введите system.mem. Автозаполнение покажет различные показатели, связанные с памятью:
Если вы выберете system.mem.used, вы начнете видеть используемую память хоста базы данных. Обратите внимание, что диалоговое окно содержит описание выбранной метрики.
Метрики, специфичные для PostgreSQL, которые доступны в Datadog, также интересны. Например, мы можем в любой момент отслеживать количество активных подключений к базе данных.
В этом запросе поле «от» использует экземпляр одной базы данных, а Datadog суммирует данные на основе свойства database-id в метрике.
Мониторинг — полезный инструмент отладки. Если вы столкнулись с медленным откликом базы данных в своем приложении, вы можете просмотреть текущие показатели в Datadog. Сопоставляя метрики PostgreSQL, такие как время запроса или количество соединений, со временем отклика приложения, вы можете обнаружить плохо написанный запрос, связанный с определенной конечной точкой или определенным кодом, который неправильно очищает соединения с базой данных. Доступ к этим показателям может дать ключ к решению проблемы.
Конечно, решение проблемы обычно зависит от того, насколько вы осведомлены о ее возникновении.
К счастью, Datadog предоставляет значительные ресурсы для предупреждения в случае снижения производительности ваших систем. Вы можете настроить эти оповещения для отслеживания выбранных вами показателей, отправляя уведомления в различные места.
Давайте поговорим об оповещениях как об инструменте отладки веб-приложений.
Оповещения в Datadog
Выберите Мониторы на панели навигации Datadog, затем выберите Новый монитор и выберите тип монитора Показатель.
Мы создадим монитор, который будет предупреждать нас, когда количество активных подключений к базе данных превышает пороговое значение.
Выберите Предупреждение о пороге, а затем определите запрос метрики так же, как на странице метрик. Мы хотим использовать метрику postgres.connections из нашего единственного экземпляра базы данных. Наконец, мы выбираем пороговое значение min by. Если «минимальное количество подключений» превышает пороговое значение, это указывает на то, что в настоящее время к этому экземпляру базы данных подключено слишком много. Вот когда мы должны быть предупреждены.
Затем определите пороговые значения, которые вызывают оповещение:
Это надуманный пример, но он означает, что Datadog выдаст предупреждение, если обнаружит 12 подключений к базе данных за последние пять минут. Тем временем мы получим полное оповещение о 20 подключениях к базе данных за последние пять минут.
Наконец, мы настроили уведомления, которые будут появляться при срабатывании предупреждения. Например, Datadog может отправлять уведомления в Jira, Slack или пользовательскую конечную точку веб-перехватчика. Настройка уведомлений выходит за рамки этой статьи, но документация Datadog для уведомлений ясна.
Оповещения важны для отладки веб-приложения, поскольку они повышают осведомленность о возникновении проблемы, указывая на соответствующие показатели, описывающие текущее состояние системы.
Показатели, которые мы рассматривали до сих пор, в основном относятся к типу «вне системы».
Далее рассмотрим, как использовать журналы, чтобы понять, что происходит внутри самой системы.
Отладка с помощью потоков журналов
При разработке Node.js использование console.log является распространенным методом отладки. Просмотр выходных данных журнала прост, если вы развернули приложение Node.js на локальном компьютере, но это сложно, если вы развернули его в облаке. Здесь поможет потоки журналов.
Потоки журналов рендеринга позволяют экспортировать системные журналы из развернутых служб во внешний агрегатор журналов. Одним из примеров является Datadog, но Render поддерживает и другие, в том числе Papertrail и LogTail< /а>.
Настройка экспорта системного журнала
Чтобы настроить экспорт системного журнала, войдите в свою учетную запись Render и перейдите на страницу Настройки учетной записи. Нажмите «Потоки журналов». Добавьте конечную точку для агрегатора журналов вместе с токеном API (если есть). В нашем примере мы будем отправлять системные журналы в Datadog.
В Datadog перейдите на вкладку Журналы.
Это приведет вас к панели управления Поиск по журналам, где вы сможете увидеть в реальном времени хвост всех журналов, загружаемых вашей учетной записью Datadog. Сюда входят журналы, создаваемые нашим экземпляром базы данных, нашей микрослужбой Node.js и процессом сборки Render для нашей микрослужбы.
Чтобы сузить журналы, мы можем добавить имя хоста в строку поиска запроса. В результате будут показаны только те журналы, которые поступают из нашего экземпляра микрослужбы Users (как журналы приложений, так и журналы сборки Render).
Журналы, созданные приложением через console.log или регистратор, такой как Pino, будут отображаться здесь, помогая при отладке. Вы можете отслеживать целые запросы через свои системы, следя за ними через журналы различных служб. По мере того, как данные передаются через вашу систему от конечных точек API на уровень службы, а затем на уровень базы данных, вы можете использовать журналы для отслеживания основной причины проблем.
Использование журналов для отладки
Как вы можете использовать журналы своего приложения Node.js для отладки? Вот несколько полезных советов:
- Отправлять журнал при перехвате исключения. Использование try-catch является хорошей практикой, поскольку гарантирует изящная обработка при возникновении ошибки. В блоке
catchвы можете делать больше, чем просто обрабатывать исключение; создать сообщение журнала с полезной контекстной информацией. Затем запросите такие сообщения в своей системе управления журналами, чтобы отследить основную причину. - Используйте другие серьезности, кроме
log. При использовании console, вы не ограничены только использованиемconsole.log. Вы также можете использовать такие функции, какconsole.info,console.debugиconsole.error. Это поможет вам различать серьезность того, что вы регистрируете, и упростит запрос или фильтрацию для конкретных проблем. - Настройте оповещения при определенных условиях журнала. Большинство систем управления журналами имеют механизм оповещения, позволяющий вам устанавливать определенные условия для входящих журналов, которые приводят к срабатыванию уведомления. Например, если ваше приложение Node.js регистрирует каждый код ответа HTTP (например,
200,401и500), вы можете установить оповещение, чтобы уведомить вас, когда определенный код ответа появляется слишком часто. Вы можете настроить оповещение, чтобы сообщать вам, когда код500или401встречается более пяти раз за десять минут, что указывает на возможную проблему, которую необходимо решить. с немедленно.
Заключение
В нашем мини-проекте мы создали небольшое микросервисное приложение, используя простую серверную службу Node.js и базу данных PostgreSQL. Мы развернули обе части в Render, чтобы мы могли исследовать отладку системы через Render. Мы рассмотрели два разных способа отладки:
- Отправка показателей наблюдаемости в Datadog в сочетании с предупреждениями и уведомлениями.
- Использование Log Streams для экспорта системных журналов из различных компонентов вашего приложения, которые мы также видели в Datadog.
Когда возникают проблемы с вашим микросервисным приложением, ваша команда должна быстро реагировать, чтобы сократить или предотвратить простои. Эффективные методы отладки в сочетании с предупреждениями и уведомлениями помогут вам быстро реагировать. Если вы развертываете свое приложение в Render, у вас есть быстрые и простые средства — интеграция Datadog и Log Streams — для предоставления сведений об отладке и предупреждений в реальном времени.
Также опубликовано здесь.
Оригинал