Szolgáltatás-felügyelet az Azure Cognitive Search a Azure PortalService administration for Azure Cognitive Search in the Azure portal

Az Azure Cognitive Search egy teljes körűen felügyelt, felhőalapú keresési szolgáltatás, amellyel gazdag keresési élményt hozhat létre egyéni alkalmazásokba.Azure Cognitive Search is a fully managed, cloud-based search service used for building a rich search experience into custom apps. Ez a cikk ismerteti azokat a szolgáltatás-felügyeleti feladatokat, amelyeket elvégezhet a Azure Portalban egy már üzembe helyezett keresési szolgáltatáshoz.This article covers the service administration tasks that you can perform in the Azure portal for a search service that you've already provisioned. A szolgáltatás felügyeletét könnyű megtervezni, a következő feladatokra korlátozódik:Service administration is lightweight by design, limited to the following tasks:

  • Győződjön meg arról, hogy a tároló a középső oldal használati hivatkozását használja.Check storage using the mid-page Usage link.
  • Vizsgálja meg a lekérdezési köteteket és a késést a középső oldal figyelési hivatkozásának használatával, valamint hogy a kérelmek szabályozása megtörtént-e.Check query volumes and latency using the mid-page Monitoring link, and whether requests were throttled.
  • A hozzáférés kezelése a kulcsok oldal bal oldalán.Manage access using the Keys page to the left.
  • Állítsa be a kapacitást a Méretezés lapon balra.Adjust capacity using the Scale page to the left.

A portálon végrehajtott feladatokat a felügyeleti API -k és az az. Search PowerShell-modulhasználatával is lehet programozott módon kezelni.The same tasks performed in the portal can also be handled programmatically through the Management APIs and Az.Search PowerShell module. A felügyeleti feladatok teljes mértékben képviseltetik magukat a portál és a programozott felületek között.Administrative tasks are fully represented across portal and programmatic interfaces. Nincs olyan konkrét felügyeleti feladat, amely csak egy módozatban érhető el.There is no specific administrative task that is available in only one modality.

Az Azure Cognitive Search további Azure-szolgáltatásokat használ a további monitorozáshoz és felügyelethez.Azure Cognitive Search leverages other Azure services for deeper monitoring and management. Önmagában az egyetlen keresési szolgáltatással tárolt adattartalom (indexek, indexelő és adatforrás-definíciók és egyéb objektumok).By itself, the only data stored with a search service is content (indexes, indexer and data source definitions, and other objects). A portál oldalain jelentett mérőszámok a 30 napos időszakon belüli belső naplókból vannak kihúzva.Metrics reported out to portal pages are pulled from internal logs on a rolling 30-day cycle. A felhasználó által vezérelt naplózás és a további események esetében Azure monitorralesz szüksége.For user-controlled log retention and additional events, you will need Azure Monitor.

Rögzített szolgáltatás tulajdonságaiFixed service properties

A keresési szolgáltatás több aspektusa is meg van határozva, ha a szolgáltatás kiépítve lett, és később nem módosítható:Several aspects of a search service are determined when the service is provisioned and cannot be changed later:

  • Szolgáltatás neve (a szolgáltatás nem nevezhető át)Service name (you cannot rename a service)
  • Szolgáltatás helye (jelenleg nem helyezhető át egy érintetlen szolgáltatás egy másik régióba)Service location (you cannot currently move an intact service to another region)
  • A replika és a partíciók maximális száma (a szint, az alapszintű vagy a standard alapján meghatározva)Maximum replica and partition counts (determined by the tier, Basic or Standard)

Ha az alapszintű és egy partícióval rendelkezik, és most már több partícióra van szüksége, új szolgáltatást kell létrehoznia egy magasabb szintű szinten, és újra létre kell hoznia a tartalmat az új szolgáltatáson.If you started with Basic with its maximum of one partition, and you now need more partitions, you will need to create a new service at a higher tier and recreate your content on the new service.

Rendszergazdai jogosultságokAdministrator rights

A szolgáltatás kiépítés vagy leszerelése egy Azure-előfizetés rendszergazdája vagy egy társ-rendszergazda által végezhető el.Provisioning or decommissioning the service itself can be done by an Azure subscription administrator or co-administrator.

A végponthoz való hozzáférés tekintetében bárki hozzáférhet a szolgáltatás URL-címéhez, és egy API-kulcs hozzáfér a tartalomhoz.Regarding access to the endpoint, anyone with access to the service URL and an api-key has access to content. A kulcsokkal kapcsolatos további információkért lásd: az API-kulcsok kezelése.For more information about keys, see Manage the api-keys.

  • A szolgáltatáshoz csak olvasási hozzáférés van lekérdező jogosultság, amelyet általában egy ügyfélalkalmazás biztosít az URL-cím és a lekérdezési API-kulcs megadásával.Read-only access to the service is query rights, typically granted to a client application by giving it the URL and a query api-key.
  • Az írási és olvasási hozzáférés lehetővé teszi a kiszolgálói objektumok hozzáadását, törlését és módosítását, beleértve az API-kulcsokat, az indexeket, az indexelő, az adatforrásokat és az ütemterveket. Az olvasási és írási hozzáférés az URL-cím, egy rendszergazdai API-kulcs megadásával adható meg.Read-write access provides the ability to add, delete, or modify server objects, including api-keys, indexes, indexers, data sources, and schedules.Read-write access is granted by giving the URL, an admin API key.

A szolgáltatás kiépítési berendezéséhez szükséges jogosultságokat a szerepkör-hozzárendelések biztosítják.Rights to the service provisioning apparatus is granted through role assignments. Az Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC) az Azure-erőforrások kiépítésére Azure Resource Manager épülő engedélyezési rendszer.Azure role-based access control (Azure RBAC) is an authorization system built on Azure Resource Manager for provisioning of Azure resources.

Az Azure Cognitive Search kontextusában az Azure szerepkör-hozzárendelések határozzák meg, hogy ki végezhet el feladatokat, függetlenül attól, hogy a portált, a PowerShelltvagy a felügyeleti REST API-kathasználják:In the context of Azure Cognitive Search, Azure role assignments will determine who can perform tasks, regardless of whether they are using the portal, PowerShell, or the Management REST APIs:

  • Szolgáltatás létrehozása vagy törléseCreate or delete a service
  • A szolgáltatás skálázásaScale the service
  • API-kulcsok törlése vagy újragenerálásaDelete or regenerate API keys
  • Diagnosztikai naplózás engedélyezése (szolgáltatások létrehozása)Enable diagnostic logging (create services)
  • Traffic Analytics engedélyezése (szolgáltatások létrehozása)Enable traffic analytics (create services)

Tipp

Az Azure-ra kiterjedő mechanizmusok használatával zárolhatja az előfizetést vagy az erőforrást, így megakadályozhatja a keresési szolgáltatás véletlen vagy jogosulatlan törlését rendszergazdai jogosultságokkal rendelkező felhasználók számára.Using Azure-wide mechanisms, you can lock a subscription or resource to prevent accidental or unauthorized deletion of your search service by users with admin rights. További információ: erőforrások zárolása a váratlan törlés megakadályozása érdekében.For more information, see Lock resources to prevent unexpected deletion.

Naplózási és rendszerinformációkLogging and system information

Az alapszintű és újabb verziók esetében a Microsoft minden Azure Cognitive Search-szolgáltatást az 99,9%-os rendelkezésre állást figyeli a szolgáltatói szerződések (SLA) esetében.At the Basic tier and above, Microsoft monitors all Azure Cognitive Search services for 99.9% availability per service level agreements (SLA). Ha a szolgáltatás lassú, vagy az átviteli sebesség az SLA-küszöbérték alá esik, a támogatási csapatoknak tekintse át a rendelkezésre álló naplófájlokat, és foglalkozzon a probléma megoldásával.If the service is slow or request throughput falls below SLA thresholds, support teams review the log files available to them and address the issue.

Az Azure Cognitive Search az indexelési és lekérdezési tevékenységek gyűjtésére és tárolására Azure monitor használ.Azure Cognitive Search leverages Azure Monitor to collect and store indexing and query activity. A keresési szolgáltatás önmagában csak a tartalmát tárolja (indexek, indexelő definíciók, adatforrás-definíciók, készségkészlet-definíciók, szinonimák leképezései).A search service by itself stores just its content (indexes, indexer definitions, data source definitions, skillset definitions, synonym maps). A gyorsítótárazás és a naplózott adatok a szolgáltatáson kívül, gyakran egy Azure Storage-fiókban tárolódnak.Caching and logged information is stored off-service, often in an Azure Storage account. Az indexelési és lekérdezési számítási feladatok naplózásával kapcsolatos további információkért lásd: naplózási adatok gyűjtése és elemzése.For more information about logging indexing and query workloads, see Collect and analyze log data.

A szolgáltatással kapcsolatos általános információk alapján az Azure Cognitive Search beépített szolgáltatásainak használatával a következő módokon szerezheti be az információkat:In terms of general information about your service, using just the facilities built into Azure Cognitive Search itself, you can obtain information in the following ways:

Erőforrás-használat figyeléseMonitor resource usage

Az irányítópulton az erőforrás-figyelés a szolgáltatás irányítópultján megjelenő információkra korlátozódik, és néhány mérőszámot, amelyet a szolgáltatás lekérdezésével érhet el.In the dashboard, resource monitoring is limited to the information shown in the service dashboard and a few metrics that you can obtain by querying the service. A szolgáltatás irányítópultjának használat szakaszában gyorsan meghatározhatja, hogy a partíciós erőforrások szintje megfelelő-e az alkalmazáshoz.On the service dashboard, in the Usage section, you can quickly determine whether partition resource levels are adequate for your application. Ha a naplózott eseményeket szeretné rögzíteni és megőrizni, külső erőforrásokat (például az Azure-figyelést) is kiépítheti.You can provision external resources, such as Azure monitoring, if you want to capture and persist logged events. További információ: az Azure Cognitive Search figyelése.For more information, see Monitoring Azure Cognitive Search.

A Search szolgáltatás REST API használatával a dokumentumok és indexek száma programozott módon is elvégezhető:Using the search service REST API, you can get a count on documents and indexes programmatically:

Vész-helyreállítási és szolgáltatás-kimaradásokDisaster recovery and service outages

Bár az adatai megmentését is lehetővé teszi, az Azure Cognitive Search nem biztosítja a szolgáltatás azonnali feladatátvételét, ha a fürt vagy az adatközpont szintjén áramkimaradás történik.Although we can salvage your data, Azure Cognitive Search does not provide instant failover of the service if there is an outage at the cluster or data center level. Ha egy fürt meghibásodik az adatközpontban, az operatív csapat felismeri és a szolgáltatás visszaállítását végzi.If a cluster fails in the data center, the operations team will detect and work to restore service. A szolgáltatás visszaállítása során állásidőt tapasztalhat, de a szolgáltatási kreditek igénylésével kompenzálhatja a szolgáltatás nem rendelkezésre állását a szolgáltatói szerződés (SLA).You will experience downtime during service restoration, but you can request service credits to compensate for service unavailability per the Service Level Agreement (SLA).

Ha a Microsoft általi ellenőrzésen kívüli katasztrofális hibák esetén folyamatos szolgáltatásra van szükség, egy másik régióban is kiépítheti a további szolgáltatásokat, és a Geo-replikációs stratégia megvalósításával biztosíthatja, hogy az indexek teljes mértékben redundánsak legyenek az összes szolgáltatásban.If continuous service is required in the event of catastrophic failures outside of Microsoft’s control, you could provision an additional service in a different region and implement a geo-replication strategy to ensure indexes are fully redundant across all services.

Azok az ügyfelek, akik Indexelő adatokat használnak az indexek feltöltéséhez és frissítéséhez, az azonos adatforrást használó geo-specifikus indexelő segítségével kezelhetik a vész-helyreállítást.Customers who use indexers to populate and refresh indexes can handle disaster recovery through geo-specific indexers leveraging the same data source. A különböző régiókban található két szolgáltatás, amelyek mindegyike indexelt, indexelheti ugyanazt az adatforrást a Geo-redundancia eléréséhez.Two services in different regions, each running an indexer, could index the same data source to achieve geo-redundancy. Ha olyan adatforrásokból származó indexelést is használ, amelyek földrajzilag redundánsak, vegye figyelembe, hogy az Azure Cognitive Search indexelő csak növekményes indexelést végezhetnek (új, módosított vagy törölt dokumentumokból származó frissítések egyesítése) az elsődleges replikából.If you are indexing from data sources that are also geo-redundant, be aware that Azure Cognitive Search indexers can only perform incremental indexing (merging updates from new, modified, or deleted documents) from primary replicas. Feladatátvételi esemény esetén ügyeljen arra, hogy az indexelő újra az új elsődleges replikára irányítsa.In a failover event, be sure to re-point the indexer to the new primary replica.

Ha nem használ indexelő funkciót, az alkalmazás kódjával párhuzamosan küldheti el az objektumokat és az adatait a különböző keresési szolgáltatásoknak.If you do not use indexers, you would use your application code to push objects and data to different search services in parallel. További információ: teljesítmény és optimalizálás az Azure Cognitive Searchban.For more information, see Performance and optimization in Azure Cognitive Search.

Biztonsági mentés és visszaállításBackup and restore

Mivel az Azure Cognitive Search nem elsődleges adattárolási megoldás, nem biztosítunk formális mechanizmust az önkiszolgáló biztonsági mentéshez és visszaállításhoz.Because Azure Cognitive Search is not a primary data storage solution, we do not provide a formal mechanism for self-service backup and restore. Az Azure Cognitive Search .net minta -tárházban található index-Backup-Restore mintakód használatával azonban az index definícióját és a pillanatképet egy sor JSON-fájlra is felhasználhatja, majd ezekkel a fájlokkal visszaállíthatja az indexet, ha szükséges.However, you can use the index-backup-restore sample code in this Azure Cognitive Search .NET sample repo to backup your index definition and snapshot to a series of JSON files, and then use these files to restore the index, if needed. Ez az eszköz az indexeket is át tudja helyezni a szolgáltatási szintek között.This tool can also move indexes between service tiers.

Ellenkező esetben az index létrehozásához és feltöltéséhez használt alkalmazás kódja a de facto Visszaállítási lehetőség, ha tévedésből töröl egy indexet.Otherwise, your application code used for creating and populating an index is the de facto restore option if you delete an index by mistake. Az indexek újraépítéséhez törölnie kell azt (feltéve, hogy létezik), újra létre kell hoznia az indexet a szolgáltatásban, majd újra kell töltenie az adatok elsődleges adattárból való beolvasásával.To rebuild an index, you would delete it (assuming it exists), recreate the index in the service, and reload by retrieving data from your primary data store.

Vertikális fel- és leskálázásScale up or down

Minden keresési szolgáltatás legalább egy replikával és egy partícióval indul el.Every search service starts with a minimum of one replica and one partition. Ha olyan platformra regisztrált, amely támogatja a nagyobb kapacitást, kattintson a bal oldali navigációs ablaktábla Méretezés elemére az erőforrás-használat módosításához.If you signed up for a tier that supports more capacity, click Scale on the left navigation pane to adjust resource usage.

Ha erőforráson keresztül ad hozzá kapacitást, a szolgáltatás automatikusan ezeket használja.When you add capacity through either resource, the service uses them automatically. Az Ön részéről nincs szükség további műveletre, de az új erőforrás hatásának megvalósulása némi késéssel jár.No further action is required on your part, but there is a slight delay before the impact of the new resource is realized. További erőforrások kiépítéséhez akár 15 percet is igénybe vehet.It can take 15 minutes or more to provision additional resources.

Replikák hozzáadásaAdd replicas

A lekérdezések másodpercenkénti száma (QPS) vagy a magas rendelkezésre állás elérése a replikák hozzáadásával történik.Increasing queries per second (QPS) or achieving high availability is done by adding replicas. Minden replika egyetlen másolattal rendelkezik egy indexből, így a szolgáltatás lekérdezési kéréseinek kiszolgálásához még egy replika hozzáadására van lehetőség.Each replica has one copy of an index, so adding one more replica translates to one more index available for handling service query requests. A magas rendelkezésre álláshoz legalább 3 replika szükséges (lásd: a kapacitás módosítása a részletekhez).A minimum of 3 replicas are required for high availability (see Adjust capacity for details).

A több replikát tartalmazó keresési szolgáltatás a lekérdezési kérelmeket nagyobb számú indexnél tudja betölteni.A search service having more replicas can load balance query requests over a larger number of indexes. A lekérdezési mennyiség szintje miatt a lekérdezési átviteli sebesség gyorsabb lesz, ha a kérés kiszolgálásához több példány is rendelkezésre áll az indexben.Given a level of query volume, query throughput is going to be faster when there are more copies of the index available to service the request. Ha a lekérdezés késését tapasztalja, pozitív hatással lehet a teljesítményre, ha a további replikák online állapotban vannak.If you are experiencing query latency, you can expect a positive impact on performance once the additional replicas are online.

Bár a lekérdezési átviteli sebesség a replikák hozzáadásakor leáll, a replikák szolgáltatáshoz való hozzáadásakor nem lehet pontosan dupla vagy tripla.Although query throughput goes up as you add replicas, it does not precisely double or triple as you add replicas to your service. Az összes keresési alkalmazásra olyan külső tényezők vonatkoznak, amelyek hatással lehetnek a lekérdezési teljesítményre.All search applications are subject to external factors that can impinge on query performance. Az összetett lekérdezések és a hálózati késés két tényező, amelyek hozzájárulnak a lekérdezési válaszidő változásaihoz.Complex queries and network latency are two factors that contribute to variations in query response times.

Partíciók hozzáadásaAdd partitions

Sokkal gyakoribb a replikák hozzáadása, de ha korlátozott a tárterület, hozzáadhat partíciókat, amelyekkel nagyobb kapacitást érhet el.It's more common to add replicas, but when storage is constrained, you can add partitions to get more capacity. A szolgáltatás kiépített szintje határozza meg, hogy a partíciók hozzáadhatók-e.The tier at which you provisioned the service determines whether partitions can be added. Az alapszintű csomag egyetlen partíción van zárolva.The Basic tier is locked at one partition. A standard szintű csomagok és a fenti csomagok további partíciókat is támogatnak.Standard tiers and above support additional partitions.

A partíciók 12 (konkrét, 1, 2, 3, 4, 6 vagy 12) osztóban lesznek hozzáadva.Partitions are added in divisors of 12 (specifically, 1, 2, 3, 4, 6, or 12). Ez egy horizontális skálázási összetevő.This is an artifact of sharding. Az indexek 12 szegmensben jönnek létre, amelyek mindegyike 1 partíción tárolható, vagy egyenlően 2, 3, 4, 6 vagy 12 partícióra osztható (egy-egy szegmens/partíció).An index is created in 12 shards, which can all be stored on 1 partition or equally divided into 2, 3, 4, 6, or 12 partitions (one shard per partition).

Replikák eltávolításaRemove replicas

A nagy mennyiségű lekérdezési kötetek után a csúszka segítségével csökkentheti a replikákat a keresési lekérdezés terhelésének normalizálása után (például az üdülési értékesítések felett).After periods of high query volumes, you can use the slider to reduce replicas after search query loads have normalized (for example, after holiday sales are over). Az Ön részéről nincs szükség további lépésekre.There are no further steps required on your part. A replikák számának csökkentése lemond az adatközpontban található virtuális gépekről.Lowering the replica count relinquishes virtual machines in the data center. A lekérdezési és az adatfeldolgozási műveletek mostantól kevesebb virtuális gépen futnak, mint korábban.Your query and data ingestion operations will now run on fewer VMs than before. A minimális követelmény egy replika.The minimum requirement is one replica.

Partíciók eltávolításaRemove partitions

A replikák eltávolításával szemben, amelyhez nincs szükség további erőfeszítésre, előfordulhat, hogy néhány teendője van, ha több tárterületet használ, mint amennyit csökkenteni lehet.In contrast with removing replicas, which requires no extra effort on your part, you might have some work to do if you are using more storage than can be reduced. Ha például a megoldás három partíciót használ, az egy vagy két partícióra való leépítés hibát eredményez, ha az új tárolóhely kisebb, mint az index üzemeltetéséhez szükséges.For example, if your solution is using three partitions, downsizing to one or two partitions will generate an error if the new storage space is less than required for hosting your index. Az elvárásoknak megfelelően lehetőség van az indexek vagy dokumentumok törlésére egy társított indexen belül, hogy felszabadítsa a helyet, vagy megtartja a jelenlegi konfigurációt.As you might expect, your choices are to delete indexes or documents within an associated index to free up space, or keep the current configuration.

Nincs olyan észlelési módszer, amely közli, hogy mely indexek vannak tárolva egy adott partíción.There is no detection method that tells you which index shards are stored on specific partitions. Az egyes partíciók körülbelül 25 GB tárhelyet biztosítanak, ezért a tárterületet a szükséges partíciók számával kell csökkenteni.Each partition provides approximately 25 GB in storage, so you will need to reduce storage to a size that can be accommodated by the number of partitions you have. Ha egy partícióra kíván visszaállítani, akkor mind a 12 szegmensnek el kell férnie.If you want to revert to one partition, all 12 shards will need to fit.

Ha segítségre van szüksége a jövőbeli tervezéssel kapcsolatban, érdemes lehet megtekinteni a tárterületet (az indexek statisztikájának lekérésehasználatával), hogy megtekintse, mennyit használtTo help with future planning, you might want to check storage (using Get Index Statistics) to see how much you actually used.

Következő lépésekNext steps