The syntax validation of the Monit configuration file can be checked using the following command: $ sudo monit -t You can use the netstat command to verify that Monit is listening on port 2812 as shown below: $ netstat -na | grep :2812 The execution of the above playbook to enable the Web interface is shown below: $ ansible-playbook -i inventory/kvm/inventory playbooks/configuration/monit.yml -tags ui -K The Ansible playbook to enable the Monit’s Web interface is as follows: - name: Configure UI After making changes to the configuration file, the service needs to be restarted. The Web UI port needs to be enabled with basic login credentials. The default configuration file for Monit is located at /etc/monit/monitrc. Monit software provides a Web interface that listens on port 2812. The -K option prompts for the sudo password for the Debian user account. You can use up to four ‘v’s for a more detailed output. The -vv represents the verbosity in the Ansible output. The above playbook can be invoked using the following command: $ ansible-playbook -i inventory/kvm/inventory playbooks/configuration/monit.yml -tags install -vv -K Figure 3: Monit Web UI with SSH and Nginx name: Update the software package repository The Ansible playbook for the above tasks is provided below, for reference:. The Monit service is then started using systemd. The net-tools package is installed to provide the netstat command in the system. The Debian software package repository is first updated and then Monit is installed. You can now test connectivity from Ansible to the Debian 9 VM using the following command: $ ansible -i inventory/kvm/inventory debian -m ping You should add an entry in /etc/hosts file for the Debian VM as shown below: 192.168.122.197 debian Figure 2: Monit Web UI status The ‘debian’ user also requires sudo access: apt-get install adduser debian sudo Log in to the VM and install the sudo package. The default Debian 9 installation does not have the sudo package installed. The inventory/kvm/inventory file contains the following code: debian ansible_host=192.168.122.197 ansible_connection=ssh ansible_user=debian ansible_password=password The Ansible playbook and inventory file are created on the host system as follows: ansible/inventory/kvm/ The version of Ansible used is 2.6.0, as indicated below: $ ansible -versionĬonfigured module search path = Īnsible python module location = /usr/lib/python3.6/site-packages/ansible The host system is a Parabola GNU/Linux-libre x86_64 system and Ansible is installed using the distribution package manager. In my case, because I start docker services on boot it wasn't an issue.A Debian 9 (x86_64) guest virtual machine (VM) using KVM/QEMU will be set up and monitored using Monit. The only downside to this method is that Monit will log about the service not running repeatedly until it is started. Here you see I'm also using the MATCHING syntax because the entrypoint for Docker containers may change in the future (I don't maintain this one myself). In my case, 13% is about 65% CPU on a single core which (over 3 minutes) I deemed enough to recognize when the bug had occurred. Monit considers 100% CPU usage to be full utilization on all cores, which is why you see 13% (you can also verify current service CPU usage checking the output of monit status). ![]() If cpu usage > 13% for 3 cycles then restart Stop program = "/usr/bin/docker stop home-assistant" Start program = "/usr/bin/docker start home-assistant" Monit doesn't have a good answer for this built-in, so the key is to override the start action by executing a no-op when the service isn't running: only check process home-assistant MATCHING ^python.+homeassistant "if already running" turned out to be a little more complicated than I expected. Otherwise, Monit would proceed to start the container on boot prior to the mounted drive being present, resulting in a bunch of headaches. I wanted Monit to automatically restart the service when it was eating CPU (which ordinarily is trivial to do), but due to the mapped volume, I only wanted it to stop & start the service if it was already running. I recently ran into an issue where a bug in one of my Docker containers would intermittently chew through CPU until restarted.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |