Debug e risoluzione dei problemi

Modifica online

Raccogli le informazioni sul cluster e i log di debug per risolvere i problemi relativi a Standard Edition.

Attenzione:

Standard Edition in proprio 1.10.3 and earlier versions:

Nelle installazioni online (non isolate fisicamente), la maggior parte stanctl dei comandi relativi al ciclo di vita, come ad stanctl up esempio, non verrà eseguita.
Nelle installazioni isolate fisicamente, i stanctl comandi continuano a funzionare.

Azione richiesta: eseguire l'aggiornamento stanctl a 1.10.4 o o versioni successive prima di eseguire un'operazione relativa al ciclo di vita.

Esempio: nelle distribuzioni online che eseguono stanctl1.10.3 o versioni precedenti, qualsiasi flusso di lavoro che arresti i servizi, ad esempio un stanctl down comando, prima di un backup, non può essere completato perché il comando stanctl up successivo non va a buon fine. Esegui l'aggiornamento stanctl a 1.10.4 o o a una versione successiva prima di procedere con questi passaggi.

Informazioni di raccolta

Modifica online

Creare un file di archiviazione con le informazioni sul proprio cluster. È possibile utilizzare le informazioni contenute nel file per risolvere i problemi o condividere il file con il team di supporto.

Il file di archivio raccoglie le seguenti informazioni:

Log di contenitore
Manifesti delle risorse (in formato YAML )
stanctl log
Informazioni di sistema che includono l'utilizzo di memoria, CPU e CPU
Montaggi disco e relativo utilizzo
File aperti (allocati, liberi e massimi)
Log del backend

Utilizzare il comando seguente per creare il file di archivio:

stanctl debug

Dopo aver eseguito il comando, vengono visualizzati i seguenti messaggi. Quando si visualizza Done! nei messaggi, significa che il file di archivio è pronto.

./stanctl debug
⠼ Streaming container logs  [26s] ✓
⠸ Gathering resource manifests  [27s] ✓
⠋ Gathering stanctl config files  [0s] ✓
⠋ Gathering system information  [0s] ✓
⠹ Creating tar file  [0s] ✓

----------------------
Done!
Debug package -> debug_20231027111737
Compressed debug package -> debug_20231027111737.tar.gz
----------------------

Modifica il livello di log per i componenti di Instana

Modifica online

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

Modifica il file di configurazione principale, ad esempio, $HOME/.stanctl/values/instana-core/custom-values.yaml.

Configurare il livello di log di un componente nel Core o nell'Unit CR. Nell'esempio seguente, il livello di log viene modificato in DEBUG per il butler componente :

componentConfigs:
  - name: butler
    env:
      - name: COMPONENT_LOGLEVEL
        # Possible values are DEBUG, INFO, WARN, ERROR (not case-sensitive)
        value: DEBUG

Applica i valori personalizzati eseguendo il seguente comando:
```
stanctl backend apply
 
```
Per visualizzare i log, eseguire 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.

Certificati Secure Sockets Layer ( SSL )

Modifica online

Comprendere le configurazioni supportate, le limitazioni e le procedure di risoluzione dei problemi relative ai certificati SSL.

Certificati Wildcard SSL

È possibile utilizzare certificati con caratteri jolly SSL con Instana Standard Edition. Alcune configurazioni con caratteri jolly non sono supportate, mentre determinati modelli di implementazione richiedono un'analisi più approfondita.

Scenario di esempio

Si consideri la seguente struttura ` DNS `:

Certificato con caratteri jolly: *.company.com
Instana backend: instana.company.com
Punto finale dell'accettore dell'agente: agent-acceptor.instana.company.com
Instana Interfaccia utente: unit-tenant.instana.company.com

Limiti dei caratteri jolly a livello singolo

In questo scenario non è possibile utilizzare un certificato con caratteri jolly, come ad *.company.com esempio

Motivo: per impostazione predefinita, un asterisco (*) può sostituire solo un'etichetta nel nome di un' DNS. Non può estendersi su più livelli di sottodomini.

Regole di corrispondenza dei certificati

Risultati della ricerca per certificato *.company.com :

www.company.com
api.company.com
mail.company.com

Il certificato *.company.com non corrisponde:

a.b.company.com
dev.api.company.com
company.com

Nota: ogni punto (.) separa le etichette dell' DNS. Il carattere jolly sostituisce esattamente una sola etichetta.

Per supportare l'implementazione di Instana, utilizzare una delle seguenti opzioni:

Creare un certificato con caratteri jolly per l'intero dominio di base Instana :
```
*.instana.company.com 
```

Utilizza un certificato SAN che includa tutti i nomi host richiesti.

DNS: api.example.com
DNS: dev.api.example.com
DNS: prod.api.example.com

Combinare più voci con caratteri jolly all'interno di un certificato SAN:
```
DNS: *.example.com
DNS: *.api.example.com
```

Ripristina il certificato autofirmato

È possibile ripristinare un certificato autofirmato TLS precedentemente rimosso.

Elimina il segreto esistente " TLS ":

kubectl delete secret instana-tls -n instana-core

Generare un nuovo certificato autofirmato:
```
stanctl be apply --core-tls-generate-cert
```
Risultato:
- Viene generato e applicato un nuovo certificato autofirmato SSL.
- TLS La crittografia è abilitata per gli endpoint Instana.
- I browser moderni (come Chrome o Firefox ) visualizzano avvisi di sicurezza poiché il certificato non è stato emesso da un'autorità di certificazione attendibile.
Importante: sebbene i browser contrassegnino la connessione come non attendibile, tutte le comunicazioni rimangono crittografate.

Riepilogo

I certificati con caratteri jolly a livello singolo (ad esempio, *.company.com) non supportano i sottodomini a più livelli.
Instana Lo standard richiede solitamente certificati SAN o certificati con caratteri jolly per il dominio di base.
Se necessario, è possibile rigenerare in tutta sicurezza i certificati autofirmati, tenendo conto degli avvisi che potrebbero comparire nel browser.

Risoluzione dei problemi

Modifica online

Risolvere questi problemi.

Instana L'agente non viene visualizzato nell'interfaccia utente

Modifica online

Dopo aver eliminato l'agente Instana configurato per il monitoraggio remoto e aver installato l'agente Instana per l'automonitoraggio, è possibile che l'agente non venga visualizzato nell'interfaccia utente di Instana.

È possibile che l'agente stia tentando di connettersi al backend remoto Instana anziché a quello locale Instana.

Per risolvere questo problema, installare l'agente e specificare l'host dell'endpoint di backend e una chiave dell'agente:

stanctl agent apply --agent-cluster-name <cluster-name> --agent-endpoint-host acceptor.instana-core --agent-endpoint-port 8600 --agent-zone-name <zone-name> --agent-key <agent-key-of-local-backend>

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

Modifica online

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 di tipo « Instana » non attivano la modalità di sola lettura a livelli di utilizzo simili (anche superiori al 95%), il che può rendere questo problema di difficile comprensione.

Per risolvere il problema, procedere in uno dei seguenti modi:

Liberare spazio 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 correttamente.

Nota: altri dischi di tipo « Instana » non passano alla modalità di sola lettura a livelli di utilizzo simili (anche superiori al 95%), il che potrebbe creare confusione durante la risoluzione dei problemi.

Instana L'aggiornamento del backend non va a buon fine a causa di un'installazione non corretta del grafico " Helm "

Modifica online

L'aggiornamento del backend di Instana non va a buon fine dopo l'esecuzione del stanctl backend apply comando. Potrebbe comparire il seguente errore:

Error: another operation (install/upgrade/rollback) is in progress

Nel file console.log potresti trovare informazioni simili alle seguenti voci:

ts=2025-05-26T12:26:09Z level=INFO msg="upgrading Helm chart" name=instana-core release=instana-core version=1.8.1 namespace=instana-core
ts=2025-05-26T12:26:09Z level=DEBUG msg="preparing upgrade for instana-core"

Questo problema indica che l'installazione del grafico " Helm " del grafico principale corrente è danneggiata; è possibile ripristinarla utilizzando il seguente comando:

Elimina il vecchio segreto del grafico " Helm " dallo instana-core spazio dei nomi.
```
kubectl delete secret -n instana-core -l owner=helm
 
```
Aggiornare il backend.

stanctl up

L'agente host non riesce a connettersi al backend Instana sugli host SLES

Modifica online

Dopo aver installato l'agente host sull'host locale su un sistema SLES ( SUSE Linux Enterprise Server ) 15 SP5 per il monitoraggio automatico, l'agente non si connette automaticamente al backend Instana.

È necessario utilizzare l'agente esterno URL per connettersi al backend come host remoto.

Utilizzare il seguente comando:

stanctl agent apply --agent-endpoint-host agent-acceptor.<base_domain> --agent-endpoint-port 8443

Kafka I pod mostrano lo stato dell' CrashLoopBackOff

Modifica online

Kafka I pod non si riavviano dopo lo spegnimento dell'host backend di Instana. Potresti visualizzare lo CrashLoopBackOff stato dei pod di Kafka.

Per risolvere il problema, riavvia il backend di Instana.

Chiudere il backend.
```
stanctl down
 
```
Avviare il backend.
```
stanctl up
 
```

Una volta riavviato il backend, controlla lo stato dei pod Kafka .

kubectl get pods --all-namespaces | grep kafka

Lo stato del pod Kafka deve essere visualizzato come Running.

I test sintetici pianificati non vengono eseguiti dopo un'operazione di backup e ripristino di Instana

Modifica online

Dopo il ripristino dei dati del backend e degli agenti di Instana, i test sintetici pianificati non vengono eseguiti.

Per risolvere questo problema, riavvia il pod synthetic-pop-controller sul cluster in cui è installato.

Standard Edition L'installazione su RHEL 9.3 non va a buon fine

Modifica online

Red Hat® Enterprise Linux® 9.3 utilizza iptables 1.8.8.

Se stai installando Standard Edition su RHEL 9.3, l'installazione potrebbe non andare a buon fine a causa di iptables 1.8.8.

Per risolvere il problema, aggiornare l'host a RHEl 9.4, che aggiorna anche iptables alla versione 1.8.10.

L'aggiornamento non va a buon fine su Standard Edition 1.9.x

Modifica online

Quando si esegue l'aggiornamento di Standard Edition 1.9.x a una versione più recente, è possibile che venga visualizzato il seguente errore:

Error: installation failed for prerequisite app coredns: Unable to continue with install: ConfigMap "coredns" in namespace "kube-system" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "coredns"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"

Per risolvere il problema, esegui nuovamente il stanctl up comando.

Systemd non imposta una directory di lavoro predefinita

Modifica online

Quando stanctl viene avviato da un servizio systemd, systemd non imposta automaticamente una directory di lavoro. Se non si specifica una directory di lavoro, systemd esegue il servizio da /. Questa operazione può comportare stanctl la creazione di file, come i dati dei cluster o le configurazioni di Kubernetes, in una posizione .stanctlerrata (spesso / o /root/), anche se il servizio utilizza un utente non root.

Per risolvere il problema, è necessario aggiungere una WorkingDirectory= riga al servizio systemd per creare i file nella directory home corretta degli utenti. Ad esempio, WorkingDirectory=/home/instana.

Impossibile aggiornare la licenza

Modifica online

Quando si esegue il stanctl license update comando, è possibile che l'operazione non vada a buon fine e venga visualizzato il seguente messaggio di errore:

...
no dependency found: 'instana-core'
...

Esegui i seguenti comandi per aggiornare la licenza:

stanctl license download --sales-key=<your-key>
stanctl backend apply

Instana L'aggiornamento del backend non va a buon fine a causa dell'esaurimento dello spazio su disco del nodo

Modifica online

L'installazione o l'aggiornamento del backend di Instana potrebbe non andare a buon fine se il nodo è sottoposto a un carico eccessivo sul disco.

Sintomi

Potresti notare uno o più dei seguenti sintomi:

L'installazione o l'aggiornamento del backend non va a buon fine.
I pod sono ancora in sospeso.
Alcuni carichi di lavoro mostrano ContainerStatusUnknown.

Causa

Durante l'installazione, l'aggiornamento o l'importazione di pacchetti in modalità air-gapped, l'utilizzo del disco aumenta temporaneamente mentre vengono elaborate le immagini dei container e gli artefatti. Se il nodo esaurisce lo spazio su disco, Kubernetes imposta una condizione di " DiskPressure " e impedisce l'avvio di nuovi pod.

Verifica

Esegui il seguente comando per verificare lo stato del nodo:
```
kubectl describe node <node-name>
```
Nella sezione "Condizioni", seleziona l'opzione " DiskPressure ".
Esegui il seguente comando per verificare l'utilizzo del disco:
```
df -h
```
Verificare se lo spazio su disco è quasi esaurito o ha raggiunto la capacità massima.

Soluzione

Per risolvere il problema, eseguire una delle seguenti operazioni:

Elimina le immagini dei container inutilizzate o i file superflui per liberare spazio su disco.
Aumentare la capacità di archiviazione del nodo.

Ripristino

Se i carichi di lavoro rimangono in quello ContainerStatusUnknown stato dopo aver liberato spazio su disco, riavviare il nodo. Una volta completato il riavvio, riprova a eseguire l'installazione o l'aggiornamento.

La licenza non è valida o manca

Modifica online

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

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.
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
```
Controlla il componente backend di Groundskeeper, lo stato del pod e i log:
```
kubectl get pods -n instana-core | grep groundskeeper 
```
Se la licenza risulta ancora non valida, contatta l'assistenza di IBM.

L'installazione non va a buon fine con il messaggio «Errore grave di glibc: la CPU non supporta l' x86‑64‑v2”

Modifica online

Sintomo

L'installazione fallisce nelle prime fasi dell'esecuzione stanctl install, generando un errore simile al seguente:

Fatal glibc error: CPU does not support x86-64-v2

Questo errore si verifica in genere prima che tutti i componenti siano stati installati e può impedire l'avvio di servizi quali Cassandra e Kafka.

Causa

Questo errore indica che il sistema operativo non è in grado di rilevare il set di istruzioni dell' x86‑64‑v2. La causa più comune è una configurazione della CPU della macchina virtuale che non rende disponibili i flag della CPU richiesti, spesso a causa di impostazioni di compatibilità con versioni precedenti.

Risoluzione

Negli ambienti VMware e vSphere, questo problema è solitamente causato dalla selezione di un'architettura di CPU virtuale obsoleta o dall'attivazione di modalità di compatibilità della CPU che limitano i set di istruzioni. Per risolvere il problema:

Quando si configura la macchina virtuale, evitare di utilizzare i profili di compatibilità CPU legacy.
Assicurati che la mascheratura della CPU non sia abilitata.
Se la funzione EVC (Enhanced vMotion Compatibility) è abilitata, verificare che sia impostata su un livello che supporti le istruzioni dell' x86‑64‑v2.
Spegnere la macchina virtuale e aggiornare la configurazione della CPU.
Se necessario, ricrea la macchina virtuale con le impostazioni della CPU aggiornate.

Dopo aver applicato le modifiche, verificare che i flag della CPU richiesti siano visibili nel sistema operativo guest prima di rieseguire l'installazione.

Contatta il supporto

Modifica online

Se non è possibile risolvere il problema in modo autonomo, rivolgersi al supporto IBM. Fornire il file di archiviazione creato al team di supporto.