Tomcat

Auto-Detection

Built-in Metrics

Apache Tomcat is a free, open-source web server and servlet container that runs Java-based web applications.

Auto-Detection

Bleemeo monitors Apache Tomcat through automatic service detection by its process and command line, a service check on port 8080, and built-in connector and JVM metrics read from the manager application’s status page. If the auto-detected parameters are incorrect, you can override them manually.

Linux

sudo tee /etc/glouton/conf.d/99-tomcat.conf > /dev/null << 'EOF'
service:
  # For a Tomcat running outside a container
  - type: "tomcat"
    address: "127.0.0.1"
    port: 8080
    username: "glouton"
    password: "REPLACE_WITH_YOUR_PASSWORD"

  # For a Tomcat running in a Docker container
  - type: "tomcat"
    instance: "CONTAINER_NAME"
    port: 8080
    username: "glouton"
    password: "REPLACE_WITH_YOUR_PASSWORD"
EOF

Windows

Create or edit C:\ProgramData\glouton\conf.d\99-tomcat.conf:

service:
  - type: "tomcat"
    address: "127.0.0.1"
    port: 8080
    username: "glouton"
    password: "REPLACE_WITH_YOUR_PASSWORD"

Glouton automatically detects configuration changes.

Requirements

Both a username and a password are required. Tomcat ships an empty conf/tomcat-users.xml, so there is no factory account to fall back on and a password alone can only ever get a 401. Without both, Tomcat is detected and checked but no metrics are collected.

Declare an account holding the manager-status role in conf/tomcat-users.xml:

<tomcat-users xmlns="http://tomcat.apache.org/xml" version="1.0">
  <role rolename="manager-status"/>
  <user username="glouton" password="REPLACE_WITH_YOUR_PASSWORD" roles="manager-status"/>
</tomcat-users>

The manager application must also be deployed so Glouton can reach it to ask for metrics. Some distributions and the official container image ship it undeployed, under webapps.dist/; it has to be copied into webapps/ before Tomcat starts.

The manager only accepts requests from localhost by default. When Tomcat runs in a container, Glouton connects from outside it and is a remote client as far as Tomcat is concerned, so its address filter has to be widened in webapps/manager/META-INF/context.xml:

<Context antiResourceLocking="false" privileged="true">
  <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.0\.0\.1|172\.17\..*"/>
</Context>

Credentials on a Container

Tomcat reads its accounts from conf/tomcat-users.xml and from no environment variable, so unlike ActiveMQ or PostgreSQL there is nothing for Glouton to pick up from the container environment. Carry them as Docker labels instead, and the container needs no entry in the Glouton configuration at all:

docker run --label glouton.username=glouton --label glouton.password=REPLACE_ME [...]

username and password are honored out of the box; see container.allowed_label_overrides. The equivalent Kubernetes pod annotations work the same way.

Built-in Metrics

Connector and memory-pool metrics carry a name label holding the connector (http-nio-8080) or the pool they describe, so there is one series per connector and per pool.

Metric	Description
service_status	Status of Tomcat
tomcat_connector_request_count	Number of Tomcat connector requests, per second
tomcat_connector_error_count	Number of Tomcat connector errors, per second
tomcat_connector_processing_time_seconds	Average Tomcat connector request processing time
tomcat_connector_bytes_received	Number of bytes Tomcat received, per second
tomcat_connector_bytes_sent	Number of bytes Tomcat sent, per second
tomcat_connector_current_threads_busy	Number of busy Tomcat connector threads
tomcat_connector_max_threads	Maximum number of Tomcat connector threads
tomcat_jvm_memory_free	Tomcat JVM free memory
tomcat_jvm_memory_max	Tomcat JVM maximum memory
tomcat_jvm_memorypool_used	Tomcat JVM memory pool used

Monitoring Troubleshooting

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The Service Check is not OK

The check only opens the TCP port so it fails when nothing listens there (Connection refused), when a firewall drops the packets (connection timed out after 10 seconds), or when the configured address cannot be parsed (Invalid TCP address). A green check proves the port is open, and nothing more: it says nothing about the manager application or the credentials.

Metrics are Missing

Reproduce what Glouton does, from the machine where the agent runs:

curl -su glouton:PASSWORD 'http://127.0.0.1:8080/manager/status/all?XML=true' | head -5

What you see	Cause	Fix
nothing collected, no request in the Tomcat log	No username or no password is configured	Set both — one alone is not enough
401 Unauthorized	The account does not exist or the password is wrong	Check conf/tomcat-users.xml
403 Forbidden	The account exists but lacks the manager-status role, or the manager refuses the agent’s address	Add the role, or widen RemoteAddrValve
404 Not Found	The manager application is not deployed	Copy it from webapps.dist/ into webapps/
a connection error	Tomcat listens on another address or port	Set address / port, or stats_url for a full URL