监控C ++应用程序

我们正在实施新的集中监控解决方案（Zenoss）。使用SNMP和JMX可以很容易地将服务器，网络和Java程序整合在一起。

但是，问题是，在大型异构（Solaris x86，RHEL Linux，Windows）环境中监视和管理自定义C ++应用程序的最佳实践是什么？

我看到的可能性是：

1. 网络SNMP

• 优点

1. 每个服务器上的单个中央守护程序
2. 知名标准
3. 轻松集成到监控解决方案中
4. 我们已经在服务器上运行了Net SNMP守护程序

1. 复杂的实现（MIB，Net SNMP库）
2. 为C ++开发人员介绍的新技术

• 优点

1. 每个服务器上的单个中央守护程序
2. 知名标准
3. 未知集成到监视解决方案中（我知道它们可以基于文本发出警报，但是在发送遥测信息（如内存使用率，队列深度，线程容量等）时效果如何？
4. 简单的实现

1. 可能的整合问题
2. C ++开发人员的一些新技术
3. 如果我们切换监视供应商，可能会出现移植问题
4. 可能涉及提出临时通信协议（或使用RFC5424结构化数据；我不知道Zenoss是否在没有自定义Zenpack编码的情况下支持该协议）

• 优点

1. Java和C ++的一致管理接口
2. 知名标准
3. 轻松集成到监控解决方案中
4. 有点简单的实现（我们今天已经出于其他目的执行了此操作）

1. 复杂性（JNI，本机C ++和Java之间的转换层，基本上编写两次管理代码）
2. 可能的稳定性问题
3. 在每个进程中都需要一个JVM，使用更多的内存
4. JMX是C ++开发人员的新技术
5. 每个进程都有自己的JMX端口（我们在每台计算机上运行很多进程）

• 优点

1. 每个服务器上的单个中央守护程序
2. Java和C ++的一致管理接口
3. 知名标准
4. 轻松集成到监控解决方案中

1. 复杂性（基本上写两次管理代码）
2. 需要找到或编写这样的守护程序
3. 在JMX守护程序和C ++进程之间需要协议
4. JMX是C ++开发人员的新技术

• 优点

1. Java和C ++的一致管理接口
2. 知名标准
3. 轻松集成到监控解决方案中
4. 在共享JVM模式下运行时，每台服务器上的单个中央守护程序
5. 有点简单的实现（需要代码生成）

1. 复杂性（代码生成，需要GUI和几轮调整才能生成代理代码）
2. 可能的JNI稳定性问题
3. 在每个进程中都需要一个JVM，使用更多的内存（在嵌入式模式下）
4. 不支持Solaris x86（交易中断器）
5. 即使它确实支持Solaris x86，也可能存在编译器兼容性问题（我们在Solaris上使用STLPort和Forte的奇怪组合
6. 在嵌入式模式下运行时，每个进程都有其自己的JMX端口（我们在每台计算机上运行很多进程）
7. 可能会排除用于非C ++进程的共享JMX服务器（？）

我缺少一些合理的标准化，简单的解决方案吗？

如果没有其他合理的解决方案，那么这些解决方案中的哪些通常用于自定义C ++程序？

我的直觉是，Net SNMP是人们执行此操作的方式，但是在做出决定之前，我需要其他人的意见和经验。

我对Zenoss并不十分熟悉，但是当我以前使用nagios进行此类操作时，我们将使c / c ++进程在套接字上侦听并编写一个自定义的nagios插件，该插件将提供诊断和状态信息。

第一步是选择要用于使进程进行侦听的库。诸如C ++套接字库之类的功能可以做到这一点。那里没有什么复杂的..只是让过程听。

然后，您必须定义在特定刺激下您的过程将发送的响应。这确实意味着（至少对于nagios而言）定义了“服务”，然后向流程发送与该服务相对应的信号。您可以做的最简单的事情是创建一个“进程ping”，以查看是否可以成功连接到正在运行的进程。如果您这样做，那么自定义nagios插件至少知道该过程仍然有效。

您可以做很多更复杂的事情，但是这个想法很简单。您可以编写自己的封装在对象中的进程侦听代码的小库，并在构建一个（或全部）可执行文件时以标准化方式将其放入自定义c ++程序中

我的理解是Zenoss也可以做到这一点。

可能是因为Zenoss是python，所以您将使用Twisted之类的代码为它编写自定义插件，以连接到您正在侦听的c ++可执行文件。

我对您命名的这些产品并不熟悉，但对于Windows，我使用perfmon监视内存消耗，有一些特殊的计数器，例如非页面缓冲池错误，它们会向您显示程序是否包含内存泄漏，它们可能很少，因此花费很长时间是时候进行监视了，但是我认为这是一种简单的检查方法。

在Windows上，您甚至可以远程使用perfmon进行很多操作，或者使用WMI附加到相同的计数器，并对其进行一些自动化（在wmi中）以执行操作。

我在最近像您一样经历相同的过程时就对此有所了解：我们正在寻找一种轻量级，无阻塞的开源解决方案，该解决方案允许在C / C ++服务中公开和随后对指标进行远程监控（我们大约有3000个）。

SNMP最接近，但与源和监视系统的集成非常麻烦，不适合我们的实时过程。

最后，我们决定开发一种名为CMX的新解决方案，该解决方案使用共享内存技术并将其开源。您可以在此处进行检查： www.cern.ch/cmx。

我对事物的c ++方面不是很熟悉，但是在Java中，我们广泛地将CodaHale指标与Graphite结合使用。CodaHale基于实例将指标存储在实例的本地内存中，然后使用后台线程每分钟（可配置）将指标刷新到石墨服务器。在石墨中，我们可以跨实例聚合并识别故障实例。如果您不想维护石墨簇的复杂性，可以使用HostedGraphite。

这种设置意味着度量聚合或报告不会出现单点故障，因为（基于时间的聚合发生在节点本身上，而报告聚合则发生在分布式石墨簇（或宿主石墨）中。

最后，您可以使用Seyren在监视数据之上提供警报。

如果您使用的是Windows，则倾向于写入事件日志，然后使用WMI或类似的过程读取事件。如果要监视，可以将性能监视器计数器添加到您的应用程序中，然后让perfmon读取它们。两者都是Windows中的系统服务。

在Linux上，它显然趋向于更加灵活，但是我一直看到实现了nagios样式的监视器，并通过自定义套接字将数据发送到nagios样式服务器。

综上所述，我已经看过使用SMNP的几个地方，坦率地说，我看不出您不使用它的原因-尤其是在运行完全异构的环境时。