h6. Contents
{toc:minLevel=5|maxLevel=5|printable=false}
h5. Description
This technical bulletin is for all GroundWork customers. It provides an update to the SLA processing and dashboards (for enterprise customers) and the downtime scheduler "slareport" database. It is applicable to GroundWork Monitor 7.2.1 only, and requires the application of the [GWME-7.2.1-00 Rollup Patch Installer|DOC721:GWME-7.2.1-00 Rollup Patch Installer].
{color:#333333}UPDATED 11/08/2018:{color} The 2018-10-31 v2 version of this TB contained the original version of the retention scripting, which did not support retention control of audittrail data and did not match the install instructions here. Also, that version did not verify that the patch is being installed over the GWME-7.2.1-00 Rollup Patch. The v2 version has been replaced with a v3 tarball. It now matches the install instructions, supports retention control of audittrail data, verifies that the rollup patch is in place before this SLA patch can be applied, and does proper state reversion if either install or uninstall of the patch fails. If you had either the original version or the v2 version of this SLA patch applied, it is recommended that you uninstall it, verify that you have the rollup patch installed, and then install the v3 version of this SLA patch.
h6. What is in this update?
This patch will add a cron job to remove historical expired downtimes from the database. By default only downtimes expired for more than 90 days will be removed, but you have to enable this. By default sufficiently ancient SLA audittrail data will also be deleted, with the default value being 90 days as well.
See install steps below.
h5. Prerequisites
{color:#333333}This technical bulletin does not depend upon prior technical bulletins. {color}There is no need to schedule a downtime to apply this technical bulletin. There is no need to halt GroundWork Monitor to run the script, although you should be prepared to see the initial running of the script take longer to complete depending on the number of downtime requests you have accumulated in the system.
* You need to be running GroundWork Monitor Core or Enterprise, version 7.2.1.
* You must have already installed any version of the [GWME-7.2.1-00 Rollup Patch Installer|DOC721:GWME-7.2.1-00 Rollup Patch Installer].
You can learn what version and patch if any are installed by the following command line as the root or nagios user
{noformat}
cat /usr/local/groundwork/Info.txt
{noformat}
Typing that should get you a text page like the next one, in which you can see that you have the right version and patch. If you don't see something like it you have some work to do getting upgraded and patched, give Support a call for assistance.
{noformat}
cat /usr/local/groundwork/Info.txt
GroundWork Installation Report
==============================
Components Installed:
PostgreSQL ..... 9.6.9
Monitor ..... 7.2.1-br494-gw3901
Product Info
=============
name= enterprise
version= 7.2.1
bitrock_build= br494
gw_build= gw3901
installer_name= groundworkenterprise-7.2.1-br494-gw3901-linux-64-installer.run
installation_date= 11/02/2018 21:36 PM
patch_version= 7.2.2
patch_gw_build= gw4042
patch_installation_date= 11/07/2018 10:10 PM
{noformat}
h5. Installation Steps
{attachments:patterns=TB7.2.1-04-sla-updates-v3.tgz}
# As {{root}} user, copy the attached tgz to the {{/tmp}} directory on the GroundWork server.
# Unpack the tar using the command:
{noformat}
tar zxvf TB7.2.1-04-sla-updates-v3.tgz
{noformat}
# Change into the directory created by untarring:
{noformat}
cd TB7.2.1-04-sla-updates
{noformat}
# Run the installer script, and respond to the prompt:
{noformat}
./TB7.2.1-04_install.sh
{noformat}
The install script will test that you are on a 7.2.1 system (which is required), that you have installed the 7.2.1 Rollup Patch, that you have not already installed this patch, and that you want to go ahead.
{note}A backup will be created for rollback in case the install is interrupted. A new maintenance script and configuration file will be copied into place. The related cron job will be modified so it doesn't run if a previous execution is still running. A new cronjob will be added, to impose retention control on SLA downtime and audit-trail data. Only the cron job will be affected. {note}
When does the cron job run? At 40 minutes past midnight every night. Here is the line that we add to the nagios crontab.
{noformat}
40 0 * * * /usr/local/groundwork/tools/sla_retention --downtimes --audittrail
{noformat}
h5. Usage
There are no special usage instructions, but if you want to get the benefit of the trimmed database right away, you can follow these steps:
# (Optional) Edit the file:
{noformat}
/usr/local/groundwork/config/sla_retention.conf
{noformat}
and change the days value from the default of 90 to the desired number of days to retain expired downtime and audit trail information.
# As the {{nagios}} user, run:
{noformat}
/usr/local/groundwork/tools/sla_retention --downtimes --audittrail
{noformat}
This may take a minute or two.
# (Optional) Clean up the database after deleting records by:
## Logging in as the {{root}} (or superuser).
## Type:
{noformat}
/usr/local/groundwork/postgresql/bin/psql
{noformat}and supply the postgres user password.
## Enter at the sql prompt:
{noformat}
\c slareport
vacuum (full, analyze);
{noformat}
h5. Uninstalling
Reversal of this patch will remove the new files, and it's best to put back the original cron job setup. Monitoring in general can continue while this happens. If you had previously modified the frequency of the {{yiic downtime process}} cronjob, you will want to edit that again after uninstalling this patch.
# As the {{root}} user, navigate to the patch-unpack directory you created when installing the patch, (if that directory no longer exists, first unpack the patch again):
{noformat}
cd TB7.2.1-04-sla-updates
{noformat}
# Run the uninstall command:
{noformat}
./TB7.2.1-04_uninstall.sh
{noformat}
{toc:minLevel=5|maxLevel=5|printable=false}
h5. Description
This technical bulletin is for all GroundWork customers. It provides an update to the SLA processing and dashboards (for enterprise customers) and the downtime scheduler "slareport" database. It is applicable to GroundWork Monitor 7.2.1 only, and requires the application of the [GWME-7.2.1-00 Rollup Patch Installer|DOC721:GWME-7.2.1-00 Rollup Patch Installer].
{color:#333333}UPDATED 11/08/2018:{color} The 2018-10-31 v2 version of this TB contained the original version of the retention scripting, which did not support retention control of audittrail data and did not match the install instructions here. Also, that version did not verify that the patch is being installed over the GWME-7.2.1-00 Rollup Patch. The v2 version has been replaced with a v3 tarball. It now matches the install instructions, supports retention control of audittrail data, verifies that the rollup patch is in place before this SLA patch can be applied, and does proper state reversion if either install or uninstall of the patch fails. If you had either the original version or the v2 version of this SLA patch applied, it is recommended that you uninstall it, verify that you have the rollup patch installed, and then install the v3 version of this SLA patch.
h6. What is in this update?
This patch will add a cron job to remove historical expired downtimes from the database. By default only downtimes expired for more than 90 days will be removed, but you have to enable this. By default sufficiently ancient SLA audittrail data will also be deleted, with the default value being 90 days as well.
See install steps below.
h5. Prerequisites
{color:#333333}This technical bulletin does not depend upon prior technical bulletins. {color}There is no need to schedule a downtime to apply this technical bulletin. There is no need to halt GroundWork Monitor to run the script, although you should be prepared to see the initial running of the script take longer to complete depending on the number of downtime requests you have accumulated in the system.
* You need to be running GroundWork Monitor Core or Enterprise, version 7.2.1.
* You must have already installed any version of the [GWME-7.2.1-00 Rollup Patch Installer|DOC721:GWME-7.2.1-00 Rollup Patch Installer].
You can learn what version and patch if any are installed by the following command line as the root or nagios user
{noformat}
cat /usr/local/groundwork/Info.txt
{noformat}
Typing that should get you a text page like the next one, in which you can see that you have the right version and patch. If you don't see something like it you have some work to do getting upgraded and patched, give Support a call for assistance.
{noformat}
cat /usr/local/groundwork/Info.txt
GroundWork Installation Report
==============================
Components Installed:
PostgreSQL ..... 9.6.9
Monitor ..... 7.2.1-br494-gw3901
Product Info
=============
name= enterprise
version= 7.2.1
bitrock_build= br494
gw_build= gw3901
installer_name= groundworkenterprise-7.2.1-br494-gw3901-linux-64-installer.run
installation_date= 11/02/2018 21:36 PM
patch_version= 7.2.2
patch_gw_build= gw4042
patch_installation_date= 11/07/2018 10:10 PM
{noformat}
h5. Installation Steps
{attachments:patterns=TB7.2.1-04-sla-updates-v3.tgz}
# As {{root}} user, copy the attached tgz to the {{/tmp}} directory on the GroundWork server.
# Unpack the tar using the command:
{noformat}
tar zxvf TB7.2.1-04-sla-updates-v3.tgz
{noformat}
# Change into the directory created by untarring:
{noformat}
cd TB7.2.1-04-sla-updates
{noformat}
# Run the installer script, and respond to the prompt:
{noformat}
./TB7.2.1-04_install.sh
{noformat}
The install script will test that you are on a 7.2.1 system (which is required), that you have installed the 7.2.1 Rollup Patch, that you have not already installed this patch, and that you want to go ahead.
{note}A backup will be created for rollback in case the install is interrupted. A new maintenance script and configuration file will be copied into place. The related cron job will be modified so it doesn't run if a previous execution is still running. A new cronjob will be added, to impose retention control on SLA downtime and audit-trail data. Only the cron job will be affected. {note}
When does the cron job run? At 40 minutes past midnight every night. Here is the line that we add to the nagios crontab.
{noformat}
40 0 * * * /usr/local/groundwork/tools/sla_retention --downtimes --audittrail
{noformat}
h5. Usage
There are no special usage instructions, but if you want to get the benefit of the trimmed database right away, you can follow these steps:
# (Optional) Edit the file:
{noformat}
/usr/local/groundwork/config/sla_retention.conf
{noformat}
and change the days value from the default of 90 to the desired number of days to retain expired downtime and audit trail information.
# As the {{nagios}} user, run:
{noformat}
/usr/local/groundwork/tools/sla_retention --downtimes --audittrail
{noformat}
This may take a minute or two.
# (Optional) Clean up the database after deleting records by:
## Logging in as the {{root}} (or superuser).
## Type:
{noformat}
/usr/local/groundwork/postgresql/bin/psql
{noformat}and supply the postgres user password.
## Enter at the sql prompt:
{noformat}
\c slareport
vacuum (full, analyze);
{noformat}
h5. Uninstalling
Reversal of this patch will remove the new files, and it's best to put back the original cron job setup. Monitoring in general can continue while this happens. If you had previously modified the frequency of the {{yiic downtime process}} cronjob, you will want to edit that again after uninstalling this patch.
# As the {{root}} user, navigate to the patch-unpack directory you created when installing the patch, (if that directory no longer exists, first unpack the patch again):
{noformat}
cd TB7.2.1-04-sla-updates
{noformat}
# Run the uninstall command:
{noformat}
./TB7.2.1-04_uninstall.sh
{noformat}