Monitoring Generated Services¶
Use logging and metrics to monitor your generated OData service.
Logging¶
For simple logging configuration with good log readability of logs,
see the -console:log,
-log:debug and
-log:trace options in your server-log.options file.
Caution
Using the TRACE log level, and to a lesser extent the DEBUG log level, may result in personal or sensitive
information being included in the server application's log files. It may also result in performance issues,
or out-of-disk-space conditions. Once your application is tested and ready for production,
you may need to use a reduced log level (such as INFO, WARN, or ERROR) to ensure compliance with the
EU General Data Protection Regulation or other applicable regulations. If you temporarily
enable logging for diagnostic purposes in a system that stores sensitive or personal information, regulations may
dictate that you retain the log files only for the minimum period required for the purposes of such diagnostic
activities. Transmitting log files outside the administrative boundaries of the regulations (for example for
technical support purposes) might be prohibited.
If you've used the deploy-mobile-server or preview-mobile-server tasks, a log file automatically appears in your project's logs folder. The generated .gitignore file prevents these logs from being checked into a Git repository.
For a simple logging setup with SAP Business Technology Platform – Cloud Foundry, use the following command to get a complete log file containing the last gigabyte of log messages since the server's last restart. This approach is especially helpful during development. It avoids the complexity of SLF4J-based logging configurations and ensures a log file optimized for human readability without losing any log messages
(unless the server is stopped or restarted). Be sure to check the -log:size option.
cd logs
cf ssh "<appname>" -c "tail -c 100000000 -f ~/logs/console.log" > "<appname>.log"
Note
If the server is stopped, the console.log file will be inaccessible, and if the server is restarted, the console.log file will be cleared (but accessible).
See the SLF4J options below for logs that can survive even if the server is stopped or restarted.
The above command requires ssh to be enabled for your Cloud Foundry app. See the -cf:ssh option in build-cloud.options, cf ssh-enabled, and cf enable-ssh.
-
When the
-cf:sshoption is added, the service should be rebuilt/redeployed for that change to take effect. -
When
cf enable-sshis used, the service should be restarted for that change to take effect.
SLF4J Logging Configuration (Local Server)¶
If the -console:log option is not used,
the generated main servlet class declares an SLF4J application logger.
-
The application's logger name is
odata.server. -
Configure the logger with the
DEBUGlog level to get basic request and response information (e.g. URL and status). -
Configure the logger with the
TRACElog level to get detailed request and response information (e.g. headers and payload).
See SLF4J for more details, and consult your application server documentation.
SLF4J Logging Configuration (SAP Business Technology Platform – Cloud Foundry)¶
If the -console:log option is not used,
the generated main servlet class declares an SLF4J application logger.
The remainder of this section assumes that you have installed the Cloud Foundry command-line tools. You can also view the logs from the SAP Business Technology Platform Cockpit.
To set up SLF4J for monitoring for your generated OData service:
-
By default, the generated
manifest.ymlenables theINFOlog level. Change the log level toDEBUGorTRACEas required, then rebuild and redeploy the application. -
Test your application, then use the
cf logscommand to download logs as required:-
Download recent logs for your application using:
cf logs --recent myapp -
Stream logs as they are produced using:
cf logs myapp
-
-
See Configure a Java Application for Logs and Traces for further details and options.
Metrics¶
The generated OData service includes an embedded metrics OData service for use by administrators.
Metrics are collected and aggregated according to the SAVE_METRICS_EVERY_PERIOD parameter in the generated MetricSettings class, which is one hour by default. The accepted values for this parameter are: 1 day (for example, P1D), N
hours where 24 mod N = 0 (for example, PT1H), or N minutes where 60 mod N = 0 (for example, PT5M). Metrics are
automatically retained in your SQL database in accordance with the RETAIN_METRICS_FOR_PERIOD parameter, which is seven days by default.
Newly collected metrics are available only at the end of each aggregation period, for example at the end of each hour.
To access metrics, append /admin/metrics to the main service root URL, followed by one of these read-only entity set names:
history, recent, or last. For example, if you deployed a test application in the SAP Business Technology Platform Cloud Foundry
environment, and wanted to collect metrics for it, you'd use the following URLs:
-
https://insert-your-host-info-here/admin/metrics/history– all available metrics that have not yet been deleted according to theretainMetricsForparameter. -
https://insert-your-host-info-here/admin/metrics/recent– metrics for the last five completed aggregation periods. -
https://insert-your-host-info-here/admin/metrics/last– metrics for the last completed aggregation period.
Use regular OData URL conventions to filter or select metrics.
You can look at metrics in HTML format using a browser client, or by appending ?$format=html to the URL.
This allows you to conveniently access the metrics via HTML import into spreadsheet software.
When security is enabled, the metrics are available only to users with appropriate roles. Administrators with direct access to the SQL database can also find the metrics in the database table with name <appname>_xs_data_metrics_<version>.
Note
Metrics are primarily provided for SQL database operations and back-end system interactions;
when you are using the in-memory database
(-imdb option), metrics might be available.