* Adding function hooks into rule type definition and call extract fn on rule create * Adding hooks for extracting and injecting saved object references. Adding extractReferences to create and update workflow * Adding type template for extracted params * Adding type template for extracted params * Adding type template for extracted params * Adding type template for extracted params * Calling injectReferences function if defined. Finishing unit tests for create and update * Adding tests for get * Adding tests for find * Cleanup * Fixing types check * Fixing functional tests * Fixing functional tests * Fixing tests * Updating README * Throwing boom error instead of normal error * Adding framework level prefix to extracted saved object reference names * Fixing types * Fixing types * PR fixes Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> |
||
---|---|---|
.. | ||
common | ||
docs | ||
scripts/generate_ecs_fieldmap | ||
server | ||
jest.config.js | ||
kibana.json | ||
README.md | ||
tsconfig.json |
Rule Registry
The rule registry plugin aims to make it easy for rule type producers to have their rules produce the data that they need to build rich experiences on top of a unified experience, without the risk of mapping conflicts.
The plugin installs default component templates and a default lifecycle policy that rule type producers can use to create index templates.
It also exposes a rule data client that will create or update the index stream that rules will write data to. It will not do so on plugin setup or start, but only when data is written.
Configuration
By default, these indices will be prefixed with .alerts
. To change this, for instance to support legacy multitenancy, set the following configuration option:
xpack.ruleRegistry.index: '.kibana-alerts'
To disable writing entirely:
xpack.ruleRegistry.write.enabled: false
Setting up the index template
On plugin setup, rule type producers can create the index template as follows:
// get the FQN of the component template. All assets are prefixed with the configured `index` value, which is `.alerts` by default.
const componentTemplateName = plugins.ruleRegistry.getFullAssetName('apm-mappings');
// if write is disabled, don't install these templates
if (!plugins.ruleRegistry.isWriteEnabled()) {
return;
}
// create or update the component template that should be used
await plugins.ruleRegistry.createOrUpdateComponentTemplate({
name: componentTemplateName,
body: {
template: {
settings: {
number_of_shards: 1,
},
// mappingFromFieldMap is a utility function that will generate an
// ES mapping from a field map object. You can also define a literal
// mapping.
mappings: mappingFromFieldMap({
[SERVICE_NAME]: {
type: 'keyword',
},
[SERVICE_ENVIRONMENT]: {
type: 'keyword',
},
[TRANSACTION_TYPE]: {
type: 'keyword',
},
[PROCESSOR_EVENT]: {
type: 'keyword',
},
}),
},
},
});
// Install the index template, that is composed of the component template
// defined above, and others. It is important that the technical component
// template is included. This will ensure functional compatibility across
// rule types, for a future scenario where a user will want to "point" the
// data from a rule to a different index.
await plugins.ruleRegistry.createOrUpdateIndexTemplate({
name: plugins.ruleRegistry.getFullAssetName('apm-index-template'),
body: {
index_patterns: [plugins.ruleRegistry.getFullAssetName('observability-apm*')],
composed_of: [
// Technical component template, required
plugins.ruleRegistry.getFullAssetName(TECHNICAL_COMPONENT_TEMPLATE_NAME),
componentTemplateName,
],
},
});
// Finally, create the rule data client that can be injected into rule type
// executors and API endpoints
const ruleDataClient = new RuleDataClient({
alias: plugins.ruleRegistry.getFullAssetName('observability-apm'),
getClusterClient: async () => {
const coreStart = await getCoreStart();
return coreStart.elasticsearch.client.asInternalUser;
},
ready,
});
// to start writing data, call `getWriter().bulk()`. It supports a `namespace`
// property as well, that for instance can be used to write data to a space-specific
// index.
await ruleDataClient.getWriter().bulk({
body: eventsToIndex.flatMap((event) => [{ index: {} }, event]),
});
// to read data, simply call ruleDataClient.getReader().search:
const response = await ruleDataClient.getReader().search({
body: {
query: {},
size: 100,
fields: ['*'],
sort: {
'@timestamp': 'desc',
},
},
allow_no_indices: true,
});
Schema
The following fields are defined in the technical field component template and should always be used:
@timestamp
: the ISO timestamp of the alert event. For the lifecycle rule type helper, it is always the value ofstartedAt
that is injected by the Kibana alerting framework.event.kind
: signal (for the changeable alert document), state (for the state changes of the alert, e.g. when it opens, recovers, or changes in severity), or metric (individual evaluations that might be related to an alert).event.action
: the reason for the event. This might beopen
,close
,active
, orevaluate
.tags
: tags attached to the alert. Right now they are copied over from the rule.rule.id
: the identifier of the rule type, e.g.apm.transaction_duration
rule.uuid
: the saved objects id of the rule.rule.name
: the name of the rule (as specified by the user).rule.category
: the name of the rule type (as defined by the rule type producer)kibana.rac.alert.producer
: the producer of the rule type. Usually a Kibana plugin. e.g.,APM
.kibana.rac.alert.owner
: the feature which produced the alert. Usually a Kibana feature id likeapm
,siem
...kibana.rac.alert.id
: the id of the alert, that is unique within the context of the rule execution it was created in. E.g., for a rule that monitors latency for all services in all environments, this might beopbeans-java:production
.kibana.rac.alert.uuid
: the unique identifier for the alert during its lifespan. If an alert recovers (or closes), this identifier is re-generated when it is opened again.kibana.rac.alert.status
: the status of the alert. Can beopen
orclosed
.kibana.rac.alert.start
: the ISO timestamp of the time at which the alert started.kibana.rac.alert.end
: the ISO timestamp of the time at which the alert recovered.kibana.rac.alert.duration.us
: the duration of the alert, in microseconds. This is always the difference between either the current time, or the time when the alert recovered.kibana.rac.alert.severity.level
: the severity of the alert, as a keyword (e.g. critical).kibana.rac.alert.severity.value
: the severity of the alert, as a numerical value, which allows sorting.kibana.rac.alert.evaluation.value
: The measured (numerical value).kibana.rac.alert.threshold.value
: The threshold that was defined (or, in case of multiple thresholds, the one that was exceeded).kibana.rac.alert.ancestors
: the array of ancestors (if any) for the alert.kibana.rac.alert.depth
: the depth of the alert in the ancestral tree (default 0).kibana.rac.alert.building_block_type
: the building block type of the alert (default undefined).
Alerts as data
Alerts as data can be interacted with using the AlertsClient api found in x-pack/plugins/rule_registry/server/alert_data_client/alerts_client.ts
This api includes public methods such as
[x] getFullAssetName [x] getAlertsIndex [x] get [x] update [ ] bulkUpdate (TODO) [ ] find (TODO)