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

It is too cumbersome to index an active alert instance "as-is" into a document in Elasticsearch #90412

Closed
gmmorris opened this issue Feb 5, 2021 · 3 comments · Fixed by #94909
Assignees
Labels
enhancement New value added to drive a business result Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@gmmorris
Copy link
Contributor

gmmorris commented Feb 5, 2021

Related to #88957 (comment)

Describe the feature:
We'd like to make it possible to index the raw Alert Instance using an Index Connector.

Describe a specific use case for the feature:
This is a quick win in order to make it easier to store alerts as data which users can interact with using Discover & Dashboards.

@gmmorris gmmorris changed the title We need an easier way to index an active alert instance into a documents in Elastic Search It is too cumbersome to index an active alert instance "as-is" into a document in Elasticsearch Feb 5, 2021
@gmmorris gmmorris added the enhancement New value added to drive a business result label Feb 5, 2021
@mikecote mikecote added the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Feb 5, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@pmuellr
Copy link
Member

pmuellr commented Feb 9, 2021

Is the intention to provide a checkbox like in your POC? Or somehow make it easier for a customer to "manually" do this?

proceeding down the "manually" doing it path ...

I think in theory you can capture all the "alert variables" that action templates can use with {{.}}, however when rendered, this will end up rendering as [object Object]. The trick we did to make all the nested JSON objects expand to their JSON representation doesn't apply to the top-level object - but we could probably fix this. Mean time, we could hard-code all the top-level properties, and then add the context via { ... , "context": {{context}} }.

So, let's say it's easy for a customer to create an index action with the documents body being {{.}}, which would expand to the full JSON. I think our JSON editing for that action prevents us from actually doing that, since it won't be legal JSON. At some point we have to fix that anyway.

Dumping the variables as the document via {{.}} implies each alert would have to be a different index. Alternatively, we could say you have to do { indexThreshold: {{.}} } to get the alert type in as a top-level property, to allow multiple alert types to use the same index.

Then we need mappings and an index template.

All of this seems programmable, except for the mappings part, which we'd need to keep updated as the contexts change. Presumably a function test would indicate some mapping-related failures, if we add a test of this per-type, but maybe there's some that would sneak through.

@mikecote
Copy link
Contributor

mikecote commented Feb 9, 2021

We should timebox this to 3 days max.

@ymao1 ymao1 self-assigned this Mar 11, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
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 Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants