如何使用 Datadog 进行 APM 指标应用程序

有效的指标和监控在高质量开发、错误修复以及用户请求和事件处理中发挥着关键作用。在 Social Discovery Group，我们采用多种工具来评估我们产品的性能。

在本文中，我们将分享一些如何在 Datadog 的帮助下构建稳定的应用程序监控和指标系统并减少产品错误检测时间的技巧。

SDG 产品正在帮助全球超过 2.5 亿人建立联系和建立关系，而且我们的用户群正在不断增长。这一成功的主要因素是我们能够及时响应用户需求。我们在使用各种监控系统（包括 Datadog）方面拥有丰富的经验。原因如下：

1. 目前，Datadog 提供了多种不同级别系统的集成选项。您可以在此处探索这些功能。

   
   

2. Datadog 提供了用于配置与各种服务的集成的全面文档。

   
   

3. 我们成功建立了牢固的伙伴关系。

在这里，我们将分享在 Datadog 的 Kubernetes 集群中为应用程序设置和配置 APM 指标的经验。本文不会介绍 AKS 中的项目部署、CI/CD 流程以及其他 DevOps 详细信息。

相反，我们将重点关注为 APM 指标配置 Datadog 监控的细节。

使用的技术堆栈：Azure Services、Azure Kubernetes Service (AKS)、ASP .Net Core 7、Datadog。

为了监控应用程序和服务，我们通过 Helm 图表使用部署在集群内的 Datadog 代理，并使用 value.yaml 文件中的其他参数。在主代理配置文件中，您需要启用 DogStatsD 模块并指定端口（默认为 8125）。

对于从外部主机发送的数据，Datadog 代理需要以下配置：dogstatsd_non_local_traffic: true 和 apm_non_local_traffic: true。以下是其中一个集群的 value.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 "

完成所有这些步骤后，所有服务的包含高度详细指标的数据开始在 APM -> 服务部分下的 Datadog 中流动，并且图表会自动显示。

我们必须修改第二种方法的注释设置；并非所有事情都立即开始顺利进行。

关于通知系统，值得一提的是，Datadog 中的通知系统非常用户友好且直观。通知是在“监视器 -> 管理监视器”部分中创建的。

我们上面描述的改进产生了一些有价值的成果。我们现在对我们的系统如何运行和适应各种变化有了更深入的了解。

此外，我们还建立了一个稳定的应用程序监控和指标系统，该系统独立于服务构建运行，有助于减少错误检测时间。

这反过来又使我们能够优化我们的服务并提高开发速度和整体系统质量。