Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Microsoft Entra-Authentifizierung
In diesem Artikel wird beschrieben, wie Sie einen Remote-Schreibzugriff einrichten, um Daten von einem selbst verwalteten Prometheus-Server zu senden, der in Ihrem Azure Kubernetes Service (AKS) Cluster oder Azure Arc-fähigen Kubernetes-Cluster läuft. Dazu verwenden Sie die Microsoft Entra-Authentifizierung und einen von Azure Monitor bereitgestellten Side Car Container. Beachten Sie, dass Sie den Remote-Schreibzugriff auch direkt in der Prometheus-Konfiguration konfigurieren können.
Hinweis
Wir empfehlen Ihnen, Prometheus, das auf Ihrem Kubernetes-Cluster läuft, direkt so zu konfigurieren, dass es per Remote-Schreibzugriff in den Azure Monitor Workspace schreibt. Weitere Informationen finden Sie unter Senden von Prometheus-Daten an Azure Monitor mithilfe der Microsoft Entra Id-Authentifizierung. Die folgenden Schritte verwenden den Azure Monitor Side Car Container.
Clusterkonfigurationen
Dieser Artikel gilt für die folgenden Clusterkonfigurationen:
- Azure Kubernetes Service-Cluster
- Kubernetes-Cluster mit Azure Arc-Unterstützung
- Kubernetes-Cluster, der in einer anderen Cloud oder lokal ausgeführt wird
Hinweis
Für einen AKS-Cluster oder einen Kubernetes-Cluster mit Azure Arc-Unterstützung empfehlen wir, die Authentifizierung mit verwalteten Identitäten zu verwenden. Weitere Informationen finden Sie unter Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Authentifizierung mit verwalteten Identitäten.
Voraussetzungen
Unterstützte Versionen
- Für die Microsoft Entra ID-Anwendungsauthentifizierung sind Prometheus-Versionen größer als v2.48 erforderlich.
Azure Monitor-Arbeitsbereich
Dieser Artikel behandelt das Senden von Prometheus-Metriken an einen Azure Monitor-Arbeitsbereich. Informationen zum Erstellen eines Azure Monitor-Arbeitsbereichs finden Sie unter Verwalten eines Azure Monitor-Arbeitsbereichs.
Berechtigungen
Zum Ausführen der Schritte in diesem Artikel sind Administratorberechtigungen für den Cluster oder die Ressource erforderlich.
Einrichten einer Anwendung für Microsoft Entra ID
Der Prozess zum Einrichten des Prometheus-Remoteschreibzugriffs für eine Anwendung unter Verwendung der Microsoft Entra-Authentifizierung umfasst folgende Aufgaben:
- Melden Sie eine Anwendung mit Microsoft Entra ID an.
- Rufen Sie die Client-ID der Microsoft Entra-Anwendung ab.
- Zuweisen der Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel des Arbeitsbereichs zur Anwendung
- Erstellen eines Azure-Schlüsseltresors und Generieren eines Zertifikats
- Hinzufügen eines Zertifikats zur Microsoft Entra-Anwendung
- Hinzufügen eines CSI-Treibers und eines Speichers für den Cluster
- Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs
Die Aufgaben werden in den folgenden Abschnitten beschrieben.
Registrieren einer Anwendung mit Microsoft Entra ID
Führen Sie die Schritte zum Registrieren einer Anwendung mit Microsoft Entra ID und zum Erstellen eines Dienstprinzipals aus.
Abrufen der Client-ID der Microsoft Entra-Anwendung
- Navigieren Sie im Azure-Portal zum Menü Microsoft Entra ID, und wählen Sie die Option App-Registrierungen aus.
- Kopieren Sie in der Liste der Anwendungen den Wert für Anwendungs-ID (Client) für die registrierte Anwendung.
Zuweisen der Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel des Arbeitsbereichs zur Anwendung
Der Anwendung muss die Rolle „Herausgeber von Überwachungsmetriken“ in der Datensammlungsregel zugewiesen werden, die Ihrem Azure Monitor-Arbeitsbereich zugeordnet ist.
Wählen Sie im Ressourcenmenü für Ihren Azure Monitor-Arbeitsbereich die Option Übersicht aus. Wählen Sie unter Datensammlungsregel den Link aus.
Wählen Sie im Ressourcenmenü für die Datensammlungsregel die Option Zugriffssteuerung (IAM) aus.
Wählen Sie Hinzufügen und dann Rollenzuweisung hinzufügen aus.
Wählen Sie die Rolle Herausgeber von Überwachungsmetriken und dann Weiter aus.
Wählen Sie Benutzer, Gruppe oder Dienstprinzipal und dann Mitglieder auswählen aus. Wählen Sie die erstellte Anwendung und dann Auswählen aus.
Wählen Sie Überprüfen + zuweisen aus, um die Rollenzuweisung abzuschließen.
Erstellen eines Azure-Schlüsseltresors und Generieren eines Zertifikats
- Wenn Sie noch nicht über einen Azure-Schlüsseltresor verfügen, erstellen Sie einen Tresor.
- Erstellen Sie anhand der Anleitung Hinzufügen eines Zertifikats zu Key Vault ein Zertifikat.
- Laden Sie das Zertifikat anhand der Anleitung Exportieren eines Zertifikats aus Key Vault im CER-Format herunter.
Hinzufügen eines Zertifikats zur Microsoft Entra-Anwendung
Wählen Sie im Ressourcenmenü für die Microsoft Entra-Anwendung die Option Zertifikate und Geheimnisse aus.
Wählen Sie auf der Registerkarte Zertifikate die Option Zertifikat hochladen und anschließend das von Ihnen heruntergeladene Zertifikat aus.
Warnung
Zertifikate haben ein Ablaufdatum. Benutzer*innen sind dafür verantwortlich, die Gültigkeit von Zertifikaten sicherzustellen.
Hinzufügen eines CSI-Treibers und eines Speichers für den Cluster
Hinweis
Die CSI-Treiberkonfiguration von Azure Key Vault ist nur eine der Möglichkeiten, ein Zertifikat in einen Pod einzubinden. Der Remoteschreibcontainer benötigt nur für den Wert <AZURE_CLIENT_CERTIFICATE_PATH>
im Schritt Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs einen lokalen Pfad zu einem Zertifikat im Pod.
Dieser Schritt ist nur erforderlich, wenn Sie bei der Clustererstellung nicht den Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber aktiviert haben.
Führen Sie den folgenden Azure CLI-Befehl aus, um den Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber für Ihren Cluster zu aktivieren:
az aks enable-addons --addons azure-keyvault-secrets-provider --name <aks-cluster-name> --resource-group <resource-group-name>
Führen Sie die folgenden Befehle aus, um der Identität Zugriff auf den Schlüsseltresor zu gewähren:
# show client id of the managed identity of the cluster az aks show -g <resource-group> -n <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv # set policy to access keys in your key vault az keyvault set-policy -n <keyvault-name> --key-permissions get --spn <identity-client-id> # set policy to access secrets in your key vault az keyvault set-policy -n <keyvault-name> --secret-permissions get --spn <identity-client-id> # set policy to access certs in your key vault az keyvault set-policy -n <keyvault-name> --certificate-permissions get --spn <identity-client-id>
Erstellen Sie
SecretProviderClass
, indem Sie den folgenden YAML-Code in einer Datei mit dem Namen secretproviderclass.yml speichern. Ersetzen Sie die Werte füruserAssignedIdentityID
,keyvaultName
,tenantId
und die Objekte, die aus dem Schlüsseltresor abgerufen werden sollen. Informationen zu den zu verwendenden Werten, die verwendet werden sollen, finden Sie unter Verbinden Ihres Azure-Identitätsanbieters mit dem Azure Key Vault Secrets Store-CSI-Treiber in Azure Kubernetes Service (AKS).# This is a SecretProviderClass example using user-assigned identity to access your key vault apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-kvname-user-msi spec: provider: azure parameters: usePodIdentity: "false" useVMManagedIdentity: "true" # Set to true for using managed identity userAssignedIdentityID: <client-id> # Set the client ID of the user-assigned managed identity to use keyvaultName: <key-vault-name> # Set to the name of your key vault cloudName: "" # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud objects: | array: - | objectName: <name-of-cert> objectType: secret # object types: secret, key, or cert objectFormat: pfx objectEncoding: base64 objectVersion: "" tenantId: <tenant-id> # The tenant ID of the key vault
Führen Sie den folgenden Befehl für Ihren Cluster aus, um
SecretProviderClass
anzuwenden:kubectl apply -f secretproviderclass.yml
Bereitstellen eines Sidecar-Containers zum Einrichten des Remoteschreibzugriffs
Kopieren Sie den folgenden YAML-Code, und speichern Sie ihn in einer Datei. In dem YAML-Code wird der Port 8081 als Lauschport verwendet. Ändern Sie diesen Wert im YAML-Code, falls Sie einen anderen Port verwenden.
prometheus: prometheusSpec: externalLabels: cluster: <CLUSTER-NAME> ## Azure Managed Prometheus currently exports some default mixins in Grafana. ## These mixins are compatible with data scraped by Azure Monitor agent on your ## Azure Kubernetes Service cluster. These mixins aren't compatible with Prometheus ## metrics scraped by the Kube Prometheus stack. ## To make these mixins compatible, uncomment the remote write relabel configuration below: ## writeRelabelConfigs: ## - sourceLabels: [metrics_path] ## regex: /metrics/cadvisor ## targetLabel: job ## replacement: cadvisor ## action: replace ## - sourceLabels: [job] ## regex: 'node-exporter' ## targetLabel: job ## replacement: node ## action: replace ## https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write remoteWrite: - url: 'http://localhost:8081/api/v1/write' # Additional volumes on the output StatefulSet definition. # Required only for Microsoft Entra ID based auth volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: azure-kvname-user-msi containers: - name: prom-remotewrite image: <CONTAINER-IMAGE-VERSION> imagePullPolicy: Always # Required only for Microsoft Entra ID based auth volumeMounts: - name: secrets-store-inline mountPath: /mnt/secrets-store readOnly: true ports: - name: rw-port containerPort: 8081 livenessProbe: httpGet: path: /health port: rw-port initialDelaySeconds: 10 timeoutSeconds: 10 readinessProbe: httpGet: path: /ready port: rw-port initialDelaySeconds: 10 timeoutSeconds: 10 env: - name: INGESTION_URL value: '<INGESTION_URL>' - name: LISTENING_PORT value: '8081' - name: IDENTITY_TYPE value: aadApplication - name: AZURE_CLIENT_ID value: '<APP-REGISTRATION-CLIENT-ID>' - name: AZURE_TENANT_ID value: '<TENANT-ID>' - name: AZURE_CLIENT_CERTIFICATE_PATH value: /mnt/secrets-store/<CERT-NAME> - name: CLUSTER value: '<CLUSTER-NAME>'
Ersetzen Sie die folgenden Werte in der YAML-Datei:
Wert Beschreibung <CLUSTER-NAME>
Der Name Ihres AKS-Clusters. <CONTAINER-IMAGE-VERSION>
mcr.microsoft.com/azuremonitor/containerinsights/ciprod/prometheus-remote-write/images:prom-remotewrite-20240617.1
Die Version des Remoteschreibzugriff-Containerimages.<INGESTION-URL>
Der Wert für Metrikerfassungsendpunkt auf der Seite Übersicht für den Azure Monitor-Arbeitsbereich. <APP-REGISTRATION -CLIENT-ID>
Die Client-ID Ihrer Anwendung. <TENANT-ID>
Die Mandanten-ID der Microsoft Entra-Anwendung. <CERT-NAME>
Der Name des Zertifikats. <CLUSTER-NAME>
Der Name des Clusters, in dem Prometheus ausgeführt wird. Öffnen Sie Azure Cloud Shell, und laden Sie die YAML-Datei hoch.
Verwenden Sie Helm, um die YAML-Datei anzuwenden und Ihre Prometheus-Konfiguration zu aktualisieren:
# set the context to your cluster az aks get-credentials -g <aks-rg-name> -n <aks-cluster-name> # use Helm to update your remote write config helm upgrade -f <YAML-FILENAME>.yml prometheus prometheus-community/kube-prometheus-stack -namespace <namespace where Prometheus pod resides>
Überprüfung und Problembehandlung
Informationen zur Überprüfung und Problembehandlung finden Sie unter Problembehandlung bei Remoteschreibzugriff und Verwalteter Azure Monitor-Dienst für Prometheus-Remoteschreibzugriff.
Nächste Schritte
- Sammeln von Prometheus-Metriken aus einem AKS-Cluster
- Weitere Informationen zum verwalteten Azure Monitor-Dienst für Prometheus
- Verwalteter Azure Monitor-Dienst für Prometheus-Remoteschreibzugriff
- Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Authentifizierung mit verwalteten Identitäten
- Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Authentifizierung mit Microsoft Entra Workload ID (Vorschau)
- Senden von Prometheus-Daten an Azure Monitor unter Verwendung der Authentifizierung mit podseitig verwalteter Microsoft Entra-Identität (Vorschau)