应用程序运行状况监视系统的要求是什么?

• cpu/内存/网络使用异常。
• 报告任何未处理的异常。
• 各种模块的状态(如适用)。
• 外部组件(数据库、Web服务、文件服务器等)的状态
• 挂起的后台任务数(如果适用)。
• 也许可以跟踪应用程序的使用情况,并报告大多数/较少使用的功能的统计信息,以便您知道哪些优化最有益。

答案是“视情况而定”。你为什么需要监控?你们的操作人员有多大?你需要报告吗?什么是应用程序环境?谁在乎应用程序是否失败?谁在乎是否发生了异常?有任何错误是可恢复的吗?我可以问这样的问题很长时间。

不久前,我们一直在寻找一些应用程序级监控解决方案,以满足我们的需求,但运气不佳。流行的监控解决方案主要用于监控基础设施,而且在我看来,它们对于大多数中小型公司的要求来说过于复杂。

• 警报-我们想知道 尽可能快地处理这一事件
• 无痛管理-托管服务
• 可视化-最好知道发生了什么,并从数据中获取一些知识

AlertGrid . (当然,您可以免费查看。)

• 监视计划任务(cron作业)
• 我们还正在研究使用AlertGrid进行基础设施监控的示例

这是一个开放的问题,但我会从物理测量开始。
1.我认为所有托管此站点的机器都可以ping吗?

3.每台机器上的预期服务是否都在运行?
3a。这些服务最近运行了吗?
4.每台机器是否还有硬盘空间?(别忘了db)
5.这些机器有备份吗?上次是什么时候?



1.自动脚本可以登录吗?花了多长时间?
2.有多少用户是实时的?是否增加了一百万个假账户?

这类问题变得更加模糊,可能非常系统化。当对PHSY测量作出反应时,通常也可以得到它们。硬盘被填满了,可能是因为一群代理创造了太多的假用户,网络服务器日志被填满了。那种事。

虽然计划A不一定是被动的,但它是许多站点设置监控系统的方式。

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

我认为这是相当简单的-监控,以便您可以在出现问题之前提前得到警告。这意味着监视依赖项和应用程序本身。

如果您不打算提供所监视的应用程序的详细信息,那么很难提供详细信息,因此我建议将其作为一般规则。

至少你想知道系统是健康的。这是主观的,在什么定义您的系统是健康的。是计算机启动,所需资源存在,数据在系统中流动,数据正确产生结果,等等。

还有一些“现成的”工具,若你们只是太过努力地查看数据结果,它们会为你们做很多艰苦的工作。我特别喜欢 Nagios 当我环顾四周,但我们需要的东西比它能轻易显示的要多,所以我写了我们自己的监控系统。基本上,我们还观察系统中的“特性”、内存/cpu峰值等。。。

区别在于:

• 基础结构监视将是服务器加上MS Exchange Server、Apache、IIS等
• 应用程序监控将是用户机器和他们用来完成工作的特定程序,和/或服务器加上他们运行以保持数据流动的数据移动/后端应用程序

有时很难划清界限——过于简单的定义可能是“如果你的团队编写了它,它就是一个应用程序;如果你购买了它,它就是一个基础设施”

我认为在实践中最好同时监控这两个方面