- EN - Monitoring for Web apps based on Selenium Webdriver, FB Chrome Driver, RRDTool et NSCA
- FR - Supervision d'applications Web basée sur Selenium Webdriver, FB Chrome Driver, RRDTool et NSCA
- Define a scenario in wich you describe steps to test if a website is available, if login is successful, if different links work and get response time for each step plus total time.
- Each scenario is written in a seperate file, stored in the
testcasesfolder and contains the steps to use, so you can define different steps and actions for each one. - The TestSelenium script is lightweight and fast, so you can use it not only for unit testing, but also for monitoring your apps. That's why it's packed with RRDTool and NSCA integration.
- PHP Object Oriented scripts
- Selenium WebDriver https://www.seleniumhq.org/
- FB Chrome Driver https://github.com/facebook/php-webdriver
- RRDTool https://oss.oetiker.ch/rrdtool/
- NSCA https://exchange.nagios.org/directory/Addons/Passive-Checks/NSCA--2D-Nagios-Service-Check-Acceptor/details
- PHPMailer https://github.com/PHPMailer/PHPMailer
The TestSelenium Class should be called for each software you want to check, with arguments containing the config file to use and the name of the scenario. It performs checks and then runs the scenario, returning durations to Cacti or mailling the admins if an error is encountered. It's designed to be called regularily from a command in a CRONTAB. Another tool (statusFileGen) read Nagios status.dat file and generates separate .status files for each software.
AppMonitor is design to work with Nagios and Cacti, by designing specific scenarios that check different actions a user would execute in a specific online software. At the heart, there is TestSelenium.php, that should be called for each software, each time you want to check it :
- It takes arguments to call a specific scenario, a config file (could be different for dev or production environnement), and load the libraries (via composer, for example : FB-Webdriver).
- It also calls the config file to check for the presence of the needed folders.
- It uses some homemade libraries : NiceMail (built on top of PHPMailer), NiceSSH (to create folders in the hosts that will get the status files) and a NSCA PHP library to send status to the Nagios server.
- It loads a Wrapper Class (DriverWrapper) that helps manage the FB-ChromeDriver.
- THEN it calls the Scenario Class, passing it the Driver and the name of the Scenario to execute, returning a specific scenario, with steps designed to fit one software.
- Right after that, it checks if the same scenario (launched by a precedent instance of the Testselenium) is still running to avoid stacking up multiple NSCA requests or connections to the same software.
- Since the script is design to work with Cacti, we need to call a class that will generate RRD files and send the duration of each step of the scenario : this is ReportingTool.
- To be sure that we send values, even in case of a TimeOut or error, we use the destructor of the ReportingTool class to do multiple things :
- Send NSCA request
- Gather the durations of the tasks
- Update the RRD files
- Delete the lockfiles
- Then it checks that the Chrome WebDriver is responding by calling a "dummy page", on the same network.
- AT LAST, a loop runs the scenario throught each of the steps, getting duration, recording it the reporting tool, taking screenshots and logging errors during the process, sending mail with details if an error has occured.
- Finally, it cleans things up by deleting screenshots files and destroying ReportingTool (provoking NSCA and RRD updates), Scenario and Mail instances.
Each test is lightweight enough to be called every minute, so the RRD file is almost updated in realtime.
We added a special tool, statusFileGen, that can read the "status.dat" generated by Nagios, find the services in the host (provided in config), read their status and generate .status files for each one (so you can read them from another script - see ListAppn a little further).
Clone or Copy the content of the folder into an apache server
To keep realtime track of the status of your software, you should set up a CRONTAB task to execute the test regularily.
You can get graphs in Cacti showing the response times of your softwares. In the config file, set the pathes for rrdtool and rrdupdate on your server. The ReportingTool Class is called with the name of the scenario (corresponding to the name of the service in Nagios) and creates a .rrd file if it doesn't already exists.
When the scenario ends, it triggers the destruction of the RRD object and the update of the times throught rrdupdate.
For now, the names of the steps are defined in Nagios as :
- home
- login
- actions
- logout
All your scenarios MUST have steps names consistent with the ones declared in Nagios.
You need to set up a SMTP server.
(doc in progress)
(doc in progress)
- $DEFAULT_DEST = array(), Liste des destinataires des mails
- $DEFAULT_REPLY = array(), Liste des destinataires des réponses
- $DEFAULT_EXP_MAIL = string, Adresse de l'expéditeur
- $DEFAULT_EXP_NAME = string, Nom de l'expéditeur
- $SMTP = 'smtp.saintmaur.local', Serveur SMTP
- $CREATE_DIR_IF_ABSENT = boolean, TRUE pour créer les dossiers FALSE pour arrêter le script si un dossier est manquant, sans le créer.
- $SCREENSHOT_DIR = string, chemin pour enregistrer les screenshots
- $TEST_COMM_URL = string, URL d'une page accessible sans passer par internet pour tester le fonctionnement du ChromeDriver
- $SELENIUM_HOST = string, URL to a running selenium server
- $SELENIUM_HOST_NAME = string, Nom du serveur sur lequel le test est effectué
- $CHROME_OPTIONS = ["--start-maximized","--headless","--no-default-browser-check","--incognito", "--window-size=1920,1080", "--no-sandbox", "--disable-setuid-sandbox"], Options pour le ChromeDriver (array)
- $RRD_TOOL = "/opt/rrdtool-1.7.0/bin/rrdtool", Emplacement du fichier rrdtool
- $RRD_UPD = "/opt/rrdtool-1.7.0/bin/rrdupdate", Emplacement du fichier rrdupdate
- $RRD_DEFAULT_FILE = "default.rrd", Nom par defaut du fichier RRD
- $SSH_HOSTS = array("www03-p.dmz.saintmaur.local", "www04-p.dmz.saintmaur.local"), Un array de noms de serveurs auxquels envoyer les fichiers .status
- $SSH_PORT = 22, Port SSH
- $SSH_FP = "19:f8:27:1f:df:64:02:d4:38:5d:83:16:f7:dc:91:cf", Fingerprint
- $SSH_AUTH_USER = 'root', Login
- $SSH_AUTH_PUB = '/root/.ssh/id_rsa.pub', Clé publique
- $SSH_AUTH_PRIV = '/root/.ssh/id_rsa', Clé privée
- $NAGIOS_DAT_FILE_DIR = "/srv/eyesofnetwork/nagios/var/log/", //dossier où trouver le fichier DAT de Nagios
- $NAGIOS_HOST_NAME = 'Applications', //nom du host Nagios dans lequel se trouvent les services
- $STATUS_FILE_DIR = "/var/www/html/listapp/app_status/",//dossier où stocker les fichiers .status
- $CONNECT_TIMEOUT = 15000,
- $QUERY_TIMEOUT = 120000,
- $LOCKFILE_FOLDER = './lockfiles/', Emplacement des fichiers lockfile
- $LOCKFILE_MIN_EXPIRE = 600, //10 minutes - temps de validité du fichier lockfile
- $EON_SRV = 'localhost', nom du serveur pour les requêtes NSCA
Arguments : -s (obligatoire) pour le nom du scenario; -c (facultatif) pour le fichier de config à utiliser; -i (facultatif)pour l'intervalle horaire permis pour les mails; -v (facultatif)pour le mode verbose; -h ou -help (facultatif) liste les paramètres;
In order to run, TestSelenium.php needs at least a scenario name corresponding to a scenario PHP file stored in the "testcases" folder and a config file (config.php by default).
For example :
php TestSelenium.php -sAdmimail -cprod_config.php-v is a verbose mode where every step is output to the console, great for debugging.
-i can limit the amount of mail sent by delimiting a time span allowed for it.
For each software you want to test, you need a scenario file that explain the different step to perform.
It's important to note that the name of the scenario called in the command line must be the same (case sensitive) as the filename of the scenario file, and the same (case sensitive) as the Class declared in it.
For example :
php TestSelenium.php -sAdmimailWill call the file Admimail.php in the testcases folder and this file must contain a class called Admimail. Each scenario file extends the scenario Class, wich is used to give some variables and functions to the scenario, for example :
- the names of the steps you want to use (can be overwritten in each scenario, but useful if all scenario use the same steps, see further on that)
- the createScenario() function, used to instanciate specific scenario Classes
- the isLocked() function, used in conjonction with the lockfiles to skip a test if the precedent is not finished
- basics getters and setters, commons to every scenario
- the init_step() function that checks if the asked step exists
Each scenario file is designed to contain only software-specific instructions :
- a construtor, to get the driver and set specific steps if needed
- a function for each step
Since we use RRD to store and Cacti to display the duration of each step, we have divided every scenario in four essential steps :
- Home (loading homepage)
- Login (entering credentials or else...)
- Actions (performing a few clicks to make sure the software responds accordingly)
- Logout (not much to explain here...)
You can use statusFileGen to generate separate .status file, containing the status of each software listed in Nagios. The script takes -c as a parameter for the config file, if not provided, config.php is tried. Without it, the script ends right here. It takes from the config :
- NAGIOS_DAT_FILE_DIR : path to the Nagios dat file that contains the information
- STATUS_FILE_DIR : the path where to store the .status files
- SSH_HOSTS : hosts (server) where to send the files (multiple hosts can be listed, in an array)
- NAGIOS_HOST_NAME : yours Nagios services have to be listed in a single "host", and this is where its name should be passed
The script reads each line of the "status.dat" file and store status info in an array, then, for each host, it sends SSH commands to create the directories and the files.
We created another application to read .status files and display a list a software, using the status to change the color of the blocks (Green = OK, Red = Unavailable, Yellow = Under maintenance, Blue/Gray = No info). We use a JS script to check the status of each app and to create a list of div, styled to show if each app is available.