Telegraf twemproxy 输入插件详解采集 Twemproxy 代理层统计指标的原理与配置实战【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegrafTelegraf 的twemproxy输入插件用于周期性拉取 TwemproxyTwitter 开源的 Redis/Memcached 代理stats 接口暴露的统计信息并将其转换为twemproxy、twemproxy_pool、twemproxy_pool_server三类分层指标写入时序数据库。本文基于该插件的 README 文档与源码实现完整讲解其配置参数、采集流程、指标字段含义与典型输出帮助你在生产环境中快速部署针对 Twemproxy 代理层包括其客户端连接、后端池与每台后端服务器的细粒度的监控能力。插件定位与版本信息按照 README 的说明该插件自Telegraf v0.3.0起提供归类为server服务器端输入插件支持all全部平台不依赖特定操作系统的接口因此 Windows、Linux、macOS 上均可使用。从源码注册结构看插件通过 plugins/inputs/twemproxy/twemproxy.go 末尾的init()函数以inputs.Add(twemproxy, ...)注册到插件体系并在 plugins/inputs/all/twemproxy.go 中通过空导入完成全量构建时的装配//go:build !custom || inputs || inputs.twemproxy import _ github.com/influxdata/telegraf/plugins/inputs/twemproxy // register plugin构建标签!custom || inputs || inputs.twemproxy表明在默认全量构建、启用inputs标签或显式启用inputs.twemproxy标签时该插件都会被编译进 Telegraf 二进制。工作原理一次 TCP 连接读取 JSON 统计快照与许多基于 HTTP 的输入插件不同该插件直接对 Twemproxy 的 stats 端口发起裸 TCP 连接。核心采集逻辑在 twemproxy.go 的Gather方法中流程非常简洁net.DialTimeout(tcp, t.Addr, 1*time.Second)—— 以1 秒硬编码超时连接配置的 stats 地址io.ReadAll(conn)—— 一次性读取服务端返回的全部内容服务端发送完整 JSON 后即关闭连接json.Unmarshal解析为map[string]interface{}解析失败则返回error decoding JSON response错误以配置中的addr作为twemproxy标签交给processStat做分层解析。func (t *Twemproxy) Gather(acc telegraf.Accumulator) error { conn, err : net.DialTimeout(tcp, t.Addr, 1*time.Second) if err ! nil { return err } body, err : io.ReadAll(conn) if err ! nil { return err } var stats map[string]interface{} if err json.Unmarshal(body, stats); err ! nil { return errors.New(error decoding JSON response) } tags : make(map[string]string) tags[twemproxy] t.Addr t.processStat(acc, tags, stats) return nil }从源码结构可以看出几个值得注意的实现细节采集是全量快照式而非长连接每次 interval 触发时新建 TCP 连接、读完整响应后由服务端关闭。这意味着 Twemproxy stats 端口必须允许频繁短连接且 1 秒的拨号超时是写死的无法通过配置调整标签复制防止串扰copyTags 为每个 pool、每个 backend server 深拷贝一份 tags注释中明确说明 Tags is not expected to be mutated after passing to Add保证不同层级的指标不会互相污染标签类型收敛所有字段仅接受float64类型的 JSON 数值参与入库JSON 数字反序列化到interface{}后统一为float64非数值内容会被静默丢弃。三层指标的解析路径processStat方法twemproxy.go体现了 Twemproxy stats JSON 的嵌套结构到指标的映射关系第一层代理实例级从 JSON 顶层取total_connections、curr_connections、timestamp三个字段加上sourceJSON 中的主机名标识映射为同名字段与配置地址映射出的twemproxy标签组成twemproxy指标第二层pool 级按配置项Pools数组逐个在 JSON 顶层查找同名键命中且为对象时进入processPool只白名单提取 6 个 pool 级字段生成twemproxy_pool指标并追加pool标签第三层backend server 级processPool在遍历 pool 对象时凡值是嵌套对象的键即后端服务器地址如10.16.29.1:6379都视为一台 backend server交给processServer收集其中全部float64字段生成twemproxy_pool_server指标并追加server标签。// Process pool data in Twemproxy stats func processPool(acc telegraf.Accumulator, tags map[string]string, data map[string]interface{}) { ... fields : make(map[string]interface{}) for key, value : range data { switch key { case client_connections, forward_error, client_err, server_ejects, fragments, client_eof: if val, ok : value.(float64); ok { fields[key] val } default: if data, ok : value.(map[string]interface{}); ok { if _, ok : serverTags[key]; !ok { serverTags[key] copyTags(tags) serverTags[key][server] key } processServer(acc, serverTags[key], data) } } } acc.AddFields(twemproxy_pool, fields, tags) }可以推断出配置约束pools中列出的池名必须与 Twemproxy stats JSON 顶层的键完全一致未列出的池不会被采集即使 JSON 中存在列错名字则只会静默缺失该池的指标不会报错。配置插件配置只有两个参数。以下是 sample.conf 的完整内容该文件通过go:embed内嵌进二进制即telegraf --sample-config中[[inputs.twemproxy]]段落的来源并由 generator 工具 保证与 README 同步# Read Twemproxy stats data [[inputs.twemproxy]] ## Twemproxy stats address and port (no scheme) addr localhost:22222 ## Monitor pool name pools [redis_pool, mc_pool]参数类型默认值说明addrstringlocalhost:22222Twemproxy stats 服务端的host:port不带协议前缀源码中直接net.DialTimeout(tcp, ...)写http://会连接失败。22222 是 Twemproxy 默认的 stats 管理端口pools[]string无需要采集的 pool 名称列表对应 Twemproxy 配置中的池名。留空则只采集实例级twemproxy指标pool 与 backend server 指标不会出现全局配置选项按照 README 中 Global configuration options 一节本插件还支持 Telegraf 通用的全局与插件级配置设置例如修改指标、标签、字段、创建别名以及配置插件顺序等具体见 CONFIGURATION.md 的 Plugins 章节。配置完成后随全局interval定时触发采集即可。由于连接超时仅 1 秒若 stats 端口不通例如admin_port未开放或防火墙拦截每次采集会直接返回拨号错误Telegraf 会按输出/插件的错误处理策略记录日志不会阻塞整个 agent。指标体系一次Gather会产生三种 metric name层级逐下细化标签逐层叠加twemproxy代理实例级标签含义sourcestats JSON 中的source字段通常是被采集主机名twemproxy配置中的addr值host:port标识具体的 stats 端点字段类型含义curr_connectionsfloat当前活跃连接数total_connectionsfloat累计连接数timestampfloatTwemproxy 侧的时间戳twemproxy_pool池级标签在实例级基础上增加pool池名。字段类型含义client_connectionsfloat池上的客户端连接数client_eoffloat客户端 EOF 计数client_errfloat客户端错误计数forward_errorfloat转发错误计数fragmentsfloat碎片未匹配到后端键空间计数server_ejectsfloat后端被弹出eject计数twemproxy_pool_server后端服务器级标签在池级基础上增加server后端host:port。该层字段由processServer对后端对象中的全部float64字段动态收集典型字段如下字段类型含义in_queue/in_queue_bytesfloat入队请求数 / 字节数out_queue/out_queue_bytesfloat出队请求数 / 字节数requests/request_bytesfloat请求总数 / 请求字节数responses/response_bytesfloat响应总数 / 响应字节数server_connectionsfloat到该后端的连接数server_ejected_atfloat后端被弹出时的时间戳server_eoffloat后端 EOF 计数server_errfloat后端错误计数server_timedoutfloat后端超时计数示例输出README 给出的 Line Protocol 示例如下与 twemproxy_test.go 中sampleStats的模拟数据一一对应twemproxy,sourceserver1.website.com,twemproxy127.0.0.1:22222 curr_connections1322,timestamp1447312436,total_connections276448 1748893350082522719 twemproxy_pool_server,pooldemo,server10.16.29.1:6379,sourceserver1.website.com,twemproxy127.0.0.1:22222 in_queue0,in_queue_bytes0,out_queue0,out_queue_bytes0,request_bytes2775840400,requests43604566,response_bytes7663182096,responses43603900,server_connections1,server_ejected_at0,server_eof0,server_err0,server_timedout24 1748893350082546069 twemproxy_pool_server,pooldemo,server10.16.29.2:6379,sourceserver1.website.com,twemproxy127.0.0.1:22222 in_queue0,in_queue_bytes0,out_queue0,out_queue_bytes0,request_bytes2412114759,requests37870211,response_bytes5228980582,responses37869551,server_connections1,server_ejected_at0,server_eof0,server_err0,server_timedout25 1748893350082560329 twemproxy_pool,pooldemo,sourceserver1.website.com,twemproxy127.0.0.1:22222 client_connections1305,client_eof126813,client_err147942,forward_error11684,fragments0,server_ejects0 1748893350082572369对照示例可以读出实际语义twemproxy指标表明该代理当前 1322 个活跃连接、累计 276448 个连接twemproxy_pool显示 demo 池有 147942 次客户端错误、11684 次转发错误是排查客户端侧异常的首要入口两条twemproxy_pool_server则把流量按后端拆分requests分别为 4360 万与 3787 万并结合server_timedout、in_queue/out_queue即可定位单台后端慢或队列堆积的问题。测试与验证插件自带的单元测试 twemproxy_test.go 展示了如何验证采集结果也给出了 Twemproxy stats 响应格式的完整样例mockTwemproxyServerL63-L82在127.0.0.1:22222上监听接受一次连接后写回一段 JSON顶层含total_connections、curr_connections、source、timestamp以及名为demo的池对象池内含 6 个池级字段和10.16.29.1:6379、10.16.29.2:6379两个后端对象然后关闭连接——这正是真实 Twemproxy stats 端点的行为模型TestGather使用testutil.Accumulator断言三类指标的字段与标签组合例如要求twemproxy_pool_server指标必须同时携带pooldemo、server10.16.29.1:6379、sourceserver1.website.com、twemproxy127.0.0.1:22222四个标签。在生产环境验证时可直接用裸 TCP 工具确认 stats 端点返回 JSON例如nc localhost 22222后直接收到 JSON 报文并确认其中顶层键名与pools配置一致随后运行telegraf --test --config telegraf.conf输出中应出现上述三种 metric name。实践要点小结addr只接受host:port默认localhost:22222对应 Twemproxy 默认的 stats 管理端口pools必须与 Twemproxy stats JSON 顶层的池名精确匹配未匹配的池不会报错而是被跳过排查缺指标时优先核对池名拼写拨号超时固定为 1 秒且无重试参数可配网络抖动超过 1 秒即当次采集失败跨机房采集时需评估该约束后端服务器层字段是动态收集的Twemproxy 版本若新增 stats 字段且为数值类型会被自动纳入twemproxy_pool_server指标无需升级插件三层指标通过twemproxy/pool/server标签逐级细化配合 InfluxQL/InfluxQL 风格的 group by 即可完成实例 → 池 → 单机后端的下钻分析。【免费下载链接】telegrafAgent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.项目地址: https://gitcode.com/GitHub_Trending/te/telegraf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
