The name JENNIFER Kubernetes can suggest a product concerned mainly with Kubernetes infrastructure. Its focus, however, is the application: how a request is processed, where it slows down and what happened when an error occurred.
Those are the questions JENNIFER has long addressed through application performance monitoring. Kubernetes changes the environment in which engineers investigate them.
The application has a different operating environment
Enterprise web applications have run on application servers such as WebLogic, WebSphere, JEUS, Tomcat and JBoss. In these environments, JENNIFER has followed application transactions and brought together response times, throughput, SQL activity and external calls.
As applications move to Kubernetes, engineers still need to understand slow requests and errors. They also have more surrounding activity to consider. An application can run across several Pods, and those Pods can be created or removed as the system changes.
A performance problem may involve the application code, a Pod’s condition or the resources available to it. A deployment or restart may also coincide with the problem. Seeing the transaction alongside that context helps engineers decide what to investigate.
Connect the transaction to the Pod
Start with the request that slowed down. Which Pod handled it? What was happening to the application and its environment at that time?
The transaction shows the application work recorded for the request. Pod information, resource metrics and operational events provide context for interpreting it. For example, engineers may need to look at CPU or memory conditions alongside an application slowdown, or examine when a deployment or restart occurred.
These observations need to be considered together. A change in a metric or an event at the same time as a slow request is a reason to investigate further, rather than proof of the cause.
Keep the investigation centered on the application
JENNIFER’s work in Kubernetes extends its application monitoring focus into the environment where the application runs. The purpose is to help engineers relate transaction behavior to the relevant Pods and operational conditions.
That expands the question an engineer can ask. Alongside “What happened to this transaction?” comes “Where did it run, and what was happening around it?”
The distinction matters when evaluating the product. Kubernetes information is useful here because it helps explain an application problem. JENNIFER’s focus remains the request and the work performed to serve it.
The same questions in a changing environment
Application environments have moved through physical servers, virtualization and containers. The questions facing the people who operate services remain familiar. Are requests completing normally? Where is a request spending its time? What evidence helps explain an error?
JENNIFER Kubernetes brings the application’s operating context into that investigation. The aim is to make it easier to understand an application running on Kubernetes while keeping transaction analysis at the center.