Fundraising tech/Essential systems

Systems we should be keeping an eye on all the time, and how they interact
Before any big campaign we should make sure all of these things are working. Also see Fundraising tech/Pre-campaign checklist.

Before any big change, we should understand how it will affect all of these things.

For a more general list of components see Fundraising tech/Components.


 * CiviCRM and its databases
 * DBs:
 * drupal (also needed by payments-wiki)
 * civicrm
 * fredge
 * smashpig
 * postfix
 * Payments-wiki
 * Memcache
 * drupal database
 * minfraud
 * Redis
 * Needed by payments-wiki, listeners, and CiviCRM
 * job runner (process-control)
 * cron
 * pending queue consumer
 * adyen and paypal job runners
 * Donatewiki
 * depends on i18n messages from DonationInterface
 * CentralNotice
 * meta.wm.o
 * translations infrastructure
 * MessageCache
 * robots.txt (keeps banners out of search result previews)
 * GeoIP cookie-setter in Varnish
 * Some banners load js from donatewiki, like payment method availability
 * Stats
 * DjangoBannerStats
 * Analytics' pipeline sending a sample of beacon/impression to the fr cluster (kafkatee, but not the same as below?)
 * Jeff made a thing (that replaces udp2log) to read banner load stats from the main cluster - kafkatee?
 * Hive webreqest and beacon/impression stats
 * Payments listeners
 * Connectivity to verification URLs
 * Audit processors
 * SFTP job
 * Silverpop export
 * Depends on civicrm subscriber database, not master
 * utilities
 * drush
 * composer
 * Google docs "Multilingual master" and e-mail campaigns spreadsheet
 * Monitoring
 * Ganglia (soon to be Promtheus)
 * Icinga
 * Catchpoint