一个SNMP调用来获取Linux的CPU使用率，最终只读取/ proc / stat文件？
叹息1 。 幸运的是，你不需要/proc/stat
man 5 proc ：
/proc/loadavg该文件中的前三个字段是平均负载数字，表示运行队列（状态R）中的作业数量或者等待磁盘I / O（状态D）的平均时间为1,5和15分钟。 它们与正常运行时间（1）和其他程序给出的平均负载数相同。 第四个字段由两个用斜杠（/）分隔的数字组成。 其中第一个是当前可运行的内核调度实体（进程，线程）的数量。 斜线后的值是系统上当前存在的内核调度实体的数量。 第五个字段是最近在系统上创build的进程的PID。
但是您可能需要咨询http://www.net-snmp.org/的来源以确定它们实际使用的内容：
net-snmp-5.7.3 / agent / mibgroup / ucd-snmp / loadave.c：
#elif defined(linux) { FILE *in = fopen("/proc/loadavg", "r"); if (!in) { NETSNMP_LOGONCE((LOG_ERR, "snmpd: cannot open /proc/loadavg\n")); return (-1); }
脚注1.有时你真的不能select与你合作的人。
为了回应你的意见，再次感叹 。 由于只有内核知道它实际上在做什么，所以任何监视都会以某种方式与内核进行交互以检索这些信息。 与内核交互的通用接口是/proc/尽pipe也可以devise其他的方法（ auditd和kerneltap ）。 但是这些都不是“更轻量级”……
总是会有一定数量的观察效果和影响造成监控。
唯一的零影响方法是根本不做任何监测。 然后，谁有传呼机责任可以声称，由于没有警报被观察系统也不倒。
我会称这是一个胜利！
HBrujin有你的直接问题的答案，但这里解决的实际问题需要一些额外的讨论。
正如你可能从目前的评论中收集到的，大多数人对你的同事的态度感到困惑。 这是因为系统信息的轮询/proc相当普遍。 害怕直接库调用轮询内核（使用编译语言），获取内核状态的唯一方法是从/proc或/sys轮询它。
大部分的系统自动化是通过使用高级语言的脚本来完成的。 其中一些将提供绕过从/proc读取信息的需要的库封装器，但是shell脚本根本不能，也不能。 这与上面评论中强调的同事的立场是直接矛盾的： “反对意见是普遍地从/ proc中读取的” 。
你的同事是错误的，需要让这个挂断。 如果其他人被迫按照这些标准来操作， 他们就不能工作 。 整个互联网的实践经验值得在这里对付他们。 唯一会购买这些废话的人是那些不太了解的经理人。