为各种未由其他监控守护进程（或处理不佳）的各种内容收集Graphite指标数据
项目描述
graphite-metrics：未由其他监控守护进程（或处理不佳）的各种内容的指标收集器
项目核心是一个简单的守护进程（harvestd），它收集指标值并在每个间隔后将它们发送到graphite carbon守护进程（和/或其他配置的目标）。
包括用于处理以下内容的独立数据收集组件（“收集器”）：
/proc/slabinfo，用于有用的可观察值，不是所有内容（可配置）。
/proc/vmstat和/proc/meminfo以一致的方式。
/proc/stat用于irq、softirq、forks。
/proc/buddyinfo和/proc/pagetypeinfo（内存碎片）。
/proc/interrupts和/proc/softirqs。
Cron日志以生成每个作业的启动/完成事件和持续时间，并将作业适配到指标名称的正则表达式。
使用systemd及其cgroups进行每个系统服务的会计（对于较新版本，必须在system.conf中启用“Default…Accounting=”选项）。
sysstat 的 sadc 日志数据（可以使用类似 sadc -F -L -S DISK -S XDISK -S POWER 60 的命令来记录更多信息）通过 sadf 二进制文件和它的 JSON 导出（sadf -j，自 sysstat-10.0.something 开始支持，据我所知）。
iptables 规则“命中”数据包和字节计数器，来自 ip{,6}tables-save，通过单独的“table chain_name rule_no metric_name”文件映射，该文件应与防火墙规则一起生成（我使用 此脚本 来完成此操作）。
可以通过 setuptools/distribute graphite_metrics.collectors 入口点 添加额外的指标收集器，并通过常见的配置机制进行配置。
同样适用于数据点接收器（目的地 - 不一定是单个碳宿主），数据点处理器（修改/重命名/过滤数据点）和主循环，可以将主循环替换为异步（简单情况 - 线程或 gevent）或缓冲循环。
当前支持的后端（数据目的地，接收器）
graphite carbon 守护进程（默认启用/使用）
请参阅附带收集器、处理器、接收器和循环及其基类（例如 graphite_metrics.sinks.Sink 或 loops.Basic）的 API 示例。
安装
这是一个 Python 2.7 的常规包（不是 3.X）。
使用 pip 是最好的方式
% pip install graphite-metrics
如果您没有，请使用
% easy_install pip % pip install graphite-metrics
或者（另请参阅）
% curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python % pip install graphite-metrics
或者，如果您绝对必须
% easy_install graphite-metrics
但，您真的不应该这么做。
当前 git 版本可以按以下方式安装
% pip install 'git+https://github.com/mk-fg/graphite-metrics.git#egg=graphite-metrics'
要求
基本要求是（pip 或 easy_install 应该可以为您处理这些）
一些附带模块需要额外的包才能运行（可以在安装时指定额外包，例如：pip install 'graphite-metrics[collectors.cgacct]'）
收集器
cgacct
cron_log
sysstat
xattr（除非使用 –xattr-emulation）
（可选）simplejson - 比stdlib json模块有更好的性能
接收器
librato_metrics
（可选）simplejson - 比stdlib json模块有更好的性能
（可选）gevent - 启用通过并发 API 请求进行大块数据恒时（更可扩展）的异步提交
请参阅 requirements.txt 文件或 setup.py 中的“install_requires”和“extras_require”。
运行
第一次运行可能看起来像这样
% harvestd --debug -s dump -i10
这将使用默认配置，启用所有收集器，将数据输出到 stderr（仅启用“dump”数据接收器）并在收集数据点之间使用短（5s）间隔，并输出有关正在执行的操作的附加信息。
之后，请参阅 默认 harvestd.yaml 配置文件，其中包含所有加载的收集器的配置，可以使用 -c 选项覆盖。
请注意，您不需要在覆盖配置中指定所有选项，只需更新您需要的选项即可。
例如，简单的配置文件（例如，/etc/harvestd.yaml）仅用于指定碳主机和日志行格式（删除时间戳，因为它将被管道传输到syslog或systemd-journal）可能如下所示
sinks:
carbon_socket:
host: carbon.example.host
logging:
formatters:
basic:
format: '%(levelname)s :: %(name)s: %(message)s'
启动方式如下：harvestd -c /etc/harvestd.yaml
请参阅harvestd --help输出以获取完整的CLI参考。
注意事项、严厉警告和末日预言
虽然这里的大多数库存收集器每隔一段时间从/proc中拉取指标，与其他工具一样，但请特别注意处理内存指标（如/proc/slabinfo和cgroup值解析器）的收集器。
/proc中的所谓“文件”实际上是内核代码中的回调，为了对整个slabinfo表进行一致的读取，（至少某些版本的内核）必须锁定某些操作，这会导致在特定的工作负载下（例如，memcache服务器）整个系统出现意外的延迟。
cgroup数据收集器在每个收集周期中处理大量文件，可能是数十、数百甚至数千个，这也可能引起类似的问题。
特别感谢Marcus Barczak指出这一点。
原因
大多数其他工具（理论上）可以收集这些数据，我大多数时间使用collectd，但是它
不提供一些最有用的功能 - nfs统计信息、磁盘利用率百分比等。
未能收集某些其他统计信息，产生了奇怪的价值，如0的值，不切实际或负值（对于io、网络、传感器等）。
通用插件（如“tail”）增加了许多复杂性，使配置变得混乱，同时仍缺乏一些基本功能，10行代码（插件）可以轻松提供（支持是有的，但请参见下面）。
插件更改了由/proc提供的度量名称，这些名称在内核文档和互联网上引用，这使得收集的数据难以解释，并对其含义提出了疑问（这对于底层和计算度量越来越重要）。
最初我尝试通过collectd插件（实现相同的收集器）来解决这些问题，但它的Python插件系统被发现会泄漏RAM，collectd本身每天大约崩溃一次，尽管可能是由于C插件中的问题。
此外，collectd数据需要后处理 - 正确的度量命名空间、计数器处理等。
鉴于替代方案是将数据直接以“name val timestamp”的形式发送到tcp套接字，因此决定避免collectd提供的额外复杂性和问题。
除了collectd之外，我还尝试过ganglia、munin和一些其他监控基础设施，但发现重新使用它们的聚合和/或收集基础设施几乎没有理由，如果不是直接的限制（例如，ganglia中的静态数据模式）。
守护进程二进制文件（奇怪地）称为“harvestd”，因为“metricsd”名称已经被用来指代另一个相关的守护进程（还有没有“d”的“metrics”，可能还有其他），而且太通用，没有额外的混淆，我认为。还有，我似乎缺乏创造力来想出一个更合理的名称（“reaperd”现在听起来太像MassEffect了）。
