Working with Event Details

In this Topic ShowHide

Basic Tasks

Detaching an Issue

Advanced Tasks

To access this page, go to Monitor | Events and select an issue ID from the list.

This page shows aggregated details regarding the events that triggered a specific rule. The details include audit trail information and options for investigating and resolving issues.

For a more detailed description of events and issues, see Monitor.

The actions in the issue details page can be divided into two categories:

Basic Tasks: Simple actions that can be applied to the page.
Advanced Tasks: Advanced actions for diagnosing and managing the content of the issue.

Event Drilldown

Basic Tasks

The following actions can be applied in an issue.

Return to the Events page.
To return to the Events page, click Return
Refresh an issue's details.
To refresh an issue, click Refresh
Detach an issue

Detaching an Issue

This procedure describes how to detach an issue. Detaching an issue is the process of opening an issue in a new popup window. This feature can be used to display several events at the same time.

To detach an event:

Go to Monitor | Events.
Select an issue from the table and open the issue (click on the event ID).
The event is displayed.
In the opened issue, click Detach .
The issue is opened in a new popup and the main page returns to the Events list.

Once an issue is detached, it cannot be re-attached. This process can be repeated to open several issues at the same time.

Advanced Tasks

Issues contain different types of information and actions that allow you to detect the source and drill down to investigate what caused a problem. In some cases (and depending on the type of event that happened), the information also indicates the solution. For example, issue information includes the exact line of code that has a problem and the nature of the problem.

Basic Details

The first layer of issue details are the basic details. These details are used to identify an issue with high-level characteristics. Every issue includes the following basic details:

ID and Rule Name - The ID number is a unique identifier for a specific issue. The Rule Name states the rule (defined in Rule Management | Monitoring) that triggered the event. The ID number can be used to locate a specific issue using in Monitor | Events. The Rule Name indicates the rule that triggered the event: Several issues can be triggered by the same rule. Knowing the rule name makes it easy to find the rule if you want to modify the rule settings (Rule Management | Monitoring | Edit).
Occurrence Info - An issue is a collection of aggregated events: This detail specifies how many times this event occurred since the first time.
Status - The Status indicates the state of the issue. In some cases, the Status changes automatically. The Status can be used to locate events in the Events page: Use a filter to display the specific status.
Severity - Currently there are two severity levels, Critical and Warning. These levels reflect your preferences, in terms of the importance of the event.

General Details

Each issue is an aggregation of one or more events with common, predefined characteristics. These common characteristics are displayed in the General Details section. Therefore, you can assume that each event that occurred for this issue has at least these details in common. This is the first step in identifying the source of the event and understanding the circumstances surrounding the event.

Group Details

Grouping is yet another additional aggregation layer applied to an issue. Inside a single issue, events are divided into groups according to the time they occurred. A new group is created only if there was no activity for at least five minutes. If a new event occurs after five minutes have passed, a new group is added to the issue.

Group Details show how many groups were created for an event, when a group was created and how many events are in a group. When the event is also a relative or quantitative event, an additional "Runtime" column is added to show the time it took to perform the action. This helps you determine if there are differences in the event's runtime, identify which events took longer and what else may have happened when the event occurred (for example, did the event occur during a peak load, or during a DB query, etc.).
Group Drilldown - Clicking on a group changes the contents of tabbed display to show the details collected for that specific group of events.
Diagnostic Actions - These actions can be applied to each group to investigate what caused the event. The diagnostic actions are Debug, Profile and Show File in Zend Studio. All these actions run on the server defined in . By default, the settings are set to run diagnostic actions on the originating server (the server on which the event was created). You can change the settings to run on a different server.

Note:

When you use these actions, make sure that you have Zend Studio on the remote machine, access to the remote server and that the remote server is an allowed host. For more details, see Error: Failed to Communicate with Zend Studio.

Action Buttons

Export

The Export option creates a file with a .zsf prefix that contains all the information collected for the event. This includes and Basic and General Details of a specific Group.

If Zend Code Tracing data was collected for the group (see Setting a Monitor Rule to Run a Code Trace), it will also be included in the exported file.

This file can then be viewed in Zend Studio's Integration section. The "Export" feature allows you to export all the data related to an event as a file that can be opened in Zend Studio for further analysis. Examples of analysis are, executing a debugging session based on the event context information, or viewing and analyzing relevant Code Tracing information, again only if such information was captured by the server.

The flexibility of creating a file means that you can easily email the file to be opened in a Zend Studio that does not have any connection to a server. This can be useful for diagnosing sensitive trace information and preserving security protocols.

For instructions on exporting Zend Code Trace information to a Trace file see Exporting Trace Information.

Some events may not include this option, This only happen in events that collect information that is not relevant for debugging.

Show Code Tracing

This option is only available if you have Zend Code Tracing set for the Event, see Setting a Monitor Rule to Run a Code Trace.

The Show Code Tracing option opens the Zend Code Trace Tree and Statistics views for the specific trace information collected for the event you are in.

Change Status

The Change Status option provides an easy way to manage issues. Issues that are assigned an appropriate status can be efficiently filtered to control which issues to display in Monitor | Events.

The following summary describes what happens to issues when they are created and what happens when new events are added to issues that have a changed status.

New events are created with the status New.
If the event status is Closed and a new issue occurs, the event status is changed to Reopened.
If the event status is Ignored and a new issue occurs, the event status does not change. However, the system continues to collect information about the event.

To change an issue's status:

Go to Events and select an issue from the list.
In the issue details page, scroll down to the bottom and use the drop-down list to select a status.
Closed - Changing an issue's status to closed will close the issue until a new event of that type occurs and then the issue will automatically be changed to Open.
Open - Changing an issue's status to Open can be applied to issues that are in status, closed or ignored.
Ignore - Changing an issue's status to Ignored will keep the same status even when new events occur.
Click to apply changes.

The status in the basic details area and in Monitor | Events will be changed accordingly.