Pokyny k řešení potíží s indexerem pro Azure AI Search

Článek
01/13/2024

Indexery občas narazí na problémy, které negenerují chyby nebo se vyskytují v jiných službách Azure, například při ověřování nebo při připojování. Tento článek se zaměřuje na řešení potíží s indexerem v případě, že neexistují žádné zprávy, které by vás provedou. Poskytuje také řešení potíží s chybami, které pocházejí z nehledaných prostředků používaných při indexování.

Poznámka:

Pokud máte chybu služby Azure AI Search, která se má prošetřit, přečtěte si téma Řešení běžných chyb a upozornění indexeru .

Řešení potíží s připojeními k omezeným prostředkům

U zdrojů dat v rámci zabezpečení sítě Azure jsou indexery omezené tím, jak se připojení vytváří. Indexery v současné době můžou přistupovat k omezeným zdrojům dat za bránou firewall protokolu IP nebo ve virtuální síti prostřednictvím privátního koncového bodu pomocí sdíleného privátního propojení.

Pravidla brány firewall

Azure Storage, Azure Cosmos DB a Azure SQL poskytují konfigurovatelnou bránu firewall. Pokud brána firewall zablokuje požadavek, neexistuje žádná konkrétní chybová zpráva. Obvykle jsou chyby brány firewall obecné. Mezi běžné chyby patří:

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

Existují dvě možnosti, jak povolit indexerům přístup k těmto prostředkům v takové instanci:

Nakonfigurujte příchozí pravidlo pro IP adresu vaší vyhledávací služby a rozsah IP adres značky AzureCognitiveSearchslužby. Podrobnosti o konfiguraci omezení rozsahu IP adres pro každý typ zdroje dat najdete na následujících odkazech:
Jako poslední nebo dočasná míra zakažte bránu firewall povolením přístupu ze všech sítí.

Omezení: Omezení rozsahu IP adres fungují jenom v případě, že vaše vyhledávací služba a váš účet úložiště jsou v různých oblastech.

Kromě načítání dat také indexery odesílají odchozí žádosti prostřednictvím sad dovedností a vlastních dovedností. Pro vlastní dovednosti založené na funkci Azure mějte na paměti, že služby Azure Functions mají také omezení IP adres. Seznam IP adres, které se mají povolit pro provádění vlastních dovedností, zahrnují IP adresu vaší vyhledávací služby a rozsah IP adres značky AzureCognitiveSearch služby.

Pravidla skupin zabezpečení sítě (NSG)

Když indexer přistupuje k datům ve spravované instanci SQL nebo když se virtuální počítač Azure používá jako identifikátor URI webové služby pro vlastní dovednosti, skupina zabezpečení sítě určuje, jestli jsou požadavky povolené.

U externích prostředků umístěných ve virtuální síti nakonfigurujte příchozí pravidla NSG pro AzureCognitiveSearch značku služby.

Další informace o připojení k virtuálnímu počítači najdete v tématu Konfigurace připojení k SQL Serveru na virtuálním počítači Azure.

Chyby sítě

Obvykle jsou chyby sítě obecné. Mezi běžné chyby patří:

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

Když se zobrazí některá z těchto chyb:

Ujistěte se, že je zdroj přístupný tak, že se k němu pokusíte připojit přímo, a ne prostřednictvím vyhledávací služby.
Zkontrolujte, jestli váš prostředek na webu Azure Portal nemá žádné aktuální chyby nebo výpadky.
Kontrola výpadků sítě ve stavu Azure
Ověřte, že používáte veřejný DNS pro překlad názvů, a ne azure Privátní DNS

Bezserverové indexování azure SQL Database (kód chyby 40613)

Pokud je vaše databáze SQL na bezserverové výpočetní úrovni, ujistěte se, že je databáze spuštěná (a není pozastavená), když se k ní indexer připojí.

Pokud je databáze pozastavená, očekává se, že první přihlášení z vyhledávací služby automaticky obnoví databázi, ale místo toho vrátí chybu s oznámením, že databáze není k dispozici a zobrazí kód chyby 40613. Po spuštění databáze zkuste znovu přihlásit a navázat připojení.

Zásady podmíněného přístupu Microsoft Entra

Když vytvoříte indexer SharePointu Online, musíte se po zadání kódu zařízení přihlásit ke své aplikaci Microsoft Entra. Pokud se zobrazí zpráva, že "Your sign-in was successful but your admin requires the device requesting access to be managed"indexer je pravděpodobně zablokován z knihovny dokumentů SharePointu pomocí zásad podmíněného přístupu .

Aktualizace zásad a povolení přístupu indexeru ke knihovně dokumentů:

Otevřete web Azure Portal a vyhledejte podmíněný přístup Microsoft Entra.
V nabídce vlevo vyberte Zásady . Pokud nemáte přístup k zobrazení této stránky, musíte najít někoho, kdo má přístup, nebo získat přístup.
Určete, které zásady blokují indexer SharePointu Online v přístupu ke knihovně dokumentů. Zásady, které můžou blokovat indexer, zahrnují uživatelský účet, který jste použili k ověření během kroku vytváření indexeru v části Uživatelé a skupiny . Zásady také můžou mít podmínky , které:
- Omezení platforem Windows
- Omezit mobilní aplikace a desktopové klienty
- Mají stav zařízení nakonfigurovaný na Ano.
Jakmile ověříte, které zásady indexer blokují, vytvořte výjimku pro indexer. Začněte načtením IP adresy vyhledávací služby.

Nejprve získejte plně kvalifikovaný název domény (FQDN) vaší vyhledávací služby. Plně kvalifikovaný název domény vypadá takto <your-search-service-name>.search.windows.net. Plně kvalifikovaný název domény najdete na webu Azure Portal.

Teď, když máte plně kvalifikovaný název domény, získejte IP adresu vyhledávací služby provedením nslookup (nebo a ping) plně kvalifikovaného názvu domény. V následujícím příkladu byste do příchozího pravidla v bráně firewall služby Azure Storage přidali "150.0.0.1". Než se indexer vyhledávací služby aktualizuje, může trvat až 15 minut, než se aktualizuje nastavení brány firewall, aby měl přístup k účtu služby Azure Storage.
```
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
```
Získejte rozsahy IP adres pro spouštěcí prostředí indexeru pro vaši oblast.

Další IP adresy se používají pro požadavky, které pocházejí z víceklientské spouštěcího prostředí indexeru. Tento rozsah IP adres můžete získat ze značky služby.

Rozsahy IP adres pro AzureCognitiveSearch značku služby je možné získat buď přes rozhraní API zjišťování, nebo soubor JSON ke stažení.

Pro účely tohoto cvičení by se měl stáhnout soubor JSON azure za předpokladu, že vyhledávací služba je veřejný cloud Azure.

Za předpokladu, že je vyhledávací služba v oblasti USA – středozápad, je seznam IP adres pro spouštěcí prostředí víceklientského indexeru uvedený níže.
```
    {
      "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"
        ]
      }
    }
```
Zpět na stránce Podmíněný přístup na webu Azure Portal vyberte v nabídce na levé straně pojmenovaná umístění a pak vyberte umístění rozsahů IP adres. Pojmenujte nové pojmenované umístění a přidejte rozsahy IP adres pro spouštěcí prostředí vyhledávací služby a indexeru, která jste shromáždili v posledních dvou krocích. 0
- Pro IP adresu vyhledávací služby možná budete muset na konec IP adresy přidat /32, protože přijímá jenom platné rozsahy IP adres.
- Mějte na paměti, že pro rozsahy IP adres prostředí spouštění indexeru stačí přidat pouze rozsahy IP adres pro oblast, ve které je vaše vyhledávací služba.
Vylučte nové pojmenované umístění ze zásad:
1. V nabídce vlevo vyberte Zásady .
2. Vyberte zásadu, která blokuje indexer.
3. Vyberte podmínky.
4. Vyberte umístění.
5. Vyberte Možnost Vyloučit a pak přidejte nové pojmenované umístění.
6. Uložte změny.
Počkejte několik minut, než se zásada aktualizuje a vynutí nová pravidla zásad.
Zkuste znovu vytvořit indexer:
1. Odešlete žádost o aktualizaci objektu zdroje dat, který jste vytvořili.
2. Znovu odešlete požadavek na vytvoření indexeru. Pomocí nového kódu se přihlaste a odešlete další požadavek na vytvoření indexeru.

Indexování nepodporovaných typů dokumentů

Pokud indexujete obsah ze služby Azure Blob Storage a kontejner obsahuje objekty blob nepodporovaného typu obsahu, indexer tento dokument přeskočí. V jiných případech můžou nastat problémy s jednotlivými dokumenty.

V této situaci můžete nastavit možnosti konfigurace, které umožní zpracování indexeru pokračovat v případě problémů s jednotlivými dokumenty.

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

Chybějící dokumenty

Indexery extrahují dokumenty nebo řádky z externího zdroje dat a vytvářejí vyhledávací dokumenty, které pak indexuje vyhledávací služba. Někdy se dokument, který existuje ve zdroji dat, nezobrazuje v indexu vyhledávání. K tomuto neočekávanému výsledku může dojít z následujících důvodů:

Dokument byl aktualizován po spuštění indexeru. Pokud je indexer v plánu, nakonec se znovu spustí a převezme dokument.
Časový limit indexeru vypršel, než se dokument mohl ingestovat. Existují maximální časové limity zpracování, po kterých se nezpracovávají žádné dokumenty. Stav indexeru můžete zkontrolovat na portálu nebo voláním Get Indexer Status (REST API).
Mapování polí nebo rozšiřování AI změnilo dokument a jeho artikulaci v indexu vyhledávání se liší od toho, co očekáváte.
Hodnoty sledování změn jsou chybné nebo chybí požadavky. Pokud je hodnota vašeho horního vodoznaku nastavená na budoucí čas, indexer přeskočí všechny dokumenty, které mají dřívější datum. Stav sledování změn indexeru můžete určit pomocí polí initialTrackingState a finalTrackingState ve stavu indexeru. Indexery pro Azure SQL a MySQL musí mít index ve sloupci horního limitu zdrojové tabulky nebo dotazy používané indexerem můžou vyprší časový limit.

Tip

Pokud dokumenty chybí, zkontrolujte dotaz , který používáte, a ujistěte se, že dokument nevyloučíte. Pokud chcete zadat dotaz na konkrétní dokument, použijte rozhraní REST API pro vyhledávání dokumentů.

Chybějící obsah ze služby Blob Storage

Indexer objektů blob najde a extrahuje text z objektů blob v kontejneru. Mezi problémy s extrahováním textu patří:

Dokument obsahuje jenom naskenované obrázky. Objekty blob PDF, které mají netextový obsah, jako jsou naskenované obrázky (JPG), negenerují výsledky ve standardním kanálu indexování objektů blob. Pokud máte obsah obrázku s textovými prvky, můžete text najít a extrahovat pomocí analýzy OCR nebo obrázku.
Indexer objektů blob je nakonfigurovaný tak, aby indexoval pouze metadata. Aby bylo možné extrahovat obsah, musí být indexer objektů blob nakonfigurovaný tak, aby extrahovali obsah i 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" } }
}

Chybějící obsah ve službě Azure Cosmos DB

Azure AI Search má implicitní závislost na indexování služby Azure Cosmos DB. Pokud automatické indexování ve službě Azure Cosmos DB vypnete, azure AI Search vrátí úspěšný stav, ale obsah kontejneru se indexuje. Pokyny ke kontrole nastavení a zapnutí indexování najdete v tématu Správa indexování ve službě Azure Cosmos DB.

Nesrovnalosti mezi zdrojem dat a indexem počtu dokumentů

Indexer může zobrazit jiný počet dokumentů než zdroj dat, samotný index nebo počet v kódu. Tady je několik možných důvodů, proč k tomuto chování může dojít:

Index může zpožďovat zobrazení skutečného počtu dokumentů, zejména na portálu.
Indexer má odstraněnou zásadu dokumentu. Odstraněné dokumenty se počítají indexerem, pokud jsou dokumenty indexovány před odstraněním.
Pokud sloupec ID ve zdroji dat není jedinečný. To platí pro zdroje dat, které mají koncept sloupců, jako je Azure Cosmos DB.
Pokud má definice zdroje dat jiný dotaz než ten, který používáte k odhadu počtu záznamů. V databázi například dotazujete počet záznamů databáze, zatímco v definičním dotazu zdroje dat můžete vybrat jenom podmnožinu záznamů, které se mají indexovat.
Počty se kontrolují v různých intervalech pro každou komponentu kanálu: zdroj dat, indexer a index.
Zdroj dat obsahuje soubor, který je namapovaný na mnoho dokumentů. K této podmínce může dojít při indexování objektů blob a "parsingMode" je nastavena a jsonArrayjsonLines.

Dokumenty zpracovávané několikrát

Indexery používají konzervativní strategii ukládání do vyrovnávací paměti, aby se zajistilo, že se během indexování vyzvedne každý nový a změněný dokument ve zdroji dat. V některých situacích se tyto vyrovnávací paměti můžou překrývat, což způsobí, že indexer indexer indexuje dokument dvakrát nebo vícekrát, což vede k tomu, že počet zpracovaných dokumentů bude větší než skutečný počet dokumentů ve zdroji dat. Toto chování nemá vliv na data uložená v indexu, například duplikování dokumentů, ale může trvat déle, než dosáhne konečné konzistence. Tato podmínka je obzvláště rozšířená, pokud platí některá z následujících kritérií:

Žádosti indexeru na vyžádání se vydávají v rychlém sledu.
Topologie zdroje dat zahrnuje více replik a oddílů (jeden z příkladů je zde popsán).
Zdroj dat je databáze Azure SQL a sloupec zvolený jako "horní značka" je typu datetime2

Indexery nejsou určené k vícenásobnému vyvolání v rychlém sledu. Pokud potřebujete aktualizace rychle, podporovaným přístupem je nabízení aktualizací do indexu při souběžné aktualizaci zdroje dat. Pro zpracování na vyžádání doporučujeme postupovat podle tempa vašich požadavků v pětiminutových intervalech nebo více a spustit indexer podle plánu.

Příklad zpracování duplicitního dokumentu s 30sekundovou vyrovnávací pamětí

Podmínky, za kterých se dokument zpracovává dvakrát, je vysvětleno na následující časové ose, která zaznamenává každou akci a akci čítače. Tento problém znázorňuje následující časová osa:

Časová osa (hh:mm:ss)	Událost	Horní horní mez indexeru	Komentář
00:01:00	Zápis `doc1` do zdroje dat s konečnou konzistencí	`null`	Časové razítko dokumentu je 00:01:00.
00:01:05	Zápis `doc2` do zdroje dat s konečnou konzistencí	`null`	Časové razítko dokumentu je 00:01:05.
00:01:10	Spustí se indexer.	`null`
00:01:11	Indexer se dotazuje na všechny změny před 00:01:10; replika, o které dotazy indexeru `doc2`vědí pouze ; je načtena pouze `doc2`	`null`	Indexer požaduje všechny změny před spuštěním časového razítka, ale ve skutečnosti obdrží podmnožinu. Toto chování vyžaduje období vyrovnávací paměti zpětného vyhledávání.
00:01:12	Indexer zpracovává `doc2` poprvé	`null`
00:01:13	Indexer končí	00:01:10	Horní mez se aktualizuje na počáteční časové razítko aktuálního spuštění indexeru.
00:01:20	Spustí se indexer.	00:01:10
00:01:21	Dotazy indexeru pro všechny změny mezi 00:00:40 a 00:01:20; replika, o které dotazy `doc1` indexeru vědí, a `doc2`; načítá `doc1` a `doc2`	00:01:10	Indexer požaduje všechny změny mezi aktuální vysokou horní mez minus 30sekundovou vyrovnávací pamětí a počátečním časovým razítkem aktuálního spuštění indexeru.
00:01:22	Indexer zpracovává `doc1` poprvé	00:01:10
00:01:23	Indexer zpracovává `doc2` podruhé	00:01:10
00:01:24	Indexer končí	00:01:20	Horní mez se aktualizuje na počáteční časové razítko aktuálního spuštění indexeru.
00:01:32	Spustí se indexer.	00:01:20
00:01:33	Dotazy indexeru pro všechny změny mezi 00:00:50 a 00:01:32; načítá `doc1` a `doc2`	00:01:20	Indexer požaduje všechny změny mezi aktuální vysokou horní mez minus 30sekundovou vyrovnávací pamětí a počátečním časovým razítkem aktuálního spuštění indexeru.
00:01:34	Indexer zpracovává `doc1` podruhé	00:01:20
00:01:35	Indexer zpracovává `doc2` třetí čas	00:01:20
00:01:36	Indexer končí	00:01:32	Horní mez se aktualizuje na počáteční časové razítko aktuálního spuštění indexeru.
00:01:40	Spustí se indexer.	00:01:32
00:01:41	Indexer se dotazuje na všechny změny mezi 00:01:02 a 00:01:40; Načte `doc2`	00:01:32	Indexer požaduje všechny změny mezi aktuální vysokou horní mez minus 30sekundovou vyrovnávací pamětí a počátečním časovým razítkem aktuálního spuštění indexeru.
00:01:42	Indexer zpracovává `doc2` čtvrtý čas.	00:01:32
00:01:43	Indexer končí	00:01:40	Všimněte si, že spuštění indexeru začalo více než 30 sekund po posledním zápisu do zdroje dat a také zpracovával `doc2`. Toto je očekávané chování, protože pokud jsou všechny spuštění indexeru před 00:01:35 eliminovány, stane se to první a jediné spuštění pro zpracování `doc1` a `doc2`.

V praxi k tomuto scénáři dochází pouze v případě, že se indexery na vyžádání ručně vyvolá v řádu minut od sebe pro určité zdroje dat. Může mít za následek neshodná čísla (například indexer zpracoval celkem 345 dokumentů podle statistik provádění indexeru, ale ve zdroji dat a indexu je 340 dokumentů) nebo se může zvýšit fakturace, pokud používáte stejné dovednosti pro stejný dokument vícekrát. Upřednostňovaným doporučením je spuštění indexeru s využitím plánu.

Indexování dokumentů pomocí popisků citlivosti

Pokud máte u dokumentů nastavené popisky citlivosti, možná je nebudete moct indexovat. Pokud se vám zobrazí chyby, odeberte popisky před indexováním.