Как использовать Datadog для приложения APM Metrics

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

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

Продукты SDG помогают более чем 250 миллионам людей общаться и строить отношения по всему миру, и наша база пользователей постоянно растет. Главным фактором этого успеха является наша способность оперативно реагировать на потребности пользователей. У нас большой опыт работы с различными системами мониторинга, в том числе с Datadog. Вот почему:

1. В настоящее время Datadog предлагает множество вариантов интеграции с системами разного уровня. Вы можете изучить эти возможности здесь .

   
   

2. Datadog предоставляет исчерпывающую документацию для настройки интеграции с различными сервисами.

   
   

3. Нам удалось построить крепкие партнерские отношения.

Здесь мы делимся нашим опытом установки и настройки метрик APM для приложений в нашем кластере Kubernetes для Datadog. В статье не рассматривается развертывание проектов в AKS, процесс CI/CD и другие детали DevOps.

Вместо этого мы сосредоточимся на более тонких моментах настройки мониторинга Datadog для метрик APM.

Используемый стек технологий: Службы Azure, Служба Azure Kubernetes (AKS), ASP .Net Core 7, Datadog.

Для мониторинга приложений и сервисов мы используем агент Datadog, развернутый внутри кластера через диаграмму Helm с дополнительными параметрами из файлаvalues.yaml. В основном файле конфигурации агента вам необходимо включить модуль DogStatsD и указать порт (по умолчанию — 8125).

Для данных, отправляемых с внешнего хоста, агенту Datadog требуется следующая конфигурация: Dogstatsd_non_local_traffic: true и apm_non_local_traffic: true. Вот файлvalues.yaml для одного из кластеров, в котором на этапе развертывания передаются некоторые переменные. Развертывание производится с помощью Azure Devops.

 " datadog: apiKey: #{apiKey}# appKey: #{appKey}# clusterName: #{ClusterName}# kubeStateMetricsEnabled: true clusterChecks: enabled: true dogstatsd: useSocketVolume: false nonLocalTraffic: true collectEvents: false apm: portEnabled: true #тут обязательно включить env: - name: "DD_KUBELET_TLS_VERIFY" value: "false" systemProbe: collectDNSStats: false orchestratorExplorer: enabled: false clusterAgent: image: repository: public.ecr.aws/datadog/cluster-agent tag: #{tag}# admissionController: enabled: false agents: image: repository: public.ecr.aws/datadog/agent tag: #{tag}# doNotCheckTag: true clusterChecksRunner: image: repository: public.ecr.aws/datadog/agent tag: #{tag}# "

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

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

Поскольку агент уже был настроен, одним из способов было добавить в сборку образа необходимые строки и передать в систему CI/CD переменные: DD_ENV, DD_SERVICE, DD_AGENT_HOST, для указания среды, имени сервиса и адреса агента соответственно. . Нам также необходимо добавить следующее в dockerfiles для сервисов:

 " RUN TRACER_VERSION=$(curl -s \https://api.github.com/repos/DataDog/dd-trace-dotnet/releases/latest | grep tag_name | cut -d '"' -f 4 | cut -c2-) \ && curl -Lo /tmp/datadog-dotnet-apm.deb https://github.com/DataDog/dd-trace-dotnet/releases/download/v${TRACER_VERSION}/datadog-dotnet-apm_${TRACER_VERSION}_amd64.deb # Copy the tracer from build target COPY --from=build /tmp/datadog-dotnet-apm.deb /tmp/datadog-dotnet-apm.deb # Install the tracer RUN mkdir -p /opt/datadog \ && mkdir -p /var/log/datadog \ && dpkg -i /tmp/datadog-dotnet-apm.deb \ && rm /tmp/datadog-dotnet-apm.deb # Enable the tracer ENV CORECLR_ENABLE_PROFILING=1 ENV CORECLR_PROFILER={846F5F1C-F9AE-4B07-969E-05C26BC060D8} ENV CORECLR_PROFILER_PATH=/opt/datadog/Datadog.Trace.ClrProfiler.Native.so ENV DD_DOTNET_TRACER_HOME=/opt/datadog ENV DD_INTEGRATIONS=/opt/datadog/integrations.json "

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

 " metadata.labels: tags.datadoghq.com/env: feature tags.datadoghq.com/service: service_name tags.datadoghq.com/version: '1488' spec.template.metadata.labels: admission.datadoghq.com/config.mode: service admission.datadoghq.com/enabled: 'true' tags.datadoghq.com/env: feature tags.datadoghq.com/service: service_name tags.datadoghq.com/version: '1111' spec.template.metadata.annotations: admission.datadoghq.com/dotnet-lib.version: v2.38.0 spec.template.spec.containers.name.env: - name: DD_TRACE_AGENT_URL value: datadog-agent.monitoring - name: DD_TRACE_STARTUP_LOGS value: 'true' - name: DD_LOGS_INJECTION value: 'true' - name: DD_RUNTIME_METRICS_ENABLED value: 'true' - name: DD_PROFILING_ENABLED value: 'true' - name: DD_APPSEC_ENABLED value: 'true' "

Вот что изменилось в агентах:

 " datadog: apm: socketEnabled: true portEnabled: true enabled: true clusterAgent: admissionController: enabled: true mutateUnlabelled: false providers: aks: enabled: true "

После всех этих действий данные с очень подробными метриками для всех сервисов начали поступать в Datadog в раздел APM -> Services, и графики отображались автоматически.

Нам пришлось повозиться с настройками аннотаций для второго метода; не сразу все пошло гладко.

Что касается системы уведомлений, стоит отметить, что она в Datadog удобна и интуитивно понятна. Уведомления создаются в разделе «Мониторы -> Управление мониторами».

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

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

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