Pour les problèmes de connexion Internet, on ne peut pas faire grand chose
Pour les problèmes de lenteur d’affichage, les outils Yslow et PageSpeed (en ligne via gtmetrix.com ou couplés à Firebug pour Firefox) vous donneront toutes les informations utiles pour optimiser votre site, la CSS, les images, etc.
On s’intéressera ici à la partie Serveur, les raisons sont souvent parmi les suivantes :
- des requêtes trop lourdes ou trop fréquentes, ou les deux
- des processus (tâches, générations de fichiers) trop longs (parfois à cause des requêtes)
- des serveurs « extérieurs » qui appellent vos scripts/images trop souvent (un gros site qui appelle vos images fera planter votre serveur si vous n’êtes pas dimensionné pour son trafic)

Requêtes trop lourdes

Connectez-vous en ligne de commande (SSH) à votre console MySQL (ou via phpMyAdmin dans l’onglet processus sur l’accueil) et regardez les processus en cours (commande SQL « SHOW FULL PROCESSLIST; »), vous en verrez peut-être des récurrentes, ou des longues. Maintenant, vous savez quoi optimiser.

Si votre processlist est souvent vide ou pleine de « sleep », tout va bien. S’il y a trop de sleep avec une durée trop longue, réduisez votre timeout ou utilisez mysql_connect plutôt que mysql_pconnect. 2mn peut être une durée honnête pour un timeout.

Identifier les scripts consommateurs

Pour identifier les scripts consommateurs, il est intéressant d’utiliser un petit programme : Apachetop (apt-get install apachetop sous debian – comment installer ?)

Pour voir l’état du serveur, il est bon d’utiliser htop (apt-get install htop sous Debian),

Identifier les extérieurs

Pour voir les extérieurs qui appellent vos scripts, rien de tel qu’un bon vieux tail -f /var/log/apache2/error.log (à modifier par votre nom de fichier d’erreur)

• Identifiez-vous en root sur le Shell du serveur considéré
• Pour optimiser MySQL, on va s’intéresser principalement au fichier /etc/mysql/my.cnf (généralement ainsi situé, notamment sur les distributions Debian, mais n’hésitez pas à faire un # locate my.cnf pour identifier la localisation de ce fichier et vérifier s’il n’y a pas de doublon)
• nano /etc/mysql/my.cnf (éditons la configuration)


[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
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
# pour utiliser moins de mémoire, si on n'utilise pas Berkeley DB on ajoute cette ligne
skip-bdb
# idem si on n'utilise pas InnoDB
skip-innodb
# de la même façon, si on n'utilise pas InnoDB, on peut commenter les lignes suivantes
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# Vous pouvez définir .._buffer_pool_size entre 50 et 80 %
# de la RAM mais attention à ce que l'utilisation globale de RAM par MySQL ne soit pas trop important (à suivre)
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Définissez .._log_file_size à 25% du buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Décommentez la ligne suivante si vous n'êtes pas familier avec SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout

Quelques paramètres qui nécessitent attention

query_cache_size

MySQL fournit une fonctionnalité qui peut s’avérer très pratique : un cache de requêtes. Lorsqu’une même requête est exécutée plusieurs fois, et retourne les mêmes résultats à chaque fois, MySQL peut mettre en cache le résultat, ce qui décharge assez le serveur.

key_buffer

La valeur de key_buffer_size est la taille du buffer utilisé pour les index. Plus il y a de mémoire tampon, et plus rapidement la commande SQL se termine et un résultat sera retourné. La règle de base est de régler le key_buffer_size à au moins un quart, mais pas plus de la moitié de la quantité totale de mémoire sur le serveur. Idéalement, il sera assez grand pour contenir tous les index (la taille totale de tous les fichiers .MYI sur le serveur).

table_cache

La valeur par défaut est 64. Chaque fois que MySQL accède à une table, il la place dans le cache. Si le système accède à de nombreuses tables, il est plus efficace d’avoir ces tables dans le cache. MySQL, étant multi-thread, peut exécuter de nombreuses requêtes sur une table au même moment, et chacune de ces requête va ouvrir une connexion avec la table. Examinez la valeur de open_tables aux heures de pointe. Si vous trouvez qu’il reste à la même valeur que la valeur de votre table_cache, puis que le nombre de opened_tables commence à augmenter rapidement, il faut augmenter la taille du table_cache si vous avez suffisamment de mémoire disponible.

sort_buffer

Le sort_buffer est très utile pour accélérer les opérations myisamchk (c’est pourquoi il est défini beaucoup plus haut dans les fichiers de configuration par défaut), mais il peut aussi être utile lors de l’exécution quotidienne un grand nombre de classements (fonctions comme sort(),…).

thread_cache

Si vous avez un serveur surchargé à force de recevoir un grand nombre de connexions rapides, définissez votre thread_cache suffisamment haut pour que la valeur threads_created de SHOW STATUS (commande SQL) cesse d’augmenter. Cela devrait décharger un peu le CPU.

Autres optimisations MySQL

Bien souvent, c’est sur les jointures que se jouent les lenteurs. Utilisez les jointures à bon escient, vérifiez que pour chaque clé utilisée dans les jointures, il existe bien un index sur ce champ clé, sinon créez-le tout de suite et ça fera une grande différence.

Les chiffres pèsent moins lourd dans les index que les lettres, par conséquent, préférez les clés numériques pour vos jointures de grosses tables pour éviter de trop surcharger vos index.

Apache

Le principal problème avec Apache est la quantité de RAM qu’il utilise. Nous allons voir comment baisser la quantité de RAM utilisée par Apache.

• Charger moins de modules
• Faire moins de demandes simultanées
• Recycler les processus Apache
• Utiliser les KeepAlive, mais pas pour trop longtemps
• Réduire vos timeout
• Créer moins de logs
• ne pas résoudre pas les Hostname
• N’utilisez pas les .htaccess

Cela nécessite d’avoir deux serveurs, puisque l’un doit faire un « ping » sur l’autre qui doit répondre (« pong »). Appelons le serveur à tester Frodon et celui qui le teste Gandalf.

Sur Gandalf, créez un script sh :
touch /home/checkFrodon.sh
chown u+rwx /home/checkFrodon.sh

Editez ensuite checkFrodon.sh (apt-get install nano si nano n’est pas installé) :
nano /home/checkFrodon.sh

Mettez-y ceci :

ping -c 1 "monsiteatester.fr" > /dev/null 2>&1
if [ $? -eq 0 ] ; then
echo "=> running"
else
echo "=> not running"
mutt -s "[MONSITE] Ping monsisteatester.fr nok - serveur down ?" monemail@gmail.com < /home/checkFrodon.sh
fi


Testez le script en question :
/home/checkFrodon.sh
Cela vous affichera dans le shell suivant les cas "=> running" ou "=> not running". Et si ça vous affiche not running, ça vous enverra un e-mail contenant le contenu du script SHELL pour rappel.

Pour l'automatiser, il vous suffit de créer un cron faisant appel au script en question toutes les minutes, toutes les 5 minutes, toutes les heures, comme vous voulez.

Enjoy !

Surtout, si vous avez mieux, n'hésitez pas !

Oh, je parlais de SMS également, parce qu'il suffit dans la condition de faire appel grâce à la commande wget à la requête explicitée ici : http://api.orange.com/fr/api/sms-api/imprimer

wget http://run.orangeapi.com/sms/sendSMS.xml?id=[votre API Access Key]&from=[numéro court d'émission]&to=[numéro de téléphone]&content=[votre message à envoyer]&long_text=[activer ou non le SMS long]&max_sms=[nombre maximum de "parties" d'un SMS long]&ack=[activer ou non l'accusé de réception]

8,36€ le crédit de 1000 SMS... ça se regarde ! (Cf grille tarifaire Orange)

Bonus : si vous voulez tester qu'une chaine apparaît bien sur une page web (car auparavant, on ne teste que le ping, et un serveur ping même si le serveur web est tombé, il vaut donc mieux tester que le rendu Web se fait bien). Ici, on teste que l'identifiant Google Analytics existe bien dans le code source de la page, mais ça pourrait être autre chose :

cd /tmp/
rm -f /tmp/index.html*
wget monsite.fr
if [ "$(cat /tmp/index.html | grep "UA-XXXXXX-1" )" = "" ] ; then
mutt -s "[MONSITE] apache or mysql down ?" monadresse@gmail.com < /home/checkFrodon.sh
echo "monsite.fr web not running"
else
echo "monsite.fr web running"
fi

Pour cela, rien de plus simple, une commande vous permet de vous synchroniser avec un serveur donné.

Exemple :
ntpdate ntp.univ-lyon1.fr

Après, il vous suffit de programmer un cron (automate) tous les jours à 2, 3 et 4h et vous êtes relativement tranquilles.

Pour rappel, vous pouvez souvent programmer un cron grâce au webmin de votre serveur, rubrique Système > taches cron (si vous n’avez pas webmin, installez-le !) ou en ligne de commande (man crontab si ça vous amuse)

Pour vérifier l’heure de votre serveur, il vous suffit d’afficher la date courante :

echo $(date '+%H.%M.%S')

ATTENTION pour les débutants, si les commandes que vous faites ne fonctionnent pas, certaines nécessitent d’être connecté en « root ». Pour ce faire, tapez la commande « su » et tapez le mot de passe root pour avoir les pleins pouvoirs.

Nous allons utiliser Very Secure FTPd (autrement appelé vsftpd qui équipe des serveurs FTP tels que ceux Red Hat, Suse, OpenBSD, kernel.org et bien (bien sûr) Debian.

Loggez vous en root et tapez :
# apt-get install vsftpd

Une fois vsftpd installé, il faudra remplacer le fichier de configuration /etc/vsftpd.conf par le suivant :

# Nous voulons que le serveur fonctionne en mode standalone
listen=YES
#
# On ne veut surtout pas de connexions en mode anonymous
anonymous_enable=NO
#
# On veut que les utilisateurs locaux puissent se connecter
local_enable=YES
#
# On veut que les utilisateurs puissent remonter des fichiers sur le serveur
write_enable=YES
#
# On fixe le masque local a 022 (les fichiers remontés auront des droits en 755)
local_umask=022
#
# On interdit l’upload anonyme
anon_upload_enable=NO
#
# Idem pour la creation de repertoires
anon_mkdir_write_enable=NO
#
# On demande a ce que les actions des utilisateurs soient loggees
xferlog_enable=YES
#
# On verifie que la commande PORT provienne bien du port 20 de la machine cliente
connect_from_port_20=YES
#
# Les logs seront enregistres dans le fichier /var/log/vsftpd.log
xferlog_file=/var/log/vsftpd.log
#
# On declare les valeurs de timeout. Celles fournies par defaut sont ok pour notre utilisation
idle_session_timeout=300
data_connection_timeout=120
connect_timeout=60
accept_timeout=60
#
# Par securite, on interdit la commande ABOR
async_abor_enable=NO
#
# Les transferts en ASCII sont souvent source de confusions
ascii_upload_enable=NO
ascii_download_enable=NO
#
# Par securite, on change la banniere
ftpd_banner=Bienvenue sur le serveur Debian Addict
#
# On veut limiter les utilisateurs a leur repertoire
chroot_local_user=YES
chroot_list_enable=NO
#
# Les heures d’enregistrement des fichiers seront affichees a l’heure locale
use_localtime=YES

Une fois le fichier de configuration remplacé, on relance le serveur FTP en tapant en root :
# /etc/init.d/vsftpd restart

A partir de ce moment, les utilisateurs ont accès à leurs répertoires personnels via FTP et leurs actions sont enregistrées dans le fichier /var/log/vsftpd.log.

Il nous reste donc à créer un répertoire commun auquel chacun aura accès. Pour cela, on crée un utilisateur lambda que l’on appellera « commun » [1]. En root, tapez :
# adduser identifiantutilisateur

Le système demande ensuite le mot de passe de l’utilisateur puis différents renseignements qui sont à passer. Ce n’est PAS le mot de passe FTP, juste le mot de passe de l’utilisateur.

NB : Pour connaître les utilisateurs existants, en faisant cat /etc/passwd ou cat /etc/group, cela affiche les utilisateurs et les groupes qui existent dans ces fichiers, à savoir que les commandes getent passwd et getent group affichent en plus les utilisateurs de tous les annuaires connus.

Définition des droits sur le
# chmod -R 755 /home/identifiantutilisateur
# chown identifiantutilisateur:identifiantutilisateur -R /home/identifiantutilisateur

A ce stade, si on essaie de s’identifier avec un utilitaire FTP, le client arrivera à se connecter au serveur mais il proposera une belle erreur 530 vsftpd FAIL LOGIN: Client
Il faut donc continuer et préciser les utilisateurs/mots de passe que l’on veut pour le FTP

Nous allons utiliser une base de données pour les noms et mots de passe des utilisateurs virtuels.

On a besoin d’un utilitaire de base de données qui nous servira à hasher les couples identifiant/mot de passe.

Dans le répertoire /etc/vsftpd/ nous allons créer un fichier login.txt contenant les infos de login, il est formé sous cette forme :


user1
pass1
user2
pass2
user3
pass3


Attention, ici, l’éditeur de Winscp par exemple rajoute une ligne à la fin, même si on n’en a pas l’impression, ce qui affiche le message « db4.6_load: odd number of key/data pairs« , il suffit alors de vérifier en SSH en utilisant la fonction nano par exemple :

nano /etc/vsftpd/login.txt
une fois la dernière ligne vide supprimée s’il y en a une, faites Ctrl+X pour quitter, et confirmer avec un O majuscule puis entrée

Une fois le fichier fait, nous créons la base de données qui serat utilisé par PAM :
Installez db4.6 :
apt-get install db4.6-util
puis hashez les données du fichier login.txt dans un format sécurisé et compréhensible par vsftpd :

db4.6_load -T -t hash -f /etc/vsftpd/login.txt /etc/vsftpd/login.db

On sécurise les fichiers

chmod 600 /etc/vsftpd/login.db
sudo chmod 600 /etc/vsftpd/login.txt

Il faut informer le module PAM, dans le fichier etc/pam.d/vsftpd :

auth required /lib/security/pam_userdb.so db=/etc/vsftpd/login
account required /lib/security/pam_userdb.so db=/etc/vsftpd/login

Et voilà, vous pouvez vous connecter via le port 21 normalement.

Merci pour vos retours !

Sources :
http://www.debianaddict.org/article47.html
http://olange.developpez.com/articles/debian/installation-serveur-dedie/?page=page_5
http://www.cpasdemoi.fr/securisation-ssl-et-utilisateurs-pour-le-serveur-ftp-vsftpd-sur-debian-lenny/
http://doc.fedora-fr.org/wiki/Vsftpd_:_Installation_et_configuration
http://www.developpez.net/forums/d744109/systemes/linux/reseau/vsftpd-serveur-dedie/

ATTENTION : vérifiez bien les droits d’accès autres que SSH aux utilisateurs que vous créez !!
Lire ceci : Autorisations SSH pour les utilisateurs (compatible Debian)
En deux mots :
1. précisez grâce à un AllowUsers monutilisateur1 monutilisateur2 dans /etc/ssh/sshd_config qui est autorisé
2. vous pouvez faire idem avec les groupes (AllowGroups group1 group2)
3. redémarrez ssh avec /etc/init.d/ssh restart
4. Faites des tests !

Une bonne commande pour faire cela est mysqldump, Pour faire cela, vous devez utiliser le shell (via putty par exemple) pour vous connecter sur votre serveur dédié ou sur votre poste de travail sous linux. Si vous êtes sur un serveur mutualisé, il faut que vous voyez avec votre hébergeur, pourquoi pas dans votre interface d’administration si vous en avez une.

MySQLDump prépare le script pour (re-)créer les tables et le contenu de celles-ci, prêt à être importé plus tard.

La commande au plus simple :

mysqldump -u [nomUtilisateur] -p [motDePasse] -B [nomBDD] > [fichierSauvegarde].dump

Si vous ne saisissez pas le mot de passe mais laissez -p il vous demandera de donner le mot de passe. Si vous souhaitez éviter de dévoiler le mot de passe dans l’historique, c’est mieux.

Vous pouvez également ajouter une option pour optimiser la requête.

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] > [fichierSauvegarde].dump

Ceci permettra de supprimer les tables (DROP) avant qu’elles ne soient recréées puis remplies de leur contenu.

Pour des raisons évidentes de taille de base de données, il est parfois bien de compresser (gzipper) le fichier extrait :

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] | gzip > [fichierSauvegarde].dump.gz

Le jour où vous souhaitez réimporter votre base, il suffit d’inverser la flèche. (Attention à dézipper le fichier au préalable – gunzip – s’il était gzippé)

mysql [nomBDD] < [fichierSauvegarde].dump

Pour savoir où sont les fichiers : commande pwd pour voir où vous êtes

La documentation Man de MysqlDump avec toutes les options :

http://www.manpagez.com/man/1/mysqldump/

Tout est ici : http://www.lephpfacile.com/manuel-mysql/mysql-optimization.php#tips

- vérifier les index / créés vs qui devraient exister
- types de tables (MyISAM,…)
- éviter les varchar et blob pour ce qui est régulièrement modifié
- pas forcément utile de scinder les grosses tables en plus petites
-…

Une petite check-list à se faire de temps en temps !

Tout ceci se fait de façon visuelle en créant des étapes et en éditant le détail de chaque étape. (je sais, ça dépasse.. mais comme ça on peut tout voir )

Visuel de la préparation de scripts avec Kettle

Il est possible de faire des scripts personnalisés sous forme de script java (javascript)

Exemples de sources et exports possibles :

• Bases de données (37 bases de données disponibles dont MySQL, Oracle, SQLite, PostgreSQL, MS Access, MS SQL Server, Sybase, Firebird SQL, AS/400,…)
• Fichiers (XML, TXT, CSV, PSV, TSV ou autres séparateurs, instructions SQL dans fichier,
• Flux SOAP, REST
• Récupération ou envoi depuis ou vers des FTP/SFTP/FTPS/over SSH2
• Possibilité de dézipper ou zipper des fichiers en entrée ou en sortie
• Envoi / récupération depuis ou vers des e-mails / courriels (suivant sensibilité)

Comme les exemples sont souvent plus parlants, je vais vous donner quelques exemples bien pratiques de choses que l’on peut faire avec un ETL :

• récupérer un fichier XML à 10 niveaux de données depuis un FTP, l’aplatir sous forme de tableau, mettre à jour les données dans une table MySQL puis l’exporter sous forme de fichier CSV et l’envoyer par e-mail
• joindre trois fichiers excel (format XLS) et les entrées en base de données en comparant les sources, en dédoublonnant, et en faisant un fichier par type d’erreur possible
• prendre tout simplement un fichier, renommer des colonnes, en rajouter, normaliser la longueur des champs et le nombre de décimales, enlever les espaces vides et réexporter le tout dans un format souhaité

Les scripts réalisés visuellement sont exportables et installables comme tâches planifiées sur un serveur.

Bon, pour tout ça, je vous conseille de télécharger la version Pentaho Data Integration Spoon 4.0 (http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=spoon+4.0)

Je vous mets ici bientôt quelques exemples de scripts que vous puissiez jouer avec.

Il était amusant de voir que cette fonctionnalité était possible mais qu’elle était juste refusée au niveau de la requête par Google : si vous lisiez via le navigateur le flux JSON, vous y voyiez des informations intéressantes telles que la distance et l’itinéraire pour aller d’un point A à un point B, qu’on aurait tout à fait pu parser. Mais Google le refusait.

Cette annonce n’a l’air de rien : http://googlegeodevelopers.blogspot.com/2010/05/directions-web-service-arrives-at.html mais c’est une révolution pour ceux qui souhaitent intégrer des calculs de distance, ou faire des PDF avec des itinéraires ou ce genre de choses.

Concrètement, le flux que vous recevez ressemble à ceci :

{
« status »: « OK »,
« routes »: [ {
« summary »: « Massachusetts Ave, Massachusetts 2A W et Lexington Rd »,
« legs »: [ {
« steps »: [ {
« travel_mode »: « DRIVING »,
« start_location »: {
« lat »: 42.3585300,
« lng »: -71.0600700
},
« end_location »: {
« lat »: 42.3580200,
« lng »: -71.0604300
},
« polyline »: {
« points »: « ycpaGl|upLdBfA »,
« levels »: « BB »
},
« duration »: {
« value »: 4,
« text »: « 1 minute »
},
(…)

(http://maps.google.com/maps/api/directions/json?origin=Boston,MA&destination=Concord,MA&waypoints=Charlestown,MA|Lexington,MA&sensor=false
Enjoy !

Source : https://mail.google.com/mail/?hl=fr&shva=1#inbox/128b3a8d28ec3fd6
Autres API qui viennent de sortir : http://www.zorgloob.com/2010-05/google-fait-le-plein-dapi/

Le script PHP permettant de calculer l’itinéraire est ici : PHP : distance en kilomètres, durée et étapes du trajet grâce à Google Maps API Directions

Google Analytics a mis en bêta un système d’alertes qui permet d’être notifié (uniquement par e-mail pour l’instant) lorsque les conditions de ces alertes sont remplies. il s’agit de définir des critères et de remplir un seuil.

Ce qui permet par exemple de dire « si mon nombre de visiteurs uniques par jour est supérieur à X, me prévenir par e-mail ».

Tout simplement.

Reste à faire évoluer le système en fonction, pourvu qu’il soit agile !

De base, cela ne monitore que si les services Apache (si on regarde le port 80 / http) sont up ou down et non si les pages sont fonctionnelles (on ne verra pas les erreurs PHP mais on va pouvoir trouver des solutions pour cela.. bientôt)

Chaque SMS envoyé coûtera 10 centimes débités sur le compte. Soit le prix d’un SMS que vous envoyez avec n’importe quel mobile.

0. Allez sur l’interface API SMS d’Orange, inscrivez-vous, créditez votre compte de 10€ pour le test (cochez éventuellement la case renouvellement automatique) et dans l’onglet « key », notez bien votre clé API.
1. Mettez en ligne le script (cliquez ici pour télécharger) sur un serveur autre que celui que vous souhaitez monitorer et allez à son adresse en ajoutant /install/ à la fin et suivez les instructions (attention, il n’y a pas d’espaces de nom sur les tables…)
2. Allez dans la table « logs » et ajoutez une colonne « message ». Elle servira à reccueillir lors d’un problème un arrêté de l’e-mail envoyé. Cela peut toujours servir.
3. Ouvrez le fichier cron.php qui se trouve à la racine du répertoire PHPWatch et insérez le code suivant en lieu et place de l’existant :

<?php
// A qui on envoie des SMS en cas de problème ?
$contactsMonitoringSMS=Array(
‘RomainMobile’=>’33679241180′,
‘CollegueMobile’=>’336XXXXXX’,

);
// A qui on envoie un mail en cas de problème ? (en parallèle)
$contactsMonitoringEMAIL=Array(
‘RomainPerso’=>’monemail@gmail.com’
,’ServiceInformatique’=>’monemailpro@maboite.com’
);

define(‘PATH_TO’, ‘./’);
require_once(PATH_TO . ‘common.php’);

$all = ServiceChecker::getReport();

foreach($all as $monitors)
{
foreach($monitors as $monitor)
{
$monitor['derniereFoisOffline']=date(« d/m/Y H:i:s »,$monitor['last_offline']);
// print_r($monitor);
if(!$monitor['online'])
{
$message = $monitor['host'] . ‘ HORS LIGNE. NOTIFICATIONS ENVOYEES. (/!\\ PHASE DE TEST, A VOIR SI C FIABLE)’;
echo $message;

foreach($contactsMonitoringSMS as $prenom=>$numero) {
$phone_number = $numero;
$contactsEmail= »"; foreach($contactsMonitoringEMAIL as $prenom=>$email) $contactsEmail.= » [".$prenom."] « ;
$contactsSMS= »"; foreach($contactsMonitoringSMS as $prenom=>$numero) $contactsSMS.= » [".$prenom."] « ;

// attention, on coupe le message à 155 caractères
$sms=$monitor['host']. » HS – SMS : « .$contactsSMS. » – @ : « .$contactsEmail;
if(strlen($sms)>159) $sms=substr($sms,0,154).’[...]‘;
$text_message = urlencode($sms);
$api_access_key = ‘dexxxx5ac’; // Mettez votre clé API – disponible sur l’API Manager
$url = « http://sms.alpha.orange-api.net/sms/sendSMS.xml?id=$api_access_key&to=$phone_number&content=$text_message »;
$response = file_get_contents($url);
$xml = simplexml_load_string($response);
echo « Status: « ,$xml->status->status_msg;

}
foreach($contactsMonitoringEMAIL as $prenom=>$email) {
$to = $email;
$subject = $message;
ob_start();
echo $message;
echo « \nE-mails envoyes a :\n »;
print_r($contactsMonitoringEMAIL);
echo « \nSMS envoyes a :\n »;
print_r($contactsMonitoringSMS);
echo « \nDetails Erreur :\n »;
print_r($monitor);
$msg=ob_get_contents();
ob_end_clean();
$headers = ‘From: Roms Monitoring ‘. »\r\n »;
//$headers .= ‘Bcc: Moi ; lui ‘. »\r\n »;
$headers .= « \r\n »;
mail($to, $subject, $msg, $headers);
}
NotificationHandler::sendNotifications($monitor);
}

$requete=’INSERT INTO logs (monitor, timestamp, online, message) VALUES
(‘ . $monitor['id'] . ‘, ‘ . time() . ‘, ‘ . ($monitor['online'] ? 1 : 0) . ‘, \ ».addslashes($msg).’\')’;
$GLOBALS['PW_DB']->query($requete);
}
}
?>

4. Créez le cron qui va bien dans le crontab si vous avez un serveur dédié (autre que celui monitoré évidemment – en faisant un wget http://www.monsite.com/repertoirePHPWatch/cron.php).
Si vous avez un mutualisé chez OVH (type 60gp, 90plan,…), vous pouvez aller dans votre manager OVH, rubrique « Mutualisé » > « Hébergement » > Planificateur de tâches et créer une tâche qui lance le fichier cron.php chaque heure.
Si vous n’avez ni l’un ni l’autre, vous avez toujours WebCron.org ou ça..
Ou bien, si vous avez des amis qui ont un dédié, c’est le moment de les solliciter, c’est pas bien méchant un cron..
Réserves : attention, il s’agit d’une première version de développement, tous les composants sont en phase bêta. Vous aurez remarqué également que lorsqu’on dit dans le message envoyé « NOTIFICATIONS ENVOYEES », on n’a pas vérifié que c’était effectivement le cas… Par ailleurs, on peut imaginer monitorer l’état réel d’un script en jouant avec les entêtes renvoyées ou avec des contenus de la page. Pour l’instant, cette version me convient.

Tous retours d’expérience bienvenus pour compléter ce tutoriel.

Si c’est le domaine qui ne répond pas
1. Faire un ZoneCheck pour voir si les DNS sont correctement configurés : http://www.afnic.fr/outils/zonecheck/zc.cgi?zone=guide-sensations.com
1.a si ça vous répond qu’il y a un problème avec les SOA, c’est qu’il y a un problème dans les réponses SOA de votre serveur : à voir dans les BIND ou dans les configurations & RNDC (named.conf, named.conf.options,…)
1.b si ça cherche les DNS et que ça met que les zones ne sont pas cohérentes, il faut vérifier 3 points : les DNS bien configurés chez le registrar (ovh, gandhi, bookmyname, amen,…), le reverse bien défini pour les serveurs dédiés (ovh pour l’exemple : Manager OVH > Services > DNS Secondaires), et les SOA bien définis sur le serveur (Serveur BIND à configurer) dans les 3 cas, l’IP et les NS (primaire et secondaires) doivent correspondre. Un dig (http://www.webmaster-toolkit.com/dig.shtml?address=guide-sensations.com) vous aidera à vérifier la configuration en cours.
1.c une fois une modif faite, ça peut prendre du temps à se répercuter (jusqu’à 6 jours chez Orange..), il faut tester chez plusieurs FAI autant que possible pour voir si ça commence à se propager ou pas et faire quelques nslookup pour tester depuis les serveurs souhaités si la propagation se fait bien (windows : exécuter > cmd > nslookup). Exemple
# nslookup
# > server 212.216.212.112 (tester les IP par FAI à cette URL : http://www.commentcamarche.net/faq/sujet-1496-serveurs-dns-des-principaux-fai)
# > guide-sensations.com
et là ça vous sortira l’IP qui est prévu pour ce nom de domaine suivant la propagation des infos sur ce serveur là et donc vous aurez les infos de propagation par FAI.
1.d vérifiez à cette adresse : http://www.zonecut.net/dns/ avec un bon visuel que tout est ok.

Si c’est le serveur qui est en panne

1. Tester les services les uns après les autres et les restarter s’ils sont tombés
2. à côté, il est bon d’être connecté en SSH et de faire un tail -f /var/log/syslog pour voir ce qu’il se passe et l’erreur éventuelle qui se produit (avec le fichier et la ligne de l’erreur avec un peu de chance)
3. N’oubliez pas de faire un fcsk de temps en temps

Je vous invite à lire cet excellent article du site haute-disponibilite.net qui reprend un document de présentation d’une société spécialisée.

http://www.haute-disponibilite.net/2008/09/25/planning-des-evolutions-de-votre-architecture-web/

C’est un début et c’est une proposition, ça a le mérite d’exister.

php -i | grep php.ini

En espérant vous avoir aidé !

Pour utiliser SSH, utilisez Putty sur Windows, ou le terminal sur Mac et Linux; Sur le terminal, entrez la commande « ssh userSSH@ipServeur » ce qui vous invitera à entrer le mot de passe de l’utilisateur « userSSH ».

top
=> indique les processus appelés
=> pendant l’exécution, taper « A » pour avoir des informations sur les tâches, « U » pour classer les processus par %CPU
=> faire ctrl+C (même sur Mac) pour en sortir

time wget URL
=> vous indique le temps pris pour exécuter telle URL

ps aux
affiche des informations sur les processus en cours
==> ps aux | grep ssh vous permet d’afficher les utilisateurs SSH connectés

find /path/to/directory/ -type f -name « fichier.ext » -exec ls -alF {} \; | grep « toto »
==> permet de faire afficher sous forme de liste avec fichier et date les fichiers trouvés à l’aide de la commande find