Felsökningsanvisningar för indexerare för Azure Cognitive Search

Ibland stöter indexerare på problem och det finns inga fel som hjälper till med diagnos. Den här artikeln beskriver problem och möjliga lösningar när indexerarens resultat är oväntade och det finns begränsad information att fortsätta med. Om du har ett 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 som skyddas av Azures nätverkssäkerhetsmekanismer har indexerare en begränsad uppsättning alternativ för att upprätta anslutningen. 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.

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 är aktiverad. 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:

  • Inaktivera brandväggen genom att tillåta åtkomst från Alla nätverk (om möjligt).

  • Du kan också tillåta åtkomst för IP-adressen för din söktjänst och IP-adressintervallet AzureCognitiveSearch för tjänsttaggen i brandväggsreglerna för din resurs (begränsning av IP-adressintervall).

Information om hur du konfigurerar BEGRÄNSNINGAR för IP-adressintervall för varje typ av datakälla finns på följande länkar:

Begränsning: Enligt dokumentationen ovan för Azure Storage fungerar begränsningar för IP-adressintervall endast om din söktjänst och ditt lagringskonto finns i olika regioner.

Azure-funktioner (som kan användas som en anpassad webb-API-färdighet) stöder även IP-adressbegränsningar. Listan över IP-adresser som ska konfigureras är IP-adressen för din söktjänst och IP-adressintervallet AzureCognitiveSearch för 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.

Konfigurera regler för nätverkssäkerhetsgrupper (NSG)

När du kommer åt data i en SQL-hanterad instans, eller när en virtuell Azure-dator används som webbtjänst-URI för en anpassad webb-API-färdighet, behöver kunderna inte bry sig om specifika IP-adresser.

I sådana fall kan den virtuella Azure-datorn eller den hanterade SQL-instansen konfigureras att finnas i ett virtuellt nätverk. Sedan kan en nätverkssäkerhetsgrupp konfigureras för att filtrera den typ av nätverkstrafik som kan flöda in och ut från de virtuella nätverksundernäten och nätverksgränssnitten.

Tjänsttaggen AzureCognitiveSearch kan användas direkt i de inkommande NSG-reglerna utan att behöva leta upp ip-adressintervallet.

Mer information om hur du kommer åt data i en SQL-hanterad instans beskrivs här.

Nätverksfel

Nätverksfel är vanligtvis 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 källan i Azure Portal om det finns aktuella fel eller avbrott
  • Sök efter nätverksfel i Azure-status
  • Kontrollera att du använder offentlig DNS för namnmatchning och inte en Azure-Privat DNS

Azure SQL databasserverlös indexering (felkod 40613)

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

Om databasen pausas återupptar den första inloggningen från söktjänsten databasen automatiskt, men det returnerar också ett fel som anger att databasen inte är tillgänglig med 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 SharePoint

När du skapar en SharePoint-indexerare går du igenom ett steg som kräver att du loggar in på din Azure AD-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 troligen kommer att blockeras från att komma åt SharePoint-dokumentbiblioteket på grund av en princip för villkorsstyrd åtkomst .

Följ stegen nedan om du vill uppdatera principen så att indexeraren får åtkomst till dokumentbiblioteket:

  1. Öppna Azure Portal och sök Azure AD villkorlig åtkomst och välj sedan 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.

  2. Fastställ vilken princip som hindrar SharePoint-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 när indexeraren skapades 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.
  3. När du har bekräftat att det finns en princip som blockerar indexeraren måste du göra ett undantag för indexeraren. Hämta söktjänstens IP-adress.

    1. Hämta det fullständigt kvalificerade domännamnet (FQDN) för söktjänsten. Detta kommer att se ut som <search-service-name>.search.windows.net. Du kan ta reda på FQDN genom att leta upp din söktjänst på Azure Portal.

    Hämta tjänst-FQDN

    IP-adressen för söktjänsten kan hämtas genom att utföra en nslookup (eller en ping) av det fullständiga domännamnet. I exemplet nedan lägger du till "150.0.0.1" i en regel för inkommande trafik i Azure Storage-brandväggen. Det kan ta upp till 15 minuter efter att brandväggsinställningarna har uppdaterats för söktjänstindexeraren för att 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
    
  4. Hämta IP-adressintervallen för indexerarens körningsmiljö för din region.

    Ytterligare IP-adresser används för begäranden som kommer från indexerarens körningsmiljö för flera klientorganisationer. 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.

    I den här genomgången, förutsatt att söktjänsten är det offentliga Azure-molnet, bör den offentliga Azure JSON-filen laddas ned.

    Ladda ned JSON-fil

    I 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 indexeraren för flera klientorganisationer 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"
            ]
          }
        }
    
  5. På sidan Villkorsstyrd åtkomst i Azure Portal väljer du Namngivna platser på menyn till vänster och väljer sedan + PLATS för IP-intervall. 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 samlade in i de två senaste stegen.

    • 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 bara 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.
  6. 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.
  7. Vänta några minuter tills principen uppdateras och framtvinga de nya principreglerna.

  8. 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 till 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.

Du kan ange konfigurationsalternativ så att indexerarens bearbetning kan fortsätta om det uppstår problem med enskilda dokument.

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

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:

  • Dokumentet uppdaterades efter att indexeraren kördes. Om indexeraren är enligt ett schema körs den så småningom igen och hämtar dokumentet.
  • Indexerarens tidsgräns överst gick ut innan dokumentet kunde matas in. Det finns maximala tidsgränser för bearbetning efter vilken inga dokument kommer att 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 artikulering i sökindexet skiljer sig från vad du förväntar dig.
  • Ändringsspårningsvärden är felaktiga eller krav saknas. Om värdet för högvattenmärket är ett datum som anges till en framtida tid, hoppas alla dokument som har ett datum som är mindre än detta över av indexeraren. Du kan förstå indexerarens status för ändringsspårning 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å källtabellens högvattenmärkeskolumn, annars kan frågor som används av indexeraren överskrida tidsgränsen.

Tips

Om dokument saknas kontrollerar du vilken fråga 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 från Blob Storage saknas

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 för att endast indexmetadata. Om du vill 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 i Azure Cosmos DB

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

Indexeraren visar ett annat dokumentantal än datakälla eller index

Indexeraren kan visa ett annat dokumentantal än datakällan, indexet eller antalet i koden under en viss tidpunkt, beroende på specifika omständigheter. Här följer några möjliga orsaker till varför detta kan inträffa:

  • Indexeraren har en princip för borttaget dokument. De borttagna dokumenten räknas på indexerarens slut om de indexeras innan de tas bort.
  • Om kolumnen ID 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 som du använder för att uppskatta antalet poster. I din databas kör du till exempel frågor mot alla dina databasposter, medan du i definitionsfrågan för datakällan kanske bara väljer en delmängd av poster som ska indexeras.
  • Antalet kontrolleras i olika intervall för varje komponent i pipelinen: datakälla, indexerare och index.
  • Indexet kan ta några minuter att visa det verkliga antalet dokument.
  • 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.
  • På grund av dokument som bearbetas flera gånger.

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 större än det faktiska antalet dokument i datakällan. Det här beteendet påverkar inte de data som lagras i indexet, till exempel duplicering av dokument, bara att det kan ta längre tid att uppnå slutlig konsekvens. Detta kan vara 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 väljs som "högvattenmärke" är av typendatetime2

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 du uppdaterar datakällan. 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 nedan i en tidslinje som noterar varje åtgärd och räknaråtgärd. Följande tidslinje illustrerar problemet:

Tidslinje (hh:mm:ss) Händelse Högvattenmärke för indexerare Kommentar
00:01:00 Skriva doc1 till datakälla med slutlig konsekvens null Dokumenttidsstämpeln är 00:01:00.
00:01:05 Skriva doc2 till datakälla med slutlig konsekvens null Dokumenttidsstämpeln är 00:01:05.
00:01:10 Indexeraren startar null
00:01:11 Indexeraren frågar efter alla ändringar före 00:01:10; repliken som indexeringsfrågorna bara känner doc2till . 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 buffertperioden för tillbakablick.
00:01:12 Indexeringsprocesser 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 indexeringsfrågorna råkar känna till både doc1 och doc2; hämtar doc1 och doc2 00:01:10 Indexeraren begär alla ändringar mellan aktuellt högvattenmärke minus bufferten på 30 sekunder och starttidsstämpeln för den aktuella indexerarens körning.
00:01:22 Indexeringsprocesser doc1 för första gången 00:01:10
00:01:23 Indexeringsprocesser 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 Indexeraren begär alla ändringar mellan aktuellt högvattenmärke minus bufferten på 30 sekunder och starttidsstämpeln för den aktuella indexerarens körning.
00:01:34 Indexeringsprocesser doc1 för andra gången 00:01:20
00:01:35 Indexeringsprocesser 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 Indexeringsfrågor för alla ändringar mellan 00:01:02 och 00:01:40; Hämtar doc2 00:01:32 Indexeraren begär alla ändringar mellan aktuellt högvattenmärke minus bufferten på 30 sekunder och starttidsstämpeln för den aktuella indexerarens körning.
00:01:42 Indexeringsprocesser doc2 för fjärde gången 00:01:32
00:01:43 Indexeraren slutar 00:01:40 Observera att den här indexeringskörningen startade mer än 30 sekunder efter den senaste skrivningen till datakällan och även bearbetade doc2. Detta är det förväntade beteendet eftersom om alla indexeringskörningar före 00:01:35 elimineras blir detta den första och enda körningen som bearbetar doc1 och doc2.

I praktiken inträffar 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 tal (t.ex. att indexeraren har bearbetat 345 dokument totalt 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 märkt dokument med känslighetsetiketter kanske du inte kan indexera dem. Om du får fel tar du bort etiketterna innan du indexerar.

Se även