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

[ResponseOps] [Connectors] Add a template to the Block Kit in the Slack connector #198506

Open
adcoelho opened this issue Oct 31, 2024 · 3 comments
Labels
enhancement New value added to drive a business result Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@adcoelho
Copy link
Contributor

adcoelho commented Oct 31, 2024

Summary

The Slack action supports Block Kit. However, its usability(and adoption) could be improved by adding a default template when the Block Kit option is selected. The current default is an empty field.

To view the Block Kit option the Slack connector needs to be configured as Web API. Documentation here.

slack-blockkit-shorter.mov

Initial ER https://github.com/elastic/enhancements/issues/21431

@adcoelho adcoelho added enhancement New value added to drive a business result Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Oct 31, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@simonhearne
Copy link

Thanks for raising this issue. I have a few examples that I've created before, it would be great if there was a template option within Kibana enabling users to set default active / recovery messages.

Active

{
	"blocks": [
		{
			"type": "header",
			"text": {
				"type": "plain_text",
				"text": "⚠️ {{rule.name}} ⚠️",
				"emoji": true
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": """{{context.reason}}
View rule: <{{rule.url}}|{{rule.name}}>"""
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": "<{{context.alertDetailsUrl}}|View alert>"
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": "Alert UUID: `{{alert.uuid}}`"
			}
		}
	]
}

Recovered

{
	"blocks": [
		{
			"type": "header",
			"text": {
				"type": "plain_text",
				"text": "🎉 {{rule.name}} Recovered 🎉",
				"emoji": true
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": """View rule: <{{rule.url}}|{{rule.name}}>"""
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": "<{{context.alertDetailsUrl}}|View alert>"
			}
		},
		{
			"type": "section",
			"text": {
				"type": "mrkdwn",
				"text": "Alert UUID: `{{alert.uuid}}`"
			}
		}
	]
}

Stretch

As a stretch goal, for some rule types it would be great to include a graph of the relevant data. For example log threshold alert rules could include the graph of logs vs threshold similar to the alert rule preview.
Image

@pmuellr
Copy link
Member

pmuellr commented Oct 31, 2024

Side note: I haven't played with Blockkit - I really should - but the verbosity in the example above was about what I was expecting - maybe that's why I haven't played with it. 😄

Given our serverless o11y rules we've been authoring, which don't yet use Blockkit (just the old school Mrkdwn formatted string), I can see these are going to get REALLY unwieldy.

So I opened this issue, to look at making the JSON body perhaps easier to read/write by humans: #198528

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

4 participants