path: root/wiki/src/contribute/how/sysadmin/deploy_icinga2_checks.mdwn
diff options
Diffstat (limited to 'wiki/src/contribute/how/sysadmin/deploy_icinga2_checks.mdwn')
1 files changed, 79 insertions, 0 deletions
diff --git a/wiki/src/contribute/how/sysadmin/deploy_icinga2_checks.mdwn b/wiki/src/contribute/how/sysadmin/deploy_icinga2_checks.mdwn
new file mode 100644
index 0000000..67570b5
--- /dev/null
+++ b/wiki/src/contribute/how/sysadmin/deploy_icinga2_checks.mdwn
@@ -0,0 +1,79 @@
+[[!meta title="Deploying Icinga2 checks in the Tails infrastructure"]]
+See [[our sysadmin contribution page|contribute/working_together/roles/sysadmins]]
+for a description of our Icinga2 setup.
+The upstream Icinga2 Puppet module, which may help in simplifying our
+Puppet manifest, requires to use the puppetdb backend to support its
+complex exported resources. In Debian Jessie, exported resources are
+only supported through the active record backend, so we can't really use
+this Puppet module right now. Until PuppetDB can be used (possibly in
+Stretch), we have to write more Puppet code to deploy new checks.
+# Plugins
+Icinga2 "plugins" are scripts or softwares executed by Icinga2 to
+retrieve services data. Icinga2 natively ships a bunch of them. Have a
+look [at the
+if one fits our needs. If not, you'll have to install your custom
+plugin. Check the `tails::monitoring::plugin::check_torbrowser_archive`
+manifest in the [[!tails_gitweb_repo puppet-tails]] for a good
+The plugins manifests are not deployed directly, but are rather
+included from their respective "check commands" manifests. See below.
+# Check commands
+"Check commands" are describing to Icinga2 the way to use plugins. It
+describes the options that can be used, and helps to configure for a
+service how this plugin will be executed. If you intend to use a new
+custom plugin, you also need to install the related check command. See
+the torbrowser-archive one for a good starter. See
+`tails::monitoring::checkcommand::torbrowser_archive` manifest in
+[[!tails_gitweb_repo puppet-tails]].
+If you're using a new custom plugin, that's the place where you should
+include its manifest so that it is installed on every system for which a
+service check is using it.
+# Services
+Once plugins and check commands are checked, you can define a related
+service check.
+Have a look at the `tails::monitoring::service:torbrowser_archive` class
+in [[!tails_gitweb_repo puppet-tails]] and the related service
+configuration template. It is the place where the related check command
+manifest has to be included.
+There are two types of service checks:
+## Remotely executed service
+Ran from the master on a remote hosted service. In this
+case, this service exported resources needs to be collected on the
+Icinga2 master only as we do in the `tails::monitoring::master` class
+for the `Tails::Monitoring::Service::Http` check in
+[[!tails_gitweb_repo puppet-tails]].
+## Locally executed service
+It needs to be deployed on every host that will run it.
+In this case, the exported resources for this kind of service checks
+need to be collected on the master, satellite and concerned system(s).
+That's what we do in the `tails::monitoring::{master,satellite,agent)`
+class for the `Tails::Monitoring::Service::Memory` check in
+[[!tails_gitweb_repo puppet-tails]]. Pay attention to the parameter
+passed at the exported resources collection.
+# Deploy
+Once all of the plugin, check command and service related manifests are
+checked, it's time to configure the service check. Declare it in the
+related node manifest **as an exported resource**.
+Depending if the service is local or remote, the Puppet clients may need
+to be run serveral time on different systems for the service check
+exported resource to be collected and realized correctly.