Skip to main content
Data Infrastructure Insights
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Risoluzione dei problemi delle prestazioni

Collaboratori netapp-alavoie
PDF

Usa questa procedura per analizzare un volume, un datastore, una macchina virtuale, un carico di lavoro Kubernetes o un altro oggetto DII lento, correlando metriche, avvisi e log della piattaforma.

Nota Il DII MCP è una funzionalità "Anteprima" ed è pertanto soggetto a modifiche.

Prerequisiti

  • Il nome della risorsa interessata e l'ora approssimativa dell'incidente.

  • Un intervallo di tempo di 30 giorni o meno.

  • Un periodo di confronto o una baseline nota in stato di salute, ove possibile.

Strumenti utilizzati

  • ObjectService_getObjectTypes

  • ObjectService_getMetadataForObjectType

  • ObjectService_query

  • ObjectService_queryPerformanceMetricsForObjects

  • ObjectService_groupObjects

  • AlertsService_getMetadata

  • AlertsService_queryForAlerts

  • LogService_getLogTypes

  • LogService_getLogTypeMetadata

  • LogService_queryLogEvents

Richiesta iniziale

Analizza perché il volume example-volume era lento tra le 09:00 e le 11:00 UTC. Individua il tipo di oggetto corretto e le metriche valide, confronta latenza, IOPS e throughput durante la finestra dell'incidente, esamina gli avvisi attivi correlati e i log della piattaforma e confronta con un periodo senza problemi. Distingui le prove dalle ipotesi e identifica la prossima misurazione necessaria.

Flusso di lavoro dell'agente

  1. Risolvi la risorsa associandola a un tipo di oggetto e a un'identità precisi.

  2. Recupera i metadati per quel tipo di oggetto.

  3. Identifica metriche valide di latenza, operazioni, throughput, utilizzo e capacità.

  4. Interroga gli attributi correnti dell'oggetto per stabilire il posizionamento e le relazioni.

  5. Recupera le serie temporali in un periodo di:

    • La finestra dell'incidente

    • Una finestra integra comparabile

  6. Allinea i timestamp e le funzioni di aggregazione tra le metriche.

  7. Recupera gli avvisi relativi alla risorsa, contenenti il sistema, l'host, il nodo o il pool di storage.

  8. Seleziona i flussi di log pertinenti, recupera i metadati e cerca in un intervallo ristretto intorno alle variazioni delle metriche.

  9. Verifica ipotesi plausibili:

    • Picco della domanda

    • Saturazione delle risorse

    • Errori di storage o del fabric

    • Pressione sulla capacità

    • Contesa dell'host o della VM

    • Lacuna nella raccolta

  10. Riporta la spiegazione più supportata e le alternative irrisolte.

Standard di evidenza

Risultati dell'etichettatura:

  • Osservato: restituito direttamente da uno strumento.

  • Correlati: segnali indipendenti cambiati nello stesso intervallo.

  • Dedotto: una spiegazione plausibile non ancora dimostrata.

  • Sconosciuto: le prove richieste non sono disponibili.

La correlazione non implica causalità. Un allarme simultaneo va considerato come elemento a supporto, non come prova definitiva, a meno che il meccanismo non sia stabilito.

Guida alle metriche

  • Usa `AVG`per il comportamento generale, ma controlla `MAX`quando i brevi picchi sono importanti.

  • Usa `SUM`solo per metriche additive.

  • Usa CHANGE o CHANGE_RATIO per i contatori o la crescita dove i metadati lo supportano.

  • Evita di confrontare serie con limiti di intervallo o unità di misura diversi.

  • I filtri si applicano prima dell'aggregazione degli intervalli temporali.

Output suggerito

  1. Ambito e cronologia dell'incidente

  2. Evidenza delle metriche

  3. Avviso e prove del log

  4. Confronto del periodo integro

  5. Spiegazione più probabile

  6. Ipotesi alternative

  7. Affidabilità e prove mancanti

  8. Controllo successivo consigliato

Limiti e privacy

  • Le finestre delle serie temporali non possono superare i 30 giorni.

  • Lo strumento di analisi delle prestazioni restituisce un numero limitato di serie; restringi il filtro prima di aumentare il limite.

  • Ometti i campi di log raw sensibili che non contribuiscono alla diagnosi.

  • Non proporre interventi correttivi invasivi senza averli prima convalidati attraverso i normali controlli operativi.

Suggerimenti di approfondimento

Confronta la latenza massima e media durante l'incidente con la stessa ora del giorno precedente in cui il sistema era in buone condizioni.

Raggruppa i carichi di lavoro correlati per host o pool di storage e identifica se il rallentamento era isolato o condiviso.

Mostra gli eventi della piattaforma entro 15 minuti dal primo aumento della latenza.

"Torna alle ricette"