Wskazówki dotyczące rozwiązywania problemów z indeksatorem dla usługi Azure AI Search

Od czasu do czasu indeksatory napotkają problemy, które nie generują błędów lub występują w innych usługach platformy Azure, takich jak podczas uwierzytelniania lub podczas nawiązywania połączenia. Ten artykuł koncentruje się na rozwiązywaniu problemów z indeksatorem, gdy nie ma komunikatów, które cię przeprowadzą. Zapewnia również rozwiązywanie problemów z błędami pochodzącymi z zasobów innych niż wyszukiwanie używanych podczas indeksowania.

Uwaga

Jeśli masz błąd usługi Azure AI Search do zbadania, zobacz Rozwiązywanie typowych błędów i ostrzeżeń indeksatora .

Rozwiązywanie problemów z połączeniami z ograniczonymi zasobami

W przypadku źródeł danych w ramach zabezpieczeń sieci platformy Azure indeksatory są ograniczone w sposobie nawiązywania połączenia. Obecnie indeksatory mogą uzyskiwać dostęp do ograniczonych źródeł danych za zaporą IP lub w sieci wirtualnej za pośrednictwem prywatnego punktu końcowego przy użyciu udostępnionego łącza prywatnego.

Reguły zapory

Usługi Azure Storage, Azure Cosmos DB i Azure SQL zapewniają konfigurowalną zaporę. Nie ma określonego komunikatu o błędzie, gdy zapora blokuje żądanie. Zazwyczaj błędy zapory są ogólne. Niektóre typowe błędy to:

• 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

Istnieją dwie opcje zezwalania indeksatorom na dostęp do tych zasobów w takim wystąpieniu:

• Skonfiguruj regułę ruchu przychodzącego dla adresu IP usługi wyszukiwania i zakresu adresów IP tagu AzureCognitiveSearchusługi. Szczegółowe informacje dotyczące konfigurowania ograniczeń zakresu adresów IP dla każdego typu źródła danych można znaleźć pod następującymi linkami:

  • Azure Storage
  • Azure Cosmos DB
  • Azure SQL

• W ostateczności lub jako środek tymczasowy wyłącz zaporę, zezwalając na dostęp ze wszystkich sieci.

Ograniczenie: Ograniczenia zakresu adresów IP działają tylko wtedy, gdy usługa wyszukiwania i konto magazynu znajdują się w różnych regionach.

Oprócz pobierania danych indeksatory wysyłają również żądania wychodzące za pośrednictwem zestawów umiejętności i umiejętności niestandardowych. W przypadku umiejętności niestandardowych opartych na funkcji platformy Azure należy pamiętać, że funkcje platformy Azure mają również ograniczenia adresów IP. Lista adresów IP umożliwiających wykonywanie niestandardowych umiejętności obejmuje adres IP usługi wyszukiwania i zakres adresów IP tagu AzureCognitiveSearch usługi.

Problemy dotyczące reguł sieciowej grupy zabezpieczeń (NSG)

Gdy indeksator uzyskuje dostęp do danych w wystąpieniu zarządzanym SQL lub gdy maszyna wirtualna platformy Azure jest używana jako identyfikator URI usługi internetowej dla umiejętności niestandardowych, sieciowa grupa zabezpieczeń określa, czy żądania są dozwolone.

W przypadku zasobów zewnętrznych znajdujących się w sieci wirtualnej skonfiguruj przychodzące reguły sieciowej grupy zabezpieczeń dla tagu AzureCognitiveSearch usługi.

Aby uzyskać więcej informacji na temat nawiązywania połączenia z maszyną wirtualną, zobacz Konfigurowanie połączenia z programem SQL Server na maszynie wirtualnej platformy Azure.

Błędy sieci

Zazwyczaj błędy sieci są ogólne. Niektóre typowe błędy to:

• 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

Po otrzymaniu dowolnego z tych błędów:

• Upewnij się, że źródło jest dostępne, próbując połączyć się z nim bezpośrednio, a nie za pośrednictwem usługi wyszukiwania
• Sprawdź zasób w witrynie Azure Portal pod kątem bieżących błędów lub awarii
• Sprawdzanie awarii sieci w stanie platformy Azure
• Sprawdź, czy używasz publicznego systemu DNS do rozpoznawania nazw, a nie usługi Azure Prywatna strefa DNS

Indeksowanie bezserwerowe usługi Azure SQL Database (kod błędu 40613)

Jeśli baza danych SQL znajduje się w bezserwerowej warstwie obliczeniowej, upewnij się, że baza danych jest uruchomiona (i nie jest wstrzymana), gdy indeksator łączy się z nią.

Jeśli baza danych jest wstrzymana, oczekuje się, że pierwsze logowanie z usługi wyszukiwania spowoduje automatyczne wznowienie bazy danych, ale zamiast tego zwraca błąd informujący, że baza danych jest niedostępna, podając kod błędu 40613. Po uruchomieniu bazy danych spróbuj ponownie zalogować się, aby nawiązać łączność.

Zasady dostępu warunkowego do usługi Microsoft Entra

Podczas tworzenia indeksatora usługi SharePoint Online następuje krok wymagający zalogowania się do aplikacji Microsoft Entra po podaniu kodu urządzenia. Jeśli zostanie wyświetlony komunikat z "Your sign-in was successful but your admin requires the device requesting access to be managed"komunikatem , indeksator prawdopodobnie zostanie zablokowany z biblioteki dokumentów programu SharePoint przez zasady dostępu warunkowego.

Aby zaktualizować zasady i zezwolić indeksatorowi na dostęp do biblioteki dokumentów:

1. Otwórz witrynę Azure Portal i wyszukaj pozycję Dostęp warunkowy firmy Microsoft Entra.

2. Wybierz pozycję Zasady w menu po lewej stronie. Jeśli nie masz dostępu do wyświetlania tej strony, musisz znaleźć osobę, która ma dostęp lub uzyskać dostęp.

3. Ustal, które zasady blokują indeksatorowi usługi SharePoint Online dostęp do biblioteki dokumentów. Zasady, które mogą blokować indeksator, obejmują konto użytkownika użyte do uwierzytelniania podczas kroku tworzenia indeksatora w sekcji Użytkownicy i grupy . Zasady mogą również mieć warunki , które:

   • Ogranicz platformy systemu Windows .
   • Ogranicz aplikacje mobilne i klientów stacjonarnych.
   • Skonfigurowano stan urządzenia na wartość Tak.

4. Po potwierdzeniu, które zasady blokują indeksator, utwórz wykluczenie dla indeksatora. Zacznij od pobrania adresu IP usługi wyszukiwania.

   Najpierw uzyskaj w pełni kwalifikowaną nazwę domeny (FQDN) usługi wyszukiwania. Nazwa FQDN wygląda następująco: <your-search-service-name>.search.windows.net. Nazwę FQDN można znaleźć w witrynie Azure Portal.

   

   Teraz, gdy masz nazwę FQDN, pobierz adres IP usługi wyszukiwania, wykonując nslookup wartość (lub ) pingnazwy FQDN. W poniższym przykładzie do reguły ruchu przychodzącego w zaporze usługi Azure Storage zostanie dodana wartość "150.0.0.1". Może upłynąć do 15 minut po zaktualizowaniu ustawień zapory, aby indeksator usługi wyszukiwania mógł uzyskać dostęp do konta usługi 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
   

5. Pobierz zakresy adresów IP dla środowiska wykonywania indeksatora dla twojego regionu.

   Dodatkowe adresy IP są używane w przypadku żądań pochodzących z wielodostępnego środowiska wykonywania indeksatora. Ten zakres adresów IP można uzyskać z tagu usługi.

   Zakresy adresów IP dla tagu usługi można uzyskać za pośrednictwem interfejsu AzureCognitiveSearchAPI odnajdywania lub pliku JSON do pobrania.

   W tym ćwiczeniu przy założeniu, że usługa wyszukiwania jest chmurą publiczną platformy Azure, należy pobrać plik JSON platformy Azure.

   

   W pliku JSON przy założeniu, że usługa wyszukiwania znajduje się w regionie Zachodnio-środkowe stany USA, lista adresów IP dla wielodostępnego środowiska wykonywania indeksatora znajduje się poniżej.

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

6. Po powrocie na stronę Dostęp warunkowy w witrynie Azure Portal wybierz pozycję Nazwane lokalizacje z menu po lewej stronie, a następnie wybierz pozycję + Lokalizacje zakresów adresów IP. Nadaj nowej nazwie lokalizacji nazwę i dodaj zakresy adresów IP dla usługi wyszukiwania i środowisk wykonywania indeksatora zebranych w dwóch ostatnich krokach. 1

   • W przypadku adresu IP usługi wyszukiwania może być konieczne dodanie adresu "/32" na końcu adresu IP, ponieważ akceptuje tylko prawidłowe zakresy adresów IP.
   • Należy pamiętać, że w przypadku zakresów adresów IP środowiska wykonywania indeksatora należy dodać tylko zakresy adresów IP dla regionu, w którym znajduje się usługa wyszukiwania.

7. Wyklucz nową nazwaną lokalizację z zasad:

   1. Wybierz pozycję Zasady w menu po lewej stronie.
   2. Wybierz zasady blokujące indeksator.
   3. Wybierz pozycję Warunki.
   4. Wybierz pozycję Lokalizacje.
   5. Wybierz pozycję Wyklucz , a następnie dodaj nową lokalizację nazwaną.
   6. Zapisz zmiany.

8. Poczekaj kilka minut na zaktualizowanie zasad i wymuszenie nowych reguł zasad.

9. Spróbuj ponownie utworzyć indeksator:

   1. Wyślij żądanie aktualizacji dla utworzonego obiektu źródła danych.
   2. Wyślij ponownie żądanie utworzenia indeksatora. Użyj nowego kodu, aby się zalogować, a następnie wyślij kolejne żądanie utworzenia indeksatora.

Indeksowanie nieobsługiwanych typów dokumentów

Jeśli indeksujesz zawartość z usługi Azure Blob Storage, a kontener zawiera obiekty blob nieobsługiwanego typu zawartości, indeksator pomija ten dokument. W innych przypadkach mogą występować problemy z poszczególnymi dokumentami.

W takiej sytuacji można ustawić opcje konfiguracji, aby umożliwić kontynuowanie przetwarzania indeksatora w przypadku problemów z poszczególnymi dokumentami.

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

Brakujące dokumenty

Indeksatory wyodrębniają dokumenty lub wiersze z zewnętrznego źródła danych i tworzą dokumenty wyszukiwania, które są następnie indeksowane przez usługę wyszukiwania. Czasami dokument, który istnieje w źródle danych, nie może pojawić się w indeksie wyszukiwania. Ten nieoczekiwany wynik może wystąpić z następujących powodów:

• Dokument został zaktualizowany po uruchomieniu indeksatora. Jeśli indeksator jest zgodnie z harmonogramem, w końcu ponownie uruchamia i pobiera dokument.
• Upłynął limit czasu indeksatora, zanim dokument będzie mógł zostać pozyskany. Istnieją maksymalne limity czasu przetwarzania, po których żadne dokumenty nie są przetwarzane. Stan indeksatora można sprawdzić w portalu lub wywołując polecenie Pobierz stan indeksatora (interfejs API REST).
• Mapowania pól lub wzbogacanie sztucznej inteligencji zmieniły dokument, a jego artykulacja w indeksie wyszukiwania różni się od oczekiwanego.
• Brak wartości śledzenia zmian lub brakuje wymagań wstępnych. Jeśli wartość wysokiego limitu jest datą ustawioną na czas przyszły, wszystkie dokumenty, które mają wcześniejszą datę, zostaną pominięte przez indeksator. Stan śledzenia zmian indeksatora można określić przy użyciu pól "initialTrackingState" i "finalTrackingState" w stanie indeksatora. Indeksatory dla usług Azure SQL i MySQL muszą mieć indeks w kolumnie górnego znaku wodnego tabeli źródłowej lub zapytania używane przez indeksator mogą przekraczać limit czasu.

Napiwek

Jeśli brakuje dokumentów, sprawdź zapytanie , którego używasz, aby upewnić się, że nie wyklucza on danego dokumentu. Aby utworzyć zapytanie dotyczące określonego dokumentu, użyj interfejsu API REST wyszukiwania dokumentów.

Brak zawartości z usługi Blob Storage

Indeksator obiektów blob znajduje i wyodrębnia tekst z obiektów blob w kontenerze. Niektóre problemy z wyodrębnianiem tekstu obejmują:

• Dokument zawiera tylko zeskanowane obrazy. Obiekty blob PDF, które mają zawartość nietekstową, takie jak zeskanowane obrazy (JPG), nie generują wyników w standardowym potoku indeksowania obiektów blob. Jeśli masz zawartość obrazu z elementami tekstowymi, możesz użyć funkcji OCR lub analizy obrazów, aby znaleźć i wyodrębnić tekst.

• Indeksator obiektów blob jest skonfigurowany tylko do indeksowania metadanych. Aby wyodrębnić zawartość, indeksator obiektów blob musi być skonfigurowany do wyodrębniania zawartości i metadanych:

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

Brak zawartości z usługi Azure Cosmos DB

Usługa Azure AI Search ma niejawną zależność od indeksowania usługi Azure Cosmos DB. Jeśli wyłączysz automatyczne indeksowanie w usłudze Azure Cosmos DB, usługa Azure AI Search zwróci stan powodzenia, ale nie może indeksować zawartości kontenera. Aby uzyskać instrukcje dotyczące sprawdzania ustawień i włączania indeksowania, zobacz Zarządzanie indeksowaniem w usłudze Azure Cosmos DB.

Rozbieżność liczby dokumentów między źródłem danych a indeksem

Indeksator może wyświetlać inną liczbę dokumentów niż źródło danych, sam indeks lub liczba w kodzie. Oto kilka możliwych powodów, dla których takie zachowanie może wystąpić:

• Indeks może opóźnić wyświetlanie rzeczywistej liczby dokumentów, szczególnie w portalu.
• Indeksator ma usunięte zasady dokumentu. Usunięte dokumenty są liczone przez indeksator, jeśli dokumenty są indeksowane przed usunięciem.
• Jeśli kolumna ID w źródle danych nie jest unikatowa. Dotyczy to źródeł danych, które mają pojęcie kolumn, takich jak usługa Azure Cosmos DB.
• Jeśli definicja źródła danych ma inne zapytanie niż to, którego używasz do oszacowania liczby rekordów. Na przykład w bazie danych wysyłasz zapytania dotyczące liczby rekordów bazy danych, podczas gdy w zapytaniu definicji źródła danych możesz wybrać tylko podzbiór rekordów do indeksowania.
• Liczby są sprawdzane w różnych odstępach czasu dla każdego składnika potoku: źródła danych, indeksatora i indeksu.
• Źródło danych zawiera plik mapowany na wiele dokumentów. Ten warunek może wystąpić, gdy indeksowanie obiektów blob i "parsingMode" jest ustawione na jsonArray i jsonLines.

Dokumenty przetwarzane wiele razy

Indeksatory używają konserwatywnej strategii buforowania, aby upewnić się, że każdy nowy i zmieniony dokument w źródle danych jest pobierany podczas indeksowania. W niektórych sytuacjach bufory te mogą się nakładać, powodując indeksator indeksatora dwa lub więcej razy, co powoduje, że liczba przetworzonych dokumentów jest większa niż rzeczywista liczba dokumentów w źródle danych. To zachowanie nie ma wpływu na dane przechowywane w indeksie, takie jak duplikowanie dokumentów, tylko to, że osiągnięcie spójności ostatecznej może potrwać dłużej. Ten warunek jest szczególnie powszechny, jeśli którekolwiek z następujących kryteriów są spełnione:

• Żądania indeksatora na żądanie są wydawane w krótkim odstępie czasu
• Topologia źródła danych zawiera wiele replik i partycji (omówiono w tym przykładzie)
• Źródło danych jest bazą danych Azure SQL Database, a kolumna wybrana jako "wysoki znak wodny" jest typu datetime2

Indeksatory nie mają być wywoływane wielokrotnie w krótkim odstępie czasu. Jeśli potrzebujesz aktualizacji szybko, obsługiwaną metodą jest wypychanie aktualizacji do indeksu podczas jednoczesnego aktualizowania źródła danych. W przypadku przetwarzania na żądanie zalecamy tempo żądań w odstępach co najmniej pięciu minut i uruchamianie indeksatora zgodnie z harmonogramem.

Przykład zduplikowanego przetwarzania dokumentów z buforem 30 sekund

Warunki, w których dokument jest przetwarzany dwa razy, wyjaśniono na poniższej osi czasu, które zauważają każdą akcję i akcję licznika. Na poniższej osi czasu przedstawiono problem:

Oś czasu (hh:mm:ss)	Zdarzenie	Wskaźnik wysokiej wody indeksatora	Komentarz
00:01:00	Zapisywanie doc1 w źródle danych ze spójnością ostateczną	null	Sygnatura czasowa dokumentu to 00:01:00.
00:01:05	Zapisywanie doc2 w źródle danych ze spójnością ostateczną	null	Sygnatura czasowa dokumentu to 00:01:05.
00:01:10	Indeksator uruchamia	null
00:01:11	Indeksator wykonuje zapytania dotyczące wszystkich zmian przed 00:01:10; replika, z którą zapytania indeksatora są uwzględniane tylko w doc2przypadku ; pobierana jest tylko doc2 replika	null	Indeksator żąda wszystkich zmian przed rozpoczęciem znacznika czasu, ale faktycznie otrzymuje podzbiór. To zachowanie wymaga okresu buforu wyszukiwania wstecz.
00:01:12	Indeksator przetwarza doc2 po raz pierwszy	null
00:01:13	Końce indeksatora	00:01:10	Wysoki limit wody jest aktualizowany do znacznika czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:20	Indeksator uruchamia	00:01:10
00:01:21	Indeksator wykonuje zapytania dotyczące wszystkich zmian z zakresu od 00:00:40 do 00:01:20; replika, z którą wykonuje się zapytania indeksatora, jest świadoma zarówno funkcji , jak doc1 i doc2; pobiera doc1 i doc2	00:01:10	Indeksator żąda wszystkich zmian między bieżącym wysokim znacznikem wody minus 30 sekund buforu i znacznik czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:22	Indeksator przetwarza doc1 po raz pierwszy	00:01:10
00:01:23	Proces doc2 indeksatora po raz drugi	00:01:10
00:01:24	Końce indeksatora	00:01:20	Wysoki limit wody jest aktualizowany do znacznika czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:32	Indeksator uruchamia	00:01:20
00:01:33	Indeksator wykonuje zapytania dotyczące wszystkich zmian z zakresu od 00:00:50 do 00:01:32; pobiera doc1 i doc2	00:01:20	Indeksator żąda wszystkich zmian między bieżącym wysokim znacznikem wody minus 30 sekund buforu i znacznik czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:34	Proces doc1 indeksatora po raz drugi	00:01:20
00:01:35	Proces indeksatora doc2 po raz trzeci	00:01:20
00:01:36	Końce indeksatora	00:01:32	Wysoki limit wody jest aktualizowany do znacznika czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:40	Indeksator uruchamia	00:01:32
00:01:41	Indeksator wykonuje zapytania dotyczące wszystkich zmian z zakresu od 00:01:02 do 00:01:40; Pobiera doc2	00:01:32	Indeksator żąda wszystkich zmian między bieżącym wysokim znacznikem wody minus 30 sekund buforu i znacznik czasu rozpoczęcia bieżącego wykonywania indeksatora.
00:01:42	Indeksator przetwarza doc2 po raz czwarty	00:01:32
00:01:43	Końce indeksatora	00:01:40	Zwróć uwagę, że wykonanie indeksatora rozpoczęło się ponad 30 sekund po ostatnim zapisie w źródle danych, a także przetworzone doc2. Jest to oczekiwane zachowanie, ponieważ jeśli wszystkie wykonania indeksatora przed 00:01:35 zostaną wyeliminowane, staje się to pierwszym i jedynym wykonaniem do przetworzenia doc1 i doc2.

W praktyce ten scenariusz występuje tylko wtedy, gdy indeksatory na żądanie są wywoływane ręcznie w ciągu kilku minut od siebie w przypadku niektórych źródeł danych. Może to spowodować niezgodność liczb (takich jak indeksator przetworzył 345 dokumentów łącznie zgodnie ze statystykami wykonywania indeksatora, ale istnieje 340 dokumentów w źródle danych i indeksie) lub potencjalnie zwiększone rozliczenia, jeśli używasz tych samych umiejętności dla tego samego dokumentu wiele razy. Uruchamianie indeksatora przy użyciu harmonogramu jest preferowaną rekomendacją.

Indeksowanie dokumentów z etykietami poufności

Jeśli w dokumentach są ustawione etykiety poufności, indeksowanie może nie być możliwe. Jeśli występują błędy, usuń etykiety przed indeksowaniem.

Zobacz też

• Rozwiązywanie typowych błędów i ostrzeżeń indeksatora
• Monitorowanie indeksowania opartego na indeksatorze