Risoluzione dei problemi

Informazioni su come risolvere un problema con Custom Edition.

Raccogliere i dati diagnostici per la risoluzione dei problemi

Utilizzare il comando kubectl instana diagnostics per raccogliere una serie completa di dati diagnostici relativi a Kubernetes e, piattaforma, nodo e datastore, al fine di risolvere i problemi di una distribuzione self-hosted di Instana (Custom Edition) in esecuzione su Kubernetes o OpenShift.

Per eseguire il comando, utilizzare la seguente sintassi:

kubectl instana diagnostics [flags]
kubectl instana debug [flags]

kubectl instana debug è un alias di kubectl instana diagnostics e si comporta esattamente allo stesso modo.

Nota:
Questo comando non gestisce né configura un cluster. Si connette a un cluster Kubernetes già in esecuzione utilizzando il contesto kubeconfig attivo.

Opzioni di comando

Tabella 1. Opzioni di comando
Contrassegno Breve Immettere Predefinito Descrizione
--download-key - Stringa Obbligatorio Instana Scarica la chiave utilizzata come password del registro dei container (nome utente: _) per scaricare l'immagine di node-collector. È necessario specificare questo flag per eseguire il comando.
--output-dir -o Indirizzario Directory di lavoro corrente La directory in cui il comando crea la cartella di diagnostica con data e ora e l'archivio.
--deep-debug - Booleano false Esegue una serie aggiuntiva di script di debug approfondito al termine della raccolta dei dati diagnostici standard.
--max-log-lines -l Numero intero 20000 Numero massimo di righe di log da raccogliere per ogni container. Impostare su 0 per raccogliere tutte le righe di log disponibili.
--log-collection-days - Numero intero 7 Numero di giorni di registrazioni storiche da raccogliere.
--node-collector-image - Stringa Immagine predefinita inclusa nella versione Immagine del container utilizzata dal node-collector temporaneo DaemonSet. Sovrascrivere questo flag per le implementazioni con registry in modalità “air-gapped” o private.
--node-collector-namespace - Stringa default Spazio dei nomi in cui il comando crea il node-collector temporaneo DaemonSet.
--external-script - Fettina di stringa Nessuna Uno o più script di shell forniti dall'utente da eseguire durante la raccolta dei dati diagnostici. Specificare più valori sotto forma di elenco separato da virgole oppure ripetendo il flag.
--env-file - File Nessuna Carica le variabili d'ambiente da un .env file per sovrascrivere la configurazione della diagnostica (spazi dei nomi, credenziali, selettori di pod e impostazioni simili).

Una volta completata la raccolta dei dati diagnostici, il comando visualizza il percorso del pacchetto generato.

Done!
Diagnostics package ->
<output-dir>/diagnostics_<YYYYMMDDHHmmss>

Il comando crea una cartella con data e ora all'interno della cartella specificata con --output-dir.

Cosa raccoglie il motore

Il motore di diagnostica esegue i seguenti collettori.

  • Risorse di tipo " Kubernetes " con ambito di cluster

    Il motore raccoglie le risorse Kubernetes a livello di cluster, tra cui:

    • Nodi
    • Spazio dei nomi
    • ClusterRoles
    • ClusterRoleBindings
    • StorageClasses
    • PersistentVolumes
    • CustomResourceDefinitions (CRD)
    • Altre risorse a livello di cluster
  • Informazioni sulla rete dell'host

    Il motore raccoglie informazioni relative alla rete dell'host, tra cui:

    • Tabelle di instradamento
    • Interfacce di rete
    • regole di iptables
    • Parametri di rete sysctl
    • Informazioni sulla connettività
  • Envoy diagnostica

    Il motore raccoglie i dati diagnostici di “ Envoy ” dai pod del bilanciatore di carico “ Instana Core”, tra cui:

    • Statistiche sui cluster
    • Configurazione dell'ascoltatore
    • Instradamenti
    • Informazioni sull'integrità
  • Risorse " Kubernetes " con spazio dei nomi

    Il motore raccoglie le risorse Kubernetes con namespace in tutti i namespace Instana, tra cui:

    • Pod
    • Distribuzioni
    • StatefulSets
    • Servizi
    • ConfigMaps
    • Segreti (valori omessi)
    • Eventi
    • ReplicaSets
    • DaemonSets
    • PersistentVolumeClaims
    • HorizontalPodAutoscalers
    • Risorse personalizzate
  • Informazioni a livello di nodo

    Il motore utilizza un " DaemonSet " temporaneo per raccogliere informazioni a livello di nodo, tra cui:

    • CPU
    • Memoria
    • Topologia del disco
    • Versione del kernel e del sistema operativo
    • Punti di montaggio
    • Utilizzo disco
    • Configurazione di sysctl
    • Output di dmesg

    Il collettore di nodi temporaneo DaemonSet applica una tolleranza per i caratteri jolly. Ciò consente al motore di raccogliere i dati diagnostici da ogni nodo del cluster, inclusi quelli del piano di controllo, dell’infrastruttura, dei datastore dedicati, delle GPU e di eventuali nodi con taint personalizzati. Questo comportamento è automatico e non è necessario specificare alcun parametro aggiuntivo.

  • Instana diagnostica del backend

    Il motore raccoglie i dati diagnostici del back Instana, tra cui:

    • Risposte relative agli endpoint di salute
    • Metriche interne
    • Utilizzo delle risorse del pod
  • Kafka diagnostica

    Il motore raccoglie i dati diagnostici dell' Kafka, tra cui:

    • Elenco degli argomenti
    • Ritardo gruppo di consumatori
    • Configurazione del broker
    • Kafka Stato delle risorse personalizzate
  • Cassandra diagnostica

    Il motore raccoglie i dati diagnostici dell' Cassandra, tra cui:

    • Output del comando "nodetool status"
    • Output del comando `info` di nodetool
    • Statistiche tabella
    • Risultati della convalida CQL
  • Elasticsearch diagnostica

    Il motore raccoglie i dati diagnostici dell' Elasticsearch, tra cui:

    • Integrità del cluster
    • Statistiche di indice
    • Assegnazione degli shard
    • Elasticsearch Stato delle risorse personalizzate
  • BeeInstana diagnostica

    Il motore raccoglie i dati diagnostici dell' BeeInstana, tra cui:

    • Log dell'aggregatore
    • Log di Ingestor
    • Log di Monconfig
    • BeeInstana Stato delle risorse personalizzate
    • Metriche interne
  • Kubernetes registri di servizio a livello di nodo

    Il motore raccoglie i log di servizio a livello di nodo per le distribuzioni standard di Kubernetes, comprese le piattaforme cloud gestite. Ecco alcuni esempi:

    • kubelet
    • containerd
    • Docker durata (ove applicabile)
  • OpenShift-specific registri dei servizi della piattaforma

    Il motore raccoglie i log di servizio della piattaforma OpenShift-specific insieme ai log di servizio a livello di nodo Kubernetes. Ecco alcuni esempi:

    • CRI-O
    • OpenShift API Server
    • Daemon di configurazione del sistema
    • Altri componenti della piattaforma
    Nota:
    Sui cluster " non-OpenShift ", questo collettore termina l'esecuzione senza generare alcun output.
  • Script di debug approfondito (richiede l' --deep-debug))

    --deep-debugQuando si abilita questa opzione, il motore esegue una serie aggiuntiva di script di debug approfondito al termine della raccolta standard. Ecco alcuni esempi:

    • Diagnostica avanzata della rete
    • Ispezione approfondita del datastore

Spazi dei nomi predefiniti

Il motore di diagnostica utilizza i seguenti spazi dei nomi predefiniti.

Tabella 2. Spazi dei nomi predefiniti
Componente Namespace predefinito
ClickHouse instana-clickhouse
PostgreSQL instana-postgres
BeeInstana instana-beeinstana
Elasticsearch instana-elasticsearch
Cassandra instana-cassandra
Kafka instana-kafka
Agent Instana instana-agent

Il motore rileva automaticamente gli spazi dei nomi Core e Unit dal cluster.

Riferimenti alla variabile di ambiente

È possibile specificare la configurazione utilizzando direttamente le variabili d'ambiente oppure passando un .env file tramite il --env-file flag. Laddove il valore predefinito è indicato come “Rilevato automaticamente”, il motore legge il valore dai segreti di Kubernetes nel namespace pertinente.

ClickHouse

Tabella 3. ClickHouse variabili d'ambiente
Variabile Predefinito Descrizione
CLICKHOUSE_NAMESPACE instana-clickhouse ClickHouse spazio dei nomi
CLICKHOUSE_NOME_POD chi-clickhouse-local-0-0-0 Pod " ClickHouse " di Target
CLICKHOUSE_CLUSTER local Nome del cluster
CLICKHOUSE_ORARI_FINESTRE 24 Ore di dati diagnostici da raccogliere
CLICKHOUSE_ADMIN_USER Rilevato automaticamente Nome utente amministratore
CLICKHOUSE_ADMIN_PASSWORD Rilevato automaticamente Password amministratore
CLICKHOUSE_UTENTE Rilevato automaticamente Nome utente dell'applicazione
CLICKHOUSE_PASSWORD Rilevato automaticamente Password applicazione

PostgreSQL

Tabella 4. PostgreSQL variabili d'ambiente
Variabile Predefinito Descrizione
POSTGRES_NAMESPACE instana-postgres PostgreSQL spazio dei nomi
POSTGRES_ADMIN_USER Rilevato automaticamente Nome utente amministratore
POSTGRES_ADMIN_PASSWORD Rilevato automaticamente Password amministratore
POSTGRES_USER Rilevato automaticamente Nome utente dell'applicazione
POSTGRES_PASSWORD Rilevato automaticamente Password applicazione

BeeInstana

Tabella 5. BeeInstana variabili d'ambiente
Variabile Predefinito Descrizione
BEEINSTANA_NAMESPACE instana-beeinstana BeeInstana spazio dei nomi
BEEINSTANA_UTENTE Rilevato automaticamente Nome utente dell'applicazione
BEEINSTANA_PASSWORD Rilevato automaticamente Password applicazione
BEEINSTANA_POD_SELECTOR app.kubernetes.io/name=beeinstana Selettore di pod per i pod " BeeInstana "

Elasticsearch

Tabella 6. Elasticsearch variabili d'ambiente
Variabile Predefinito Descrizione
ELASTICSEARCH_NAMESPACE instana-elasticsearch Elasticsearch spazio dei nomi
ELASTICSEARCH_ADMIN_USER Rilevato automaticamente Nome utente amministratore
ELASTICSEARCH_ADMIN_PASSWORD Rilevato automaticamente Password amministratore
ELASTICSEARCH_USER Rilevato automaticamente Nome utente dell'applicazione
ELASTICSEARCH_PASSWORD Rilevato automaticamente Password applicazione
ELASTICSEARCH_POD_SELECTOR common.k8s.elastic.co/type=elasticsearch Selettore di pod per i pod " Elasticsearch "

Cassandra

Tabella 7. Cassandra variabili d'ambiente
Variabile Predefinito Descrizione
CASSANDRA_NAMESPACE instana-cassandra Cassandra spazio dei nomi
CASSANDRA_ADMIN_USER Rilevato automaticamente Nome utente amministratore
CASSANDRA_ADMIN_PASSWORD Rilevato automaticamente Password amministratore
CASSANDRA_USER Rilevato automaticamente Nome utente dell'applicazione
CASSANDRA_PASSWORD Rilevato automaticamente Password applicazione
CASSANDRA_POD_SELECTOR app.kubernetes.io/name=cassandra Selettore di pod per i pod " Cassandra "

Kafka

Tabella 8. Kafka variabili d'ambiente
Variabile Predefinito Descrizione
KAFKA_NAMESPACE instana-kafka Kafka spazio dei nomi
KAFKA_UTENTE_AMMINISTRATORE Rilevato automaticamente Nome utente amministratore
KAFKA_ADMIN_PASSWORD Rilevato automaticamente Password amministratore
KAFKA_UTENTE_CONSUMATORE Rilevato automaticamente Nome utente del consumatore
KAFKA_CONSUMER_PASSWORD Rilevato automaticamente Password dell'utente
KAFKA_PRODUCER_USER Rilevato automaticamente Nome utente del produttore
KAFKA_PRODUCER_PASSWORD Rilevato automaticamente Password del produttore
KAFKA_SASL_MECHANISM SCRAM-SHA-512 Meccanismo SASL
KAFKA_SASL_PLAINTEXT SASL_PLAINTEXT Protocollo di trasporto SASL
KAFKA_POD_SELECTOR app.kubernetes.io/name=kafka Selettore di pod per i pod " Kafka "

Core e Agent

Tabella 9. Variabili d'ambiente del core e dell'agente
Variabile Predefinito Descrizione
CORE_NAMESPACE Rilevato automaticamente Spazio dei nomi per il componente principale " Instana "
CORE_NAME Rilevato automaticamente Nome dell'istanza principale di Instana
INSTANA_AGENT_NAMESPACE instana-agent Instana Spazio dei nomi dell'agente

Credenziali di backend API

Tabella 10. Credenziali API del backend
Variabile Descrizione
ADMIN_API_USER Nome utente amministratore API (rilevato automaticamente)
ADMIN_API_PASSWORD Password amministratore API (rilevata automaticamente)
SERVICE_API_USER Nome utente del servizio " API " (rilevato automaticamente)
SERVICE_API_PASSWORD Password del servizio " API " (rilevata automaticamente)

Registro Docker

Tabella 11. Docker variabili d'ambiente del Registro di sistema
Variabile Predefinito Descrizione
DOCKER_REGISTRY_USER _ Nome utente del Registro di sistema
DOCKER_REGISTRY_PASSWORD Valore di --download-key Password registro

Esempio di file.env

Crea un .env file per sovrascrivere i valori di configurazione predefiniti.

CLICKHOUSE_NAMESPACE=my-clickhouse
KAFKA_NAMESPACE=my-kafka

CLICKHOUSE_ADMIN_USER=clickhouse_operator_user
CLICKHOUSE_ADMIN_PASSWORD=s3cr3t

CLICKHOUSE_WINDOW_HOURS=48

CASSANDRA_POD_SELECTOR=app=instana-cassandra,tier=database

Esegui il comando con il tuo file di impostazioni personalizzate:

kubectl instana diagnostics \
  --download-key <download-key> \
  --env-file ./my-overrides.env

Regolazione del livello di log per i componenti di Instana

Per regolare il livello dei componenti dell' Instana, procedere come segue:

  1. Configurare il livello di log di un componente nell' CoreSpec. Nell'esempio seguente, si modifica il livello di log a DEBUG per il componente 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. Visualizza i log immettendo il seguente comando:

    kubectl logs <component name> -n instana-core

    <nome componente> è il nome del componente per cui si desidera eseguire la risoluzione dei problemi.

Utilizzo di un comando specifico di " kubectl " per il debug e la diagnosi

Il comando `cluster-info dump` di ` kubectl ` è uno strumento utile per il debug e la diagnostica dei cluster di ` Kubernetes `. Fornisce un rapporto dettagliato sullo stato attuale del cluster Kubernetes, comprese varie informazioni sulle risorse.

Configurare lo spazio dei nomi di destinazione e la directory per emettere le informazioni di debug. Nel seguente esempio, lo spazio dei nomi è instana-units e la directory temp. Quando si esegue questo comando, ` kubectl ` genera file ` YAML ` per ogni risorsa nel instana-units namespace e salva tali file ` YAML ` nella temp directory.

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

Il seguente estratto mostra parte del contenuto nella directory temp . Nella sottodirectory instana-units , puoi trovare i dettagli sulle serie di daemon, le distribuzioni, gli eventi, i pod e altre risorse nei file .yaml . I log su tutti i pod si trovano in ogni sottodirectory 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
Nota:
  • È possibile scegliere un altro spazio dei nomi come instana-core.
  • Se non kubectl è installato sul cluster, è possibile utilizzare il comando oc cluster-info dump, che offre lo stesso supporto del comando kubectl cluster-info dump .

Per ulteriori comandi di risoluzione dei problemi, consultare la guida alla risoluzione dei problemi dei cluster all’indirizzo kubectl e il riferimento ai comandi per sviluppatori della CLI all’indirizzo Red Hat OpenShift.

Utilizzo del backend interno API

È possibile utilizzare alcuni endpoint interni dei componenti API per facilitare l'amministrazione di un backend Instana in proprio. È possibile inviare queste chiamate ` API ` dal cluster ai pod corrispondenti utilizzando ` curl `. Poiché le risorse richiedono l'autenticazione, è necessario prima ottenere credenziali valide. Le credenziali dell' API e sono disponibili nel segreto "internal-instana" nel namespace core. Gli endpoint dell' API e contengono due tipi di URL: AdminAPIUser e ServiceAPIUser. Per ottenere le credenziali valide per un'installazione di Instana, eseguire i seguenti comandi:

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 }}'

Per ottenere le credenziali per l'utente amministratore, interrogare .data.adminAPIUser e .data.adminAPIPassword.

È possibile utilizzare queste credenziali per le seguenti procedure.

Reimpostazione della password utente di Instana

Per reimpostare la password di un account utente Instana, eseguire il seguente comando:

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/reset/user -u {adminAPIUser}:{adminAPIPassword} -H 'Content-Type: application/json' -d '{"email":"{user}","pass":"{newPassword}"}'

Disattivazione delle configurazioni dei provider SSO ( LDAP / SAML / OIDC)

Se si utilizza un provider di identità per l'autenticazione di Instana, disattivare tale provider con il seguente comando. Successivamente, potrai utilizzare gli account utente interni Instana per l'autenticazione.

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/idp -u {adminAPIUser}:{adminAPIPassword}

Disattivazione di " 2FA " su un account utente

Per disattivare l'autenticazione a due fattori ( 2FA ) per un account utente Instana, eseguire il seguente comando:

kubectl exec -it -n instana-core deploy/butler -- curl -X DELETE http://localhost:8601/admin/2fa/users/{email} -u {adminAPIUser}:{adminAPIPassword}

Verifica delle licenze

Per verificare tutte le licenze memorizzate, eseguire il seguente comando:

kubectl exec -it -n instana-core deploy/groundskeeper -- curl -X GET http://localhost:8600/license/list/{tenant}/{unit} -u {serviceAPIUser}:{serviceAPIPassword}

Alcuni indicatori non vengono visualizzati nei dashboard

Se i dashboard non visualizzano alcune metriche, probabilmente hai raggiunto il limite previsto per le metriche. Il limite è impostato su 3.000 per impostazione predefinita.

Suggerimento: è possibile vedere il limite corrente in maxMetrics nel file filler/config.yaml . Il limite è presente per impedire ad alcune entità di inviare troppe metriche, che aumenterebbero l'archiviazione e la CPU utilizzata dal riempimento e aumenterebbero la larghezza di banda per inviare le metriche all'interfaccia utente.

Per aumentare il limite, aggiungere il blocco con config.max.metrics nella risorsa personalizzata per l'unità nel modo seguente:

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

Instana Il backend smette di funzionare quando il disco dati dell' Elasticsearch e supera l'85% di utilizzo

Elasticsearch imposta automaticamente l'archivio dati in modalità di sola lettura quando lo spazio utilizzato sul disco supera l'85%. Ciò provoca l'interruzione del funzionamento del backend Instana. Liberare spazio sul disco dati dell' Elasticsearch e oppure aumentarne la capacità per ripristinare il normale funzionamento. Nota: altri dischi “ Instana ” non attivano la modalità di sola lettura a livelli di utilizzo simili (anche superiori al 95%), il che può rendere questo problema poco chiaro.

Per risolvere il problema, procedere in uno dei seguenti modi:
  • Spazio libero sul disco dati dell' Elasticsearch
  • Aumentare lo spazio su disco assegnato a Elasticsearch
Quando è disponibile spazio sufficiente, Elasticsearch riprende le normali operazioni di scrittura e il backend torna a funzionare.
Nota:
Altri dischi “ Instana ” non entrano in modalità di sola lettura a livelli di utilizzo simili (anche superiori al 95%), il che potrebbe creare confusione durante la risoluzione dei problemi.

La licenza non è valida o manca

Se la licenza non è valida o manca, il backend impedisce agli agenti di connettersi.

Quando ciò accade

  • La licenza importata non è valida.
  • L'operatore dell' Instana e non può applicare la licenza al backend di Groundskeeper.

Come risolvere i problemi

  1. Verificare che la chiave di vendita contenuta nel segreto principale corrisponda alle stringhe di licenza presenti nel segreto dell'unità. Se i dati non corrispondono, scarica nuovamente la licenza utilizzando il codice di vendita corretto.
  2. Controlla i log dell'operatore di Instana per verificare la presenza di errori nell'importazione delle licenze:
    kubectl logs -n instana-operator deployment/instana-operator --tail=100
  3. Controlla il componente backend di Groundskeeper, lo stato del pod e i log:
    kubectl get pods -n instana-core | grep groundskeeper
  4. Se la licenza risulta ancora non valida, contatta l'assistenza di IBM.