Для меня, как и для моей команды, важна скорость разработки и ее качество, именно поэтому особое внимание я всегда уделяю выбору хорошей системе мониторинга.
В моем понимании мониторинг должен быть:
Хорошо визуализированным;
Максимально удобным в использовании;
Гибким по различным настройкам;
Надежным в плане отказоустойчивости, обновлений;
Адаптированным к нагрузкам.
Немного бекграунда: в основном я занимаются разработкой новых фич, выпуском обновлений, поиском и устранением ошибок. Как и вам, мне важно понимать, как ведет себя разрабатываемая система в контексте ресурсов и нагрузок. Именно поэтому нужна грамотная и качественно настроенная система мониторинга. Одной из таких, на мой взгляд, как раз и является система Datadog, о преимуществах и возможностях которой я хотел бы рассказать подробнее.
Очевидные бенефиты Datadog:
Различные возможности интеграции с системами на разных уровнях.
Достаточно хорошая документация по настройке интеграций к различным сервисам.
Итак, используемый стек технологий: Azure Services, Azure Kubernetes Service (AKS), MSSQL, MongoDB, Rabbitmq, ASP .Net Core 5.
Так что, дорогие читатели, в тексте расскажу о возможности мониторинга Datadog на различных уровнях. А о том, как развернуть проект в AKS, настроить CI/CD и прочие DevOps фишки оставлю на сладкое до следующего материала.
В статье хотел бы разложить по полочкам следующие блоки:
мониторинг Azure
мониторинг Kubernetes
мониторинг баз данных и rabbitmq
мониторинг приложений
мониторинг сервисов
Как и в любой системе мониторинга, в Datadog хотелось бы видеть всё структурированно, поэтому рекомендую создавать для проекта отдельную организацию (неймспейс) в личном кабинете Datadog.
Уровни и интеграции мониторинга (а также тонкости настроек)
При разработке проектов на Azure существует возможность интеграции с подпиской Azure.
Для интеграции необходимо знать:
Tenant_name
Client_id
Client_secret
Шаги интеграции с Azure хорошо описаны тут.
Отталкиваясь от информации по ссылке на github сразу устанавливаем через Helm в кубернейтс агента Datadog для мониторинга самих сущностей Kubernetes, указывая в качестве параметра DD_API_KEY который сгенерирован в личном кабинете для организации (Integrations → Agent).
Следующий наш шаг - установка соответствующих модулей в меню Integrations Datadog для Azure и для Kubernetes.
Кстати, очень удобно что при интеграции и установке модуля сразу предлагаются ссылки на инструкции на сайте компании. Вот такой вот плюс!
Успешно настроив предыдущее шаги и подождав некоторое время сразу “из коробки” видим огромное количество готовых дашбордов в личном кабинете Datadog. Наблюдаем мониторинг сервисов подписки Azure и мониторинг нашего AKS кластера.
Присутствует мониторинг хостов в AKS по всем ресурсам.
Мониторинг Kubernetes позволяет максимально детально мониторить всё необходимое (Pods, Deployments, Services…):
Все графики выглядят как и описано в блоге Datadog и даже лучше!
Ресурс также предлагает и самому пользователю попробовать себя в создании дашбордов и графиков по метрикам. Так что я решил не упустить эту возможность и поэкспериментировал с созданием собственных дашбордов. Результат оказался крайне полезнен для команды разработки системы.
На этом мы с командой решили не останавливаться и посмотреть возможные решения и архитектуру работы продукта Datadog по мониторингу баз данных используемых на проекте.
Для мониторинга баз данных использовали схему работы через агента Datadog.
Настраиваются конфигурации мониторингов БД достаточно просто:
1) Для MSSQL предварительно создается пользовать.
2) Далее в на хосте агента в директории Datadog агента (etc/datadog) создается конфигурация в файл - conf.d/sqlserver.d/mssql-conf.yaml
Ниже приведу пример самых базовых настроек, более углубленная конфигурация будет зависеть от настроек вашего SQL сервера:
init_config:
instances:
- host: IP,PORT
username: datadog
password: passwordПри необходимости подключения нескольких хостов их можно добавить в конфиг по аналогии. Кстати, также возможно добавление тегов к хостам.
При необходимости указываются дополнительные настройки для подключений к БД (например connector: odbc с указанием конкретного driver) и различные специфические метрики.
Вы также можете собрать дополнительные метрики из вашей интеграции с SQL, в официальной документации достаточно неплохо расписано по этому вопросу.
Для MongoDB, как и для MSSQL, предварительно создается пользователь на основе инструкций при установке модуля интеграции на портале Datagog, а затем по примеру можно сделать конфигурационный файл на агенте: conf.d/mongo.d/mongo-conf.yaml.
Для мониторинга RabbitMQ указывается api_url имя пользователя и пароль в базовой конфигурации. Из коробки создается 2 дашборда: Overview и Metrics.
Далее перейдём к самому интересному - мониторингу самих приложений и сервисов.
Для мониторинга приложений и сервисов также используется агент. В основном конфигурационном файле агента включается модуль DogStatsD и указывается порт (по умолчанию 8125).
Для данных, отправленных с внешнего хоста, агенту Datadog требуется следующая конфигурация: dogstatsd_non_local_traffic: true и apm_non_local_traffic: true. Это также можно настроить в файле конфигурации datadog.yaml
В настройках приложений указывается адрес агента через который слать метрики в Datadog.
А вот дашборды для мониторинга самих приложений по используемым внутренним метрикам приходится создавать самостоятельно.
Лично мне для настройки мониторинга ASP.Net сервисов помогла официальная документации по этой ссылке. Агент уже был, но необходимо было только добавить в сборку образов соответствующие строки и в системе CI/CD передавать переменные: DD_ENV, DD_SERVICE, DD_AGENT_HOST, соответственно для указания: энвайрмента, имени сервиса и адреса агента.
После всего этого в Datadog в разделе APM → Services стали поступать данные, с максимально подробными метриками всех сервисов и отобразились автоматически графики.
Проблемы есть везде, и тут это тоже не исключение. Мне пришлось столкнуться с тем, что ты сам вынужден ковыряться с настройками мониторинга MSSQL сервера в контексте использования определенного odbc драйвера. И чтобы не наступать на эти же грабли кому-то другому, дублирую вам ссылку на статью, которая помогла мне разобраться с установкой агента и написанием конфига.
Теперь о перспективах: сейчас рассматривается возможное конфигурирование Datadog для сбора логов, пока используется другая система.
Немного затрагивая систему оповещений, хотелось бы отметить что она удобная в Datadog и интуитивно понятная.
Подводя итог могу сказать, что есть еще множество тонких настроек в подробности которых я бы не вдавался именно в этой статье. Но всегда буду рад ответить на ваши комментарии.
Стоит отметить, что Datadog также возможно интегрировать с различными системами оповещений.
Лично у меня остались только позитивные впечатления от Datadog: в процессе настройки системы на различных уровнях оперативно удавалось выявить те или иные проблемы. Так что да, мы с командой нашли оптимальный уровень ресурсов для нашего окружения. Меняя такие параметры как количество нод в кластере, распределение сервисов по нодам, ресурсы самих пулов узлов в кластере, а также используя различное количество потоков и количество параллельных запусков в тестировании и одновременное тестирование различных модулей системы, мы пришли к наиболее оптимальной конфигурации в нашем случае.
Сейчас я уже хорошо понимаю, какие нагрузки на какие сервисы поступают при тестировании. Результат этой работы, конечно, впечатлял.
И, на последок, небольшой список того, что мне удалось прокачать благодаря Datadog:
Сформировалось более детальное понимание работы разрабатываемой системы и реакции на те или иные изменения;
Да, теперь у моей команды есть стабильная многоуровневая систему мониторинга;
Улучшились процессы в команде и коммуникации между командами;
Ускорилось время нахождения багов и конкретизировать влияние этих багов на систему;
Оптимизировались сервисы по работе с базами данных;
Улучшилось скорость разработки системы, а разрабатываемые сервисы стали лучше.