尧图网站建设 
可观测性数据可视化后端【免费下载链接】graphite-webA highly scalable real-time graphing system项目地址https://gitcode.com/gh_mirrors/gr/graphite-web点击查看免费下载Carbon 是 Graphite 安装中的存储后端由若干守护进程组成负责接收指标数据并将其写入磁盘。本文以官方文档 docs/carbon-daemons.rst 为骨架系统讲解carbon-cache.py、carbon-relay.py、carbon-aggregator.py与carbon-aggregator-cache.py的职责分工、适用场景与配置要点并结合本仓库中的 carbonlink.py、hashing.py 等源码揭示读写路径与一致哈希分片的底层实现。读完本文你将掌握如何根据指标规模设计多实例、分片、复制与聚合的完整 Carbon 存储拓扑。一、Carbon 是什么Graphite 的存储后端在 Graphite 的三组件架构Carbon、Whisper、Graphite Webapp中Carbon 扮演数据入口的角色它是一组基于 Twisted 的守护进程监听时间序列数据并通过底层 whisper 库把数据高效写入磁盘Graphite Webapp 则负责按需渲染图形。整体架构可参考 docs/overview.rst 中的说明。当我们谈论 Carbon 时实际指的是构成存储后端的一个或多个守护进程简单安装中通常只有一个守护进程carbon-cache.py随着安装规模增长可以引入carbon-relay.py来分发指标负载以及carbon-aggregator.py来执行自定义聚合。所有 Carbon 守护进程都监听时间序列数据并可以通过同一套协议接收数据详见 docs/feeding-carbon.rst。它们之间的区别在于收到数据之后如何处理。以下逐一说明每个守护进程的功能及使用方式。二、carbon-cache.py核心写入与热数据查询服务carbon-cache.py是存储后端的核心它通过多种协议接收指标并尽可能高效地将其写入磁盘。其工作方式是接收指标时先把数值缓存在内存RAM中按照固定时间间隔使用底层 whisper 库把缓存批量刷入磁盘同时对外提供内存指标数据点的查询服务供 Graphite Webapp 获取热数据。换句话说carbon-cache.py既是写入者把数据落盘也是热数据查询服务让 Webapp 读取最近尚未落盘或仍在缓存中的数据避免每次都访问磁盘。这个查询服务就是 Webapp 侧 CarbonLink 客户端所连接的端口详见下文一致哈希与 CarbonLink小节。2.1 运行所需的配置文件carbon-cache.py需要以下基础配置文件才能运行carbon.conf ——[cache]部分该部分告诉carbon-cache.py监听哪些端口默认 2003/2004/7002、使用哪些协议换行分隔的 plaintext、pickle以及传输方式TCP/UDP。配置文件均位于/opt/graphite/conf/目录下安装后需将.conf.example复制为.confpushd /opt/graphite/conf cp carbon.conf.example carbon.conf cp storage-schemas.conf.example storage-schemas.confstorage-schemas.conf —— 保留策略基于正则表达式模式为进入的指标定义保留策略retention policy。该策略在.wsp文件预分配时传递给 whisper决定了数据存储多长时间、以什么精度存储。更完整的格式说明见 docs/config-carbon.rst。一个典型的保留策略条目由三行组成——方括号中的名称、pattern后的正则、以及retentions后的保留行[garbage_collection] pattern garbageCollections$ retentions 10s:14dretentions中的10s:14d表示每个数据点代表 10 秒、总计保留 14 天的数据后缀s/m/h/d/w/y分别表示秒、分、时、天、周、年。多个保留级别用逗号分隔例如15s:7d,1m:21d,15m:5ywhisper 会按最精确→最短历史到最粗略→最长历史的顺序进行下采样默认取平均。2.2 扩展性多实例横向扩展当进入的指标数量增加时单个carbon-cache.py实例可能无法承受 I/O 负载。此时可以在一个或多个机器上运行多个carbon-cache.py实例并在其前面放置carbon-aggregator.py或carbon-relay.py来分担负载——这正是后两个守护进程存在的意义。2.3 常见故障文件描述符耗尽EMFILE官方文档特别提醒如果连接到carbon-cache.py的客户端遇到connection refused等错误常见原因是文件描述符短缺。在console.log日志中若发现以下任一信息Could not accept new connection (EMFILE)或exceptions.IOError: [Errno 24] Too many open files: /var/lib/graphite/whisper/systems/somehost/something.wsp则说明carbon-cache.py可打开的文件数已到上限需要调高。许多系统默认最大文件描述符为 1024根据同时连接的客户端数量可能把该值提高到 8192 或更高。在 Linux 上系统全局文件描述符上限可通过 sysctl 设置进程级限制则通过 ulimit 设置具体取决于所用发行版的文档。三、carbon-relay.py复制与分片carbon-relay.py承担两个截然不同的职责复制replication与分片sharding。3.1 RELAY_METHOD rules按规则转发当以RELAY_METHOD rules运行时carbon-relay.py实例可以代替carbon-cache.py服务器把进入的所有指标转发到运行在不同端口或不同主机上的多个后端carbon-cache.py。这一模式常用于高可用同一份数据写入多个副本按指标划分归属不同正则规则转发到不同后端。其转发规则定义在relay-rules.conf中每条规则由方括号名称、pattern正则和servers服务器列表组成[example] pattern ^mydata\.foo\.. servers 10.1.2.3, 10.1.2.4:2004, myserver.mydomain.com注意servers列表中至少要定义一个默认规则条目否则没有匹配规则的指标将无处可去。3.2 RELAY_METHOD consistent-hashing一致性哈希分片在RELAY_METHOD consistent-hashing模式下carbon.conf的[relay]部分中由DESTINATIONS设置定义跨多个carbon-cache.py后端的分片策略每个指标根据其名称的哈希值被稳定地路由到某个后端实例。一致性哈希的优点是后端节点增减时只有少量指标的归属发生变化无需全量重新分布。更关键的是同一个一致性哈希列表也要提供给 Graphite Webapp通过CARBONLINK_HOSTS从而把读取请求也分散到多个后端——写入与读取使用同一哈希环才能保证某条指标数据被写入哪个实例就从哪个实例读到。官方配置建议还提醒carbon-cache 和 carbon-relay 可以运行在同一主机上。若如此做可互换[cache]与[relay]部分的LINE_RECEIVER_PORT和PICKLE_RECEIVER_PORT默认端口以避免重新配置已有的指标发送端同时在[relay]中设置DESTINATIONS时要记得使用你为[cache]新设置的PICKLE_RECEIVER_PORT。3.3 一致哈希与 CarbonLink 的源码实现Webapp 侧读取路径正是围绕一致哈希构建的。在 webapp/graphite/render/hashing.py 中实现了ConsistentHashRing类每个节点在哈希环上生成多个副本默认replica_count100副本键格式为%s:%d % (key, i)carbonHash()支持三种哈希类型传统的carbon_ch取 MD5 前 4 字节转 int、fnv1a_chFNV-1a 哈希与mmh3_ch需安装 mmh3 库get_node()/get_nodes()通过二分查找bisect在环上定位指标归属的节点。Webapp 侧的连接池实现在 webapp/graphite/carbonlink.py 中CarbonLinkPool.select_host()对指标名应用keyfunc默认恒等函数后用同一哈希环选出目标主机并支持REPLICATION_FACTOR级别的副本选择与失败主机黑名单CARBONLINK_RETRY_DELAY。它发送的cache-query、get-metadata、set-metadata请求即为碳缓存查询协议对应carbon-cache.py的 7002 查询端口。相关默认配置见 webapp/graphite/settings.pyCARBONLINK_HOSTS [127.0.0.1:7002] CARBONLINK_TIMEOUT 1.0 CARBONLINK_HASHING_KEYFUNC None CARBONLINK_HASHING_TYPE carbon_ch CARBONLINK_RETRY_DELAY 15 CARBONLINK_PICKLE_PROTOCOL -1多实例场景下的写法可参考 webapp/graphite/local_settings.py.example每个条目为ip:查询端口:实例名例如CARBONLINK_HOSTS [127.0.0.1:7002:a, 127.0.0.1:7102:b, 127.0.0.1:7202:c]官方注释特别强调如果使用一致哈希CARBONLINK_HOSTS中主机的顺序必须与 relay 中DESTINATIONS的顺序保持一致否则会造成缓存未命中cache misses。这也是[relay]分片与 Webapp 读取正确配对的要点。3.4 carbon-relay.py 的配置清单carbon-relay.py通过以下文件配置carbon.conf ——[relay]部分定义监听主机/端口与RELAY_METHODrelay-rules.conf当RELAY_METHOD rules时其中的 pattern/servers 元组定义哪些匹配特定正则的指标被转发到哪些主机。四、carbon-aggregator.py缓冲与自定义聚合carbon-aggregator.py可以运行在carbon-cache.py之前用于在一段时间内缓冲指标然后再上报到 whisper。这在以下场景非常有用不需要细粒度上报时降低 I/O 负载由于保留策略更粗可以减小 whisper 文件体积多个主机上报同一指标时先在入口合并为一条。4.1 聚合规则aggregation-rules.confaggregation-rules.conf为匹配特定模式的指标定义聚合时间间隔秒和聚合函数sum 或 average 等。每个时间间隔结束时收到的值被聚合并作为单一指标发布给carbon-cache.py。规则格式为output_template (frequency) method input_pattern例如指标命名方案为env.applications.app.server.metric时env.applications.app.all.requests (60) sum env.applications.app.*.requests env.applications.app.all.latency (60) avg env.applications.app.*.latency当收到prod.applications.apache.www01.requests等 5 条请求指标后60 秒间隔结束时会计算出聚合指标prod.applications.apache.all.requests。可用聚合方法包括sum、avg、min、max、p50、p75、p80、p90、p95、p99、p999、countp999即 99.9 百分位。使用百分位聚合方法需谨慎因为再聚合re-aggregation的行为与直觉不同。模板细节env这样的单尖括号组件匹配到下一个点为止app_metric双尖括号可匹配包含点的多个组件也支持正则如domain\d{2}。与某些配置文件不同修改 aggregation-rules.conf 会立即生效无需重启前提是 carbon-aggregator 服务在运行。这为动态调整聚合策略提供了便利。4.2 重写规则rewrite-rules.confrewrite-rules.conf允许使用 Python 正则表达式重写指标名采用搜索 替换的方式。它分为[pre]和[post]两个部分[pre]中的规则在指标名一被接收时就应用[post]中的规则在聚合完成之后应用。每行格式为regex-pattern replacement-text支持捕获组^collectd\.([a-z0-9])\. \1.system.结果示例collectd.prod.cpu-0.idle-time→prod.system.cpu-0.idle-item。再如[post]中常见的去除聚合后缀[post] _sum$ _avg$ 注意如果规则中需要使用字符请使用其八进制转义值\075例如foobar foo.bar应写成foo\075bar foo.bar。该文件同样支持热加载修改后自动生效。4.3 白名单与黑名单carbon.conf 中的USE_WHITELIST标志可以启用白名单/黑名单功能让任意 Carbon 守护进程只接受被显式白名单允许的指标并/或拒绝黑名单中的指标。这在指标过多、或存在发送无效指标的上游时非常有用。GRAPHITE_CONF_DIR下会查找whitelist.conf和blacklist.conf每个文件每行一个正则表达式。若白名单配置缺失或为空默认放行所有指标。五、carbon-aggregator-cache.py合并后的单进程方案carbon-aggregator-cache.py将carbon-aggregator.py与carbon-cache.py的功能合并到一个进程中。当聚合量与写入量都较小、但希望减少资源占用与管理开销时这是一个更简洁的选择。其配置清单为carbon.conf ——[aggregator-cache]部分定义监听与目标主机/端口relay-rules.conf同carbon-relay.py一节所述aggregation-rules.conf同carbon-aggregator.py一节所述rewrite-rules.conf同carbon-aggregator.py一节所述。六、统一的数据接入协议无论使用哪个守护进程数据都可以通过同一套协议送入 Carbon详见 docs/feeding-carbon.rst只是不同协议面向不同场景plaintext 协议默认端口 2003最直白格式为metric path metric value metric timestamp。可用 netcat 快速测试PORT2003 SERVERgraphite.your.org echo local.random.diceroll 4 date %s | nc ${SERVER} ${PORT}若 Carbon 以 UDP 监听还需加-u参数nc实现不同可能需要-q0、-c或-N让发送后关闭连接。pickle 协议默认端口 2004更高效支持一次批量发送。数据结构为[(path, (timestamp, value)), ...]的列表pickle 后加 4 字节大端长度头再发送payload pickle.dumps(listOfMetricTuples, protocol2) header struct.pack(!L, len(payload)) message header payloadAMQP当AMQP_METRIC_NAME_IN_BODY为 True 时消息体格式与 plaintext 相同为 False 时省略指标名。时间戳为-1时carbon-cache.py会使用数据到达时间作为时间戳。指标名、值与时间戳的具体规范同样记录在 docs/feeding-carbon.rst。七、小结如何按规模选择部署拓扑综合以上内容可以按部署规模画出清晰的选型路径场景推荐拓扑关键配置单机小规模仅运行carbon-cache.py[cache]端口与storage-schemas.conf指标量大、需水平扩展relay 多 cache 实例[relay]的RELAY_METHODconsistent-hashing、DESTINATIONSWebapp 侧CARBONLINK_HOSTS顺序一致高可用、多副本relayrules 模式转发到多后端relay-rules.conf的 pattern/servers无需细粒度、降低 I/O 与磁盘aggregator 前置聚合aggregation-rules.conf、rewrite-rules.conf聚合缓存合并管理carbon-aggregator-cache.py单进程[aggregator-cache]与聚合/重写规则所有守护进程共用同一套接入协议与storage-schemas.conf保留策略体系细节可继续阅读 docs/config-carbon.rst含storage-aggregation.conf的下采样聚合方法配置。把握写入端分片、读取端同环、聚合减载、复制保高可用四条主线即可构建一套可平滑扩容的 Graphite 存储后端。赞分享可观测性数据可视化后端【免费下载链接】graphite-webA highly scalable real-time graphing system项目地址https://gitcode.com/gh_mirrors/gr/graphite-web点击查看免费下载相关推荐go-carbon高效性能的 Graphite/CARBON 服务器实现go carbon高效性能的 Graphite/CARBON 服务器实现 在现代监控系统中Graphite 是一个广泛使用的开源解决方案用于存储和检索时间Windows 11 激活怎么办MAS 免费激活的 3 条路线指南Windows 11 激活怎么办MAS 免费激活的 3 条路线指南 右下角挂着未激活水印MASMicrosoft Activation Scripts操作系统基于 Carbon 构建自己的图标库从 carbon/icons 到 carbon/icon-helpers 的完整实战指南基于 Carbon 构建自己的图标库从 carbon/icons 到 carbon/icon helpers 的完整实战指南 本指南基于 Carbon D前端UI组件设计系统上一篇告别繁琐字幕制作VideoCaptioner如何用AI实现从语音到完美字幕的全流程自动化下一篇RuView BFLD 隐私门控层如何保证 BFI 原始数据不出节点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Graphite Carbon 守护进程全解析：carbon-cache、carbon-relay 与 carbon-aggregator 的架构与配置实战
可观测性数据可视化后端【免费下载链接】graphite-webA highly scalable real-time graphing system项目地址https://gitcode.com/gh_mirrors/gr/graphite-web点击查看免费下载Carbon 是 Graphite 安装中的存储后端由若干守护进程组成负责接收指标数据并将其写入磁盘。本文以官方文档 docs/carbon-daemons.rst 为骨架系统讲解carbon-cache.py、carbon-relay.py、carbon-aggregator.py与carbon-aggregator-cache.py的职责分工、适用场景与配置要点并结合本仓库中的 carbonlink.py、hashing.py 等源码揭示读写路径与一致哈希分片的底层实现。读完本文你将掌握如何根据指标规模设计多实例、分片、复制与聚合的完整 Carbon 存储拓扑。一、Carbon 是什么Graphite 的存储后端在 Graphite 的三组件架构Carbon、Whisper、Graphite Webapp中Carbon 扮演数据入口的角色它是一组基于 Twisted 的守护进程监听时间序列数据并通过底层 whisper 库把数据高效写入磁盘Graphite Webapp 则负责按需渲染图形。整体架构可参考 docs/overview.rst 中的说明。当我们谈论 Carbon 时实际指的是构成存储后端的一个或多个守护进程简单安装中通常只有一个守护进程carbon-cache.py随着安装规模增长可以引入carbon-relay.py来分发指标负载以及carbon-aggregator.py来执行自定义聚合。所有 Carbon 守护进程都监听时间序列数据并可以通过同一套协议接收数据详见 docs/feeding-carbon.rst。它们之间的区别在于收到数据之后如何处理。以下逐一说明每个守护进程的功能及使用方式。二、carbon-cache.py核心写入与热数据查询服务carbon-cache.py是存储后端的核心它通过多种协议接收指标并尽可能高效地将其写入磁盘。其工作方式是接收指标时先把数值缓存在内存RAM中按照固定时间间隔使用底层 whisper 库把缓存批量刷入磁盘同时对外提供内存指标数据点的查询服务供 Graphite Webapp 获取热数据。换句话说carbon-cache.py既是写入者把数据落盘也是热数据查询服务让 Webapp 读取最近尚未落盘或仍在缓存中的数据避免每次都访问磁盘。这个查询服务就是 Webapp 侧 CarbonLink 客户端所连接的端口详见下文一致哈希与 CarbonLink小节。2.1 运行所需的配置文件carbon-cache.py需要以下基础配置文件才能运行carbon.conf ——[cache]部分该部分告诉carbon-cache.py监听哪些端口默认 2003/2004/7002、使用哪些协议换行分隔的 plaintext、pickle以及传输方式TCP/UDP。配置文件均位于/opt/graphite/conf/目录下安装后需将.conf.example复制为.confpushd /opt/graphite/conf cp carbon.conf.example carbon.conf cp storage-schemas.conf.example storage-schemas.confstorage-schemas.conf —— 保留策略基于正则表达式模式为进入的指标定义保留策略retention policy。该策略在.wsp文件预分配时传递给 whisper决定了数据存储多长时间、以什么精度存储。更完整的格式说明见 docs/config-carbon.rst。一个典型的保留策略条目由三行组成——方括号中的名称、pattern后的正则、以及retentions后的保留行[garbage_collection] pattern garbageCollections$ retentions 10s:14dretentions中的10s:14d表示每个数据点代表 10 秒、总计保留 14 天的数据后缀s/m/h/d/w/y分别表示秒、分、时、天、周、年。多个保留级别用逗号分隔例如15s:7d,1m:21d,15m:5ywhisper 会按最精确→最短历史到最粗略→最长历史的顺序进行下采样默认取平均。2.2 扩展性多实例横向扩展当进入的指标数量增加时单个carbon-cache.py实例可能无法承受 I/O 负载。此时可以在一个或多个机器上运行多个carbon-cache.py实例并在其前面放置carbon-aggregator.py或carbon-relay.py来分担负载——这正是后两个守护进程存在的意义。2.3 常见故障文件描述符耗尽EMFILE官方文档特别提醒如果连接到carbon-cache.py的客户端遇到connection refused等错误常见原因是文件描述符短缺。在console.log日志中若发现以下任一信息Could not accept new connection (EMFILE)或exceptions.IOError: [Errno 24] Too many open files: /var/lib/graphite/whisper/systems/somehost/something.wsp则说明carbon-cache.py可打开的文件数已到上限需要调高。许多系统默认最大文件描述符为 1024根据同时连接的客户端数量可能把该值提高到 8192 或更高。在 Linux 上系统全局文件描述符上限可通过 sysctl 设置进程级限制则通过 ulimit 设置具体取决于所用发行版的文档。三、carbon-relay.py复制与分片carbon-relay.py承担两个截然不同的职责复制replication与分片sharding。3.1 RELAY_METHOD rules按规则转发当以RELAY_METHOD rules运行时carbon-relay.py实例可以代替carbon-cache.py服务器把进入的所有指标转发到运行在不同端口或不同主机上的多个后端carbon-cache.py。这一模式常用于高可用同一份数据写入多个副本按指标划分归属不同正则规则转发到不同后端。其转发规则定义在relay-rules.conf中每条规则由方括号名称、pattern正则和servers服务器列表组成[example] pattern ^mydata\.foo\.. servers 10.1.2.3, 10.1.2.4:2004, myserver.mydomain.com注意servers列表中至少要定义一个默认规则条目否则没有匹配规则的指标将无处可去。3.2 RELAY_METHOD consistent-hashing一致性哈希分片在RELAY_METHOD consistent-hashing模式下carbon.conf的[relay]部分中由DESTINATIONS设置定义跨多个carbon-cache.py后端的分片策略每个指标根据其名称的哈希值被稳定地路由到某个后端实例。一致性哈希的优点是后端节点增减时只有少量指标的归属发生变化无需全量重新分布。更关键的是同一个一致性哈希列表也要提供给 Graphite Webapp通过CARBONLINK_HOSTS从而把读取请求也分散到多个后端——写入与读取使用同一哈希环才能保证某条指标数据被写入哪个实例就从哪个实例读到。官方配置建议还提醒carbon-cache 和 carbon-relay 可以运行在同一主机上。若如此做可互换[cache]与[relay]部分的LINE_RECEIVER_PORT和PICKLE_RECEIVER_PORT默认端口以避免重新配置已有的指标发送端同时在[relay]中设置DESTINATIONS时要记得使用你为[cache]新设置的PICKLE_RECEIVER_PORT。3.3 一致哈希与 CarbonLink 的源码实现Webapp 侧读取路径正是围绕一致哈希构建的。在 webapp/graphite/render/hashing.py 中实现了ConsistentHashRing类每个节点在哈希环上生成多个副本默认replica_count100副本键格式为%s:%d % (key, i)carbonHash()支持三种哈希类型传统的carbon_ch取 MD5 前 4 字节转 int、fnv1a_chFNV-1a 哈希与mmh3_ch需安装 mmh3 库get_node()/get_nodes()通过二分查找bisect在环上定位指标归属的节点。Webapp 侧的连接池实现在 webapp/graphite/carbonlink.py 中CarbonLinkPool.select_host()对指标名应用keyfunc默认恒等函数后用同一哈希环选出目标主机并支持REPLICATION_FACTOR级别的副本选择与失败主机黑名单CARBONLINK_RETRY_DELAY。它发送的cache-query、get-metadata、set-metadata请求即为碳缓存查询协议对应carbon-cache.py的 7002 查询端口。相关默认配置见 webapp/graphite/settings.pyCARBONLINK_HOSTS [127.0.0.1:7002] CARBONLINK_TIMEOUT 1.0 CARBONLINK_HASHING_KEYFUNC None CARBONLINK_HASHING_TYPE carbon_ch CARBONLINK_RETRY_DELAY 15 CARBONLINK_PICKLE_PROTOCOL -1多实例场景下的写法可参考 webapp/graphite/local_settings.py.example每个条目为ip:查询端口:实例名例如CARBONLINK_HOSTS [127.0.0.1:7002:a, 127.0.0.1:7102:b, 127.0.0.1:7202:c]官方注释特别强调如果使用一致哈希CARBONLINK_HOSTS中主机的顺序必须与 relay 中DESTINATIONS的顺序保持一致否则会造成缓存未命中cache misses。这也是[relay]分片与 Webapp 读取正确配对的要点。3.4 carbon-relay.py 的配置清单carbon-relay.py通过以下文件配置carbon.conf ——[relay]部分定义监听主机/端口与RELAY_METHODrelay-rules.conf当RELAY_METHOD rules时其中的 pattern/servers 元组定义哪些匹配特定正则的指标被转发到哪些主机。四、carbon-aggregator.py缓冲与自定义聚合carbon-aggregator.py可以运行在carbon-cache.py之前用于在一段时间内缓冲指标然后再上报到 whisper。这在以下场景非常有用不需要细粒度上报时降低 I/O 负载由于保留策略更粗可以减小 whisper 文件体积多个主机上报同一指标时先在入口合并为一条。4.1 聚合规则aggregation-rules.confaggregation-rules.conf为匹配特定模式的指标定义聚合时间间隔秒和聚合函数sum 或 average 等。每个时间间隔结束时收到的值被聚合并作为单一指标发布给carbon-cache.py。规则格式为output_template (frequency) method input_pattern例如指标命名方案为env.applications.app.server.metric时env.applications.app.all.requests (60) sum env.applications.app.*.requests env.applications.app.all.latency (60) avg env.applications.app.*.latency当收到prod.applications.apache.www01.requests等 5 条请求指标后60 秒间隔结束时会计算出聚合指标prod.applications.apache.all.requests。可用聚合方法包括sum、avg、min、max、p50、p75、p80、p90、p95、p99、p999、countp999即 99.9 百分位。使用百分位聚合方法需谨慎因为再聚合re-aggregation的行为与直觉不同。模板细节env这样的单尖括号组件匹配到下一个点为止app_metric双尖括号可匹配包含点的多个组件也支持正则如domain\d{2}。与某些配置文件不同修改 aggregation-rules.conf 会立即生效无需重启前提是 carbon-aggregator 服务在运行。这为动态调整聚合策略提供了便利。4.2 重写规则rewrite-rules.confrewrite-rules.conf允许使用 Python 正则表达式重写指标名采用搜索 替换的方式。它分为[pre]和[post]两个部分[pre]中的规则在指标名一被接收时就应用[post]中的规则在聚合完成之后应用。每行格式为regex-pattern replacement-text支持捕获组^collectd\.([a-z0-9])\. \1.system.结果示例collectd.prod.cpu-0.idle-time→prod.system.cpu-0.idle-item。再如[post]中常见的去除聚合后缀[post] _sum$ _avg$ 注意如果规则中需要使用字符请使用其八进制转义值\075例如foobar foo.bar应写成foo\075bar foo.bar。该文件同样支持热加载修改后自动生效。4.3 白名单与黑名单carbon.conf 中的USE_WHITELIST标志可以启用白名单/黑名单功能让任意 Carbon 守护进程只接受被显式白名单允许的指标并/或拒绝黑名单中的指标。这在指标过多、或存在发送无效指标的上游时非常有用。GRAPHITE_CONF_DIR下会查找whitelist.conf和blacklist.conf每个文件每行一个正则表达式。若白名单配置缺失或为空默认放行所有指标。五、carbon-aggregator-cache.py合并后的单进程方案carbon-aggregator-cache.py将carbon-aggregator.py与carbon-cache.py的功能合并到一个进程中。当聚合量与写入量都较小、但希望减少资源占用与管理开销时这是一个更简洁的选择。其配置清单为carbon.conf ——[aggregator-cache]部分定义监听与目标主机/端口relay-rules.conf同carbon-relay.py一节所述aggregation-rules.conf同carbon-aggregator.py一节所述rewrite-rules.conf同carbon-aggregator.py一节所述。六、统一的数据接入协议无论使用哪个守护进程数据都可以通过同一套协议送入 Carbon详见 docs/feeding-carbon.rst只是不同协议面向不同场景plaintext 协议默认端口 2003最直白格式为metric path metric value metric timestamp。可用 netcat 快速测试PORT2003 SERVERgraphite.your.org echo local.random.diceroll 4 date %s | nc ${SERVER} ${PORT}若 Carbon 以 UDP 监听还需加-u参数nc实现不同可能需要-q0、-c或-N让发送后关闭连接。pickle 协议默认端口 2004更高效支持一次批量发送。数据结构为[(path, (timestamp, value)), ...]的列表pickle 后加 4 字节大端长度头再发送payload pickle.dumps(listOfMetricTuples, protocol2) header struct.pack(!L, len(payload)) message header payloadAMQP当AMQP_METRIC_NAME_IN_BODY为 True 时消息体格式与 plaintext 相同为 False 时省略指标名。时间戳为-1时carbon-cache.py会使用数据到达时间作为时间戳。指标名、值与时间戳的具体规范同样记录在 docs/feeding-carbon.rst。七、小结如何按规模选择部署拓扑综合以上内容可以按部署规模画出清晰的选型路径场景推荐拓扑关键配置单机小规模仅运行carbon-cache.py[cache]端口与storage-schemas.conf指标量大、需水平扩展relay 多 cache 实例[relay]的RELAY_METHODconsistent-hashing、DESTINATIONSWebapp 侧CARBONLINK_HOSTS顺序一致高可用、多副本relayrules 模式转发到多后端relay-rules.conf的 pattern/servers无需细粒度、降低 I/O 与磁盘aggregator 前置聚合aggregation-rules.conf、rewrite-rules.conf聚合缓存合并管理carbon-aggregator-cache.py单进程[aggregator-cache]与聚合/重写规则所有守护进程共用同一套接入协议与storage-schemas.conf保留策略体系细节可继续阅读 docs/config-carbon.rst含storage-aggregation.conf的下采样聚合方法配置。把握写入端分片、读取端同环、聚合减载、复制保高可用四条主线即可构建一套可平滑扩容的 Graphite 存储后端。赞分享可观测性数据可视化后端【免费下载链接】graphite-webA highly scalable real-time graphing system项目地址https://gitcode.com/gh_mirrors/gr/graphite-web点击查看免费下载相关推荐go-carbon高效性能的 Graphite/CARBON 服务器实现go carbon高效性能的 Graphite/CARBON 服务器实现 在现代监控系统中Graphite 是一个广泛使用的开源解决方案用于存储和检索时间Windows 11 激活怎么办MAS 免费激活的 3 条路线指南Windows 11 激活怎么办MAS 免费激活的 3 条路线指南 右下角挂着未激活水印MASMicrosoft Activation Scripts操作系统基于 Carbon 构建自己的图标库从 carbon/icons 到 carbon/icon-helpers 的完整实战指南基于 Carbon 构建自己的图标库从 carbon/icons 到 carbon/icon helpers 的完整实战指南 本指南基于 Carbon D前端UI组件设计系统上一篇告别繁琐字幕制作VideoCaptioner如何用AI实现从语音到完美字幕的全流程自动化下一篇RuView BFLD 隐私门控层如何保证 BFI 原始数据不出节点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考