Now that you are acquainted with how to view, filter, and create events, let’s seem at a technique using event triggers that you can use to mechanize the event monitoring process. With event triggers, you can configure system everyday jobs that monitor the event logs and then take a exact action if an event occurs. For example, you can create a trigger that monitors the event logs for low disk space events and if such events happen, you can run a script that remove any temporary or needless files to decide the low disk space condition. Thus, not merely can event triggers help you automate the monitoring process, the actions triggers take can also help you determine issues as they arise to maintain system performance, ensure system integrity, and more.

Creating event triggers isn’t something you should do carelessly, without careful consideration. You need to have a clear plan of action—a set of goals that you hope to achieve by using event triggers. Let’s take a look at the reason you might want to use event triggers and then look at the tools you can use to direct them.

Why Use Event Triggers?

Maintaining application and system presentation is a key reason for using event triggers. For example, if an application running on a server has known issues that you typically have to resolve physically, you may be able to configure event triggers that monitor the event logs for connected errors and then run scripts that take the suitable actions to resolve the problem. Here, you would want to track down the known issues for the application by searching the event logs, asking other administrators about issues, or searching for knowledge-base articles that describe the issues. Afterward, match issues to precise events or types of events for which you can arrange event triggers to monitor, and then write a script that notifies administrators of the issue or takes suitable actions to decide the issue. This script is then used as the task that the event trigger runs.

Another common reason for using event triggers is to help you recognize request and repair outages quickly, and to possibly restore normal operations. When an application or service stops, users can no longer use the resource and this can cost the organization dearly in time, money, and wasted resources. Here, you would want to search for documentation on the types of errors that can occur if the request or service isn’t respond normally. Then, searching the event logs to see if you find analogous or matching events in the logs, you would note sources, event IDs, and descriptions used so that you can create event triggers to watch for the connected events. Lastly, you could write a script that restarts the request or takes other suitable actions to resolve the outage.

You may also want to use event triggers to help you preserve system security and honesty. When a system is under attack, events may be written to the log files that indicate the application, component or service that is under attack. With a brute force attack, a hacker may be trying a variety of user name and password combination in an effort to gain access. If you are monitoring the system under attack, you would see failed logon attempt in the safety logs as the hacker attempt to gain access. A hacker may also try to bring down the system, request, or service using a denial-of-service attack. Characteristically hackers deny service by sending incessant streams of malformed service requirements. These attempts should show up in the related application, system, or service-specific logs as errors. To combat such attack, you could configure event triggers that watch for related events, such as account lockouts due to a series of failed logon attempts.

Getting Ready to Use Event Triggers

Previous to you start creating event triggers, you be supposed to consider what you hope to achieve through automatic monitoring, as well as any crash the monitoring might have on the exaggerated systems and the network as a whole. You should

• Recognize the events you want to monitor and define the reasons for monitoring each event. Use the event logs on multiple systems and certification of known issues and errors, such as knowledge-base articles, to help you locate places to start.
• Identify the actions you want to take when an event occurs. Originally, write this as a list. Be sure to consider the collision any remedial actions might have on the system or the system as a whole.
• Write scripts or application to handle the essential corrective actions or user notifications. Don’t implement them as triggers yet. You be supposed to test the scripts first on an inaccessible network or development system to uncover any flaw in the planning.
• Define the event triggers and the tasks to carry out, and then realize the triggers. Make sure you monitor the exaggerated systems intimately for the next several days or weeks to make sure there are no unfavorable affects.
• Maintain and remove triggers as necessary to ensure continuing operations.

Steps 1, 2, and 3 can be talented using the earlier discussions in this and other chapters of this book. Steps 4 and 5, however, involve the process of defining, maintaining, and removing event triggers. These processes are handling with the following subcommands of the Event triggers utility:

• Event triggers /create - Creates a new event trigger and sets the action to take
• Event triggers /query - Displays the event triggers at present configured on a specified system
• Event triggers /delete - Removes an event trigger when it is no longer wanted

Note: Unlike most other commands with subcommands, Event triggers subcommands use a forward slash (/).