diff --git a/SUMMARY.md b/SUMMARY.md index 33c78ced8..3fc09623a 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -61,7 +61,6 @@ * [Send health data over HTTP](configure/health/send-health-data/README.md) * [Send health data](configure/health/send-health-data/send-health-data.md) * [Repeat Snapshots JSON](configure/health/send-health-data/repeat_snapshots.md) - * [Repeat States JSON](configure/health/send-health-data/repeat_states.md) * [Transactional Increments JSON](configure/health/send-health-data/transactional_increments.md) * [Debug health synchronization](configure/health/debug-health-sync.md) diff --git a/configure/health/debug-health-sync.md b/configure/health/debug-health-sync.md index 1f02da2f9..3562bba1c 100644 --- a/configure/health/debug-health-sync.md +++ b/configure/health/debug-health-sync.md @@ -78,7 +78,6 @@ $ sts health status -u urn:health:sourceId:streamId -sub-stream-urn subStreamId3 {% hint style="info" %} A substream status will show the metadata related to the consistency model: * **Repeat Snapshots** - Show repeat interval and expiry -* **Repeat States** - Show repeat interval and expiry * **Transactional Increments** - Show checkpoint offset and checkpoint batch index {% endhint %} diff --git a/configure/health/health-synchronization.md b/configure/health/health-synchronization.md index 901c64a00..4ba0fbe46 100644 --- a/configure/health/health-synchronization.md +++ b/configure/health/health-synchronization.md @@ -34,7 +34,7 @@ The health synchronization framework works as follows: ![Health synchronization pipeline](../../.gitbook/assets/health-sync-pipeline.svg) ### Consistency models -SUSE Observability health synchronization relies on different consistency models to guarantee that the data sent from an external monitoring system matches with what SUSE Observability ingests and shows. The consistency model is specified in the `"health"` property of the [common JSON object](/configure/health/send-health-data/send-health-data.md#common-json-object) or as an argument in the SUSE Observability CLI when health data is sent to SUSE Observability. The supported models are: `REPEAT_SNAPSHOTS`, `REPEAT_STATES` and `TRANSACTIONAL_INCREMENTS`. +SUSE Observability health synchronization relies on different consistency models to guarantee that the data sent from an external monitoring system matches with what SUSE Observability ingests and shows. The consistency model is specified in the `"health"` property of the [common JSON object](/configure/health/send-health-data/send-health-data.md#common-json-object) or as an argument in the SUSE Observability CLI when health data is sent to SUSE Observability. The supported models are: `REPEAT_SNAPSHOTS` and `TRANSACTIONAL_INCREMENTS`. {% tabs %} {% tab title="Repeat snapshots model" %} The `REPEAT_SNAPSHOTS` consistency model works with periodic, full snapshots of all checks in an external monitoring system. SUSE Observability keeps track of the checks in each received snapshot and decides if associated external check states need to be created, updated or deleted in SUSE Observability. For example, if a check state is no longer present in a snapshot. This model offers full control over which external checks will be deleted as all decisions are inferred from the received snapshots. There is no ambiguity over the external checks that will be present in SUSE Observability. @@ -44,14 +44,6 @@ The `REPEAT_SNAPSHOTS` consistency model works with periodic, full snapshots of **JSON payload:** The [Repeat Snapshots health payload](/configure/health/send-health-data/repeat_snapshots.md) accepts specific properties to specify when a snapshot starts or stops. {% endtab %} -{% tab title="Repeat States model" %} -The `REPEAT_STATES` consistency model works with periodic checks received from an external monitoring system. SUSE Observability keeps track of the checks and decides if associated external checks need to be created or updated in SUSE Observability. A configurable expiry mechanism is used to delete external checks that aren't observed anymore. This model offers less control over data than the `REPEAT_SNAPSHOTS` model. As an expiry configuration is used to delete external checks, it might happen that elements are deleted due to barely missing the expiry timeout. This would reflect as external checks disappearing and reappearing in SUSE Observability. - -**Use this model when:** The external monitoring system isn't capable of collecting all checks in a determined time window. The best effort is just to send the external checks as they're obtained. - -**JSON payload:** The [Repeat States health payload](/configure/health/send-health-data/repeat_states.md) accepts specific properties to specify the expiry configuration. -{% endtab %} - {% tab title="Transactional Increments model" %} The `TRANSACTIONAL_INCREMENTS` consistency model is designed to be used on streaming systems where only incremental changes are communicated to SUSE Observability. As there is no repetition of data, data consistency is upheld by ensuring that at-least-once delivery is guaranteed across the entire pipeline. To detect whether any data is missing, SUSE Observability requires that both a checkpoint and the previous checkpoint are communicated together with the `check_states`. This model requires strict control across the whole pipeline to guarantee no data loss. diff --git a/configure/health/send-health-data/repeat_states.md b/configure/health/send-health-data/repeat_states.md deleted file mode 100644 index c1c48077d..000000000 --- a/configure/health/send-health-data/repeat_states.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -description: SUSE Observability ---- - -## Overview - -This page describes the exact JSON messages that can be sent for the health synchronization Repeat States consistency model. - -## JSON property: "health" - -Health can be sent to the SUSE Observability Receiver API using the `"health"` property of the [common JSON object](send-health-data.md#common-json-object). - -{% tabs %} -{% tab title="Example health `repeat_states` JSON" %} -```javascript - "apiKey":"", - "collection_timestamp":1585818978, - "internalHostname":"lnx-343242.srv.stackstate.com", - "events":{}, - "metrics":[], - "service_checks":[], - "health":[ - { - "consistency_model": "REPEAT_STATES", - "expiry": { - "repeat_interval_s": 50, - "expiry_interval_s": 100 - }, - "stream": { - "urn": "urn:health:sourceId:streamId" - //"sub_stream_id": "subStreamId" Optional - }, - "check_states": [ - { - "checkStateId": "checkStateId1", - "message": "Server Running out of disk space", - "health": "Deviating", - "topologyElementIdentifier": "server-1", - "name": "Disk Usage" - }, - { - "checkStateId": "checkStateId2", - "message": "Provisioning failed. [Learn more](https://www.any-link.com)", - "health": "critical", - "topologyElementIdentifier": "server-2", - "name": "Health monitor" - } - ] - } - ], - "topologies":[] -``` -{% endtab %} -{% endtabs %} - -Every health Repeat States data payload has the following details: - -* **expiry** - Optional. An expiry update needs to be processed before processing `check_states`. This enables SUSE Observability to track how long the external checks should be present in the system if they aren't sent again. It carries the following fields as expiry metadata: - * **repeat_interval_s** - Time in seconds. The frequency with which the external source will send health data to SUSE Observability. Max allowed value is 1800 (30 minutes). - * **expiry_interval_s** - Time in seconds. The time to wait after the last update before an external check is deleted by SUSE Observability if the external check isn't observed again. -* **stream** - Object providing identification regarding which snapshots and `check_states` belong together. It has the following fields: - * **urn** - Data source and stream ID encoded as a SUSE Observability [URN](/configure/topology/identifiers.md) that matches the following convention: `urn:health::` where `` is the name if the external data source and `` is a unique identifier for the health data stream. - * **sub_stream_id** - Optional. Identifier for a subset of the stream health data. When the stream data is distributed and reported by several agents, this allows snapshot lifecycles per `sub_stream_id` -* **check_states** - A list of check states. Each check state can have the following fields: - * **checkStateId** - Identifier for the check state in the external system - * **message** - Optional. Message to display in SUSE Observability UI. Data will be interpreted as markdown allowing to have links to the external system check that generated the external check state. - * **health** - One of the following SUSE Observability Health state values: `Clear`, `Deviating`, `Critical`. - * **topologyElementIdentifier** - Used to bind the check state to a SUSE Observability topology element. - * **name** - Name of the external check state. - - -## Send health to SUSE Observability - -Health can be sent in one JSON message via HTTP POST. In the example below, a snapshot containing two check states is sent to SUSE Observability from a single external monitoring system. - -```bash -curl -X POST \ - '' \ - -H 'Content-Type: application/json' \ - -d '{ - "collection_timestamp": 1548857167, - "internalHostname": "local.test", - "health": [ - { - "consistency_model": "REPEAT_STATES", - "expiry": { - "repeat_interval_s": 300, - "expiry_interval_s": 600 - }, - "stream": { - "urn": "urn:health:sourceId:streamId" - }, - "check_states": [ - { - "checkStateId": "checkStateId1", - "message": "Server Running out of disk space", - "health": "Deviating", - "topologyElementIdentifier": "server-1", - "name": "Disk Usage" - }, - { - "checkStateId": "checkStateId2", - "message": "Provisioning failed. [Learn more](https://www.any-link.com)", - "health": "critical", - "topologyElementIdentifier": "server-2", - "name": "Health monitor" - } - ] - } - ] -}' -``` \ No newline at end of file diff --git a/configure/health/send-health-data/send-health-data.md b/configure/health/send-health-data/send-health-data.md index c1fb43b63..a6cb6ad85 100644 --- a/configure/health/send-health-data/send-health-data.md +++ b/configure/health/send-health-data/send-health-data.md @@ -43,7 +43,6 @@ Topology, telemetry and health data are sent to the receiver API via HTTP POST. SUSE Observability accepts health data based on a chosen [consistency model](/configure/health/health-synchronization.md#consistency-models). The message that can be sent for each model are described on the pages below: * [Repeat Snapshots JSON](/configure/health/send-health-data/repeat_snapshots.md) -* [Repeat States JSON](/configure/health/send-health-data/repeat_states.md) * [Transactional Increments JSON](/configure/health/send-health-data/transactional_increments.md) ## See also