Skip to content

Commit

Permalink
Clean up SLO and cases docs (#3294)
Browse files Browse the repository at this point in the history
* clarify description of index setting in topic about defining SLIs

* clarify description of the partition by field for SLOs

* add more info on connectors

* thank you, mike

Co-authored-by: Mike Birnstiehl <[email protected]>

---------

Co-authored-by: Mike Birnstiehl <[email protected]>
(cherry picked from commit 0cf0670)
  • Loading branch information
colleenmcginnis authored and mergify[bot] committed Oct 18, 2023
1 parent 1e4fea6 commit 3e98e4a
Show file tree
Hide file tree
Showing 2 changed files with 17 additions and 10 deletions.
13 changes: 10 additions & 3 deletions docs/en/observability/create-observability-connectors.asciidoc
Original file line number Diff line number Diff line change
@@ -1,7 +1,8 @@
[[cases-external-connectors]]
= Configure external connectors

You can send cases to these third-party systems:
If you are using an external incident management system, you can integrate Elastic Observability
cases with that system using _connectors_. These third-party systems are supported:

* {sn-itsm}
* {sn-sir}
Expand Down Expand Up @@ -61,7 +62,13 @@ To update an existing connector:

[discrete]
[[close-connector-observability]]
== Close sent cases automatically
== Sending and closing cases

To send a case to an external system, click the **Push as <connector name> incident** button from the individual case page.
This information is not sent automatically. If you make further changes to the shared case fields, you should push the case again.

If you close cases in your external incident management system, the cases will remain open in Elastic Observability until you close them
manually.

To close cases when they are sent to an external system, select
*Automatically close cases when pushing new incident to external system*.
*Automatically close cases when pushing new incident to external system* when adding a connector to a case.
14 changes: 7 additions & 7 deletions docs/en/observability/slo-create.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -35,18 +35,18 @@ The type of SLI to use depends on the location of your data:
[[custom-kql-sli]]
== Custom KQL

Create an indicator based on any of your {es} indices or index patterns. You define two queries: one that yields the good events from your index, and one that yields the total events from your index.
Create an indicator based on any of your {es} indices or data views. You define two queries: one that yields the good events from your index, and one that yields the total events from your index.

*Example:* You can define a custom KQL indicator based on the `service-logs` with the *good query* defined as `nested.field.response.latency <= 100 and nested.field.env : “production”` and the *total query* defined as `nested.field.env : “production”`.

When defining a custom KQL SLI, set the following fields:

* *Index* — The index or index pattern you want to base the SLI on. For example, `service-logs`.
* *Index* — The data view or index pattern you want to base the SLI on. For example, `service-logs`.
* *Timestamp field* — The timestamp field used by the index.
* *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents.
* *Good query* — The query yielding events that are considered good or successful. For example, `nested.field.response.latency <= 100 and nested.field.env : “production”`
* *Total query* — The query yielding all events to take into account for computing the SLI. For example, `nested.field.env : “production”`.
* *Partition by* — Create an SLO for each value of the field you enter.
* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.

[discrete]
[[custom-metric-sli]]
Expand All @@ -59,7 +59,7 @@ Create an indicator to define custom equations from metric fields in your indice
When defining a custom metric SLI, set the following fields:

* *Source*
** *Index* — The index or index pattern you want to base the SLI on. For example, `my-service-*`.
** *Index* — The data view or index pattern you want to base the SLI on. For example, `my-service-*`.
** *Timestamp field* — The timestamp field used by the index.
** *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents. For example, `'field.environment : "production" and service.name : "my-service"'`.
* *Good events*
Expand All @@ -70,7 +70,7 @@ When defining a custom metric SLI, set the following fields:
** *Metric [A-Z]* — The field that is aggregated using the `sum` aggregation for total events. For example, `processor.processed`
** *Filter [A-Z]* — The filter to apply to the metric for total events. For example, `"processor.outcome: *"`
** *Equation* — The equation that calculates the total metric. For example, `A`.
* *Partition by* — Create an SLO for each value of the field you enter.
* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.

[discrete]
[[histogram-metric-sli]]
Expand All @@ -85,7 +85,7 @@ When using a `range` aggregation, both the `from` and `to` thresholds are requir
When defining a histogram metric SLI, set the following fields:

* *Source*
** *Index* — The index or index pattern you want to base the SLI on. For example, `my-service-*`.
** *Index* — The data view or index pattern you want to base the SLI on. For example, `my-service-*`.
** *Timestamp field* — The timestamp field used by the index.
** *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents. For example, `field.environment : "production" and service.name : "my-service"`.
* *Good events*
Expand All @@ -100,7 +100,7 @@ When defining a histogram metric SLI, set the following fields:
** *From* — (`range` aggregation only) The starting value of the range for total events. For example, `0`.
** *To* — (`range` aggregation only) The ending value of the range for total events. For example, `100`.
** *KQL filter* — The filter for total events. For example, `"processor.outcome : *"`.
* *Partition by* — Create an SLO for each value of the field you enter.
* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.

[discrete]
[[apm-latency-and-availability-sli]]
Expand Down

0 comments on commit 3e98e4a

Please sign in to comment.