Skip to main content
Do checkout my poem section. You are going to love it.

CCMS (RZ20, RZ21)

Detailed Notes for CCMS (RZ20, RZ21) in SAP Basis

CCMS: Computing Center Management System

Purpose: The Computing Center Management System (CCMS) is SAP's integrated monitoring and alerting infrastructure. It provides a comprehensive set of tools for monitoring, managing, and alerting on the performance, availability, and health of the entire SAP system landscape, including ABAP and Java stacks, databases, operating systems, and even connected non-SAP components.

CCMS aims to provide a centralized monitoring solution, allowing Basis administrators to proactively identify and react to potential issues before they impact business operations.

RZ20: CCMS Monitor Sets

Purpose: RZ20 is the primary transaction for displaying the collected monitoring data and managing the alerts generated by CCMS. It organizes monitoring objects into a hierarchical structure called "Monitor Sets." Each monitor set focuses on a specific area of the SAP system.

Key Concepts and Structure in RZ20:

  • Monitor Sets: These are predefined or custom groupings of monitoring objects related to a specific area (e.g., "SAP CCMS Monitor Templates," "All Systems," "Dialog Overview").
  • Monitors: Within a monitor set, monitors are logical groupings of related MTEs (Monitoring Tree Elements).
  • Monitoring Tree Elements (MTEs): These are the individual measurable values or attributes that are collected and monitored. Each MTE has:
    • Value: The current reading (e.g., CPU utilization, number of active users, free space).
    • Status: A color-coded status indicating the health:
      • Green (Good): Everything is normal.
      • Yellow (Warning): A threshold has been exceeded, but it's not critical yet. Requires attention.
      • Red (Alert): A critical threshold has been exceeded, indicating an immediate problem. Requires urgent action.
    • Thresholds: Predefined limits that trigger Yellow or Red status.
    • Alerts: When an MTE reaches a Yellow or Red status, an alert is generated.
    • Analysis Method: A predefined action or transaction that can be launched from the MTE to analyze the problem in more detail (e.g., double-clicking a CPU MTE might open ST06).
    • Properties: Details about the MTE, including its collection method, thresholds, and assigned alert collectors.

Common Monitor Sets:

  • SAP CCMS Monitor Templates: Contains standard templates for various monitoring areas (e.g., Entire System, Database, Operating System, Workload, Background Processing).
  • Dialog Overview: Shows performance and workload of dialog work processes.
  • Operating System: Provides OS metrics similar to ST06.
  • Database: Monitors database performance, space, and availability.
  • Background Processing: Tracks background jobs, long-running jobs, failed jobs.
  • Enqueue: Monitors enqueue server statistics and lock entries.
  • Update: Monitors update records (similar to SM13).

Key Actions and Features in RZ20:

  • Displaying Monitors: Navigate through the tree structure to view MTEs and their current status.
  • Analyzing Alerts:
    • Open Alerts: View all currently open (unconfirmed) alerts.
    • Confirmed Alerts: View alerts that have been acknowledged by an administrator.
    • Alert Monitor: A central screen to manage alerts.
    • Confirming Alerts: Acknowledging an alert so it no longer appears as "open."
    • Alert Auto-Reaction Methods: Define automatic actions (e.g., sending an email, triggering an OS script, starting an SAP transaction) when an alert is triggered.
  • History: View historical values of MTEs.
  • Custom Monitors: Create your own monitor sets and MTEs tailored to specific requirements.
  • Drill-down: Double-click on an MTE to launch an analysis method (e.g., ST06, SM50, SE38).

Best Practices for RZ20:

  • Regular Monitoring: Integrate RZ20 into your daily monitoring routine. Focus on "Open Alerts" and critical monitor sets.
  • Proactive Approach: Use CCMS alerts to identify and address issues before they become critical.
  • Alert Management: Establish clear procedures for confirming, escalating, and resolving alerts.
  • Customize Thresholds: Adjust default thresholds to match your system's baseline and criticality.
  • Define Auto-Reactions: Automate responses to common, non-critical alerts (e.g., send informational emails).

RZ21: CCMS Technical Infrastructure

Purpose: RZ21 is the transaction used for configuring and maintaining the technical infrastructure of CCMS. This includes setting up data collection, defining methods, and managing agents.

Key Concepts and Configuration Areas in RZ21:

  • Methods: These define how monitoring data is collected and how alerts are handled.
    • Data Collection Methods: Programs or scripts that gather data for specific MTEs.
    • Analysis Methods: Programs or transactions launched to analyze an MTE.
    • Auto-Reaction Methods: Programs or scripts executed automatically when an alert triggers.
  • Method Assignments: Linking specific methods to MTEs.
  • Monitoring Agents (SAP Host Agent, CCMS Agents):
    • SAP Host Agent: The successor to older CCMS agents (sapccm4x, sapccmsr). It's an independent executable that collects OS-level data, database data, and other non-SAP specific information, and makes it available to the central monitoring system. It's usually installed automatically with the SAP kernel.
    • CCMS Agents (Legacy): sapccm4x (for ABAP/dual stack instances) and sapccmsr (for pure Java instances or non-SAP hosts). These are older and largely replaced by SAP Host Agent for new installations but might still exist in older landscapes.
    • CEN (Central Enqueue Server): One SAP system is typically designated as the Central Monitoring System (CEN) where all other systems register their monitoring data.
  • System Connections: Configuring which systems report data to the CEN.
  • Shared Memory: Managing the shared memory segment used by CCMS.
  • Rules and Filters: Defining rules for alert propagation and display.
  • Customizing MTEs: Creating new or modifying existing MTEs.

Important Configuration Steps/Considerations in RZ21:

  1. Setting up a Central Monitoring System (CEN):
    • Designate one stable, highly available SAP system as your CEN.
    • All other satellite systems (monitored systems) register with this CEN.
  2. Registering Systems and Agents:
    • Ensure SAP Host Agents are running on all monitored hosts.
    • Register these agents with the CEN system using saphostctrl or sapccm4x -R (for legacy agents).
    • Verify the connection in RZ21 -> "Topology" or "Agent for Remote Monitoring."
  3. Configuring Auto-Reaction Methods:
    • Crucial for Automation: Define scripts or programs to be triggered for critical alerts (e.g., send email to Basis team, restart a service, trigger a specific job).
    • Customization: Auto-reaction methods need careful testing.
  4. Adjusting Thresholds:
    • The default thresholds might not fit your specific system's normal behavior. Adjust them in RZ21 (or from RZ20 by navigating to the MTE properties) to avoid false positives or missing critical alerts.
    • Consider establishing a baseline of your system's performance metrics before setting thresholds.
  5. Monitoring Non-SAP Components:
    • CCMS can monitor external components (e.g., external databases, operating systems without an SAP instance) by installing and configuring sapccmsr (or SAP Host Agent for newer scenarios).
  6. Reorganization of Monitoring Data:
    • Ensure jobs like RSBPCOLL (for background processing) and RSAL_BATCH (for MTE value aggregation) are scheduled to run regularly for data collection.
    • Regularly reorganize old alerts and monitoring data to keep the database size manageable.

Relationship between RZ20 and RZ21:

  • RZ20 = Display & React: Used by daily users/administrators to view monitoring data, check alerts, and perform initial analysis.
  • RZ21 = Configure & Maintain: Used by Basis administrators to set up the monitoring infrastructure, define what is monitored, how it's collected, and how alerts are processed.

Important Configurations to Keep in Mind (CCMS)

  1. SAP Host Agent (or CCMS Agents):

    • Status: Ensure the SAP Host Agent is running on every host where an SAP instance resides or where you want to collect OS-level data. This is fundamental for data collection.
    • Version: Keep the SAP Host Agent updated. Newer versions support more OS features and provide better compatibility.
    • Registration: Correctly register the SAP Host Agent with your Central Monitoring System (CEN) using the saphostctrl command or relevant agent registration tools.
  2. Central Monitoring System (CEN):

    • Stability: The CEN system should be highly available and stable, as all monitoring data flows through it.
    • Resource Allocation: Ensure the CEN has sufficient CPU and memory resources to handle the incoming monitoring data and process alerts from all registered systems.
  3. Thresholds and Alerting:

    • Customization: Do NOT rely solely on default thresholds. Customize them based on your system's baseline and specific business requirements. Too many false alarms (noise) can lead to alert fatigue.
    • Alert Auto-Reaction Methods: Implement auto-reaction methods for critical alerts, such as sending emails to the Basis team, triggering specific corrective scripts, or creating tickets in an ITSM system. Test these methods thoroughly.
    • SMS/Paging: For critical systems, consider integrating with SMS or paging services for immediate notification of red alerts.
  4. Monitoring Collection Jobs:

    • Ensure the standard CCMS background jobs (RSBPCOLL, RSAL_BATCH_TOOL, etc.) are scheduled and running frequently on both the CEN and satellite systems to ensure up-to-date data.
    • RSBPCOLL: Collects background processing statistics.
    • RSAL_BATCH_TOOL: Processes monitoring data and aggregates it for history.
  5. Security and Authorizations:

    • Restrict access to RZ21 as it allows system-wide configuration changes.
    • Control access to specific monitor sets and alert confirmation in RZ20.
  6. CCMS Shared Memory:

    • Monitor the shared memory segments used by CCMS. Issues here can lead to data collection failures.
    • Parameter CCMS/SharedMemory/SizeMB defines the size of the shared memory for CCMS.
  7. System Time Synchronization:

    • Ensure all systems (CEN and satellite) have synchronized system times. Discrepancies can lead to inaccurate monitoring data and alert timestamps.

10 Interview Questions and Answers (One-Liner) for CCMS

  1. Q: What is the primary purpose of SAP CCMS?

    • A: To monitor and manage the entire SAP system landscape.
  2. Q: Which transaction code is used to display CCMS monitor sets and alerts?

    • A: RZ20.
  3. Q: Which transaction code is used for configuring the CCMS infrastructure?

    • A: RZ21.
  4. Q: What does a "Red" status for an MTE in RZ20 signify?

    • A: A critical threshold has been exceeded, requiring urgent action.
  5. Q: What is the role of the SAP Host Agent in CCMS?

    • A: It collects OS-level data and other non-SAP specific information.
  6. Q: What is a "Central Monitoring System (CEN)" in CCMS?

    • A: An SAP system designated to receive and process monitoring data from other systems.
  7. Q: What are "Auto-Reaction Methods" in CCMS?

    • A: Automated actions triggered when an alert occurs (e.g., sending an email).
  8. Q: How do you access historical monitoring data in RZ20?

    • A: Via the "History" option for an MTE.
  9. Q: What is the importance of customizing CCMS thresholds?

    • A: To avoid false positives and ensure relevant alerts.
  10. Q: Which background job is crucial for collecting background processing statistics for CCMS?

    • A: RSBPCOLL.

5 Scenario-Based Questions and Answers for CCMS

  1. Scenario: You receive a complaint that a critical background job failed, but you didn't receive any alert from CCMS. Upon checking RZ20, you find the background processing monitor set, but the specific job's status MTE is still green, even though the job failed an hour ago.

    • Q: What could be the potential reasons for the missed alert, and where would you investigate?
    • A:
      1. Data Collection Issue: The RSBPCOLL job (which collects background processing statistics) might not be running or might have failed. Check SM37 for RSBPCOLL job status.
      2. Threshold Misconfiguration: The threshold for the "Job Status" MTE might be incorrectly configured (e.g., only alerts on "Cancelled" but not "Aborted"). Check the MTE properties in RZ21 or RZ20 for the specific job status.
      3. Monitor Set Not Active/Configured: The relevant monitor set might not be active or properly configured to collect data for that specific job.
      4. Alert Auto-Reaction Method Missing/Failed: Even if the MTE turned red, the auto-reaction method (e.g., email notification) might be missing or failed. Check the alert log in RZ20 for the triggered alert and its associated auto-reaction status.
  2. Scenario: Your Basis team is overwhelmed with a large number of "Yellow" alerts for CPU utilization on several development and quality assurance systems, even though these systems are not experiencing noticeable performance issues.

    • Q: What is the most likely cause, and what steps would you take to address this "alert fatigue"?
    • A:
      • Cause: The default "Yellow" thresholds for CPU utilization are too low for the normal operating baseline of these specific systems, leading to false positives.
      • Steps:
        1. Analyze Baseline: Use ST06 (history) and RZ20 (history for the CPU MTE) to determine the normal CPU utilization patterns for these Dev/QA systems.
        2. Adjust Thresholds: In RZ21, navigate to the relevant CPU MTE for the Dev/QA systems and increase the "Yellow" threshold to a value that aligns with their normal, non-problematic peak usage.
        3. Consider Different Thresholds: If appropriate, create separate threshold profiles for Dev/QA vs. Production systems.
        4. Confirm Alerts: Confirm the existing "Yellow" alerts to clear the queue and reduce noise.
  3. Scenario: You have just set up a new application server in your landscape, and while you can log into it, its OS-level performance data (CPU, memory, disk) is not appearing in the "Operating System" monitor set in RZ20 on your CEN system.

    • Q: What is the primary component to check, and what configuration steps are likely missing?
    • A:
      • Primary Component: SAP Host Agent.
      • Missing Configuration Steps:
        1. SAP Host Agent Running: Verify that the SAP Host Agent is running on the new application server host (check OS processes or use saphostctrl -s). If not, start it.
        2. Agent Registration: The SAP Host Agent for the new application server has likely not been registered with your Central Monitoring System (CEN). You need to register it using the appropriate saphostctrl command with the CEN's message server details.
        3. CEN Connection: Ensure network connectivity from the new application server to the CEN system's message server port.
        4. Refresh Monitoring Data: After registration, it might take a few minutes for data to appear in RZ20; manually refresh the monitor set.
  4. Scenario: Your Basis team wants to be notified via email whenever an update record goes into "Error" status (as seen in SM13). They ask you to set this up using CCMS.

    • Q: What specific CCMS features would you use, and what is the high-level configuration approach?
    • A:
      • CCMS Features: MTEs for Update Status, Alert Auto-Reaction Methods (specifically for email).
      • High-Level Configuration Approach:
        1. Identify MTE: In RZ20, find the relevant MTE within the "Update" monitor set that tracks the status of update records (e.g., "Update Requests (V1/V2)" or similar).
        2. Define Auto-Reaction Method: In RZ21, create or modify an "Auto-Reaction Method" (e.g., an ABAP report like SALRT_EMAIL_SENDER or a custom script) that sends an email to the Basis team. Configure the email recipient, subject, and content.
        3. Assign Method: Assign this newly created or modified auto-reaction method to the identified "Update Status" MTE. Ensure it's assigned for "Red" alerts.
        4. Test: Intentionally create a failed update (e.g., via a test program) to verify that the email alert is triggered correctly.
  5. Scenario: The company has implemented SAP Solution Manager for central monitoring, and you need to ensure that all critical CCMS alerts from your satellite ABAP systems are forwarded to Solution Manager's Alert Inbox.

    • Q: How does Solution Manager integrate with CCMS for this purpose, and what key setup is required?
    • A:
      • Integration Method: Solution Manager uses a concept called "Managed Systems Configuration" and leverages the "Diagnostics Agent" (which incorporates SAP Host Agent functionality) on each satellite system. It pulls CCMS data from the satellite systems into its own monitoring infrastructure.
      • Key Setup Required:
        1. Diagnostics Agent Installation: Ensure the Diagnostics Agent is installed and running on each satellite ABAP system's host.
        2. Agent Registration to Solution Manager: Register the Diagnostics Agent of each satellite system with the Solution Manager system.
        3. Managed System Configuration (SOLMAN_SETUP): Perform the "Managed System Configuration" for each satellite ABAP system in Solution Manager's SOLMAN_SETUP transaction. This step involves specifying the system type, host details, and assigning the Diagnostics Agent.
        4. Activate Monitoring: Within Solution Manager (e.g., through Technical Monitoring workcenter), activate the relevant monitoring templates for the ABAP systems. This configuration will cause Solution Manager to regularly collect CCMS metrics and alerts and display them in its central Alert Inbox.

Comments

Popular posts from this blog

An experiment with the life

"Best Thing about experiment is that it only improves the outcome." Well, I am Rakshit, hope you already know. I am not special and surely not especially gifted. Neither things go according to my wish. Neither I am the best writer.  But I am myself who is totally unique from anyone else. And I am Rakshit Ranjan Singh. I have my own fun, fights and fall in the most fundamentalistic way. Mechanical is my degree. IT is my Job. Beauty in nature is what I search. Words of my heart are what I write. Four different things I carry on my shoulder and a smile on my face, hope you might have seen that. What do I care for? Family, friends and nature. Do I have regrets? More than I can imagine. Let us move further to see what really is my life.

Learn Java

Hello Friends, You might already know what Java is. Without taking much of your time, I would like to ask you to please click below if you are ready to learn it from end to end. The Material over here is available on the internet and is free to access.  I would request you to bookmark this page and follow it. Please comment if you are happy with the learning. click here

Driving

My Driving Journey: From Zero to (Almost) Hero! Hello everyone! I'm excited to share my ongoing adventure of learning to drive. It's been a mix of nervous excitement, hilarious near-misses, and the slow but steady feeling of progress. Buckle up, because here's a peek into my journey behind the wheel! The First Lesson: Clutch Confusion! My first time in the driver's seat was... memorable. Let's just say the clutch and I weren't immediate friends. Lots of jerky starts and a few stalls later, I began to understand the delicate dance between the pedals. My instructor was incredibly patient (thank goodness!). Mastering the Steering Wheel (Sort Of) Steering seemed straightforward enough, but navigating turns smoothly was a different story. I definitely had a few moments of feeling like I was wrestling with the wheel. Slowly but...