应用程序运行状况监视系统至少应为我们(开发人员)和/或者老板(IT经理)和/或者操作(应召唤)人员做什么？

超出最低要求还应该做什么？

监视"基础结构"应用程序(ms-exchange，apache等)是否足够？还是还需要监视单个用户应用程序，网站和数据库？

如果是后者，我们需要了解什么？

附录：感谢投入，我确实在寻找应用程序级别的监视而不是基础结构监视，但是很高兴了解这两者

解决方案

回答

最低要求：确保它正在运行:)

但是，其他一些东西将非常有用。例如，CPU负载，RAM使用情况以及(在多用户系统中)哪个用户正在运行什么。同样，对于访问网络的应用程序，每个应用程序的网络连接列表。而且(如果我们可以访问客户端计算机)，能够看到应用程序的"窗口标题"可能很酷，也许每2-3分钟检查一次应用程序是否更改并保存。同样，由应用程序打开的文件列表可能非常有用，但这不是必须的。

回答

• 应用程序是否正在运行。
• 不正常的cpu /内存/网络使用情况。
• 报告任何未处理的异常。
• 各种模块的状态(如果适用)。
• 外部组件(数据库，Web服务，文件服务器等)的状态
• 待处理的后台任务数(如果适用)。
• 也许跟踪应用程序的使用情况并报告最常用/较少使用的功能的统计信息，以便我们了解优化在哪些方面最有利。

回答

答案是"取决于"。为什么需要监视？运营人员有多少？我们需要举报吗？什么是应用环境？谁在乎应用程序是否失败？谁在乎是否会发生异常？任何错误都可以恢复吗？我可以问很长时间这样的问题。

回答

我认为这是一个非常简单的监视器，因此可以在出现问题之前及早警告我们。这意味着监视依赖项和应用程序本身。

如果我们不打算提供要监视的应用程序的详细信息，确实很难提供详细信息，因此我想将其用作一般规则。

回答

这是一个开放的问题，但我将从物理测量开始。
1.我认为托管该站点的所有计算机是否可ping通。
2.是否所有应提供内容的机器都提供某些内容。 (理想情况下，这将是来自外部网络的攻击。
3.每台机器上运行的每个预期服务
3a。这些服务最近运行了吗？
4.每台计算机上是否都留有硬盘驱动器空间？ (不要忘记数据库)
5.这些机器是否已备份？最后一次是什么时候？
一旦对系统进行了物理监视，就可以解决特定于系统的问题吗？
1.自动脚本可以登录吗？它花了多少时间？
2.活着有多少用户？是否增加了100万个假帐户？
...
这些问题变得更加模糊，并且可能与系统有关。它们通常还可以在响应物理测量时以反应方式导出。硬盘已满，也许Web服务器日志已满，因为一堆代理创建了太多假用户。那种事

尽管计划A不一定必须是被动的，但它是许多站点设置监视系统的方式。

回答

我们至少要知道系统运行状况良好。这在定义系统是否健康方面是主观的。是计算机启动了，所需的资源是否存在，数据是否正在系统中流动，数据是否正确地产生了结果等？

在我的项目中，我们对大多数情况进行监视，然后对某些情况进行监视。实际上，它可以归结为我们可以用来分析一切正常的最高级别。在我们的情况下，我们需要了解数据输出。如果我们只需要了解这些机器是什么，则可以避免尝试向没有经验的最终用户显示问题所在。

如果我们只是太想研究数据结果，那么还有"现成的"工具将为我们完成很多艰苦的工作。当我环顾四周时，我特别喜欢Nagios，但是我们需要的远远超出了它的显示范围，因此我编写了自己的监视系统。基本上，我们还要注意系统中的"特殊性"，内存/ CPU峰值等。

回答

感谢大家的投入，我确实在寻找应用程序级别的监控，而不是基础架构的监控，但是很高兴了解这两者

区别是：

• 基础结构监视将是服务器以及MS Exchange Server，Apache，IIS等
• 应用程序监视将是用户计算机及其用于执行其工作的特定程序，和/或者服务器以及它们运行以保持数据流动的数据移动/后端应用程序

有时很难划清界限，过度简化的定义可能是"如果团队编写了它，那是一个应用程序；如果我们购买了它，那是基础架构"

我认为在实践中最好同时监控

回答

我们需要做的是分解应用程序的业务流程，然后让软件在主要业务组件上发出事件。另外，我们需要创建端到端的综合交易(例如，模拟最终用户点击网站)。所有这些数据都将被馈送到监视工具中。过去，我已经为应用程序完成了JMX的开发，这些应用程序流入了Tivoli Monitoring的JMX适配器，然后完成了实现"假用户"的脚本，然后将结果通过管道传送到Tivoli Monitoring的脚本适配器。 Tivoli Monitoring获取数据，然后根据该原始数据创建应用程序运行状况和性能图表。

回答

好问题。

不久前，我们一直在寻找一些满足我们需求的应用程序级监视解决方案。流行的监视解决方案主要用于监视基础结构，我认为对于大多数中小型公司而言，它们太复杂了。

我们(主要)需要以下功能：

• 警报-我们想尽快了解事件
• 轻松的管理-托管服务将是最好的
• 可视化-最好知道发生了什么并从数据中获取一些知识

因为找不到合适的解决方案，所以我们开始编写自己的解决方案。最后，我们以称为AlertGrid的启动服务结束。 (我们当然可以免费检查它。)

其背后的想法是提供一种处理自定义监视方案的简便方法。集成API非常简单(一个函数带有两个必需的参数)。目前，我们和其他人正在将其用于：

• 监视计划的任务(定时作业)
• 监视整个应用程序逻辑执行
• 警告应用程序中的错误
• 我们还在研究使用AlertGrid进行基本基础架构监视的示例