This section describes the monitoring capabilities of 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.
For monitoring server parameters at the configuration level, click on Monitoring > Configurations tab. The table lists down 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 configuration name to get the configuration level statistics. The general statistics are divided into 3 types:
Request Statistics
Error Statistics
Response Time Statistics
From the administration console, the server statistics can be viewed across the following categories:
General Statistics.
Instance Statistics.
Virtual Server Statistics.
Category |
Description |
---|---|
General Statistics |
The General Statistics shows overall Request, Error and Response statistics for the configuration. |
Instance Statistics |
The 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 |
The 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 above command will fetch the statistics for the given instance.
To get 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 above command will fetch the aggregated
virtual server statistics for a given configuration across all the nodes where
the configuration has been deployed. To get 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 above command will fetch
the statistics for a given web application deployed on the given virtual server
of the given instance. To get the aggregated web application statistics for
a given configuration across all the nodes where the configuration has been
deployed, the above 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 above 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 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.
For changing settings for the configuration, perform the following tasks:
Click Configurations tab.
Select the configuration for which you need to change monitoring settings.
Click Monitoring Settings sub tab
For changing 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
For changing 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.
For starting the SNMP subagent, perform the following tasks:
Click Nodes tab
Click available node from the nodes list.
Click SNMP Subagent tab
Click Start SNMP Subagent button 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.
For stopping the SNMP subagent, perform the following tasks:
Click Nodes tab
Click available node from the nodes list.
Click SNMP Subagent tab
Click Stop SNMP Subagent button to stop the subagent.
In general, 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:
Is your system already running an SNMP agent (an agent native to your operating system)?
If so, does your native SNMP agent support SMUX communication? (If you’re using the AIX platform, your system supports SMUX.)
See your 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 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 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 |
Add the install-root/ lib directory to the System Path environment variable.
Restart the machine.
Start the Web Server instance using Windows Services option.
Start SNMP Service.
You cannot start the SNMP master agent through the administration interfaces when the Administration Server is installed as a non-root user. To allow a non-root Administration Server user to start master agent through administration interfaces, the non-root user must be given the privileges to bind to the privileged ports using RBAC, which the SNMP master agent runs on. The default SMUX port is 199 and default SNMP port is 161.
Another workaround is to manually start the master agent as root using the following command:magt CONFIG INIT The magt command is located under server-root/lib/snmp/magt/.
You can configure peer based master agent to integrate with OS Native Master Agent on Solaris 10 and Linux by following these steps.
Solaris 10 OS Native Master Agent is snmpd. By default it runs on SNMP default UDP port 161. This is configurable using /etc/sma/snmp/snmpd.conf file. It provides proxy directive for forwarding the request/response to other Master Agents or Subagent. For more information refer to the snmpd.conf man page.
For Solaris 8 and 9, there is no clean integration with OS Native Master Agent snmpd. For linux, httpagt can directly integrate with snmpd. In that case no need to run magt. For Windows, 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 allows 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 above command will
display 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 above command will display only those access log entries of a given configuration which have status code as 300.
In the above commands, the start-date and the end-date options should be in the in the format — dd/MM/yyyy:HH:mm:ss. The date format can also be customized. You could use a variable wadm_log_date_format in the rcfile to specify your own date format rather than using the default date format.
In 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%"
For enabling and editing log settings for a configuration, perform the following tasks:
Click Configuration tab
Select the configuration for which you will need to enable/edit log settings.
Click 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 you with an elegant way of setting log granularity. For testing and debugging web applications, the recommended level is finest. For 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, along with the errors, the name of the virtual server processing the request is also logged. |
Log to System Log |
Log 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 will be used to append time stamps to the error messages. The default value is [%d/%b/%Y:%H:%M:%S] |
You can set up your 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 your 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. For setting up log rotation, perform the following steps:
Click Configuration tab
Select the configuration for which you need to enable/edit log settings.
Click General Settings > Log Settings tab
Click New button under Log Archiving Section
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 button in the Log Archiving section.
All the configuration changes performed using the administration console is logged by the administration server. Some common actions logged are creating new configuration, creating virtual servers and configuring instances 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 Administration Server > General tab.
Go to Log Preferences section.
Edit the Server Log Location field.
Log 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 Administration Server > General tab.
Go to Log Preferences section.
Select the Log Verbosity Level.
This option provides you with an elegant way of setting log granularity. For testing and debugging, the recommended level is finest.
For production environment, the recommended log level is failure or security. catastrophe log level will log very few details.