monitoring
LAMP + monitoring Zabbix sur un serveur virtuel avec 256 Mo de RAM
Est-il possible d’avoir un serveur web avec PHP + MySQL + des virtual hosts, ainsi qu’un service de monitoring (Zabbix), tout ça dans un VPS avec seulement 256 Mo de RAM ? Et en plus pour 4 € / mois ? Difficile, n’est-ce pas ? :-) En fait non, c’est même large… 140 Mo de RAM suffisent ! En m’inspirant d’un article sur lowendbox.com, et en utilisant un VPS chez l’excellent QuickWeb (OpenVZ VPS Germany 256 à $6/mois), voici rapidement la procédure d’installation sur une base d’install Ubuntu 10.10 toute fraiche :
- On fait un peu de ménage en virant rsyslog, et on installe syslog-ng à la place. Dans la foulée on bazarde portmap, ainsi que bind9 (les DNS de QuickWeb font parfaitement l’affaire) :
apt-get install syslog-ng && dpkg --purge rsyslog apt-get remove --purge portmap apt-get remove --purge bind9
- On supprime openssh, et on installe le tout petit dropbear à la place :
touch /etc/ssh/sshd_not_to_be_run apt-get install dropbear sed -i "s/NO_START=1/NO_START=0/" /etc/default/dropbear /etc/init.d/ssh stop && /etc/init.d/dropbear start echo -e "PATH=/usr/bin:/bin:/usr/sbin:/sbin\nexport PATH" >> ~/.bashrc
- Voilà, on a déjà gagné quelques megs. Passons aux poids lourds… Apache en premier, qui va poliment laisser sa place à lighttpd (et son module de gestion des vhosts) :
/etc/init.d/apache2 stop update-rc.d -f apache2 remove apt-get remove --purge apache2 apt-get install lighttpd mkdir -p /var/www/monitoring.monsite.fr/html lighttpd-enable-mod simple-vhost /etc/init.d/lighttpd force-reload
- Que serait le web sans PHP et MySQL ?
apt-get install mysql-server php5-cgi php5-mysql
cat > /etc/lighttpd/conf-enabled/10-cgi-php.conf
server.modules += ("mod_cgi")
cgi.assign = (".php" => "/usr/bin/php5-cgi")
^D
/etc/lighttpd/conf-enabled/10-simple-vhost.conf :
simple-vhost.server-root = "/var/www"
simple-vhost.document-root = "html"
/etc/init.d/lighttpd force-reload
- On va immédiatement calmer le gros apétit de MySQL :
cat > /etc/mysql/conf.d/mon_tuning.cnf [mysqld] key_buffer = 16K max_allowed_packet = 1M table_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K read_rnd_buffer_size = 256K net_buffer_length = 2K thread_stack = 64K query_cache_limit = 256K query_cache_size = 1M ^D
- Au tour de Zabbix !
apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent le pass root mysql puis le pass db zabbix mysql puis le pass frontend zabbix ln -s /usr/share/zabbix /var/www/monitoring.monsite.fr/html
- On customise un peu le /etc/php5/cgi/php.ini pour faire plaisir à Zabbix :
date.timezone = Europe/Paris post_max_size = 16M max_execution_time = 300 max_input_time = 300
- Un peu de SSL pour sécuriser le tout :
cd /etc/lighttpd/conf-available/ ln -s /etc/lighttpd/conf-available/10-ssl.conf openssl req -new -x509 -keyout server.pem -out server.pem -days 3650 -nodes du bla bla pour generer le certificat... :-) /etc/init.d/lighttpd restart
- Et voilà, secouez bien fort votre VPS, et Zabbix s’offre à vous :
https://monitoring.monsite.fr
Pour 4 petits € / mois, voilà un beau serveur de monitoring, oui ma bonne dame :-) Et rassurez vous, il reste de la RAM dispo, vous pourrez donc y installer encore quelques vhosts (puisqu’il y a du PHP/MySQL, autant se faire plaisir) :
root@quickweb:~# free -m total used free shared buffers cached Mem: 384 138 245 0 0 0 -/+ buffers/cache: 138 245 Swap: 0 0 0
Calcul de la charge CPU réelle
Vous savez tous ce que représente la charge (load average) d’une machine Unix ? Non ? Bon, alors un petit rappel : c’est le nombre moyen de processus en cours d’exécution ou en attente d’exécution. Vous êtes probablement persuadé que sur une machine mono-processeur et mono-core, une charge supérieure à 1 indique que la CPU est totalement utilisée… de même pour une charge supérieur à 4 sur un dual-core hyper-threadé… et bien non, pas forcément. Prenons l’exemple d’un serveur « dédié » à bas prix chez un hébergeur français bien connu, avec un disque monté en iSCSI : De manière générale, les processus passent énormément de temps à attendre (car les accès disques sont extrêêêêêêmement lents). Techniquement ils font donc monter le load-average, puisqu’en attente d’exécution, même si la ou les CPU ne font rien ! Un load-average haut ne signifie donc pas nécessairement que la machine est au taquet ! C’est cependant un indicateur intéressant, et qui révèle souvent un problème ou une saturation des ressources.
Vous savez tous ce que représente la charge (load average) d’une machine Unix ? Non ? Bon, alors un petit rappel : c’est le nombre moyen de processus en cours d’exécution ou en attente d’exécution. Vous êtes probablement persuadé que sur une machine mono-processeur et mono-core, une charge supérieure à 1 indique que la CPU est totalement utilisée… de même pour une charge supérieur à 4 sur un dual-core hyper-threadé… et bien non, pas forcément. Prenons l’exemple d’un serveur « dédié » à bas prix chez un hébergeur français bien connu, avec un disque monté en iSCSI : De manière générale, les processus passent énormément de temps à attendre (car les accès disques sont extrêêêêêêmement lents). Techniquement ils font donc monter le load-average, puisqu’en attente d’exécution, même si la ou les CPU ne font rien ! Un load-average haut ne signifie donc pas nécessairement que la machine est au taquet ! C’est cependant un indicateur intéressant, et qui révèle souvent un problème ou une saturation des ressources.
Mais comment voir la charge CPU réelle alors, et monitorer correctement si les CPU sont surchargés ?
En utilisant /proc/stat, qui nous indique le temps total (en jiffies) passé par les processus en exécution (user, nice, system, etc…). En faisant une différence des valeurs divisé par le temps entre les deux mesures, on obtient la charge CPU consommé dans les différents « états ». Si on ajoute user+nice+system de tous les processeurs/cores divisés par le nombre de processeurs/cores, on obtient la charge CPU réelle de la machine : Si on fleurte avec les 100%, là on est réellement au taquet de la CPU :-)
Voici un petit script bash indiquant la charge CPU totale réelle de la machine, à un instant t :
#!/bin/bash
TIMER=1
function usageCPU {
read cpu user nice system reste < <(grep "^cpu " /proc/stat);
echo "$user+$nice+$system" | bc
}
NB_CPU=$(grep "^processor" /proc/cpuinfo | wc -l)
while true;
do
MESURE_1=$(usageCPU)
sleep $TIMER
MESURE_2=$(usageCPU)
CPU_USAGE=$(echo "scale=2; ($MESURE_2-$MESURE_1)/($TIMER*$NB_CPU)" | bc)
echo "Total CPU usage = $CPU_USAGE%"
done
Dans le même style, il est intéressant de monitorer le 5ème champ de /proc/stat (« iowait« ), pour déceler un goulot d’étranglement sur les accès aux disques, par exemple.
OCS Inventory NG
L’open source est une perpétuelle source de jouissance, on ne s’en lasse pas… OCS Inventory NG permet de répertorier le matériel et la conf de l’ensemble de son parc informatique. Rien que ça. L’interface d’admin est claire et simple, la recherche très puissante (« donne moi toutes les machines qui ont VMware installé », ou bien « les machines sous Linux avec plus de 2 Go de RAM »). Il existe des agents pour les stations Linux et Windows : Chose très agréable, dans les deux cas l’installation et la configuration sont triviales (une IP et un port suffisent). Et dans les contributions, on trouve également des agents pour *BSD, Solaris, AIX et Mac OS X.
Toutes les infos sont stockées dans une base de données (MySQL). Il devient donc trivial de pondre un petit script pour Nagios (à base de SELECT NAME FROM hardware WHERE (LASTDATE < DATE_SUB(NOW(), INTERVAL 2 DAY))), afin d’être alerté si une machine n’a pas envoyé d’update depuis 2 jours, par exemple. Couplé à GLPI, on obtient un système complet de gestion du matériel informatique, et des incidents qui y sont liés… Bref, je vous laisse aller essayer !
