Table of Content
- Log Capture Scripts
- Manual Server Log Retrieval
- Client Logs
- Getting FCSDK Configuration
Logs are a great source of information to help understand component behaviour. There may be times when we ask you to provide logs and different logs are useful in different use cases. If in doubt provide them all. When providing us with log please ensure the logging level is set to DEBUG. See How to Change the Logging Level to Debug article using the JBoss console. This will require a FAS restart. Alternatively here is an article that explains how to change the level dynamically using the JBoss CLI.
This article describes the location of all the logs on the server components and details on how to find logs on the clients. We include scripts for making log collection on the server easier as part of the FAS installation (which is the base on which our products, such as FCSDK, Live Assist and Palettes are deployed), and we will start by describing these scripts.
The following sections use the **Install Directory** as a starting point for locations on your file system, where this directory is located will depend on the Operation System on which you installed e.g. MAC or Linux, whether you performed a GUI or silent install, and if you have specified a non default install directory during installation. Below are the default install directories for a GUI install:
If you performed a silent install then you can go back and look at the install properties file to obtain the INSTALL_PATH property, this will be set to /opt/cafex by default. Take a look at the Trials Environment Troubleshooting article for default Trial Environment install directory. When you see FAS-x.x.x in a path, the x.x.x will be replaced with your version of FAS.
Log Capture Scripts
logcapture.sh: This script captured logs during a period of time so as to only collect relevant logs to a particular scenario. By weeding out irrelevant logs it is far easier to find log entries relating to your use case. This script is found in both the <FAS install>/bin and the Media Broker install directories and is typically executed as follows:
/<Install Directory>/FAS-x.x.x/bin/logcapture.sh -p -c -f <scenario>.tar
e.g. [root@host tmp]# /opt/cafex/FAS-2.1.15/bin/logcapture.sh -p -c -f my_test_name.tar
This command includes the -p parameter which will take a packet capture while the script is running and the -c parameter to include configuration files, which along with the logs, will be bundled in the resulting tar file.
There are also a number of other parameters than can be used which will include extra information such as heap dumps. To find out information about the other available parameters use the help parameter as follows:
/<Install Directory>/FAS-x.x.x/bin/logcapture.sh --help
Note:On a distributed environment, where the server hosts only the Fusion Application Server, but not the Fusion Media Broker, then the logcapturefordistributedenvt.sh script must be used. This script will be merged with the default logcapture.sh script in future releases.
Note: When the Fusion Media Broker is co-hosted with the Fusion Gateway the log capture script in the media broker install directory should be used instead of the FAS one....
/<Install Directory>/FCSDK-2.1.X.X/media_broker/logcapture.sh -p -c -f <scenario>.tar
It will collect FAS and Media Broker logs (and anything else specified in the script executing parameters) as well.
If you have installed the Media Broker to a separate machine to the Gateway then you can use the log capture script that will be located in the Media Broker install directory. This script is executed in the same way as the above.
MAC Installs: On a mac the -p parameter must provide a network interface to do the packet capture against, e.g. [root@host tmp]# /opt/cafex/FAS-2.1.15/bin/logcapture.sh -p en0 -c -f my_test_name.tar
FCSDK user Note: If you have FCSDK 2.1.7 to 2.1.10 installed then the logcapture.sh script may not capture Media Broker logs. Please copy the logcapture.sh script attached to this article to your fusion_media_broker directory and make it executable with chmod 777 logcapture.sh
You will also need the attached script to obtain a complete packet capture on a box with multiple network interfaces.
Trials user Note: The installed logcapture.sh scripts will not capture cafex logs correctly in a trials environment install. If you have installed trails to a mac copy the logcapturefortrials_mac.sh script attached to this article to your cafex install machine and make it executable with chmod 777 logcapturefortrials_mac.sh
If you have installed to Linux please copy the logcapturefortrials.sh script to your cafex install machine and make it executable with chmod.
log-archiver.sh: This script will capture all the FAS logs that are currently stored on your install. The resulting file will probably be quite large so this script should only be used if you cannot reproduce a scenario to use the logcapture script. This script is also stored in the <FAS install>/bin directory and is typically executed as follows:
e.g. [root@host tmp]# /opt/cafex/FAS-2.1.15/bin/log-archiver.sh
As you can see this script takes no arguments and outputs a file called fas-logs.zip.
Manual Server Log Retrieval
If for what ever reason the scripts are not appropriate, for example you want to look at some logs yourself or the issue is related to server start-up issues then below lists useful log locations:
|Gateway/FAS Main Server Log||/<Install Directory>/FAS-x.x.x/domain/servers/appserver-<Server Hostname>/log/server.log|
Gateway/FAS Call Log *
|/<Install Directory>/FAS-x.x.x/domain/servers/appserver-<Server Hostname>/log/calls.log|
Gateway/FAS Message Log **
|/<Install Directory>/FAS-x.x.x/domain/servers/appserver-<Server Hostname>/log/messages.log|
Gateway/FAS Load Balancer Server Log
|/<Install Directory>/FAS-x.x.x/domain/servers/loadbalancer-<Server Hostname>/log/server.log|
|Media Broker Proxy Log||/<Install Directory>/media_broker/proxy.log|
* This log shows SIP traffic leaving and entering FAS. Messages will not be shown in this log if SIP entities are not involved in the call flow.
** This log will show all SIP messages as they as they traverse the internal components deployed to FAS
To collect a complete set of logs
This will collect all the log available since start up and some logs contain information from multiple restarts.
Navigate to the 3 locations below and zip up all the log files in the directory...
cd /<Install Directory>/FAS-x.x.x/domain/servers/appserver-<Server Hostname>/log
zip appserver_logs *log*
cd /<Install Directory>/FAS-x.x.x/domain/log
zip domain_logs *log*
cd /<Install Directory>/FCSDK-x.x.x/media_broker
zip domain_logs *log*
The 3 created zip files may be too big to attach to an email or ticket (7 mb limit on Zendesk) so can be made available to us via the cloud or we can provide you with an upload link for our file server.
Before obtaining browsers logs (sometimes also referred to as console/client logs) from Chrome or Firefox, could you please follow the instructions below to ensure that timestamps are enabled on your browser, these can be very useful to us when attempting to resolve an issue.
Applies to both Chrome and Firefox: Press F12 on your browser and select the "cog" settings button as highlighted in the the screenshot below, you will then see the menu illustrated below, ensure that the highlighted boxes are ticked.
- Chrome: If using Chrome for a client then you can see the logs in the console, shown by bringing up the page context menu (normally by right clicking in the browser window) and selecting "Inspect Element", and then selecting the Console tab. These logs are normally detailed enough for us.
Note: Once the test is complete right click anywhere in the console window and select "save as" to save the logs to file.
On some occasions we need more detailed logs that are obtained by opening a new instance of chrome in debug mode as follows:
Windows: <Chrome Directory>\chrome.exe --enable-logging --v=9 --vmodule=*libjingle/source/*=9 --user-data-dir=c:\chromedebug
Mac: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging --v=9 --vmodule=*libjingle/source/*=9 --user-data-dir=/User/<your user dir>/chromedebug
- Firefox: Firefox console logs are accessed in a similar way to Chrome above. Right click within the firefox window and either select "Inspect Element" or after the right click just press Q. Once the window has appeared there will be a "Console" tab, the logs found here are again normally detailed enough for us.
- Internet Explorer: IE works the same as Firefox above without the shortcut of Q. To access the logs from IE simply right click, then click "Inspect Element". This will then bring up a set of windows, just click the "Console" tab. These logs should contain enough information for us to diagnose.
How to obtain the Browser/Client Logs (step by step)
- Right click in your browser window, left click 'inspect' or 'inspect element'.
- Recreate the issue you are seeing.
- To save: Each console varies from browser to browser but generally you can: Right click > Save as (notepad text file). Or Right Click > Select All, Right click > Copy. Then you'll want to paste that into a text file.
- These text files tend to be rather small so you should be able to attach this directly to the ticket.
Hand held device logs
- iPad: We support using Xcode, here are the instructions on how to find the logs:
You can obtain iPad logs by plugging the iPad into a MAC, opening XCode and navigating to Window -> Devices and selecting your iPad in the left hand menu. You can view the device console by clicking the arrow in the bottom left corner of the right hand panel. To get a copy of the logs 'select all' in the console window and paste into a text file.
To get the Crash logs click the View Device Logs button and select the Crash item in the left hand pane from the time of the crash you are interested in, then right click and select export log.
- For for older Xcode 5 & 6 versions. You can obtain iPad logs by plugging the iPad into a MAC, opening XCode 5 and navigating to Window -> Organiser -> Devices and selecting your iPad in the left hand menu. In the drop down menu select console. For XCode 6 navigate to Window -> Devices and select your iPad in the left hand menu, when click the view device logs button.
- If you don't use XCode and your using iOS7 you can download the iPhone Configuration Utility for windows or Macs and connect your iPad to it to collect the console logs. For iOS8 you can download and collect logs via http://lemonjar.com/iosconsole/ if using a MAC.
- dSYM file. If your custom iPad app has crashed please include the dSYM file as well as the crash log. The dSYM file can be found in xCode by Right Clicking on your archive -> Show in Finder -> Right click on file and click on Show package content
- Android: There are a number of ways to obtain logs from an Android device.
- In the lab if using Android Studio use this guide https://developer.android.com/studio/debug/am-logcat.html
- If you use Eclipse then this tutorial will help https://www.utest.com/courses/android-debug-bridge-part-1-how-to-capture-logcat-files-using-adb (sign in required)
- Note: From Android 4.1 onwards installing a Log capture app onto the device will only give you access to the apps own logs unless the device is rooted.
Getting FCSDK Configuration
Providing the configuration for the cluster is also normally needed along with logs. The easiest way to provide this is to navigate to
You need to provide the FSCSK web_plugin_framework credentials. Then cut and paste the contents of the page into a text file and attach it to the ticket.
Note: Please don't use MS notepad as it destroys the formatting of the page
Comments are disabled on these articles if you require help contact email@example.com.