It's time for the SAP Monitoring challenge! How to monitor ANY and ALL of the following in minutes, WITHOUT knowing anything about SAP Solution Manager, CCMS or any vendor tools? Simple, IT-Conductor does all the work using cloud-based automation, so you don't have to, YES, we'll even manage the monitoring services so all you have to do is relax and use it!
A pulse check with our SAP subscribers to see if they have implemented SAP Solution Manager 7.1 technical monitoring or are folks still waiting for the promised SAP Solution Manager 7.2? Well if you're waiting, then maybe you shouldn't because according to this SCN blog Whats new in SAP Solution Manager 7.2? it's been delayed until at least Q2 2016, and it doesn't look like there's much in the roadmap that greatly enhances technical monitoring or automation.
A common SAP technology stack for Business Intelligence that we've come across in the field has been SAP Business Warehouse (BW) backend as the enterprise data warehouse platform, with a BusinessObjects (SAP BOBJ) Business Intelligence (BI) reporting application. Performance testing, monitoring and tuning in such environment requires the setup of tools that will monitor the BOBJ as well as the BW system. This has to be part of any performance and availability management project involving the environment described above. We previously covered the technical monitoring setup using SAP Solution Manager in SAP NW on HANA Monitoring Setup (Preparation, Managed System Configuration and Technical Monitoring). The next series of 3-parts blog we will detail the setup for SAP BOBJ Monitoring in Solman 7.1
This last part we will hook up the 2 components of a SAP BOBJ BI 4.0 environment to the SAP Solution Manager, using Managed System configuration and Technical Monitoring by assigning the products and logical components.
Continuing on after installing the SAP Diagnostics Agent on the BI 4.0 system, we will use the AC (Auto-Configure) tool to step through the setup of SAP BOBJ and its various components to enable their integration and instrumentation for monitoring SAP Business Intelligence including:
- Wily Introscope
- SAPOSCOL (SAP Operating System Collector)
- Tomcat web server
In a prior blog we provided some tips on Managing HANA memory. In this article we will further explore the improvement with ESS (Embedded Statistics Service) available on HANA from SPS 7 revision 74 or higher. As a quick recap, memory consumption by the hdbstatisticsserver can be heavily impacted by the volume and frequency of various statistics collected by the HANA statistics engine, mainly the columnar tables in _SYS_STATISTICS schema. These tables provide stats for monitoring by tools such as the HANA Studio, SAP DBA Cockpit and Solution Manager, as well as external SAP management tools like IT-Conductor and HANA Management Pack for SCOM.
We've had the opportunity to work with HANA both as a Startup porting our application to HANA as well as with our SAP customers running HANA in production scale BW or ECC environments. In the R&D environment we have limited hardware capacity and thus resources, especially memory is always a constraint, so we learnt ways to monitor, and automate to optimize our performance and use of the system. In the customers' production environment, we have seen original architecture plans double in nodes and/or memory before they even got to performance testing phase.
SAP has a pretty catchy new spin since 2014 with the slogan “Run Simple”, well maybe for the business and end-users, but as far as the Basis team is concerned, managing the sprawling SAP landscapes and lifecycle is anything but simple. In my experience, the move to newer SAP technologies (such as HANA, Sybase, BOBJ, virtualization, cloud, etc.) has proliferated more requirements and demands on the Basis, Infrastructure and IT Operations teams. One example of this includes new deployments of SAP HANA which may scale out a Production environment up to 16 nodes. That is anything but simple. But I’ll play along that if you consolidated all your SAP environments into this huge HANA cluster, then it may look simple like in the old days when there was only R/3 and everything ran on it. However, if you’re going to put all your eggs into one basket, then you’ll need to protect it with a Business Continuity strategy for HA and DR which would no doubt be very complex.
As far back as I can remember, and that's more than 20 years working in SAP Basis, since the days of R/3, there's always been this 2 second average response time per dialog step (or simply 2 second response) benchmark as acceptable performance of an SAP OLTP system. Depending on the customer, some will tweak that to fit their business, and I have seen it range from 0.5 second to as high as 5 seconds. Honestly, it's a misleading indicator of performance because on any given mid-size SAP ECC production system with about 500 concurrent users, that number quickly becomes a useless measure with more transaction mix between SAP and custom code. To put it into perspective, a system may have a 0.5 second response time, but there are constant complaints from users with bad response times. Why? It's the law of averages. The more number of small transactions there are (those who run relatively quick), the more they bring down the system average into an attractive average response time, even though there are transactions that run forever and frustrate the hell out of those users who need to run them as part of their daily business process. It's because dialog steps are not created equal.
This week we finally see the results of all the work we put in to Solution Manager 7.1 from system preparation through to technical monitoring. Although no two SAP environment are exactly the same, even though they maybe based on the same products and installed in identical manners, hopefully you have a good sense of what it takes to get technical monitoring up and running in Solman. Unfortunately, no amount of SAP documentation or guided procedures can give you the same sense as actually doing it or follow along an actual implementation, so we encourage you to try it yourself, or use our example here to gauge and plan for such efforts since it's not trivial.
To recap the other 2 parts leading up to this final setup and demo, we completed:
- Netweaver on HANA Monitoring Setup Part 1 of 3 (Preparation)
- Netweaver on HANA Monitoring Setup Part 2 of 3 (Managed System Configuration)