Freigeben über

Mehrinstanzenfähige verwaltete Protokollierung in Container Insights (Vorschau)

Mehrinstanzenfähige Protokollierung in Container Insights ist für Kunden nützlich, die freigegebene Clusterplattformen mit AKS betreiben. Möglicherweise benötigen Sie die Möglichkeit, die Sammlung von Containerkonsolenprotokollen so zu konfigurieren, dass Protokolle von verschiedenen Teams getrennt werden, sodass jeder Zugriff auf die Containerprotokolle der Container hat, die in K8s-Namespaces ausgeführt werden, und die Möglichkeit, auf die Abrechnung und Verwaltung zuzugreifen, die dem Azure Log Analytics-Arbeitsbereich zugeordnet ist. Containerprotokolle aus Infrastrukturnamespaces wie kube-system können beispielsweise an einen bestimmten Log Analytics-Arbeitsbereich für das Infrastrukturteam geleitet werden, während die Containerprotokolle jedes Anwendungsteams an die jeweiligen Arbeitsbereiche gesendet werden können.

In diesem Artikel wird beschrieben, wie die Mehrinstanzenprotokollierung in Containereinblicken funktioniert, welche Szenarien unterstützt werden, und wie Sie Ihren Cluster integrieren, um dieses Feature zu verwenden.

Szenarien

Das Feature für die mehrmandantenfähige Protokollierung in Container Insights unterstützt die folgenden Szenarien:

  • Mehrinstanzenfähigkeit. Sendet Containerprotokolle (stdout & stderr) von einem oder mehreren K8s-Namespaces an den entsprechenden Log Analytics-Arbeitsbereich.

    Diagramm, das die Mehrinstanzenfähigkeit für Container Insights veranschaulicht

  • Multihoming: Sendet den gleichen Satz von Containerprotokollen (stdout & stderr) aus einem oder mehreren K8s-Namespaces an mehrere Log Analytics-Arbeitsbereiche.

    Diagramm, das Multihoming für Container Insights veranschaulicht.

Funktionsweise

Containereinblicke verwenden eine Datensammlungsregel (Data Collection Rule, DCR), um die Datensammlungseinstellungen für Ihren AKS-Cluster zu definieren. Beim Aktivieren von Container Insights wird automatisch eine DCR für die standardmäßige ContainerInsights-Erweiterung erstellt. Dieser DCR ist ein Singleton, was bedeutet, dass ein DCR pro Kubernetes-Cluster vorhanden ist.

Für die mehrinstanzenfähige Protokollierung fügt Container Insights Unterstützung für ContainerLogV2Extension DCRs hinzu, die zum Definieren der Sammlung von Containerprotokollen für K8s-Namespaces verwendet werden. Mehrere ContainerLogV2Extension DCRs können mit unterschiedlichen Einstellungen für verschiedene Namespaces und alle mit demselben AKS-Cluster verknüpft werden.

Wenn Sie das Mehrinstanzen-Feature über eine ConfigMap aktivieren, ruft der Container Insights-Agent regelmäßig sowohl die Standarderweiterung ContainerInsights DCR als auch die ContainerLogV2Extension DCRs ab, die dem AKS-Cluster zugeordnet sind. Dieser Abruf wird alle 5 Minuten ausgeführt, beginnend beim Starten des Containers. Wenn zusätzliche ContainerLogV2Extension DCRs hinzugefügt werden, werden sie erkannt, wenn der Abruf das nächste Mal ausgeführt wird. Alle konfigurierten Datenströme im Standard-DCR, abgesehen von Containerprotokollen, werden weiterhin wie gewohnt an den Log Analytics-Arbeitsbereich im Standardmäßigen ContainerInsights DCR gesendet.

Die folgende Logik wird verwendet, um zu bestimmen, wie die einzelnen Protokolleinträge verarbeitet werden:

  • Wenn ein ContainerLogV2Extension DCR für den Namespace des Protokolleintrags vorhanden ist, wird dieser DCR zum Verarbeiten des Eintrags verwendet. Dazu gehören das Log Analytics-Arbeitsbereichsziel und alle Transformationen zur Erfassungszeit.
  • Wenn kein ContainerLogV2Extension DCR für den Namespace des Protokolleintrags vorhanden ist, wird der Standardmäßige ContainerInsights DCR zum Verarbeiten des Eintrags verwendet.

Einschränkungen

Voraussetzungen

Aktivieren von Mehrinstanzenfähigkeit für den Cluster

  1. Befolgen Sie die Anweisungen unter Konfigurieren und Bereitstellen einer ConfigMap, um die ConfigMap für den Cluster herunterzuladen und zu aktualisieren.

  2. Aktivieren Sie den Hochskalierungsmodus, indem Sie die enabled-Einstellung unter agent_settings.high_log_scale wie folgt ändern.

    agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true

  3. Aktivieren Sie die Mehrinstanzenfähigkeit, indem Sie die enabled Einstellung unter log_collection_settings.multi_tenancy wie folgt ändern.

    log-data-collection-settings: |-
    [log_collection_settings]
       [log_collection_settings.multi_tenancy]
        enabled = true

  4. Wenden Sie die ConfigMap auf den Cluster mit den folgenden Befehlen an.

    kubectl config set-context <cluster-name>
kubectl apply -f <configmap_yaml_file.yaml>

Erstellen von DCR für jedes Anwendungs- oder Infrastrukturteam

Wiederholen Sie die folgenden Schritte, um einen separaten DCR für jede Anwendung oder jedes Infrastrukturteam zu erstellen. Jeder enthält eine Reihe von K8s-Namespaces und ein Log Analytics-Arbeitsbereichsziel.

Tipp

Stellen Sie für Multihoming eine separate DCR-Vorlage und -Parameterdatei für jeden Log Analytics-Arbeitsbereich bereit und schließen Sie denselben Satz von K8s-Namespaces ein. Dadurch können dieselben Protokolle an mehrere Arbeitsbereiche gesendet werden. Wenn Sie beispielsweise Protokolle für app-team-1, app-team-2 an LAW1 und LAW2 senden möchten,

  • Erstellen von DCR1 und Einschließen von LAW1 für App-team-1- und App-team-2-Namespaces
  • Erstellen von DCR2 und Einschließen von LAW2 für App-Team-1- und App-team-2-Namespaces

  1. Rufen Sie die folgende ARM-Vorlage und -Parameterdatei ab.

    Vorlage: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
    Parameter: https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

  2. Bearbeiten Sie die Parameterdatei mit Werten für die folgenden Werte.

    Parametername BESCHREIBUNG
    aksResourceId Azure-Ressourcen-ID des AKS-Clusters
    aksResourceLocation Azure-Region des AKS-Clusters
    workspaceResourceId Azure-Ressourcen-ID des Log Analytics-Arbeitsbereichs
    workspaceRegion Azure-Region des Log Analytics-Arbeitsbereichs
    K8sNamespaces Liste der K8s-Namespaces für Protokolle, die an den log Analytics-Arbeitsbereich gesendet werden sollen, der in dieser Parameterdatei definiert ist.
    resourceTagValues Azure-Ressourcentags zur Verwendung für AKS, Datensammlungsregel (Data Collection Rule, DCR) und Datensammlungsendpunkt (Data Collection Endpoint, DCE).
    transformKql KQL-Filter für die erweiterte Filterung mithilfe der Erfassungszeittransformation. Um beispielsweise die Protokolle für einen bestimmten Pod auszuschließen, verwenden Sie source \| where PodName != '<podName>'. Details finden Sie unter Transformationen in Azure Monitor .
    useAzureMonitorPrivateLinkScope Gibt an, ob azure Monitor Private Link Scope konfiguriert werden soll.
    azureMonitorPrivateLinkScopeResourceId Azure-Ressourcen-ID des Azure Monitor Private Link Scope.

  3. Stellen Sie die Vorlage mithilfe der Parameterdatei mit dem folgenden Befehl bereit.

    az deployment group create --name AzureMonitorDeployment --resource-group <aksClusterResourceGroup> --template-file existingClusterOnboarding.json --parameters existingClusterParam.json

Deaktivieren der Mehrinstanzenprotokollierung

Hinweis

Lesen Sie "Deaktivieren der Überwachung Ihres Kubernetes-Clusters ", wenn Sie Containereinblicke für den Cluster vollständig deaktivieren möchten.

Führen Sie die folgenden Schritte aus, um die Mehrinstanzenprotokollierung in einem Cluster zu deaktivieren.

  1. Verwenden Sie den folgenden Befehl, um alle DCR-Zuordnungen für den Cluster auflisten.

    az monitor data-collection rule association list-by-resource --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

  2. Verwenden Sie den folgenden Befehl, um alle DCR-Zuordnungen für die ContainerLogV2-Erweiterung zu löschen.

    az monitor data-collection rule association delete --association-name <ContainerLogV2ExtensionDCRA> --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

  3. Löschen Sie den ContainerLogV2Extension DCR.

    az monitor data-collection rule delete --name <ContainerLogV2Extension DCR> --resource-group <rgName>

  4. Bearbeiten Sie container-azm-ms-agentconfig und ändern Sie den Wert für enabled unter [log_collection_settings.multi_tenancy] von true zu false.

    kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml

Problembehandlung

Führen Sie die folgenden Schritte aus, um Probleme mit der Mehrinstanzenprotokollierung in Containereinblicken zu beheben.

  1. Stellen Sie sicher, dass die Protokollierung mit hoher Skalierung für den Cluster aktiviert ist.

      # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep high
  # output should be something like
   "Using config map value: enabled = true for high log scale config"

  2. Stellen Sie sicher, dass das ContainerLogV2-Schema für den Cluster aktiviert ist.

      # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if the containerlog v2 schema enabled or not
  env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION
  # output should be v2. If not v2, then check whether this is being enabled through DCR
  AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2
  # check if its enabled through DCR
  grep -r "enableContainerLogV2" /etc/mdsd.d/config-cache/configchunks/
  # validate the enableContainerLogV2 configured with true or not from JSON output

  3. Stellen Sie sicher, dass Mehrinstanzenfähigkeit für den Cluster aktiviert ist.

      # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep multi_tenancy
  # output should be something like
  "config::INFO: Using config map setting multi_tenancy enabled: true, advanced_mode_enabled: false and namespaces: [] for Multitenancy log collection"

  4. Überprüfen Sie, ob die DCRs und DCEs im Zusammenhang mit ContainerInsightsExtension und ContainerLogV2Extension erstellt werden.

        az account set -s <clustersubscriptionId>
    az monitor data-collection rule association list-by-resource --resource "<clusterResourceId>"
    # output should list both ContainerInsightsExtension and ContainerLogV2Extension DCRs associated to the cluster
    # From the output, for each dataCollectionRuleId and check dataCollectionEndpoint associated or not
    az monitor data-collection rule show --ids <dataCollectionRuleId>
    # you can also check the extension settings for the K8s namespace configuration

  5. Stellen Sie sicher, dass der Agent alle zugehörigen DCRs herunter lädt.

      # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if its enabled through DCR
  grep -r "ContainerLogV2Extension" /etc/mdsd.d/config-cache/configchunks
  # output should list all the associated DCRs and configuration
  # if there are no DCRs downloaded then likely Agent has issues to pull associate DCRs and this could be missing network or firewall issue and check for errors in mdsd.err log file
  cat /var/opt/microsoft/linuxmonagent/log/mdsd.err

  6. Überprüfen, ob fehler in fluent-bit-out-oms-runtime.log Datei vorhanden sind

      # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check for errors
  cat /var/opt/microsoft/docker-cimprov/log/fluent-bit-out-oms-runtime.log

Nächste Schritte