|
Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar. |
Transaktionale Elemente
Übersicht
Diese Seite beschreibt die genauen JSON-Nachrichten, die für das Konsistenzmodell der transaktionalen Inkrementen zur Gesundheitssynchronisierung gesendet werden können.
JSON-Eigenschaft: "health"
Die Gesundheitsdaten können über die "health"-Eigenschaft des gemeinsamen JSON-Objekts an die SUSE Observability Receiver API gesendet werden.
-
Beispiel für ein Gesundheitsdaten-
transactional_increments-JSON
"apiKey":"your api key",
"collection_timestamp":1585818978,
"internalHostname":"lnx-343242.srv.stackstate.com",
"events":{},
"metrics":[],
"service_checks":[],
"health":[
{
"consistency_model": "TRANSACTIONAL_INCREMENTS",
"increment": {
"checkpoint": {
"offset": 5,
"batch_index": 102
},
"previous_checkpoint": {
"offset": 5,
"batch_index": 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"
},
{
"checkStateId": "checkStateId3",
"delete": true
}
]
}
],
"topologies":[]
Jede Payload für Gesundheitsdaten bei transaktionalen Inkrementen enthält die folgenden Details:
-
Inkrement - Ein Inkrementobjekt muss in jeder Nachricht vorhanden sein. Dies ermöglicht es der SUSE Observability, die gesamte Kette von Nachrichten zu verfolgen und zu erkennen, wenn eine erneute Übertragung der Daten oder eine unerwartete Lücke in den Daten auftritt. Es enthält die folgenden Felder als Inkrement-Metadaten:
-
checkpoint - Objekt, das den Checkpoint bereitstellt, der zur
check_statesin der Nachricht gehört, es hat zwei Felder:-
offset - Der Offset, der den Nachrichten von der Streaming-Pipeline zugewiesen ist. Zum Beispiel, Kafka-Offset.
-
batch_index - Optional. Wenn eine einzelne Nachricht verwendet wird, um mehrere
check_stateszu akkumulieren, stellt der batch_index den neuesten Index dar, der in der Nachricht vorhanden ist, was das Senden großer Batches in separaten API-Aufrufen ermöglicht.
-
-
previous_checkpoint - Optional. Stellt den zuvor kommunizierten Checkpoint dar, kann bei der allerersten Übertragung im Substream leer sein. Es ermöglicht der SUSE Observability, zu verfolgen, ob möglicherweise Daten aus dem Upstream fehlen.
-
-
stream - Objekt, das die Identifikation bereitstellt, welche Snapshots und
check_stateszusammengehören. Sie enthält die folgenden Felder:-
urn - Datenquelle und Stream-ID, kodiert als eine SUSE Observability URN, die der folgenden Konvention entspricht:
urn:health:<sourceId>:<streamId>, wobei<sourceId>der Name der externen Datenquelle ist und<streamId>ein eindeutiger Identifikator für den Gesundheitsdatenstream ist. -
sub_stream_id - Optional. Identifikator für eine Teilmenge der Stream-Gesundheitsdaten. Wenn die Stream-Daten von mehreren Agenten verteilt und gemeldet werden, ermöglicht dies Snapshot-Lebenszyklen pro
sub_stream_id.
-
-
check_states - Eine Liste von Prüfzuständen. Jeder Prüfzustand kann die folgenden Felder haben:
-
checkStateId - Identifikator für den Prüfzustand im externen System.
-
message - Optional. Nachricht, die in der SUSE Observability UI angezeigt werden soll. Die Daten werden als Markdown interpretiert, sodass Links zur externen Systemprüfung, die den externen Prüfzustand erzeugt hat, möglich sind.
-
health - Einer der folgenden SUSE Observability Gesundheitszustandswerte:
Clear,Deviating,Critical. -
topologyElementIdentifier - Wird verwendet, um den Prüfzustand an ein SUSE Observability Topologieelement zu binden.
-
name - Name des externen Prüfzustands.
-
delete - Flag, das als Löschanfrage für das zugehörige
checkStateIdinterpretiert wird. Selbst wenn die restlichen Felder für die Erstellung vorhanden sind, zum Beispielname, health, …, hat die Löschung Vorrang.
-
Gesundheitsdaten an SUSE Observability senden.
Gesundheitsdaten können in einer JSON-Nachricht über HTTP POST gesendet werden. Im folgenden Beispiel wird ein Snapshot, der zwei Prüfzustände enthält, von einem einzelnen externen Überwachungssystem an SUSE Observability gesendet.
curl -X POST \
'<STACKSTATE_RECEIVER_API_ADDRESS>' \
-H 'Content-Type: application/json' \
-d '{
"collection_timestamp": 1548857167,
"internalHostname": "local.test",
"health": [
{
"consistency_model": "TRANSACTIONAL_INCREMENTS",
"increment": {
"checkpoint": {
"offset": 5,
"batch_index": 102
},
"previous_checkpoint": {
"offset": 5,
"batch_index": 100
}
},
"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"
},
{
"checkStateId": "checkStateId3",
"delete": true
}
]
}
]
}'