Для меня, как и для моей команды, важна скорость разработки и ее качество, именно поэтому особое внимание я всегда уделяю выбору хорошей системе мониторинга.
В моем понимании мониторинг должен быть:
Хорошо визуализированным;
Максимально удобным в использовании;
Гибким по различным настройкам;
Надежным в плане отказоустойчивости, обновлений;
Адаптированным к нагрузкам.
Немного бекграунда: в основном я занимаются разработкой новых фич, выпуском обновлений, поиском и устранением ошибок. Как и вам, мне важно понимать, как ведет себя разрабатываемая система в контексте ресурсов и нагрузок. Именно поэтому нужна грамотная и качественно настроенная система мониторинга. Одной из таких, на мой взгляд, как раз и является система Datadog, о преимуществах и возможностях которой я хотел бы рассказать подробнее.
Очевидные бенефиты Datadog:
Различные возможности интеграции с системами на разных уровнях. https://docs.datadoghq.com/integrations/
Достаточно хорошая документация по настройке интеграций к различным сервисам.
Итак, используемый стек технологий: 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 хорошо описаны тут: https://github.com/ryanmaclean/k8s-dd-cnhh
Отталкиваясь от информации по ссылке на github сразу устанавливаем через Helm в кубернейтс агента Datadog для мониторинга самих сущностей Kubernetes, указывая в качестве параметра DD_API_KEY который сгенерирован в личном кабинете для организации (Integrations->Agent).
Следующий наш шаг - установка соответствующих модулей в меню Integrations Datadog для Azure и для Kubernetes.
Кстати, очень удобно что при интеграции и установке модуля сразу предлагаются ссылки на инструкции на сайте компании. Вот такой вот плюс!
Успешно настроив предыдущее шаги и подождав некоторое время сразу “из коробки” видим огромное количество готовых дашбордов в личном кабинете Datadog. Наблюдаем мониторинг сервисов подписки Azure и мониторинг нашего AKS кластера.
Присутствует мониторинг хостов в AKS по всем ресурсам.
Мониторинг Kubernetes позволяет максимально детально мониторить всё необходимое (Pods, Deployments, Services…):
Все графики выглядят как и описано в блоге Datadog (https://www.datadoghq.com/blog/announcing-aks/) и даже лучше!
Ресурс также предлагает и самому пользователю попробовать себя в создании дашбордов и графиков по метрикам. Так что я решил не упустить эту возможность и поэкспериментировал с созданием собственных дашбордов. Результат оказался крайне полезнен для команды разработки системы.
На этом мы с командой решили не останавливаться и посмотреть возможные решения и архитектуру работы продукта 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, в официальной документации достаточно неплохо расписано по этому вопросу: https://docs.datadoghq.com/integrations/faq/how-can-i-collect-more-metrics-from-my-sql-server-integration/
Для 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 сервисов помогла официальная документации по этой ссылке https://www.datadoghq.com/blog/asp-dotnet-core-monitoring/. Агент уже был, но необходимо было только добавить в сборку образов соответствующие строки и в системе CI/CD передавать переменные: DD_ENV, DD_SERVICE, DD_AGENT_HOST, соответственно для указания: энвайрмента, имени сервиса и адреса агента.
После всего этого в Datadog в разделе APM->Services стали поступать данные, с максимально подробными метриками всех сервисов и отобразились автоматически графики.
Проблемы есть везде, и тут это тоже не исключение. Мне пришлось столкнуться с тем, что ты сам вынужден ковыряться с настройками мониторинга MSSQL сервера в контексте использования определенного odbc драйвера. И чтобы не наступать на эти же грабли кому-то другому, дублирую вам ссылку на статью, которая помогал мне разобраться с установкой на агента и добавления в конфиг: https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017
Теперь о перспективах: сейчас рассматривается возможное конфигурирование Datadog для сбора логов, пока используется другая система.
Немного затрагивая систему оповещений, хотелось бы отметить что она удобная в Datadog и интуитивно понятная.
Что ж, подводя итог могу сказать, что есть еще множество тонких настроек в подробности которых я бы не вдавался именно в этой статье. Но всегда буду рад ответить на ваши комментарии.
Стоит отметить, что Datadog также возможно интегрировать с различными системами оповещений.
Лично у меня остались только позитивные впечатления от Datadog: в процессе настройки системы на различных уровнях оперативно удавалось выявить те или иные проблемы. Так что да, мы с командой нашли оптимальный уровень ресурсов для нашего окружения. Меняя такие параметры как количество нод в кластере, распределение сервисов по нодам, ресурсы самих пулов узлов в кластере, а также используя различное количество потоков и количество параллельных запусков в тестировании и одновременное тестирование различных модулей системы, мы пришли к наиболее оптимальной конфигурации в нашем случае.
Сейчас я уже хорошо понимаю, какие нагрузки на какие сервисы поступают при тестировании. Результат этой работы, конечно, впечатлял.
И, на последок, небольшой список того, что мне удалось прокачать благодаря Datadog:
Сформировалось более детальное понимание работы разрабатываемой системы и реакции на те или иные изменения;
Да, теперь у моей команды есть стабильная многоуровневая систему мониторинга;
Улучшились процессы в команде и коммуникации между командами;
Ускорилось время нахождения багов и конкретизировать влияние этих багов на систему;
Оптимизировались сервисы по работе с базами данных;
Улучшилось скорость разработки системы, а разрабатываемые сервисы стали лучше.
