Some AppManager events are required for monitoring server health and availability and important application resources. But if you generate too many events, you risk overwhelming your staff, who might then ignore or overlook critical events.
Typically, you generate events when you want to find out what is wrong with the computers on your network and to quickly locate current and potential problems. You might also raise events for visibility and tracking. Some events let you know that a situation occurred and you intend to address it, either by acknowledging the event, running another Knowledge Script to remotely diagnose the problem, or diagnosing the system in person.
Always have a clearly defined purpose when generating events. For example, you may decide to raise events only for critical issues in your environment that need immediate attention, such as computers that are dangerously low on disk space or that have dangerously high CPU usage. If you are unsure of what to expect in your current environment, collect data for a period of time without raising events to determine a reasonable baseline for the computers you monitor. Once you have a better understanding of your environment, you can modify threshold settings and begin monitoring less critical event conditions, servers, and applications. Having a clear purpose and understanding the impact of the events you are generating helps you make informed decisions about when and how to generate and display events and can also help prevent your staff from being besieged by a sudden barrage of events.
Therefore, the first step in defining event-handling policies is to make a list of the specific types of events you need and your core Knowledge Scripts for monitoring basic computer resources. For example, most organizations begin by monitoring CPU, memory usage, disk space, disk I/O activity, network connections or activity, and the availability of specific computers or processes. In addition, many organizations monitor computer hardware components and application-specific resources, such as mailbox size for messaging servers and database connections for database servers. Although your list is likely to change over time, identifying a few specific Knowledge Scripts early on can help you avoid generating more events than you need.
Once you understand the type of events that require you to be notified, you can identify the Knowledge Scripts to raise the relevant events and create jobs to display those events.