1. 为什么监控交换机、UPS、打印机这类设备Prometheus必须“牵手”SNMP你有没有遇到过这样的场景公司新上了一套Prometheus Grafana的监控平台CPU、内存、磁盘、服务端口一目了然告警邮件秒发团队直呼“监控自由”。可转头一看——核心网络交换机的端口流量、丢包率、温度机房UPS的输入电压、剩余电量、电池健康状态甚至那台关键的激光打印机的碳粉余量和卡纸次数……全都是黑盒。Prometheus的抓取器scrape target对着这些设备的IP地址反复请求HTTP接口返回404或者干脆超时。不是Prometheus不行是它天生不“懂”这些设备的语言。这个语言就是SNMPSimple Network Management Protocol。它不是HTTP不是RESTful API更不是gRPC。它是网络设备领域几十年沉淀下来的“通用母语”从思科、华为、H3C的交换机路由器到APC、Eaton、CyberPower的UPS再到富士施乐、HP、佳能的企业级打印机只要标着“支持SNMP v2c/v3”它就一定在后台默默运行着一个SNMP Agent等着被查询。而Prometheus作为一款为云原生应用指标设计的时序数据库它的数据模型是“指标名标签集时间戳数值”天然适配HTTP暴露的/metrics端点。它不会、也不该去实现一套完整的SNMP协议栈。所以问题的核心从来不是“Prometheus能不能监控交换机”而是“如何让Prometheus听懂SNMP说的每一句话”。这就是“Prometheus与SNMP”这个组合背后最真实、最迫切的业务动因填补云原生监控体系与传统基础设施之间的最后一公里鸿沟。它解决的不是一个技术炫技问题而是一个运维刚需——当你的Kubernetes集群、微服务应用都已实现精细化监控时支撑它们运行的物理网络、电力、打印等底层设施绝不能成为监控盲区。我亲眼见过一家电商公司在大促期间核心接入层交换机因温度过高自动降频导致部分API延迟飙升但Prometheus告警里没有任何线索最后靠机房巡检人员发现风扇异响才定位问题。这种“看得见应用看不见地基”的窘境正是SNMP集成要终结的。关键词“普罗米修斯”、“Prometheus”、“SNMP”在此刻交汇指向的是一条清晰的技术路径用一个轻量、可靠、可配置的“翻译官”把SNMP Agent吐出的原始OID对象标识符数据翻译成Prometheus能理解的标准指标格式并通过HTTP端点暴露出来。这个“翻译官”就是snmp_exporter。它不是Prometheus的插件也不是一个需要深度定制的模块而是一个独立的、开箱即用的Go语言程序。它的存在让Prometheus的监控版图从虚拟世界无缝延伸到了物理世界的每一个网口、每一节电池、每一个墨盒。对于正在构建统一监控平台的SRE、运维工程师、乃至中小企业的IT管理员来说掌握这套组合拳意味着真正拥有了对整个IT资产的“上帝视角”。2. 核心架构拆解为什么是snmp_exporter而不是自己写一个SNMP客户端在动手配置之前必须先理解这个方案的底层逻辑。很多人第一次接触时会疑惑既然Prometheus能抓HTTP那我直接写个Python脚本用pysnmp库去轮询交换机再把结果格式化成文本格式输出到一个端口不就行了吗理论上可行但实操中会踩进无数深坑。snmp_exporter之所以成为事实标准绝非偶然而是经过大量生产环境验证后在可靠性、性能、可维护性上达成的最佳平衡点。我们来一层层拆解这个架构选择背后的硬逻辑。2.1 架构全景一个典型的SNMP监控链路整个数据流可以清晰地划分为四个环节数据源Source目标设备如一台华为S5735交换机其SNMP Agent进程持续监听UDP 161端口维护着一个庞大的MIBManagement Information Base树形数据库。翻译层Translatorsnmp_exporter进程。它不存储数据只做一件事——根据预定义的规则snmp.yml配置文件向目标设备发起SNMP GET或GETNEXT请求获取指定OID的值然后将这些原始值比如1.3.6.1.2.1.2.2.1.10.1返回的整数123456789映射、转换、打标最终生成符合Prometheus文本协议规范的指标字符串。采集层CollectorPrometheus Server。它将snmp_exporter的HTTP端点默认/metrics作为一个普通的target进行周期性抓取scrape就像抓取Node Exporter或应用自身的/metrics一样。可视化与告警层ConsumerGrafana负责图表展示Alertmanager负责基于指标的告警规则触发。这个架构的关键在于职责分离。snmp_exporter只负责“翻译”Prometheus只负责“存储与计算”Grafana只负责“展示”。任何一环的升级、故障、扩容都不会直接影响其他环节。比如你想把华为交换机的监控粒度从“端口总流量”细化到“每个端口的入向错误包数”你只需要修改snmp.yml里的配置重启snmp_exporter即可Prometheus的配置、告警规则、Grafana面板一条都不用动。这种松耦合是自研脚本永远无法企及的工程优势。2.2 为什么snmp_exporter是唯一合理的选择让我们对比几种常见但不推荐的替代方案方案A在Prometheus Server上直接集成SNMP客户端这违背了Prometheus的设计哲学。Prometheus Server的核心任务是高效存储、查询和告警它需要保持极高的稳定性和低资源占用。如果让它去处理大量并发的、可能超时的、协议复杂的SNMP网络IO无异于让一个精密的钟表匠去干搬运工的活。一旦某个SNMP请求卡住整个Prometheus的抓取循环都可能被拖慢导致所有指标延迟这是不可接受的。方案B用Python/Shell脚本轮询并写入本地文件再用Textfile Collector读取这个方案看似简单但它引入了严重的时序错乱和一致性风险。snmp_exporter是实时响应HTTP抓取请求的Prometheus每次抓取得到的都是那一刻的最新快照。而脚本轮询是定时的比如每60秒执行一次它把结果写入一个文件Textfile Collector再去读这个文件。如果脚本执行耗时超过60秒或者Prometheus恰好在脚本写入一半时读取就会得到一个不完整、不一致的数据。更糟的是多个脚本并发写入同一个文件极易产生竞态条件导致指标丢失或格式错误。snmp_exporter内部使用了高效的goroutine池和连接复用确保了高并发下的稳定输出。方案C为每台设备单独部署一个定制化的Exporter这种“一个设备一个Exporter”的思路在设备数量少5台且型号完全一致时或许可行。但一旦设备品牌混杂华为、H3C、Cisco、型号各异不同系列交换机MIB结构差异巨大、数量攀升几十上百台维护成本会指数级爆炸。你需要为每种设备写、测试、部署、更新一个独立的程序。而snmp_exporter的精髓在于其配置驱动Configuration-Driven的设计。所有设备的差异都浓缩在一个snmp.yml文件里。你新增一台设备只需在Prometheus的target配置里加一行IPsnmp_exporter会自动根据其IP段或主机名匹配到snmp.yml中对应的profile完成翻译。这极大地降低了运维复杂度。提示snmp_exporter的配置文件snmp.yml本质上是一个巨大的、结构化的“SNMP词典”。它定义了如何将晦涩的OID如1.3.6.1.4.1.2011.5.25.31.1.1.1.1.2.1翻译成人类可读的指标名如huawei_cpu_usage_percent并为其自动添加device_modelS5735、portGigabitEthernet0/0/1等丰富的标签。这个过程就是将网络管理的“二进制语言”翻译成了监控领域的“普通话”。2.3 性能与安全的底层保障snmp_exporter用Go语言编写天生具备高并发、低内存占用的特性。一个实例轻松支撑数百个SNMP target的并发抓取。更重要的是它对SNMP协议的支持非常成熟完整支持SNMP v1、v2c社区字符串认证和v3用户、认证、加密三重安全机制。内置超时、重试、连接池等健壮性机制避免单个设备故障拖垮整个Exporter。支持walk操作可以一次性获取一个OID子树下的所有值极大减少了网络往返次数这对于需要获取大量端口信息的交换机监控至关重要。因此选择snmp_exporter不是因为它“最简单”而是因为它是在可靠性、性能、可维护性、安全性这四个维度上经过千锤百炼后得出的最优解。它不是一个临时的“胶水层”而是一个坚如磐石的“协议桥”。3. 实操详解从零开始部署snmp_exporter并监控一台华为交换机理论讲得再透不如亲手跑通一遍。下面我将以一台真实的华为S5735-L交换机为例手把手带你完成从设备配置、Exporter部署到Prometheus抓取的全流程。所有命令和配置均基于当前2024年的稳定版本确保你复制粘贴就能用。3.1 前提准备确保你的环境“万事俱备”在开始之前请确认以下几项基础工作已完成Prometheus Server已成功部署并运行版本建议v2.30.0或更高。可通过curl http://prometheus-ip:9090/-/healthy验证。目标设备华为交换机已获得管理员权限可通过Console或SSH登录。Linux服务器用于部署snmp_exporter建议CentOS 7/Ubuntu 20.04拥有root或sudo权限。网络连通性部署snmp_exporter的服务器必须能ping通交换机并且UDP 161端口未被防火墙阻塞telnet switch-ip 161会失败因为是UDP应使用nc -u switch-ip 161或timeout 2 bash -c echo /dev/udp/switch-ip/161 2/dev/null echo Open || echo Closed。3.2 第一步在华为交换机上开启并配置SNMP Agent这是整个链条的起点。很多故障根源都在这一步没配好。请务必逐行执行# 进入系统视图 HUAWEI system-view # 创建一个只读的SNMP团体Community名称为public生产环境请务必更换为强密码 [HUAWEI] snmp-agent community read public # 配置SNMP版本为v2c最常用兼容性最好 [HUAWEI] snmp-agent sys-info version v2c # 可选但强烈推荐配置一个SNMP Trap接收地址用于设备主动上报告警 [HUAWEI] snmp-agent trap enable [HUAWEI] snmp-agent target-host trap address udp-domain snmp_exporter-server-ip params securityname public v2c # 保存配置 [HUAWEI] save注意public是一个默认的、弱密码的团体名仅用于测试。在生产环境中你必须将其替换为一个至少12位、包含大小写字母、数字和特殊字符的强密码例如My$ecur3SNMP2024。华为设备对团体名长度和复杂度有严格要求过于简单的密码会被拒绝。验证配置是否生效# 在交换机上查看SNMP状态 [HUAWEI] display snmp-agent sys-info # 应看到Version: V2c, Community name: public (read-only) # 在snmp_exporter服务器上用snmpwalk命令测试连通性需先安装net-snmp-utils $ yum install -y net-snmp-utils # CentOS $ apt-get install -y snmp # Ubuntu $ snmpwalk -v 2c -c public switch-ip 1.3.6.1.2.1.1.1.0 # 如果返回类似iso.3.6.1.2.1.1.1.0 STRING: Huawei Versatile Routing Platform Software VRP (R) software, Version 5.170...说明SNMP通信成功3.3 第二步下载、安装并配置snmp_exporter现在我们把“翻译官”请到服务器上。# 创建专用目录 $ mkdir -p /opt/snmp_exporter cd /opt/snmp_exporter # 下载最新稳定版以v0.24.0为例请前往https://github.com/prometheus/snmp_exporter/releases 查看最新版 $ wget https://github.com/prometheus/snmp_exporter/releases/download/v0.24.0/snmp_exporter-0.24.0.linux-amd64.tar.gz $ tar xvfz snmp_exporter-0.24.0.linux-amd64.tar.gz # 重命名并赋予执行权限 $ mv snmp_exporter-0.24.0.linux-amd64 snmp_exporter $ chmod x snmp_exporter # 生成一个基础的snmp.yml配置文件这是核心 $ ./snmp_exporter --config.filesnmp.yml --help | grep generate # 你会看到提示Use snmp_exporter --config.filesnmp.yml --web.listen-address:9116 --generator to generate a config. # 但我们不直接用generator因为它的默认配置过于庞大。我们手动创建一个精简、高效的配置。 $ cat snmp.yml EOF --- # 全局配置 global: scrape_timeout: 10s retries: 3 # 为华为S5735设备定义一个专用Profile # 这个Profile的名字将在Prometheus target配置中引用 huawei_s5735: # 指定要查询的MIB模块这里我们聚焦于CPU、内存、端口 walk: - 1.3.6.1.4.1.2011.5.25.31.1.1.1.1 # CPU利用率华为私有MIB - 1.3.6.1.4.1.2011.5.25.19.1.1.1.1 # 内存利用率华为私有MIB - 1.3.6.1.2.1.2.2.1 # IF-MIB获取所有网络接口信息 # 将原始OID映射为Prometheus指标 metrics: # CPU利用率指标 - name: huawei_cpu_usage_percent oid: 1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5.1 type: gauge help: Huawei device CPU usage percentage # 内存利用率指标 - name: huawei_memory_usage_percent oid: 1.3.6.1.4.1.2011.5.25.19.1.1.1.1.10.1 type: gauge help: Huawei device memory usage percentage # 接口状态up/down - name: if_oper_status oid: 1.3.6.1.2.1.2.2.1.8 type: gauge help: The operational status of the interface. # 接口入向字节数用于计算流量 - name: ifHCInOctets oid: 1.3.6.1.2.1.31.1.1.1.6 type: counter help: The total number of octets received on the interface. # 接口出向字节数用于计算流量 - name: ifHCOutOctets oid: 1.3.6.1.2.1.31.1.1.1.10 type: counter help: The total number of octets transmitted out of the interface. EOF这个snmp.yml文件是整个项目的灵魂。我们来解读几个关键点huawei_s5735:是Profile的名称它必须与Prometheus配置中的params参数一致。walk:指令告诉Exporter要一次性遍历整个OID子树而不是只查单个OID。这对于获取所有端口信息ifHCInOctets至关重要因为端口号是动态的1.3.6.1.2.1.31.1.1.1.6.1,1.3.6.1.2.1.31.1.1.1.6.2...walk能自动发现所有存在的索引。metrics:下的每一项都定义了一个从OID到Prometheus指标的映射。type: counter表示这是一个计数器Prometheus会自动计算其速率rate()函数type: gauge表示这是一个瞬时值直接使用。3.4 第三步启动snmp_exporter并验证配置完成后就可以启动服务了。# 启动snmp_exporter监听在9116端口并加载我们刚创建的配置 $ nohup ./snmp_exporter --config.filesnmp.yml --web.listen-address:9116 /var/log/snmp_exporter.log 21 # 检查进程是否运行 $ ps aux | grep snmp_exporter # 验证HTTP端点是否正常工作 $ curl http://localhost:9116/metrics # 你应该看到一堆以# HELP开头的注释以及以huawei_cpu_usage_percent、if_oper_status等开头的指标行。 # 如果返回空白或报错请检查snmp.yml语法YAML缩进极其严格和日志/var/log/snmp_exporter.log。此时snmp_exporter已经作为一个独立的HTTP服务运行起来了。它本身并不知道你要监控哪台设备它只是“待命”等待Prometheus来“点菜”。3.5 第四步配置Prometheus将交换机加入监控Target最后一步让Prometheus认识这个新的数据源。编辑Prometheus的主配置文件prometheus.yml通常位于/etc/prometheus/prometheus.yml或/opt/prometheus/prometheus.yml# 在scrape_configs: 下添加一个新的job - job_name: snmp # 指定抓取的目标即snmp_exporter的地址 static_configs: - targets: - localhost:9116 # snmp_exporter的地址 # 关键这里通过params参数告诉snmp_exporter“我要监控的设备是华为S5735用huawei_s5735这个Profile” metrics_path: /snmp params: module: [huawei_s5735] target: [192.168.1.100] # 请将此处替换为你的真实交换机IP # 重写标签让指标更易识别 relabel_configs: - source_labels: [__param_target] target_label: instance replacement: $1 - source_labels: [__param_module] target_label: job replacement: snmp提示params是核心。module指定了使用哪个Profilehuawei_s5735target指定了要查询的设备IP。Prometheus会将这两个参数拼接到snmp_exporter的URL上形成类似http://localhost:9116/snmp?modulehuawei_s5735target192.168.1.100的请求。snmp_exporter收到这个请求后会根据module找到对应的Profile然后用target作为目标IP发起SNMP查询。保存配置后重新加载Prometheus# 发送SIGHUP信号优雅重载配置无需重启 $ kill -HUP $(ps aux | grep prometheus | grep -v grep | awk {print $2}) # 或者如果你的Prometheus是systemd服务 $ systemctl reload prometheus几分钟后打开Prometheus Web UIhttp://prometheus-ip:9090进入Status-Targets页面。你应该能看到一个名为snmp的Job其Target列表里有一项192.168.1.100:9116状态为UP。点击它旁边的Metrics链接就能看到所有从交换机抓取过来的原始指标了。3.6 第五步在Grafana中创建第一个监控面板数据有了下一步就是让它“活”起来。在Grafana中确保已添加Prometheus作为Data Source。新建一个Dashboard点击Add new panel。在Query编辑框中输入PromQL查询huawei_cpu_usage_percent{instance192.168.1.100}这会画出该交换机的CPU使用率曲线。点击Panel title-Edit将标题改为华为交换机CPU使用率。可选添加一个告警规则在Panel的Alert选项卡中设置当huawei_cpu_usage_percent 80持续5分钟时触发告警。至此一个端到端的SNMP监控闭环就完成了。从交换机的SNMP Agent到snmp_exporter的翻译再到Prometheus的存储与计算最后到Grafana的可视化每一步都清晰、可控、可验证。4. 高级技巧与避坑指南那些官方文档里不会写的实战经验上面的流程足以让你跑通一个基本的监控。但在真实的生产环境中你会遇到各种“意料之外情理之中”的问题。这些才是区分一个合格运维和一个资深SRE的关键。下面分享我在多个项目中踩过的坑、总结的技巧全是血泪教训换来的干货。4.1 “指标不见了”排查SNMP通信的黄金三步法这是最常见的问题Prometheus Target显示UP但/metrics页面里却找不到你想要的指标比如huawei_cpu_usage_percent。别急着怀疑配置按以下顺序排查第一步绕过Exporter直接测试SNMP在snmp_exporter服务器上用snmpget命令直接查询那个具体的OIDsnmpget -v 2c -c public 192.168.1.100 1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5.1如果返回Timeout说明网络或SNMP Agent配置有问题如果返回No Such Object available on this agent说明这个OID在该设备上不存在可能是型号不匹配或MIB未启用你需要查阅该设备的MIB手册找到正确的OID。第二步检查snmp_exporter的日志日志是真相的唯一来源。tail -f /var/log/snmp_exporter.log然后手动触发一次抓取在Prometheus UI里点击Target旁边的Resync按钮。日志里会清晰地打印出是否成功建立了UDP连接。查询了哪些OID。返回了什么值或错误。如果出现walk: timeout说明设备响应太慢需要调大global.scrape_timeout。第三步用snmp_exporter的调试模式启动snmp_exporter时加上--log.leveldebug参数它会输出更详细的SNMP协议交互过程包括发送的PDU协议数据单元和收到的响应。这对于分析复杂的v3认证问题或ASN.1编码错误是无可替代的利器。经验心得我曾经在一个项目中发现所有指标都为空。日志显示walk操作超时。最终排查发现是交换机的SNMP Agent进程被另一个监控软件占用了全部CPU导致响应缓慢。snmp_exporter的默认10秒超时不够将scrape_timeout调至30秒后问题解决。这提醒我们snmp_exporter的配置必须与目标设备的实际性能相匹配。4.2 如何为“千台设备”做配置管理用Ansible自动化一切当你的监控规模从几台扩展到几百台、上千台设备时手工维护snmp.yml和Prometheus的static_configs是灾难性的。我的解决方案是用Ansible作为唯一的配置源。所有设备信息IP、厂商、型号、SNMP社区名存放在Ansible的Inventory文件如inventory/production中[network_switches] sw-hq-core-01 ansible_host10.0.1.1 vendorhuawei models5735 communityMy$ecur3SNMP2024 sw-hq-access-01 ansible_host10.0.1.2 vendorh3c models5120 communityMy$ecur3SNMP2024编写一个Jinja2模板snmp.yml.j2它会根据Inventory动态生成snmp.yml--- global: scrape_timeout: 30s retries: 3 {% for host in groups[network_switches] %} {{ hostvars[host][vendor] }}_{{ hostvars[host][model] }}: walk: - 1.3.6.1.4.1.2011.5.25.31.1.1.1.1 # 华为CPU - 1.3.6.1.4.1.25506.2.6.1.1.1.1.2 # H3C CPU metrics: - name: {{ hostvars[host][vendor] }}_cpu_usage_percent oid: {% if hostvars[host][vendor] huawei %}1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5.1{% else %}1.3.6.1.4.1.25506.2.6.1.1.1.1.2.1{% endif %} type: gauge {% endfor %}编写一个Ansible Playbook它会从Inventory生成snmp.yml。将snmp.yml推送到所有snmp_exporter服务器。重启snmp_exporter服务。动态生成Prometheus的snmp_targets.json文件使用file模块内容为所有设备的IP列表。将snmp_targets.json推送到Prometheus服务器并重载配置。这样当你新增一台设备时只需在Inventory里加一行运行一次ansible-playbook deploy_snmp.yml整个监控体系就自动更新了。这才是现代运维该有的样子。4.3 安全加固从v2c平滑迁移到SNMP v3SNMP v2c的社区字符串Community String本质上就是明文密码通过网络传输极易被嗅探。生产环境必须升级到v3。snmp_exporter对v3的支持非常完善但配置稍显复杂。以下是平滑迁移的步骤在设备上配置v3用户以华为为例[HUAWEI] snmp-agent usm-user v3 snmpuser [HUAWEI] snmp-agent usm-user v3 snmpuser authentication-mode sha MyAuthPass123 [HUAWEI] snmp-agent usm-user v3 snmpuser privacy-mode aes128 MyPrivPass456 [HUAWEI] snmp-agent usm-user v3 snmpuser acl 2000 # 限制访问ACL在snmp.yml中为v3 Profile添加auth和priv块huawei_s5735_v3: auth: username: snmpuser password: MyAuthPass123 auth_protocol: sha priv: password: MyPrivPass456 priv_protocol: aes walk: [...] metrics: [...]在Prometheus的target配置中将params改为params: module: [huawei_s5735_v3] target: [192.168.1.100]注意v3的auth_password和priv_password必须与设备上配置的完全一致且auth_protocol和priv_protocol也必须匹配。一个常见的错误是设备上配置了sha-256而snmp_exporter配置里写了sha导致认证失败。务必查阅设备文档确认协议名称。4.4 告别“指标爆炸”如何优雅地处理海量端口指标一台核心交换机可能有48个端口ifHCInOctets这个指标就会产生48个时间序列。如果监控100台设备就是4800个时间序列。Prometheus的存储和查询压力会急剧上升。解决方案是聚合与降维在Prometheus中聚合不要在Grafana里画48条线而是用sum by (instance)来查看整台设备的总流量sum(rate(ifHCInOctets[5m])) by (instance)在snmp_exporter中过滤利用relabel_configs只保留你真正关心的端口。例如只监控编号为1-24的接入端口- job_name: snmp static_configs: - targets: [localhost:9116] metrics_path: /snmp params: module: [huawei_s5735] target: [192.168.1.100] relabel_configs: # 只保留ifIndex在1-24范围内的指标 - source_labels: [ifIndex] regex: ^(1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24)$ action: keep使用snmp_exporter的lookups功能将端口索引ifIndex映射为可读的端口名ifDescr让指标自带语义huawei_s5735: walk: - 1.3.6.1.2.1.2.2.1.2 # ifDescr (端口描述) - 1.3.6.1.2.1.31.1.1.1.6 # ifHCInOctets metrics: - name: ifHCInOctets oid: 1.3.6.1.2.1.31.1.1.1.6 type: counter help: In octets labels: ifDescr: 1.3.6.1.2.1.2.2.1.2 # 将ifDescr的值作为ifDescr标签这样指标就变成了ifHCInOctets{ifDescrGigabitEthernet0/0/1}比ifHCInOctets{ifIndex1}直观一万倍。5. 场景延展SNMP不止于交换机还能监控什么掌握了核心原理和方法论你就能举一反三将这套方案应用到几乎任何支持SNMP的设备上。下面列举几个典型且高频的应用场景每个都附带关键OID和配置要点帮你快速上手。5.1 监控UPS不间断电源UPS是数据中心的生命线其状态直接关系到业务连续性。主流品牌APC、Eaton、CyberPower都提供了详尽的SNMP MIB。核心指标输入电压 (1.3.6.1.4.1.318.1.1.1.12.1.0)输出电压 (1.3.6.1.4.1.318.1.1.1.12.2.0)负载百分比 (1.3.6.1.4.1.318.1.1.1.12.3.0)电池剩余时间分钟(1.3.6.1.4.1.318.1.1.1.2.2.3.0)电池温度 (1.3.6