[Uptime] migrate to observability rules registry #100699
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| export const uptimeRuleFieldMap = { | ||
| // common fields | ||
| 'monitor.id': { | ||
| type: 'keyword', | ||
| }, | ||
| 'url.full': { | ||
| type: 'keyword', | ||
| }, | ||
| reason: { | ||
| type: 'text', | ||
| }, | ||
| // monitor status alert fields | ||
| 'error.message': { | ||
| type: 'text', | ||
| }, | ||
| 'agent.name': { | ||
| type: 'keyword', | ||
| }, | ||
| 'monitor.name': { | ||
| type: 'keyword', | ||
| }, | ||
| 'monitor.type': { | ||
| type: 'keyword', | ||
| }, | ||
| 'observer.geo.name': { | ||
| type: 'keyword', | ||
| }, | ||
| // tls alert fields | ||
| 'cert.count': { | ||
|
There was a problem hiding this comment. @shahzad31 We can't use the ecs fields here, since the fields represent a single instance of a cert, but these are meant to represent all the found expiring/aging certs to the entire alert. (Also this is supposed to be |
||
| type: 'number', | ||
| }, | ||
| 'cert_status.aging_count': { | ||
| type: 'number', | ||
| }, | ||
| 'cert_status.aging_common_name_and_date': { | ||
|
There was a problem hiding this comment. i am bit confused here, cert_status is plural or singular here. if it's a status of multiple certs , that means There was a problem hiding this comment. i personally think may be this confusion is coming out of because our cert status alert still acts as a bulk alert message, where it sends a curated message for all expiring certificates, i think we should refactor that to work as alert instance per expiring certificate just like what we have for monitor status. any thoughts @justinkambic ? There was a problem hiding this comment. Yes, you are right about the batched/bulk alert message. The intention here was to story the message string in this field. My strategy in this first go around for indexing alert documents was to index all the same things we are keeping in alert state. We store the bulk alert message as a concatenated string of all the relevant information in alert state and this is meant to match here. |
||
| type: 'text', | ||
| }, | ||
| 'cert_status.expiring_count': { | ||
| type: 'number', | ||
| }, | ||
| 'cert_status.expiring_common_name_and_date': { | ||
| type: 'text', | ||
| }, | ||
| 'cert_status.has_aging': { | ||
| type: 'boolean', | ||
| }, | ||
| 'cert_status.has_expired': { | ||
| type: 'boolean', | ||
| }, | ||
| // anomaly alert fields | ||
| 'anomaly.severity': { | ||
| type: 'keyword', | ||
| }, | ||
| 'anomaly.severity_score': { | ||
| type: 'number', | ||
| }, | ||
| 'anomaly.start': { | ||
|
There was a problem hiding this comment. do we need more fields for anomaly? There was a problem hiding this comment. the majority of the anomaly fields have been transitioned to use RAC technical fields, as well as ecs fields listed in the |
||
| type: 'date', | ||
| }, | ||
| 'anomaly.slowest_response': { | ||
| type: 'number', | ||
| }, | ||
| 'anomaly.expected_response': { | ||
| type: 'number', | ||
| }, | ||
| 'anomaly.observer_location': { | ||
| type: 'keyword', | ||
| }, | ||
| } as const; | ||
|
|
||
| export type UptimeRuleFieldMap = typeof uptimeRuleFieldMap; | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| /* | ||
| * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | ||
| * or more contributor license agreements. Licensed under the Elastic License | ||
| * 2.0; you may not use this file except in compliance with the Elastic License | ||
| * 2.0. | ||
| */ | ||
|
|
||
| import { stringify } from 'querystring'; | ||
|
|
||
| export const format = ({ | ||
| pathname, | ||
| query, | ||
| }: { | ||
| pathname: string; | ||
| query: Record<string, any>; | ||
| }): string => { | ||
| return `${pathname}?${stringify(query)}`; | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we replace this
any?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't want to change too much of the types in observability. I only pulled it out. @jasonrhodes any insight into how we can make this more strongly typed. I know Dario was likely the one who worked on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it work with
unknownfor now?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly enough, this is actually the same type used trigger actions ui, so I think it's best to leave this to be determined by the alerting team or Dario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, makes sense. For the time being, we kind of are the alerting team (that manages this rule registry) and I'm working on liaising between everyone who is currently touching it.
If any is being used already with this code, I'll log something to replace it. I just didn't want to introduce it.