airbnb / streamalert

StreamAlert is a serverless, realtime data analysis framework which empowers you to ingest, analyze, and alert on data from any environment, using datasources and alerting logic you define.
https://streamalert.io
Apache License 2.0
2.86k stars 334 forks source link

Enhancements to JIRA v1 output #1311

Open Ryxias opened 3 years ago

Ryxias commented 3 years ago

to: @ryandeivert @chunyong-lin cc: @gavinelder cc: @airbnb/streamalert-maintainers

Changes

ClientSide SSL Verification

To enable this, simply put yes in the new ssl_verify output parameter.

Aggregation Additional Filter

# When aggregation is enabled, it will fuzzy-search any JIRA ticket that best-matches
# the "summary ~ ..." statement, within the project key. For each matching rule,
# instead of creating new JIRA tasks over and over, it will instead opt to append a
# comment to a similar(ish) JIRA task.
#
# However, this can result in  very long-lived JIRA tickets getting tons of comments
# appended on. This optional parameter allows users to specify an additional JQL clause
# to filter out these older tickets, encouraging new JIRA tasks to be created from
# time to time. It can also be used to increase the accuracy of finding the parent
# task (maybe filtering on a component) in case you find the StreamAlert integration
# is appending comments to unrelated issues.
#
# Example: A highly effective JQL suffix is "created > startOfWeek(-1w)"

Can also use other fields like created > startOfWeek(-1w) AND status != Resolved or the like. It depends on your JIRA project's specific configurations. You might have some crazy custom field like custom_field_10101 = "Low". Etc.

To enable this, simply put the query string into the aggregation_additional_jql output parameter.

Additional Fields

# For example, if your JIRA project requires a custom field called "custom_field_1",
# you can set the following json-encoded string in this:
# {"custom_field_1": {"value": "FooBar"}}
#
# These fields are DEFAULT values. You can still override them using the
# @jira.additional_fields publisher parameter.

To enable this, provide the json-encoded string representation of the dict. Because the parameter store stores everything as a JSON string you'll have to escape quotes.

Testing

Deployed internally

gavinelder commented 3 years ago

I really like the changes here to the aggregation filter and also the additional fields.

To confirm was the intent in the CC to see if they should also be added to the Jira_v2 output.

Also in hindsight I wonder if supporting both auth methods in the same output behind a boolean may be better than two distinct outputs.

Ryxias commented 3 years ago

Yeah it was kind of an "FYI" since I knew you wrote a lot of the JIRA v2 integration. Admittedly we didn't sync the v2 internally yet so I actually forgot it existed on the OSS repo; only just noticed it when I synced these JIRA changes out.

And yeah, I took a cursory glance over the JIRA integration and I see the main difference is the auth; v1 uses username/password login whereas v2 uses api key in basic auth header. Since they both use REST API v1/v2 I think would be worth DRYING it out. I'll think about doing that if I have time

gavinelder commented 2 years ago

PS this is 🔥 Just pulled this in & Dry'd out the config in #1333