Solstice Enterprise Manager 4.1 Management Information Server (MIS) Guide Doc Set ContentsPreviousNextIndex


Chapter 6

Managing Event Logs

This chapter describes the Sun Enterprise Manager (Solstice EM) logging services.

This chapter describes the following topics:

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:


FIGURE 6-1   Event Log Management Activities

6.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.

TABLE 6-1   Log Object Attributes
Attribute Name Description
logIdentifier
Each log object is identified by its Fully Distinguished Name (FDN) in the MIS's MIT.
discriminatorConstruct
A test that decides whether to log an arriving notification (test can be modified).
maxLogSize
Each log object has a maximum size and an attribute that indicates when its maximum size has been reached. A maximum size set to zero indicates no limit. Size is expressed in octets (size can be modified).
currentLogSize
Number of octets the log object and its records that now occupy in MIS (reportable, but not an attribute that can be modified).
nameBinding
Specifies position of log object in the MIS's MIT, beneath the
/system/log branch (reportable, but not an attribute that can be modified).
objectClass
This class is nearly always log (reportable, but not an attribute that can be modified).
numberOfRecords
The number of log records currently written in the log object (reportable, but not an attribute that can be modified).
logFullAction
(wrap/halt)
When the log is full, it either stops accepting new records or starts to overwrite the oldest records, according to the value of this attribute (can be modified).
administrativeState
(locked/unlocked)
If locked, no events will be recorded as log records. When set to locked, the log object cannot be written to. When set to unlocked, allows the log object to be written to (can be modified).
operationalState
(enabled/disabled)
When set to enabled, the log object is "up." When set to disabled, the log object is "down" (reportable, but not an attribute that can be modified).


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:

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.

> cd /opt/SUNWconn/em/bin

2. Instantiate the M.3100 module and its definitions.

> em_compose_all 
/opt/SUNWconn/em/etc/gdmo/itu3100.gdmo

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:

> em_load_name_bindings network-root

 

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.

TABLE 6-2   Default Alarm Types and Log Record Types 
Notification Type Log Record Type
attributeValueChange
attributeValueChangeRecord
coldstartTrap
eminternalAlarmRecord
communicationsAlarm
emAlarmRecord
environmentalAlarm
emAlarmRecord
equipmentAlarm
emAlarmRecord
integrityViolation
securityAlarmReportRecord
objectCreation
objectCreationRecord
objectDeletion
objectDeletionRecord
operationalViolation
securityAlarmReportRecord
physicalViolation
securityAlarmReportRecord
processingErrorAlarm
emAlarmRecord
qualityofServiceAlarm
emAlarmRecord
relationshipChange
relationshipChangeRecord
securityServiceorMechanismViolation
securityAlarmReportRecord
serviceReport
securityAuditTrailRecord
snmAlarmEvent
emAlarmRecord
snmAlarmTrap
emAlarmRecord
snmAlarmError
emAlarmRecord
stateChange
stateChangeRecord
timeDomainViolation
securityAlarmReportRecord
internetAlarm
emInternetAlarmRecord
nerveCenterAlarm
nerveCenterAlarmRecord


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 -start

Specify 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

logID::logRecordId::logRecordClass::eventType::loggingTime::eventTime<RETURN>
managedObjectClass::managedObjectInstance <RETURN>
Optional attribute1=Opt-value1<RETURN>
Optional attribute2=Opt-value2<RETURN>
Optional attribute2=Opt-value2<RETURN>
...
Specific attribute1=Spe-value1<RETURN>
Specific attribute2=Spe-value2<RETURN>
logID::logRecordId::logRecordClass::eventType::loggingTime::eventTime<RETURN>
managedObjectClass::managedObjectInstance <RETURN>
Optional attribute1=Opt-value1<RETURN>
Optional attribute2=Opt-value2<RETURN>
...
Specific attribute1=Spe-value1<RETURN>
Specific attribute2=Spe-value2<RETURN>
...


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

TestLog::2::alarmRecord::communicationsAlarm::1995012413
5508::19
950124135508<RETURN>
system::/systemId=name:"mutley"<RETURN>
probableCause = localValue : 16<RETURN>
probableCause = localValue : 16<RETURN>

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 
attribute-1    data-type(length),
.
.
.
attribute-1    data-type(length)
)

CODE EXAMPLE 6-4   Sample Schema Definition File
RECORD event_log (
{
logID                    VARCHAR       REQUIRED,
logRecordId              INT           REQUIRED,
logRecordClass           VARCHAR(60)   REQUIRED,
eventType                VARCHAR(40)   REQUIRED,
loggingTime              DATETIME      REQUIRED,
eventTime                DATETIME,
}
{
managedObjectClass       VARCHAR(60)   REQUIRED,
managedObjectInstance    VARCHAR(60)   REQUIRED,
}
notificationIdentifier   INT,
correlatedNotificaitons  VARCHAR(60),
additionalText           VARCHAR,
additionalInformation    VARCHAR,
}

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 
// This file contains file definitions for em_log2rdb
//
// The first Record definition must be eventLog and it 
must contain
// logRecordId field. All other record definitions will 
implicitly
// contain a log record type field, along with two other 
key fields
// relating that record to its parent
// Primary Records
RECORD eventLog (
{     //block ( nl delimited ) fixed pos flds
logId          string(60)   REQ,
logRecordId    int          REQ,
logRecordClass string(60)   REQ,
eventType      string(60)   REQ,
loggingTime    datetime     REQ,
eventTime      datetime
}
{
managedObjectClass          string(60)    REQ,
managedObjectInstance       string        REQ
}
notificationIdentifier      int,
correlatedNotifications     string(1024),
additionalText              string(1024),
additionalInformation       string(1024)
) 
// The following DEFN definitions must be included in 
order to 
process
// union and setof field types
// Base Defn records
DEFN     emString ({
atext    string(1024)
})
DEFN     emInt ({
aint     int
})
DEFN     emDate ({
aDatetime datetime
})
DEFN emSetof (
ttype     int
)
// default Defn structures
DEFN emAttrValChgDef (
attributeID        string(1024)   REQ,
oldAttributeValue  string(1024)   REQ,
newAttributeValue  string(1024)   REQ
)
// Record definitions
RECORD objectCreationRecord (
soureceIndicator          string(40),
attributeIdentifierList   string(1024) // actually setof 
attributeId
)
RECORD objectDeletionRecord (
soureceIndicator          string(40),
attributeIdentifierList   string(1024) // actually setof 
attributeId
)
RECORD emAlarmRecord (
probableCause      string      REQ,
perceivedSeverity  string(20)  REQ,
specificProblems   string(1024),
backedUpStatus     bool,
backUpObject       string(1024),
trendIndication    string(20),
thresholdInfo      string(1024),
stateChangeDefinition     DREF(emAttrValChgDef),
monitoredAttributes       string(1024),
proposedRepairActions     string(1024),
ackState           string(10),
ackTime            datetime,
ackOperator        string(60),
ackText            string(1024),
clearState         string(10),
clearTime          datetime,
clearOperator      string(60),
clearText          string(1024),
displayState       string(12),
displayTime        datetime,
displayOperator    string(60),
displayText        string(1024)
)
RECORD attributeValueChangeRecord (
attributeValueChangeDefinition setof(emAttrValChgDef) 
REQ,
sourceIndicator             string(30),
// attributeIdentifierList  string
attributeIdentifierList     setof(emString)
)
RECORD relationshipChangeRecord (
recordChangeDefinition      string(1024) REQ,
sourceIndicator             string(30),
attributeIdentifierList     setof(emString)
)
RECORD emInternetAlarmRecord (
probableCause         string,
attributeIdentifierList     string(1024),
objectInstanceList    string(1024),
ackState              string(10),
ackTime               datetime,
ackOperator           string(60),
ackText               string(1024),
clearState            string(10),
clearTime             datetime,
clearOperator         string(60),
clearText             string(1024),
displayState          string(12),
displayTime           datetime,
displayOperator       string(60),
displayText           string(1024),
accessControlInfo     string(1024),
snmpVarBindList       string(1024),
transportDomain       string(1024),
transportAddress      string(1024)
)
RECORD nerveCenterAlarmRecord (
probableCause         string,
perceivedSeverity     string(20),
specificProblems      string(1024),
backedUpStatus        bool,
backUpObject          string(1024),
trendIndication       string(20),
thresholdInfo         string(1024),
stateChangeDefinition DREF(emAttrValChgDef),
monitoredAttributes   string(1024),
proposedRepairActions string(1024),
ackState              string(10),
ackTime               datetime,
ackOperator           string(60),
ackText               string(1024),
clearState            string(10),
clearTime             datetime,
clearOperator         string(60),
clearText             string(1024),
displayState          string(12),
displayTime           datetime,
displayOperator       string(60),
displayText           string(1024),
mosiSeverity          int,
mosiStateID           int
)

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 Database
Log 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 
TABLE NAME TABLE ID
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
em_this_rn attributeValueChangeDefinition Source Indicator attributeIdentifierList
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
Field Name Mandatory or Optional Field Type Field Length Comments
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
Field Name Mandatory or Optional Field Type Field Length Comments
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
Field Name Mandatory or Optional Field Type Field Length Comments
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  
Field Name Mandatory or Optional Field Type Field Length Comments
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
Field Name Mandatory or Optional Field Type Field Length Comments
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 
Field Name Mandatory or Optional Field Type Field Length Comments
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  
Field Name Mandatory or Optional Field Type Field Length Comments
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  
Field Name Mandatory or Optional Field Type Field Length Comments
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
Actions

Optional
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
create view emAlarmRecord as
select em_this_rn, probableCause, perceivedSeverity, ... 
from 
A.emAlarmRecord
union
select em_this_rn, probableCause, perceivedSeverity, ... 
from 
B.emAlarmRecord

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