The plugin provides the basic infrastructure for generating "bundles" of support information within Jenkins.
There are three ways of generating bundles:
- Automatic bundles, these get saved in $JENKINS_HOME/support once per hour starting 3 minutes after Jenkins starts the plugin (i.e. this may still be generated even if Jenkins will not fully start). The automatic bundles are retained using an exponential aging strategy, so you should have a bunch of them over the entire lifetime once the plugin has been installed.
- On demand bundles:
- You can generate them from the root "Support" action, using the User Interface ; or
- By using the CLI Command. For the association documentation,
please refer to
<yourJenkinsInstanceUrl>/cli/command/supportembedded documentation.
Features and functionalities of the Support Core plugin can be configured globally under Manage Jenkins > Support Core.
Configure the automated generation of the Support Bundle. By default, Support Core configures a periodic task that generates a support bundle every hour. This can tremendously help troubleshoot issues in Jenkins, in cases where data could not be collected at the time an issue happened or started to happen.
The following option apply:
- Enable: Whether to enable the automatic generation of the support bundle or not (default to true)
- Period: The recurrence period (in hours) to generate support bundle (default to 1h). Values between 1 and 24 are accepted.
- Components: The list of components to include in the automatic bundle (default to all components)
The system property com.cloudbees.jenkins.support.SupportPlugin.AUTO_BUNDLE_PERIOD_HOURS can
be used to enforce the value of the period. Values between 0 and 24 are accepted. A value of 0
enforce the disablement of the automated support bundle generation.
As part of the support bundle if the About Jenkins option is checked then you will receive a docker file in the bundle also. The docker file contains the current version of Jenkins, along with a wget operation to download all of the plugins on the Jenkins controller. This creates a similar environment for testing or reproducing bugs.
First build the image:
docker build -f Dockerfile
then run the docker image
docker run -d -p 8080:80
This should create a new Jenkins controller with the same version, and the same plugins and versions all bundled.
The most common situation for this to happen is when the About Jenkins option is enabled.
Meanwhile, the support bundle is getting generated it looks like the generation process is stuck as the downloaded size stays at the same point for a long time. To diagnosis this issue the best is to take a threadDump when in the moment where it is stuck and check the Jenkins logs.
If a stacktrace like the one below appears
"Handling POST /support/download from XX.XX.XX.XX : RequestHandlerThread[#126]" Id=123772 Group=main RUNNABLE
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.isDirectory(File.java:849)
at com.cloudbees.jenkins.support.impl.AboutJenkins$ItemsContent.printTo(AboutJenkins.java:641)
at com.cloudbees.jenkins.support.api.PrintedContent.writeTo(PrintedContent.java:47)
at com.cloudbees.jenkins.support.SupportPlugin.writeBundle(SupportPlugin.java:359)
at com.cloudbees.jenkins.support.SupportAction.doDownload(SupportAction.java:154)
and the Jenkins logs are populated with
2018-01-04 04:52:17.633+0000 [id=123769] WARNING c.c.j.support.SupportPlugin#writeBundle: Could not attach 'nodes/slave/agent1/checksums.md5' to support bundle
org.eclipse.jetty.io.EofException: Closed
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:476)
at net.bull.javamelody.FilterServletOutputStream.write(FilterServletOutputStream.java:88)
at net.bull.javamelody.CounterResponseStream.write(CounterResponseStream.java:82)
at org.apache.tools.zip.ZipOutputStream.writeOut(ZipOutputStream.java:1029)
at org.apache.tools.zip.ZipOutputStream.deflate(ZipOutputStream.java:680)
at org.apache.tools.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:432)
at org.apache.tools.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:489)
at com.cloudbees.jenkins.support.SupportPlugin.writeBundle(SupportPlugin.java:358)
at com.cloudbees.jenkins.support.SupportAction.doDownload(SupportAction.java:154)
Then, surely the problem is that you are hitting the Idle timeout in the load balancer and this makes the connection betweek the ELB and your broweser to drop. To workaround this problem you can:
- Increase the Idle timeout in the load balancer
- Not include About Jenkins section
- Reduce the number of builds in the system
Beginning in version
2.48,
this plugin now allows for automated ContentFilter extensions to
enable anonymizing of various data. By enabling this feature, the
default set of filters will anonymize agent names, agent computer names,
agent labels, view names (aka folders), job names, usernames, and IP
addresses (both IPv4 and IPv6). These data are mapped to randomly
generated fake names which are saved to Jenkins controller. A Jenkins
administrator can view these mappings by going to Manage Jenkins ›>
Support Bundle Anonymization. All files written to the support bundle
by this and all extensions of this plugin will replace all instances of
the original values with their anonymized counterpart. Note that the
Stop Words list on that page shows which terms are ignored when
filtering names (case-insensitive full match).
Additional Stop Words can be provided in a text file located at
$JENKINS_HOME/support/additional-stop-words.txt. Each non-blank line of
the file is treated as a stop word. The following contains 3 stop words abc,
john doe and https://test.example.com
abc
john doe
https://test.example.com
The system property com.cloudbees.jenkins.support.filter.ContentMappings.additionalStopWordsFile
can be used to override the file location.
Anonymization filters only apply to text files. It cannot handle
non-Jenkins URLs, custom proprietary Jenkins plugin names, and
exceptions quoting invalid Groovy code in a Jenkins pipeline. The active
plugins, disabled plugins, failed plugins, and Dockerfile reports are
not anonymized due to several Jenkins plugins and other Java libraries
using version numbers that are indistinguishable from IP addresses.
These reports are in the
files plugins/active.txt, plugins/disabled.txt, plugins/failed.txt,
and docker/Dockerfile. These files should all be manually reviewed if
you do not wish to disclose the names of custom proprietary plugins.
As of 2.68 version, support-core is compatible with Jenkins Configuration as Code (CasC).
The configuration looks like:
security:
anonymizeSupportBundle:
enabled: true
It enables (true) or disables (false) the anonymization of the bundle.
Previous versions of this plugin could be configured by CasC as well, but the configuration was so:
unclassified:
contentFilters:
enabled: false
This version changes the configuration fields to be more intuitive. Please update your yaml file if you update support-core to version 2.68 or later.
Starting from version 2.72.2, Support Core plugin could automatically redact any passwords stored in the following files:
nodes.mdabout.mdnodes/master/system.propertiesfor controllers and agentsnodes/master/environment.txtnodes/slave/name/proc/self/environandnodes/slave/name/proc/self/cmdlinefor Linux based instancesnodes/slave/name/config.xmlfor each agent- launch log files per each agent located in
nodes/slave/name/launchLogs
To support this feature, a text file named security-stop-words.txt has been added to the $JENKINS_HOME/support folder. It contains security stop words that are used to detect passwords or secrets. When the bundle is generated, the word "REDACTED" replaces any values associated with these stop words.
For example, if one of the security stop words is "passwd", the following string:
-username.net.passwd=mySecret
will be changed to:
-username.net.passwd=REDACTED
To disable this feature, delete all of the security stop words from the security-stop-words.txt file (but not the file itself, because it will be automatically regenerated with a default values). Any changes made to the security-stop-words.txt file are applied after a Jenkins instance restart.
See GitHub releases.
See the historical changelog.