Jama Support Bundle: How do I get it, what's in it and which logs should I care about?

By Decoteau posted 22 days ago



This document is a companion piece to the Gathering Empirical Data for Troubleshooting article.

The support bundle, a feature available in versions of Jama 8.0 +, is a simple way for a customer to create a comprehensive set of information for troubleshooting purposes. A support bundle includes all of the logs we'd traditionally ask for in support. It also includes logs for Docker and Replicated, detailed system information and all of the configuration and environment variables in use in a customer's environment.

Generating a support bundle

A support bundle can be generated in one of two ways: using the Replicated web portal user interface (UI) and the command-line interface (CLI). Using the UI is the most common method, but sometimes the UI isn't available, and using the CLI method is a great way to get around that.


Using the UI

Using the UI:
This is the easiest way to generate a support bundle and is the method you will use most often.
1. Log into the Replicated portal for your Jama instance. This will be located at https://<IP or hostname>:8800
2. Select the Support Tab.
3. Select the Download Support Bundle button to download the bundle to your local machine.
4. You can find information on how to generate the Support bundle from the UI here.


Using the CLI

There are times when the Replicated UI is not available. In those cases, users will need to use the command line (CLI.)
1. You can find information on how to generate the Support bundle from the command line here

Support Bundle Contents

Jama 8 Architecture

There's a lot of stuff in the support bundle and it can be a little intimidating at first. Most troubleshooting happens in just a few of the logs though and if you understand all of the moving parts involved, it will help you navigate the contents of the support bundle.

 NOTE: This article will not describe every file in the bundle but will call out the files of greatest interest.

The Jama 8.0 architecture looks like this:

And here are the different parts:

  • Replicated Server - The cloudy image is literally the servers the company Replicated is running. The local Replicated instance checks with the Replicated Server for updates (Replicated and Jama), to download Jama during installation, etc. It is being mentioned for the purposes of being thorough but the support bundle will not pull down any info from the Replicated Server and will not include any logs from it.
  • Replicated - This is the local instance of Replicated daemon. It is responsible for all of the operations of Replicated.
  • UI - This is the local Replicated web console.
  • Agent - Agent handles the communication between Replicated, the UI and our Docker containers.
  • Jama - This is what we're used to thinking of as Jama although there are more services than there used to be. This currently includes our five containers: jamacore, tenantmanager, elasticsearch, search and nginx.

 From that image, you can see you may be looking for things relating to Replicated, the UI, the agent and/or Jama/Docker.


The Folder/File structure

At the top level, you see two folders and two files:

  • /daemon - This folder contains information about the host, Docker containers' status, and the Replicated processes themselves. 
  • /scheduler - After drilling down, this folder's logs are all about Jama's Docker containers. It includes things like Docker inspect, stderr, stdout as well as Jama's logs. The information in this folder only pertains to Jama. There will be one sub-folder per Docker container.
  • license.txt - This includes your license's basic information, including your current version of Jama and your license's expiration date. 


Let's break that down further. Here's a list of the sub-folders, their contents, and which files should be most interesting to you.:


/daemon: - Information about your host, Replicated, and Docker

  • /docker/docker_info.json - This contains an overview of the state of your docker containers. You should see at least 5 running and 1 stopped. The tenant manager container is always stopped once its successfully done its job of getting Jamacore up. If the docker containers aren't running as they should check the next file...
  • /docker/docker_ps_a.json - This has a breakdown of each container and its state. If a container is down, it's helpful to know which one is down. 
  • /replicated/replicated.log - The uber Replicated log of errors internal to Replicated. If you are experiencing an error on the Replicated level, this is the place to look.


/scheduler/container: - Information pertaining to your Jama containers

  • /jamacore-<container_id>/files/var/log/tomcat/contour - These folders hold a majority of the logs we use to troubleshoot. This section will only cover a few of the main logs we use in this folder, but it won't hurt to look through all of the logs here if you are doing a thorough search. 
    • contour.log - This is the very first place to start looking when you are experiencing problems in Jama. This is where a majority of information is logged and is a great starting point when troubleshooting. 
    • contour-api.log - Contains errors and logs relevant to the API
    • contour-c3p0.log(pre 8.56) / contour-datasource.log(post 8.56) - These logs are related to the Java connection pool that manages our database connections. 
    • contour-dwr.log - These are logs related to the UI making calls to the server via DWR (DWR is the tech used to communicate to the backend along with a REST API).
  • /jamanginx-<container_id>/files/var/log/nginx/error.log - The nginx container is basically a proxy server for the application that functions out of its own container. The error.log file collects logs when that proxy server receives instructions it’s unable to follow or traffic that it's unable to route.
  • /search-<container_id>/files/logs/jamasearch.log - This includes any activities and errors that may be happening in the search service.