Datadog Agent是啥？它消耗什么资源？

在资本市场不那么喜人的 2015 年融资 9450 万美元的 Datadog，在运维圈刮起了一阵小旋风。作为国外很值得学习的一款平台监控产品，公司人数不足 100 的 Datadog 为什么吸引了投资人的目光？我们先来了解一下他们的 Agent。

本文系国内 ITOM 行业领军企业 OneAPM 工程师翻译整理自文章 What is the Datadog Agent, What Resources does it Consume?，原作者 Dustin Lawler。

简介

Data dog Agent 是运行在你主机上的一款轻量级软件。它的作用就是忠心耿耿地为你收集事件和性能指标，传到 Datadog 中，以便你利用这些监控和运行数据来做点什么。

点击此处获得 Datadog Agent 的源代码。

Datadog Agent的架构

Data dog Agent 主要由四个用 Python 编写的组件构成，每个组件都是单独运行的进程。

Collector（agent.py）-- Collector 会检查当前运行机器的集成环境，抓取系统性能指标，如内存和 CPU 数据。
Dogstatsd（dogstatsd.py）-- 这是 StatsD 的后台服务器，它致力于收集从你代码中发送出去的本地性能指标。
Forwarder（ddagent.py）-- Forwarder 负责把 Dogstatsd 和 Collector 收集到的数据推到一个队列中，这些数据将会被发往 Datadog。
SupervisorD -- 由一个单独的管理进程控制。我们把它与其他组件分隔开来，因此如果你担心资源消耗而不想运行所有组件的话（虽然我们建议你这么做），可以单独运行它。

学习如何在现有基础上，扩展 agent 的检查内容，或者编写自己的一套版本，请点击此处。

Datadog Agent消耗的资源

Datadog Agent的资源消耗大致如下：

常驻内存：50MB
CPU时间：平均小于1%
硬盘空间：
Linux：120MB
Windows：60MB
带宽占用：每分钟 10-50 KB

上述数据是基于一个运行了十多天的 EC2 m1.large 实例。

监控、权限和网络端口

Supervisors 作为一个主控根进程运行，可以 fork 所有的子进程为user dd-agent，其配置文件在/etc/dd-agent/datadog.conf和 /etc/dd-agent/conf.d下可以找到。所有的配置对 dd-agent 来说都必须可读。推荐使用权限 0600，因为配置文件中包含你的 API key，以及其它访问性能指标（如 mysql，postgresql metrics）所需的证书。

以下端口对一般操作开放：

为一般操作提供的 forwarder tcp/17123 端口和启用了 graphite 服务时的 tcp/17124端口
dogstatsd udp/8125

在 3.4.1 或以上版本中，所有监听进程都默认绑定 127.0.0.1 和 / 或者 ::1。而早期版本中，他们则绑定至 0.0.0.0 （例如所有的接口）。

关于如何通过代理运行agent，请戳这里；关于允许的范围，请看这里。

Collector

这是收集所有标准性能指标的地方，每十五秒收集一次。
Collector 也支持运行基于 python 的用户定义的检查内容。这些内容应存储于/etc/dd-agent/checks.d下。用户定义的检查内容必须从抽象类 AgentCheck 继承，这个类定义在 checks/init.py中。

Forwarder

Forwarder 监听并缓存传入的HTTP请求，接着通过 HTTPS 转发到 Datadog 中心。缓存请求使得网络可以一分为二，不影响性能指标的上报。性能指标将被缓存在内存中，直到达到必须发送的大小或数目才会被发送。接着，最老的性能数据包就会被丢弃，以确保 forwarder 有足够的存储空间。

DogStatsD

DogStatsD 是用 python 实现的 esty statsD 性能指标整合进程，用于通过UDP协议接收和积累任意的性能指标，这样我们就可以度量自定义代码，而不会增加延迟。

关于dgostatsd的更多信息请看这里。

Agent的优点

想要了解使用 Datadog agent 究竟有什么好处，可以参考下面的两篇文章：

再说几句

Dustin Lawler 关于 Datadog Agent 的原理的讲解思路清晰。Datadog 本身在国外拥有 Facebook、Airbnb 等重量级客户，被业界极力看好。而国内一些大公司的运维人员往往只知道 Zabbix 等开源产品，对 StatsD 系监控产品的了解比较少。而 StatsD 作为新世代的系统监控的核心，目前还处于技术累计过程。越来越多的开源项目加入到它的怀抱中，也有越来越多的公司，在此基础之上加入了研发的资源，或者在与之相关的其他领域中投入成本。

国内也有一款像 Datadog 一样基于 StatsD，提供一体化监控解决方案的产品 Cloud Insight，能够监控大规模集群、云主机、Docker 容器，支持多种操作系统、数据库、中间件等，在数据采集、计算和展现的基础上，还拥有跨部门事件流展现、报警等功能，是一款 DevOps+ChatOps 理念的产品。

有关 StatsD 和 Cloud Insight 的更多内容，可以参考以下文章：

本文转自 OneAPM 官方博客