digests.rst 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. Notification Digests
  2. ====================
  3. Sentry provides a service that will collect notifications as they occur and
  4. schedule them for delivery as aggregated "digest" notifications.
  5. Configuration
  6. -------------
  7. Although the digest system is configured with a reasonable set of default
  8. options, the ``SENTRY_DIGESTS_OPTIONS`` setting can be used to fine-tune the
  9. digest backend behavior to suit the needs of your unique installation. All
  10. backends share a common set of options defined below, while some backends may
  11. also define additional options that are specific to their individual
  12. implementations.
  13. .. describe:: minimum_delay
  14. The ``minimum_delay`` option defines the default minimum amount of time (in
  15. seconds) to wait between scheduling digests for delivery after the initial
  16. scheduling. This can be overriden on a per-project basis in the
  17. Notification Settings.
  18. .. describe:: maximum_delay
  19. The ``maximum_delay`` option defines the default maximum amount of time (in
  20. seconds) to wait between scheduling digests for delivery. This can be
  21. overriden on a per-project basis in the Notification Settings.
  22. .. describe:: increment_delay
  23. The ``increment_delay`` option defines how long each observation of an
  24. event should delay scheduling up until the ``maximum_delay`` after the
  25. last time a digest was processed.
  26. .. describe:: capacity
  27. The ``capacity`` option defines the maximum number of items that should be
  28. contained within a timeline. Whether this is a hard or soft limit is
  29. backend dependent -- see the ``truncation_chance`` option.
  30. .. describe:: truncation_chance
  31. The ``truncation_chance`` option defines the probability that an ``add``
  32. operation will trigger a truncation of the timeline to keep it's size close
  33. to the defined capacity. A value of 1 will cause the timeline to be
  34. truncated on every ``add`` operation (effectively making it a hard limit),
  35. while a lower probability will increase the chance of the timeline growing
  36. past it's intended capacity, but increases the performance of ``add``
  37. operations by avoiding truncation, which is a potentially expensive
  38. operation, especially on large data sets.
  39. Backends
  40. --------
  41. Dummy Backend
  42. ~~~~~~~~~~~~~
  43. The dummy backend disables digest scheduling, and all notifications are sent as
  44. they occur (subject to rate limits.) This is the default digest backend for
  45. installations that were created prior to version 8.
  46. The dummy backend can be specified via the ``SENTRY_DIGESTS`` setting:
  47. .. code-block:: python
  48. SENTRY_DIGESTS = 'sentry.digests.backends.dummy.DummyBackend'
  49. Redis Backend
  50. ~~~~~~~~~~~~~
  51. The Redis backend uses Redis to store schedule and pending notification data.
  52. This is the default digest backend for installations that were created since
  53. version 8.
  54. The Redis backend can be specified via the ``SENTRY_DIGESTS`` setting:
  55. .. code-block:: python
  56. SENTRY_DIGESTS = 'sentry.digests.backends.redis.RedisBackend'
  57. The Redis backend accepts several options beyond the basic set, provided via
  58. ``SENTRY_DIGESTS_OPTIONS``:
  59. .. describe:: cluster
  60. The ``cluster`` option defines the Redis cluster that should be used for
  61. storage. If no cluster is specified, the ``default`` cluster is used.
  62. .. important::
  63. Changing the ``cluster`` value or the cluster configuration after data has
  64. been written to the digest backend may cause unexpected effects -- namely,
  65. it creates the potential for data loss during cluster size changes. This
  66. option should be adjusted with care on running systems.
  67. .. describe:: ttl
  68. The ``ttl`` option defines the time-to-live (in seconds) for records,
  69. timelines, and digests. This can (and should) be a relatively high value,
  70. since timelines, digests, and records should all be deleted after they have
  71. been processed -- this is mainly to ensure stale data doesn't hang around
  72. too long in the case of a configuration error. This should be larger than
  73. the maximum scheduling delay to ensure data is not evicted too early.
  74. Example Configuration
  75. ~~~~~~~~~~~~~~~~~~~~~
  76. .. code-block:: python
  77. SENTRY_DIGESTS = 'sentry.digests.backends.redis.RedisBackend'
  78. SENTRY_DIGESTS_OPTIONS = {
  79. 'capacity': 100,
  80. 'cluster': 'digests',
  81. }