Monitoring Web services

Get insight into your application server with the GAS feature that allows you to monitor performance, set alerts, and analyze data.

The gasadmin tool has monitoring commands that allow you to continuously monitor Web services running on the GAS. The command allows you to configure alarms to monitor for different types of failures or performance issues. For example, you can decide to receive an alert when a DVM crashes, when a DVM fails to connect, or when a service request fails. In addition, monitoring allows you to see service usage metrics based on timers. The GAS writes this data to monitoring data (.dat) files, and you can fetch this data for analysis.

Configuring for the session or for the service

You set alarms with the gasadmin command, using a session id (--session) or a service name (--service).
  • gasadmin monitoring update --set-alarm DVM_NOT_STARTED --session d98290172c8f7c0d861db329f1ce6597
  • gasadmin monitoring update --set-alarm DVM_NOT_STARTED --service demo/Calculator

Whether you choose the session id or the service name has consequences.

--session monitors a running session

To monitor a running session, use the --session option and provide the service's session id. The alarm is effective immediately for the running session (or, to be precise, for the running gwsproxy managing that session.) If the session is not running, the command will return an error. When the gwsproxy for the session stops, the monitoring command for that running session is lost; when a new gwsproxy starts for that same service, the lost command does not reactivate.

Whether the gwsproxy for a session stops depends on the pool configuration for the service. For example, if KEEP_ALIVE is set to "10", the gwsproxy will stop after 10 seconds of inactivity and the monitoring command for that running session will be lost forever. Even if the a new gwsproxy is started for the service, the monitoring command is lost and does not reactivate.

--service monitors the next start of the service

If you configure alarms at the service level, the configuration is only taken into account with the start of the next gwsproxy. If you want the alarm to be effective immediately, you must configure the alarm at the session level.

Troubleshooting tips

Should I monitor the session or the service?
  • Use --session is to monitor a running session.
  • Use --service is to monitor the next start of the service.
Important:

If you want to monitor a running session and you want it to be persistent, you must use options --session and --service in two separate commands.

Why has monitoring of my service stopped?

If monitoring of your service has stopped, you likely set the monitoring using the --session option, and the gwsproxy stopped due to a timeout. When the gwsproxy stops, monitoring configured with the --session option is lost forever. The monitoring data (.dat) files remain containing all monitoring data written prior to the stop of the gwsproxy, but no new data will be written for the lost configuration.

When the gwsproxy restarted, only the monitoring set using the --service option reset for that running session.