This section describes the monitoring capabilities of the Sun Java System Web Server and provides a detailed list of the server parameters you can monitor at both instance and configuration level.
The server parameters that can be monitored are displayed when you select the Configurations or Instances tab under the monitoring parent tab.
From the Sun Java System Web Server Administration Console, you can perform the following actions:
View server statistics at an instance and configuration level.
Enable/Disable monitoring at configuration level.
View error/access log at the instance level.
To monitor server parameters at the configuration level, click Monitoring > Configurations tab. The table lists the available configuration along with the following information:
Nodes — The number of nodes in which the configuration has been deployed.
Requests — Total number of requests received across all virtual servers.
Errors — Total number of errors logged across all virtual servers.
Response Time — The maximum response time for any of the virtual servers.
Click the configuration name to see the configuration level statistics. The general statistics are divided into three types:
Request Statistics
Error Statistics
Response Time Statistics
The server statistics can be viewed across the following categories:
General Statistics
Instance Statistics
Virtual Server Statistics
Category |
Description |
---|---|
General Statistics |
General Statistics shows overall Request, Error and Response statistics for the configuration. |
Instance Statistics |
Instance Statistics shows overall Request, Error and Response statistics for the instances along with information on server crash and virtual server count. |
Virtual Server Statistics |
Virtual Server Statistics shows overall Request, Error and Response statistics for the virtual servers along with the number of open connections and total bytes received/transmitted. |
Click the Monitoring tab.
Select the configuration from the list.
View General, Instance and Virtual Server Statistics.
Using CLI
You can
monitor the server using the get-config-stats
, get-virtual-serevr-stats
, get-webapp-stats
and get-servlet-stats
commands.
wadm> get-config-stats --user=admin --password-file=admin.passwd
--host=localhost --port=8989 --config=test --node=cat.test.com --ssl=true
The preceding command
will fetch the statistics for the given instance. To see the statistics at the
configuration level, the above command can be used without the --node
option.
wadm> get-virtual-server-stats --user=admin --password-file=admin.passwd
--host=localhost --port=8989 --config=test --vs=www.test.com --node=cat.test.com
--ssl=true
The preceding command will fetch the aggregated
virtual server statistics for a given configuration across all the nodes where
the configuration has been deployed. To see the statistics for a configuration
deployed on a given node --node
option can be used.
wadm> get-webapp-stats --user=admin --password-file=admin.passwd
--host=localhost --port=8989 --config=test --node=cat.test.com --vs=www.test.com
--uri=/foo --ssl=true
The preceding command will
fetch the statistics for a given web application deployed on the given virtual
server of the given instance. To see the aggregated web application statistics
for a given configuration across all the nodes where the configuration has
been deployed, the previous command can be used without the --node
option.
wadm> get-servlet-stats --user=admin --password-file=admin.pwd
--host=localhost --port=8989 --config=test --node=cat.test.com --vs=www.test.com
--uri=/servlet-simple --ssl=true
The preceding command will fetch the statistics for the servlet servlet-simple.
From the Common Tasks page, click the Configuration tab and select the configuration from the list.
Click the Edit Virtual Server tab.
Click the Monitoring Setting tab.
Enable the XML Report check box and provide the publishing URI.
Click the Save button.
Click the Deployment Pending link at the top right of the screen.
Click the Deploy button.
For example, if you have configured the default URI, then you can view the stats-xml file by typing the following URL in the browser.
http://host:port/stats-xml
If you want to view the .dtd of the stats-xml file, type the following URL in the browser.
http://host:port/stats-xml/yyy.dtd
The server performs monitoring actions through SNMP. SNMP is a protocol used to exchange data about network activity. With SNMP, data travels between a managed device and a network management station (NMS). A managed device is anything that runs SNMP: hosts, routers, your web server, and other servers on your network. The NMS is a machine used to remotely manage that network. Usually, the NMS software will provide a graph to display collected data or use that data to make sure the server is operating within a particular tolerance.
The NMS is usually a powerful workstation with one or more network management applications installed. A network management application such as HP OpenView graphically shows information about managed devices such as your web servers. For example, it might show which servers in your enterprise are up or down, or the number and type of error messages received. When you use SNMP with the Sun Java System Web Server, this information is transferred between the NMS and the server through the use of two types of agents, the subagent and the master agent.
The subagent gathers information about the server and passes the information to the server’s master agent. Every Sun Java System Web Server except for the Administration Server has a subagent.
After making any SNMP configuration changes, you must click the Save button, then restart SNMP subagent.
To change settings for the configuration, perform the following tasks:
Click theConfigurations tab.
Select the configuration for which you need to change monitoring settings.
Click theMonitoring Settings sub tab.
To change general monitoring settings for a configuration, edit the values under the General Settings section. The following table provides the field description of general monitoring parameters:
Table 13–2 Field Description > General Monitoring Settings
To change SNMP subagent settings for a configuration, edit the values under the SNMP Subagent Settings section. The following table provides the field description of SNMP Subagent parameters:
Table 13–3 Field Description > SNMP Subagent Settings
SNMP is a protocol used to exchange data about network activity. With SNMP, data travels between a managed device and a network management station (NMS). A managed device is anything that runs SNMP: hosts, routers, your web server, and other servers on your network. The NMS is a machine used to remotely manage that network. Usually, the NMS software will provide a graph to display collected data or use that data to make sure the server is operating within a particular tolerance.
The NMS is usually a powerful workstation with one or more network management applications installed. A network management application such as Sun Management Center graphically shows information about managed devices, such as your web servers. For example, it might show which servers in your enterprise are up or down, or the number and type of error messages received. When you use SNMP with a Sun Java System Web Server, this information is transferred between the NMS and the server through the use of two types of agents, the subagent and the master agent.
The subagent gathers information about the server and passes the information to the server’s master agent.
To start the SNMP subagent, perform the following tasks:
Click the Nodes tab.
Select an available node from the nodes list.
Click the SNMP Subagent tab.
Click Start SNMP Subagent to start the subagent.
Before starting the SNMP subagent, verify that the master agent is running. The subagent is started only when the master agent is running.
To stop the SNMP subagent, perform the following tasks:
Click theNodes tab.
Select an available node from the nodes list.
Click the SNMP Subagent tab.
Click Stop SNMP Subagent to stop the subagent.
To use SNMP you must have a master agent and at least one subagent installed and running on a your system. You need to install the master agent before you can enable a subagent.
The procedures for setting up SNMP are different depending upon your system. The following table provides an overview of procedures you will follow for different situations. The actual procedures are described in detail later in the chapter.
Before you begin, you should verify two things:
that your system is already running an SNMP agent (an agent native to your operating system)
that your native SNMP agent supportsSMUX communication (If you’re using the AIX platform, your system supports SMUX.)
See the system documentation for information on how to verify this information.
After changing SNMP settings in the Administration Server, installing a new server, or deleting an existing server, you must perform the following steps:
(Windows) Restart the Windows SNMP service or reboot the machine.
(UNIX) Restart the SNMP master agent using the Administration Server.
Configure SNMP Parameters.
Set the SNMP parameters for the configuration.
wadm> enable-snmp --user=admin --password-file=../admin.passwd --host=serverhost --port=8989 --ssl=true --no-prompt --rcfile=null --config=config1 --loconfig1ion=india --master-host=hostname --description=cli-snmp --organization=sun --contact=internal |
Deploy the Configuration.
wadm> deploy-config --user=admin --password-file=admin.pwd --host=serverhost --port=8989 config1 |
Start the Server Instance.
$ ./https-test/bin/startserv |
Run the Master Agent (magt) as root.
To run magt, native snmpd must be stopped.
$ cd /etc/init.d/ $ init.dmi stop; init.snmpdx stop; init.sma stop |
Remove the file https-admserv/config/logs/pid.masteragt (If present).
$ rm ./https-admserv/config/logs/pid.masteragt wadm> start-snmp-master-agent --snmp-port 161 hostname |
Start the Sub Agent.
Remove the file https-admserv/config/logs/pid.httpagt( If present).
$ rm ./https-admserv/config/logs/pid.httpagt |
Kill the httpagt if it is already running
wadm> start-snmp-subagent hostname |
Configure SNMP Parameters.
Set the SNMP parameters for the configuration.
wadm> enable-snmp --user=admin --password-file=../admin.passwd --host=serverhost --port=8989 --ssl=true --no-prompt --rcfile=null --config=config1 --loconfig1ion=india --master-host=hostname --description=cli-snmp --organization=sun --contact=internal |
Deploy the Configuration.
wadm deploy-config --user=admin --password-file=admin.pwd --host=serverhost --port=8989 config1 |
Start the Server Instance.
$ ./https-test/bin/startserv |
Run the Native Master Agent (snmpd) as root.
To allow direct communication with snmpd , add the following line in /etc/snmp/snmpd.conf and restart snmpd.
smuxpeer 1.3.6.1.4.1.42.2.190.1
view systemview included .1.3.6.1.4.1.42.2.190.1
# cd /etc/init.d/ # ./snmpd stop # ./snmpd start |
Start the Sub Agent.
Remove the file https-admserv/config/logs/pid.httpagt( If present).
$ rm ./https-admserv/config/logs/pid.httpagt |
Kill the httpagt if it is already running
wadm> start-snmp-subagent hostname |
Configure SNMP Parameters.
Set the SNMP parameters for the configuration.
wadm> enable-snmp --user=admin --password-file=../admin.passwd --host=serverhost --port=8989 --ssl=true --no-prompt --rcfile=null --config=config1 --loconfig1ion=india --master-host=hostname --description=cli-snmp --organization=sun --contact=internal |
Deploy the configuration.
<install_root>\bin\wadm.bat deploy-config --user=admin --host=<hostname> --port=8989 <config1> |
You can check whether the SNMP service has been enabled, by running the command:
<install_root>\bin>wadm.bat get-snmp-prop --user=admin --port=8989 -c <config1> contact=internal enabled=true description=snmp master-host=127.0.0.1 location=us organization=sun |
Start the Web Server instance using Windows Services option.
Configure both SNMP and SNMP Trap Services according to the MSDN document.
Start SNMP Service and SNMP Trap Service using Windows Services option.
Ensure that <install_root>/lib directory is present in the System Path environment variable.
You can configure peer based master agent to integrate with OS Native Master Agent on Solaris 10 and Linux by following these steps.
The Solaris 10 OS Native Master Agent is snmpd. By default it runs on SNMP default UDP port 161. This agent is configurable using the /etc/sma/snmp/snmpd.conf file. The agent provides a proxy directive for forwarding the request/response to other Master Agents or to a Subagent. For more information, refer to the snmpd.conf manual page.
For Solaris 8 and 9, there is no clean integration with the OS Native Master Agent snmpd. For Linux, the httpagt can directly integrate with snmpd, in which case there is no need to run magt. For Windows, the Sun Java System Web Server snmp library directly communicates with windows SNMP service.
Start the master agent specifying the SNMP port (11161) as mentioned in the note above.
Add the following in /etc/sma/snmp/snmpd.conf for Solaris 10 .
proxy -v 1 -c public myserver:11161 .1.3.6.1.4.1.42.2.190.1 |
Restart the snmpd.
# cd /etc/init.d # init.dmi stop; init.snmpdx stop; init.sma stop # init.dmi start; init.snmpdx start; init.sma start |
To get the SNMP data use the snmpwalk on port:
$ snmpwalk -c public -v 1 <host-name>:<port> 1.3.6.1.4.1.42.2.190.1 |
The Administration Server log files record data about the server, including the types of errors encountered and information about server access. Viewing these logs enables you to monitor server activity and troubleshoot problems by providing data like the type of error encountered and the time certain files were accessed.
You can specify the type and format of the data recorded in the administration server logs using the Log Preferences page from the administration console. For instance, you can choose to log data about every client who accesses the administration server or you can omit certain clients from the log. In addition, you can choose the Common Log Format, which provides a fixed amount of information about the server, or you can create a custom log file format that better suits your requirements.
The log type can be broadly classified as:
Access Log — The access log records information about requests to and responses from the server.
Server Log — The Server Log lists all the errors the server has encountered since the log file was created. It also contains informational messages about the server, such as when the server was started and who tried unsuccessfully to log in to the server.
Viewing Server Logs.
wadm> get-log --user=admin --password-file=admin.passwd
--host=localhost --port=8989 --start-date=01/01/2006:09:00:00 --end-date=04/01/2006:10:00:00
--config=test cat.test.com
The preceding command displays the Server Logs of a
given configuration between the date 01/Jan/2006:09:00:00
and 04/Jan/2006:10:00:00
.
Viewing Access Logs.
wadm> get-access-log --user=admin --password-file=admin.passwd
--host=localhost --port=8989 --status-code=300 --config=test cat.test.com
The preceding command will display only those access log entries of a given configuration which have a status code of 300.
In the preceding commands, the start-date and the end-date options must be in the following format — dd/MM/yyyy:HH:mm:ss. The date format can also be customized. You can use a variable wadm_log_date_format in the rcfile to specify your own date format rather than using the default date format.
In the Sun Java System Web Server, you can enable access log by executing the following command:
enable-access-log --user=admin --host=serverhost --password-file=../admin.passwd
--port=8989 --ssl=true --no-prompt --rcfile=null --config=config1 --vs=vs
--uri-pattern="*.html" --file=../logs/access.new --log-ip=true--format="%Req->reqpb.
protocol% %Req->headers.authorization% %vsid% %Ses->client.dns%"
To enable and edit log settings for a configuration, perform the following tasks:
Click theConfiguration tab.
Select the configuration for which you will need to enable/edit log settings.
Click the General Settings > Log Settings tab.
The fields in the Access Log Preferences section are described in the following table:
Table 13–5 Field Description > Editing Access Log Preferences
The fields in the Server Log Preferences section are described in the following table:
Table 13–6 Field Description > Editing Server Log Preferences
Field |
Description |
Server Log Location |
The server path, where the Server Log files will be stored. The default value is ../logs/errors |
Log Verbosity Level |
This option provides a means of setting log granularity. To test and debug web applications, the recommended level is finest. For a production environment, the recommended log level is failure or security. catastrophe log level will log very few details. |
Log Virtual Server Name |
If this option is selected, the name of the virtual server processing the request is logged along with any errors. |
Log to System Log |
Logs all messages to the system log. |
Log to console |
If this option is selected, exceptions arising from deployed web applications are logged, if they are written to console. This option is enabled by default. |
Date Format |
The time format, which is used to append time stamps to the error messages. The default value is [%d/%b/%Y:%H:%M:%S] |
You can set up log files to be automatically archived. At a certain time, or after a specified interval, the server rotates your access logs. The server saves the old log files and marks the saved file with a name that includes the date and time they were saved.
For example, you can set up files to rotate every hour, and the server saves and names the file “access.199907.0152400,” where “name|year|month|day|24-hour time” is concatenated together into a single character string. The exact format of the access log archive file varies depending upon which type of log rotation you set up.
Access log rotation is initialized at server startup. If rotation is turned on, the server creates a time-stamped access log file and rotation starts at server startup.
Once the rotation starts, the server creates a new time stamped access log file when there is a request that needs to be logged to the access log file and it occurs after the previously-scheduled “next rotate time.”
You can create a schedule for error/access log rotation for the configured instances by using the log rotation option. To set up log rotation, perform the following steps:
Click the Configuration tab.
Select the configuration for which you need to enable/edit log settings.
Click the General Settings > Log Settings tab.
Under Log Archiving, click New.
The fields in the new log rotation page is described in the following section:
Table 13–7 Field Description > Setting Log Rotation
Field |
Description |
---|---|
Event |
Access Log Rotation / Server Log Rotation. Select any or both of these options to configure rotation for that log type. |
Time |
The configured time when the event will start. Select the hour and minutes value from the drop-down box. Every Day — Starts the event specified every day at the specified time. Specific Days — Starts the event specified at specific days. 1. Days — Specify any day from Sunday to Saturday. 2. Dates — Specify any day of the month from 1 to 31 as comma separated entries. E.g. 4,23,9 Specific Months — Starts the event specified at the specific time and month. Specify month from January to December. |
Interval |
Start the specified event after this time period. 1. Every Hours — Select the number of hours from the drop-down box. 2. Every Seconds — Select the number of seconds from the drop-down box. |
If you need to delete the scheduled log rotation, Click Delete in the Log Archiving section.
You can specify the absolute path of the command after the server rotates the log file. The post-rotation filename of the log file is passed as an argument to the archive command. The archive command also compresses the log file that has been rotated.
All the configuration changes performed using the administration console are logged by the administration server. Some common actions logged are creating new configurations, creating virtual servers, and configuring instance settings. However configuration level details like accessing a web application or exceptions raised while accessing a web application are logged separately by the configuration.
Click the Administration Server > General tab.
Go to the Log Preferences section.
Edit the Server Log Location field.
Log the location where the errors will be stored. Provide a valid server path for maintaining the log files. Also check if the administration server has the permission to write in the specified directory for UNIX systems.
The default location is ../log/errors
Click the Administration Server > General tab.
Go to the Log Preferences section.
Select the Log Verbosity Level.
This option provides you with a means of setting log granularity. For testing and debugging, the recommended level is finest.
For a production environment, the recommended log level is failure or security. catastrophe log level will log very few details.