The console receives, logs,
and displays events generated by managed servers and by the console
itself.
The majority of the events
are generated by the Sun StorEdge Configuration Service Agents on the
managed servers and occur when there are:
- Status changes on any
device on a managed server, including the server itself (because of
device failure, malfunction, or disconnection)
- Inventory changes (addition
or removal of devices)
- Configuration changes
(initial configuration setup and subsequent configuration changes)
- Array processes running
on the server (initialization, parity checking, rebuilding)
Although array processes
are initiated by the console, it is the server agent that generates
operation notification events after these processes start on the server.
The console generates a much
smaller number of events. For example, it generates an event if it does
not receive a certain number of consecutive heartbeats from a
managed server.
When the console receives
any event, it logs in to the Event Log file, eventlog.txt, and
displays it in the Event Log window. Also, if the event occurs
on a server, the notification of the event is sent to that server's
operating system event log. In addition, when the event occurs on a
server and that server is set up to send traps to an SNMP enterprise
management console, such as HP OpenView, the server agent also sends
a trap message to that computer.
Depending on the event received,
the console can initiate a refresh process to request the inventory
from the last periodic scan of the server involved, so the console can
update the server's inventory on the main window.
During this refresh process,
the satellite dish icon is attached to the server icon, and you are
not be able to perform any configuration and array activity commands
on that server until the process is completed and the main window is
updated.
Event Log File
The Event Log window
displays up to 500 events at a time. If you have more than 500
events, only the most recent 500 are displayed in the Event Log
window; however, Sun StorEdge Configuration Service does not delete
any events from the Event Log file, eventlog.txt, until more
than 10,000 events have been logged.
- After 10,000 events, Sun
StorEdge Configuration Service reduces the Event Log file to
the most current 500 events, and then accumulates events until the
limit of 10,000 is exceeded again.
- The fields of each event
record are separated by a semi-colon so you can easily import the
file into a database.
- eventlog.txt is
located in the directory where the Sun StorEdge Configuration Service
Console program files are installed.
NOTE:
If the event log appears not to contain all of the events from the managed
array, close and reopen the console.
The events from the agent
are logged into the system log of the host where the agent is installed,
even if the console isn't running. The following table lists the locations
where the events are logged to in each of the operating systems.
Operating System |
Event Log Location |
Solaris OS |
/var/adm/messages
(Also shown on the console) |
Linux OS |
/var/log/messages |
Microsoft Windows OS |
The application log
of the system, which can be viewed using Event Viewer. You can also
read the event log directly from the file \Program Files\Sun\sscs\eventlog.txt |
HP-UX OS |
/var/adm/syslog/syslog.log |
Filtering Events
Sun StorEdge Configuration
Service generates event log entries for three severity levels: informational,
warning, and critical. All three types are marked as "Error"
in the log file. If you want to limit your event monitoring to critical
events only, you can do so by editing the /etc/init.d/ssagent
file. Modify /etc/init.d/ssagent as follows.
- After the line _start),
add the following two lines:
SSCS_SUPPORT_MESSAGELEVELS=1
export SSCS_SUPPORT_MESSAGELEVELS
- Stop and restart
the Sun StorEdge Configuration Service agent.
/etc/init.d/ssagent stop
/etc/init.d/ssagent start
To Write Events to a Log
File for an IBM AIX Host
For an IBM AIX OS,
the event logs are not logged by default. You might need to change /etc/syslog.conf
to enable it to write to a log file.
- Modify /etc/syslog.conf
to add the following line:
*.info /tmp/syslog rotate size 1000k
- Make sure the file that
is specified in the added line exists.
If it does not exist, you need to create it. For example, in the above
configuration, you would create a file named /tmp/syslog.
- Change to /tmp/syslog
and restart the syslog by typing
kill -HUP `cat /etc/syslog.pid`
Event Log Window
To access Event Log,
choose View > Event Log. This window can be hidden by clicking
Close and reopening (from the View menu) without losing
any content.
The console begins to receive
events when they are running, regardless of whether the Event Log
window is open.
- To delete the log file,
click Delete Logfile.
The Confirmation window
is displayed, prompting you to save the log file.
- Select one of the following
options:
- Select yes at
the prompt, select a folder and a file name, and save the log file.
- Select no at
the prompt. The log file is deleted.
NOTE: You can also
save and delete the contents of the eventlog.txt file by using
the Save Event Log and Delete Event Log icons on the toolbar.
Each event record contains
the following fields:
Date |
The date on the server
when the event occurred |
Time |
The time on the server
when the event occurred |
Server |
The IP address of the
server and the server name |
Card |
The card name, if applicable,
for the event |
Severity |
One of three severity
levels: Critical, Warning, or Informational |
Error
Code |
The basic error code
and the extended error code, separated by a dash |
Text
Message |
A text message describing
the event |
Severity Levels
- Critical - A message
that does require intervention by the network administrator, such
as the failure of a device, power supply, or fan.
- Warning - Warning
messages generally indicate internal program events. However,if you
see a large number of these messages, it may mean that there is a
problem with the server or the network.
- Informational - A message about the devices on the server that does not require intervention
by the network administrator.
You receive alarm forwarding
for the level selected and any other levels of a higher severity. Thus,
if you choose Informational, you are notified of all alarm conditions.
However, if you choose Critical, only critical alarms are received.