December 2018 Summaries

Datadog offers comprehensive monitoring for Apache Tomcat by integrating logs, metrics, and events into a unified platform, facilitating long-term performance tracking across various systems within an infrastructure. It provides a step-by-step guide on setting up Tomcat integration, including installing the Datadog Agent to collect and analyze Tomcat metrics and logs via JMX, and configuring customizable dashboards for monitoring. The platform supports log processing and analysis, enabling users to extract structured data and create custom log pipelines for enhanced insights. Additionally, Datadog offers alerting features to notify users of critical issues such as anomalies in request processing times or memory usage, allowing for proactive management of Tomcat server health. With over 650 integrations, Datadog extends monitoring capabilities beyond Tomcat, offering a holistic view of infrastructure performance, and includes a free trial for users to explore its functionalities.

In this series of posts, we discuss how to monitor Apache Tomcat using Java Management Extensions (JMX) and other tools. Part 1 covered key metrics exposed through JMX, while this post delves into collecting and querying that data. We explore using Tomcat Manager, enabling remote connections for JMX viewing metrics with other monitoring platforms like JConsole and JavaMelody, and customizing Tomcat server and access logs. By setting a few simple permissions, administrators can immediately begin viewing Tomcat and JVM data with Tomcat Manager. Once remote connections for JMX are enabled, tools like JConsole and JavaMelody can be used to monitor Tomcat data with simple graphical interfaces.

Tomcat Manager provides a web-based interface to manage applications and hosts, view Tomcat metrics, and query metric data through a JMX proxy servlet. To access the management interface, users need to assign the `manager-jmx` or `manager-gui` role(s) to their account by updating the `tomcat-users.xml` configuration file. The web-based interface offers various areas for viewing metric data, including server and application status pages, an application manager with diagnostic tools, a JMX proxy text-based interface, and views of Tomcat's server status page and access logs. Remote connections can be enabled for JMX viewing metrics with other monitoring platforms like JConsole and JavaMelody, requiring adjustments to the `jmxremote` configuration file. Tools like JConsole and JavaMelody offer graphical interfaces for querying and visualizing Tomcat and JVM data, providing more insight into server health and performance than the web-based interface alone. Customization of access logs can be achieved by configuring valves and logging properties in Tomcat's `logging.properties` file, allowing for fine-grained control over log output and format.

Apache Tomcat is a widely used open-source server for running Java-based web applications, developed by the Apache Software Foundation. Originally created by Sun Microsystems and donated to the foundation in 1999, Tomcat functions as a Java Servlet Container, supporting Java EE Servlet specifications and serving dynamic content through Java Server Pages (JSP) and Java servlets. It is favored for smaller applications due to its lightweight nature and ease of administration, running efficiently within a Java Virtual Machine (JVM). The architecture of Tomcat includes a Catalina server, services, connectors, and containers that process requests and manage workloads through worker threads. Tomcat can operate as both a standalone web server and in collaboration with Apache HTTP Server, using connectors like HTTP and AJP to handle requests. Monitoring key performance metrics such as throughput, thread pool utilization, errors, and JVM memory usage is crucial for maintaining Tomcat's efficiency, with tools like JMX providing insights into these metrics. Efficient management of thread and memory resources is vital to avoid bottlenecks and errors, ensuring Tomcat serves applications effectively.

The text discusses various tools that can be used to collect metrics from ActiveMQ messaging infrastructure, including ActiveMQ command line tools, the ActiveMQ Web Console, JConsole, Hawtio, and the statistics plugin and management message API. The tools are compared in terms of their capabilities, ease of use, and the types of metrics they provide. The text also covers how to configure and launch JConsole to view ActiveMQ metrics remotely, as well as how to use Hawtio to visualize timeseries graphs of metrics. Additionally, it introduces the statistics plugin and management message API, which allow for programmatically fetching metrics by sending and receiving JMS messages. Finally, the text highlights the importance of comprehensive monitoring of the entire messaging infrastructure, including producers, consumers, and infrastructure, to identify bottlenecks and troubleshoot performance issues.

ActiveMQ is a message-oriented middleware (MOM) system that allows for loose coupling of services in an application. It is a Java-based open-source project developed by the Apache Software Foundation and currently offers two versions: Classic and Artemis. ActiveMQ sends messages between client applications using standards-based, asynchronous communication. The broker routes each message through a messaging endpoint called a destination. Both ActiveMQ versions are capable of point-to-point messaging and publish/subscribe (pub/sub) messaging. The system implements the Java Message Service (JMS) API, which defines a standard for creating, sending, and receiving messages. ActiveMQ sends messages asynchronously, so consumers don't necessarily receive messages immediately. The producer's task is disconnected from the consumer's task of fetching it. This type of arrangement, in which clients function without knowledge of one another, is known as loose coupling. The benefits of loose coupling include high throughput, flexibility, and heterogeneity. Because the components of the ActiveMQ architecture are decoupled, you need to monitor producers, consumers, destinations, addresses, and brokers holistically to understand the context of any issues that may arise. Each message ActiveMQ sends is based on the JMS specification, and is made up of headers, optional properties, and a body. The content of an ActiveMQ message can be text or binary data. ActiveMQ uses memory to store messages awaiting dispatch to consumers, and each message occupies some memory until it is dequeued and delivered to a consumer. When producers are faster than consumers, ActiveMQ's memory use increases. ActiveMQ also writes messages to disk for storage. The system monitors several key metrics, including MemoryPercentUsage (Classic) / AddressSize (Artemis), ConsumerCount, ProducerCount, QueueSize (Classic) / MessageCount (Artemis), ExpiredCount (Classic) / MessagesExpired (Artemis), and various JVM metrics. These metrics can help you proactively maintain your messaging infrastructure, providing information you need to investigate errors, missing messages, and unexpected latency.