在资本市场不那么喜人的 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 的源代码。
Data dog Agent 主要由四个用 Python 编写的组件构成,每个组件都是单独运行的进程。
学习如何在现有基础上,扩展 agent 的检查内容,或者编写自己的一套版本, 请点击此处 。
Datadog Agent的资源消耗大致如下:
上述数据是基于一个运行了十多天的 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)所需的证书。
以下端口对一般操作开放:
在 3.4.1 或以上版本中,所有监听进程都默认绑定 127.0.0.1 和 / 或者 ::1。而早期版本中,他们则绑定至 0.0.0.0 (例如所有的接口)。
关于如何通过代理运行agent, 请戳这里 ;关于允许的范围, 请看这里 。
这是收集所有标准性能指标的地方,每十五秒收集一次。 Collector 也支持运行基于 python 的用户定义的检查内容。这些内容应存储于 /etc/dd-agent/checks.d
下。用户定义的检查内容必须从抽象类 AgentCheck 继承,这个类定义在 checks/init.py 中。
Forwarder 监听并缓存传入的HTTP请求,接着通过 HTTPS 转发到 Datadog 中心。缓存请求使得网络可以一分为二,不影响性能指标的上报。性能指标将被缓存在内存中,直到达到必须发送的大小或数目才会被发送。接着,最老的性能数据包就会被丢弃,以确保 forwarder 有足够的存储空间。
DogStatsD 是用 python 实现的 esty statsD 性能指标整合进程,用于通过UDP协议接收和积累任意的性能指标,这样我们就可以度量自定义代码,而不会增加延迟。
关于dgostatsd的更多信息 请看这里 。
想要了解使用 Datadog agent 究竟有什么好处,可以参考下面的两篇文章:
Dustin Lawler 关于 Datadog Agent 的原理的讲解思路清晰。Datadog 本身在国外拥有 Facebook、Airbnb 等重量级客户,被业界极力看好。而国内一些大公司的运维人员往往只知道 Zabbix 等开源产品,对 StatsD 系监控产品的了解比较少。而 StatsD 作为新世代的系统监控的核心,目前还处于技术累计过程。越来越多的开源项目加入到它的怀抱中,也有越来越多的公司,在此基础之上加入了研发的资源,或者在与之相关的其他领域中投入成本。
国内也有一款像 Datadog 一样基于StatsD,提供一体化监控解决方案的产品Cloud Insight,能够监控大规模集群、云主机、Docker 容器,支持多种操作系统、数据库、中间件等,在数据采集、计算和展现的基础上,还拥有跨部门事件流展现、报警等功能,是一款DevOps+ChatOps 理念的产品。
有关 StatsD 和 Cloud Insight 的更多内容,可以参考以下文章: