Fundraising tech/Essential systems
Appearance
Systems we should be keeping an eye on all the time, and how they interact
[edit]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
- DBs:
- 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
- Banner log pipeline beacon/impression to the fr cluster (kafka->kafkatee->weblog_filter)
- nfs on banner log server
- 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
- Prometheus, viewed on Grafana
- Icinga
- Catchpoint