README.txt 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299
  1. README file for the Production check & Production monitor Drupal modules.
  2. Introduction
  3. ============
  4. When bringing a site live, you should double check a lot of settings, like the
  5. error logging, site e-mail, disabling the Devel module and so on.
  6. Next to that, you should ensure that all SEO modules are installed and properly
  7. configured (like Google Analytics, Page Title, XML Sitemap etc.). The Production
  8. check module will do all of this checking for you and present the results in a
  9. convenient status page accessible through /admin/reports/prod-check. Through
  10. this status page, you can easily navigate to all the settings pages or the
  11. project pages of the missing modules to rectify all you need to.
  12. It would of course also be nice that these settings remain as you set them up.
  13. In some cases, when multiple developers make updates to a live site or with the
  14. odd client having somehow gotten superadmin access, stuff can get changed,
  15. usually unintended. That's where the Production monitor comes in the picture.
  16. You can open up the Production check's XMLRPC interface through its settings
  17. page and have the Production monitor module connect to it from a 'local'
  18. monitoring site in your development environment. This will allow you to monitor
  19. all your sites from a central server and keep an eye on them. When adding a site
  20. using Production monitor, you can indicate what exactly needs to be monitored
  21. for this site. Updates can be requested manually and are fetched automatically
  22. each cron run.
  23. "But I like Nagios to monitor my sites!"
  24. If you prefer Nagios monitoring, you can open up Production check's Nagios
  25. integration from its settings page. You can specify what exactly you want to
  26. monitor there. You will obviousely need to install the Nagios module to make
  27. this functionality work.
  28. Remote module update status monitoring
  29. ======================================
  30. Since Production check recommends to turn of the Update module, we have
  31. integrated its functionality in both Production check and Production monitor.
  32. Production check can be configured to allow to transfer its module list with
  33. versioning information once a week at a given time.
  34. Production monitor can be configured to download this data along with all the
  35. rest. It will then, upon your request (still need to add this on cron, but it's
  36. a heavy operation, thinking about the best way to do this: the boost crawler
  37. code makes a good candidate), check for module updates locally for the remote
  38. site. Production check and Production monitor have the necessary code embedded
  39. so you will never need to activate the Update module, not even on the monitor
  40. site!
  41. Performance monitoring
  42. ======================
  43. If you install the performance module on a production site, you can use
  44. Production monitor to remotely monitor the collected performance data. A new
  45. subtab will be available displaying the module data in some nice Google charts.
  46. Be sure to activate the fetching of performance data in the site's config!
  47. Dependencies
  48. ============
  49. - Nagios http://drupal.org/project/nagios
  50. There are no true dependencies defined in the .info file, but naturally you need
  51. to install the Nagios module if you would like to integrate Production check
  52. with your Nagios monitoring setup.
  53. - Performance logging http://drupal.org/project/performance
  54. Again, no true dependencies defined, but if you want remote performance logging,
  55. this module can provide it for you! Install it on the remote site and enable the
  56. fetching of it's data when adding a site to Production monitor.
  57. Development
  58. ===========
  59. See prod_check.api.php
  60. Installation
  61. ============
  62. Production check
  63. ----------------
  64. 1. Extract the prod_check module and place it in /sites/all/modules/contrib
  65. 2. Remove the 'prod_monitor' folder and all it's contents
  66. 3. Upload the prod_check folder to the websites you wish to check / monitor,
  67. enable the module and adjust it's settings using /admin/config/system/prod-check.
  68. 4. You can check the /admin/reports/status page to verify if the Production
  69. check setup described above was executed correctly and no errors / warnings are
  70. reported.
  71. 5. You can find the result of the Production check module on
  72. /admin/reports/prod-check
  73. Production monitor
  74. ------------------
  75. 1. Grab the prod_monitor folder from the package and upload it to your
  76. 'monitoring site' and activate the module.
  77. 2. Make sure that the site you wish to monitor is running the prod_check module
  78. 3. Navigate to the prod_check settings page and activate XMLRPC and add an API
  79. key to 'secure' the connection. The key is limited to 128 characters.
  80. 4. Add the site to the Production monitor overview page on
  81. /admin/reports/prod-monitor
  82. 5. Enter the url and the API key and hit 'Get settings'. All available checks
  83. are now retrieved from the remote site. You can uncheck those that you do not
  84. wish to monitor.
  85. 6. If you wish to fetch the data immediately, check the appropriate box and save
  86. the settings. Good to go!
  87. Cron setup
  88. ----------
  89. To automatically check the site status and/or module updates on cron, you will
  90. need to install drush and configure the following tasks in the crontab:
  91. # Check ALL sites for updates, once a day starting at 0100H at night.
  92. 0 1 * * * /path/to/drush -r /path/to/docroot prod-monitor-updates -y --quiet
  93. # Fetch ALL site data every five minutes (or whatever you please obviously).
  94. 0/5 * * * * /path/to/drush -r /path/to/docroot prod-monitor-fetch -y --quiet
  95. Obviously, the time and frequency of these cron jobs is at your discretion.
  96. Do note that, depending on the number of sites you have configured, the crons
  97. may be running for quite some time, especially the module update checking job!
  98. Upgrading
  99. ---------
  100. When upgrading Production monitor to a newer version, always run update.php to
  101. verify if there are database or other updates that need to be applied!
  102. When ignoring this step, you might get errors and/or strange behavior!
  103. Nagios
  104. ------
  105. 1. Download and install the Nagios module from http://drupal.org/project/nagios
  106. as per its readme instructions
  107. 2. Enable Nagios support in the prod_check module on /admin/config/system/prod-check
  108. by ticking the appropriate box.
  109. 3. Untick the checkboxes for those items you do not whish to be monitored by
  110. Nagios.
  111. 4. Save the settings and you're good to go!
  112. Performance logging
  113. -------------------
  114. 1. Download and install the Nagios module from http://drupal.org/project/performance
  115. as per its readme instructions
  116. 2. Enable fetching of performance data on /admin/reports/prod-monitor when
  117. adding or editing a site.
  118. Drush
  119. -----
  120. You can view the Production Check statuspage using Drush, simply by using this
  121. command:
  122. $ drush prod-check
  123. or its alias:
  124. $ drush pchk
  125. A colour coded table will be printed. The information is limited to the name of
  126. the check and the status. In the Drupal version of the status page, you have an
  127. extra line explaining more about the curent status of a specific check.
  128. You can easily make your site 'production ready' by using the following command:
  129. $ drush prod-check-prodmode
  130. or its alias:
  131. $ drush pchk-pmode
  132. This will fix most of the problems reported in the status page. You can have
  133. some extra control on the process by adding the --config option:
  134. $ drush pchk-pmode --config
  135. This will ask for some input before setting up the site.
  136. For Production monitor, these commands are available:
  137. $ drush prod-monitor [id]
  138. $ drush prod-monitor-fetch [id]
  139. $ drush prod-monitor-flush [id]
  140. $ drush prod-monitor-delete [id]
  141. $ drush prod-monitor-updates [id] (--check, --security-only)
  142. or their aliases:
  143. $ drush pmon [id]
  144. $ drush pmon-fe [id]
  145. $ drush pmon-fl [id]
  146. $ drush pmon-rm [id]
  147. $ drush pmon-up [id] (--check, --security-only)
  148. The id parameter is optional for the prod-monitor command. The best usage is to
  149. first get a list of sites:
  150. $ drush pmon
  151. Now look up the id of a site, then use the other commands to act on that
  152. specific site by passing it the id:
  153. $ drush pmon 3
  154. $ drush pmon-fl 3
  155. You can pass multiple ID's by separating them with spaces:
  156. $ drush pmon 3 6 19
  157. $ drush pmon-fl 19 4 1
  158. The prod-monitor-updates command acts on one id only!
  159. APC/OPcache
  160. -----------
  161. Production Check complains about APC not being installed or misconfigured. What
  162. is APC you wonder? Well, APC is an opcode caching mechanism that will pre-com-
  163. pile PHP files and keep them stored in memory. The full manual can be found
  164. here: http://php.net/manual/en/book.apc.php .
  165. PHP version 5.5 comes bundled with an alternative to APC named OPcache. The full
  166. manual can be found here: http://php.net/manual/en/book.opcache.php .
  167. For Drupal sites, it is important to tune APC/OPcache in order to achieve
  168. maximum performance there. Drupal uses a massive amount of files and therefore
  169. you should assign a proper amount of RAM to APC/OPcache. For a dedicated setup
  170. 64Mb should be sufficient, in shared setups, you will need to multiply that!
  171. To tune your setup, you can use the aforementioned hidden link provided by
  172. Production check. You can see the memory usage there, verify your settings and
  173. much more.
  174. To help you out even further, an APC config file can be found in
  175. docs/apc.ini.txt. You must obviousely rename this file and omit the .txt
  176. extension (drupal.org CVS did not seem to accept files with .ini extension?).
  177. Note: This 'hidden link' makes use of the APC supplied PHP code and is subject
  178. to the PHP license: http://www.php.net/license/3_01.txt .
  179. The OPcache variant is taken from https://github.com/rlerdorf/opcache-status .
  180. Updates
  181. =======
  182. When new checks are added to the prod_check module, the prod_monitor module will
  183. automatically fetch them from the remote server when you edit the settings. Upon
  184. displaying the edit form, XMLRPC is ALWAYS used to build op the checkboxes array
  185. so that you always have the latest options available.
  186. Cron is NOT used to do this, since we want to keep the transfer to a minimum.
  187. Hidden link
  188. ===========
  189. Production check adds some 'hidden links' to the site where you can check the
  190. APC/OPcache, Memcache and DB status of your site. These pages can be found on:
  191. /admin/reports/status/apc-opc
  192. /admin/reports/status/memcache
  193. /admin/reports/status/database
  194. This is in analogy with the system module that adds this 'hidden page':
  195. /admin/reports/status/php
  196. Truely unmissable when setting up your site on a production server to check if
  197. all is well!
  198. The detailed report page
  199. ========================
  200. The page is divided into 4 sections:
  201. - Settings: checks various Drupal settings
  202. - Server: checks that are 'outside of Drupal' such as APC/OPcache and wether or
  203. not you have removed the release note files from the root.
  204. - Performance: checks relevant to the performance settings in Drupal such as
  205. page / block caching.
  206. - Modules: checks if certain modules are on / off
  207. - SEO: performs very basic SEO checks such as 'is Google Analytics activated
  208. and did you provide a GA account number.
  209. The sections might shift over time (maybe some stuff should go under a
  210. 'Security' section etc.).
  211. The checks itself should be self explanatory to Drupal developers, so they won't
  212. be described in detail here.
  213. Support
  214. =======
  215. For support requests, bug reports, and feature requests, please us the issue cue
  216. of Menu Clone on http://drupal.org/project/issues/prod_check.
  217. Thanks
  218. ======
  219. kbahey (http://drupal.org/user/4063) for making the performance logging
  220. integration possible!
  221. bocaj (http://drupal.org/user/582042) for all the great contributions!