Deploying RTView in Docker Containers

Application Monitoring, Developer's Corner

Recently, there has been increasing excitement about Docker, an open platform for the distributed and automated deployment of application services. Docker takes advantage of the powerful Linux “container” technology that has been around for a long time, but not widely used until now.

The modular architecture and lightweight footprint of RTView makes it perfectly suited for deployment in this environment. In this blog, I describe briefly how RTView operates in containers managed by Docker — and can monitor user applications deployed in other containers.

There are many sources of information about Docker, especially the Docker web site. The page What is Docker ? has nice diagrams and explains why Docker deployment is so much more efficient than a Virtual Machine model. Many organizations, including Red Hat, are actively supporting and promoting the use of Docker containers. This is a good indication that the technology is rapidly maturing and becoming mainstream.

Deploying RTView Modules in Docker

RTView is designed for monitoring and analyzing performance and resource utilization of the middleware and infrastructure behind large-scale critical business applications. It is well-suited for deployment with Docker because its fundamental functions are highly modularized and designed for distributed deployment across multiple data centers and all levels of the technology stack. RTView balances the monitoring load, as well as its analysis and archival functions, using configurable lightweight processes deployed close to the target systems. Docker provides a mechanism by which these modules are easily configured and deployed across the entire application estate.

Each instance of an RTView module, such as a DataServer, DisplayServer, or Historian, is deployed in its own container. Properties defining data connections, ports, or other variables may be supplied in configurable data volumes, or can be accessed from a shared database table. Docker manages the life cycle of RTView containers, installing them on target hosts, and starting or stopping them.

Configuring RTView Images

In Docker, the unit of deployment is the “image”, a bundle that includes a small OS instance, combined with all code and data necessary to run a single application or component service. In the case of RTView, an image consists of the OS, a Java run-time, client jars for connecting to target systems, and specific modules of the RTView data or visualization engine.

RTView modules work well with the layered approach that Docker implements. The RTView core module can be configured as a shared container, and layered with “solution packages” that address the various technologies to be monitored. Multiple solution packages can be combined as needed into a single container where appropriate. This approach makes it possible to assemble small footprint images out of many component modules that implement specific functions.

Managing the Life Cycle of RTView Containers

Once RTView images are defined and built, multiple instances may be created and deployed to containers running in any virtual machine running the Docker daemon. RTView provides additional scripting functionality that wraps around Docker, batching relevant commands to install, update, start, stop, and remove RTView services on target hosts.

An RTView service is defined as a specific RTView image type, along with environment variables and named property sets that control its connections to target systems or other RTView services. Changes may be made to property sets and applied to running RTView services by issuing commands to process property changes and modify the behavior of the service.

A big benefit in using the container approach provided by Docker is that all RTView service deployment can be controlled from a central console, without ever having to connect remotely to the target deployment systems. All file transfer and management of service state is handled by Docker. Individual containers may be updated quickly, due to their smaller size, without the overhead of transferring a large virtual machine image.

Challenges With Docker

The use of any new technology usually comes with challenges. So it is with Docker. Facilitating the automated, containerized, and distributed deployment of large scale application components is great idea. But there are practical considerations.

Docker is early in its maturity cycle. There are incomplete features, as well as known issues around stability of new releases. However, so many large organizations are supporting this new model that one must expect the situation to rapidly improve, making Docker fully suitable for use in production environments.

There are also many side projects and viable alternatives to Docker. It is difficult to know which of these will eventually surface and become standard. For example, many users supplement Docker with systemd and fleet, tools to organize and load balance large arrays of container processes. These can be useful, but are not essential when deploying RTView in Docker, as the supplied RTView scripts provide much of the required functionality.

The Future

At SL Corporation, work is under way to make deployment of RTView in Docker containers a standard product feature, for use where it is appropriate. In addition, an RTView Solution Package is being developed that will provide support for monitoring and analysis of the performance data and resource utilization of the containers in which application components are deployed. This will provide RTView users the ability to correlate the behavior of application services with the underlying VMs and containers on which they are running.

You can see the news article about Red Hat’s support of Docker by going to Red Hat Announces Enterprise-Ready Containers.

More information about the benefits of using RTView Enterprise Monitor with Docker can be found at SL Corporation’s website