Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

34.5. Configuration de l'opérateur d'observabilité du réseau

Vous pouvez mettre à jour la ressource API Flow Collector pour configurer le Network Observability Operator et ses composants gérés. Le collecteur de flux est explicitement créé lors de l'installation. Étant donné que cette ressource fonctionne à l'échelle du cluster, un seul FlowCollector est autorisé et il doit être nommé cluster.

34.5.1. Voir la ressource FlowCollector
Copier lien

Vous pouvez visualiser et éditer YAML directement dans la console web d'OpenShift Container Platform.

Procédure

  1. Dans la console web, naviguez vers Operators Installed Operators.
  2. Sous la rubrique Provided APIs de la rubrique NetObserv Operatorsélectionnez Flow Collector.
  3. Sélectionner cluster puis sélectionnez l'onglet YAML onglet. Là, vous pouvez modifier la ressource FlowCollector pour configurer l'opérateur Network Observability.

L'exemple suivant montre un exemple de ressource FlowCollector pour l'opérateur OpenShift Container Platform Network Observability :

Exemple de ressource FlowCollector 

apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: DIRECT
  agent:
    type: EBPF
1 

    ebpf:
      sampling: 50
2 

      logLevel: info
      privileged: false
      resources:
        requests:
          memory: 50Mi
          cpu: 100m
        limits:
          memory: 800Mi
  processor:
    logLevel: info
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 800Mi
    conversationEndTimeout: 10s
    logTypes: FLOW
3 

    conversationHeartbeatInterval: 30s
  loki:
4 

    url: 'http://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network'
    statusUrl: 'https://loki-query-frontend-http.netobserv.svc:3100/'
    authToken: FORWARD
    tls:
      enable: true
      caCert:
        type: configmap
        name: loki-gateway-ca-bundle
        certFile: service-ca.crt
  consolePlugin:
    register: true
    logLevel: info
    portNaming:
      enable: true
      portNames:
        "3100": loki
    quickFilters:
5 

    - name: Applications
      filter:
        src_namespace!: 'openshift-,netobserv'
        dst_namespace!: 'openshift-,netobserv'
      default: true
    - name: Infrastructure
      filter:
        src_namespace: 'openshift-,netobserv'
        dst_namespace: 'openshift-,netobserv'
    - name: Pods network
      filter:
        src_kind: 'Pod'
        dst_kind: 'Pod'
      default: true
    - name: Services network
      filter:
        dst_kind: 'Service'
Copy to Clipboard Toggle word wrap

1
La spécification de l'agent, spec.agent.type, doit être EBPF. eBPF est la seule option prise en charge par OpenShift Container Platform.
2
Vous pouvez définir la spécification d'échantillonnage, spec.agent.ebpf.sampling, pour gérer les ressources. Des valeurs d'échantillonnage plus faibles peuvent consommer une grande quantité de ressources de calcul, de mémoire et de stockage. Vous pouvez atténuer ce phénomène en spécifiant une valeur de ratio d'échantillonnage. Une valeur de 100 signifie qu'un flux sur 100 est échantillonné. Une valeur de 0 ou 1 signifie que tous les flux sont capturés. Plus la valeur est faible, plus le nombre de flux renvoyés et la précision des mesures dérivées augmentent. Par défaut, l'échantillonnage eBPF est fixé à une valeur de 50, ce qui signifie qu'un flux est échantillonné tous les 50. Il est à noter qu'un plus grand nombre de flux échantillonnés signifie également un plus grand besoin de stockage. Il est recommandé de commencer par les valeurs par défaut et de les affiner de manière empirique, afin de déterminer les paramètres que votre cluster peut gérer.
3
Les spécifications facultatives spec.processor.logTypes, spec.processor.conversationHeartbeatInterval, et spec.processor.conversationEndTimeout peuvent être définies pour activer le suivi des conversations. Lorsque cette option est activée, les événements de conversation peuvent être consultés dans la console web. Les valeurs pour spec.processor.logTypes sont les suivantes : ou : FLOWS CONVERSATIONS ENDED_CONVERSATIONS ALL les exigences en matière de stockage sont les plus élevées pour ALL et les plus faibles pour ENDED_CONVERSATIONS.
4
La spécification Loki, spec.loki, spécifie le client Loki. Les valeurs par défaut correspondent aux chemins d'installation de Loki mentionnés dans la section Installation de l'opérateur Loki. Si vous avez utilisé une autre méthode d'installation pour Loki, indiquez les informations client appropriées pour votre installation.
5
La spécification spec.quickFilters définit les filtres qui s'affichent dans la console web. Les clés du filtre Application,src_namespace et dst_namespace, sont inversées (!), de sorte que le filtre Application affiche tout le trafic provenant ou à destination de l'un des espaces de noms ou does not qui provient de, ou a une destination vers, n'importe quel espace de noms openshift- ou netobserv. Pour plus d'informations, voir Configuration des filtres rapides ci-dessous.

Vous pouvez configurer la ressource FlowCollector pour utiliser Kafka. Une instance Kafka doit être en cours d'exécution, et un sujet Kafka dédié à OpenShift Container Platform Network Observability doit être créé dans cette instance. Pour plus d'informations, reportez-vous à la documentation Kafka, telle que la documentation Kafka avec AMQ Streams.

L'exemple suivant montre comment modifier la ressource FlowCollector pour l'opérateur OpenShift Container Platform Network Observability afin d'utiliser Kafka :

Exemple de configuration Kafka dans la ressource FlowCollector 

  deploymentModel: KAFKA
1 

  kafka:
    address: "kafka-cluster-kafka-bootstrap.netobserv"
2 

    topic: network-flows
3 

    tls:
      enable: false
4
Copy to Clipboard Toggle word wrap

1
Définissez spec.deploymentModel à KAFKA au lieu de DIRECT pour activer le modèle de déploiement Kafka.
2
spec.kafka.address fait référence à l'adresse du serveur d'amorçage Kafka. Vous pouvez spécifier un port si nécessaire, par exemple kafka-cluster-kafka-bootstrap.netobserv:9093 pour utiliser TLS sur le port 9093.
3
spec.kafka.topic doit correspondre au nom d'un sujet créé dans Kafka.
4
spec.kafka.tls peut être utilisé pour chiffrer toutes les communications vers et depuis Kafka avec TLS ou mTLS. Lorsqu'il est activé, le certificat de l'autorité de certification Kafka doit être disponible en tant que ConfigMap ou Secret, à la fois dans l'espace de noms où le composant du processeur flowlogs-pipeline est déployé (par défaut : netobserv) et dans celui où les agents eBPF sont déployés (par défaut : netobserv-privileged). Il doit être référencé avec spec.kafka.tls.caCert. Lors de l'utilisation de mTLS, les secrets clients doivent également être disponibles dans ces espaces de noms (ils peuvent être générés, par exemple, à l'aide de l'opérateur utilisateur AMQ Streams) et référencés avec spec.kafka.tls.userCert.

34.5.3. Exporter des données de flux de réseau enrichies
Copier lien

Vous pouvez envoyer des flux réseau à Kafka, afin qu'ils puissent être consommés par n'importe quel processeur ou stockage prenant en charge l'entrée Kafka, comme Splunk, Elasticsearch ou Fluentd.

Conditions préalables

  • Kafka installé

Procédure

  1. Dans la console web, naviguez vers Operators Installed Operators.
  2. Sous la rubrique Provided APIs de la rubrique NetObserv Operatorsélectionnez Flow Collector.
  3. Sélectionnez cluster puis sélectionnez l'onglet YAML l'onglet

  4. Modifiez le site FlowCollector pour configurer spec.exporters comme suit : 

    apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  exporters:
  - type: KAFKA
      kafka:
        address: "kafka-cluster-kafka-bootstrap.netobserv"
        topic: netobserv-flows-export
    1 
    
        tls:
          enable: false
    2
    Copy to Clipboard Toggle word wrap
    1
    L'opérateur d'observabilité du réseau exporte tous les flux vers le sujet Kafka configuré.
    2
    Vous pouvez chiffrer toutes les communications vers et depuis Kafka avec SSL/TLS ou mTLS. Lorsqu'il est activé, le certificat de l'autorité de certification Kafka doit être disponible en tant que ConfigMap ou Secret, dans l'espace de noms où le composant du processeur flowlogs-pipeline est déployé (par défaut : netobserv). Il doit être référencé avec spec.exporters.tls.caCert. Lors de l'utilisation de mTLS, les secrets des clients doivent également être disponibles dans ces espaces de noms (ils peuvent être générés, par exemple, à l'aide de l'opérateur utilisateur AMQ Streams) et référencés avec spec.exporters.tls.userCert.
  5. Après configuration, les données de flux réseau peuvent être envoyées vers une sortie disponible au format JSON. Pour plus d'informations, voir Network flows format reference

34.5.4. Mise à jour de la ressource Collecteur de flux
Copier lien

Au lieu d'éditer YAML dans la console web d'OpenShift Container Platform, vous pouvez configurer les spécifications, telles que l'échantillonnage eBPF, en corrigeant la ressource personnalisée (CR) flowcollector:

Procédure

  1. Exécutez la commande suivante pour corriger le CR flowcollector et mettre à jour la valeur spec.agent.ebpf.sampling: 

    $ oc patch flowcollector cluster --type=json -p \N-[{"op\N" : \N "replace\N", \N "path\N" : \N"/spec/agent/ebpf/sampling\N", \N "value\N" : <nouvelle valeur>}] -n netobserv"
    Copy to Clipboard Toggle word wrap

34.5.5. Configuration des filtres rapides
Copier lien

Vous pouvez modifier les filtres dans la ressource FlowCollector. Des correspondances exactes sont possibles en utilisant des guillemets doubles autour des valeurs. Sinon, des correspondances partielles sont utilisées pour les valeurs textuelles. Le caractère bang ( !), placé à la fin d'une clé, signifie la négation. Voir l'exemple de ressource FlowCollector pour plus de détails sur la modification du YAML.

Note

Le filtre correspondant aux types "tous" ou "n'importe lequel" est un paramètre de l'interface utilisateur que les utilisateurs peuvent modifier à partir des options de la requête. Il ne fait pas partie de la configuration de cette ressource.

Voici une liste de toutes les clés de filtrage disponibles :

Expand
Tableau 34.2. Touches de filtrage
Universelle*SourceDestinationDescription

espace de noms

src_namespace

dst_namespace

Filtrer le trafic lié à un espace de noms spécifique.

nom

src_name

dst_name

Filtrer le trafic lié à un nom de ressource leaf donné, tel qu'un pod, un service ou un nœud spécifique (pour le trafic hôte-réseau).

kind

src_kind

dst_kind

Filtre le trafic lié à un type de ressource donné. Les types de ressources comprennent la ressource feuille (Pod, Service ou Node) ou la ressource propriétaire (Deployment et StatefulSet).

nom_du_propriétaire

src_owner_name

dst_owner_name

Filtrer le trafic lié à un propriétaire de ressource donné, c'est-à-dire une charge de travail ou un ensemble de pods. Par exemple, il peut s'agir d'un nom de déploiement, d'un nom de StatefulSet, etc.

ressource

src_resource

dst_resource

Filtrer le trafic lié à une ressource spécifique désignée par son nom canonique, qui l'identifie de manière unique. La notation canonique est kind.namespace.name pour les types à espace de noms, ou node.name pour les nœuds. Par exemple, Deployment.my-namespace.my-web-server.

adresse

src_address

dst_address

Filtre le trafic lié à une adresse IP. Les protocoles IPv4 et IPv6 sont pris en charge. Les plages CIDR sont également prises en charge.

mac

src_mac

dst_mac

Filtrer le trafic lié à une adresse MAC.

port

src_port

dst_port

Filtrer le trafic lié à un port spécifique.

adresse_hôte

src_host_address

dst_host_address

Filtre le trafic lié à l'adresse IP de l'hôte où les pods fonctionnent.

protocole

N/A

N/A

Filtrer le trafic lié à un protocole, tel que TCP ou UDP.

  • Les clés universelles filtrent pour n'importe quelle source ou destination. Par exemple, le filtrage de name: 'my-pod' signifie tout le trafic en provenance de my-pod et tout le trafic à destination de my-pod, quel que soit le type de correspondance utilisé, qu'il s'agisse de Match all ou Match any.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat