[ENGSUP-1947] Upgrade elastalert

changelog.md

@@ -1,5 +1,34 @@
 # Change Log
 
+## v0.1.19
+
+### Added
+- Added support for populating JIRA fields via fields in the match
+- Added support for using a TLS certificate file for SMTP connections
+- Allow a custom suffix for non-analyzed Elasticsearch fields, like ".raw" or ".keyword"
+- Added match_time to Elastalert alert documents in Elasticsearch
+
+### Fixed
+- Fixed an error in the documentation for rule importing
+- Prevent enhancements from re-running on retried alerts
+- Fixed a bug when using custom timestamp formats and new term rule
+- Lowered jira_bump_after_inactivity default to 0 days
+
+## v0.1.18
+
+### Added
+- Added a new alerter "post" based on "simple" which makes POSTS JSON to HTTP endpoints
+- Added an option jira_bump_after_inacitivty to prevent ElastAlert commenting on active JIRA tickets
+
+### Removed
+- Removed "simple" alerter, replaced by "post"
+
+## v0.1.17
+
+### Added
+- Added a --patience flag to allow Elastalert to wait for Elasticsearch to become available
+- Allow custom PagerDuty alert titles via alert_subject
+
 ## v0.1.16
 
 ### Fixed

docs/source/elastalert.rst

@@ -179,6 +179,9 @@ The environment variable ``AWS_DEFAULT_PROFILE`` will override this field.
 ``replace_dots_in_field_names``: If ``True``, ElastAlert replaces any dots in field names with an underscore before writing documents to Elasticsearch.
 The default value is ``False``. Elasticsearch 2.0 - 2.3 does not support dots in field names.
 
+``string_multi_field_name``: If set, the suffix to use for the subfield for string multi-fields in Elasticsearch.
+The default value is ``.raw`` for Elasticsearch 2 and ``.keyword`` for Elasticsearch 5.
+
 .. _runningelastalert:
 
 Running ElastAlert

docs/source/ruletypes.rst

@@ -221,7 +221,8 @@ import
 
 ``import``: If specified includes all the settings from this yaml file. This allows common config options to be shared. Note that imported files that aren't
 complete rules should not have a ``.yml`` or ``.yaml`` suffix so that ElastAlert doesn't treat them as rules. Filters in imported files are merged (ANDed)
-with any filters in the rule. (Optional, string, no default)
+with any filters in the rule. You can only have one import per rule, though the imported file can import another file, recursively. The filename 
+can be an absolute path or relative to the rules directory. (Optional, string, no default)
 
 use_ssl
 ^^^^^^^
@@ -1081,7 +1082,7 @@ or
     - email
     - jira
 
-E-mail subject or JIRA issue summary can also be customized by adding an ``alert_subject`` that contains a custom summary.
+E-mail subjects, JIRA issue summaries, and PagerDuty alerts can also be customized by adding an ``alert_subject`` that contains a custom summary.
 It can be further formatted using standard Python formatting syntax::
 
     alert_subject: "Issue {0} occurred at {1}"
@@ -1228,6 +1229,10 @@ STARTTLS.
 ``smtp_auth_file``: The path to a file which contains SMTP authentication credentials. It should be YAML formatted and contain
 two fields, ``user`` and ``password``. If this is not present, no authentication will be attempted.
 
+``smtp_cert_file``: Connect the SMTP host using the given path to a TLS certificate file, default to ``None``.
+
+``smtp_key_file``: Connect the SMTP host using the given path to a TLS key file, default to ``None``.
+
 ``email_reply_to``: This sets the Reply-To header in the email. By default, the from address is ElastAlert@ and the domain will be set
 by the smtp server.
 
@@ -1310,6 +1315,9 @@ Example usage::
     jira_bump_in_statuses:
       - Open
 
+``jira_bump_after_inactivity``: If this is set, ElastAlert will only comment on tickets that have been inactive for at least this many days.
+It only applies if ``jira_bump_tickets`` is true. Default is 0 days.
+
 Arbitrary Jira fields:
 
 ElastAlert supports setting any arbitrary JIRA field that your jira issue supports. For example, if you had a custom field, called "Affected User", you can set it by providing that field name in ``snake_case`` prefixed with ``jira_``.  These fields can contain primitive strings or arrays of strings. Note that when you create a custom field in your JIRA server, internally, the field is represented as ``customfield_1111``. In elastalert, you may refer to either the public facing name OR the internal representation.
@@ -1480,12 +1488,16 @@ The alerter requires the following option:
 
 Optional:
 
-``pagerduty_incident_key``: If not set pagerduty will trigger a new incident for each alert sent. If set to a unique string per rule pagerduty will identify the incident that this event should be applied.
+``alert_subject``: If set, this will be used as the Incident description within PagerDuty. If not set, ElastAlert will default to using the rule name of the alert for the incident.
+
+``alert_subject_args``: If set, and  ``alert_subject`` is a formattable string, ElastAlert will format the incident key based on the provided array of fields from the rule or match.
+
+``pagerduty_incident_key``: If not set PagerDuty will trigger a new incident for each alert sent. If set to a unique string per rule PagerDuty will identify the incident that this event should be applied.
 If there's no open (i.e. unresolved) incident with this key, a new one will be created. If there's already an open incident with a matching key, this event will be appended to that incident's log.
 
 ``pagerduty_incident_key_args``: If set, and ``pagerduty_incident_key`` is a formattable string, Elastalert will format the incident key based on the provided array of fields from the rule or match.
 
-``pagerduty_proxy``: By default ElastAlert will not use a network proxy to send notifications to Pagerduty. Set this option using ``hostname:port`` if you need to use a proxy.
+``pagerduty_proxy``: By default ElastAlert will not use a network proxy to send notifications to PagerDuty. Set this option using ``hostname:port`` if you need to use a proxy.
 
 Exotel
 ~~~~~~
@@ -1614,6 +1626,35 @@ Optional:
 
 The stomp_destination field depends on the broker, the /queue/ALERT example is the nomenclature used by ActiveMQ. Each broker has its own logic.
 
+HTTP POST
+~~~~~~~~~
+
+This alert type will send results to a JSON endpoint using HTTP POST. The key names are configurable so this is compatible with almost any endpoint. By default, the JSON will contain al the items from the match, unless you specify http_post_payload, in which case it will only contain those items.
+
+Required:
+
+``http_post_url``: The URL to POST.
+
+Optional:
+
+``http_post_payload``: List of keys:values to use as the content of the POST. Example - ip:clientip will map the value from the clientip index of Elasticsearch to JSON key named ip. If not defined, all the Elasticsearch keys will be sent.
+
+``http_post_static_payload``: Key:value pairs of static parameters to be sent, along with the Elasticsearch results. Put your authentication or other information here.
+
+``http_post_proxy``: URL of proxy, if required.
+
+``http_post_all_values``: Boolean of whether or not to include every key value pair from the match in addition to those in http_post_payload and http_post_static_payload. Defaults to True if http_post_payload is not specified, otherwise False.
+
+Example usage::
+
+    alert: post
+    http_post_url: "http://example.com/api"
+    http_post_payload:
+      ip: clientip
+    http_post_static_payload:
+      apikey: abc123
+
+
 Alerter
 ~~~~~~~