Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update from upstream repo yelp/elastalert@master #2

Open
wants to merge 395 commits into
base: master
Choose a base branch
from

Conversation

backstroke-bot
Copy link

Hello!

The upstream repository yelp/elastalert@master has some new changes that aren't in this fork. So, here they are, ready to be merged! 🎉

If this pull request can be merged without conflict, you can publish your software with these new changes. Otherwise, fix any merge conflicts by clicking the Resolve Conflicts button.


If you like Backstroke, consider donating to help us pay for infrastructure here. Backstroke is a completely open source project that's free to use, but we survive on sponsorships and donations. Thanks for your support! Help out Backstroke.


Created by Backstroke (I'm a bot!)

Abhishek Jaisingh and others added 30 commits November 12, 2018 15:27
…atch-value to feature/writeback_index

* commit 'e5bb26f7a865fbfc658ba536431e2330dd8e1d5d':
  writeback suffix is formatted with content from match body
  Updated the writeback suffix to include customer id
# Conflicts:
#	elastalert/config.py
#	elastalert/elastalert.py
#	elastalert/test_rule.py
#	tests/base_test.py
#	tests/conftest.py
Fixed a bug causing buffer_time to sometimes be ignored
Avoid writing slack_webhook_url in elastalert_status index
Support reading a whole dict logging configuration from the config file
and configure the logging framework accordingly.
Move special logging configuration via command line options
(--verbose, --debug) into load_rules() as it needs to be set after the
logging framework has been reconfigured.

This should keep the previous behavior as close as possible when no
logging setup is provided in the configuration and mimic the desired log
level adjustments where appropriate even if a custom logging config
is given.
Read logging configuration from config file
Add a missing comma to fix dependency error
Qmando and others added 29 commits December 5, 2019 14:10
Allow run_every to be unique per rule
updated rules_mapping to include spike_aggregation
Re-add TheHive alerter without any libraries
Added back custom fields to the hive alerter
Update elastalert-test-rule to use ascii_letters
Fix Flake Lint Ambiguous Variable Error
Made the schema valid according to draft-07
Fix slack kibana properties in schema
exotel_accout_sid → exotel_account_sid
fix issue 2518, where false positive may be triggered sometimes
This has come about because we currently use records which have timestamps like:

```
    "@timestamp": {
      "min": "2020-10-03T07:05:01.987Z",
      "max": "2020-10-05T07:05:09.572Z"
    },
```

These work fine with the `timestamp_field` set to `@timestamp.min`.

However, when we try to create a Jira alert using ElastAlert from these, we run
into a Python error:

```
File "/usr/local/lib/python3.6/site-packages/elastalert/alerts.py", line 875, in create_default_title,
title += ' - %s' % (pretty_ts(matches[0][self.rule['timestamp_field']], self.rule.get('use_local_time'))), KeyError: '@timestamp.min'
```

This is because matches[0][self.rule['timestamp_field']] attempts to access
the `timestamp_field` directly rather than using a `get()`.

The proposed fix will not change any existing behaviour, but will skip the addition
of a timestamp to the ticket title if the required field doesn't exist, rather than
throwing an error and disabling the rule.
Fix the use of timestamps in the Jira ticket titles
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.