Introduction  

In the world of software applications, observability allows you to understand what’s happening inside your applications and infrastructure by examining the most important signals from telemetry data: logs, metrics, traces, and application flows.  

Instana is IBM’s real-time full-stack observability solution. This enterprise-ready platform has gained widespread adoption and trust among organizations worldwide due to its comprehensive monitoring capabilities.

As IBM Software Hub (SWH) deployments grow in scale and complexity, understanding application behavior becomes critical. With increasing customer demand for better observability, integrating Instana support into SWH and its services became a strategic priority. Having completed Instana integration across our core services, we now officially offer Instana support in SWH 5.3.

Click the name and you are now at the Kubernetes level summary view showing more details, including stats such as “CPU/Memory requests,” “CPU/Memory limits allocation,” and “Pods allocation” in percentages, and some graphs with historical data for the same metrics in absolute numbers. 

Cluster list view

The Kubernetes platform page displays all clusters connected to your Instana server. In this example, 31 clusters are monitored by the shared Instana instance. The list view provides high-level information for each cluster:

• Number of nodes
• Number of services
• Number of pods
• Health status indicator

Cluster detail view

Click on your cluster name to access the detailed Kubernetes cluster overview. This view displays:

Resource allocation metrics (percentages):

• CPU requests
• Memory requests
• CPU limits
• Memory limits
• Pod allocation

Historical trends (absolute values):

Time-series graphs show the same metrics over time, allowing you to identify patterns and potential resource constraints.

Tip: Use the percentage metrics to quickly assess resource utilization, and refer to the historical graphs to understand trends and plan capacity.

 

Exploring cluster details

Additional tabs at the top of the page provide deeper insights into your cluster. For example, the Nodestab displays detailed metrics for each node, including resource utilization, capacity, and health status on each node.

Other available tabs include Namespaces, Deployments, Pods, Services, and Events—each offering specific views into different aspects of your cluster.

 

Viewing service pods

The Pods tab lists all running pods with status, resource usage, and restart counts. To examine a service specifically in SWH:

1. Filter by the Namespace column
2. Select your SWH namespace (e.g., zen)
3. Click a service pod to see more details of the pod

Note: The SWH namespace name may vary based on your installation configuration.

 

Persistent Volumes tab: storage monitoring

The Persistent Volumes tab provides critical storage metrics for your cluster:

• Capacity: Total storage allocated to each PV
• Usage: Current storage consumed (in MiB/GiB) 
• Utilization: Percentage of capacity used

Monitoring storage health

Sort by the Utilization column (descending) to quickly identify volumes approaching capacity limits. High utilization (>80%) may indicate the need for:

• Storage expansion
• Data cleanup or archiving
• Investigation of unexpected growth

Why this matters for SWH
Many services (databases, logging, data stores) in SWH rely on persistent storage. Monitoring PV utilization helps prevent service disruptions due to storage exhaustion.

 

 

Viewing all services

Access the complete services list via either:

• Click View all services in the Summary view, or
• Select the Services tab at the top of the page

Sorting by metrics: the Services tab displays multiple metrics including latency, call volume, and error counts. Click any column header to sort by that metric (click again to reverse order).

Example: to find services experiencing the most failures, click the Erroneous calls column header to sort in descending order, the services with the highest error counts appear at the top.

In the example shown in the screenshots below , runtime-manager-api-container shows the highest error count, indicating it requires investigation.

 

 

Click the service name of your interest from the above view. A summary view for one service is shown, similar to the service level overall summary view, but now only for the “runtime-manager-api-container” service, an example as shown below: 

 

Endpoint level analysis

For deeper insights, Instana provides endpoint-level metrics and latency breakdowns showing performance across the entire call stack. Click Analyze Calls marked by the red arrow in the above screenshot, you will see a list of sections grouped by endpoint name for the selected service. In this example, runtime-manager-api-container shows 10 endpoint groups, sortable by:

• Call volume
• Latency (mean, p95, p99)
• Error rate

The error rate graph (center, top section) reveals that the GetJob endpoint experienced 100% errors between 11:00 AM and 12:00 PM, indicating complete service failure during that interval. These failures contribute to the 8.17% overall error rate shown in the endpoint list, calculated across the entire time window.

 

Click the GetJob group, and the section will open to show all the endpoint API calls so we can understand why there is an 8.17% failure rate. 

Based on the view below, sorted by timestamp in descending order, you can see a noticeable pattern: starting from 11:37:09, above the red line, all the calls took more than 60 seconds to complete, which seems to indicate timeout errors with a 60-second timeout setting, while the rest of the entries before that timestamp seem to have normal latency. 

Now let's drill down to the individual end point calls.  Click the `GetJob` endpoint group to expand and view all individual API calls to investigate the root cause of the 8.17% error rate.  Sorting by timestamp (descending) reveals a clear pattern:

• After 11:37:09: All calls exceeded 60 seconds, indicating timeout failures (likely a 60-second timeout configuration)
• Before 11:37:09: Calls completed with normal latency (typically under 5 seconds)

This pattern suggests a sudden performance degradation starting at 11:37:09, causing all subsequent requests to time out.

 

To further investigate the root cause for the sudden performance degradation:  

1. Click any timed-out call to view its trace
2. Examine the call stack to identify slow components or any error details

The example below shows “Internal Server Error” in the “Logs” section. This further confirms that some services are no longer available, causing the failures.  Potential causes for such failures could include the following but will need additional investigation to confirm further:

• Database query delays
• External service dependencies
• Resource contention (CPU, memory, I/O)
• Network issues

 

Next, the service call flow visualization maps dependencies and communication patterns between services, making it easy to:

• Trace request paths across multiple services
• Identify performance bottlenecks in service chains
• Understand cascading failure impacts

 

To view the service dependency diagram, switch from the Summary tab to the Flow tab at the top of the page. The Flow view displays an interactive visualization showing:

• Service dependencies and relationships
• Call direction and volume
• Latency at each service hop
• Error rates across the service chain

This diagram helps you trace request paths and identify where delays or failures occur in multi-service transactions.  

 

This example shows a simple service flow. In practice, some services in SWH have far more complex dependency and flow graphs with much more interconnected services. 

Cluster level events  

You can access cluster events view by clicking Events in the left sidebar, which will lead you to the Incidents dashboard, which displays alerts and anomalies across all monitored clusters. If you monitor multiple clusters, use the filter dropdown (top of page) to narrow the view to your specific cluster. This helps you focus on relevant incidents without noise from other environments.

 

There are other tabs for different events that may be helpful to explore, but they are beyond the scope of this introductory blog post. 

Want to see Instana in action? Check out our quick start demo.

Conclusion 

Instana provides comprehensive real-time observability for IBM Software Hub deployments, from infrastructure monitoring to API-level performance analysis. While Instana offers extensive advanced features, this guide focused on essential capabilities to help you get started:

• Cluster-level monitoring: Infrastructure health and resource utilization
• Service-level analysis: Performance metrics, error rates, call flows and dependencies
• Endpoint diagnostics: API latency breakdowns and call tracing
• Event tracking: Incident detection and alerting

Instana integration enables SWH customers to:

• Proactively identify issues before they impact users
• Quickly diagnose bottlenecks and root causes
• Reduce mean time to resolution (MTTR)
• Minimize downtime and operational costs
• Gain unified visibility across the entire stack