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:
Many Enterprise Manager components generate log files containing messages that record errors, notifications, warnings, and traces.
Table 28-1 describes the columns in the Log Message table. For any given component, the optional column may not be populated in the message.
| 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 |
|
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:
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:
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.
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.
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.
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. The Message Type is sorted by importance from highest to lowest and uses the order of Incident Error, Error, Warning, Notification, and then Trace.
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.
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:
Log in to the Oracle Enterprise Manager 12c Cloud Control console as a super administrator.
From the Setup menu, choose Security, then Administrators.
Select the appropriate administrator and click Edit.
Click Next twice to arrive on the Target Privileges page of the wizard.
Scroll down the page and click Add in the Target Privileges section of the page.
From the Search and Add: Targets popup dialog, select the appropriate targets for which the administrator should have access to view logs. Click Select.
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.
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.
Notice on the Target Privileges page of the wizard the appearance of the new privilege. Click Review and then Finish to conclude the operation.
You may find that you want to add custom log files for WebLogic Server such that those log files and messages appear in the Enterprise Manager Log Viewer. While Enterprise Manager does not support adding custom log files via the Log Viewer user interface, there is a way to do it outside of Enterprise Manager.
Normally the ODL LogQueryMBean automatically discovers the Weblogic server logs and any ODL log file defined in the logging.xml file associated with the Weblogic server. However, you can register additional log files with the ODL LogQueryMBean, so that these files can be viewed and/or downloaded from the Enterprise Manager Log Viewer.
When registering a new log file there are two options you can use:
You can register a log file with an associated LogReader that can be used to parse the contents of the file. In this case the contents of the file can be viewed and searched from the main Log Messages page.
You can register the path to the log file, but do not provide a LogReader to parse the contents of the file. In this case the contents of the file cannot be viewed and searched from the main Log Messages page, but you can view the raw contents of the file or download its contents from the Target Log Files page.
To register one or more additional log files you can create a file under directory:
DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/diagnostics-registration
The file must have a .xml suffix and it should have contents similar to the following:
<?xml version='1.0' encoding='UTF-8'?>
<logs xmlns='http://www.oracle.com/iAS/EMComponent/ojdl'>
<log path="/home/oracle/mylogs/my-odl-diagnostic.log">
<logreader class="oracle.core.ojdl.reader.ODLLogReaderFactory">
</logreader>
</log>
</logs>
In this case the file is an ODL file and it is being registered with a LogReader. In addition to the ODL LogReader, there are a few existing log readers that can be used to read other formats.
You can also register a log without a log reader as seen here:
<?xml version='1.0' encoding='UTF-8'?> <logs xmlns='http://www.oracle.com/iAS/EMComponent/ojdl'> <log path="/home/oracle/mylogs/my-other-diagnostic.log"/> </logs>
You may use variables or a wildcard in the log path. The wildcard is denoted by "%*%", while a variable has the form of "%NAME%". Multiple occurrences of the same variable in the path must have the exact same value. If a variable appears only once, it will behave like a wildcard.
All log files registered in this way are associated with the server target in Enterprise Manager.
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:
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:
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.
In the Search Mode secstion, you can choose to search for only Live Logs, only Archive Logs, or Both.
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.
In the Message Types section, select one or more of the message types.
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.
Click Search.
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.
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.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:
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.
Search for particular types of messages as described in Searching Log Files: Basic Searches.
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.
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:
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.
Search for particular types of messages as described in Searching Log Files: Basic Searches.
For Show, select Group by Message Type or Group by Message ID.
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.
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.
Select either Open With or Save to Disk. Click OK.
To download the log files for a specific component:
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.
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.
Select a log file and click Download.
An Opening dialog box is displayed.
Select either Open With or Save to Disk. Click OK.
The following sections provide information on creating, retrieving, and managing saved 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.
To retrieve a saved search. follow these steps:
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.
On the Logs page, click Saved Searches located at the top-right of the page.
Choose a search.
The search results populate the Search region.
To manage a saved search, follow these steps:
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.
On the Logs page, click Saved Searches located at the top-right of the page.
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.
The following sections provide information on the log and trace files for the Oracle Management Agent:
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.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
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.
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:
| 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 |
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).
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
or
$ emctl setproperty agent -name "Logger.log.level" -value "DEBUG"
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
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
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.
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="linuxserver07.myco.com:41034_Management_Service" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target> <Target IDENTIFIER="TARGET_GUID=DF64B4A7C0F2EEBA7894EA3AD4CAF61E" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service" NAME="linuxserver07.myco.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="linuxserver07.myco.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" ASSOCIATION_NAME="app_composite_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_console" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" ASSOCIATION_NAME="internal_contains"/><AssocTargetInstance ASSOC_TARGET_TYPE="oracle_oms_pbs" ASSOC_TARGET_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" ASSOCIATION_NAME="internal_contains"/><CompositeMembership><MemberOf ASSOCIATION="" NAME="Management Services and Repository" TYPE="oracle_emrep"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" TYPE="oracle_oms_console"/><Member ASSOCIATION="" NAME="linuxserver07.myco.com:41034_Management_Service_PBS" TYPE="oracle_oms_pbs"/></CompositeMembership></Target> <Target IDENTIFIER="TARGET_GUID=4D290260F13596502EFD8F3E22752404" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service_CONSOLE" NAME="linuxserver07.myco.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="linuxserver07.myco.com:41034_Management_Service" TYPE="oracle_oms"/></CompositeMembership></Target> <Target IDENTIFIER="TARGET_GUID=D0A23AE06A9E678221B075A216364541" STATUS="MONITORED" TIMEZONE_REGION="" ON_HOST="" DISPLAY_NAME="linuxserver07.myco.com:41034_Management_Service_PBS" NAME="linuxserver07.myco.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="linuxserver07.myco.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.The following sections describe how to locate and configure the OMS log files:
Controlling the Size and Number of Oracle Management Service Log and Trace Files
Controlling the Contents of the Oracle Management Service Trace File
Controlling the Oracle WebLogic Server and Oracle HTTP Server Log 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.
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.
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 28-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.myco.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.myco.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 28-3 Oracle Management Service Log File Properties in the emomslogging.properties File
| Property | Purpose | Example |
|---|---|---|
|
When OMS log file reaches this size, then OMS copies the logging data to a new rollover file and creates a new |
log4j.appender.emlogAppender. |
|
|
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. |
|
|
When the OMS trace file reaches this size, then OMS copies the logging data to a new rollover file and creates a new |
log4j.appender.emtrcAppender. |
|
|
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. |
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 theroot 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.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 28-4 lists the location of the log files for some components.
Table 28-4 Component Log File Location
| Component | Location |
|---|---|
|
Oracle HTTP Server (OHS) |
For example,
|
|
OPMN |
For example,
|
|
Oracle WebLogic |
The log data from WebLogic will be at:
This log can be restricted, rotated by size, time, and other conditions from the WebLogic Console. The default settings are:
For example,
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:
For example,
The node manager logs are at |
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.
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:
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.
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 search patterns. In addition, you can specify a 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 a Management Agent installed and running. The operating system user who installed the Management Agent must have read access to the directories where the monitored log files reside. Log file monitoring is disabled by default. You must enable it in order to use this feature.
Log File Monitoring is disabled by default. To enable Log File Monitoring, follow these steps:
From the target menu, select Monitoring.
Choose Metric and Collection Settings.
On the Metric and Collection Settings page, in the Metrics tab, from the View drop-down menu, select All metrics.
Search for Log File Monitoring. Against the Log File Monitoring row, click the Disabled link.
On the Edit Collection Settings: Log File Monitoring page, in the Collection Schedule section, click Enable. The default collection schedule is set for every 60 minutes.
Click Continue.
The Metric and Collection Settings page appears. At this point, Enterprise Manager Cloud Control enables Log File Monitoring but does not save the changes to the Management Repository.
On the Metric and Collection Settings page, click OK.
Enterprise Manager Cloud Control saves your changes to the Management Repository.
To configure Log File Monitoring, follow these steps:
From the target menu, choose Monitoring.
From the Monitoring menu, select Metric and Collection Settings.
On the Metric and Collection Settings page, in the Metrics tab, from the View drop-down menu, select All metrics.
Search for Log File Monitoring.
Under the Log File Monitoring row, in the Log File Pattern Matched Line Count row, click the Edit icon on the right.
On the Edit Advanced Settings:Log File Pattern Matched Line Count page, in the Monitored Objects section, click Add to add new objects to specify settings for the log files to be monitored.
The table in the Monitored Objects section lists all log file names, match patterns, and ignore patterns set for this metric. You can specify different threshold settings for each of the columns. The Reorder button specifies which log file to scan first.
You can use a combination of wildcards and regular expressions to set your search criteria.
In the Log File Name column, enter the log file name pattern you want to search for.
You can use a combination of wildcards and regular expressions. However, when you use wildcards in the Log File Name column, make sure you use them only for identifying the log file names and not for identifying the location path of the log directory where the log files reside.
For example,
If you provide /u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%.log, then all files that have the .log extension in the log directory are selected.
If you provide /u01/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/%diagnostics%, then all files that have diagnostics in their file names in the log directory are selected.
If you provide /u01/domains/%_DOMAIN%/servers/EMGC_OMS1/logs/%diagnostics%, then it will be treated as an invalid pattern. Do not use wildcards to identify the log directory path.
In the Match Pattern column, enter the match pattern that should be considered in the log file. You can use a combination of wildcards and regular expressions. Case is ignored.
For example:
Set the match pattern as FATAL. This pattern will be true for any lines containing fatal.
Set the match pattern as %fatal%critical%. This pattern will be true for any lines containing fatal and critical.
In the Ignore Pattern column, enter the pattern that should be ignored in the log file. By default, % appears in the column; you should remove the default value if nothing should be ignored. You can use a combination of wildcards and regular expressions. Case is ignored.
Set the match pattern as BEA-0023 and the ignore pattern as warning. This pattern searches for BEA-0023 but ignores it if the same line contains warning.
Set the match pattern as ADFC-1023%FAILED%. This pattern searches for ADFC-1023 only if it is followed by FAILED anywhere in the same line.
Set the match pattern as BEA-% and the ignore pattern as BEA-1005. This pattern searches for all patterns starting with BEA- but ignores BEA-1005.
In the Warning Threshold and Critical Threshold columns, set the threshold values 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.
Including the Log File Pattern Matched Line Count Metric As Part of a Monitoring Template
Once log file monitoring is enabled and configured, you can include the ’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:
From the WebLogic Domain menu, select Target Setup submenu and then Monitoring Configuration.
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.
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.
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:
From the WebLogic domain home page, select Logs from the WebLogic Domain menu, then select Configure Archive Locations.
The Configure Archive Locations page appears.
Select the WebLogic domain in the table, then click Assign Host Credentials.
An Assign Host Credentials pop-up appears.
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.
Click Assign Archive Location.
A Remote File Browser pop-up appears.
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.