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.

Überschreiben Sie die Schwellenwertargumente des Monitors über Kubernetes-Annotationen

Übersicht

SUSE Observability bietet Monitore sofort einsatzbereit, die eine Überwachung häufiger Probleme in einem Kubernetes-Cluster ermöglichen. Diese Monitore arbeiten mit bestimmten Standardargumenten, die für die meisten Anwendungsfälle geeignet sind, aber manchmal ist es notwendig, ihr Verhalten anzupassen, indem einige dieser Standardargumente wie threshold oder failureState überschrieben werden. Der Mechanismus zur Deklaration der Überschreibungen erfolgt über Kubernetes-Ressourcenannotationen, die angeben, auf welchen Monitor und welche Komponente sie angewendet werden sollen. Zum Beispiel könnten wir das failureState für den Available service endpoints-Monitor für einen bestimmten Dienst überschreiben, bei dem wir einen CRITICAL-Zustand signalisieren möchten, wenn er fehlschlägt, anstatt des Standardwerts DEVIATING.

Anleitung

Als Beispiel werden die Schritte die Argumente für den Available service endpoints-Monitor von Kubernetes-HTTP-Diensten überschreiben.

Wie erstelle ich meine Annotation

Die Schlüssel für die Überschreibungsannotationen der SUSE Observability-Monitore folgen der folgenden Konvention:

monitor.${owner}.stackstate.io/${monitorShorName}

Die owner-Eigenschaft gibt an, wer einen solchen Monitor erstellt hat; für die sofort einsatzbereiten Monitore ist dies kubernetes-v2, und die monitorShorName-Eigenschaft stellt die ID des Monitors dar und kann aus der identifier-Eigenschaft eines Monitors extrahiert werden, die über die Kommandozeilenschnittstelle beim Auflisten oder Inspizieren von Monitoren gelesen werden kann.

sts monitor list

ID              | STATUS  | IDENTIFIER                                                                          | NAME                                        | FUNCTION ID     | TAGS
8051105457030   | ENABLED | urn:stackpack:kubernetes-v2:shared:monitor:kubernetes-v2:service-available-endpoint | Available service endpoints                 | 233276809885571 | [services]

In unserem Beispiel ist der Bezeichner urn:stackpack:kubernetes-v2:shared:monitor:kubernetes-v2:service-available-endpoint und die monitorShorName entspricht dem letzten Segment wie in service-available-endpoint, daher lautet der Annotationsschlüssel:

monitor.kubernetes-v2.stackstate.io/service-available-endpoint

Die Annotationspayload ist ein JSON-Objekt, in dem die folgenden optionalen Argumente definiert werden können:

  • threshold: optional. Ein numerischer Schwellenwert zum Vergleichen.

  • failureState: optional. Entweder "KRITISCH" oder "ABWEICHEND". "KRITISCH" wird in SUSE Observability als rot und "ABWEICHEND" als orange angezeigt, um unterschiedliche Schweregrade zu kennzeichnen.

  • enabled: optional. Boolescher Datentyp, der bestimmt, ob der Monitor einen Gesundheitszustand für diese Komponente erzeugen würde.

Die vollständige Annotation würde dann wie folgt aussehen

    monitor.kubernetes-v2.stackstate.io/service-available-endpoint: |-
      {
        "threshold": 0.0,
        "failureState": "CRITICAL",
        "enabled": true
      }

Welche Monitore erlauben das Überschreiben von Argumenten?

Erstellen Sie eine Überschreibung für einen benutzerdefinierten Monitor

Jeder benutzerdefinierte Schwellenwertmonitor, der mithilfe der Anleitung unter Fügen Sie einen Schwellenwertmonitor zu Komponenten mit der Kommandozeilenschnittstelle hinzu erstellt wurde, eignet sich zum Überschreiben von Argumenten. Wie das Beispiel zeigt, ist ein Bezeichner für einen benutzerdefinierten Monitor wie folgt aufgebaut: urn:custom:monitor:{monitorShortName} und der Schlüssel für die Überschreibungsannotation für einen solchen Bezeichner ist wie folgt zu erwarten:

monitor.custom.stackstate.io/${monitorShortName}

Das Beispiel verwendet den Bezeichner urn:custom:monitor:deployment-has-replicas, daher wäre der Schlüssel für die Annotation

monitor.custom.stackstate.io/deployment-has-replicas

Und die vollständige Annotation würde so aussehen

    monitor.custom.stackstate.io/deployment-has-replicas: |-
      {
        "threshold": 0.0,
        "failureState": "CRITICAL"
        "enabled": true
      }