Personnalisation des agents de surveillance Kubernetes

Dans IBM Cloud Monitoring, vous pouvez personnaliser la configuration de l'agent de surveillance pour définir un niveau de journalisation, bloquer des ports, inclure ou exclure des données de métriques, ajouter ou supprimer des événements, et filtrer des conteneurs.

Pour personnaliser un agent de surveillance Kubernetes, vous devez configurer le fichier sysdig-agent-configmap.yaml.

Vous pouvez modifier un fichier de configuration de deux façons :

Méthode 1 : Modification du fichier directement sur le cluster où l'agent est en cours d'exécution.
Méthode 2 : Modification du fichier localement et application des modifications au cluster.

Modification de la configuration de l'agent de surveillance Kubernetes à l'aide de kubectl edit

Pour modifier la configuration d'un agent de surveillance Kubernetes, procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```
Effectuez les modifications. Remarque : Reportez-vous aux instructions de l'éditeur vi pour savoir comment effectuer des modifications.

Sauvegardez les modifications. Elles sont appliquées automatiquement.

Modification de la configuration de l'agent de surveillance Kubernetes à l'aide de kubectl apply

Utilisez cette méthode si les fichiers yaml de configuration sont stockés et gérés dans un système de contrôle des sources.

Pour modifier la configuration d'un agent de surveillance Kubernetes, procédez comme suit :

Procurez-vous la copie la plus récente de chaque fichier à partir du contrôleur source.

Pour créer un fichier local avec la configuration déployée dans un cluster, vous pouvez également exécuter la commande suivante :
```
kubectl get configmap sysdig-agent -n=ibm-observe -o=yaml > prod-sysdig-agent-configmap.yaml
```
Modifiez la configuration.
Appliquez les modifications à l'aide des commandes suivantes :
```
kubectl apply -f sysdig-agent-configmap.yaml
```

Les agents en cours d'exécution sélectionneront automatiquement la nouvelle configuration une fois que Kubernetes aura propagé les modifications sur tous les noeuds du cluster.

Ajout d'étiquettes supplémentaires aux données collectées à partir d'un agent de surveillance Kubernetes

Pour ajouter d'autres étiquettes à une configuration d'agent de surveillance Kubernetes que vous avez déjà déployée, procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```

Effectuez les modifications. Remarque : Reportez-vous aux instructions de l'éditeur vi pour savoir comment effectuer des modifications.

apiVersion: v1
  data:
    dragent.yaml:
        k8s_cluster_name: mycluster
        collector: ingest.us-south.monitoring.cloud.ibm.com
        collector_port: 6443
        ssl: true
        sysdig_capture_enabled: false
        new_k8s: true
        tags: department:finance,region:us-south
  ...

Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Pour l'exemple fourni, vous obtiendrez les balises agent.tag.department et agent.tag.region Vous pouvez les utiliser pour définir des alertes, personnaliser des portées et bien davantage.

Collecte d'un ensemble d'événements Kubernetes

Monitoring prend en charge les intégrations d'événements avec Kubernetes. Monitoring reconnaissent automatiquement ces services et en collectent les données. Vous pouvez éditer le fichier de configuration de l'agent pour modifier son comportement par défaut et inclure ou exclure des données d'événement.

Par défaut, seul un ensemble limité d'événements est collecté. Pour plus d'informations sur les événements collectés par défaut, voir Types d'événements.

Pour ajouter ou supprimer des événements, vous devez personnaliser le fichier sysdig-agent-configmap.yaml et spécifier les événements à inclure et ceux à filtrer. Remarque : Une entrée dans une section du fichier sysdig-agent-configmap.yaml remplace la totalité de la section dans la configuration par défaut.

Pour filtrer des événements provenant de pods Kubernetes, procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```
Effectuez les modifications. Ajoutez la section events ou mettez-la à jour.

Remarque : Reportez-vous aux instructions de l'éditeur vi pour savoir comment effectuer des modifications.

Par exemple, vous voudrez peut-être collecter des événements d'extraction de pod Kubernetes et filtrer d'autres événements de pod qui sont collectés par défaut. Vous souhaitez toujours collecter les événements Kubernetes par défaut pour les noeuds et les contrôleurs de réplication.
```
events:
  kubernetes:
    pod:
      - Pulling
```
Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Un autre exemple vous permet de voir comment collecter un sous-ensemble d'événements Kubernetes : vous voulez uniquement surveiller les événements en cours d'extraction, extraits et en échec pour les pods.

Option 1 : Définissez la séquence d'entrées sous forme de liste à puces :

events:
  kubernetes:
    pod:
      - Pulling
      - Pulled
      - Failed

Option 2 : Définissez la séquence d'entrées sur une seule ligne entre crochets :
```
events:
  kubernetes:
    pod: [Pulling, Pulled, Failed]
```

Pour plus d'informations sur l'utilisation des événements personnalisés, voir Evénements personnalisés.

Désactivation de la collecte d'événements

Pour empêcher un agent de surveillance de collecter des événements Kubernetes, vous devez modifier le fichier sysdig-agent-configmap.yaml. Définissez l'entrée Kubernetes dans la section events sur none.

Procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```
Effectuez les modifications. Ajoutez la section events ou mettez-la à jour.
```
events:
  kubernetes: none
```
Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Inclusion et exclusion de métriques

Pour filtrer des métriques personnalisées, vous devez personnaliser la section metrics_filter dans le fichier sysdig-agent-configmap.yaml. Vous pouvez indiquer les métriques à inclure et celles à filtrer en configurant les paramètres de filtrage include et exclude.

L'ordre des règles de filtrage est défini comme suit : la première règle correspondant à une métrique est appliquée. Les règles de suivi pour cette métrique sont ignorées.

Procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```
Effectuez les modifications. Ajoutez la section metrics_filter ou mettez-la à jour.

Par exemple, si la section metrics_filter d'un agent de surveillance se présente comme suit :
```
metrics_filter:
  - include: metricA.*
  - exclude: metricA.*
  - include: metricB.*
  - include: haproxy.backend.*
  - exclude: haproxy.*
  - exclude: metricC.*
```
- Vous configurez l'agent de surveillance pour qu'il collecte toutes les données des métriques commençant par metricA, metricB et haproxy.backend.
- Vous filtrez les métriques commençant par metricC et d'autres métriques commençant par haproxy.
- L'entrée exclude: metricA.* est ignorée.
Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Filtrage de conteneurs et d'objets Kubernetes à partir desquels les données sont collectées

Un agent de surveillance Kubernetes collecte automatiquement les métriques de tous les conteneurs qu'il détecte dans un cluster, notamment Prometheus, StatsD, JMX, app-checks, ainsi que les métriques intégrées.

Vous pouvez personnaliser l'agent de surveillance pour exclure des conteneurs de la collecte de métriques.

Lorsque vous excluez des conteneurs, prenez en compte les informations suivantes :

Vous réduisez la charge de l'agent et du système de back end.
Vous collectez uniquement les données provenant des conteneurs que vous souhaitez surveiller.
Vous pouvez maîtriser les coûts en signalant les conteneurs importants et en filtrant les conteneurs inutiles ou non essentiels.

Pour activer la fonction de filtrage des conteneurs par un agent de surveillance, vous devez personnaliser le fichier sysdig-agent-configmap.yaml. Définissez l'entrée use_container_filter dans la section containers sur true. Remarque : Par défaut, cette fonction est désactivée. Définissez ensuite les règles incluant une ou plusieurs conditions à appliquer.

Le tableau suivant présente les paramètres permettant de définir les règles de filtrage dans un cluster :

Paramètres permettant de définir les conditions applicables aux conteneurs
Paramètre	Condition
`container.image`	Nom de l'image de conteneur
`container.name`	Nom du conteneur
`container.label.*`	Libellé du conteneur
`kubernetes.object.*`	Objet Kubernetes. Il peut s'agir d'un pod, d'un espace de nom, etc.
`kubernetes.object.annotation.*`	Annotation d'objet Kubernetes
`kubernetes.object.label.*`	Libellé d'objet Kubernetes
`all`	Règle par défaut pour spécifier tous les objets

Prenez en compte les informations suivantes qui concernent la façon dont l'agent de surveillance applique les règles que vous définissez dans la section container_filter :

Vous définissez des conditions en les configurant avec les paramètres de filtrage include et exclude.
La première règle correspondante dans la liste détermine si le conteneur est inclus ou exclu.
Les conditions sont constituées d'un nom de clé et d'une valeur. Si la clé donnée pour un conteneur correspond à la valeur, la règle s'applique.
Lorsqu'une règle contient plusieurs conditions, all the conditions doivent correspondre pour que la règle s'applique.

Pour filtrer les conteneurs surveillés par un agent de surveillance dans un cluster, procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```

Effectuez les modifications. Ajoutez l'entrée use_container_filter et la section container_filter ou mettez à jour les entrées existantes.

Par exemple, voici un extrait d'une mappe de configuration :

# Enable the feature
use_container_filter: true
#
# Include or exclude conditions
container_filter:
  - include:
        container.image: appdomain/my-app-image
  - include:
        container.name: my-java-app
  - exclude:
        kubernetes.namespace.name: kube-system

Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Blocage de ports

Pour bloquer le trafic réseau et les métriques provenant de ports réseau, vous devez personnaliser la section blacklisted_ports dans le fichier sysdig-agent-configmap.yaml. Vous devez répertorier les ports à partir desquels vous voulez filtrer les données.

Le port 53 (DNS) est toujours sur la liste rouge et n'a pas besoin d'être spécifié dans blacklisted_ports.

Procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```
Effectuez les modifications. Ajoutez la section metrics_filter ou mettez-la à jour.

L'exemple suivant montre comment définir la section blacklisted_ports d'un agent de surveillance pour exclure les données provenant des ports 6666 et 6379 :
```
blacklisted_ports:
  - 6666
  - 6379
```
Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Modification des configurations de journalisation

Pour configurer les configurations de journalisation, vous devez personnaliser la section log dans le fichier sysdig-agent-configmap.yaml.

L'agent de surveillance génère des entrées de journal dans /opt/draios/logs/draios.log.

Le fichier journal pivote lorsque sa taille atteint 10 Mo.
Les 10 derniers fichiers journaux sont conservés. L'horodatage qui est ajouté au nom de fichier permet de déterminer les fichiers à conserver.

Le tableau suivant répertorie certains scénarios courants, ainsi que la valeur que vous devez définir dans chacun d'eux :

Entrées dans la section du journal
Cas d'utilisation	Entrée de section de journal	Valeur par défaut
Traitement des incidents liés au comportement de l'agent	`file_priority: debug`	`info`
Réduction de la sortie de la console de conteneur	`console_priority: warning`	`info`
Filtrage des événements par gravité	`event_priority: warning`	`information`
Vérification de l'inclusion ou de l'exclusion de métriques	`metrics_excess_log: true`	`false`

Modification du niveau de journalisation

L'entrée file_priority de la section log contrôle le type des entrées de journal enregistrées dans le fichier /opt/draios/logs/draios.log.
L'entrée console_priority de la section log contrôle le type des entrées de journal enregistrées dans la sortie de la console du conteneur lors de l'exécution de l'agent conteneurisé.
Le niveau de journalisation par défaut est info, où une entrée de journal est créée pour chaque transmission de métriques agrégées aux serveurs de back end, sur la base d'une par seconde, outre les entrées pour les avertissements et les erreurs.
Les niveaux de journalisation valides sont les suivants : none, error, warning, info, debug, trace.

Filtrage des événements Kubernetes par gravité

L'entrée event_priority de la section log contrôle le type des événements envoyés à partir de l'agent.
Le niveau de journalisation par défaut est information. Cela signifie que seuls les événements de type information et de gravité supérieure sont transmis.
Les niveaux valides sont les suivants : emergency, alert, critical, error, warning, notice, information, debug et none. Remarque : Les valeurs sont répertoriées par ordre de priorité décroissant.
La définition du niveau sur none bloque la collecte de tous les événements.

Journalisation des métriques incluses ou exclues dans un fichier

La définition de metrics_excess_log sur true dans la section log active la journalisation des métriques personnalisées incluses ou exclues.
La journalisation des métriques est désactivée par défaut.
La journalisation se produit au niveau INFO toutes les 30 secondes et dure 10 secondes.
Le paramètre metricsfile est requis pour spécifier l'emplacement des métriques à enregistrer par l'agent. La valeur metricsfile.location correspond à un chemin d'accès relatif sous le répertoire /opt/draios. Remarque : l'entrée metricsfile est spécifiée au même niveau que log(et non comme enfant dans le fichier yaml)
Les données de journalisation sont formatées comme suit :
```
+/-[type] [metric included/excluded]: metric.name (filter: +/-[metric.filter])
```
- Le symbole +/- indique si la métrique est incluse ou exclue. Le signe plus (+) indique qu'une métrique est incluse, tandis que le signe moins (-) indique qu'elle est exclue.
- [type] spécifie le type de métrique, par exemple, statsd.
- [métrique incluse/exclue] indique de manière lisible si la métrique est incluse ou exclue.
- metric.name indique le nom de la métrique.
- (filter : +/-metric[metric.filter]) fournit des informations sur les filtres définis dans la section metrics_filter du fichier sysdig-agent-configmap.yaml.

Voici un exemple d'entrée de journal :

-[statsd] metric excluded: mongo.statsd.vsize (filter: -[mongo.statsd.*])
+[statsd] metric included: mongo.statsd.netIn (filter: +[mongo.statsd.net*])

Pour configurer les paramètres de journalisation, procédez comme suit :

Configurez l'environnement de cluster. Exécutez les commandes suivantes :

Commencez par vous procurer la commande de définition de la variable d'environnement et téléchargez les fichiers de configuration Kubernetes.
```
ibmcloud ks cluster config --cluster <cluster_name_or_ID>
```
Editez le fichier sysdig-agent-configmap.yaml.

Exécutez la commande suivante :
```
kubectl edit configmap sysdig-agent -n ibm-observe
```

Effectuez les modifications. Ajoutez la section log ou mettez-la à jour et incluez les configurations à modifier en fonction des descriptions précédentes.

Exemple :

log:
  file_priority: warning
  console_priority: info
  event_priority: warning
  metrics_excess_log: true
metricsfile: { location : metrics }

Sauvegardez les modifications.

Elles sont appliquées automatiquement.

Exemple de fichier yaml configmap

apiVersion: v1
data:
  dragent.yaml: |
    ### Agent tags
    # tags: linux:ubuntu,dept:dev,local:nyc

    ####
    # collector address
    # collector: 192.168.1.1
    # Collector TCP port
    # collector_port: 6666
    # Whether collector accepts ssl
    # ssl: true
    # collector certificate validation
    # ssl_verify_certificate: true
    #######################################
    #
    k8s_cluster_name: cluster12
    collector: ingest.us-south.monitoring.cloud.ibm.com
    collector_port: 6443
    ssl: true
    ssl_verify_certificate: true
    sysdig_capture_enabled: false
    new_k8s: true
    tags: type:mycluster,region:us-south
    blacklisted_ports:
      - 6666
      - 6379
    events:
      kubernetes:
        node:
          - Rebooted
    metrics_filter:
      - include: metricA.*
      - exclude: metricA.*
      - include: metricB.*
    use_container_filter: true
    container_filter:
      - exclude:
        kubernetes.namespace.name: kube-system
    log:
      file_priority: warning
      console_priority: info
      event_priority: warning
      metrics_excess_log: true
    metricsfile: { location : metrics }
kind: ConfigMap
metadata:
  annotations:
...