IBM Sovereign Core

IBM Sovereign Core

IBM Sovereign Core delivers a cohesive ready-to-run sovereignty software stack — combining an AI control plane, continuous compliance evidence, and governed agentic workflows across any hybrid environment.


#Automation
#AI
#Data
#Cloud
#Storage
 View Only

Running Sovereign Platforms: Observability and ITSM by Design

By Shikha Srivastava posted Thu April 30, 2026 05:45 PM

  

Authors: 

@Shikha Srivastava - Distinguished Engineer, Sovereign Core and MCSP, Master Inventor, IBM Software

@Ashwin B  - Observability and ITSM Lead

Overview 

  • Observability is key pillar in operational aspect to understand system behavior in production. Observability bundles three pillars - Monitoring, Logging & Tracing which becomes essential part of troubleshooting any customer escalations.  

As there are many vendors in this market with Opentelemetry standards given twist to adopt to vendor neutral solution & extend the flexibility to change the vendors. 

  • Organizations commonly encounter operational challenges when establishing observability infrastructure and ensuring high-quality data collection from deployed applications. Customers frequently deploy oversized observability stacks that ingest excessive amounts of data, or they adopt vendor solutions that require dedicated engineers to manage data volume and control licensing costs.
    Shape 

Solution Overview  

As the data volumes are huge, it was relooked at the adopt at the solution given by RH bundle which simplifies in planning, deployment & operational aspects which supports:

    • Simple data volume-based sizing configuration like 1x.demo,1x.extra-small”, etc.,.

    • Stack will be deployed automatically with flexibility to customize the configuration 

    • Adhere to well documented configuration changes which gives control in one place modify & the changes will be propagated to the agents  

    • RH managed images – so adhering the vulnerability governance by RedHat 

    • Easy to integrate the customer’s observability stack with simple configuration changes. 

    • CR based customizations to add or modify the dashboards 

    • Customization flexibility on Alert management & routing to onboard any On Call Management tool 

    • Flexibility to integrate the external SIEM tool. 

    • Customers bring the ITSM tool integration which would help the customer bring Incidents, change management as data & later it will be extended to support RCA, Notification managements on Incidents or release process. 

 

High-level components  

As Service Provider Cluster has the observability stack deployed by default with configuring Prometheus, Alert manager, Pre deployed dashboard/alerts of Service Provider services. Observability stack will be setup & configured done in such way 

 

  1. Application’s having service monitors will be auto scraped by Prometheus & would be able to search in the "OpenShift Console --> Observe --> Metrics UI".
  2. RH provided dashboards would be visible in "OpenShift Console  --> Observe --> Dashboard"
  3. RH provided operators the alerts will be auto deployed.
  4. Control plane service dashboards would be visible in "OpenShift Console  --> Observe -->Dashboard (Perses)"
  5. Deployed Alerts would be visible in "OpenShift Console  --> Observe -->Alerts"
    • User can look at the Alerts firing, Alerts definition or Alerts which needs to be silenced in separate tabs 
  6. All Discovered targets from Prometheus would be visible in OpenShift Console  --> Observe -->Targets
  7. Logs will be visible in OpenShift Console  --> Observe -->Logs
    • User can look Application, Audit & Infra logs by selecting in combo
    • User can apply filters (i.e., logQL) in the logs search filters
  8. Traces will be visible in OpenShift Console --> Observe -->Traces
    • User can select datasource & tenant (i.e., default tenant) to check the traces for the window
    • User can select the traces to drill down

Shape Sovereignty & customer Value 

  • As shown below the sovereign core components stays within the boundary set by Client. Observability stack provided by sovereign core stays within the OpenShift cluster boundary & so there will be no data movement unless configuration as part of customer changes like Alert notification, external SIEM integrations or using the customer observability stack.  

 

 

 

 

  • As Observability stack is deployed, the customer needs to focus mainly on deploying the instrumented Application’s so that metrics or traces shipped to observability stack. As opentelemetry complaint tool stack is deployed, the with auto or manual instruments the traces or metrics can be shipped by configuring the environment variables. As it is opentelemetry standards, the customer need not worry about the compatibility aspects with respect to Observability. 

  • Users have complete control over redeploying the observability stack with various configuration options, including scaling log or trace stack sizes, reviewing resource utilization and customization settings, and modifying data retention policies for metrics, traces, or logs. Additionally, users can apply granular controls to enable or disable logging at the namespace or pod level.  Based on the data volume, customer can change the configuration to scale up the infra components.

 

  • This simplifies deployment planning by aligning it with actual usage requirements. For example, for log management, the chart automatically selects the appropriate cluster type (e.g., 1x.x-small, indicating available cluster resources) based on log ingestion volume and required search latency. Components are then deployed with pre-configured sizing and tuning parameters optimized for the customer's data volume. 

 

 

Key Takeaways 

Customer responsibility to:  

  • Instruments the application code with Opentelemetry standards to metrics & traces
  • Defining operational criteria with respect failure metrics or logs-based alerts
  • Provide the necessary object storage & resources like CPU, memory & storage including block + object storage as per recommendation guide. 
  • Ease of operation
  • The pipeline automatically sets up and configures the Observability stack, eliminating the need for manual initial setup. 
  • Users need only minimal configuration adjustments based on log volumes, selecting from predefined size options like "1x.demo" or "1x.extra-small" for logs and traces." 

 

Demo Dashboard Video

 

Links to Sovereign Core to Learn More:




0 comments
62 views

Permalink