| Solstice Enterprise Manager 4.1 Management Information Server (MIS) Guide |
|
Managing Event Logs
This chapter describes the Sun Enterprise Manager (Solstice EM) logging services.
This chapter describes the following topics:
- Section 6.1 Logging Event Files
- Section 6.2 Using Event Logging
- Section 6.3 Creating and Instantiating Logs
- Section 6.4 Creating and Defining Events to be Logged
- Section 6.5 Logging Received Events
- Section 6.6 Logging Historical Records
- Section 6.7 Merging Log Records from Different Databases
6.1 Logging Event Files
The MIS support system Management Log control functions specified in CCITT Rec. X.735 | ISO/IEC 10164-6.
Solstice EM's log management involves three main activities:
- MIS logging--MIS receives, processes, and stores events as log records in the MIT. These log records can be retrieved, updated, or purged by the Alarms via PMI.
- Historical logging--MIS historical log files store all the event log records generated during MIS event processing and logging.
- Historical Relational Database (RDB) logging--historical log files are mapped and translated into a relational database. The Log Management activities are illustrated in the following figure.
FIGURE 6-1 Event Log Management Activities6.2 Using Event Logging
Using the Event Logs, a log object can be created to capture specific MIS events. The discriminator construct of the log object specifies the type of event that is captured. Captured events become log records. Log records can be automatically reviewed and manipulated using the Alarm Manager or by the Manager affiliations.
6.2.1 Logging Services
Solstice EM provides logging services that allow applications to define log objects in the OmniPoint 1 log format, to specify the kinds of events to be logged, and to manipulate log records.
Each log object contains attributes that distinguish it from other log objects. These attributes are described in the following table.
Log objects can be created, modified, or deleted, just like any other managed objects, through the PMI. For users, the Event Logs application offers the same functions available through the PMI.
Log records are added to the log object when all of the following conditions are met:
- The notification passed the test of the discriminator construct for the log object.
- The maxLogSize has not been reached. You can choose to have the Event Logs either wrap around to the beginning of the file and overwrite existing log records, or halt, in which case no new records are created.
Note – For more information on configuring these options, refer to the Customizing Guide.
- The administrativeState is unlocked.
- The operationalState is enabled.
Log records are created when an event notification is logged in a log object. You can modify the contents of a log record through the Alarms tool. Some notifications are Alarms, that are translated to Alarm records. Alarm records are sub-classes of log records. Only Alarm records can be viewed using Alarm Manager. Log Manager can show all kinds of log records, including alarm records. For more information refer to the Customizing Guide.
Log records can be deleted by the Alarms and the Log Entries. Log records are deleted automatically as a consequence of the log full action. If the log full action is "wrap", an individual log record will be deleted from the beginning of a log object when a new record is added.
Caution – Log records that are dropped or deleted due to the log full action cannot be retrieved through the PMI since they no longer exist in the MIS.
6.2.2 Non-Default Location of Logs
The log object can reside under any containment hierarchy in the MIT, provided there is a GDMO and ASN.1 definition for the log object. Currently, only OBED can access logs in non-default locations.
Note – In the current implementation, the containment hierarchy specified in the M.3100 standard has been tested. The GDMO and ASN.1 metadata for logs conforming to this standard are the itu3100.gdmo and itu3100.asn1 documents.
6.3 Creating and Instantiating Logs
To create logs under containment hierarchies other than the default ones, and to instantiate these logs in the system, do the following:
1. Go to em/bin directory.
Instantiating the M.3100 module in this way is a short cut and is done because the network-root name binding is in the vo14.gdmo document and not in the itu31000 document. The vo14.gdmo document has other dependencies and does not compile using em_compose_all.
It is easier to load this name-binding without searching for all the dependencies of the vo14.gdmo decanting by doing the following:
To Create a Log Under managedElement
(M-CREATE)1. Create a network object instance.2. Create a managedElement instance.3. Create a log under managedElement type
/networkId= ".."/managedElementID=".."/logID=pString:".."- or
/networkID=".."/managedElementID=".."/logID=nu mber: N"6.4 Creating and Defining Events to be Logged
In general, events in MIS are not persistent. That is, they exist for the use of Solstice EM tools and your applications only while MIS is running. However, an event can be defined so that it has persistence, as in the following description.
To Create an Event to be Logged
1. In the Network Tools window click Event Logs.2. Under the Actions pull-down menu select Create.3. Use an Existing or New Filter by:
- clicking Readymade and choosing a filter, or
adding one in the space provided.
To Define an Event to be Logged
1. In the Network Tools window select Event Logs.2. Click Administration \xd4 MIS Objects.3. Under the Object pull-down menu select Create.4. In the Object Class field type log.5. Define a discriminator construct for an existing or new log object that causes events of a given type to be logged.
- For information on defining such a construct, refer to the Customizing Guide
6. Specify a mapping from an event object type to a log record type.
- When MIS receives an event of a type that fits the criteria of a discriminator construct, MIS logs the event in a log record of the type specified in the mapping for that event type.
To View the Mapping Between a Log Record and its Event
1. In the MIS Objects window click EM-MIS.2. Double-click Events Object Class.
- For more information and examples on defining events for persistence, refer to the Customizing Guide.
Alarms are a particular type of event indicating an abnormal condition. By default, Solstice EM logs all alarms (called "AlarmLog"), which means that the default discriminator construct accepts alarm events such as:
- logged (which would be true for any event type that fits the criteria of an Event Logs discriminator construct and has a mapping to a log record type)
- have attributes that allow them to be acknowledged and cleared
- are recognized by and displayed in Alarm Manager
The default alarm types supported by Solstice EM and the log record types to which they are mapped are listed in the following table.
The mapping shown above is defined in the file init_platform, and stored by default in $EM_HOME/install/em_platform. The mappings are implemented by the object event2ObjectClass, whose LDN is subsystemId="EM-MIS"
/listname="event2Objec tClass". Solstice EM allows you to define new events to be mapped on new log records.
To Create a New Type of Alarm Record
1. Derive a new alarm record from emAlarm Record.2. Create a mapping in evr2oC between the events to be logged in and this new log record.
Note – All alarm log records, including emInternetAlarmRecord and nerveCenterAlarmRecord, are derived from emAlarmRecord.
- Together, the standard log object and Solstice EM-specific log object types have a rich functionality that will accommodate most alarm-logging needs. To establish a mapping at runtime, use MIS Objects application to edit evr2oclist or the init_platform file, then restart MIS.
6.5 Logging Received Events
In order to log events forwarded from various application (such as other MISs, Agents, objects in MIS) you must create a log object containing a discriminator which will create log records for the desired events.
To Create a Log Object Containing Discriminator
1. Select Event Logs \xd4 Actions \xd4 Create Log.2. Type the appropriate information in the window fields.
- For more detailed instructions on creating a log object, refer to the Customizing Guide.
- To log every event the Manager MIS receives, type the discriminator definition in the discriminatorConstruct field: and : {}
- To log all attributeValueChange events in one log record, type :item : equality : {eventType, attributeValueChange} in the discriminatorConstruct field.
- This log object will log each attribute value change known by the local and forwarding entity.
3. Click OK.6.6 Logging Historical Records
Historical logging is an extension of MIS logging in the sense that every log record will be kept in a historical log, and there is no log size limitation that forces old logs to be removed. The purpose of historical logging is to provide statistics of log records over a long period of time, which MIS logging cannot support. For Solstice EM log tables, see Chapter A.
During the historical logging process, MIS stores each log record in a historical log file. Each event that is logged in the persistence store is also logged in a historical log file. The historical log file can contain many event logs or records.
6.6.1 Enabling Historical Logging
The environmental variable <EM_HLOG_INTERVAL> defines the rate (in hours) that the historical log files are created in EM_HLOG_DIR (default is /var/opt/SUNWconn/em/data/HLOG). If the value of <EM_HLOG_INTERVAL> is 0 (default), then the historical log files are not created. You must set <EM_HLOG_INTERVAL> to a positive value by typing the following series of commands:
- em_services -stop
setenv EM_HLOG_INTERVAL <number_of_hours>
em_services -startSpecify a positive integer in place of <number_of_hours> in the command shown above. A new HLOG file is created after every <number_of_hours> hour.
6.6.2 Logging Historical Log Files
Historical log files contain many event log records. Each logical event log record contains information that describes the event. Logical event log records are separated by a blank line.
Unless specified otherwise, historical log files are located in the directory specified by the EM_HLOG_DIR environment variable (the default is /var/opt/SUNWconn/em/data/HLOG.). Type the naming convention for historical log files using the configuration logID.yymmddhh.
Different types of log record events (for example, alarmRecord and objectCreationRecord) have a set of common attributes. These attributes are derived from the eventLog. Each log record contains a description that includes the type of event, where the event occurred, etc., and can be many lines in length. Each description field is separated by the delimiter ":". The optional fields appear at the end of the record, or as attribute value pairs.
The following code example illustrates one description of a log record and CODE EXAMPLE 6- 2 provides an example of a log record specific for alarmRecord. Each description is separated by a blank line or carriage return.
CODE EXAMPLE 6-1 Generic Log Record Format
Note – New line characters are explicitly shown when present and the eventTime field is optional.
CODE EXAMPLE 6-2 Sample Log Record of alarmRecord Type
6.6.2.1 Configuration File
Information such as the type of database, server name, user name, and password is required to connect to a database. All of these parameters are located in a configuration file that overrides default locations and file names. In addition, specification of this information via the command line overrides the configuration file information.
Note – If the em_log2rdb daemon is unable to connect to the database, stderr is notified and the process is terminated.
The default configuration file is named em_log2rdb.cfg and is located in $EM_RUNTIME/conf/ where the $EM_RUNTIME default is /var/opt/SUNWconn/em
The configuration file contains the following information:
- DBTYPE <dbtype>
- SERVER <server_name>
- USER <user_name>
- DATABASE <database_name>
- SCHEMA <schema_definition_file_name> ;
- HISTORYFILEPATH <historical_log_file_path>
- SLEEP <time_in_seconds>
- PASSWORD <user_password>< /font>
- comments that are preceded by "//"
Note – The default configuration location and file name can be overridden by providing these as parameters on the command line.
6.6.2.2 Database Schema Definition File
In order to map the event information in the historical log files to corresponding database tables, a database schema definition file is accessed. This definition file contains information such as how the database table is structured and how the log record description maps or relates to the tables. After the mapping or translating is complete, the database tables are updated with log record information.
The default database schema definition file is named em_log2rdb.def and is located in $EM_RUNTIME/conf/ where the $EM_RUNTIME default is /var/opt/SUNWconn/em
Note – The definition file location and file name can be modified in the configuration file.
CODE EXAMPLE 6- 3 example shows the generic schema definition file. CODE EXAMPLE 6- 4 is a sample of this file.
CODE EXAMPLE 6-3 Generic Schema Definition File
The schema definition file in the following code example shows the file definitions for the Solstice EM em_log2rdb daemon.
CODE EXAMPLE 6-5 Schema Definition File for em_log2rdb Daemon
{ //block ( nl delimited ) fixed pos flds{DEFN emString ({DEFN emInt ({DEFN emDate ({6.6.2.3 Database Schema Mapping
Common attributes of eventLog are stored in a single table named eventLog. One table is defined for storing specific attributes of any one class of records. These records are related to the eventLog with a key made up of logID(coded)+logRecordId. Coded logID is a number assigned by the em_log2rdb daemon and can be found in Solstice EM database tables.
For each log record of a known type, one record is created in the eventLog table and one is created in the corresponding table of that type. In CODE EXAMPLE 6- 5, probableCause and perceivedSeverity fields are stored in emAlarmRecord table, while all other common fields are stored in eventLog table.
Special handling is provided for lists of common items. Each list, called a SETOF, is delimited in the log history records by {} and stored in a separate table, the structure of which corresponds to the fields in the list.
For every attribute that is present, a record is created in a table structured to hold lists of changes.
The following figure shows an Entity Relationship (ER) diagram for the log record database. An internal primary key em_this_rn and an internal foreign key em_key_rn are used to relate the common part of a log record with its type-specific information.
FIGURE 6-2 Entity Relationship Model for Log Record DatabaseLog Record Types
The log record types supported by the platform are as follows:
- attributeValueChangeRecord
- emAlarmRecord
- objectCreationRecord
- objectDeletionRecord
- relationshipChangeRecord
- stateChangeRecord
- emInternetAlarmRecord
- nerveCenterAlarmRecord
6.6.2.4 Database Tables
The following table lists the tables created by the em_log2rdb daemon. The tables that are created are specified in the configuration file. These tables correspond to the log record types and contain miscellaneous system information. The following is a list of the database tables:
- eventLog
- emString
- emInt
- emDate
- emSetof
- emAttrValChgDef
- objectCreationRecord
- objectDeletionRecord
- emAlarmRecord
- attributeValueChangeRecord
- relationshipChangeRecord
- emInternetAlarmRecord
- nerveCenterAlarmRecord
Two additional tables are created for special functions to contain a master list of tables and emLogHist to contain information used for tracking processed log history files.
In the following table, each entry has a table ID (TBLID). For a table that stores log records, its table ID starts from 1. For a table that stores elements of a setof attribute, its table ID starts at 1001. For such entries, the table ID is used in place of its attributes value in the log record table. TABLE 6-4 is a sample attributeValueChangeRecord table.
TABLE 6-3 Sample Master List of Tables emString 1001 emInt 1002 emDate 1003 emSetof 1004 emAttrValChgDef 1005 eventLog 1 objectCreationRecord 2 objectDeletionRecord 3 emAlarmRecord 4 attributeValueChangeRecord 5 securityAlarmReportRecord 6 relationshipChangeRecord 7 emInternetAlarmRecord 8 nerveCenterAlarmRecord 9
TABLE 6-4 Sample attributeValueChangeRecord 3 1005 managementOperation 1001 4 1005 managementOperation 1001 5 1005 managementOperation 1001 6 1005 managementOperation 1001 7 1005 managementOperation 1001 8 1005 managementOperation 1001 9 1005 managementOperation 1001 12 1005 managementOperation 1001 16 1005 managementOperation 1001 20 1005 managementOperation 1001 24 1005 managementOperation 1001 28 1005 managementOperation 1001
The attributeValueChangeRecord table has two sets of columns:
- attributeValueChangeDefinition
- attributeIdentifierList
The elements for the attributeValueChangeDefinition column are stored in the emAttrValChgDef table, so 1005 is stored as the value of this column by looking up TABLE 6-3. For this reason, 1001 is stored as the value for the attributeIdentifierList column, since its elements are strings. The relationship between each element and its owner record is stored in the emSetof table.
Tables 6-5 through 6-12 illustrate specific system information for the database tables that are created by the em_log2rdb daemon.
TABLE 6-5 eventLog em_This_Rn Mandatory int 4 Primary Key logID Mandatory varchar < 255 Key Field (for example, "AlarmLog") logRecordId Mandatory int 4 Key Field (for example, "1") logRecordClass Mandatory varchar < 255 For example, "objectCreationRecord" eventType Mandatory varchar < 255 For example, "objectCreation" loggingTime Mandatory time "yyyymmddhhmmss" format in the log file managedObjectClass Mandatory varchar < 255 For example, "emApplicationInstance" managedObjectInstance Mandatory varchar < 255 For example,
`/systemId="vidhi"'eventTime optional time "yyyymmddhhmmss" format on file notificationIdentifier optional int 4 correlatedNotifications optional varchar < 255 additionalText optional varchar < 255 additionalInformation optional varchar < 255
TABLE 6-6 objectCreationRecord em_This_Rn Mandatory int 4 Primary Key sourceIndicator Optional char 1 `1'=resourceOperation `2'=managementOperation `3'=unknown attributeIdentifierList Optional boolean 1 SET OF AttributeId*
TABLE 6-7 objectDeletionRecord em_This_Rn Mandatory int 4 Primary Key sourceIndicator Optional char 1 `1'=resourceOperation `2'=managementOperation `3'=unknown attributeList Optional boolean 1 SET OF Attribute
TABLE 6-8 emAlarmRecord em_This_Rn Mandatory int 4 Primary Key probableCause Mandatory varchar < 255 Choice syntax in dmi.asn1 perceivedSeverity Mandatory char 1 `1'=indeterminate, `2'=critical `3'=major `4'=minor `5'=warning `6'=cleared specificProblems Optional varchar < 255 Optional of alarmRecord backedUpStatus Optional boolean 1 Optional of alarmRecord backUpObject Optional varchar < 255 Object instance trendIndication Optional char 1 `1'=lessSevere, `2'=noChange, `3'= moreSevere thresholdInfo Optional varchar < 255 stateChangeDefinition Optional boolean 1 Type avChangeDefinition monitoredAttributes Optional varchar < 255 proposedRepairActions Optional varchar < 255 ackState Mandatory char 1 `1'=unAcked `2'=acked ackTime Mandatory time ackOperator Mandatory varchar ackText Mandatory varchar < 255 clearState Mandatory char 1 `1'=unCleared `2'=cleared clearTime Mandatory time clearOperator Mandatory varchar < 255 clearText Mandatory varchar < 255 displayState Mandatory char 1 `1'=unDisplayed, `2'=displayed displayTime Mandatory time displayOperator Mandatory varchar < 255 displayText Mandatory varchar < 255
TABLE 6-9 attributeValueChangeRecord em_This_Rn Mandatory int 4 Primary Key avChangeDefinition Mandatory boolean 1 sourceIndicator Optional char 1 `1'=resourceOperation, `2'=managementOperation, `3'=unknown attributeIdentifierList Optional boolean 1 SET OF AttributeId
TABLE 6-10 relationshipChangeRecord em_This_Rn Mandatory int 4 Primary Key rcChangeDefinition Mandatory varchar < 255 avChangeDefinition sourceIndicator Optional char 1 `1'=resourceOperation `2'=managementOperation `3'=unknown attributeIdentifierList Optional boolean 1 SET OF AttributeId
TABLE 6-11 emInternetAlarmRecord em_This_Rn Mandatory int 4 Primary Key ackState Mandatory char 1 `1'=unAcked `2'=acked ackTime Mandatory time ackOperator Mandatory varchar < 255 ackText Mandatory varchar < 255 clearState Mandatory char 1 `1'=unCleared `2'=cleared clearTime Mandatory time clearOperator Mandatory varchar < 255 clearText Mandatory varchar < 255 displayState Mandatory char 1 `1'=unDisplayed `2'=displayed displayTime Mandatory time displayOperator Mandatory varchar < 255 displayText Mandatory varchar < 255 probableCause Mandatory varchar < 255 attributeIdentifierList Optional boolean 1 objectInstanceList Optional boolean 1
TABLE 6-12 nerveCenterAlarmRecord em_This_Rn Mandatory int 4 Primary Key probableCause Mandatory varchar < 255 perceivedSeverity Mandatory char 1 `1'=indeterminate `2'=critical `3'=major `4'=minor `5'=warning `6'=cleared specificProblems Optional varchar < 255 An optional alarmRecord backedUpStatus Optional char 1 All fields of em_alarm_rec start backUpObject Optional varchar < 255 trendIndication Optional char 1 `1'=lessSevere `2'=noChange `3'= moreSevere thresholdInfo Optional varchar < 255 stateChangeDefinition Optional boolean 1 avChangeDefinition monitoredAttributes Optional varchar < 255 proposedRepair
ActionsOptional varchar < 255 ackState Mandatory char 1 `1'=unAcked `2'=acked ackTime Mandatory time ackOperator Mandatory varchar < 255 ackText Mandatory varchar < 255 clearState Mandatory char 1 `1'=unCleared `2'=cleared clearTime Mandatory time clearOperator Mandatory varchar < 255 clearText Mandatory varchar < 255 displayState Mandatory char 1 `1'=unDisplayed `2'=displayed displayTime Mandatory time displayOperator Mandatory varchar < 255 displayText Mandatory varchar < 255 All fields of em_alarm_rec end mosiSeverity Mandatory int 4 mosiStateID Mandatory int 4
Note – All these attributes are of list type. These attributes are optional fields in the database table.
6.6.2.5 Database Schema Parser
Log records are derived from eventLog. Additionally, new types of log records can be defined by deriving from the base eventLog and adding new attributes. This allows the database structure to be configurable. Therefore, a mechanism exists that facilitates dynamic addition to the known types of event records by using a description language to define all record types and their structure. An initialization file containing these descriptions is processed each time the daemon is started; it must contain a definition of the base record and all other possible records. If it is determined that database tables corresponding to each record type do not already exist, then they are created; it is possible to set a configuration option that will cause the system to fail instead.
Along with the basic data types (such as int and string), the more complex SETOF data type is supported. The SETOF attribute type is a list. If N elements are present in one instance of such an attribute type, then N elements are created in a table, emSetof, which corresponds to the list structure. (This table is defined in a similar fashion as a record.) On encountering a data element set, a record is written to the emSetof table in addition to the actual data being written to its corresponding table.
6.7 Merging Log Records from Different Databases
It is possible to create a view that merges log records of the same type from various databases so that the report tool can use the view to generate a report.
For example, suppose the log records from MIS A and MIS B are stored into Server A and Server B, respectively. The following code example shows an SQL statement that creates a view called emAlarmRecord that unions the alarm record table from Server A and Server B for joint reporting purposes.
CODE EXAMPLE 6-6 SQL Statement
As the view does not contain a join, querying this view is just as fast as querying the underlying tables that comprise the view.
Note – The em_log2rdb is discontinued in the Solstice EM 4.1 release and hence would discourage the user from using it.
|
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |