Az Indexelő hibaelhárítási útmutatója az Azure AI Search szolgáltatáshoz

Cikk
01/13/2024

Az indexelők időnként olyan problémákba ütköznek, amelyek nem okoznak hibákat, vagy más Azure-szolgáltatásokban fordulnak elő, például a hitelesítés vagy a csatlakozás során. Ez a cikk az indexelők problémáinak elhárítására összpontosít, ha nincsenek olyan üzenetek, amelyek irányítják Önt. Az indexelés során használt nem keresési erőforrásokból származó hibák hibaelhárítását is biztosítja.

Feljegyzés

Ha az Azure AI Search-hiba kivizsgálása sikertelen, tekintse meg az indexelők gyakori hibáinak és figyelmeztetéseinek hibaelhárítását.

Korlátozott erőforrások kapcsolatainak hibaelhárítása

Az Azure hálózati biztonsága alatt álló adatforrások esetében az indexelők korlátozottak a kapcsolat létrehozásának módjában. Az indexelők jelenleg egy IP-tűzfal mögött vagy egy virtuális hálózaton keresztül férhetnek hozzá korlátozott adatforrásokhoz egy privát végponton keresztül egy megosztott privát hivatkozás használatával.

Tűzfalszabályok

Az Azure Storage, az Azure Cosmos DB és az Azure SQL konfigurálható tűzfalat biztosít. Nincs konkrét hibaüzenet, ha a tűzfal blokkolja a kérést. A tűzfalhibák általában általánosak. Néhány gyakori hiba:

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

Két lehetőség van arra, hogy az indexelők hozzáférjenek ezekhez az erőforrásokhoz egy ilyen példányban:

Konfiguráljon egy bejövő szabályt a keresési szolgáltatás IP-címéhez és a szolgáltatáscímke IP-címtartományához.AzureCognitiveSearch Az egyes adatforrástípusok IP-címtartomány-korlátozásainak konfigurálására vonatkozó részletek az alábbi hivatkozásokon találhatók:
Végső megoldásként vagy ideiglenes intézkedésként tiltsa le a tűzfalat a minden hálózatról való hozzáférés engedélyezésével.

Korlátozás: Az IP-címtartomány korlátozásai csak akkor működnek, ha a keresési szolgáltatás és a tárfiók különböző régiókban található.

Az adatlekérés mellett az indexelők készségkészleteken és egyéni képességeken keresztül is küldenek kimenő kéréseket. Az Azure-függvényeken alapuló egyéni képességek esetében vegye figyelembe, hogy az Azure-függvények IP-címkorlátozásokkal is rendelkeznek. Az egyéni képességek végrehajtásához engedélyezni kívánt IP-címek listája tartalmazza a keresési szolgáltatás IP-címét és a szolgáltatáscímke IP-címtartományát AzureCognitiveSearch .

Hálózati biztonsági csoport- (NSG-) szabályok

Ha egy indexelő hozzáfér egy felügyelt SQL-példány adataihoz, vagy ha egy Azure-beli virtuális gépet használnak webszolgáltatás-URI-ként egy egyéni képességhez, a hálózati biztonsági csoport határozza meg, hogy a kérelmek engedélyezve vannak-e.

A virtuális hálózaton található külső erőforrások esetében konfigurálja a AzureCognitiveSearch szolgáltatáscímke bejövő NSG-szabályait.

További információ a virtuális géphez való csatlakozásról: Sql Server-kapcsolat konfigurálása Azure-beli virtuális gépen.

Hálózati hibák

A hálózati hibák általában általánosak. Néhány gyakori hiba:

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

Ha a következő hibák bármelyikét kapja:

Győződjön meg arról, hogy a forrás elérhető, ha közvetlenül próbál csatlakozni hozzá, és nem a keresési szolgáltatáson keresztül
Ellenőrizze az erőforrást az Azure Portalon az aktuális hibákért vagy kimaradásokért
Ellenőrizze, hogy vannak-e hálózati kimaradások az Azure-ban
Ellenőrizze, hogy nyilvános DNS-t használ-e névfeloldáshoz, és nem Azure-saját DNS

Azure SQL Database kiszolgáló nélküli indexelés (hibakód: 40613)

Ha az SQL-adatbázis kiszolgáló nélküli számítási szinten van, győződjön meg arról, hogy az adatbázis fut (és nem szünetel), amikor az indexelő csatlakozik hozzá.

Ha az adatbázis szüneteltetve van, a keresési szolgáltatásból való első bejelentkezés várhatóan automatikusan folytatja az adatbázist, de ehelyett hibaüzenetet ad vissza, amely szerint az adatbázis nem érhető el, és a 40613 hibakódot adja vissza. Az adatbázis futtatása után próbálkozzon újra a bejelentkezéslel a kapcsolat létrehozásához.

Microsoft Entra feltételes hozzáférési irányelvek

SharePoint Online-indexelő létrehozásakor egy lépésben be kell jelentkeznie a Microsoft Entra alkalmazásba egy eszközkód megadása után. Ha egy üzenet jelenik "Your sign-in was successful but your admin requires the device requesting access to be managed"meg, az indexelőt valószínűleg egy feltételes hozzáférési szabályzat blokkolja a SharePoint-dokumentumtárból.

A szabályzat frissítése és az indexelő hozzáférésének engedélyezése a dokumentumtárhoz:

Nyissa meg az Azure Portalt, és keresse meg a Microsoft Entra feltételes hozzáférését.
Válassza a bal oldali menü Házirendek elemét. Ha nem rendelkezik hozzáféréssel a lap megtekintéséhez, vagy meg kell keresnie valakit, aki rendelkezik hozzáféréssel vagy hozzáféréssel rendelkezik.
Határozza meg, hogy melyik szabályzat blokkolja a SharePoint Online-indexelőt a dokumentumtár elérésében. Az indexelőt esetleg blokkoló szabályzat tartalmazza azt a felhasználói fiókot, amelyet az indexelő létrehozási lépése során hitelesítésre használt a Felhasználók és csoportok szakaszban. A szabályzat olyan feltételekkel is rendelkezhet, amelyek:
- Windows-platformok korlátozása.
- Mobilalkalmazások és asztali ügyfelek korlátozása.
- Állítsa be az eszköz állapotát Igen értékre.
Miután meggyőződött arról, hogy melyik szabályzat blokkolja az indexelőt, tegyen kivételt az indexelő számára. Kezdje a keresési szolgáltatás IP-címének beolvasásával.

Először szerezze be a keresési szolgáltatás teljes tartománynevét (FQDN). Az FQDN a következőképpen <your-search-service-name>.search.windows.netnéz ki. A teljes tartománynevet az Azure Portalon találja.

Most, hogy rendelkezik a teljes tartománynévvel, kérje le a keresési szolgáltatás IP-címét a teljes tartománynév egy nslookup (vagy egy ping) végrehajtásával. Az alábbi példában a "150.0.0.1" értéket adná hozzá egy bejövő szabályhoz az Azure Storage tűzfalán. A tűzfalbeállítások frissítése után akár 15 percig is eltarthat, amíg a keresési szolgáltatás indexelője hozzáfér az Azure Storage-fiókhoz.
```
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
```
Kérje le a régió indexelő végrehajtási környezetének IP-címtartományait.

A rendszer további IP-címeket használ az indexelő több-bérlős végrehajtási környezetéből származó kérelmekhez. Ezt az IP-címtartományt a szolgáltatáscímkéből szerezheti be.

A szolgáltatáscímke IP-címtartományai a AzureCognitiveSearch felderítési API-val vagy a letölthető JSON-fájllal kérhetők le.

Ebben a gyakorlatban, feltéve, hogy a keresési szolgáltatás az Azure Nyilvános felhő, le kell tölteni az Azure Public JSON-fájlt .

A JSON-fájlból, feltéve, hogy a keresési szolgáltatás az USA nyugati középső régiójában található, a több-bérlős indexelő végrehajtási környezet IP-címeinek listája alább látható.
```
    {
      "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"
        ]
      }
    }
```
Az Azure Portal Feltételes hozzáférés lapjára visszatérve válassza a bal oldali menüBen a Nevesített helyek lehetőséget, majd válassza a + IP-tartományok helyét. Adjon nevet az új névvel ellátott helynek, és adja hozzá a keresési szolgáltatás és az indexelő végrehajtási környezeteinek IP-tartományait, amelyeket az utolsó két lépésben gyűjtött össze. 0
- Előfordulhat, hogy a keresési szolgáltatás IP-címéhez hozzá kell adnia a "/32" értéket az IP-cím végéhez, mivel csak érvényes IP-címtartományokat fogad el.
- Ne feledje, hogy az indexelő végrehajtási környezetÉNEK IP-tartományaihoz csak ahhoz a régióhoz kell hozzáadnia az IP-tartományokat, amelyben a keresési szolgáltatás található.
Zárja ki az új elnevezett helyet a szabályzatból:
1. Válassza a bal oldali menü Házirendek elemét.
2. Válassza ki az indexelőt blokkoló szabályzatot.
3. Válassza a Feltételek lehetőséget.
4. Válassza ki a Helyek lehetőséget.
5. Válassza a Kizárás lehetőséget, majd adja hozzá az új elnevezett helyet.
6. Mentse a módosításokat.
Várjon néhány percet, amíg a szabályzat frissíti és kikényszeríti az új szabályzatszabályokat.
Próbálja meg újból létrehozni az indexelőt:
1. Küldjön egy frissítési kérést a létrehozott adatforrás-objektumhoz.
2. Az indexelő létrehozási kérésének újraküldése. Az új kód használatával jelentkezzen be, majd küldjön egy másik indexelő létrehozási kérelmet.

Nem támogatott dokumentumtípusok indexelése

Ha az Azure Blob Storage-ból indexel tartalmat, és a tároló nem támogatott tartalomtípusú blobokat tartalmaz, az indexelő kihagyja a dokumentumot. Más esetekben problémák merülhetnek fel az egyes dokumentumokkal kapcsolatban.

Ebben az esetben megadhatja a konfigurációs beállításokat , hogy az indexelő feldolgozása folytatódjon az egyes dokumentumokkal kapcsolatos problémák esetén.

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

Hiányzó dokumentumok

Az indexelők kinyerik a dokumentumokat vagy sorokat egy külső adatforrásból , és létrehoznak keresési dokumentumokat, amelyeket a keresési szolgáltatás indexel. Előfordulhat, hogy egy adatforrásban található dokumentum nem jelenik meg a keresési indexben. Ez a váratlan eredmény a következő okok miatt fordulhat elő:

A dokumentum az indexelő futtatása után frissült. Ha az indexelő ütemezés szerint működik, az végül újrafut, és felveszi a dokumentumot.
Az indexelő időtúllépést észlelt a dokumentum betöltése előtt. Vannak maximális feldolgozási határidők , amelyek után nem dolgoznak fel dokumentumokat. Az indexelő állapotát a portálon vagy az Indexelő állapotának lekérése (REST API) meghívásával ellenőrizheti.
A mezőleképezések vagy az AI-bővítés megváltoztatta a dokumentumot, és a keresési indexben való artikulációja eltér a várttól.
A változáskövetési értékek hibásak, vagy hiányoznak az előfeltételek. Ha a magas vízjel értéke egy jövőbeli időpontra beállított dátum, akkor az indexelő kihagyja a korábbi dátummal rendelkező dokumentumokat. Az indexelő változáskövetési állapotát az indexelő állapotának "initialTrackingState" és "finalTrackingState" mezőivel határozhatja meg. Az Azure SQL és a MySQL indexelőinek indexelniük kell a forrástábla magas vízjeloszlopán, vagy az indexelő által használt lekérdezések időtúllépést eredményezhetnek.

Tipp.

Ha a dokumentumok hiányoznak, ellenőrizze a használt lekérdezést , hogy ne zárja ki a kérdéses dokumentumot. Egy adott dokumentum lekérdezéséhez használja a Lookup Document REST API-t.

Hiányzó tartalom a Blob Storage-ból

A blobindexelő megkeresi és kinyeri a tárolóban lévő blobok szövegét. A szöveg kinyerésével kapcsolatos problémák közé tartoznak a következők:

A dokumentum csak beolvasott képeket tartalmaz. A nem szöveges tartalmú PDF-blobok, például a beolvasott képek (JPG-k) nem hoznak létre eredményeket egy szabványos blobindexelési folyamat során. Ha szöveges elemeket tartalmazó képtartalommal rendelkezik, az OCR vagy a képelemzés használatával megkeresheti és kinyerheti a szöveget.
A blobindexelő csak indexelési metaadatokra van konfigurálva. A tartalom kinyeréséhez a blobindexelőt úgy kell konfigurálni, hogy a tartalmat és a metaadatokat is kinyerje:

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

Hiányzó tartalom az Azure Cosmos DB-ből

Az Azure AI Search implicit függőséget ad az Azure Cosmos DB-indexeléshez. Ha kikapcsolja az automatikus indexelést az Azure Cosmos DB-ben, az Azure AI Search sikeres állapotot ad vissza, de nem indexeli a tároló tartalmát. A beállítások ellenőrzésére és az indexelés bekapcsolására vonatkozó utasításokért lásd : Indexelés kezelése az Azure Cosmos DB-ben.

Dokumentumszám eltérése az adatforrás és az index között

Az indexelők eltérő dokumentumszámot mutathatnak, mint az adatforrás, maga az index vagy a kódban szereplő szám. Az alábbiakban néhány lehetséges oka lehet ennek a viselkedésnek:

Az index késésben lehet a valós dokumentumszám megjelenítésében, különösen a portálon.
Az indexelő törölt dokumentumszabályzattal rendelkezik. A törölt dokumentumokat az indexelő megszámolja, ha a dokumentumok indexelve vannak a törlés előtt.
Ha az adatforrás azonosító oszlopa nem egyedi. Ez az oszlopok fogalmával rendelkező adatforrásokra vonatkozik, például az Azure Cosmos DB-re.
Ha az adatforrás definíciója eltér a rekordok számának becsléséhez használt lekérdezésétől. Az adatbázisban például az adatbázisrekordok számát kérdezi le, míg az adatforrásdefiníciós lekérdezésben csak a rekordok egy részhalmazát kell indexelnie.
A rendszer a folyamat minden összetevőjére vonatkozóan különböző időközönként ellenőrzi a számokat: adatforrás, indexelő és index.
Az adatforrás egy sok dokumentumra leképezett fájllal rendelkezik. Ez a feltétel akkor fordulhat elő, ha a blobok indexelése és a "parsingMode" értéke jsonArray és jsonLines.

Többször feldolgozott dokumentumok

Az indexelők konzervatív pufferelési stratégiát használnak annak biztosítására, hogy az adatforrás minden új és módosított dokumentuma bekerüljön az indexelés során. Bizonyos helyzetekben ezek a pufferek átfedésben lehetnek, így az indexelők két vagy több alkalommal indexelnek egy dokumentumot, ami azt eredményezi, hogy a feldolgozott dokumentumok száma meghaladja az adatforrásban lévő dokumentumok tényleges számát. Ez a viselkedés nem befolyásolja az indexben tárolt adatokat, például a dokumentumok duplikálását, csak azt, hogy a végleges konzisztencia elérése hosszabb időt vehet igénybe. Ez a feltétel különösen elterjedt, ha az alábbi feltételek bármelyike igaz:

Az igény szerinti indexelő kérések gyors egymásutánban jelennek meg
Az adatforrás topológiája több replikát és partíciót tartalmaz (egy ilyen példát itt tárgyalunk)
Az adatforrás egy Azure SQL-adatbázis, és a "magas vízjelként" kiválasztott oszlop típusa datetime2

Az indexelőket nem célja, hogy gyors egymásutánban többször is meghívják. Ha gyorsan szüksége van frissítésekre, a támogatott módszer az, hogy az adatforrás egyidejű frissítése mellett leküldi a frissítéseket az indexbe. Igény szerinti feldolgozáshoz azt javasoljuk, hogy a kéréseket ötperces időközönként vagy több időintervallumban hajtsa végre, és futtassa az indexelőt ütemezés szerint.

Példa duplikált dokumentumfeldolgozásra 30 másodperces pufferrel

A dokumentumok kétszeri feldolgozásának feltételeit az alábbi ütemterv ismerteti, amely az egyes műveletet és a számlálóműveleteket veszi fel. Az alábbi ütemterv a problémát mutatja be:

Idővonal (óó:mm:ss)	Esemény	Indexelő magas vízjele	Megjegyzés
00:01:00	Írás `doc1` adatforrásba végleges konzisztenciával	`null`	A dokumentum időbélyege 00:01:00.
00:01:05	Írás `doc2` adatforrásba végleges konzisztenciával	`null`	A dokumentum időbélyege 00:01:05.
00:01:10	Az indexelő elindul	`null`
00:01:11	Az indexelő a 00:01:10 előtti összes módosítást lekérdezi; a replika, amelyről az indexelő lekérdezései csak tudomást `doc2`szereznek; csak `doc2` a rendszer kéri le	`null`	Az indexelő minden módosítást kér az időbélyeg indítása előtt, de valójában egy részhalmazt kap. Ez a viselkedés megköveteli a visszatekintési pufferidőszakot.
00:01:12	Indexelő folyamatok `doc2` első alkalommal	`null`
00:01:13	Indexelő végei	00:01:10	A magas vízjel frissül az indexelő aktuális végrehajtásának kezdő időbélyegére.
00:01:20	Az indexelő elindul	00:01:10
00:01:21	Az indexelő lekérdezi a 00:00:40 és 00:01:20 közötti összes módosítást; a replika, amelyről az indexelő lekérdezések tudomást szereznek mind `doc1doc2`az; lekéri `doc1` és `doc2`	00:01:10	Az indexelő az aktuális magas vízjel és a 30 másodperces puffer közötti összes módosításra vonatkozó kérést, valamint az indexelő aktuális végrehajtásának kezdő időbélyegét kéri.
00:01:22	Indexelő folyamatok `doc1` első alkalommal	00:01:10
00:01:23	Indexelő folyamatok `doc2` második alkalommal	00:01:10
00:01:24	Indexelő végei	00:01:20	A magas vízjel frissül az indexelő aktuális végrehajtásának kezdő időbélyegére.
00:01:32	Az indexelő elindul	00:01:20
00:01:33	Az indexelő a 00:00:50 és 00:01:32 közötti összes módosítást lekérdezi; lekéri `doc1` és `doc2`	00:01:20	Az indexelő az aktuális magas vízjel és a 30 másodperces puffer közötti összes módosításra vonatkozó kérést, valamint az indexelő aktuális végrehajtásának kezdő időbélyegét kéri.
00:01:34	Indexelő folyamatok `doc1` második alkalommal	00:01:20
00:01:35	Az Indexelő harmadik alkalommal dolgozza `doc2` fel az indexelőt	00:01:20
00:01:36	Indexelő végei	00:01:32	A magas vízjel frissül az indexelő aktuális végrehajtásának kezdő időbélyegére.
00:01:40	Az indexelő elindul	00:01:32
00:01:41	Az indexelő lekérdezi a 00:01:02 és 00:01:40 közötti összes módosítást; lekéri `doc2`	00:01:32	Az indexelő az aktuális magas vízjel és a 30 másodperces puffer közötti összes módosításra vonatkozó kérést, valamint az indexelő aktuális végrehajtásának kezdő időbélyegét kéri.
00:01:42	Indexelő folyamatok `doc2` negyedik alkalommal	00:01:32
00:01:43	Indexelő végei	00:01:40	Figyelje meg, hogy ez az indexelő végrehajtása több mint 30 másodperccel azután kezdődött, hogy az utolsó írást az adatforrásba írta, és feldolgozta `doc2`is. Ez a várt viselkedés, mert ha a 00:01:35 előtti összes indexelő-végrehajtás megszűnik, akkor ez lesz az első és egyetlen feldolgozásra váró `doc1` végrehajtás.`doc2`

A gyakorlatban ez a forgatókönyv csak akkor fordul elő, ha az igény szerinti indexelőket manuálisan hívják meg egymástól néhány percen belül bizonyos adatforrások esetében. Ez eltérő számokat eredményezhet (például az indexelő összesen 345 dokumentumot feldolgozott az indexelő végrehajtási statisztikái szerint, de 340 dokumentum található az adatforrásban és az indexben), vagy növelheti a számlázást, ha ugyanazt a képességet többször futtatja ugyanazon dokumentumhoz. Az indexelő ütemezéssel történő futtatása az előnyben részesített javaslat.

Dokumentumok indexelése bizalmassági címkékkel

Ha bizalmassági címkék vannak beállítva a dokumentumokon, előfordulhat, hogy nem tudja indexelni őket. Ha hibaüzenetet kap, az indexelés előtt távolítsa el a címkéket.