Skip Headers
Oracle® Enterprise Manager Cloud Control Administrator's Guide
12c Release 4 (12.1.0.4)

E24473-31
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

22 Locating and Configuring Enterprise Manager Log Files

When you install the Oracle Management Agent (Management Agent) or the Oracle Management Service (OMS), Enterprise Manager automatically configures the system to save certain informational, warning, and error information to a set of log files.

Log files can help you troubleshoot potential problems with an Enterprise Manager installation. They provide detailed information about the actions performed by Enterprise Manager and whether or not any warnings or errors occurred.

This chapter not only helps you locate and review the contents of Enterprise Manager log files, but also includes instructions for configuring the log files to provide more detailed information to help in troubleshooting or to provide less detailed information to save disk space.

This chapter contains the following sections:

22.1 Managing Log Files

Many Enterprise Manager components generate log files containing messages that record errors, notifications, warnings, and traces.

Table 22-1 describes the columns in the Log Message table. For any given component, the optional column may not be populated in the message.

Table 22-1 Message Columns

Column Name Description

Time

The date and time when the message was generated. This reflects the local time zone.

Message Type

The type of message. Possible values are: Incident Error Warning, Notification, and Trace. In addition, the value Unknown may be used when the type is not known.

Message ID

The ID that uniquely identifies the message within the component. The ID consists of a prefix that represents the component, followed by a dash, then a 5-digit number. For example:

OHS-51009

Message

The text of the error message.

Target (Expanded)

Expanded target name.

Target

Target name

Target Type

Target type

Execution Context

The Execution Context ID (ECID), which is a global unique identifier of the execution of a particular request in which the originating component participates. You can use the ECID to correlate error messages from different components.

The Relationship ID, which distinguishes the work done in one thread on one process, from work done by any other threads on this and other processes, on behalf of the same request.

Component

The component that originated the message.

Module

The identifier of the module that originated the message.

Incident ID

The identifier of the incident to which this message corresponds.

Instance

The name of the Oracle instance to which the component that originated the message belongs.

Message Group

The name of the group to which this message belongs.

Message Level

The message level, represented by an integer value that qualifies the message type. Possible values are from 1 (highest severity) through 32 (lowest severity).

Hosting Client

The identifier for the client or security group to which this message relates.

Organization

The organization ID for the originating component. The ID is oracle for all Oracle components.

Host

The name of the host where the message originated.

Host IP Address

The network address of the host where the message originated.

User

The name of the user whose execution context generated the message.

Process ID

The ID for the process or execution unit that generated the message.

Thread ID

The ID of the thread that generated the message.

Upstream Component

The component that the originating component is working with on the client (upstream) side.

Downstream Component

The component that the originating component is working with on the server (downstream) side.

Detail Location

A URL linking to additional information regarding the message.

Supplemental Detail

Supplemental information about the event, including more detailed information than the message text.

Archive

Values are Yes or No. If the checkbox is checked, the message is collected from the archive location. Otherwise, the message is collected from the live system.

Target Log Files

Link to the log files page for this target.

Log File

Log file that this message contains.


Using Log Viewer, you can do the following:

22.1.1 Viewing Log Files and Their Messages

You can use Enterprise Manager Cloud Control to view messages across log files.

In particular, when you navigate in the context of a farm or domain, then the logs that you can view and search are filtered to just those associated with that farm or domain. When you navigate to Logs by way of the Enterprise menu, you can pick and choose exactly what targets you want to view and search logs against. You could also, for example pick multiple WebLogic Server targets that span across domains/farm.

For example, to view the log files and their messages:

  1. From the Enterprise menu, select Monitoring, select Logs, then select the target from the popup target selector.

    or

    The Logs menu is available at the individual target label and at the parent target level. For example, for WebLogic server and for other j2ee components, the logs menu can be accessed by choosing Logs from the Targets menu. The same is applicable for parent targets like domain and farm targets.

  2. In the context of a farm or domain, expand Selected Targets and in the row for a particular component or application, click the Target Log Files icon.

    When you are in the context of the Enterprise menu, add targets to the Target table and click the Target Log Files icon.

    The Log Files page is displayed. On this page, you can see a list of log files related to the target.

  3. Select a file and click View Log File.

    The View Log File page is displayed. On this page, you can view the list of messages and download the log file from this page.

  4. To view the details of a message, select the message.

    By default, the messages are sorted by time, in ascending order. You can sort the messages by the any of the columns, such as Message Type, by clicking the column name.

  5. When you are in context of one domain or one farm and looking at logs, the related messages are confined to that one domain or one farm. For example, to view messages that are related by time or ECID, click View Related Messages and select by Time or by ECID (Execution Context ID).

    The Related Messages page is displayed.

When trying to view log messages, you may see the following error:

Logging Configuration is missing or invalid for the targets (). Also, make sure that these targets are up and EM User has the CONFIGURE_TARGET privilege on the corresponding domains.

To ascertain which method to use to fix the problem, choose one of these three alternatives:

  • The domain's Administration Server is down. To resolve the problem, start the Administration Server and try viewing log messages again.

  • The Managed Server for which you are trying to view log messages is down. To resolve the problem, start the Managed Server and try viewing log messages again.

  • The Enterprise Manager Cloud Control administrator who is trying to access log messages does not have the necessary target privileges to do so. In order to view log messages, the administrator must have been granted the target privilege ”Configure target” for the corresponding WebLogic Domain target. Talk to your Oracle Enterprise Manager site administrator or super administrator regarding whether or not you have this privilege.

22.1.1.1 Restricting Access to the View Log Messages Menu Item and Functionality

You can restrict which administrators in Oracle Enterprise Manager Cloud Control have access to the View Log Messages menu item and its corresponding functionality. You can grant a target privilege labeled ”Ability to view Fusion Middleware Logs” to administrators and/or roles. This target privilege is applicable to all Oracle Fusion Applications related and Oracle Fusion Middleware related target types. This target privilege is automatically included as part of the following other target privileges: Operator Fusion Middleware, Operator, and Full. Consequently, you can grant an administrator one of the following privileges in order for him/her to be able to view log messages for Oracle Fusion Applications related and Oracle Fusion Middleware related log files:

  • Ability to view Fusion Middleware Logs target privilege

  • Operator Fusion Middleware target privilege

  • Operator target privilege

  • Full target privilege

To grant the ability to an administrator to view the Fusion Middleware Logs target privilege, follow these steps:

  1. Log in to the Oracle Enterprise Manager 12c Cloud Control console as a super administrator.

  2. From the Setup menu, choose Security, then Administrators.

  3. Select the appropriate administrator and click Edit.

  4. Click Next twice to arrive on the Target Privileges page of the wizard.

  5. Scroll down the page and click Add in the Target Privileges section of the page.

  6. From the Search and Add: Targets popup dialog, select the appropriate targets for which the administrator should have access to view logs. Click Select.

  7. From the Target Privileges section of the Target Privileges page of the wizard, select the targets to which you want to grant the ”Ability to view Fusion Middleware Logs” target privilege and select Grant to Selected. Notice that the default target privilege automatically given for this target is View.

  8. Select the Ability to view Fusion Middleware Logs target privilege and click Continue. Notice that the ”Ability to view Fusion Middleware Logs” target privilege is also included as part of other target privileges (for example, Operator target privilege). So, depending on the responsibilities of the administrator, you may want to grant the Operator target privilege to the administrator.

  9. Notice on the Target Privileges page of the wizard the appearance of the new privilege. Click Review and then Finish to conclude the operation.

22.1.2 Searching Log Files

You can search for diagnostic messages using the Log Messages page. By default, this page shows a summary of the logged issues for the last 10 minutes.

You can modify the search criteria to identify messages of relevance. You can view the search results in different modes, allowing ease of navigation through large amounts of data.

The following sections describe how to search log files:

22.1.2.1 Searching Log Files: Basic Searches

You can search for all of the messages for all of the entities in a domain, an Oracle WebLogic Server, a component, or an application.

For example, to search for messages for a domain:

  1. From the Enterprise menu, select Monitoring, select Logs, then select the target from the popup target selector.

    or

    From the Targets menu, select Middleware, click a farm. From the Farm menu, select Logs, then select View Log Messages.

    The Log Messages page displays a Search section and a table that shows a summary of the messages for the last hour.

  2. In the Search Mode secstion, you can choose to search for only Live Logs, only Archive Logs, or Both.

  3. In the Date Range section, you can select either:

    • Most Recent: If you select this option, select a time, such as 3 hours. The default is 10 minutes.

    • Time Interval: If you select this option, select the calendar icon for Start Date. Select a date and time. Then, select the calendar icon for End Date. Select a date and time.

  4. In the Message Types section, select one or more of the message types.

  5. You can specify more search criteria, for example, by providing text in the Message text field, so you can search on explicit words or patterns across log files.You can specify more search criteria, as described in Searching Log Files: Advanced Searches.

  6. Click Search.

  7. To help identify messages of relevance, in the table, for Show, select one of the following modes:

    • Messages - You can select an operator, such as contains and then enter a value to be matched.

      To see the details of a particular message, click the message. The details are displayed below the table of messages.

      To view related messages, select a message, then click View Related Messages and select by Time or by ECID (Execution Context ID).

    • Application ID - Groups messages related to a particular application.

    • ECID + Relationship ID - Groups messages by Execution Context (ECID) and Relationship ID (RID) which enables you to use log file entries to correlate messages from one application or across application server components. By searching related messages using the message correlation information, you can examine multiple messages and identify the component that first generated the problem.

    • Host - Groups messages associated with a particular host.

    • Host IP Address - Groups messages associated with a particular host IP address.

    • Incident ID

    • Message Type - Groups messages for each target based on the message type. It displays the total number of messages available for each message type, for example, ERROR, INCIDENT ERROR, WARNING, NOTIFICATION, TRACE, and UNKNOWN for every target.

    • Message ID - Groups messages based on the combination of Message ID, Message Type, Target, Message Level, Component, Module, and Organization.

    • Module - Groups the classes / modules that originated the message.

    • Target

    • Thread ID - Groups messages by Thread ID

    • User - Groups all messages for a particular user. For example, all the messages for user Jones will be listed before the messages for user Smith.

22.1.2.2 Searching Log Files: Advanced Searches

You can refine your search criteria using the following controls in the Log Messages page:

  • Message: You can select an operator, such as contains and then enter a value to be matched.

  • Add Fields: Click this to specify additional criteria, such as Host, which lets you narrow the search to particular hosts. Then click Add.

    For each field you add, select an operator, such as contains and then enter a value to be matched.

  • Selected Targets: Expand this to see the targets that are participating in the search. To add targets, click Add and provide information in the dialog box. To remove targets, select the target and click Remove.

  • Search Archived Logs: Enable this check box to access the log viewer. These are the archive log file locations for multiple targets you configured on the Configure Archive Locations page.

    Note:

    The Search Archived Logs check box is not applicable to standalone Oracle HTTP Servers.

22.1.3 Downloading Log Files

You can download the log messages to a file. You can download either the matching messages from a search or the messages in a particular log file.

To download the matching messages from a search to a file:

  1. From the Enterprise menu, select Monitoring, then select Logs.

    or

    From the Targets menu, select Middleware, then select a domain. From the Farm menu, select Logs, then select View Log Messages.

    The Log Messages page is displayed.

  2. Search for particular types of messages as described in Searching Log Files: Basic Searches.

  3. Select a file type by clicking Export Messages to File and select one of the following:

    • As Oracle Diagnostic Log Text (.txt)

    • As Oracle Diagnostic Log XML (.xml)

    • As Comma-Separated List (.csv)

    An Opening dialog box is displayed.

  4. Select either Open With or Save to Disk. Click OK.

To export specific types of messages or messages with a particular Message ID to a file:

  1. From the Enterprise menu, select Monitoring, then select Logs.

    or

    From the Targets menu, select Middleware, then select a domain. From the Farm menu, select Logs, then select View Log Messages.

    The Log Messages page is displayed.

  2. Search for particular types of messages as described in Searching Log Files: Basic Searches.

  3. For Show, select Group by Message Type or Group by Message ID.

  4. To download the messages into a file, if you selected Group by Message Type, select the link in one of the columns that lists the number of messages, such as the Errors column. If you selected Group by Message ID, select one of the links in the Occurrences column.

    The Messages by Message Type page or Message by Message ID is displayed.

  5. Select a file type by clicking the arrow near Export Messages to File.

    You can select one of the following:

    • As Oracle Diagnostic Log Text (.txt)

    • As Oracle Diagnostic Log XML (.xml)

    • As Comma-Separated List (.csv)

    An Opening dialog box is displayed.

  6. Select either Open With or Save to Disk. Click OK.

To download the log files for a specific component:

  1. From the Enterprise menu, select Monitoring, then select Logs.

    or

    From the Targets menu, select Middleware, click a domain. From the Farm menu, select Logs, then select View Log Messages.

    The Log Messages page is displayed.

  2. Expand the Selected Targets section because it is hidden by default. Click Target Log Files.

    The Log Files page is displayed.

    Select one of the possibly many Target Log Files icons. Select the icon that is associated with the target type log files you want to view.

  3. Select a log file and click Download.

  4. An Opening dialog box is displayed.

  5. Select either Open With or Save to Disk. Click OK.

22.2 Managing Saved Searches

The following sections provide information on creating, retrieving, and managing saved searches:

22.2.1 Saving Searches

Saved searches save administrators time by not having to redefine the same search again in the future. Saved searches help you in diagnosing problems faster because you are only a few clicks away from accessing a saved search as opposed to redefining the search again and again.

Note: Saved searches are per administrator. Therefore when the administrator logs out of the console, the search is stored and is available the next time the administrator logs in. In other words, saved searches that one administrator defines are not accessible by another administrator.

Once you have specified search criteria as described in Searching Log Files, you save it by clicking Save Search located at the top-right of the page. The name of the search is automatically created by concatenating fields used in the search, for example, Log Messages - Saved Search: "error", Last 1 hours, Incident Error,Error,Unknown.

Note: You can change the default name using the Manage Saved Search popup. This allows you to accept the default name and change it later.

22.2.2 Retrieving Saved Searches

To retrieve a saved search. follow these steps:

  1. From the Enterprise menu, select Monitoring, select Logs., then select the target from the popup target selector.

    or

    From the Targets menu, select Middleware, click a farm. From the Farm menu, select Logs, then select View Log Messages.

    or

    Access the saved search from the Favorites menu.

    The Log Messages page appears.

  2. On the Logs page, click Saved Searches located at the top-right of the page.

  3. Choose a search.

    The search results populate the Search region.

22.2.3 Managing Saved Searches

To manage a saved search, follow these steps:

  1. From the Enterprise menu, select Monitoring, select Logs, then select the target from the popup target selector.

    or

    From the Targets menu, select Middleware, click a farm. From the Farm menu, select Logs, then select View Log Messages. You can manage the saved searches pertaining to the target context only.

    or

    Access the saved search from the Favorites menu and select Manage Favorites. You can manage all the log-saved searches which you have created irrespective of the context. You can see all the saved searches.

    The Log Messages page appears.

  2. On the Logs page, click Saved Searches located at the top-right of the page.

  3. On the list, click Manage Saved Searches.

    The Manage Favorites pop-up appears. You can:

    • Change the name of the search.

      When you select a row from the table, the name of search appears in the Name field at the bottom of the screen. You can edit the name of the search and click OK or you can click Cancel.

      Note: When you click OK, you will only be changing the name of the search, not the saved search criteria. Once the search criteria is changed, the Save Searches button is enabled.

    • Edit the search criteria.

      Click the link of the saved search. The Log Viewer screen appears in the context of the saved search. Make the changes and click Save.

    • Delete a search

      Choose a search and click Remove Selected.

22.3 Locating Management Agent Log and Trace Files

The following sections provide information on the log and trace files for the Oracle Management Agent:

22.3.1 About the Management Agent Log and Trace Files

Oracle Management Agent log and trace files store important information that support personnel can later use to troubleshoot problems. The agent main log is located in $EMSTATE/sysman/log. The log is segmented by default to 11 segments, 5MB each. The segments are named gcagent.log and gcagent.log.# where # is a number in the range of 1-10. These settings are controlled by properties in emd.properties as explained in the following sections. The latest segment is always gcagent.log and the oldest is the gcagent.log.X where X is the highest number.

The Management Agent uses the following log files:

  • Oracle Management Agent metadata log file (gcagent.log)

    This log file contains trace, debug, information, error, or warning messages from the agent.

  • Oracle Management Agent fetchlet trace file (gcagent_sdk.trc)

    This log file contains logging information about fetchlets and receivelets.

  • Oracle Management Agent errors log file (gcagent_errors.log)

    This error log file contains information about errors. The errors in this file are duplicate of the errors in gcagent.log.

  • Oracle Management Agent metadata log file (gcagent_mdu.log)

    This log tracks the metadata updates to the agent.

  • Enterprise Manager Control log file (emctl.log)

    The information is saved to emctl.log file, when you run the Enterprise Manager Control commands. For more information about emctl.log file, see chapter Starting and Stopping Enterprise Manager Components.

Note:

All the agent logs mentioned above (existing in $EMSTATE/sysman/log) are transient. Agent logs are segmented and have a limited overall size and hence need not be deleted or managed.

22.3.1.1 Structure of Agent Log Files

The log contain individual log messages with the following format:

YYYY-MM-DD HH:MM:SS,### [<tid>:<thread code or code:name>] <level> -<the message>

Where:

  • YYYY-MM-DD HH:MM:SS,### is a timestamp (in 24 hours format and ### is the fraction in msec).

  • <tid> is the thread id (as a decimal number)

  • <thread name or code> is the thread full name or an abbreviated hexadecimal code (see the following example).

  • <level> is the logging level that can be one of (in ascending order of importance): DEBUG, INFO, WARN, ERROR, FATAL.

  • <the message> is the free text message that is being logged. The message can contain new lines and spawn multiple lines.

For example:

2011-06-07 15:00:00,016 [1:3305B9:main] DEBUG - ADR_BASE='/ade/example_user/oracle/example/agentStateDir' 
2011-06-07 15:00:01,883 [1:3305B9] INFO - Agent is starting up

22.3.2 Locating the Management Agent Log and Trace Files

The log and trace files for the Management Agent are written in the agent runtime directory. You can find the runtime directory by using this command:

$ emctl getemhome

The log and trace files will be located at <EMHOME>/sysman/log.

22.3.3 Setting Oracle Management Agent Log Levels

Every log message is logged using a specific log level. The log levels are ordered in priority order: DEBUG, INFO, WARN, ERROR, and FATAL. The log setting determines the minimum level that will be included in the log. For example, if the log level is set to INFO (the default), only log messages of level INFO and above (INFO, WARN, ERROR and FATAL) are going to be included in the log.

The logging configuration syntax uses the concept of handlers (appendares in log4j terms) and loggers. A handler defines a single output file and how the file is to be managed (maximum file size, number of segments, and so on). Note that there is a default logging prefix oracle.sysman that is used for all handlers that does not specify any logging prefix. The logging properties uses the Logger. prefix for agent (log4j) logging configuration and ODLLogger. prefix for the ODL (which is based on java.util.logger.*) logging configuration. Beside the prefix, both systems share the same syntax. The configuration full syntax (without a Logger or ODLLogger prefix) is the following:

Table 22-2

Property Name Description Mandatory Default Value

directory=<directory>

Defines the logging system (log4j or ODL) logging directory. Specifing a directoryfor one system does not affect the other system (setting Logger. directory will only affect the Logger. configuration but not ODLLogger.)

No

$EMSTATE/sysman/log

<handler>.filename=<filename>

The filename to use for the handler. If the filename is relative it will be relative to the logging directory (see direrctory property above). An absolute file name will be used as is.

Yes

 

<handler>.level=<level>

The default logging level for the handler. Possbile levels are:

DEBUG, INFO, WARN, ERROR, FATAL

Yes

 

<handler>.totalSize=<size>

The total size in MB for all the handler file segments.

No

No limit

<handler>.segment.count=<count>

The number of segments to use for the handler.

No

1

<handler>.logger=<logger names>

A comma delimited list of logger names that will use this handler.

No

When not specified, the default logger is used.

level.<logger name>=<level>

Set a specific logging level to the logger and all its descendants. Possbile levels are:

DEBUG, INFO, WARN, ERROR, FATAL

No

 

additivity.<logger name>=<true or false>

If set to false, only handlers that are configured for the specific logger name will be used. Otherwise, handlers that are configured for the logger parent name will also be used.

No

true


An example of the syntax is as follows:

# logging properties
Logger.log.filename=gcagent.log
Logger.log.level=INFO
Logger.log.totalSize=100
Logger.log.segment.count=20 

ODLLogger.wsm.level=ERROR
ODLLogger.wsm.totalSize=5
ODLLogger.wsm.segment.count=5
ODLLogger.wsm.filename=gcagent_wsm.log

The above log configuration sets up a handler (log) that creates a gcagent.log file (in the default logging directory) with a default logging level of INFO, total size of 100MB, uses up to 20 segments, and is configured to be used by the default logger (oracle.sysman).

22.3.3.1 Modifying the Default Logging Level

To enable DEBUG level logging for the Management Agent, set the log handler level to DEBUG (see below). And then reload the agent.

Logger.log.level=DEBUG 

Alternatively, use emctl setproperty agent command as follows:

$ emctl setproperty agent -name 'Logger.log.level' -value 'DEBUG' 

22.3.3.2 Setting gcagent.log

The gcagent.log is the agent main log that contain log entries from all the agent core code. The following is gcagent.log configuration:

Logger.log.filename=gcagent.log
Logger.log.level=DEBUG
Logger.log.totalSize=100
Logger.log.segment.count=20

22.3.3.3 Setting gcagent_error.log

The gcagent_errors.log is a subset of the gcagent.log and contains log messages of ERROR and FATAL levels. The logging configuration for gcagent_errors.log is specified in emd.properties. Following are the settings for gcagent_errors.log:

Logger.err.filename=gcagent_errors.log
Logger.err.level=ERROR
Logger.err.totalSize=100
Logger.err.segment.count=5

22.3.3.4 Setting the Log Level for Individual Classes and Packages

The logging level for individual class and/or packages can also be set. The following are examples that are currently configured by default:

# Set the class loaders to level INFO
Logger.level.oracle.sysman.gcagent.metadata.impl.ChainedClassLoader=INFO 
Logger.level.oracle.sysman.gcagent.metadata.impl.ReverseDelegationClassLoader=INFO 
Logger.level.oracle.sysman.gcagent.metadata.impl.PluginLibraryClassLoader=INFO 
Logger.level.oracle.sysman.gcagent.metadata.impl.PluginClassLoader=INFO 

The above configuration changed the default level of logging for the four classes to be INFO. When the default level of logging is INFO it does not make any difference but if the default log level is set to DEBUG (when debugging the code) it will prevent those four classes from logging at DEBUG level (as they are normally too verbose).

The reverse is also true, for example if the following configuration is added (not set by default):

Logger.level.oracle.sysman.gcagent.metadata.impl.collection=DEBUG 

It will cause all classes in the oracle.sysman.gcagent.metadata.impl.collection package to log at DEBUG level even if the default log level is INFO.

22.3.3.5 Setting gcagent_mdu.log

A set of entries are created in the gcagent_mdu.log file for each client command that modifies target instances, target instance collections, or blackouts. Entries are as follows:

2011-08-18 22:56:40,467 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SAVE TARGET(S)
<Target IDENTIFIER="TARGET_GUID=6A3A159D0BB320C50B7926E0671A1A98" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="EM Management Beacon" NAME="EM Management Beacon" TYPE="oracle_beacon"/>
<Target IDENTIFIER="TARGET_GUID=51F9BBC6F5B833058F4278B51E496000" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="mytestBeacon" NAME="mytestBeacon" TYPE="oracle_beacon"><Property VALUE="***" NAME="proxyHost"/><Property VALUE="***" NAME="proxyPort"/><Property VALUE="***" NAME="dontProxyFor"/></Target>
<Target IDENTIFIER="TARGET_GUID=7C4336B536C9F241DBCAC4D1D082AD22" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="CSAcollector" NAME="CSAcollector" TYPE="oracle_csa_collector"><Property VALUE="***" NAME="recvFileDir"/></Target>
<Target IDENTIFIER="TARGET_GUID=207B57A3FE300C86F81FE7D409F5DD1C" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="Oemrep_Database" NAME="Oemrep_Database" TYPE="oracle_database"><Property VALUE="***" NAME="MachineName"/><Property VALUE="***" NAME="Port"/><Property VALUE="***" NAME="SID"/><Property VALUE="***" NAME="OracleHome"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="UserName"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="Role"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="password"/></Target>
<Target IDENTIFIER="TARGET_GUID=0C48C5AE0FAFB42ED91F897FF398FC84" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="Management Services and Repository" NAME="Management Services and Repository" TYPE="oracle_emrep"><Property VALUE="***" NAME="ConnectDescriptor"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="UserName"/><Property ENCRYPTED="FALSE" VALUE="***" NAME="password"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><Member ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/><Member ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=DF64B4A7C0F2EEBA7894EA3AD4CAF61E" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="adc2190447.us.oracle.com:41034_Management_Service" NAME="adc2190447.us.oracle.com:41034_Management_Service" TYPE="oracle_oms"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_console" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_console" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="internal_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><Member ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=4D290260F13596502EFD8F3E22752404" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" NAME="adc2190447.us.oracle.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><MemberOf ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
<Target IDENTIFIER="TARGET_GUID=D0A23AE06A9E678221B075A216364541" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" NAME="adc2190447.us.oracle.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"><Property VALUE="***" NAME="InstanceHome"/><Property VALUE="***" NAME="OracleHome"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><MemberOf ASSOCIATION="" NAME="adc2190447.us.oracle.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target>
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS
2011-08-18 22:57:10,084 [HTTP Listener-34 - /emd/main/ (DispatchRequests)] - SUCCESS

For the batch of saved targets in the above example, the original request came in at 22:56:40 and the list of targets saved are found in the line(s) following the SAVE TARGET(S) message. In this case, there were 8 targets. The result of saving the targets is available in the next 8 lines (for the same thread) and in this case all were saved successfully by 22:57:10.

The pattern is the same for saved collection items (or collections) and blackouts.

The logging configuration for the gcagent_mdu log is specified in emd.properties but you must not modify this log. For example, these entries are logged at INFO level, which means that if you decided to save space and change this to WARN only by editing the mdu log entries in the emd.properties file, you will have effectively disabled this log.

Following are the settings for gcagent_mdu log:

Logger.mdu.filename=gcagent_mdu.log
Logger.mdu.level=INFO
Logger.mdu.totalSize=100
Logger.mdu.segment.count=5
Logger.mdu.logger=Mdu

Note:

Change the filename and logger settings only if asked by Support.

22.3.3.6 Setting the TRACE Level

The following _enableTrace property when set to "true" will enable the TRACE logging level that shows as DEBUG messages.

Logger._enableTrace=true

The default log level for the agent log must be set to DEBUG for the tracing level to work.

22.4 Locating and Configuring Oracle Management Service Log and Trace Files

The following sections describe how to locate and configure the OMS log files:

22.4.1 About the Oracle Management Service Log and Trace Files

OMS log and trace files store important information that Oracle Support can later use to troubleshoot problems. OMS uses the following six types of log files:

  • Oracle Management Service log file (emoms.log)

    The Management Service saves information to the log file when it performs an action (such a starting or stopping) or when it generates an error. This is a log file for console application.

  • Oracle Management Service trace file (emoms.trc)

    OMS trace file provides an advanced method of troubleshooting that can provide support personnel with even more information about what actions the OMS was performing when a particular problem occurred. This is a trace file for Console application.

  • Oracle Management Service log file (emoms_pbs.log)

    The Management Service saves information to this log file for background modules such as the loader, job system, event system, notification system, and so on. This file contains messages logged at ERROR or WARN levels.

  • Oracle Management Service trace file (emoms_pbs.trc)

    This trace file provides additional logging for the background modules such as the loader, job system, event system, notification system, and so on when DEBUG or INFO level logging is enabled for these modules. This file can provide Support personnel with even more information about actions these modules were performing when a particular problem occurred.

  • Enterprise Manager Control log file (emctl.log)

    The information is saved to emctl.log file, when you run the Enterprise Manager Control commands. For more information about emctl.log file, see chapter Starting and Stopping Enterprise Manager Components.

  • Enterprise Manager Control message file (emctl.msg)

    This file is created by the HealthMonitor thread of the OMS when it restarts the OMS because of a critical error. This file is used for troubleshooting the OMS restart problem. It provides information such as the exact time when the OMS is restarted and which module has caused the crash.

22.4.2 Locating Oracle Management Service Log and Trace Files

The OMS Instance Base directory is gc_inst in the Oracle Middleware Home (middleware home). This directory stores all log and trace files related to OMS 12c.

You can choose to change this, if you want, in the installer.

For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the instance base location is /u01/app/Oracle/gc_inst. You can choose to change this, if you want, in the installer. However, you can change it for only advanced installation and not for simple installation.

22.4.3 Controlling the Size and Number of Oracle Management Service Log and Trace Files

OMS log and trace files increases in size over time as information is written to the files. However, the files are designed to reach a maximum size. When the files reach the predefined maximum size, the OMS renames (or rolls) the logging information to a new file name and starts a new log or trace file. This process keeps the log and trace files from growing too large.

As a result, you will often see multiple log and trace files in the OMS log directory. The following example shows one archived log file and the current log file in the /u01/app/Oracle/gc_inst/em/EMGC_OMS1/sysman/log/ directory:

emoms.log
emoms.log.1

To control the maximum size of the OMS log and OMS trace files, as well as the number of rollover files, run the following command, and specify details as described in Table 22-3:

emctl set property -name <property> -value <property value> -module logging

The above command will set the property for all OMSes. If you want to set it for a single OMS, then specify an extra option -oms_name as follows:

emctl set property -name <name> -value  <value> -module logging -oms_name example.us.oracle.com:portnumber_Management_Service

To set it for the current OMS, use the property -oms_name local_oms. To set it for any other OMS, you can provide the name of that OMS. The OMS name has to be similar to example.us.oracle.com:portnumber_Management_Service.

Note:

In Oracle Enterprise Manager Cloud Control 12c, you do not have to restart OMS for the changes to take effect.

Note:

In Oracle Enterprise Manager Cloud Control 12c, emctl set property by default sets the logging properties for all the OMS. To set the property for only one OMS, use the -oms_name option.

Table 22-3 Oracle Management Service Log File Properties in the emomslogging.properties File

Property Purpose Example

log4j.appender.emlogAppender. MaxFileSize

When OMS log file reaches this size, then OMS copies the logging data to a new rollover file and creates a new emoms.log log file. The size of the log is specified in units of bytes. This property is also applicable for emoms_pbs.log.

log4j.appender.emlogAppender. MaxFileSize=20000000

log4j.appender.emlogAppender. MaxBackupIndex

This optional property indicates how many times OMS will rollover the log file to a new file name before deleting logging data. This property is also applicable for emoms_pbs.log.

Note: Because the log file does not contain as much data as the trace file, it is usually not necessary to create more than one rollover file.

log4j.appender.emlogAppender. MaxBackupIndex=1

log4j.appender.emtrcAppender. MaxFileSize

When the OMS trace file reaches this size, then OMS copies the logging data to a new rollover file and creates a new emoms.trc log file. This property is also applicable for emoms_pbs.trc.

log4j.appender.emtrcAppender. MaxFileSize=5000000

log4j.appender.emtrcAppender. MaxBackupIndex

This property indicates how many times the OMS will rollover the trace file to a new file name before deleting tracing data. This property is also applicable for emoms_pbs.trc.

log4j.appender.emtrcAppender. MaxBackupIndex=10


22.4.4 Controlling the Contents of the Oracle Management Service Trace File

By default, the OMS will save all critical and warning messages to the emoms.trc file. However, you can adjust the amount of logging information that the OMS generates.

To change the amount of logging information generated by the OMS, run the following command:

emctl set property -name "log4j.rootCategory" -value "<LEVEL>, emlogAppender, emtrcAppender" -module logging

The above command will change the log level for all OMS, unless -oms_name option is specified.

Note:

If you change the root logging level for the emoms.trc file, then a lot of messages are written to the trace file filling up the space quickly, and potentially slowing down the system. Run the following command to enable debug selectively for specific modules that need to be assessed:
emctl set property -name <logging module> -value DEBUG -module logging

Where, <logging module> represents the logging module from a specific subsystem.

For example, oracle.sysman.emdrep.dbjava.loader.

The logging level can be changed for specific modules by running the following command:

emctl set property -name "<CATEGORY>" -value "<LEVEL>" -module logging

where LEVEL can be DEBUG, INFO, WARN, or ERROR, and CATEGORY is specific to the module for which level has to be changed. To change the logging module, contact Oracle Support.

Note:

The location of emoms.trc, emoms.log, emoms_pbs.trc, and emoms_pbs.log files can be changed to a different location from the default location. However, it is not advisable to do so.

22.4.5 Controlling the Oracle WebLogic Server and Oracle HTTP Server Log Files

Oracle Management Service is a Java EE application deployed on an Oracle WebLogic Server. Different components of the Oracle WebLogic Server generate their own log files. These files contain important information that can be used later by support personnel to troubleshoot problems.

Table 22-4 lists the location of the log files for some components.

Table 22-4 Component Log File Location

Component Location

Oracle HTTP Server (OHS)

<EM_INSTANCE_BASE>/<webtier_instance_name>/diagnostics/logs/OHS/<ohs_name>

For example,

/u01/app/Oracle/gc_inst/WebTierIH1/diagnostics/logs/OHS/ohs1

OPMN

<EM_INSTANCE_BASE>/<webtier_instance_name>/diagnostics/logs/OPMN/<opmn_name>

For example,

/u01/app/Oracle/gc_inst/WebTierIH1/diagnostics/logs/OPMN/opmn

Oracle WebLogic

The log data from WebLogic will be at:

<EM_INSTANCE_BASE>/user_projects/domains/<domain_name>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.log

This log can be restricted, rotated by size, time, and other conditions from the WebLogic Console. The default settings are:

  • In production mode, they are rotated at a default of 5MB.

  • The log level is WARNING.

  • The number files are restricted to 10.

For example,

/u01/app/Oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.log

The messages written to sysout and syserr will be available in the .out files. They cannot be rotated by size or time. They are rotated only when the server starts. They are located at:

<EM_INSTANCE_BASE>/user_projects/domains/<domain_name>/servers/<SERVER_NAME>/logs/<SERVER_NAME>.out

For example,

/u01/app/Oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out

The node manager logs are at <INST_HOME>/NodeManager/emnodemanager and the admin server logs are at <INST_HOME>/user_projects/domains/GCDomain/servers/EMGC_ADMINSERVER/logs.


By default, the Enterprise Manager Cloud Control configures Oracle HTTP Server logs to roll over periodically to a new file, so that each file does not grow too large in size. You must also ensure that you delete the old rollover files periodically to free up the disk space. You can use an operating system scheduler, like cron on UNIX, to periodically delete the rollover files.

Note:

Following are log files that you will need to maintain and manually purge:
  • <gc_inst>/user_projects/domains/<domain_name>/servers/EMGC_ADMINSERVER/logs/<domain_name>.log*

  • All files under <gc_inst>/WebTierIH1/diagnostics/logs/OHS/ohs1/. For example:

    em_upload_http_access_log.*
    access_log.*
    em_upload_https_access_log.*
    ohs1-*.log
    console~OHS~1.log*
    mod_wl_ohs.log*
    
  • Log files under the admin server and emgc_oms server:

    <gc_inst>\users_projects\domains\<domain_name>\servers\EMGC_ADMINSERVER\logs\*.out*
    <gc_inst>\users_projects\domains\<domain_name>\servers\EMGC_OMS?\logs\*.out*
    

For instructions on controlling the size and rotation of these log files, refer to chapter "Managing Log Files and Diagnostic Data" in Oracle Fusion Middleware Administrator's Guide.

For information about configuring Enterprise Manager to view Fusion Applications PL/SQL and C diagnostic log files, see chapter "Managing Oracle Fusion Applications Log Files and Diagnostic Tests" in Oracle Fusion Applications Administrator's Guide.

22.5 Monitoring Log Files

You can use Log File Monitoring to monitor WebLogic Server and Application Deployment log files for specific patterns. You can set up Cloud Control to receive alert notifications in the context of targets when patterns are found. This allows you to be more proactive and learn of problems as an administrator before end users discover them.

Use the following topics to learn how to set up and use Log File Monitoring:

22.5.1 About Log Viewer

Log Viewer enables administrators to view, search, and download middleware-related log files regardless of where the files reside on disk. Complex search criteria can be specified and saved for future reference in order to help administrators quickly diagnose performance problems across multiple middleware components spanning multiple Fusion Middleware Farms and WebLogic Domains.

Note:

If you want to use all features of the log viewer in Cloud Control, and the target domain for which you want to view log messages is SSL-enabled with a custom certificate, then log viewer features will not function properly. For most features of log viewer, the OMS makes a JMX connection to the Admin Server of that domain. The only log viewer feature that does not have the OMS make a direct JMX connection to the Admin Server is the feature used for archived log files. Instead, the agent is used for viewing archived log files.

For log viewer features to fully function in this environment, you must apply additional configuration changes.You must take the rootca of the custom certificate from the Admin Server target for the domain against which you want to view log messages and import it into the trust store of the OMS.

When accessing Log Viewer, default search criteria is specified for the selected target type. The administrator can then refine the search criteria based on diagnostic requirements for the particular Fusion Middleware Farm. By using the Add Fields button, you can refine the search criteria to include:

  • Selecting one or more member targets of the Fusion Middleware Farm

  • Specifying the date range

  • Selecting the message types

  • Specifying the messages to be searched

  • Specifying the ECIDs to be searched

  • Specifying the application name

  • Specifying the user name

Once the search criteria has been defined, the administrator clicks on the search button.

The administrator modifies the search as needed and clicks the Save Search button on the Log Viewer.

The search criteria specified, including the targets against which the search was performed, is then saved to the Management Repository for the currently logged in administrator.

You can click on the Saved Searches button to retrieve and apply a previously stored Search Criteria.

You can click on the Manage Saved Searches and bring up a pop-up to edit or delete the previously Saved Search Criteria.

22.5.2 Overview of WebLogic Server and Application Deployment Log File Monitoring

You can use Log File Monitoring to monitor WebLogic Server and Application Deployment log files for specific patterns and thereby reduce troubleshooting time. You can set up Cloud Control to receive alert notifications in context of targets when patterns are found.

The Log File Monitoring metric, Log File Pattern Matched Line Count for WebLogic Server and Application Deployment target types allows you to monitor one or more log files for the occurrence of one or more perl patterns. In addition, you can specify a perl pattern to be ignored for the log file. Periodic scanning, which occurs by default every 60 minutes, is performed against any new content added since the last scan. Lines matching the ignore pattern are ignored first, then lines matching specified match patterns result in one record being uploaded to the repository for each pattern. You can set a threshold against the number of lines matching the given pattern. File rotation will be handled within the given file.

You can also use the monitoring templates functionality, which allows an administrator to configure a metric once in a template and then apply the template to several WebLogic Server or Application Deployment targets at once, rather than having to configure each WebLogic Server log file monitoring metric individually.

If you are currently using log file monitoring via the Host target type, you should configure log file monitoring via the Fusion Middleware related target type instead so you can see alerts in context of a Fusion Middleware target.

Prerequisites to Use Log File Monitoring

Log File Monitoring requires a local Management Agent monitoring target. In other words, the host on which the log files you want to monitor reside must have an agent installed and running. The OS user who installed the agent must have read access to directories where the monitored log files reside. Log file monitoring is disabled by default. You must enable it in order to use this feature.

22.5.3 Enabling Log File Monitoring

Log File Monitoring is disabled by default. To enable Log File Monitoring, follow these steps:

  1. From the target menu, select Monitoring.

  2. Choose Metric and Collection Settings.

  3. Under the Log File Monitoring row, click the Disabled link to change the setting to Enabled.

  4. On the Edit Collection Settings: Log File Monitoring page, click Enable in the Collection Schedule section.

  5. Click Continue.

Once you enable and configure Log File Monitoring, the default collection schedule is set for every 60 minutes.

22.5.4 Configuring Log File Monitoring

To configure Log File Monitoring, follow these steps:

  1. From the target menu, choose Monitoring.

  2. From the Monitoring menu, select Metric and Collection Settings, then choose the Log File Pattern Matched Line Count metric.

  3. Click the Edit icon on the right.

    Cloud Control displays the Edit Advanced Settings:Log File Pattern Matched Line Count page.

  4. Click Add to add new object(s) in order to specify settings for the log files to be monitored.

Add objects to the Monitored Objects table. The table lists all Log File Name/Match Pattern in Perl/Ignore Pattern in Perl objects monitored for this metric. You can specify different threshold settings for each Log File Name/Match Pattern in Perl/Ignore Pattern in Perl objects. The Reorder button specifies which log file to scan first.

In past releases, if % was provided, the text was not ignored and all lines read from the file were included for pattern matching. However, this behavior has been updated wherein only "" (an empty string) is the prescribed method not to ignore any lines. However for backward compatibility "%" will still be considered as the equivalent to the "" string.

Good examples:

/u01/middleware/user_projects/domains/riddles_domain/servers/ManagedServer_1/logs/access.log

C:\\u01\middleware\user_projects\domains\riddles_domain\severs\ManagedServer_1\logs\access.log

Bad example:

/u01/middleware/user_projects/domains/riddles_domain/servers/ManagedServer_1/logs/%.log

The Match Pattern in Perl value specifies the pattern that should be monitored in the log file. Perl expressions are supported in this field, and case is ignored.

Examples:

  • FATAL - This pattern will be true for any lines containing fatal

  • *fatal.*critical.* - This pattern will be true for any lines containing fatal and critical

The Ignore Pattern in Perl value specifies the pattern that should be ignored in the log file. If the Ignore Pattern in Perl field has a default value of % in the field, you should remove the default value if nothing should be ignored. Perl expressions are supported in this field, and case is ignored.

The Warning Threshold and Critical Threshold values should be set to a number such that if the pattern occurs in the log file the specified number of times within the collection schedule, then an alert will be triggered. If the number of occurrences is specified in the advanced settings, then this factors into when alert is raised.

For example, if you set the critical threshold to 1 (if pattern found more than 1 time in log file, it is critical alert) and the number of occurrences to 2, then a critical alert is raised only when the pattern is found more than once in the log file within 2 consecutive collections.

Once log file monitoring is enabled and configured, you can include the &rsquor;Log File Pattern Matched Line Count' metric as part of a Monitoring Template. Log file locations must be the same across targets to which the template is applied. You can apply the template to multiple WebLogic servers or Application Deployment targets at once rather than setting monitoring settings individually on a per-target basis.

If after configuring the Log File Monitoring metric the log file contains the specified patterns but the alerts are not generated in the OMS, you should do the following:

  • Check whether the log file name contains a perl pattern.

  • Check whether the ignore pattern contains an asterisk (*). Providing an asterisk in the ignore pattern field will also ignore all the lines which include the matched patterns.

Configuration Issues

If an error message displays indicating that logging configuration is missing or invalid for certain targets, you can try the following options.

First, the WebLogic Domain that you are accessing may not be Oracle JRF (Java Required Files) enabled. Oracle JRF consists of components not included in the Oracle WebLogic Server installation and that provide common functionality for Oracle business applications and application frameworks. To view log messages, the target must be Oracle JRF enabled. To check to see if your WebLogic Domain, for example, is Oracle JRF enabled, perform the following steps:

  1. From the WebLogic Domain menu, select Target Setup submenu and then Monitoring Configuration.

  2. On the Monitoring Configuration page for the domain, look for the property labeled ”Can Apply JRF”. The value for this property could be true or false. If the value is false, then the domain is not Oracle JRF enabled.

If the value of the ”Can Apply JRF” property is true for the domain, this does not necessarily mean that all managed servers within the domain are Oracle JRF enabled. If you are unable to access log messages in the context of a specific managed server, then navigate to the relevant managed server's Monitoring Configuration page. From the Monitoring Configuration page, look for the property ”Is JRF Enabled”. The value for this property could be true or false. If the value is false, then the managed server is not Oracle JRF enabled.

Second, the Enterprise Manager Cloud Control administrator who is trying to access log messages does not have the necessary target privileges to do so. In order to view log messages, the administrator must have been granted the target privilege ”Ability to view Fusion Middleware Logs” for the corresponding target. Talk to your Oracle Enterprise Manager's site administrator or super administrator regarding whether you have this privilege or not. Refer to later questions in this document for additional details on this target privilege and granting the privilege to administrators.

22.5.5 Viewing Alerts from Log File Monitoring

Alerts generated from the Log File Pattern Matched Line Count metric appear on the home page of the target or the Alert History page.

Triggered alerts must be manually cleared.

22.6 Configuring Log Archive Locations

You can configure the host, its credentials, and archive location information for a WebLogic domain and for all targets under the domain. You can either configure everything collectively under the target at the same time, or you can configure the targets individually.

To configure all of the targets at the same time, follow these steps:

  1. From the WebLogic domain home page, select Logs from the WebLogic Domain menu, then select Configure Archive Locations.

    The Configure Archive Locations page appears.

  2. Select the WebLogic domain in the table, then click Assign Host Credentials.

    An Assign Host Credentials pop-up appears.

  3. Provide the requisite information and make sure that the Apply Above Host Credentials to Child Targets check box is enabled, then click OK.

    The host name you selected now appears in the Host column of the Configure Archive Locations page, and the column also displays this host for all of the child targets.

  4. Click Assign Archive Location.

    A Remote File Browser pop-up appears.

  5. Double-click a directory name to enter in the host name field, then repeat this process for each sub-directory that you want to in the field. Click OK when you have finished.

    The directory location you selected now appears in the Archive Location column of the Configure Archive Locations page, and the column also displays this location for all of the child targets.

To configure the targets separately, follow the procedure above, except select a particular target rather than the WebLogic domain.