Sdílet prostřednictvím


Konfigurace místního prostředí Integration Runtime (SHIR) pro shromažďování log Analytics

PLATÍ PRO: Azure Data Factory Azure Synapse Analytics

Tip

Vyzkoušejte si službu Data Factory v Microsoft Fabric, řešení pro analýzy typu all-in-one pro podniky. Microsoft Fabric zahrnuje všechno od přesunu dat až po datové vědy, analýzy v reálném čase, business intelligence a vytváření sestav. Přečtěte si, jak začít používat novou zkušební verzi zdarma.

Požadavky

Pro tento přístup se vyžaduje dostupný pracovní prostor služby Log Analytics. Doporučujeme si poznamenejte ID pracovního prostoru a ověřovací klíč pracovního prostoru služby Log Analytics, protože ho možná budete potřebovat pro určité scénáře. Toto řešení zvýší data odesílaná do pracovního prostoru služby Log Analytics a bude mít malý dopad na celkové náklady. Přečtěte si podrobnosti o tom, jak zachovat minimální množství dat.

Cíle a scénáře

Centralizace událostí a dat čítače výkonu do pracovního prostoru služby Log Analytics, nejprve musí být odpovídajícím instrumentovaným virtuálním počítačem, který je hostitelem SHIR. Vyberte si mezi dvěma hlavními scénáři níže.

Instrumentace místních virtuálních počítačů

Článek Instalace agenta Log Analytics na počítačích s Windows popisuje, jak nainstalovat klienta na virtuální počítač, který je obvykle hostovaný místně. Může to být fyzický server nebo virtuální počítač hostovaný na hypervisoru spravovaném zákazníkem. Jak je uvedeno v části předpokladů, při instalaci agenta Log Analytics budete muset zadat ID pracovního prostoru služby Log Analytics a klíč pracovního prostoru pro dokončení připojení.

Instrumentace virtuálních počítačů Azure

Doporučeným přístupem k instrumentaci služby SHIR založeného na virtuálních počítačích Azure je použití přehledů virtuálních počítačů, jak je popsáno v článku Povolení přehledů virtuálních počítačů. Agenta Log Analytics můžete nakonfigurovat několika způsoby, když je prostředí SHIR hostované na virtuálním počítači Azure. Všechny možnosti jsou popsané v článku Přehled agenta Log Analytics.

Konfigurace protokolu událostí a zachycení čítače výkonu

Tento krok zvýrazní, jak nakonfigurovat protokoly prohlížeče událostí i čítače výkonu, které se mají odesílat do Log Analytics. Níže popsané kroky jsou běžné bez ohledu na to, jak byl agent nasazen.

Výběr deníků prohlížeče událostí

Nejprve musíte shromáždit deníky prohlížeče událostí relevantní pro prostředí SHIR, jak je popsáno v článku Shromažďování zdrojů dat protokolu událostí Windows pomocí agenta Log Analytics ve službě Azure Monitor.

Je důležité si uvědomit, že při výběru protokolů událostí pomocí rozhraní je normální, že neuvidíte všechny deníky, které mohou existovat na počítači. V tomto seznamu se tedy nezobrazí dva deníky, které potřebujeme pro monitorování SHIR. Pokud zadáte název deníku přesně tak, jak se zobrazí na místním virtuálním počítači, zachytí se a odešle do pracovního prostoru služby Log Analytics.

Název deníku událostí, který musíme nakonfigurovat, jsou:

  • Konektory – Integration Runtime
  • Integration Runtime

Snímek obrazovky s výběrem relevantních protokolů SHIR se zaškrtnutými chybami a upozorněními

Důležité

Když necháte zaškrtnutou úroveň informací , výrazně se zvýší objem dat, pokud máte nasazených mnoho hostitelů SHIR a větší počet kontrol. Důrazně doporučujeme zachovat pouze chybu a upozornění.

Výběr čítačů výkonu

Ve stejném podokně konfigurace můžete kliknutím na čítače výkonu systému Windows vybrat jednotlivé čítače výkonu, které se mají odeslat do log Analytics.

Důležité

Mějte na paměti, že čítače výkonu jsou podle své povahy průběžným datovým proudem. Proto je důležité zvážit dopad shromažďování dat na celkové náklady na nasazení služby Azure Monitor nebo Log Analytics. Pokud není udělen povolený rozpočet pro příjem dat a není povolený a rozpočtován konstantní příjem dat, mělo by být shromažďování čítačů výkonu nakonfigurováno pouze pro definované období, aby bylo možné stanovit směrný plán výkonu.

Při první konfiguraci rozhraní se doporučí navrhovaná sada čítačů. Vyberte ty, které platí pro typ analýzy výkonu, kterou chcete provést. %Procesor a dostupná paměť jsou běžně monitorované čítače, ale jiné, jako je spotřeba šířky pásma sítě, můžou být užitečné ve scénářích, kdy je objem dat velký a šířka pásma nebo doba provádění jsou omezená.

Snímek obrazovky s rozhraním pro výběr čítače na webu Azure Portal

Zobrazení dat čítačů událostí a výkonu v Log Analytics

Informace o analýze dat monitorování v úložišti protokolů služby Azure Monitor / Log Analytics pomocí dotazovacího jazyka Kusto (KQL) najdete v dotazech Kusto.

Dvě tabulky, ve kterých se telemetrie ukládá, se nazývají Výkon a Událost. Následující dotaz zkontroluje počet řádků a zjistí, jestli máme tok dat. To potvrzuje, jestli instrumentace popsaná výše funguje.

Ukázkové dotazy KQL

Kontrola počtu řádků

(
        Event 
        | extend TableName = "Event"
        | summarize count() by TableName
)     
| union
(     
        Perf
        | extend TableName = "Perf"
        | summarize count() by TableName
)

Dotazování událostí

Načtení prvních 10 řádků události
Event
| take 10
Načtení počtu událostí podle závažnosti zprávy
Event
| summarize count() by EventLevelName
Vykreslení výsečového grafu počtu podle závažnosti zprávy
Event
| summarize count() by EventLevelName
| render piechart 
Načtení všech chyb s konkrétním textovým řetězcem

Tady hledáme všechny zprávy, které mají slovo odpojené .

Event
| where RenderedDescription has "disconnected"
Hledání klíčového slova ve více tabulce bez znalosti schématu

Vyhledávací příkaz je užitečný, když nevíte, ve kterém sloupci jsou informace obsaženy. Tento dotaz vrátí všechny řádky ze zadaných tabulek, které mají alespoň jeden sloupec obsahující hledaný termín. Slovo je v tomto příkladu odpojeno .

search in (Perf, Event) "disconnected"
Načtení všech událostí z jednoho konkrétního deníku protokolu

V tomto příkladu zúžíme dotaz na deník protokolů s názvem Konektory – Integration Runtime.

Event 
| where EventLog == "Connectors - Integration Runtime"
Omezení výsledků dotazu pomocí časových rozsahů

Tento dotaz používá stejný dotaz jako výše, ale omezuje výsledky na výsledky, ke kterým dochází před 2 dny nebo v poslední době.

Event 
| where EventLog      == "Connectors - Integration Runtime"
  and   TimeGenerated >= ago(2d)

Dotazování dat čítačů výkonu

Načtení prvních 10 čtení čítačů výkonu
Perf
| take 10
Načtení konkrétního čítače s časovými omezeními
Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
        and CounterName   == "Bytes Received/sec"

Čítače výkonu jsou v podstatě hierarchické, takže mějte na paměti, že máte dost místa, kde predikáty v dotazu vyberou jenom konkrétní čítač, který potřebujete.

Načtení 95. percentilu pro daný čítač rozdělený do 30minutových řezů za posledních 24 hodin

Tento příklad je všechny čítače pro konkrétní síťový adaptér.

Perf
| where     TimeGenerated >= ago(24h)
        and ObjectName    == "Network Adapter"
        and InstanceName  == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
| project TimeGenerated, Computer, ObjectName, InstanceName, CounterName, CounterValue
| summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName
Použití proměnných pro opakované použití kódu

Tady vytvoříme název objektu a název čítače proměnnou, takže nebudeme muset změnit tělo dotazu KQL, aby se změny těchto výběrů provedly později.

let pObjectName  = "Memory"; // Required to select the right counter
let pCounterName = "Available MBytes"; // Required to select the right counter
Perf
| where Type == "Perf" and ObjectName == pObjectName and CounterName == pCounterName
| project TimeGenerated, Computer, CounterName, CounterValue
| order by TimeGenerated asc 
| summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated