Richtlijnen voor het oplossen van problemen met indexeerfuncties voor Azure AI Search

Artikel
01/13/2024

Af en toe ondervinden indexeerfuncties problemen die geen fouten veroorzaken of die optreden in andere Azure-services, zoals tijdens verificatie of bij het maken van verbinding. Dit artikel is gericht op het oplossen van problemen met indexeerfuncties wanneer er geen berichten zijn om u te helpen. Het biedt ook probleemoplossing voor fouten die afkomstig zijn van niet-zoekbronnen die tijdens het indexeren worden gebruikt.

Notitie

Als u een Azure AI Search-fout hebt om te onderzoeken, raadpleegt u In plaats daarvan veelvoorkomende indexeerfouten en waarschuwingen oplossen.

Problemen met verbindingen met beperkte resources oplossen

Voor gegevensbronnen onder Azure-netwerkbeveiliging zijn indexeerfuncties beperkt in de wijze waarop ze de verbinding maken. Op dit moment hebben indexeerfuncties toegang tot beperkte gegevensbronnen achter een IP-firewall of via een virtueel netwerk via een privé-eindpunt met behulp van een gedeelde privékoppeling.

Firewallregels

Azure Storage, Azure Cosmos DB en Azure SQL bieden een configureerbare firewall. Er is geen specifiek foutbericht wanneer de firewall de aanvraag blokkeert. Firewallfouten zijn doorgaans algemeen. Enkele veelvoorkomende fouten zijn:

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

Er zijn twee opties waarmee indexeerfuncties toegang kunnen krijgen tot deze resources in een dergelijk exemplaar:

Configureer een binnenkomende regel voor het IP-adres van uw zoekservice en het IP-adresbereik van AzureCognitiveSearchde servicetag. Meer informatie over het configureren van beperkingen voor IP-adresbereiken voor elk gegevensbrontype vindt u via de volgende koppelingen:
Als laatste redmiddel of als tijdelijke maatregel schakelt u de firewall uit door toegang vanuit alle netwerken toe te staan.

Beperking: beperkingen voor IP-adresbereiken werken alleen als uw zoekservice en uw opslagaccount zich in verschillende regio's bevinden.

Naast het ophalen van gegevens verzenden indexeerfuncties ook uitgaande aanvragen via vaardighedensets en aangepaste vaardigheden. Voor aangepaste vaardigheden op basis van een Azure-functie moet u er rekening mee houden dat Azure-functies ook IP-adresbeperkingen hebben. De lijst met IP-adressen waarmee aangepaste vaardigheden kunnen worden uitgevoerd, omvatten het IP-adres van uw zoekservice en het IP-adresbereik van AzureCognitiveSearch de servicetag.

NSG-regels (netwerkbeveiligingsgroep)

Wanneer een indexeerfunctie toegang heeft tot gegevens in een met SQL beheerd exemplaar of wanneer een Azure-VM wordt gebruikt als de webservice-URI voor een aangepaste vaardigheid, bepaalt de netwerkbeveiligingsgroep of aanvragen zijn toegestaan in.

Voor externe resources die zich in een virtueel netwerk bevinden, configureert u binnenkomende NSG-regels voor de AzureCognitiveSearch servicetag.

Zie Een verbinding met SQL Server configureren op een Azure-VM voor meer informatie over het maken van verbinding met een virtuele machine.

Netwerkfouten

Meestal zijn netwerkfouten algemeen. Enkele veelvoorkomende fouten zijn:

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

Wanneer u een van deze fouten ontvangt:

Zorg ervoor dat uw bron toegankelijk is door er rechtstreeks verbinding mee te maken en niet via de zoekservice
Controleer uw resource in Azure Portal op eventuele huidige fouten of storingen
Controleren op netwerkstoringen in Azure-status
Controleer of u een openbare DNS gebruikt voor naamomzetting en niet een Azure-Privé-DNS

Serverloze indexering van Azure SQL Database (foutcode 40613)

Als uw SQL-database zich op een serverloze rekenlaag bevindt, moet u ervoor zorgen dat de database wordt uitgevoerd (en niet onderbroken) wanneer de indexeerfunctie hiermee verbinding maakt.

Als de database is onderbroken, wordt verwacht dat de eerste aanmelding van uw zoekservice de database automatisch hervat, maar retourneert in plaats daarvan een fout waarin wordt aangegeven dat de database niet beschikbaar is, waarbij foutcode 40613 wordt gegeven. Nadat de database is uitgevoerd, probeert u zich opnieuw aan te melden om verbinding te maken.

Beleid voor voorwaardelijke toegang van Microsoft Entra

Wanneer u een SharePoint Online-indexeerfunctie maakt, moet u zich aanmelden bij uw Microsoft Entra-app nadat u een apparaatcode hebt opgegeven. Als u een bericht ontvangt met de mededeling "Your sign-in was successful but your admin requires the device requesting access to be managed", wordt de indexeerfunctie waarschijnlijk geblokkeerd voor de SharePoint-documentbibliotheek door een beleid voor voorwaardelijke toegang .

Het beleid bijwerken en indexeerfunctietoegang tot de documentbibliotheek toestaan:

Open Azure Portal en zoek naar voorwaardelijke toegang van Microsoft Entra.
Selecteer Beleid in het linkermenu. Als u geen toegang hebt om deze pagina weer te geven, moet u iemand zoeken die toegang heeft of toegang heeft.
Bepaal welk beleid de SharePoint Online-indexeerfunctie blokkeert voor toegang tot de documentbibliotheek. Het beleid dat de indexeerfunctie blokkeert, bevat het gebruikersaccount dat u hebt gebruikt om te verifiëren tijdens de stap voor het maken van de indexeerfunctie in de sectie Gebruikers en groepen . Het beleid kan ook voorwaarden hebben die:
- Beperk Windows-platforms .
- Mobiele apps en desktopclients beperken.
- De apparaatstatus is geconfigureerd op Ja.
Zodra u hebt bevestigd welk beleid de indexeerfunctie blokkeert, maakt u een uitzondering voor de indexeerfunctie. Begin met het ophalen van het IP-adres van de zoekservice.

Haal eerst de FQDN (Fully Qualified Domain Name) van uw zoekservice op. De FQDN ziet er als volgt uit <your-search-service-name>.search.windows.net. U vindt de FQDN in Azure Portal.

Nu u de FQDN hebt, haalt u het IP-adres van de zoekservice op door een nslookup (of een ping) van de FQDN uit te voeren. In het volgende voorbeeld voegt u '150.0.0.1' toe aan een regel voor inkomend verkeer in de Azure Storage-firewall. Het kan tot 15 minuten duren voordat de firewallinstellingen zijn bijgewerkt voordat de indexeerfunctie van de zoekservice toegang heeft tot het Azure Storage-account.
```
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
```
Haal de IP-adresbereiken op voor de uitvoeringsomgeving van de indexeerfunctie voor uw regio.

Extra IP-adressen worden gebruikt voor aanvragen die afkomstig zijn van de multitenant-uitvoeringsomgeving van de indexeerfunctie. U kunt dit IP-adresbereik ophalen uit de servicetag.

De IP-adresbereiken voor de AzureCognitiveSearch servicetag kunnen worden verkregen via de detectie-API of het downloadbare JSON-bestand.

Voor deze oefening, ervan uitgaande dat de zoekservice de openbare Azure-cloud is, moet het openbare JSON-bestand van Azure worden gedownload.

Vanuit het JSON-bestand, ervan uitgaande dat de zoekservice zich in VS - west-centraal bevindt, wordt de lijst met IP-adressen voor de uitvoeringsomgeving voor de multitenant-indexeerfunctie hieronder vermeld.
```
    {
      "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"
        ]
      }
    }
```
Selecteer op de pagina Voorwaardelijke toegang in Azure Portal benoemde locaties in het menu aan de linkerkant en selecteer vervolgens de locatie + IP-adresbereiken. Geef uw nieuwe benoemde locatie een naam en voeg de IP-bereiken toe voor uw zoekservice- en indexeeromgevingen die u in de laatste twee stappen hebt verzameld. 1
- Voor het IP-adres van uw zoekservice moet u mogelijk '/32' toevoegen aan het einde van het IP-adres, omdat deze alleen geldige IP-bereiken accepteert.
- Houd er rekening mee dat u voor de IP-adresbereiken van de indexeerfunctie alleen de IP-bereiken hoeft toe te voegen voor de regio waarin uw zoekservice zich bevindt.
Sluit de nieuwe benoemde locatie uit van het beleid:
1. Selecteer Beleid in het linkermenu.
2. Selecteer het beleid dat de indexeerfunctie blokkeert.
3. Selecteer Voorwaarden.
4. Selecteer Locaties.
5. Selecteer Uitsluiten en voeg vervolgens de nieuwe benoemde locatie toe.
6. Sla de wijzigingen op .
Wacht enkele minuten totdat het beleid is bijgewerkt en de nieuwe beleidsregels afdwingen.
Probeer de indexeerfunctie opnieuw te maken:
1. Verzend een updateaanvraag voor het gegevensbronobject dat u hebt gemaakt.
2. De aanvraag voor het maken van de indexeerfunctie opnieuw verzenden. Gebruik de nieuwe code om u aan te melden en vervolgens een andere aanvraag voor het maken van een indexeerfunctie te verzenden.

Niet-ondersteunde documenttypen indexeren

Als u inhoud van Azure Blob Storage indexeert en de container blobs van een niet-ondersteund inhoudstype bevat, slaat de indexeerfunctie dat document over. In andere gevallen kunnen er problemen zijn met afzonderlijke documenten.

In dit geval kunt u configuratieopties instellen zodat de verwerking van indexeerfuncties kan worden voortgezet in het geval van problemen met afzonderlijke documenten.

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

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

Ontbrekende documenten

Indexeerfuncties extraheren documenten of rijen uit een externe gegevensbron en maken zoekdocumenten, die vervolgens worden geïndexeerd door de zoekservice. Af en toe kan een document in een gegevensbron niet worden weergegeven in een zoekindex. Dit onverwachte resultaat kan worden veroorzaakt door de volgende redenen:

Het document is bijgewerkt nadat de indexeerfunctie is uitgevoerd. Als uw indexeerfunctie volgens een schema staat, wordt het document uiteindelijk opnieuw uitgevoerd en opgehaald.
Er is een time-out opgetreden voordat het document kan worden opgenomen. Er zijn maximale verwerkingstijdlimieten waarna er geen documenten worden verwerkt. U kunt de status van de indexeerfunctie controleren in de portal of door de Status van de indexeerfunctie (REST API) aan te roepen.
Veldtoewijzingen of AI-verrijking hebben het document gewijzigd en de bijbehorende articulatie in de zoekindex verschilt van wat u verwacht.
Waarden voor het bijhouden van wijzigingen zijn onjuist of vereisten ontbreken. Als uw hoge grenswaarde een datum is die is ingesteld op een toekomstige tijd, worden documenten met een eerdere datum overgeslagen door de indexeerfunctie. U kunt de status van het bijhouden van wijzigingen van uw indexeerfunctie bepalen met behulp van de velden initialTrackingState en finalTrackingState in de status van de indexeerfunctie. Indexeerfuncties voor Azure SQL en MySQL moeten een index hebben op de kolom met hoge watermarkeringen van de brontabel, of query's die door de indexeerfunctie worden gebruikt, kunnen een time-out hebben.

Tip

Als documenten ontbreken, controleert u de query die u gebruikt om ervoor te zorgen dat het betreffende document niet wordt uitgesloten. Als u een query wilt uitvoeren op een specifiek document, gebruikt u de REST API voor opzoekdocument.

Ontbrekende inhoud in Blob Storage

De blob-indexeerfunctie zoekt en extraheert tekst uit blobs in een container. Enkele problemen met het extraheren van tekst zijn:

Het document bevat alleen gescande afbeeldingen. PDF-blobs met niet-tekstinhoud, zoals gescande afbeeldingen (JPG's), produceren geen resultaten in een standaard-blobindexeringspijplijn. Als u afbeeldingsinhoud met tekstelementen hebt, kunt u OCR of afbeeldingsanalyse gebruiken om de tekst te zoeken en te extraheren.
De blob-indexeerfunctie is geconfigureerd voor alleen indexmetagegevens. Als u inhoud wilt extraheren, moet de blob-indexeerfunctie worden geconfigureerd om zowel inhoud als metagegevens te extraheren:

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

Ontbrekende inhoud in Azure Cosmos DB

Azure AI Search heeft een impliciete afhankelijkheid van azure Cosmos DB-indexering. Als u automatische indexering in Azure Cosmos DB uitschakelt, retourneert Azure AI Search een geslaagde status, maar kan de inhoud van de container niet indexeren. Zie Indexering beheren in Azure Cosmos DB voor instructies over het controleren van instellingen en het inschakelen van indexering.

Afwijking van het aantal documenten tussen de gegevensbron en de index

Een indexeerfunctie kan een ander aantal documenten weergeven dan de gegevensbron, de index zelf of het aantal in uw code. Hier volgen enkele mogelijke redenen waarom dit gedrag kan optreden:

De index kan vertraging oplopen bij het weergeven van het werkelijke aantal documenten, met name in de portal.
De indexeerfunctie heeft een verwijderd documentbeleid. De verwijderde documenten worden geteld door de indexeerfunctie als de documenten worden geïndexeerd voordat ze worden verwijderd.
Als de id-kolom in de gegevensbron niet uniek is. Dit geldt voor gegevensbronnen met het concept van kolommen, zoals Azure Cosmos DB.
Als de definitie van de gegevensbron een andere query heeft dan de definitie die u gebruikt om het aantal records te schatten. In uw database voert u bijvoorbeeld een query uit op het aantal databaserecords, terwijl u in de definitiequery voor de gegevensbron slechts een subset records selecteert die u wilt indexeren.
De aantallen worden gecontroleerd met verschillende intervallen voor elk onderdeel van de pijplijn: gegevensbron, indexeerfunctie en index.
De gegevensbron heeft een bestand dat is toegewezen aan veel documenten. Deze voorwaarde kan optreden wanneer het indexeren van blobs en 'parsingMode' is ingesteld jsonArray op en jsonLines.

Documenten die meerdere keren worden verwerkt

Indexeerfuncties gebruiken een conservatieve bufferstrategie om ervoor te zorgen dat elk nieuw en gewijzigd document in de gegevensbron wordt opgehaald tijdens het indexeren. In bepaalde situaties kunnen deze buffers elkaar overlappen, waardoor een indexeerfunctie een document twee of meer keren indexeert, waardoor het aantal verwerkte documenten groter is dan het werkelijke aantal documenten in de gegevensbron. Dit gedrag heeft geen invloed op de gegevens die zijn opgeslagen in de index, zoals het dupliceren van documenten, alleen dat het langer kan duren om uiteindelijke consistentie te bereiken. Deze voorwaarde komt vooral voor als aan een van de volgende criteria wordt voldaan:

Aanvragen voor indexeerfunctie op aanvraag worden snel achter elkaar uitgegeven
De topologie van de gegevensbron bevat meerdere replica's en partities (een dergelijk voorbeeld wordt hier besproken)
De gegevensbron is een Azure SQL-database en de kolom die is gekozen als 'hoog watermarkering' is van het type datetime2

Indexeerfuncties zijn niet bedoeld om meerdere keren achter elkaar aan te roepen. Als u snel updates nodig hebt, is de ondersteunde methode het pushen van updates naar de index terwijl de gegevensbron tegelijkertijd wordt bijgewerkt. Voor verwerking op aanvraag raden we u aan om uw aanvragen in intervallen van vijf minuten of meer te tempo aan te passen en de indexeerfunctie volgens een schema uit te voeren.

Voorbeeld van dubbele documentverwerking met buffer van 30 seconden

Voorwaarden waaronder een document tweemaal wordt verwerkt, wordt uitgelegd in de volgende tijdlijn waarin elke actie en telleractie worden weergegeven. De volgende tijdlijn illustreert het probleem:

Tijdlijn (uu:mm:ss)	Gebeurtenis	Indexeerfunctie hoog watermarkering	Opmerking
00:01:00	Schrijven `doc1` naar gegevensbron met uiteindelijke consistentie	`null`	De tijdstempel van het document is 00:01:00.
00:01:05	Schrijven `doc2` naar gegevensbron met uiteindelijke consistentie	`null`	De tijdstempel van het document is 00:01:05.
00:01:10	Indexeerfunctie wordt gestart	`null`
00:01:11	Indexeerfunctiequery's voor alle wijzigingen vóór 00:01:10; de replica waarvan de indexeerfunctie alleen op de hoogte `doc2`is; alleen `doc2` wordt opgehaald	`null`	Indexeerfunctie vraagt alle wijzigingen aan voordat de tijdstempel wordt gestart, maar ontvangt daadwerkelijk een subset. Dit gedrag vereist de terugblikperiode.
00:01:12	Indexeerfunctie verwerkt `doc2` voor de eerste keer	`null`
00:01:13	Indexeerfunctie eindigt	00:01:10	Hoog waterteken wordt bijgewerkt naar het begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:20	Indexeerfunctie wordt gestart	00:01:10
00:01:21	Indexeerquery's voor alle wijzigingen tussen 00:00:40 en 00:01:20; de replica die de indexeerfunctie opvraagt, moet rekening houden met zowel `doc1` als `doc2`; haalt en op `doc1doc2`	00:01:10	Indexeerfunctieaanvragen voor alle wijzigingen tussen de huidige hoge watermarkering min de buffer van 30 seconden en de begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:22	Indexeerfunctie verwerkt `doc1` voor de eerste keer	00:01:10
00:01:23	Indexeerfunctie verwerkt `doc2` voor de tweede keer	00:01:10
00:01:24	Indexeerfunctie eindigt	00:01:20	Hoog waterteken wordt bijgewerkt naar het begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:32	Indexeerfunctie wordt gestart	00:01:20
00:01:33	Indexeerfunctiequery's voor alle wijzigingen tussen 00:00:50 en 00:01:32; `doc1` haalt en `doc2`	00:01:20	Indexeerfunctieaanvragen voor alle wijzigingen tussen de huidige hoge watermarkering min de buffer van 30 seconden en de begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:34	Indexeerfunctie verwerkt `doc1` voor de tweede keer	00:01:20
00:01:35	Indexeerfunctie verwerkt `doc2` voor de derde keer	00:01:20
00:01:36	Indexeerfunctie eindigt	00:01:32	Hoog waterteken wordt bijgewerkt naar het begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:40	Indexeerfunctie wordt gestart	00:01:32
00:01:41	Indexeerfunctiequery's voor alle wijzigingen tussen 00:01:02 en 00:01:40; Opgehaald `doc2`	00:01:32	Indexeerfunctieaanvragen voor alle wijzigingen tussen de huidige hoge watermarkering min de buffer van 30 seconden en de begintijdstempel van de huidige indexeerfunctieuitvoering.
00:01:42	Indexeerfunctieprocessen `doc2` voor de vierde keer	00:01:32
00:01:43	Indexeerfunctie eindigt	00:01:40	U ziet dat de uitvoering van deze indexeerfunctie meer dan 30 seconden na de laatste schrijfbewerking naar de gegevensbron is gestart en ook is verwerkt `doc2`. Dit is het verwachte gedrag omdat als alle indexeerfuncties vóór 00:01:35 worden geëlimineerd, dit de eerste en enige uitvoering wordt om te verwerken `doc1` en `doc2`.

In de praktijk gebeurt dit scenario alleen wanneer indexeerfuncties op aanvraag handmatig worden aangeroepen binnen enkele minuten van elkaar, voor bepaalde gegevensbronnen. Dit kan resulteren in niet-overeenkomende getallen (zoals de indexeerfunctie verwerkt 345 documenten in totaal volgens de uitvoeringsstatistieken van de indexeerfunctie, maar er zijn 340 documenten in de gegevensbron en index) of mogelijk verhoogde facturering als u meerdere keren dezelfde vaardigheden voor hetzelfde document uitvoert. Het uitvoeren van een indexeerfunctie volgens een schema is de aanbevolen aanbeveling.

Documenten indexeren met vertrouwelijkheidslabels

Als er gevoeligheidslabels zijn ingesteld voor documenten, kunt u deze mogelijk niet indexeren. Als u fouten krijgt, verwijdert u de labels voordat u indexeert.