-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
0
-
2
-
Currently the JFR (Java Flight Recorder) configuration file (active_config.jfr) is stored in the $JIRA_HOME/log/jfr files directory. This raises several issues:
- It breaks the best practice of storing configuration files in a common location
- In containerized environments with a non-persistent log files dir,
- your configuration will reset on every restart of Jira
- OR you must manage a persistent volume to maintain the integrity of a single config file.
- OR you must manage the file as code, which also means you must ensure that changes from within the UI are also updated in code.
- If you clean out your log files directory either as a troubleshooting task, or as a regular process, you may lose your JFR configuration if you are unaware of the file or it's changes.
- Allows for inconsistency between nodes in a DataCenter environment as it is stored in the local home, rather than the shared home.
- for example, if one node is down when it is configured, it would not pick up the changes.
- If you are upgrading Jira using a new server, you will lose any custom configuration if you are unaware of changes in this file, and fail to copy it to your new server.
- In some instances JFR will fail to start due to a missing configuration file if the file doesn't exist because one of the previous issues.
- with a non-persistent log volume this means you must add a manual step to every Jira restart, to go in, and turn off and back on JFR.
The following solutions are proposed:
- Include a setting to move the location of the configuration file
- Move the configuration file to a common location for configuration files (such as the $shared_home, $shared_home/data, $jira_home, or $jira_install directories)Move the configuration into the database
- Move the configuration into the database)
- mentioned in
-
Page Loading...
Support reference count | Original: 1 | New: 2 |
Support reference count | New: 1 |
Remote Link | New: This issue links to "Page (Confluence)" [ 893578 ] |
UIS | Original: 1 | New: 0 |
UIS | New: 1 |
Comment | [ This affects Confluence as well. Please create an associated Confluence ticket. ] |
Description |
Original:
Currently the JFR (Java Flight Recorder) configuration file ({{{}active_config.jfr{}}}) is stored in the {{$JIRA_HOME/log/jfr}} files directory. This raises several issues:
# It breaks the best practice of storing configuration files in a common location # In containerized environments with a non-persistent log files dir, ** your configuration will reset on every restart of Jira ** OR you must manage a persistent volume to maintain the integrity of a single config file. ** OR you must manage the file as code, which also means you must ensure that changes from within the UI are also updated in code. # If you clean out your log files directory either as a troubleshooting task, or as a regular process, you may lose your JFR configuration if you are unaware of the file or it's changes. # Allows for inconsistency between nodes in a DataCenter environment as it is stored in the local home, rather than the shared home. ** for example, if one node is down when it is configured, it would not pick up the changes. # If you are upgrading Jira using a new server, you will lose any custom configuration if you are unaware of changes in this file, and fail to copy it to your new server. # In some instances JFR will fail to start due to a missing configuration file if the file doesn't exist because one of the previous issues. ** with a non-persistent log volume this means you must add a manual step to every Jira restart, to go in, and turn off and back on JFR. The following solutions are proposed: # Include a setting to move the location of the configuration file # Move the configuration file to a common location for configuration files (such as the {{{}$shared_home{}}}, {{{}$shared_home/data{}}}, {{{}$jira_home{}}}, or {{$jira_install}} directories)Move the configuration into the database |
New:
Currently the JFR (Java Flight Recorder) configuration file ({{{}active_config.jfr{}}}) is stored in the {{$JIRA_HOME/log/jfr}} files directory. This raises several issues:
# It breaks the best practice of storing configuration files in a common location # In containerized environments with a non-persistent log files dir, ** your configuration will reset on every restart of Jira ** OR you must manage a persistent volume to maintain the integrity of a single config file. ** OR you must manage the file as code, which also means you must ensure that changes from within the UI are also updated in code. # If you clean out your log files directory either as a troubleshooting task, or as a regular process, you may lose your JFR configuration if you are unaware of the file or it's changes. # Allows for inconsistency between nodes in a DataCenter environment as it is stored in the local home, rather than the shared home. ** for example, if one node is down when it is configured, it would not pick up the changes. # If you are upgrading Jira using a new server, you will lose any custom configuration if you are unaware of changes in this file, and fail to copy it to your new server. # In some instances JFR will fail to start due to a missing configuration file if the file doesn't exist because one of the previous issues. ** with a non-persistent log volume this means you must add a manual step to every Jira restart, to go in, and turn off and back on JFR. The following solutions are proposed: # Include a setting to move the location of the configuration file # Move the configuration file to a common location for configuration files (such as the {{{}$shared_home{}}}, {{{}$shared_home/data{}}}, {{{}$jira_home{}}}, or {{$jira_install}} directories)Move the configuration into the database # {{{}Move the configuration into the database{}}}) |