Traitement des incidents

Pour régler le niveau des composants d' Instana, procédez comme suit :

1. Configurez le niveau de journalisation d'un composant dans l' CoreSpec. Dans l'exemple suivant, le niveau de journalisation est remplacé par DEBUG pour le composant butler :

   apiVersion: instana.io/v1beta2
   kind: Core
   metadata:
     name: instana-core
     namespace: core
   spec:
     ...
     componentConfigs:
       - name: butler
         env:
           - name: COMPONENT_LOGLEVEL
             # Possible values are DEBUG, INFO, WARN, ERROR (not case-sensitive)
             value: DEBUG
    

2. Affichez les journaux en exécutant la commande suivante:

   kubectl logs <component name> -n instana-core
    

   <nom du composant> est le nom du composant pour lequel vous souhaitez effectuer un dépannage.

La commande « cluster-info dump » d' kubectl est un outil utile pour le débogage et le diagnostic des clusters d' Kubernetes. Il fournit un rapport détaillé sur l'état actuel du cluster Kubernetes, comprenant diverses informations sur les ressources.

Configurez l'espace de nom cible et le répertoire pour générer des informations de débogage. Dans l'exemple suivant, l'espace de nom est instana-units et le répertoire est temp. Lorsque vous exécutez cette commande, ` kubectl ` génère des fichiers ` YAML ` pour chaque ressource de l'espace instana-units de noms et enregistre ces fichiers ` YAML ` dans le temp répertoire.

kubectl cluster-info dump --namespace instana-units --output-directory temp --output yaml
 

L'extrait suivant présente une partie du contenu du répertoire temp . Dans le sous-répertoire instana-units , vous trouverez des détails sur les objets daemonsets, les déploiements, les événements, les pods et d'autres ressources dans les fichiers .yaml . Les journaux de tous les pods se trouvent dans chaque sous-répertoire instana-units\pod name .

├── instana-units
│   ├── daemonsets.yaml
│   ├── deployments.yaml
│   ├── events.yaml
│   ├── pods.yaml
│   ├── replicasets.yaml
│   ├── replication-controllers.yaml
│   ├── services.yaml
│   ├── tu-instana-prod-appdata-legacy-converter-755bb474c7-xn4vg
│   │   └── logs.txt
│   ├── tu-instana-prod-appdata-processor-6b8f448584-nmvgl
│   │   └── logs.txt
│   ├── tu-instana-prod-filler-9485b85d-wj7pv
│   │   └── logs.txt
│   ├── tu-instana-prod-issue-tracker-bbd5f5d5f-98zxx
│   │   └── logs.txt
│   ├── tu-instana-prod-processor-fc956c46c-fxs5z
│   │   └── logs.txt
│   └── tu-instana-prod-ui-backend-89bccd9c5-8lp76
│       └── logs.txt
...
└── nodes.yaml
 

• Vous pouvez choisir un autre espace de nom, tel que instana-core.
• Si kubectl n'est pas installé sur votre cluster, vous pouvez utiliser la commande oc cluster-info dump, qui fournit la même prise en charge que la commande kubectl cluster-info dump.

Pour plus de commandes de dépannage, consultez les documents « Red Hat OpenShift : dépannage des clusters » disponibles sur kubectl ainsi que le guide de référence des commandes CLI pour développeurs sur Red Hat OpenShift.

Vous pouvez utiliser certains points de terminaison de l' API des composants internes pour vous aider à administrer un backend Instana auto-hébergé. Ces appels ` API ` peuvent être envoyés depuis le cluster vers les pods correspondants à l'aide de ` curl `. Etant donné que les ressources requièrent une authentification, vous devez d'abord obtenir des données d'identification valides. Les identifiants de l' API e se trouvent dans le secret « internal-instana » de l'espace de noms « core ». Les points de terminaison de l' API, AdminAPIUser et ServiceAPIUser, contiennent deux types de données. Pour obtenir les identifiants valides pour une installation d' Instana, exécutez les commandes suivantes :

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIUser  | base64decode }}'

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIPassword  | base64decode }}'
 

Pour obtenir les données d'identification de l'administrateur, interrogez .data.adminAPIUser et .data.adminAPIPassword.

Ces données d'identification peuvent être utilisées pour les procédures suivantes.

Si certaines métriques ne sont pas affichées dans les tableaux de bord, il est possible que la limite des métriques soit atteinte. La limite de métrique est définie sur 3000, par défaut.

Astuce: Vous pouvez voir la limite actuelle sous maxMetrics dans le fichier filler/config.yaml . La limite est là pour empêcher certaines entités d'envoyer un trop grand nombre de métriques, ce qui augmenterait le stockage et l'unité centrale utilisés par l'agent de remplissage, et augmenterait la bande passante pour envoyer des métriques à l'interface utilisateur.

Pour augmenter la limite, ajoutez le bloc avec config.max.metrics dans la ressource personnalisée pour l'unité comme suit:

kind: unit
...
spec:
...
  properties:
    - name: config.max.metrics
      value: "6000"
...
 

Elasticsearch passe automatiquement son magasin de données en mode lecture seule lorsque l'espace utilisé sur le disque dépasse 85 %. Cela entraîne l'arrêt du fonctionnement du backend Instana. Libérez de l'espace sur le disque de données de l' Elasticsearch, ou augmentez sa capacité afin de rétablir un fonctionnement normal. Remarque : les autres disques « Instana » ne passent pas en mode lecture seule à des taux d'utilisation similaires (même supérieurs à 95 %), ce qui peut rendre ce problème difficile à comprendre.

Si la licence n'est pas valide ou est manquante, le serveur empêche les agents de se connecter.