Linee guida per la risoluzione dei problemi dell'indicizzatore per Ricerca cognitiva di Azure

Occasionalmente, gli indicizzatori si verificano problemi e non si verifica alcun errore per facilitare la diagnosi. Questo articolo illustra i problemi e le possibili risoluzioni quando i risultati dell'indicizzatore sono imprevisti e sono disponibili informazioni limitate. Se si verifica un errore, vedere Risoluzione degli errori e degli avvisi comuni dell'indicizzatore .

Risolvere i problemi relativi alle connessioni alle risorse con restrizioni

Per le origini dati protette dai meccanismi di sicurezza di rete di Azure, gli indicizzatori hanno un set limitato di opzioni per stabilire la connessione. Attualmente, gli indicizzatori possono accedere a origini dati limitate dietro un firewall IP o in una rete virtuale tramite un endpoint privato.

Regole del firewall

Archiviazione di Azure, Azure Cosmos DB e Azure SQL forniscono un firewall configurabile. Non vengono visualizzati messaggi di errore specifici quando il firewall è abilitato. In genere, gli errori del firewall sono generici. Alcuni errori comuni includono:

  • The remote server returned an error: (403) Forbidden
  • This request is not authorized to perform this operation
  • Credentials provided in the connection string are invalid or have expired

Esistono due opzioni per consentire agli indicizzatori di accedere a queste risorse in un'istanza di questo tipo:

  • Disabilitare il firewall consentendo l'accesso da Tutte le reti (se possibile).

  • In alternativa, è possibile consentire l'accesso per l'indirizzo IP del servizio di ricerca e l'intervallo di indirizzi IP del tag di AzureCognitiveSearchservizio nelle regole del firewall della risorsa (restrizione dell'intervallo di indirizzi IP).

Per informazioni dettagliate sulla configurazione delle restrizioni relative all'intervallo di indirizzi IP per ogni tipo di origine dati, vedere i collegamenti seguenti:

Limitazione: come indicato nella documentazione precedente per Archiviazione di Azure, le restrizioni relative all'intervallo di indirizzi IP funzioneranno solo se il servizio di ricerca e l'account di archiviazione si trovano in aree diverse.

Le funzioni di Azure (che possono essere usate come competenza api Web personalizzata) supportano anche le restrizioni relative agli indirizzi IP. L'elenco di indirizzi IP da configurare sarà l'indirizzo IP del servizio di ricerca e l'intervallo di indirizzi IP del tag di AzureCognitiveSearch servizio.

Per altre informazioni sulla connessione a una macchina virtuale, vedere Configurare una connessione a SQL Server in una macchina virtuale di Azure.

Configurare le regole del gruppo di sicurezza di rete

Quando si accede ai dati in un'istanza gestita di SQL o quando una macchina virtuale di Azure viene usata come URI del servizio Web per una competenza api Web personalizzata, i clienti non devono preoccuparsi di indirizzi IP specifici.

In questi casi, la macchina virtuale di Azure o l'istanza gestita di SQL possono essere configurate per risiedere all'interno di una rete virtuale. È quindi possibile configurare un gruppo di sicurezza di rete per filtrare il tipo di traffico di rete che può scorrere tra le subnet della rete virtuale e le interfacce di rete.

Il AzureCognitiveSearch tag del servizio può essere usato direttamente nelle regole del gruppo di sicurezza di rete in ingresso senza dover cercare il relativo intervallo di indirizzi IP.

Altre informazioni sull'accesso ai dati in un'istanza gestita di SQL sono descritte qui.

errori di rete

In genere, gli errori di rete sono generici. Alcuni errori comuni includono:

  • A network-related or instance-specific error occurred while establishing a connection to the server
  • The server was not found or was not accessible
  • Verify that the instance name is correct and that the source is configured to allow remote connections

Quando si riceve uno di questi errori:

  • Assicurarsi che l'origine sia accessibile provando a connettersi direttamente e non tramite il servizio di ricerca
  • Controllare l'origine nel portale di Azure per eventuali errori o interruzioni correnti
  • Verificare eventuali interruzioni di rete in Stato di Azure
  • Verificare di usare DNS pubblico per la risoluzione dei nomi e non un DNS privato di Azure

Azure SQL indicizzazione serverless del database (codice di errore 40613)

Se il database SQL si trova in un livello di calcolo serverless, assicurarsi che il database sia in esecuzione (e non sospeso) quando l'indicizzatore si connette.

Se il database viene sospeso, il primo account di accesso del servizio di ricerca riprenderà automaticamente il database, ma restituirà anche un errore che indica che il database non è disponibile con il codice di errore 40613. Dopo aver eseguito il database, ripetere l'accesso per stabilire la connettività.

Criteri di accesso condizionale di SharePoint

Quando si crea un indicizzatore di SharePoint, si eseguirà un passaggio che richiede l'accesso all'app Azure AD dopo aver fornito un codice del dispositivo. Se viene visualizzato un messaggio che indica "Your sign-in was successful but your admin requires the device requesting access to be managed" che l'indicizzatore è probabilmente bloccato dall'accesso alla raccolta documenti di SharePoint a causa di un criterio di accesso condizionale .

Per aggiornare i criteri per consentire all'indicizzatore di accedere alla raccolta documenti, seguire questa procedura:

  1. Aprire il portale di Azure e cercare l'accesso condizionale di Azure AD, quindi selezionare Criteri nel menu a sinistra. Se non si ha accesso per visualizzare questa pagina, sarà necessario trovare qualcuno che ha accesso o ottenere l'accesso.

  2. Determinare quali criteri bloccano l'accesso all'indicizzatore di SharePoint. I criteri che potrebbero bloccare l'indicizzatore includeranno l'account utente usato per l'autenticazione durante il passaggio di creazione dell'indicizzatore nella sezione Utenti e gruppi . I criteri potrebbero anche avere condizioni che:

    • Limitare le piattaforme Windows .
    • Limitare le app per dispositivi mobili e i client desktop.
    • Fare in modo che lo stato del dispositivo sia configurato su .
  3. Dopo aver confermato che è presente un criterio che blocca l'indicizzatore, è quindi necessario effettuare un'esenzione per l'indicizzatore. Recuperare l'indirizzo IP del servizio di ricerca.

    1. Ottenere il nome di dominio completo (FQDN) del servizio di ricerca. L'aspetto sarà simile a <search-service-name>.search.windows.net. È possibile trovare il nome di dominio completo cercando il servizio di ricerca nel portale di Azure.

    Ottenere il nome FQDN del servizio Ottenere

    L'indirizzo IP del servizio di ricerca può essere ottenuto eseguendo un nslookup (o un ping) dell'FQDN. Nell'esempio seguente si aggiungerà "150.0.0.1" a una regola in ingresso nel firewall di Archiviazione di Azure. L'aggiornamento delle impostazioni del firewall potrebbe richiedere fino a 15 minuti prima che l'indicizzatore del servizio di ricerca possa accedere all'account di archiviazione di Azure.

    
    nslookup contoso.search.windows.net
    Server:  server.example.org
    Address:  10.50.10.50
    
    Non-authoritative answer:
    Name:    <name>
    Address:  150.0.0.1
    Aliases:  contoso.search.windows.net
    
  4. Ottenere gli intervalli di indirizzi IP per l'ambiente di esecuzione dell'indicizzatore per l'area.

    Gli indirizzi IP aggiuntivi vengono usati per le richieste provenienti dall'ambiente di esecuzione multi-tenant dell'indicizzatore. È possibile ottenere questo intervallo di indirizzi IP dal tag del servizio.

    Gli intervalli di indirizzi IP per il tag di AzureCognitiveSearch servizio possono essere ottenuti tramite l'API di individuazione o il file JSON scaricabile.

    Per questa procedura dettagliata, presupponendo che il servizio di ricerca sia il cloud pubblico di Azure, il file JSON pubblico di Azure deve essere scaricato.

    Scaricare il file JSON Scaricare il

    Dal file JSON, supponendo che il servizio di ricerca si trovi negli Stati Uniti centro-occidentali, l'elenco di indirizzi IP per l'ambiente di esecuzione dell'indicizzatore multi-tenant è elencato di seguito.

        {
          "name": "AzureCognitiveSearch.WestCentralUS",
          "id": "AzureCognitiveSearch.WestCentralUS",
          "properties": {
            "changeNumber": 1,
            "region": "westcentralus",
            "platform": "Azure",
            "systemService": "AzureCognitiveSearch",
            "addressPrefixes": [
              "52.150.139.0/26",
              "52.253.133.74/32"
            ]
          }
        }
    
  5. Nella pagina Accesso condizionale in portale di Azure selezionare Località denominate dal menu a sinistra e quindi selezionare + Percorso intervalli IP. Assegnare un nome alla nuova posizione denominata e aggiungere gli intervalli IP per gli ambienti di esecuzione del servizio di ricerca e dell'indicizzatore raccolti negli ultimi due passaggi.

    • Per l'indirizzo IP del servizio di ricerca potrebbe essere necessario aggiungere "/32" alla fine dell'indirizzo IP perché accetta solo intervalli IP validi.
    • Tenere presente che per gli intervalli IP dell'ambiente di esecuzione dell'indicizzatore è sufficiente aggiungere gli intervalli IP per l'area in cui si trova il servizio di ricerca.
  6. Escludere il nuovo percorso denominato dai criteri.

    1. Selezionare Criteri nel menu a sinistra.
    2. Selezionare i criteri che bloccano l'indicizzatore.
    3. Selezionare Condizioni.
    4. Selezionare Località.
    5. Selezionare Escludi e quindi aggiungere il nuovo percorso denominato.
    6. Fare clic su Salva per salvare le modifiche.
  7. Attendere alcuni minuti prima che il criterio aggiorni e applichi le nuove regole dei criteri.

  8. Provare a creare di nuovo l'indicizzatore

    1. Inviare una richiesta di aggiornamento per l'oggetto origine dati creato.
    2. Inviare nuovamente la richiesta di creazione dell'indicizzatore. Usare il nuovo codice per accedere, quindi inviare un'altra richiesta di creazione dell'indicizzatore.

Indicizzazione di tipi di documenti non supportati

Se si indicizza il contenuto da Archiviazione BLOB di Azure e il contenitore include BLOB di un tipo di contenuto non supportato, l'indicizzatore ignorerà il documento. In altri casi, possono verificarsi problemi con singoli documenti.

È possibile impostare le opzioni di configurazione per consentire all'elaborazione dell'indicizzatore di continuare in caso di problemi con singoli documenti.

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2020-06-30
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "failOnUnsupportedContentType" : false, "failOnUnprocessableDocument" : false } }
}

Documenti mancanti

Gli indicizzatori estraggono documenti o righe da un'origine dati esterna e creano documenti di ricerca che vengono quindi indicizzati dal servizio di ricerca. In alcuni casi, un documento presente nell'origine dati non viene visualizzato in un indice di ricerca. Questo risultato imprevisto può verificarsi a causa dei motivi seguenti:

  • Il documento è stato aggiornato dopo l'esecuzione dell'indicizzatore. Se l'indicizzatore fa parte di una pianificazione, a un certo punto verrà eseguito nuovamente e selezionerà il documento.
  • Timeout dell'indicizzatore prima dell'inserimento del documento. Sono previsti limiti massimi di tempo di elaborazione dopo i quali non verranno elaborati documenti. È possibile controllare lo stato dell'indicizzatore nel portale o chiamando Get Indexer Status (API REST).You can check indexer status in the portal or by calling Get Indexer Status (REST API).
  • I mapping dei campi o l'arricchimento dell'intelligenza artificiale hanno modificato il documento e la relativa articolazione nell'indice di ricerca è diversa da quella prevista.
  • I valori di rilevamento delle modifiche sono errati o prerequisiti mancanti. Se il valore della filigrana elevato è una data impostata su un'ora futura, tutti i documenti con una data minore di questo verrà ignorato dall'indicizzatore. È possibile comprendere lo stato di rilevamento delle modifiche dell'indicizzatore usando i campi "initialTrackingState" e "finalTrackingState" nello stato dell'indicizzatore. Gli indicizzatori per Azure SQL e MySQL devono avere un indice nella colonna del contrassegno di acqua elevata della tabella di origine o le query usate dall'indicizzatore possono richiedere il timeout.

Suggerimento

Se i documenti sono mancanti, controllare la query usata per assicurarsi che non sia escluso il documento in questione. Per eseguire una query per un documento specifico, usare l'API REST del documento di ricerca.

Contenuto mancante dall'archiviazione BLOB

L'indicizzatore BLOB trova ed estrae il testo dai BLOB in un contenitore. I problemi relativi all'estrazione del testo includono i seguenti:

  • Il documento contiene solo immagini digitalizzate. I BLOB PDF con contenuti non testuali, ad esempio immagini digitalizzate (JPG), non producono risultati in una pipeline di indicizzazione BLOB standard. Se si dispone di contenuto dell'immagine con elementi di testo, è possibile usare l'analisi OCR o immagine per trovare ed estrarre il testo.

  • L'indicizzatore BLOB è configurato solo per i metadati dell'indice. Per estrarre il contenuto, l'indicizzatore BLOB deve essere configurato per estrarre sia il contenuto che i metadati:

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2020-06-30
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "dataToExtract" : "contentAndMetadata" } }
}

Contenuto mancante da Azure Cosmos DB

Ricerca cognitiva di Azure ha una dipendenza implicita dall'indicizzazione di Azure Cosmos DB. Se si disattiva l'indicizzazione automatica in Azure Cosmos DB, Ricerca cognitiva di Azure restituisce uno stato corretto, ma non riesce a indicizzare il contenuto del contenitore. Per istruzioni su come controllare le impostazioni e attivare l'indicizzazione, vedere Gestire l'indicizzazione in Azure Cosmos DB.

Indicizzatore riflette un numero di documenti diverso rispetto all'origine dati o all'indice

L'indicizzatore può visualizzare un numero di documenti diverso rispetto all'origine dati, all'indice o al conteggio nel codice in un momento, a seconda di circostanze specifiche. Ecco alcune possibili cause del motivo per cui può verificarsi:

  • L'indicizzatore dispone di criteri di documento eliminati. I documenti eliminati vengono conteggiati alla fine dell'indicizzatore se vengono indicizzati prima dell'eliminazione.
  • Se la colonna ID nell'origine dati non è univoca. Si tratta di origini dati con il concetto di colonne, ad esempio Azure Cosmos DB.
  • Se la definizione dell'origine dati ha una query diversa da quella usata per stimare il numero di record. Ad esempio, nella data base si esegue una query su tutti i record di data base, mentre nella query di definizione dell'origine dati è possibile selezionare solo un subset di record da indicizzare.
  • I conteggi vengono controllati in intervalli diversi per ogni componente della pipeline: origine dati, indicizzatore e indice.
  • L'indice può richiedere alcuni minuti per visualizzare il conteggio dei documenti reali.
  • L'origine dati include un file mappato a molti documenti. Questa condizione può verificarsi durante l'indicizzazione di BLOB e "parsingMode" è impostata su jsonArray e jsonLines.
  • A causa di documenti elaborati più volte.

Documenti elaborati più volte

Gli indicizzatori sfruttano una strategia di buffer conservativa per garantire che ogni nuovo documento e modificato nell'origine dati venga raccolto durante l'indicizzazione. In alcune situazioni, questi buffer possono sovrapporsi, causando un indicizzatore per indicizzare un documento due o più volte, causando il conteggio dei documenti elaborati più che il numero effettivo di documenti nell'origine dati. Questo comportamento non influisce sui dati archiviati nell'indice, ad esempio la duplicazione di documenti, solo che potrebbe richiedere più tempo per raggiungere la coerenza finale. Questo può essere particolarmente diffuso se una delle seguenti condizioni è vera:

  • Le richieste di indicizzatore su richiesta vengono rilasciate in successione rapida
  • La topologia dell'origine dati include più repliche e partizioni (un esempio è illustrato qui)

Gli indicizzatori non devono essere richiamati più volte in successione rapida. Se sono necessari aggiornamenti rapidamente, l'approccio supportato consiste nel eseguire il push degli aggiornamenti all'indice durante l'aggiornamento simultaneo dell'origine dati. Per l'elaborazione su richiesta, è consigliabile impostare le richieste in intervalli di cinque minuti o più ed eseguire l'indicizzatore in una pianificazione.

Esempio di elaborazione di documenti duplicati con 30 secondi buffer

Le condizioni in cui un documento viene elaborato due volte sono descritte di seguito in una sequenza temporale che annota ogni azione e azione contatore. La sequenza temporale seguente illustra il problema:

Sequenza temporale (hh:mm:ss) Evento Contrassegno dell'acqua alta dell'indicizzatore Commento
00:01:00 Scrivere doc1 nell'origine dati con coerenza finale null Timestamp del documento è 00:01:00.
00:01:05 Scrivere doc2 nell'origine dati con coerenza finale null Timestamp documento è 00:01:05.
00:01:10 L'indicizzatore avvia null
00:01:11 Query dell'indicizzatore per tutte le modifiche prima delle 00:01:10; la replica che le query dell'indicizzatore devono essere consapevoli solo di doc2; viene recuperata solo doc2 null Indicizzatore richiede tutte le modifiche prima dell'avvio del timestamp, ma riceve effettivamente un subset. Questo comportamento richiede il periodo di buffer di ricerca.
00:01:12 Processi doc2 indicizzatore per la prima volta null
00:01:13 Fine dell'indicizzatore 00:01:10 Il contrassegno di acqua elevato viene aggiornato per avviare il timestamp dell'esecuzione corrente dell'indicizzatore.
00:01:20 L'indicizzatore avvia 00:01:10
00:01:21 Query indicizzatore per tutte le modifiche tra 00:00:40 e 00:01:20; la replica che le query dell'indicizzatore devono essere a conoscenza di entrambi doc1 e doc2; recupera doc1 e doc2 00:01:10 Le richieste dell'indicizzatore per tutte le modifiche tra il segno di acqua elevata corrente meno il buffer di 30 secondi e il timestamp iniziale dell'esecuzione corrente dell'indicizzatore.
00:01:22 Processi doc1 indicizzatore per la prima volta 00:01:10
00:01:23 Processi doc2 indicizzatore per la seconda volta 00:01:10
00:01:24 Fine dell'indicizzatore 00:01:20 Il contrassegno di acqua elevato viene aggiornato per avviare il timestamp dell'esecuzione corrente dell'indicizzatore.
00:01:32 L'indicizzatore avvia 00:01:20
00:01:33 Query indicizzatore per tutte le modifiche tra 00:00:50 e 00:01:32; doc1 recupera e doc2 00:01:20 Le richieste dell'indicizzatore per tutte le modifiche tra il segno di acqua elevata corrente meno il buffer di 30 secondi e il timestamp iniziale dell'esecuzione corrente dell'indicizzatore.
00:01:34 Processi doc1 indicizzatore per la seconda volta 00:01:20
00:01:35 Processi doc2 indicizzatore per la terza volta 00:01:20
00:01:36 Termina l'indicizzatore 00:01:32 Il contrassegno di acqua elevato viene aggiornato all'avvio del timestamp dell'esecuzione dell'indicizzatore corrente.
00:01:40 Avvio dell'indicizzatore 00:01:32
00:01:41 Query indicizzatore per tutte le modifiche tra 00:01:02 e 00:01:40; Recupera doc2 00:01:32 Le richieste dell'indicizzatore per tutte le modifiche tra il contrassegno di acqua elevata corrente meno il buffer di 30 secondi e il timestamp iniziale dell'esecuzione corrente dell'indicizzatore.
00:01:42 Processi doc2 dell'indicizzatore per la quarta volta 00:01:32
00:01:43 Termina l'indicizzatore 00:01:40 Si noti che l'esecuzione dell'indicizzatore è iniziata più di 30 secondi dopo l'ultima scrittura nell'origine dati ed è stata doc2elaborata anche . Questo è il comportamento previsto perché se tutte le esecuzioni dell'indicizzatore prima delle 00:01:35 vengono eliminate, questo diventerà il primo e solo l'esecuzione da elaborare doc1 e doc2.

In pratica, questo scenario si verifica solo quando gli indicizzatori su richiesta vengono richiamati manualmente tra loro in pochi minuti, per determinate origini dati. Può causare numeri non corrispondenti (ad esempio l'indicizzatore ha elaborato 345 documenti totali in base alle statistiche di esecuzione dell'indicizzatore, ma ci sono 340 documenti nell'origine dati e nell'indice) o potenzialmente aumentato la fatturazione se si eseguono le stesse competenze per lo stesso documento più volte. L'esecuzione di un indicizzatore tramite una pianificazione è la raccomandazione preferita.

Indicizzazione di documenti con etichette di riservatezza

Se nei documenti sono impostate etichette di riservatezza, potrebbe non essere possibile indicizzare i documenti. Se si verificano errori, rimuovere le etichette prima dell'indicizzazione.

Vedi anche