Beobachtbarkeit und Analytik in Azure Operator 5G Core Vorschau

Die Observability hat drei Säulen: Metriken, Tracing und Protokolle. Azure Operator 5G Core Preview bündelt diese Überwachungstools, um Ihnen zu helfen, Probleme zu identifizieren, zu untersuchen und zu lösen. Darüber hinaus stellen Azure Operator 5G Core-Warnungen Benachrichtigungen basierend auf Metriken und Protokollen bereit.

Übersicht über die Observability

Die folgenden Komponenten bieten Beobachtbarkeit für Azure Betreiber 5G Core:

Observability Open Source-Komponenten

Azure Operator 5G Core verwendet die folgenden offenen Source-Komponenten für Beobachtbarkeitsfunktionen.

Parameter der Beobachtbarkeit	Open Source-Komponenten
Kennzahlen	Prometheus, AlertManager, Grafana
Protokolle	Elasticsearch, Fluentd und Kibana (EFK); Elastalert
Verfolgung	Jaeger, OpenTelemetry Collector

Protokollierungsrahmenwerk

Elasticsearch, Fluentd und Kibana (EFK) bieten ein verteiltes Protokollierungssystem, das zum Sammeln und Visualisieren der Protokolle zur Problembehandlung von Microservices verwendet wird.

Architektur

Das folgende Diagramm zeigt die EFK-Architektur:

Anmerkung

Abschnitte der folgenden verknüpften Inhalte sind nur für Kunden mit einem aktuellen Supportvertrag für bestätigte Netzwerke verfügbar. Um auf die Inhalte zuzugreifen, müssen Sie über die Anmeldeinformationen von "Affirmed Networks" verfügen. Wenn Sie Hilfe benötigen, wenden Sie sich bitte an das Supportteam von Affirmed Networks.

Das Protokollierungsframework enthält die folgenden Komponenten:

• Fluentd – Fluentd ist ein Open-Source-Protokollsammler. Fluentd ermöglicht es Ihnen, die Datensammlung und den Verbrauch zu vereinheitlichen, um die Daten besser zu nutzen und zu verstehen. Fluentd wird als DaemonSet im Kubernetes-Cluster bereitgestellt. Sie sammelt die Protokolle in jedem K8s-Knoten und überträgt die Protokolle an Elasticsearch. Siehe Protokolle, die von Fluentdunterstützt werden.

• Elasticsearch - Elasticsearch ist ein Open-Source, verteiltes, Echtzeit-Such-Backend. Elasticsearch speichert die Protokolle sicher und bietet eine HTTP-Webschnittstelle für die Protokollanalyse.

• Kibana - Kibana wird verwendet, um die in Elasticsearch gespeicherten Protokolle zu visualisieren. Kibana ruft die Logdateien von Elasticsearch ab.

  Weitere Informationen zu Elasticsearch und Kibana finden Sie in der Elastic-Dokumentation.

• ElastAlert - ElastAlert ist ein einfaches Framework zur Benachrichtigung über Anomalien, Spitzen oder andere interessante Muster in den Daten in Elasticsearch. Es funktioniert, indem die Elasticsearch mit zwei Arten von Komponenten kombiniert wird: Regeltypen und Warnungen. Elasticsearch wird in regelmäßigen Abständen abgefragt, und die Daten werden an den Regeltyp übergeben, der bestimmt, wann eine Übereinstimmung gefunden wird. Wenn eine Übereinstimmung auftritt, werden ein oder mehrere Alarme aufgrund der Übereinstimmung ausgelöst.

  Weitere Informationen zu ElastAlert finden Sie in ElastAlert-Dokumentation.

Funktionen

Das Protokollierungsframework bietet die folgenden Features:

• Log-Sammlung und Streaming - Fluentd sammelt und streamt die Protokolle an Elasticsearch.

• Überwachungsprotokolle unterstützen – Fluentd liest Kube-Apiserver Überwachungsprotokolle aus dem Kubernetes-Masterknoten und schreibt diese Protokolle in Elasticsearch. Das in fed-paas-helpers bereitgestellte auditlogEnabled-Flag wird verwendet, um das Lesen von Audit-Logs zu aktivieren/deaktivieren. Wenn das Flag "auditlogEnabled" auf "true" festgelegt ist, wird Fluentd zusammen mit den Workerknoten auch auf dem Masterknoten eingesetzt.

• Ereignisprotokollierung – Fluentd erstellt einen separaten Elasticsearch-Index für alle Ereignisprotokolle für einen bestimmten Namespace. Auf diese Weise können Regeln angewendet und die Ereignisprotokolle besser durchsucht werden. Der Index beginnt mit dem Präfix fluentd-event. Alle anderen regulären Debugprotokolle werden in einen separaten Elasticsearch-Index eingefügt, dem die Zeichenfolge fluentd-*vorangestellt ist.

• Protokollspeicher und -analyse - Elasticsearch speichert die Protokolle sicher und bietet eine Abfragesprache zum Suchen und Analysieren der Protokolle.

• Logvisualisierung - Kibana zieht die Logdaten aus Elasticsearch und visualisiert sie. Kibana ermöglicht das Erstellen von Dashboards zum Visualisieren der Protokolle.

• Warnungsmechanismus – ElastAlert stellt Regeln zum Abfragen von Elasticsearch in Bezug auf die Protokolle bereit. Wenn eine Übereinstimmung auftritt, werden Benachrichtigungen ausgelöst.

Helmanpassung

Azure Operator 5G Core bietet einen Standardsatz von Helm-Werten, mit dem Sie das EFK-Logging-Framework bereitstellen können. Sie können diese Werte anpassen, um die Skalierbarkeit und Leistung bei Bedarf zu verbessern.

Beobachtbarkeit

In diesem Abschnitt werden die Funktionen zur Beobachtbarkeit (Dashboards, Statistiken, Protokolle und Alarme) des EFK-Protokollierungsframeworks beschrieben.

Armaturenbretter

Verschiedene Dashboards werden unterstützt, darunter:

• Grafana-Dashboards (siehe Protokollierungsframework-Dashboards)
• Kibana-Dashboards (siehe Übersicht über die Kibana-Dashboards)
• Grafana Kibana Dashboards (siehe Kibana Grafana Dashboards)
• Fluentd Operator-Dashboard (siehe Fluentd Operator-Grafana-Dashboard)
• Elasticsearch-Grafana-Dashboard (siehe Elasticsearch-Dashboard)

Statistik

Informationen zu unterstützten Statistiken für EFK-Komponenten finden Sie unter:

• Elasticsearch-Statistiken
• Andere Elasticsearch-Statistiken
• Fluentd-Operator-Statistiken

Informationen zu metrikbasierten Warnungen finden Sie unter:

• metrikbasierten Warnungen des Fluentd-Operators
• Metrik-basierte elastische Warnungen

Ereignisse

Informationen zu Elastic-Ereignissen finden Sie unter Elastic Events.

Protokollvisualisierung

Das Framework aggregiert Protokolle von Knoten und Anwendungen, die in Ihrer Azure Operator 5G Core-Installation ausgeführt werden. Wenn die Protokollierung aktiviert ist, verwendet das EFK-Framework Fluentd, um Ereignisprotokolle aus allen Anwendungen und Knoten in Elasticsearch zu aggregieren. Das EFK-Framework bietet auch eine zentrale Kibana-Webbenutzeroberfläche, auf der Benutzer die Protokolle anzeigen oder umfangreiche Visualisierungen und Dashboards mit den aggregierten Daten erstellen können.

Metrikrahmenwerk

Das Metrikframework besteht aus Prometheus, Grafana und AlertManager.

Prometheus (die Hauptkomponente) ist ein open-source-, metrikbasiertes Überwachungssystem. Es stellt ein Datenmodell und eine Abfragesprache bereit, um zu analysieren, wie die Anwendungen und Infrastruktur ausgeführt werden. Prometheus sammelt Metriken aus instrumentierten Aufträgen direkt und speichert alle verschrotteten Proben im lokalen externen Speicher. Basierend auf definierten Regeln aggregiert und zeichnet Prometheus entweder eine neue Zeitreihe aus vorhandenen Daten auf oder generiert Warnungen. Der AlertManager verarbeitet die von Clientanwendungen gesendeten Warnungen durch Deduplizieren, Gruppieren und Weiterleiten an die richtigen Empfängerintegrationen.

Grafana stellt Dashboards bereit, um die gesammelten Daten zu visualisieren.

Architektur

Das folgende Diagramm zeigt, wie die verschiedenen Komponenten des Metrikframeworks miteinander interagieren.

Die Kernkomponenten des Metrikframeworks sind:

• Prometheus-Server – Der Prometheus-Server sammelt Metriken aus konfigurierten Zielen in bestimmten Intervallen, wertet Regelausdrücke aus, zeigt die Ergebnisse an und löst Warnungen aus, wenn bestimmte Bedingungen erfüllt sind. Azure Operator 5G Core unterstützt die Integration mit dem Prometheus-Server ohne erforderliche Mindestkonfiguration.
• Clientbibliotheken – Clientbibliotheken instrumentieren den Anwendungscode.
• AlertManager- – AlertManager verarbeitet Benachrichtigungen, die von Clientanwendungen wie dem Prometheus-Server gesendet werden. Es kümmert sich um das Deduplizieren, Gruppieren und Weiterleiten von Benachrichtigungen an die richtigen Empfängerintegrationen (E-Mail, Slack usw.). AlertManager unterstützt auch die Stummschaltung und Unterdrückung von Warnmeldungen.
• Grafana - Grafana bietet einen vordefinierten Satz von Dashboards, die voller 3GPP und anderer KPIs sind, um die gesammelten Daten abzufragen, zu visualisieren und zu verstehen. Das Grafana-Überwachungsfeature bietet einen Mechanismus zum Wiederherstellen oder Neuanstellen von Dashboards auf dem Grafana-Server, wenn grafana server pod neu gestartet wird. Das Überwachungsfeature hilft auch, veraltete Dashboards vom Grafana-Server zu löschen.

Funktionen

Das Metrikframework unterstützt die folgenden Features:

• Mehrdimensionales Datenmodell mit Zeitreihendaten, die durch Metriknamen und Schlüssel-Wert-Paare identifiziert werden.
• PromQL, eine flexible Abfragesprache, die die mehrdimensionalen Daten verwendet.
• Keine Abhängigkeit vom verteilten Speicher: Einzelne Serverknoten sind autonom.
• Zeitreihenauflistung mithilfe eines Pullmodells über HTTP.
• Ziele werden anhand der Dienstermittlung oder durch statische Konfiguration ermittelt.
• Mehrere Modi der Unterstützung von Diagrammen und Dashboarding.

Weitere Informationen zu Prometheus finden Sie in Prometheus-Dokumentation. Weitere Informationen zu Grafana finden Sie in Open Source-Dokumentation von Grafana.

Beobachtbarkeit

In diesem Abschnitt werden die Überwachbarkeitsfunktionen (Dashboards, Statistiken, Protokolle und Alarme) beschrieben, die vom Metrik-Framework bereitgestellt werden.

Armaturenbretter

Das Metrikframework unterstützt die folgenden Dashboards:

• Grafana-Dashboards (siehe Grafana-Dashboard)
• Prometheus Grafana Dashboards (siehe Prometheus Grafana Dashboard)

Statistik

Informationen zu unterstützten Statistiken für Metrikframeworkkomponenten finden Sie unter:

• Grafana-Statistiken
• Prometheus-Statistik
• Prometheus-Serverfehlerstatistik

Informationen zu Prometheus-Metrikbasierten Warnungen finden Sie unter Prometheus-Metrikbasierte Warnungen.

Ereignisse/Protokolle

Informationen zu Metrikframeworkereignissen finden Sie unter:

• Prometheus-Ereignisse
• Infrastrukturereignisse

Metrikbasierte Warnungen für Netzwerk-/HTTP-Fehler

Prometheus-Warnungsregeln generieren Warnungen, wenn HTTP-/Netzwerkfehler im System erkannt werden. Die folgenden Warnungen werden für Netzwerkfehler generiert.

Globale Warnungen auf Anwendungsebene:

• IstioGlobalHTTP5xxRatePercentageHigh - Eine Anwendung, die Teil des Istio-Dienstgitters ist, antwortet mit 5xx-Fehlern, und der Prozentsatz der Fehlerrate überschreitet den <konfigurierten Wert > %
• IstioGlobalHTTP4xxRatePercentageHigh - Eine Anwendung reagiert mit einem 4xx-Fehler, und die Fehlerrate liegt über dem konfigurierten Wert <configured_value> %. IstioHTTPRequestLatencyTooHigh: Anforderungen dauern mehr als die <configured_value> Sekunden.

Warnungen auf Pod- und Containerebene:

• HTTPServerError5xxPercentageTooHigh - HTTP-Server antwortet mit 5xx-Fehler und der Fehlerprozentsatz ist höher als der <konfigurierte Wert> %.
• HTTPServerError4xxPercentageTooHigh - HTTP-Server reagiert mit 4xx-Fehler und der Fehlerprozentsatz ist höher als der <configured_value> %.
• HTTPServerRequestRateTooHigh – Die Gesamtzahl der empfangenen Anforderungen auf dem HTTP-Server ist höher als der <konfigurierte Wert>.
• HTTPClientRespRcvd5xxPercentageTooHigh - HTTP-Clientantwort mit einem 5xx-Fehler empfangen, und der empfangene Fehlerprozentsatz ist höher als der konfigurierte Wert <> %.
• HTTPClientRespRcvd4xxPercentageTooHigh - HTTP-Clientantwort mit 4xx-Fehler empfangen, und der empfangene Fehlerprozentsatz ist höher als der konfigurierte Wert <> %.

Ablaufverfolgungsframework

Jaeger-Ablaufverfolgung mit OpenTelemetry-Protokoll

Azure Operator 5G Core verwendet das OpenTelemetry Protocol (OTLP) in der Jaeger-Ablaufverfolgung. OTLP ersetzt den Jaeger Agent in fed-paas-helpers. Azure Operator 5G Core stellt die fed-otel_collector-Föderation bereit. Der OpenTelemetry (OTEL)-Collector wird als Teil des fed-otel_collector-Namespaces ausgeführt:

Die Jaeger-Ablaufverfolgung verwendet den folgenden Workflow:

1. Die Anwendung, die die OTLP-Clientbibliothek verwendet, sendet Traces über das OTLP-GRPC-Protokoll an den OTEL Collector. Der OTEL Collector verfügt über drei Komponenten: Empfänger, Prozessoren und Exporteure.
2. Der OTLP GRPC-Empfänger im OTEL Collector empfängt Traces und sendet sie an den Jaeger-Exporter.
3. Der Jaeger Exporter sendet Spuren an den Jaeger Sammler, der als Teil von fed-jaeger läuft.
4. Der Jaeger Collector speichert die Traces im Elastic Backend-Speicher (fed-elastic).

Verwandte Inhalte

• Was ist Azure Operator 5G Core Preview?
• Schnellstart: Bereitstellen von Azure Operator 5G Core Observability (Vorschau) auf Azure Kubernetes Services (AKS)

[def]: