Monitorer les services exécutés sur Kubernetes

Si vous disposez de services exécutés sur Kubernetes et pris en charge par notre intégration applicable, vous pouvez activer ces intégrations via notre intégration Kubernetes .

Démarrer

Notre intégration Kubernetes est fournie avec certaines de nos intégrations sur hôte. Cela vous permet d'obtenir des données pour ces services en ajoutant une section à la configuration de l'intégration Kubernetes, qui se trouve sous la forme d'un ConfigMap dans un manifeste.

Pour un exemple de monitoring Redis exécuté sur un livre d'or PHP Kubernetes , consultez ce tutoriel.

Exigences

Pour monitorer les services exécutés sur Kubernetes, vous avez besoin de :

• Un cluster Kubernetes exécutant une version prise en charge.

• Un cluster Kubernetes exécutant l’intégration Kubernetes (installer | vérifier la version | mettre à jour).

• Un service pris en charge fonctionnant sur Kubernetes qui répond à nos exigences. Les services pris en charge sont :

  • Apache
  • Cassandre
  • Base de canapé
  • Elasticsearch
  • HAProxy
  • Consul de HashiCorp
  • JMX
  • Kafka
  • Memcached
  • MongoDB
  • MySQL
  • NGINX
  • PostgreSQL
  • RabbitMQ
  • Redis

Pour cette méthode d'installation, notre intégration RabbitMQ et Apache ne rapporte pas de données d'inventaire.

Activer monitoring des services à l'aide du graphique Helm

Les services de monitoring dans Kubernetes fonctionnent en exploitant notre agent infrastructure et notre intégration sur hôte et un mécanisme de découverte automatique pour les pointer vers un pod avec un sélecteur spécifié.

Voir cet exemple de configuration pour la version 2.

Pour permettre à notre intégration Kubernetes de monitorer un ou plusieurs services :

Obtenir la configuration de base

Vous pouvez obtenir un exemple de fichier configuration pour notre intégration qui peut s'exécuter dans K8s à partir des liens suivants :

Veuillez prendre en compte que la plupart de ces exemples devront être configurés pour votre environnement particulier, principalement pour saisir les informations d'identification requises pour s'authentifier auprès du service particulier. Vous pouvez en savoir plus sur la façon de configurer chaque intégration en détail à partir des pages spécifiques à l'intégration, liées dans la liste déroulante ci-dessus.

Ajoutez la configuration à votre values-newrelic.yaml

Un fonctionnel configuration snippet doit être un document YAML avec la structure suivante :

# Top level name can be arbitrary, akin to a config file name
redis-sampleapp.yaml:
  # Discovery section will define which pods will be monitored.
  discovery:
    command:
      # nri-discovery-kubernetes is a tool that connects to the Kubelet to fetch local pods
      # without putting stress in the API Server. It accepts the following arguments:
      # --namespaces: Comma separated namespaces to limit discovery on
      # --tls: Use tls for connecting to the kubelet
      # --port: Port used to connect to the kubelet. Defaults to 10255.
      exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
      # Monitor pods which have a `app=sampleapp` label
      match:
        label.app: sampleapp

  # Integrations section contains the integration configs.
  # ${placeholders} will be replaced with the specified attributes for each pod that is discovered
  integrations:
    - name: nri-redis  # Integration name, should not be changed
      env:
        # Using the discovered pod IP as the hostname address
        HOSTNAME: ${discovery.ip}
        PORT: 6379
        # Other integration options go here

Ce snippet doit être ajouté à la section integrations, sous newrelic-infrastructure dans votre fichier values-newrelic.yaml. Par exemple:

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# Other settings...

newrelic-infrastructure:
  # verboseLog: true
  integrations:
    redis-sampleapp.yaml:
      discovery:
        command:
          # --namespaces: Comma separated list of namespaces to discover pods on
          # --port: Port used to connect to the kubelet. Default is 10255
          # --tls: Use secure (TLS) connection
          exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
          match:
            label.app: sampleapp

      integrations:
        - name: nri-redis
          env:
            HOSTNAME: ${discovery.ip}
            PORT: 6379

l'intégration ciblant d'autres pods doit avoir sa propre section à côté de redis-sampleapp.yaml.

les intégrations sont des binaires autonomes et sont exécutées par l'agent infrastructure inclus dans le pod newrelic-nrk8s-kubelet-xxxxx. Les fichiers de configuration sont déployés sur tous les pods du DaemonSet nrk8s-kubelet, mais la découverte garantit que chaque pod ciblera uniquement les pods de service planifiés dans le même nœud que ce pod nrk8s-kubelet particulier. Si une instance du DaemonSet nrk8s-kubelet ne possède aucun pod correspondant aux étiquettes spécifiées, l'intégration ne sera pas exécutée par cette instance ### .

Vérifiez que l'intégration fonctionne

Accédez à one.newrelic.com > All capabilities > Infrastructure, sélectionnez Third party services, puis sélectionnez le dashboard du service. Vous devriez voir des données signalées.

Si vous ne voyez pas les données ici, il se peut que l'intégration manque de certains paramètres dont elle a besoin pour s'exécuter ou qu'elle ne puisse pas atteindre le service cible. Vous pouvez obtenir le log de l'intégration en exécutant :

$
kubectl logs -n newrelic newrelic-nrk8s-kubelet-xxxxx agent

Assurez-vous de sélectionner le pod particulier du DaemonSet nrk8s-kubelet qui est planifié à côté du pod que l'intégration doit cibler. Vous pouvez vérifier quelle instance s'exécute sur quel nœud en exécutant la commande suivante :

$
kubectl get pods -n newrelic -o wide -l app.kubernetes.io/component=kubelet

Notes supplémentaires sur l'activation des services

• L'activation de plusieurs services peut utiliser plus de ressources que ce qui est défini dans les limites de ressources du fichier de configuration de l'intégration Kubernetes. Si cela devient un problème, augmentez la limite dans la section resources .
• L'intégration Kubernetes ne se met pas à jour automatiquement. Pour de meilleurs résultats, mettez à jour régulièrement .

En savoir plus

Plus de ressources pour en savoir plus sur la configuration :

• Apprenez les détails techniques sur le fonctionnement de la configuration.
• Découvrez comment configurer monitoring de plusieurs services avec le même fichier de configuration.
• Consultez un didacticiel étape par étape montrant comment monitorer un service Redis sur Kubernetes.

Activer monitoring des services à l'aide de manifestes

Pour chaque service que vous souhaitez monitorer, vous devez ajouter un configuration fichier pour cette intégration à de notre Kubernetes intégration configuration. Ce document couvrira les sujets suivants :

• Comment configuration snippet fonctionne l' YAML spécifique au service
• Ajout du YAML spécifique au service dans le fichier de configuration de l'intégration Kubernetes
• Ajout de plusieurs services au fichier de configuration de l'intégration Kubernetes

Comment fonctionne la configuration YAML spécifique au service

La configuration de notre intégration Kubernetes suit le format ConfigMap . L’utilisation d’un ConfigMap nous permet de découpler la configuration de l’intégration de l’image Kubernetes . L’autre avantage est qu’un ConfigMap peut être mis à jour automatiquement sans recharger le conteneur en cours d’exécution.

Étant donné que l’agent infrastructure utilise YAML pour configurer son intégration associée, ConfigMaps est un bon choix pour stocker YAML. (Pour plus d'informations sur le format du fichier de configuration, consultez le format du fichier de configuration d'intégration.)

L'image d'intégration Kubernetes est livrée avec une fonctionnalité de découverte automatique qui simplifie la configuration de plusieurs instances de services à l'aide d'un seul fichier configuration . Par exemple, si vous avez plusieurs instances NGINX en cours d'exécution, la création d'un fichier configuration intégration NGINX pour chaque instance serait difficile à implémenter et à mettre à jour. Avec notre option de découverte automatique, vous pouvez découvrir et monitorer toutes vos instances NGINX avec un seul fichier configuration .

Chaque intégration a sa propre configuration YAML spécifique. Notre fichier de configuration par défaut d'intégration NGINX ressemble à ceci :

discovery:
  command:
    # Use the following optional arguments:
    # --namespaces: Comma separated list of namespaces to discover pods on
    # --port: Port used to connect to the kubelet. Default is 10255
    # --tls: Use secure (TLS) connection
    # Custom Example:
    # exec: /var/db/newrelic-infra/nri-discovery-kubernetes --namespaces namespace1,namespace2 --port 10250 --tls
    # Default
    exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
    match:
      label.app: nginx
integrations:
  - name: nri-nginx
    env:
      STATUS_URL: http://${discovery.ip}/status
      STATUS_MODULE: discover
      METRICS: 1

La configuration ci-dessus permet les opérations suivantes :

• Exécute nri-discovery-kubernetes pour interroger les données du nœud sur lequel nous nous trouvons actuellement.

• Analyse les données qui reviennent et recherche tout pod Kubernetes doté d'un conteneur Kubernetes avec une étiquette app= avec la valeur nginx.

• Pour toutes les correspondances, il tente d'exécuter l'intégration NGINX. L'URL d'état est construite à partir de :

  • L'adresse IP du pod
  • La page d'état est extraite de l'étiquette du pod K8s appelée status_url

Cette découverte automatique fonctionne de la même manière que la découverte automatique de conteneurs utilisée par l'agent infrastructure . Pour des options plus avancées, voir conteneur auto-discovery.

Ajouter un service YAML à la configuration d'intégration Kubernetes

L'intégration reconnaîtra le snippet ci-dessus, si vous le placez à l'intérieur d'un ConfigMap désigné. Si vous utilisez notre intégration Kubernetes v3, un ConfigMap avec un nom se terminant par -integrations-cfg devrait déjà exister.

Si vous utilisez la version 2 de l'intégration Kubernetes, consultez Ajouter un service YAML.

Localisez la carte de configuration et ajoutez-y le snippet modifié, de sorte qu'elle ressemble à ceci :

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: newrelic-infrastructure-integrations-cfg
  namespace: newrelic
data:
  nginx-config.yml: |
    discovery:
      command:
        # Use the following optional arguments:
        # --namespaces: Comma separated list of namespaces to discover pods on
        # --port: Port used to connect to the kubelet. Default is 10255
        # --tls: Use secure (TLS) connection
        # Custom Example:
        # exec: /var/db/newrelic-infra/nri-discovery-kubernetes --namespaces namespace1,namespace2 --port 10250 --tls
        # Default
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
        match:
          label.app: nginx
    integrations:
      - name: nri-nginx
        env:
          STATUS_URL: http://${discovery.ip}/status
          STATUS_MODULE: discover
          METRICS: 1

Si vous utilisez notre intégration Kubernetes v3, ce ConfigMap sera déjà monté dans le conteneur requis.

Veuillez noter que le même ConfigMap peut contenir plusieurs fichiers de configuration, ce qui est recommandé pour limiter au minimum les modifications apportées aux manifestes.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: newrelic-infrastructure-integrations-cfg
  namespace: newrelic
data:
  nginx-config.yml: |
    discovery: # ...
    integrations:
      - name: nri-nginx
        # ...
  redis-config.yml: |
    discovery: # ...
    integrations:
      - name: nri-redis
        # ...

Comment utiliser les données rapportées

Vous pouvez en savoir plus sur la façon de rechercher et d’utiliser vos données Kubernetes ici et vous pouvez consulter notre schéma de données K8sServiceSample ici.