priately, this can be converted to an event where the failure object is narrowed down to either the router or its interface. Event filters allow still further processing of the event and generating actions, such as e-mailing a human operator. Filter actions might also include suppression of mul- tiple events in a given interval, the running of shell commands on a server system, sending e-mails or traps and running custom Java code to filter events. Custom Java code may be needed where additional data must be retrieved or specific code applied to process the event. Processed events are stored in RDBMS tables or logged into flat files and made available to the event browsers in a client. In modern fault management OSSs, 12 Fault Management Autonomous Traps Messages Autonomous Handler Message Handler Traps Trap Filter Trap Parser Events Trap Observer Events Event Processor Other Events Event Parser Suppress Events Execute Commands Event Filter Client Send Traps Send Email Events User Filters Observer Event Correlator Alerts Suppress Events Execute Commands Alert Processor Send Traps Alert Filter Send Email User Filters Alerts Client Listener Figure 12.5 Detailed event flow. the new information is generally available to event browsers immediately upon the processing of an event, limited only by the network over which the OSS system is running. The processed events are then sent to the fault manager for higher-level event processing. The primary element used by the fault manager is the failure object identified in event processing. Using this as a key to the fault, the events are processed to create or update alerts as appropriate. For all the events with the same failure object, only one alert object with the same failure object is created/updated. The alert object reflects the status of the latest event with the same failure object. Alert filtering can be applied for processing alert and executing appropriate actions. Alert filter actions available are generally the same as event filter actions. The processed alerts