2019-02-24 // Check_MK Monitoring - SAP Cloud Connector
The SAP Cloud Connector provides a service which is used to connect on-premise systems – non-SAP, SAP ECC and SAP HANA – with applications running on the SAP Cloud Platform. This article introduces a new Check_MK agent and several service checks to monitor the status of the SAP Cloud Connector and its connections to the SAP Cloud Platform.
For the impatient and TL;DR here is the Check_MK package of the SAP Cloud Connector monitoring checks:
SAP Cloud Connector monitoring checks (Compatible with Check_MK versions 1.4.0p19 and later)
The sources are to be found in my Check_MK repository on GitHub
Monitoring the SAP Cloud Connector can be done in two different, not mutually exclusive, ways. The first approach uses the traditional application monitoring features, already built into Check_MK, like:
the presence and count of the application processes
the reachability of the applications TCP ports
the validity of the SSL Certificates
queries to the applications health-check URL
The first approach is covered by the section Built-in Check_MK Monitoring below.
The second approach uses a new Check_MK agent and several service checks, dedicated to monitor the internal status of the SAP Cloud Connector and its connections to the SAP Cloud Platform. The new Check_MK agent uses the monitoring API provided by the SAP Cloud Connector in order the monitor the application specific states and metrics. The monitoring endpoints on the SAP Cloud Connector currently used by this Check_MK agent are the:
“List of Subaccounts” (URL:
https://<scchost>:<sccport>/api/monitoring/subaccounts)“List of Open Connections” (URL:
https://<scchost>:<sccport>/api/monitoring/connections/backends)“Performance Monitor Data” (URL:
https://<scchost>:<sccport>/api/monitoring/performance/backends)“Top Time Consumers” (URL:
https://<scchost>:<sccport>/api/monitoring/performance/toptimeconsumers)
At the time of writing, there unfortunately is no monitoring endpoint on the SAP Cloud Connector for the Most Recent Requests metric. This metric is currently only available via the SAP Cloud Connectors WebUI. The Most Recent Requests metric would be a much more interesting and useful metric than the currently available Top Time Consumers or Performance Monitor Data, both of which have limitations. The application requests covered by the Top Time Consumers metric need a manual acknowledgement inside the SAP Cloud Connector in order to reset events with the longest request runtime, which limits the metrics usability for external monitoring tools. The Performance Monitor Data metric aggregates the application requests into buckets based on their overall runtime. By itself this can be useful for external monitoring tools and is in fact used by the Check_MK agent covered in this article. In the process of runtime bucket aggregation though, the Performance Monitor Data metric hides the much more useful breakdown of each request into runtime subsections (“External (Back-end)”, “Open Connection”, “Internal (SCC)”, “SSO Handling” and “Latency Effects”). Hopefully the Most Recent Requests metric will in the future also be exposed via the monitoring API provided by the SAP Cloud Connector. The new Check_MK agent can then be extended to use the newly exposed metric in order to gain a more fine grained insight into the runtime of application requests through the SAP Cloud Connector.
The second approach is covered by the section SAP Cloud Connector Agent below.
Built-in Check_MK Monitoring
Application Processes
To monitor the SAP Cloud Connector process, use the standard Check_MK check “State and count of processes”. This can be found in the WATO WebUI under:
-> Manual Checks
-> Applications, Processes & Services
-> State and count of processes
-> Create rule in folder ...
-> Rule Options
Description: Process monitoring of the SAP Cloud Connector
Checktype: [ps - State and Count of Processes]
Process Name: SAP Cloud Connector
-> Parameters
[x] Process Matching
[Exact name of the process without arguments]
[/opt/sapjvm_8/bin/java]
[x] Name of the operating system user
[Exact name of the operating system user]
[sccadmin]
[x] Levels for process count
Critical below [1] processes
Warning below [1] processes
Warning above [1] processes
Critical above [2] processes
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
Application Health Check
To implement a rudimentary monitoring of the SAP Cloud Connector application health, use the standard Check_MK check “Check HTTP service” to query the Health Check endpoint of the monitoring API provided by the SAP Cloud Connector. The “Check HTTP service” can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Active checks (HTTP, TCP, etc.)
-> Check HTTP service
-> Create rule in folder ...
-> Rule Options
Description: SAP Cloud Connector (SCC)
-> Check HTTP service
Name: SAP SCC
[x] Check the URL
[x] URI to fetch (default is /)
[/exposed?action=ping]
[x] TCP Port
[8443]
[x] Use SSL/HTTPS for the connection:
[Use SSL with auto negotiation]
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
SSL Certificates
To monitor the validity of the SSL certificate of the SAP Cloud Connector WebUI, use the standard Check_MK check “Check HTTP service”. The “Check HTTP service” can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Active checks (HTTP, TCP, etc.)
-> Check HTTP service
-> Create rule in folder ...
-> Rule Options
Description: SAP Cloud Connector (SCC)
-> Check HTTP service
Name: SAP SCC Certificate
[x] Check SSL Certificate Age
Warning at or below [30] days
Critical at or below [60] days
[x] TCP Port
[8443]
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
SAP Cloud Connector Agent
The new Check_MK package to monitor the status of the SAP Cloud Connector and its connections to the SAP Cloud Platform consists of three major parts – an agent plugin, two check plugins and several auxiliary files and plugins (WATO plugins, Perf-o-meter plugins, metrics plugins and man pages).
Prerequisites
The following prerequisites are necessary in order for the SAP Cloud Connector agent to work properly:
A SAP Cloud Connector application user must be created for the Check_MK agent to be able to authenticate against the SAP Cloud Connector and gain access to the protected monitoring API endpoints. See the article SAP Cloud Connector - Configuring Multiple Local Administrative Users on how to create a new application user.
A DNS alias or an additional IP address for the SAP Cloud Connector service.
An additional host in Check_MK for the SAP Cloud Connector service with the previously created DNS alias or IP address.
Installation of the Python
requestslibrary on the Check_MK server. This library is used in the Check_MK agent pluginagent_sapccto perform the authentication and the HTTP requests against the monitoring API of the SAP Cloud Connector. On e.g. RHEL based systems it can be installed with:root@host:# yum install python-requests
Installation of the new Check_MK package for the SAP Cloud Connector monitoring checks on the Check_MK server.
SAP Cloud Connector Agent Plugin
The Check_MK agent plugin agent_sapcc is responsible for querying the endpoints of the monitoring API on the SAP Cloud Connector, which are described above. It transforms the data returned from the monitoring endpoints into a format digestible by Check_MK. The following example shows the – anonymized and abbreviated – agent plugin output for a SAP Cloud Connector system:
<<<check_mk>>> Version: 0.1 <<<sapcc_connections_backends:sep(59)>>> subaccounts,abcdefghi,locationID;Test Location subaccounts,abcdefghi,regionHost;hana.ondemand.com subaccounts,abcdefghi,subaccount;abcdefghi <<<sapcc_performance_backends:sep(59)>>> subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,1,minimumCallDurationMs;10 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,1,numberOfCalls;1 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,2,minimumCallDurationMs;20 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,2,numberOfCalls;36 [...] subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,20,minimumCallDurationMs;3000 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,21,minimumCallDurationMs;4000 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,buckets,22,minimumCallDurationMs;5000 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,name;PROTOCOL/sapecc.example.com:44300 subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,protocol;PROTOCOL subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,virtualHost;sapecc.example.com subaccounts,abcdefghi,backendPerformance,PROTOCOL/sapecc.example.com:PORT,virtualPort;44300 subaccounts,abcdefghi,locationID;Test Location subaccounts,abcdefghi,regionHost;hana.ondemand.com subaccounts,abcdefghi,sinceTime;2019-02-13T08:05:36.084 +0100 subaccounts,abcdefghi,subaccount;abcdefghi <<<sapcc_performance_toptimeconsumers:sep(59)>>> subaccounts,abcdefghi,locationID;Test Location subaccounts,abcdefghi,regionHost;hana.ondemand.com subaccounts,abcdefghi,requests,0,externalTime;373 subaccounts,abcdefghi,requests,0,id;932284302 subaccounts,abcdefghi,requests,0,internalBackend;sapecc.example.com:PORT subaccounts,abcdefghi,requests,0,openRemoteTime;121 subaccounts,abcdefghi,requests,0,protocol;PROTOCOL subaccounts,abcdefghi,requests,0,receivedBytes;264 subaccounts,abcdefghi,requests,0,resource;/sap-webservice-url/ subaccounts,abcdefghi,requests,0,sentBytes;4650 subaccounts,abcdefghi,requests,0,startTime;2019-02-13T11:31:59.113 +0100 subaccounts,abcdefghi,requests,0,totalTime;536 subaccounts,abcdefghi,requests,0,user;RFC_USER subaccounts,abcdefghi,requests,0,virtualBackend;sapecc.example.com:PORT subaccounts,abcdefghi,requests,1,externalTime;290 subaccounts,abcdefghi,requests,1,id;1882731830 subaccounts,abcdefghi,requests,1,internalBackend;sapecc.example.com:PORT subaccounts,abcdefghi,requests,1,latencyTime;77 subaccounts,abcdefghi,requests,1,openRemoteTime;129 subaccounts,abcdefghi,requests,1,protocol;PROTOCOL subaccounts,abcdefghi,requests,1,receivedBytes;264 subaccounts,abcdefghi,requests,1,resource;/sap-webservice-url/ subaccounts,abcdefghi,requests,1,sentBytes;4639 subaccounts,abcdefghi,requests,1,startTime;2019-02-13T11:31:59.114 +0100 subaccounts,abcdefghi,requests,1,totalTime;532 subaccounts,abcdefghi,requests,1,user;RFC_USER subaccounts,abcdefghi,requests,1,virtualBackend;sapecc.example.com:PORT [...] subaccounts,abcdefghi,requests,49,externalTime;128 subaccounts,abcdefghi,requests,49,id;1774317106 subaccounts,abcdefghi,requests,49,internalBackend;sapecc.example.com:PORT subaccounts,abcdefghi,requests,49,protocol;PROTOCOL subaccounts,abcdefghi,requests,49,receivedBytes;263 subaccounts,abcdefghi,requests,49,resource;/sap-webservice-url/ subaccounts,abcdefghi,requests,49,sentBytes;4660 subaccounts,abcdefghi,requests,49,startTime;2019-02-16T11:32:09.352 +0100 subaccounts,abcdefghi,requests,49,totalTime;130 subaccounts,abcdefghi,requests,49,user;RFC_USER subaccounts,abcdefghi,requests,49,virtualBackend;sapecc.example.com:PORT subaccounts,abcdefghi,sinceTime;2019-02-13T08:05:36.085 +0100 subaccounts,abcdefghi,subaccount;abcdefghi <<<sapcc_subaccounts:sep(59)>>> subaccounts,abcdefghi,displayName;Test Application subaccounts,abcdefghi,locationID;Test Location subaccounts,abcdefghi,regionHost;hana.ondemand.com subaccounts,abcdefghi,subaccount;abcdefghi subaccounts,abcdefghi,tunnel,applicationConnections,abcdefg:hijklmnopqr,connectionCount;8 subaccounts,abcdefghi,tunnel,applicationConnections,abcdefg:hijklmnopqr,name;abcdefg:hijklmnopqr subaccounts,abcdefghi,tunnel,applicationConnections,abcdefg:hijklmnopqr,type;JAVA subaccounts,abcdefghi,tunnel,connectedSince;2019-02-14T10:11:00.630 +0100 subaccounts,abcdefghi,tunnel,connections;8 subaccounts,abcdefghi,tunnel,state;Connected subaccounts,abcdefghi,tunnel,user;P123456
The agent plugin comes with a Check_MK check plugin of the same name, which is solely responsible for the construction of the command line arguments from the WATO configuration and passing it to the Check_MK agent plugin.
With the additional WATO plugin sapcc_agent.py it is possible to configure the username and password for the SAP Cloud Connector application user which is used to connect to the monitoring API. It is also possible to configure the TCP port and the connection timeout for the connection to the monitoring API through the WATO WebUI and thus override the default values. The default value for the TCP port is 8443, the default value for the connection timeout is 30 seconds. The configuration options for the Check_MK agent plugin agent_sapcc can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Datasource Programs
-> SAP Cloud Connector systems
-> Create rule in folder ...
-> Rule Options
Description: SAP Cloud Connector (SCC)
-> SAP Cloud Connector systems
SAP Cloud Connector user name: [username]
SAP Cloud Connector password: [password]
SAP Cloud Connector TCP port: [8443]
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
After saving the new rule, restarting Check_MK and doing an inventory on the additional host for the SAP Cloud Connector service in Check_MK, several new services starting with the name prefix SAP CC should appear.
The following image shows a status output example from the WATO WebUI with the service checks HTTP SAP SCC TLS and HTTP SAP SCC TLS Certificate from the Built-in Check_MK Monitoring described above. In addition to those, the example also shows the service checks based on the data from the SAP Cloud Connector Agent. The service checks SAP CC Application Connection, SAP CC Subaccount and SAP CC Tunnel are provided by the check plugin sapcc_subaccounts, the service check SAP CC Perf Backend is provided by the plugin sapcc_performance_backends:
SAP Cloud Connector Subaccount
The check plugin sapcc_subaccounts implements the three sub-checks sapcc_subaccounts.app_conn, sapcc_subaccounts.info and sapcc_subaccounts.tunnel.
Info
The sub-check sapcc_subaccounts.info just gathers information on several configuration options for each subaccount on the SAP Cloud Connector and displays them in the status details of the check. These configuration options are the:
subaccount name on the SAP Cloud Platform to which the connection is made.
display name of the subaccount.
location ID of the subaccount.
the region host of the SAP Cloud Platform to which the SAP Cloud Connector establishes a connection.
The sub-check sapcc_subaccounts.info always returns an OK status. No performance data is currently reported by this check.
Tunnel
The sub-check sapcc_subaccounts.tunnel is responsible for the monitoring of each tunnel connection for each subaccount on the SAP Cloud Connector. Upon inventory this sub-check creates a service check for each tunnel connection found on the SAP Cloud Connector. During normal check execution, the status of the tunnel connection is determined for each inventorized item. If the tunnel connection is not in the Connected state, an alarm is raised accordingly. Additionally, the number of currently active connections over a tunnel as well as the elapsed time in seconds since the tunnel connection was established are determined for each inventorized item. If either the value of the currently active connections or the number of seconds since the connection was established are above or below the configured warning and critical threshold values, an alarm is raised accordingly. For both values, performance data is reported by the check.
With the additional WATO plugin sapcc_subaccounts.py it is possible to configure the warning and critical levels for the sub-check sapcc_subaccounts.tunnel through the WATO WebUI and thus override the following default values:
| Metric | Warning Low Threshold | Critical Low Threshold | Warning High Threshold | Critical High Threshold |
|---|---|---|---|---|
| Number of connections | 0 | 0 | 30 | 40 |
| Connection duration | 0 sec | 0 sec | 284012568 sec | 315569520 sec |
The configuration options for the tunnel connection levels can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Parameters for discovered services
-> Applications, Processes & Services
-> SAP Cloud Connector Subaccounts
-> Create Rule in Folder ...
-> Rule Options
Description: SAP Cloud Connector Subaccounts
-> Parameters
[x] Number of tunnel connections
Warning if equal or below [0] connections
Critical if equal or below [0] connections
Warning if equal or above [30] connections
Critical if equal or above [40] connections
[x] Connection time of tunnel connections
Warning if equal or below [0] seconds
Critical if equal or below [0] seconds
Warning if equal or above [284012568] seconds
Critical if equal or above [315569520] seconds
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
and/or
Application Or Tunnel Name [x]
Specify explicit values [Tunnel name]
The above image with a status output example from the WATO WebUI shows one sapcc_subaccounts.tunnel service check as the last of the displayed items. The service name is prefixed by the string SAP CC Tunnel and followed by the subaccount name, which in this example is anonymized. For each tunnel connection the connection state, the overall number of application connections currently active over the tunnel, the time when the tunnel connection was established and the number of seconds elapsed since establishing the connection are shown. The overall number of currently active application connections is also visualized in the perf-o-meter, with a logarithmic scale growing from the left to the right.
The following image shows an example of the two metric graphs for a single sapcc_subaccounts.tunnel service check:
The upper graph shows the time elapsed since the tunnel connection was established. The lower graph shows the overall number of application connections currently active over the tunnel connection. Both graphs would show warning and critical thresholds values, which in this example are currently outside the displayed range of values for the y-axis.
Application Connection
The sub-check sapcc_subaccounts.app_conn is responsible for the monitoring of each applications connection through each tunnel connection for each subaccount on the SAP Cloud Connector. Upon inventory this sub-check creates a service check for each application connection found on the SAP Cloud Connector. During normal check execution, the number of currently active connections for each application is determined for each inventorized item. If the value of the currently active connections is above or below the configured warning and critical threshold values, an alarm is raised accordingly. For the number of currently active connections, performance data is reported by the check.
With the additional WATO plugin sapcc_subaccounts.py it is possible to configure the warning and critical levels for the sub-check sapcc_subaccounts.app_conn through the WATO WebUI and thus override the following default values:
| Metric | Warning Low Threshold | Critical Low Threshold | Warning High Threshold | Critical High Threshold |
|---|---|---|---|---|
| Number of connections | 0 | 0 | 30 | 40 |
The configuration options for the tunnel connection levels can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Parameters for discovered services
-> Applications, Processes & Services
-> SAP Cloud Connector Subaccounts
-> Create Rule in Folder ...
-> Rule Options
Description: SAP Cloud Connector Subaccounts
-> Parameters
[x] Number of application connections
Warning if equal or below [0] connections
Critical if equal or below [0] connections
Warning if equal or above [30] connections
Critical if equal or above [40] connections
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
and/or
Application Or Tunnel Name [x]
Specify explicit values [Application name]
The above image with a status output example from the WATO WebUI shows one sapcc_subaccounts.app_conn service check as the 5th item from top of the displayed items. The service name is prefixed by the string SAP CC Application Connection and followed by the application name, which in this example is anonymized. For each application connection the number of currently active connections and the connection type are shown. The number of currently active application connections is also visualized in the perf-o-meter, with a logarithmic scale growing from the left to the right.
The following image shows an example of the metric graph for a single sapcc_subaccounts.app_conn service check:
The graph shows the number of currently active application connections. The graph would show warning and critical thresholds values, which in this example are currently outside the displayed range of values for the y-axis.
SAP Cloud Connector Performance Backends
The check sapcc_performance_backends is responsible for the monitoring of the performance of each (on-premise) backend system connected to the SAP Cloud Connector. Upon inventory this check creates a service check for each backend connection found on the SAP Cloud Connector. During normal check execution, the number of requests to the backend system, categorized in one of the 22 runtime buckets is determined for each inventorized item. From these raw values, the request rate in requests per second is derived for each of the 22 runtime buckets. Also from the raw values, the following four additional metrics are derived:
calls_total: the total request rate over all of the 22 runtime buckets.calls_pct_ok: the relative number of requests in percent with a runtime below a given runtime warning threshold.calls_pct_warn: the relative number of requests in percent with a runtime above a given runtime warning threshold.calls_pct_crit: the relative number of requests in percent with a runtime above a given runtime critical threshold.
If the relative number of requests is above the configured warning and critical threshold values, an alarm is raised accordingly. For each of the 22 runtime buckets, the total number of requests and the relative number of requests (calls_pct_ok, calls_pct_warn, calls_pct_crit), performance data is reported by the check.
With the additional WATO plugin sapcc_performance_backends.py it is possible to configure the warning and critical levels for the check sapcc_performance_backends through the WATO WebUI and thus override the following default values:
| Metric | Warning Threshold | Critical Threshold |
|---|---|---|
| Request runtime | 500 msec | 1000 msec |
| Percentage of requests over request runtime thresholds | 10% | 5% |
The configuration options for the backend performance levels can be found in the WATO WebUI under:
-> Host & Service Parameters
-> Parameters for discovered services
-> Applications, Processes & Services
-> SAP Cloud Connector Backend Performance
-> Create Rule in Folder ...
-> Rule Options
Description: SAP Cloud Connector Backend Performance
-> Parameters
[x] Runtime bucket definition and calls per bucket in percent
Warning if percentage of calls in warning bucket equal or above [10.00] %
Assign calls to warning bucket if runtime equal or above [500] milliseconds
Critical if percentage of calls in critical bucket equal or above [5.00] %
Assign calls to critical bucket if runtime equal or above [1000] milliseconds
-> Conditions
Folder [The folder containing the SAP Cloud Connector systems]
and/or
Explicit hosts [x]
Specify explicit host names [SAP Cloud Connector systems]
and/or
Backend Name [x]
Specify explicit values [Backend name]
The above image with a status output example from the WATO WebUI shows one sapcc_performance_backends service check as the 6th item from top of the displayed items. The service name is prefixed by the string SAP CC Perf Backend and followed by a string concatenated from the protocol, FQDN and TCP port of the backend system, which in this example is anonymized. For each backend connection the total number of requests, the total request rate, the percentage of requests below the runtime warning threshold, the percentage of requests above the runtime warning threshold and the percentage of requests above the runtime critical threshold are shown. The relative number of requests in percent are also visualized in the perf-o-meter.
The following image shows an example of the metric graph for the total request rate from the sapcc_performance_backends service check:
The following image shows an example of the metric graph for the relative number of requests from the sapcc_performance_backends service check:
The graph shows the percentage of requests below the runtime warning threshold in the color green at the bottom, the percentage of requests above the runtime warning threshold in the color yellow stacked above and the percentage of requests above the runtime critical threshold in the color red stacked at the top.
The following image shows an example of the combined metric graphs for the request rates to a single backend system in each of the 22 runtime buckets from the sapcc_performance_backends service check:
To provide a better overview, the individual metrics are grouped together into three graphs. The first graph shows the request rate in the runtime buckets >=10ms, >=20ms, >=30ms, >=40ms, >=50ms, >=75ms and >=100ms. The second graph shows the request rate in the runtime buckets >=125ms, >=150ms, >=200ms, >=300ms, >=400ms, >=500ms, >=750ms and >=1000ms. The third and last graph shows the request rate in the runtime buckets >=1250ms, >=1500ms, >=2000ms, >=2500ms, >=3000ms, >=4000ms and >=5000ms.
The following image shows an example of the individual metric graphs for the request rates to a single backend system in each of the 22 runtime buckets from the sapcc_performance_backends service check:
Each of the metric graphs shows exactly the same data as the previously show combined graphs. The combined metric graphs are actually based on the individual metric graphs for the request rates to a single backend system.
Conclusion
The newly introduced checks for the SAP Cloud Connector enables you to monitor several application specific aspects of the SAP Cloud Connector with your Check_MK Server. The combination of built-in Check_MK monitoring facilities and a new agent plugin for the SAP Cloud Connector complement each other in this regard. While the new SAP Cloud Connector agent plugin for Check_MK utilizes most of the data provided by the monitoring endpoints on the SAP Cloud Connector, a more in-depth monitoring could be achieved if the data from the Most Recent Requests metric would also be exposed over the monitoring API of SAP Cloud Connector. It hope this will be the case in a future release of the SAP Cloud Connector.
I hope you find the provided new check useful and enjoyed reading this blog post. Please don't hesitate to drop me a note if you have any suggestions or run into any issues with the provided checks.
2018-11-18 // SAP Cloud Connector - Configuring Multiple Local Administrative Users
Out of the box, the SAP Cloud Connector does not support the creation of multiple local users for administration purposes through its WebUI. The standard and documented way provides only the use of LDAP in conjunction with an external user directory in case multiple administrative users are necessary. This in turn introduces an unnecessary overhead and external dependency. It also has rather strict limitations on the names of the groups (admin or sccadmin) that can used to authorize users for administrative tasks in the SAP Cloud Connector. There is a simple workaround for this limitation, which will be described in this blog post.
Since the SAP Cloud Connector uses an embedded Tomcat servlet container as an application server, it also uses some of the infrastructure provided by Tomcat. This includes the local file-based user directory. In order to use multiple, distinctly named administrative users, they simply need to be manually added to this local file-based user directory.
The first step though, is to create a password hash that is compatible with the Tomcat servlet container. This can be accomplished with the use of the Tomcat command line tool digest.sh or digest.bat. Depending on your operating system this tool might have other names, e.g. /usr/bin/tomcat-digest on RedHat Enterprise Linux. On any system that has said command line tool available (e.g. on a RHEL 7 system with the RPM tomcat installed), run the following command:
user@host:$ /usr/bin/tomcat-digest -a sha-256 '<PASSWORD>'
Substitute the placeholder <PASSWORD> with the actual passwort that will be used for the new administrative user. The output of the above command will be in the form of <PASSWORD>:<HASH>. For the following step, only the <HASH> part of the output will be necessary.
The next step is to manually add the new adminstrative user to the local file-based user directory of the embedded Tomcat. This is achieved by editing the file config/users.xml in your SAP Cloud Connector installation. In this example the installation was performed in the standard path for Linux systems, which is /opt/sap/scc. Open the file config/users.xml in an editor of your choice:
root@host:# vi /opt/sap/scc/config/users.xml
Alter its contents by adding a new line, like shown in the following example:
- /opt/sap/scc/config/users.xml
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="admin"/> <group groupname="initial"/> <user username="Administrator" password="********" roles="admin"/> <user username="<USERNAME>" password="<HASH>" roles="admin"/> [...] </tomcat-users>
Substitute the placeholder <USERNAME> with the desired username of the new administrative user and substitute the placeholder <HASH> with the password hash generated above.
Restart the SAP Cloud Connector.
The newly created user should now be able to log in via the WebUI of the SAP Cloud Connector.
This kind of local file-based user directory is fairly simple to manage and to understand. I keep wondering why SAP would not document or even integrate this kind of user management in the WebUI of the SAP Cloud Connector. Another issue is the use of only one authorization role (admin or sccadmin), which is independent of the particular user directory used. This authorization role grants full administrative rights to the SAP Cloud Connector for a given user. A slightly more differentiated authorization scheme with roles for e.g. operations (connector restart and monitoring, no configuration changes) or monitoring (only monitoring, no connector restart, no configuration changes) purposes would be much more suitable for purposes in an enterprise environment.
