-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Research image / chart support for actions via markdown #67383
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
This could and should be paired. |
Is there a branch with the POC code for this? |
POC PR is elastic/eui#3658 I did a research of possibility to use EuiMarkdownEditor for adding message templates with images and chart snapshots for actions like Slack and Email. There are a few blockers which doesn't allows to use it as a template builder for action messages:
We have two different approaches on how to post a Slack message with an image. Both is implemented in my PR
Slack WebAPI method:
Fo doing that we will use Slack as image hoster. WARNING! It will take from 5 - 10 seconds to have the file available after upload. Step 1 - Upload image to Slack Step 2 - Create public URL Slack WebAPI method: Next you need to construct the direct image link from the link to website / permalink_public property of the file. The website link you get from https://slack-files.com/{team_id}-{file_id}-{pub_secret} https://files.slack.com/files-pri/{team_id}-{file_id}/{filename}?pub_secret={pub_secret} Step 3 - Send message Slack WebAPI method:
|
To enable more elaborate formatting, we'll likely change Slack in the future to use the "blocks" framework it provides to be able to send a more structured message. We'd then include any images with Slack messages in a block per example 3 ^^^. For email, we'll want want to embed the image as part of a multipart message - there's some convention about to how refer to an "attached" message from within another html part of the multipart message. One potential issue is size. Presumably we'll get the image bytes when the alert runs, which means we then have to store it to use when the actions execute later as part of another task. So, those image bytes will end up in the action task params saved object, which isn't great. Another thought is to delay generating the image bytes till they are needed (the action is run), but by then, it may be too late, we may not be able to reconstruct an image after the fact. This could also push us to implementing a story where we run all actions in the same task as the alert they were scheduled from. This makes action retries harder/impossible, but makes a lot of other aspects of running multiple actions much nicer. |
Investigate from a high level the implementation details of #49908.
The text was updated successfully, but these errors were encountered: