Monitoring Drupal with Icinga
Overview:
Monitoring one or two Drupal sites can be done by logging into the status report every few days and reviewing settings, looking at your watchdog log, and reading the emails the sites send you. However, as you run more and more sites that process becomes overwhelming and can take up a large amount of time. A few services exist to help monitor all of your sites in one place, Droptor, Drupal Monitor, and Acquia all provide really slick solutions. However, if you want to roll your own due to cost, corporate security, etc... the Drupal community has developed several tools leveraging Nagios.
I wanted to set this up to monitor the sites I manage and chose to use Icinga, a fork of Nagios and openSUSE 12.2 as that is consistent with our environment. Currently I am doing this as a proof of concept project and it is running inside of VirtualBox on an older Mac. The Drupal projects that I am using are the following:
These two modules first let us talk with our Nagios server but also provide most of the stats you can find in the paid services. On initial install the results are not all that pretty to look at but I believe there are ways to fix that and I would rather have comprehensive than pretty any day.
Installation was inspired by the post at awebfactory. There is currently no write-ups on how to do the install if you are using Icinga but since it is a fork of Nagios all of the steps are quite similar. I still know very little about Nagios so if you see a goofy config file please improve upon it. The readme file that accompanies the Nagios Monitoring module is fairly comprehensive and if using Icinga use the Nagios 3 style configuration options. Here are four tips that I wish I had known while setting this up.
4 Tips
- You must define a host in your .cfg file you create for monitoring the Drupal sites. The README assumes you have done this already but if you are creating a monitoring server from scratch this is news. Add the following at the top of the hostgroups.cfg file the instructions ask you to create.
define host{ use linux-server host_name domainname.edu alias DevVM ; You will see what you put here in Icinga } - The unique string you generate for use in the module and within Icinga goes where the instructions have the words unique identifier.
- Initially my Drupal check was not returning any results. I got an error "Service Check Timed Out." My dev server is a little pokey so I needed to edit the service_check_timeout line in icinga.cfg from 60 to 600. I chose 600 because this article uses it, very scientific, I know.
- The SUSE Icinga package places Icinga in /etc/icinga, /etc/init.d/icinga check_verbose checks your settings in the .cfg files you have edited/created and /etc/init.d/icinga restart restarts the service.
Installing Icinga
Thankfully there is a package for Icinga in the openSUSE repositories. I installed this using the GUI tools but if I move out of a proof of concept phase I would do this with an openSUSE box run level 3 so I will try to show the command line install options rather than how to use Yast. This generally just involves following the documentation at http://docs.icinga.org/latest/en/quickstart-icinga.html.
Install the dependencies:
$ zypper install gd gd-devel libjpeg libjpeg-devel libpng libpng-devel $ zypper install net-snmp net-snmp-devel perl-Net-SNMP Create a user named icinga, please follow the instructions at the link above. $ zypper install thttpd $ sudo vi /etc/icinga/etc/objects/contacts.cfg Change the email address associated with icingaadmin to one that you can receive email at. ESC : wq ENTER to exit. Set the password for icingaadmin
$ htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin $ sudo /etc/init.d/apache2 reload
Make sure Icinga starts when you boot.
$ chkconfig --add icinga
$ chkconfig icinga on
Verify everything is good with your initial configuration.
$ sudo /etc/init.d/icinga check_verbose
Start Icinga
$ sudo /etc/init.d/icinga start
Navigate to http://localhost/icinga/ and login with icingaadmin and the password you set earlier.
Install the Nagios Drupal Check service
The steps in the README file are correct for openSUSE. Just use the Nagios 3.x version of the commands and follow tip number 1 from above.
Final Result
I started monitoring a site I have on my devVM and it shows me a boatload of issues. Core is out of date, stuff is turned on that shouldn't be for a production site, modules need to be updated, etc... The beauty of this is that I simply need to turn the module on for each site I want to monitor, update my hostgroup definition in hostgroups.cfg and I have instant monitoring. I hope to provide further details such as NRPE on the remote host, selective alerts, and a prettier interface.
Thank you to everyone I have linked to in this article and to the developers of the fantastic Icinga, Nagios, and Drupal modules. On a happy note, Acquia itself uses Nagios to monitor their sites in the Acquia cloud.
Installing pdftk on RHEL6
A project at work required me to use the Fill PDF module for Drupal. After installation I realized I needed the pdftk package on our VM to leverage the power of the module. Since we have the VM there is no need to use the service option.
Searching for the package with yum did not turn anything up. I did find the package at repoforge.org. We are running a 64bit install so we needed the 64bit RPM. Here are the steps to install.
$wget http://pkgs.repoforge.org/
rpm -K --nosignature pdftk-1.44-2.el6.rf.x86_64.rpm
sudo yum install jre-gcj
sudo rpm -Uvh pdftk-1.44-2.el6.rf.x86_64.rpm
$PATH
which pdftk
First we download the package and check that it a complete package with rpm -K --nosignature command. Then we install the dependency jre-gcj which is a Java Runtime Environment compiler. Next, we install the package using the update -U flag. Run $PATH to list our path and run the which command to verify it is installed in our path.
After that the Fill PDF module detects pdftk is installed and life is good.
RedHat's documentation on RPMs was fantastic and a big help in making sure this went smoothly.
Drupal APC changes in version 3.1.3p1 for file upload progress.
Many of us use APC for the file upload progress meter in Drupal. Recently, APC expanded what is contained in their apc.ini file rendering the following error message displayed in the Drupal status report rather useless.
"Your server is capable of displaying file upload progress through APC, but it is not enabled. Add apc.rfc1867 = 1 to your php.ini configuration. Alternatively, it is recommended to use PECL uploadprogress, which supports more than one simultaneous upload."
You can add apc.rfc1867 = 1 in your php.ini file, reload Apache, but alas the error message still appears. Somewhere between APC version 3.1.9 and 3.1.3p1 the APC configuration file got much more robust. To find out what version you are running simply run from the command line $php -i | less and then search for apc using /apc.
Anyhow, the fix is really simple.
Navigate to /etc/php.d/apc.ini and go to line 54. Change that line from 0 to 1. You end up with:
apc.rfc1867 = 1
Save the file and reload apache. Voila, no more error. These paths and commands work on Red Hat Enterprise Linux 6 (RHEL6).
Installing xhprof on RedHat 6
After listening to a great session on PHP profiling at the Pacific Northwest Drupal Summit I decided to install it on a dev machine at work. It runs RHEL6 which is a great system, though sometimes it is a bit of an oddity to work with.
Installation is pretty straight forward, do not expect to be able to use PECL to install the package though as phpize is referenced incorrectly in the PECL package, as far as I could find using Google. However, we can compile it from source without much problem.
First go to the location that you install scripts, I chose /usr/local/bin, then you grab the latest copy of xhprof and start making it happen.
cd /usr/bin/local
wget http://pecl.php.net/get/xhprof-0.9.2.tgz
tar zxf xhprof-0.9.2.tgz
We then navigate into the extension directory of xhprof, run phpize, configure, and then use make to compile the extension.
cd /xhprof-0.9.2/extension
phpize
./configure
make
make install
make test
You should see that you passed all 8/8 tests. Then add xhprof to your php.ini file and restart apache.
You want to add the following to your php.ini file, mine is in /etc/php.ini
vi /etc/php.ini
[xhprof]
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"
You need apache to be able to write to the folder you have just named so go create it and change ownership to apache:root.
cd /var/tmp/
mkdir xhprof
chown apache:root xhprof
Then restart apache. apachectl -k graceful
The final step mentioned, but not shown at the excellent writeup on techportal.ibuildings.com/2009/12/01/profiling-with-xhprof is that you need to symlink the xhprof_html folder so that you can access the reports in a browser. Do this by navigating to your web root, mine is at /var/www/html and create a symlink.
ln -s /usr/local/bin/xhprof-0.9.2/xhprof_html xhprof
Enjoy using xhprof with the devel module in Drupal and with your other projects.
AMAHI CHOWN and backups
I just finished setting up an AMAHI server for our home office use. It was a fairly straight setup except for the backup folder creation. Supposedly it creates a folder called backups automatically upon installation, that did not occur for me.
AMAHI runs on Fedora 12 which I found out is a bit different than Ubuntu 7+. You cannot just create folders in the HDA directory because you do not login as root and cannot do so from the GNOME GUI. You must do it from the command line.
This is not all that bad, just a bit of an annoyance because of AMAHI stating that backups work with a clean install. Here is how you do it.
First you must open a terminal, Applications -> System Tools -> Terminal. Or I think you can use Alt-F2 and type gnome-terminal.
Then you login as root su - it will prompt you for the root password, enter that and press the enter/return key.
Now navigate to the HDA directory where backups is supposed to be cd /var/hda/files/
List the folders in the files directory ls go ahead and make the backups directory because it is not there. mkdir backups
Again list the folders but show the permissions ls -l
You will see that the folder backups is not accessible to the average user so you have to change the owner and group using CHOWN.
chown user:group backupswhere user is the Fedora user you are using with AMAHI and the group is what you also setup, most likely users.
Now you can navigate to the directory in Nautilus, right click on the backups folder and change permissions to allow read and write so that backups with Ubuntu Simple Backup and Windows 7 built in utility will work. I am sure you can do that on the command line with chmod as well but I am not the best with that command.
Backups setup this way are working wonderfully and I am very pleased thus far with AMAHI.
