Remote controlled client-side log collection
Logging is the instrumentation of source code that uses API calls to record messages in order to facilitate diagnostics and debugging. Example:
java.util.logging in Java.
Logging libraries typically have verbosity controls, that are frequently called levels. From least to most verbose: ERROR, WARN, INFO, LOG, DEBUG
- Developers can filter by level in their log viewer.
- Capture tools can filter by level in their configurations.
This tutorial covers the following topics:
- Log capture
- Server preparation (in production)
- Admin control for client logs
- Crash capture
- For more information
- API calls for specific environments
Log capture is the ability to persistently record messages that are passed to the logging API.
Capture is on by default but can be turned off.
Logging defaults to DEBUG level in development, and to FATAL in production. You can control levels, and therefore verbosity, with API calls that are specific to your environment.
Server preparation (in production)
It is useless to persistently capture log output in browsers and devices in production unless that captured data can be sent for diagnostic inspection. You can send captured data by calling the send method explicitly in your application.
You can turn the automatic behavior on or off with API calls that are specific to your environment, or by calling the
send method explicitly in your application.
How to receive and process logs at the server?
There are two ways to receive client logs on MobileFirst Server:
- Install the IBM MobileFirst Platform Operational Analytics (MobileFirst Operational Analytics for short).
- Develop and deploy an adapter that is named
WLClientLogReceiverwith a function (procedure) that is named
The MobileFirst Operational Analytics is available by default in the embedded Liberty server in the MobileFirst Studio development environment. You can open the Analytics Console from the MobileFirst Operations Console. When MobileFirst Operational Analytics is properly installed and configured, client logs that are sent to MobileFirst Server are automatically forwarded to MobileFirst Operational Analytics.
For more information about installing MobileFirst Operational Analytics in a production environment, see the topic about installing MobileFirst Operational Analytics, in the user documentation.
If you do not wish to use MobileFirst Operational Analytics, you can still collect and process client logs by creating an adapter. By default, MobileFirst Platform Foundation is configured to forward client logs to an adapter named
WLClientLogReceiver, which exposes a method called
If MobileFirst Operational Analytics and the adapter have both been configured, MobileFirst Platform Foudation sends logs to both endpoints. Using both may be useful if you want to take benefit of MobileFirst Operational Analytics log searching capabilities AND do some custom operations on client logs by using your own adapter.
Note: Installation and configuration of MobileFirst Operational Analytics and development of adapters is beyond the scope of this Getting Started tutorial. For more information, see the topic about installing MobileFirst Operational Analytics, in the user documentation, and the Adapters overview tutorial.
Admin control of client log capture
To configure log capture preferences for applications in production, use the MobileFirst Operations Console. Administrators can control the MobileFirst client SDK log capture and levels from the MobileFirst Operations Console.
The MobileFirst client SDK, on Android and iOS, captures a stack trace upon application crash and logs it at FATAL level. This type of crash is a true crash where the UI disappears from the user's view.
Crash, uncaught exceptions, and global errors are caught and logged automatically.
For more information
For more information about logging and log capture, see the user documentation.
API calls for specific environments▲
- Logging in native Android (Java)
- Logging in native iOS (Objective-C)
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.