Use WebLogic Remote Console to monitor WebLogic Server and its related resources and services.
For general information on monitoring, diagnostic, and tuning tools in WebLogic Server, see Monitoring, Diagnosing, and Troubleshooting in Understanding Oracle WebLogic Server.
Review the servers in your domain to ensure they are functioning as expected.
In the Monitoring Tree, go to Environment, then Servers.
Use the Servers table to monitor and compare properties across the different server instances in your domain.
Use the Customize Table feature to rearrange the table columns to suit your needs.
To see more information about a server, click on its row in the table.
Each server has its own child node under the Servers node. A top-level myServer node provides general runtime information regarding the selected server. Expand the myServer node to see more specific information for other areas such as scheduling or deployments.
You can check the current status of Node Manager and use Node Manager logs to help troubleshoot problems in starting or stopping individual Managed Servers.
For more information, see Log Files in Administering Node Manager for Oracle WebLogic Server.
Node Manager must be running to view its logs.
In the Monitoring Tree, go to Environment, then Node Manager Logs.
Click the name of the machine whose Node Manager logs you want to view.
Click Download.
When using Hosted WebLogic Remote Console, your browser controls the location where the log files are downloaded. If you want to change the default download location, update your browser settings accordingly.
A server can monitor key aspects of its subsystems and report when a subsystem is not functioning properly.
If the server is running under a Node Manager, the Node Manager can automatically restart a server with an unhealthy subsystem. Node Manager can only perform automatic monitoring and shutdown for servers that it starts.
In the Edit Tree, go to Environment, then Servers, then myServer.
On the Health tab, modify the options as necessary.
Click Save.
Use dashboards to quickly assess and filter data about your domain. You can specify criteria for WebLogic Remote Console to match against MBeans in your domain and then review the results.
Dashboards are highly customizable. Start from any node in the Monitoring perspective and you can use its properties to develop precise criteria that go far beyond simple true/false statements. Dashboards let you find obscure, cross-functional data that might otherwise require comparison across multiple nodes.
Dashboards are only available on the Monitoring Tree perspective.
Tip:
You can expand the Dashboards node at the bottom of the Navigation tree to see any saved or built-in dashboards.
In dashboards, filters are the criteria that you use to curate your results. Generally, filters are based on the properties of a node.
WebLogic Remote Console restricts which filters are available based on your current node so you can focus on the criteria that is relevant to your goals. As such, the filters that are available on the Environments: Servers node are different than those available under Deployments: Application Runtime Data.
Each filter consists of a name (or property) from the domain, a value, and an operator that determines how the name and value interact with each other. A basic dashboard filter is simply name=value. The following example dashboard filter returns any servers that require a restart to apply configuration changes:
ServerRuntime.RestartRequired == true
Values come in three formats:
On for True, Off for False.Use operators to determine how a value should be assessed. Only the operators that are applicable to a name or property appear as options - you won’t see greater than for text values. By default, all filters are set to Any to provide the broadest possible search parameters.
Dashboards consist of one or more filters and filters are cumulative - beans must match ALL of the defined filters to be returned as a result. Therefore, when you build a dashboard, only edit the filters that are relevant to your query and leave the rest of the filters unchanged.
WebLogic Remote Console provides a set of pre-defined dashboards to monitor common domain statistics.
On the Monitoring Tree, expand the Dashboards node to see both custom and built-in dashboards.
You cannot edit or delete built-in dashboards. However, you can use a built-in dashboards as a starting point for another dashboard. Select a built-in dashboard and click Copy, then enter a new name for your custom dashboard. Edit it as you would a custom dashboard.
You can create your own custom dashboards to monitor the state of your domain.
In the Monitoring Tree, go to the node in the Navigation Tree that most closely matches the type of content that you want to track. For example, if you want to learn about servers, open the Environment: Servers node.
Click New Dashboard.
Enter a name for your new dashboard and then begin configuring the filters that will determine the results of the dashboard. For guidance on how to build filters, see Dashboard Filters.
Click Create to generate the dashboard.
Click Customize Table to control which columns appear in the dashboard.
All of your dashboards are available in the Dashboards node of the Monitoring Tree.
Dashboards are not automatically refreshed with new data. You must refresh or rerun the dashboard page to see any changes to MBeans. Click Reload to update the results. You can also click Auto Reload Interval to set the dashboard to regularly reload and update the results.
WebLogic Server logging services provide facilities for writing, viewing, filtering, and listening for log messages. These log messages are generated by WebLogic Server instances, subsystems, and Java EE applications that run on Oracle WebLogic Server or in client JVMs.
Use WebLogic Remote Console to configure WebLogic Server Logging services. For general information on WebLogic Server logging services, see Understanding WebLogic Logging Services in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
Each subsystem within WebLogic Server generates log messages to communicate its status. To keep a record of the messages that its subsystems generate, WebLogic Server writes the messages to log files.
The contents of log files are generated according to the logging settings that are currently defined for a server. To manage what information is sent to a log file, see Configure Logs.
For more information on WebLogic logging services, see Understanding WebLogic Logging Services in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
In the Monitoring Tree, go to Diagnostics, then Logs and Archives.
Each row is a type of diagnostic data. Click on the row that you’re interested in to view its logs.
Select a log file and then click Download Logs.
Logs are segregated by server instance.
WebLogic Server generates log files to track and communicate the status of its various subsystems. To ensure these log files remain valuable and usable, you can configure their settings.
Each WebLogic Server instance writes all messages from its subsystems and applications to a server log file that is located on the local host computer. In addition to writing messages to the server log file, each server instance forwards a subset of its messages to a domain-wide log file. By default, servers forward only messages of severity level Notice or higher. See Server Log Files and Domain Log Files in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
The server log records information about events such as the startup and shutdown of servers, the deployment of new applications, or the failure of one or more subsystems. The messages include information about the time and date of the event as well as the ID of the user who initiated the event. You can view and sort these server log messages to detect problems, track down the source of a fault, and track system performance.
You can also create client applications that listen for these messages and respond automatically. For example, you can create an application that listens for messages indicating a failed subsystem and sends email to a system administrator.
For more information on WebLogic logging services, see Understanding WebLogic Logging Services in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Logging tab.
Modify the logging settings to suit your needs.
Click Save.
Repeat on the rest of the servers.
Go to Environment, then Domain.
Click the Logging tab.
Modify the settings for the domain-level log to suit your needs.
Click Save.
Specify debugging settings for WebLogic Server.
In the Edit Tree, go to Environment, then Servers, then myServer.
Click the Debug tab.
The Debug tab is split into several subtabs that group related debug flags together. Use the All tab to see all available debug flags.
Enable the debug flags that you want to generate logging messages.
Click Save.
If you haven’t already, you should configure general logging settings for this server. See Configure Logs.
If you create applications to run on WebLogic Server, you can configure your applications to generate messages of severity DEBUG. These messages are never forwarded to the domain log and are intended to contain detailed information about the operation of an application or the server.
WebLogic Server can generate a significant amount of data in its log messages. You can filter log messages so only certain messages are published.
For example, you can filter out messages of a certain severity level, or from a particular subsystem, or according to some other specified criteria. Only the log messages that satisfy the filter criteria get published. You can also create separate filters for the messages that each server instance writes to its server log file, standard out, memory buffer, or broadcasts to the domain-wide message log.
WebLogic Server offers multiple methods for filtering log messages and you can use these methods simultaneously. Choose the methods that work for your environment. For more information, see Filtering WebLogic Server Log Messages in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
In the Edit Tree, go to Environment, then myServer.
Click on the Logging tab.
Click Show Advanced Fields.
If you want to change the default severity level for all loggers or packages in the logger tree, then choose a new level from the Minimum severity to log drop-down list.
The default level is Info. For information on message severity, see Message Severity in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
If you want to redirect the standard out of the JVM in which the WebLogic Server instance runs to the four log message destinations (log file, standard out, domain log, and message buffer), then turn on Redirect stdout logging enabled. For more information, see Redirecting JVM Output in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
If you want to override the setting for the root Logger (as specified by the Minimum severity to log list option) or its closest parent node in the logger tree, then do as follows:
Click the Severity Properties tab.
In the Logger Severity Properties table, click + to add a new key-value row, then double-click the row cells to update the key and value.
You can also use Logger severity properties to specify severity levels for packages (if using the Commons Logging API) or for individual WebLogic Server subsystem Loggers (if using the Message Catalog Logger).
All loggers inherit the severity level of their nearest parent node in the logger hierarchy. You can specify a severity level for a given logger that is different than its nearest parent node using key-value pairs, where the key is the logger name and the value is the severity level (Info, Critical, Warning, and so on).
See Specifying Severity Level for Loggers in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
If you want to control which log messages are published, you can create log filters which use custom logic to evaluate log message content and then accept or reject it for publication based on its criteria. You can apply log filters to these log message destinations: log file, standard out, and domain log broadcaster.
To apply a log filter to the log file message destination, choose your preferred severity level from the Log File Severity Level drop-down list, then choose a log filter from the Log File Filter drop-down list.
To apply a log filter to the standard out message destination, choose your preferred severity level from the Stdout Severity Level drop-down list, then choose a log filter from the Stdout Filter drop-down list.
To apply a log filter to the domain log broadcaster message destination, choose your preferred severity level from the Domain Log Broadcast Severity Level drop-down list, then choose a log filter from the Domain Log Broadcast Filter drop-down list.
You can specify the size of the message buffer which stores messages that will be forwarded to the domain log. A higher value causes more messages to be stored in the buffer before the contents are forwarded to the domain log. For performance reasons, it is recommended that this value be set to 10 or higher in production mode.
You cannot forward DEBUG messages to the domain log.
Click Save.
Log filters provide control over the log messages that get published. A filter uses custom logic to evaluate the log message content, which you use to accept or reject a log message
For example, to filter out messages of a certain severity level, from a particular subsystem, or according to specified criteria. Only the log messages that satisfy the filter criteria get published. You can create separate filters for the messages that each server instance writes to its server log file, standard out, memory buffer, or broadcasts to the domain-wide message log.
In the Edit Tree, go to Environment, then Log Filters.
Click New.
Enter a name for the log filter and click Create.
Enter an expression in the Filter Expression field.
A filter expression defines simple filtering rules to limit the volume of log messages written to a particular log destination. For information on building filter expressions, see WLDF Query Language in Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.
Click Save.
Update your logging settings to apply this log filter. See Filter Log Messages.
Set a rotation schedule for the log files generated by WebLogic Server.
For more information, see Rotating Log Files in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
WebLogic Server sets a threshold size limit of 2,097,152 kilobytes before it forces a hard rotation to prevent excessive log file growth.
In the Edit Tree, go to Environment, then Servers, then myServer.
On the Logging tab, from the Rotation Type drop-down list, select the criteria that triggers the server to move log messages to a separate file. Depending on your choice, configure the appropriate settings.
If you chose By Size as the Rotation Type.
SERVER_NAME.log00007. After the server renames the file, subsequent messages accumulate in a new file named SERVER_NAME.log.If you chose By Time as the Rotation Type.
In the Begin rotation time field, enter the start time
Use the following format: hh:mm, where hh is the hour in a 24-hour format and mm is the minute. At the time that you specify, the server rotates the current log file. If the time that you specify is already past, the server rotates the log file at the next scheduled interval, as specified in Rotation Interval.
In the Rotation Interval field, enter the interval, in hours, at which the server saves old messages to another file.
If you want to limit the number of log files that the server creates to store old log messages, enable the Limit Number of Retained Log Files option. Then, in the Files to Retain field, enter the maximum number of files. If the server receives additional log messages after reaching the capacity of the last log file, it overwrites the oldest log file.
In the Log file rotation directory field, enter the directory location where the rotated log files will be stored.
Enter an absolute pathname or a pathname that is relative to the server’s root directory. By default, the rotated files are stored in the same directory where the log file is stored.
If you want to add a time or date stamp to the file name when the log file is rotated, then in the Log file name field, add java.text.SimpleDateFormat variables to the file name and surround each variable with percentage (%) characters.
For example, if you enter the following value in the Log file name field: myserver_%yyyy%%MM%%dd%%hh%%mm%.log, the server’s log file will be named myserver_yyyy_MM_dd_hh_mm.log.
When the server instance rotates the log file, the rotated file name contains the date stamp. For example, if the server instance rotates its local log file on 4 March 2020 at 10:15 AM, the log file that contains the old log messages will be named myserver_2020_03_04_10_15.lognnnnn. (The current, in-use server log file retains the name myserver_yyyy_MM_dd_hh_mm.log.)
If you do not include a time and date stamp, the rotated log files are numbered in order of creation SERVER_NAME.lognnnnn, where SERVER_NAME is the name configured for the log file. For example: myserver.log00007.
Click Save.
You can configure the Administration Server to emit audit messages that enable auditing of configuration changes in a domain.
This provides a record of changes to the configuration of any resource within a domain or invokes management operations on any resource within a domain. Configuration audit records can be saved to a log file, sent to an Auditing provider in the security realm, or both.
If you plan to audit configuration changes, then you must configure the WebLogic Auditing Provider first. See Configure an Auditing Provider.
In the Edit Tree, go to Environment, then Domain.
Click Show Advanced Fields.
From the Configuration Audit Type drop-down list, select the method to use for auditing configuration change events.
Click Save.
You can display the current stack for an active thread.
In the Monitoring Tree, go to Environment, then JVM Runtime.
Click the Thread Stack Dump tab to see an overview of the thread stack dumps for each server in the domain.
To see the thread stack dump for a single server, click the server instance in the table. This sends you to the JVM Runtime node for the selected server. Click the Thread Stack Dump tab.
To ensure that your WebLogic Server environment is performing optimally, you should regularly monitor its behavior and then adjust its settings accordingly.
For guidance on the performance tuning options that are available in WebLogic Server, see Tuning Performance of Oracle WebLogic Server.
In the Edit Tree, go to Environment, then Servers, then myServer.
On the Advanced tab, select the Tuning subtab.
Modify the available options as recommended based on the needs of your environment.
Click Save.
Repeat as needed for the rest of the servers in your domain.