Felsökningsvägledning för Indexer för Azure AI Search

Artikel
01/13/2024

Ibland stöter indexerare på problem som inte ger upphov till fel eller som inträffar på andra Azure-tjänster, till exempel under autentisering eller vid anslutning. Den här artikeln fokuserar på felsökning av indexeringsproblem när det inte finns några meddelanden som hjälper dig. Det ger också felsökning för fel som kommer från icke-sökresurser som används under indexering.

Kommentar

Om du har ett Azure AI Search-fel att undersöka kan du läsa Felsöka vanliga indexeringsfel och varningar i stället.

Felsöka anslutningar till begränsade resurser

För datakällor under Azure-nätverkssäkerhet är indexerare begränsade i hur de ansluter. För närvarande kan indexerare komma åt begränsade datakällor bakom en IP-brandvägg eller i ett virtuellt nätverk via en privat slutpunkt med hjälp av en delad privat länk.

Brandväggsregler

Azure Storage, Azure Cosmos DB och Azure SQL tillhandahåller en konfigurerbar brandvägg. Det finns inget specifikt felmeddelande när brandväggen blockerar begäran. Vanligtvis är brandväggsfel allmänna. Några vanliga fel är:

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

Det finns två alternativ för att tillåta indexerare att komma åt dessa resurser i en sådan instans:

Konfigurera en inkommande regel för IP-adressen för söktjänsten och IP-adressintervallet AzureCognitiveSearchför tjänsttaggen. Information om hur du konfigurerar BEGRÄNSNINGAR för IP-adressintervall för varje typ av datakälla finns på följande länkar:
Som en sista utväg eller som ett tillfälligt mått inaktiverar du brandväggen genom att tillåta åtkomst från Alla nätverk.

Begränsning: Begränsningar för IP-adressintervall fungerar bara om din söktjänst och ditt lagringskonto finns i olika regioner.

Utöver datahämtning skickar indexerare även utgående begäranden via kompetensuppsättningar och anpassade kunskaper. För anpassade kunskaper baserat på en Azure-funktion bör du vara medveten om att Azure-funktioner också har IP-adressbegränsningar. Listan över IP-adresser som ska tillåtas för anpassad kompetenskörning inkluderar IP-adressen för din söktjänst och IP-adressintervallet AzureCognitiveSearch för tjänsttaggen.

Regler för nätverkssäkerhetsgrupper (NSG)

När en indexerare kommer åt data på en SQL-hanterad instans, eller när en virtuell Azure-dator används som webbtjänst-URI för en anpassad färdighet, avgör nätverkssäkerhetsgruppen om begäranden tillåts i.

För externa resurser som finns i ett virtuellt nätverk konfigurerar du inkommande NSG-regler för AzureCognitiveSearch tjänsttaggen.

Mer information om hur du ansluter till en virtuell dator finns i Konfigurera en anslutning till SQL Server på en virtuell Azure-dator.

Nätverksfel

Vanligtvis är nätverksfel allmänna. Några vanliga fel är:

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

När du får något av dessa fel:

Kontrollera att källan är tillgänglig genom att försöka ansluta till den direkt och inte via söktjänsten
Kontrollera om det finns aktuella fel eller avbrott i resursen i Azure-portalen
Sök efter nätverksfel i Azure-status
Kontrollera att du använder en offentlig DNS för namnmatchning och inte en Azure-Privat DNS

Serverlös indexering i Azure SQL Database (felkod 40613)

Om SQL-databasen finns på en serverlös beräkningsnivå kontrollerar du att databasen körs (och inte pausas) när indexeraren ansluter till den.

Om databasen har pausats förväntas den första inloggningen från söktjänsten återuppta databasen automatiskt, men returnerar i stället ett fel som anger att databasen inte är tillgänglig, vilket ger felkoden 40613. När databasen har körts försöker du logga in igen för att upprätta anslutningen.

Principer för villkorsstyrd åtkomst i Microsoft Entra ID

När du skapar en SharePoint Online-indexerare finns det ett steg som kräver att du loggar in på din Microsoft Entra-app när du har angett en enhetskod. Om du får ett meddelande om att "Your sign-in was successful but your admin requires the device requesting access to be managed"indexeraren förmodligen blockeras från SharePoint-dokumentbiblioteket av en princip för villkorsstyrd åtkomst .

Så här uppdaterar du principen och ger indexeraren åtkomst till dokumentbiblioteket:

Öppna Azure-portalen och sök efter villkorsstyrd åtkomst för Microsoft Entra.
Välj Principer på den vänstra menyn. Om du inte har åtkomst att visa den här sidan måste du antingen hitta någon som har åtkomst eller få åtkomst.
Ta reda på vilken princip som hindrar SharePoint Online-indexeraren från att komma åt dokumentbiblioteket. Principen som kan blockera indexeraren innehåller det användarkonto som du använde för att autentisera under indexerarens skapandesteg i avsnittet Användare och grupper . Principen kan också ha villkor som:
- Begränsa Windows-plattformar .
- Begränsa mobilappar och skrivbordsklienter.
- Ha Enhetstillstånd konfigurerat till Ja.
När du har bekräftat vilken princip som blockerar indexeraren gör du ett undantag för indexeraren. Börja med att hämta söktjänstens IP-adress.

Hämta först det fullständigt kvalificerade domännamnet (FQDN) för söktjänsten. FQDN ser ut som <your-search-service-name>.search.windows.net. Du hittar det fullständiga domännamnet i Azure-portalen.

Nu när du har FQDN hämtar du IP-adressen för söktjänsten genom att utföra en nslookup (eller en ping) av det fullständiga domännamnet. I följande exempel lägger du till "150.0.0.1" i en inkommande regel i Azure Storage-brandväggen. Det kan ta upp till 15 minuter efter att brandväggsinställningarna har uppdaterats för att söktjänstindexeraren ska kunna komma åt Azure Storage-kontot.
```
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
```
Hämta IP-adressintervallen för indexerarens körningsmiljö för din region.

Extra IP-adresser används för begäranden som kommer från indexerarens körningsmiljö för flera klienter. Du kan hämta det här IP-adressintervallet från tjänsttaggen.

IP-adressintervallen AzureCognitiveSearch för tjänsttaggen kan antingen hämtas via identifierings-API:et eller den nedladdningsbara JSON-filen.

För den här övningen, förutsatt att söktjänsten är Azure Public Cloud, bör Azure Public JSON-filen laddas ned.

Från JSON-filen, förutsatt att söktjänsten finns i USA, västra centrala, visas listan över IP-adresser för körningsmiljön för flertenantindexerare nedan.
```
    {
      "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"
        ]
      }
    }
```
På sidan Villkorsstyrd åtkomst i Azure-portalen väljer du Namngivna platser i menyn till vänster och väljer sedan + IP-intervallplats. Ge den nya namngivna platsen ett namn och lägg till IP-intervallen för söktjänsten och indexerarens körningsmiljöer som du har samlat in i de två senaste stegen. 1
- För din IP-adress för söktjänsten kan du behöva lägga till "/32" i slutet av IP-adressen eftersom den endast accepterar giltiga IP-intervall.
- Kom ihåg att för IP-intervallen för indexerarens körningsmiljö behöver du bara lägga till IP-intervallen för den region som söktjänsten finns i.
Undanta den nya namngivna platsen från principen:
1. Välj Principer på den vänstra menyn.
2. Välj den princip som blockerar indexeraren.
3. Välj Villkor.
4. Välj Platser.
5. Välj Exkludera och lägg sedan till den nya namngivna platsen.
6. Spara ändringarna.
Vänta några minuter tills principen uppdateras och framtvinga de nya principreglerna.
Försök att skapa indexeraren igen:
1. Skicka en uppdateringsbegäran för datakällans objekt som du skapade.
2. Skicka om begäran om att skapa indexeraren igen. Använd den nya koden för att logga in och skicka sedan en annan begäran om att skapa indexeraren.

Indexering av dokumenttyper som inte stöds

Om du indexerar innehåll från Azure Blob Storage och containern innehåller blobar av en innehållstyp som inte stöds hoppar indexeraren över dokumentet. I andra fall kan det finnas problem med enskilda dokument.

I det här fallet kan du ange konfigurationsalternativ så att indexerarens bearbetning kan fortsätta i händelse av problem med enskilda dokument.

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

Dokument som saknas

Indexerare extraherar dokument eller rader från en extern datakälla och skapar sökdokument som sedan indexeras av söktjänsten. Ibland visas inte ett dokument som finns i datakällan i ett sökindex. Det här oväntade resultatet kan inträffa på grund av följande orsaker:

Dokumentet uppdaterades efter att indexeraren kördes. Om indexeraren är enligt ett schema, körs den så småningom igen och hämtar dokumentet.
Indexeraren överskrider tidsgränsen innan dokumentet kan matas in. Det finns maximala tidsgränser för bearbetning varefter inga dokument bearbetas. Du kan kontrollera indexerarens status i portalen eller genom att anropa GET Indexer Status (REST API).
Fältmappningar eller AI-berikning har ändrat dokumentet och dess artikulation i sökindexet skiljer sig från vad du förväntar dig.
Ändringsspårningsvärden är felaktiga eller krav saknas. Om ditt värde för högvattenstämpel är ett datum som har angetts till en framtida tid hoppas indexeraren över alla dokument som har ett tidigare datum. Du kan fastställa indexerarens ändringsspårningstillstånd med hjälp av fälten "initialTrackingState" och "finalTrackingState" i indexerarens status. Indexerare för Azure SQL och MySQL måste ha ett index på högvattenmärkeskolumnen i källtabellen, eller så kan frågor som används av indexeraren överskrida tidsgränsen.

Dricks

Om dokument saknas kontrollerar du den fråga som du använder för att se till att det inte utesluter dokumentet i fråga. Om du vill fråga efter ett visst dokument använder du REST-API:et för uppslagsdokument.

Innehåll saknas från Blob Storage

Blobindexeraren hittar och extraherar text från blobar i en container. Några problem med att extrahera text är:

Dokumentet innehåller endast skannade bilder. PDF-blobar som har icke-textinnehåll, till exempel skannade bilder (JPG:er), ger inte resultat i en standardpipeline för blobindexering. Om du har bildinnehåll med textelement kan du använda OCR eller bildanalys för att hitta och extrahera texten.
Blobindexeraren är konfigurerad att endast indexmetadata. För att extrahera innehåll måste blobindexeraren konfigureras för att extrahera både innehåll och metadata:

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

Innehåll saknas från Azure Cosmos DB

Azure AI Search har ett implicit beroende av Azure Cosmos DB-indexering. Om du inaktiverar automatisk indexering i Azure Cosmos DB returnerar Azure AI Search ett lyckat tillstånd, men kan inte indexera containerinnehållet. Anvisningar om hur du kontrollerar inställningar och aktiverar indexering finns i Hantera indexering i Azure Cosmos DB.

Dokumentantalsavvikelse mellan datakällan och indexet

En indexerare kan visa ett annat dokumentantal än antingen datakällan, själva indexet eller antalet i koden. Här följer några möjliga orsaker till varför det här beteendet kan inträffa:

Indexet kan fördröja det faktiska antalet dokument, särskilt i portalen.
Indexeraren har en princip för borttaget dokument. De borttagna dokumenten räknas av indexeraren om dokumenten indexeras innan de tas bort.
Om ID-kolumnen i datakällan inte är unik. Detta gäller för datakällor som har begreppet kolumner, till exempel Azure Cosmos DB.
Om datakällans definition har en annan fråga än den du använder för att uppskatta antalet poster. I din databas kör du till exempel frågor mot antalet databasposter, medan du i definitionsfrågan för datakällan bara väljer en delmängd av poster som ska indexeras.
Antalet kontrolleras med olika intervall för varje komponent i pipelinen: datakälla, indexerare och index.
Datakällan har en fil som är mappad till många dokument. Det här villkoret kan inträffa när indexering av blobar och "parsingMode" är inställt på jsonArray och jsonLines.

Dokument som bearbetas flera gånger

Indexerare använder en konservativ buffringsstrategi för att säkerställa att varje nytt och ändrat dokument i datakällan hämtas under indexeringen. I vissa situationer kan dessa buffertar överlappa varandra, vilket gör att en indexerare indexerar ett dokument två eller flera gånger, vilket resulterar i att antalet bearbetade dokument är mer än det faktiska antalet dokument i datakällan. Det här beteendet påverkar inte data som lagras i indexet, till exempel duplicering av dokument, bara att det kan ta längre tid att nå slutlig konsekvens. Det här villkoret är särskilt vanligt om något av följande villkor är sant:

Begäranden om indexerare på begäran utfärdas i snabb följd
Datakällans topologi innehåller flera repliker och partitioner (ett sådant exempel beskrivs här)
Datakällan är en Azure SQL-databas och kolumnen som valts som "högvattenmärke" är av typen datetime2

Indexerare är inte avsedda att anropas flera gånger i snabb följd. Om du behöver uppdateringar snabbt är den metod som stöds att skicka uppdateringar till indexet samtidigt som datakällan uppdateras. För bearbetning på begäran rekommenderar vi att du ökar takten för dina begäranden i fem minuters intervall eller mer och kör indexeraren enligt ett schema.

Exempel på duplicerad dokumentbearbetning med 30 sekunders buffert

Villkor under vilka ett dokument bearbetas två gånger förklaras i följande tidslinje som noterar varje åtgärd och räknaråtgärd. Följande tidslinje illustrerar problemet:

Tidslinje (hh:mm:ss)	Event	Indexerarens högvattenmärke	Kommentar
00:01:00	Skriva `doc1` till datakälla med slutlig konsekvens	`null`	Tidsstämpeln för dokument är 00:01:00.
00:01:05	Skriva `doc2` till datakälla med slutlig konsekvens	`null`	Tidsstämpeln för dokument är 00:01:05.
00:01:10	Indexeraren startar	`null`
00:01:11	Indexerare frågar efter alla ändringar före 00:01:10; repliken som indexerarens frågor råkar vara medveten om `doc2`– endast `doc2` hämtas	`null`	Indexeraren begär alla ändringar innan tidsstämpeln startas, men tar faktiskt emot en delmängd. Det här beteendet kräver tillbakablicksbuffertperioden.
00:01:12	Indexeraren bearbetar `doc2` för första gången	`null`
00:01:13	Indexeraren slutar	00:01:10	Högvattenmärket uppdateras till starttidsstämpeln för den aktuella indexerarens körning.
00:01:20	Indexeraren startar	00:01:10
00:01:21	Indexerare frågar efter alla ändringar mellan 00:00:40 och 00:01:20; repliken som indexeraren frågar råkar känna till både `doc1` och `doc2`; hämtar `doc1` och `doc2`	00:01:10	Indexerare begär alla ändringar mellan aktuellt högvattenmärke minus 30 sekunders buffert och starttidsstämpel för aktuell indexerarekörning.
00:01:22	Indexeraren bearbetar `doc1` för första gången	00:01:10
00:01:23	Indexeraren bearbetar `doc2` för andra gången	00:01:10
00:01:24	Indexeraren slutar	00:01:20	Högvattenmärket uppdateras till starttidsstämpeln för den aktuella indexerarens körning.
00:01:32	Indexeraren startar	00:01:20
00:01:33	Indexerare frågar efter alla ändringar mellan 00:00:50 och 00:01:32; hämtar `doc1` och `doc2`	00:01:20	Indexerare begär alla ändringar mellan aktuellt högvattenmärke minus 30 sekunders buffert och starttidsstämpel för aktuell indexerarekörning.
00:01:34	Indexeraren bearbetar `doc1` för andra gången	00:01:20
00:01:35	Indexeraren bearbetar `doc2` för tredje gången	00:01:20
00:01:36	Indexeraren slutar	00:01:32	Högvattenmärket uppdateras till starttidsstämpeln för den aktuella indexerarens körning.
00:01:40	Indexeraren startar	00:01:32
00:01:41	Indexerare frågar efter alla ändringar mellan 00:01:02 och 00:01:40; Hämtar `doc2`	00:01:32	Indexerare begär alla ändringar mellan aktuellt högvattenmärke minus 30 sekunders buffert och starttidsstämpel för aktuell indexerarekörning.
00:01:42	Indexeraren bearbetar `doc2` för fjärde gången	00:01:32
00:01:43	Indexeraren slutar	00:01:40	Observera att indexerarens körning startade mer än 30 sekunder efter den senaste skrivning till datakällan och även bearbetad `doc2`. Detta är det förväntade beteendet eftersom om alla indexerarekörningar före 00:01:35 elimineras blir detta den första och enda körningen som ska bearbetas `doc1` och `doc2`.

I praktiken sker det här scenariot bara när indexerare på begäran anropas manuellt inom några minuter från varandra, för vissa datakällor. Det kan resultera i felmatchade siffror (som indexeraren bearbetade totalt 345 dokument enligt indexerarens körningsstatistik, men det finns 340 dokument i datakällan och indexet) eller potentiellt ökad fakturering om du kör samma kunskaper för samma dokument flera gånger. Att köra en indexerare med ett schema är den rekommenderade rekommendationen.

Indexera dokument med känslighetsetiketter

Om du har angett känslighetsetiketter för dokument kanske du inte kan indexera dem. Om du får fel tar du bort etiketterna innan du indexerar.

Share via