Udostępnij za pośrednictwem

Perspektywa platformy Azure Well-Architected Framework dla usługi Log Analytics

  • Artykuł

Well-Architected Framework funkcje obciążeń i wydajność muszą być monitorowane na różne sposoby i z różnych powodów. Obszary robocze usługi Azure Monitor Log Analytics to podstawowy dziennik i ujście metryk dla dużej części danych monitorowania. Obszary robocze obsługują wiele funkcji w usłudze Azure Monitor, w tym zapytania ad hoc, wizualizacje i alerty. Aby uzyskać ogólne zasady monitorowania, zobacz Wskazówki dotyczące monitorowania i diagnostyki. Wskazówki przedstawiają ogólne zasady monitorowania. Identyfikuje różne typy danych. Identyfikuje ona wymaganą analizę, którą obsługuje usługa Azure Monitor, a także identyfikuje dane przechowywane w obszarze roboczym, który umożliwia analizę.

W tym artykule przyjęto założenie, że rozumiesz zasady projektowania systemu. Potrzebna jest również działająca wiedza na temat obszarów roboczych i funkcji usługi Log Analytics w usłudze Azure Monitor, które wypełniają dane obciążeń operacyjnych. Aby uzyskać więcej informacji, zobacz Omówienie obszaru roboczego usługi Log Analytics.

Ważne

Jak korzystać z tego przewodnika

Każda sekcja zawiera listę kontrolną projektu , która przedstawia zagadnienia związane z architekturą wraz ze strategiami projektowania zlokalizowanymi w zakresie technologii.

Dostępne są również zalecenia dotyczące możliwości technologii lub topologii wdrażania, które mogą pomóc zmaterializować te strategie. Zalecenia nie reprezentują wyczerpującej listy wszystkich konfiguracji dostępnych dla obszarów roboczych usługi Log Analytics i powiązanych z nią zasobów usługi Azure Monitor. Zamiast tego wyświetlają listę kluczowych zaleceń mapowanych na perspektywy projektu. Skorzystaj z zaleceń, aby utworzyć weryfikację koncepcji, zaprojektować środowisko monitorowania obciążenia lub zoptymalizować istniejące rozwiązanie do monitorowania obciążeń.

Zakres technologii

Ten przewodnik koncentruje się na powiązanych decyzjach dotyczących następujących zasobów platformy Azure.

  • Obszary robocze usługi Log Analytics
  • Dane dziennika operacyjnego obciążenia
  • Ustawienia diagnostyczne zasobów platformy Azure w obciążeniu

Niezawodność

Celem filaru niezawodności jest zapewnienie ciągłej funkcjonalności poprzez budowanie wystarczającej odporności i możliwość szybkiego odzyskiwania sprawności po awariach.

Zasady projektowania niezawodności zapewniają strategię projektowania wysokiego poziomu stosowaną dla poszczególnych składników, przepływów systemowych i całego systemu.

Sytuacje dotyczące niezawodności, które należy wziąć pod uwagę w przypadku obszarów roboczych usługi Log Analytics, to:

  • Dostępność obszaru roboczego.
  • Ochrona zebranych danych w rzadkich przypadkach awarii centrum danych lub regionu platformy Azure.

Obecnie nie ma standardowej funkcji trybu failover między obszarami roboczymi w różnych regionach, ale istnieją strategie, których należy użyć, jeśli masz określone wymagania dotyczące dostępności lub zgodności.

Lista kontrolna projektowania pod kątem niezawodności

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu pod kątem niezawodności i określ jej znaczenie dla wymagań biznesowych, pamiętając o jednostkach SKU i funkcjach maszyn wirtualnych oraz ich zależnościach. Rozszerz strategię w celu uwzględnienia większej liczby podejść zgodnie z potrzebami.

  • Przejrzyj limity usług dla obszarów roboczych usługi Log Analytics. Sekcja Limity usługi ułatwia zrozumienie ograniczeń dotyczących zbierania i przechowywania danych oraz innych aspektów usługi. Te limity ułatwiają określenie, jak prawidłowo zaprojektować strategię obserwacji obciążenia. Pamiętaj, aby przejrzeć limity usługi Azure Monitor , ponieważ wiele omówionych tam funkcji, takich jak zapytania, współpracuje z obszarami roboczymi usługi Log Analytics.
  • Planowanie odporności i odzyskiwania obszaru roboczego. Obszary robocze usługi Log Analytics są regionalne, bez wbudowanej obsługi nadmiarowości między regionami ani replikacji. Ponadto opcje nadmiarowości strefy dostępności są ograniczone. W związku z tym należy określić wymagania dotyczące niezawodności obszarów roboczych i strategizować, aby spełnić te cele. Wymagania mogą przewidywać, że obszar roboczy musi być odporny na awarie centrum danych lub awarie regionalne. Mogą one również oznaczać, że musisz mieć możliwość odzyskania danych do nowego obszaru roboczego w regionie trybu failover. Każdy z tych scenariuszy wymaga wprowadzenia dodatkowych zasobów i procesów w celu pomyślnego wdrożenia, dlatego należy starannie rozważyć równoważenie celów niezawodności kosztami i złożonością.
  • Wybierz odpowiednie regiony wdrażania, aby spełnić wymagania dotyczące niezawodności. Wdrażanie obszarów roboczych usługi Log Analytics i punktów końcowych zbierania danych (DCE) znajdujących się ze składnikami obciążenia emitujących dane operacyjne. Wybór odpowiedniego regionu, w którym ma zostać wdrożony obszar roboczy i kontrolery domeny, powinny być informowane przez miejsce wdrożenia obciążenia. Może być konieczne rozważenie regionalnej dostępności niektórych funkcji usługi Log Analytics, takich jak dedykowane klastry, w porównaniu z innymi czynnikami bardziej centralnymi dla wymagań dotyczących niezawodności, kosztów i wydajności obciążenia.
  • Upewnij się, że systemy obserwacji są w dobrej kondycji. Podobnie jak każdy inny składnik obciążenia, upewnij się, że systemy monitorowania i rejestrowania działają prawidłowo. Aby to osiągnąć, włącz funkcje wysyłające sygnały danych dotyczących kondycji do zespołów operacyjnych. Skonfiguruj sygnały danych kondycji specyficzne dla obszarów roboczych usługi Log Analytics i skojarzonych zasobów.

Zalecenia dotyczące konfiguracji dotyczące niezawodności

Zalecenie Korzyść
Nie dołączaj obszarów roboczych usługi Log Analytics do ścieżki krytycznej obciążenia. Obszary robocze są ważne dla działającego systemu obserwacji, ale funkcjonalność obciążenia nie powinna zależeć od nich. Utrzymywanie obszarów roboczych i skojarzonych funkcji poza krytyczną ścieżką obciążenia minimalizuje ryzyko problemów wpływających na system obserwacji, które mają wpływ na wykonywanie środowiska uruchomieniowego obciążenia.
Aby zapewnić wysoką trwałość danych obszaru roboczego, wdróż obszary robocze usługi Log Analytics w regionie obsługującym odporność danych. Odporność danych jest możliwa tylko dzięki połączeniu obszaru roboczego z dedykowanym klastrem w tym samym regionie. Gdy korzystasz z dedykowanego klastra, umożliwia rozłożenie skojarzonych obszarów roboczych między strefy dostępności, które zapewniają ochronę przed awariami centrum danych. Jeśli nie zbierzesz teraz wystarczającej ilości danych, aby uzasadnić dedykowany klaster, ten wybór regionalny będzie wspierać przyszły wzrost.
Wybierz wdrożenie obszaru roboczego w oparciu o bliskość obciążenia.

Użyj punktów końcowych zbierania danych (DCE) w tym samym regionie co obszar roboczy usługi Log Analytics.		 Wdróż obszar roboczy w tym samym regionie co wystąpienia obciążenia. Posiadanie obszaru roboczego i kontrolerów domeny w tym samym regionie, w którym obciążenie zmniejsza ryzyko wystąpienia awarii w innych regionach.

Kontrolery domeny są używane przez agenta usługi Azure Monitor i interfejs API pozyskiwania dzienników do wysyłania danych operacyjnych obciążenia do obszaru roboczego usługi Log Analytics. Może być potrzebnych wiele kontrolerów domeny, mimo że wdrożenie ma tylko jeden obszar roboczy. Aby uzyskać więcej informacji na temat konfigurowania kontrolerów domeny dla określonego środowiska, zobacz Jak skonfigurować punkty końcowe zbierania danych na podstawie wdrożenia.<Br
Jeśli obciążenie jest wdrażane w projekcie aktywne-aktywne, rozważ użycie wielu obszarów roboczych i kontrolerów domeny rozmieszczonych w różnych regionach, w których wdrożono obciążenie.

Wdrażanie obszarów roboczych w wielu regionach zwiększa złożoność środowiska. Zrównoważ kryteria opisane w temacie Projektowanie architektury obszaru roboczego usługi Log Analytics zgodnie z wymaganiami dotyczącymi dostępności.
Jeśli chcesz , aby obszar roboczy był dostępny w przypadku awarii regionu lub nie zbierasz wystarczającej ilości danych dla dedykowanego klastra, skonfiguruj zbieranie danych w celu wysyłania krytycznych danych do wielu obszarów roboczych w różnych regionach. Ta praktyka jest również znana jako multiemisji dzienników.

Na przykład skonfiguruj kontrolery domeny dla wielu obszarów roboczych dla agenta usługi Azure Monitor uruchomionego na maszynach wirtualnych. Skonfiguruj wiele ustawień diagnostycznych, aby zbierać dzienniki zasobów z zasobów platformy Azure i wysyłać dzienniki do wielu obszarów roboczych.
W ten sposób dane operacyjne obciążenia są dostępne w alternatywnym obszarze roboczym, jeśli wystąpi awaria regionalna. Należy jednak pamiętać, że zasoby, które opierają się na danych, takich jak alerty i skoroszyty, nie będą automatycznie replikowane do innych regionów. Rozważ przechowywanie szablonów usługi Azure Resource Manager (ARM) dla krytycznych zasobów alertów z konfiguracją alternatywnego obszaru roboczego lub wdrażanie ich we wszystkich regionach, ale wyłączanie ich w celu zapobiegania nadmiarowym alertom. Obie opcje obsługują szybką obsługę włączania w przypadku awarii regionalnej.

Kompromis: ta konfiguracja powoduje zduplikowane opłaty za pozyskiwanie i przechowywanie, dzięki czemu są używane tylko w przypadku danych krytycznych.
Jeśli potrzebujesz ochrony danych w centrum danych lub awarii regionu, skonfiguruj eksportowanie danych z obszaru roboczego w celu zapisania danych w lokalizacji alternatywnej.

Ta opcja jest podobna do poprzedniej opcji multiemisji danych do różnych obszarów roboczych. Jednak ta opcja kosztuje mniej, ponieważ dodatkowe dane są zapisywane w magazynie.

Użyj opcji nadmiarowości usługi Azure Storage, w tym magazynu geograficznie nadmiarowego (GRS) i magazynu geograficznie nadmiarowego (GZRS), aby dodatkowo replikować te dane do innych regionów.

Eksport danych nie zapewnia odporności na zdarzenia wpływające na regionalny potok pozyskiwania.		 Chociaż historyczne dane dziennika operacyjnego mogą nie być łatwo możliwe do wykonywania zapytań w wyeksportowanym stanie, gwarantuje, że dane przetrwają długotrwałą awarię regionalną i mogą być dostępne i przechowywane przez dłuższy czas.

Jeśli eksport tabel nie jest obsługiwany przez eksport danych, możesz użyć innych metod eksportowania danych, w tym usługi Logic Apps, w celu ochrony danych.

Aby ta strategia działała jako realny plan odzyskiwania, należy dysponować procesami w celu ponownego skonfigurowania ustawień diagnostycznych dla zasobów na platformie Azure i na wszystkich agentach, którzy dostarczają dane. Należy również zaplanować ręczne ponowne wypełnianie wyeksportowanych danych do nowego obszaru roboczego. Podobnie jak w przypadku opisanej wcześniej opcji, należy również zdefiniować procesy dla tych zasobów, które opierają się na danych, takich jak alerty i skoroszyty.
W przypadku obciążeń o krytycznym znaczeniu wymagających wysokiej dostępności rozważ wdrożenie modelu federacyjnego obszaru roboczego, który używa wielu obszarów roboczych w celu zapewnienia wysokiej dostępności, jeśli wystąpi awaria regionalna. Program Mission-Critical udostępnia nakazowe wskazówki dotyczące najlepszych rozwiązań dotyczących projektowania wysoce niezawodnych aplikacji na platformie Azure. Metodologia projektowania obejmuje model federacyjnego obszaru roboczego z wieloma obszarami roboczymi usługi Log Analytics w celu zapewnienia wysokiej dostępności w przypadku wystąpienia wielu awarii, w tym awarii regionu świadczenia usługi Azure.

Ta strategia eliminuje koszty ruchu wychodzącego między regionami i pozostaje operacyjna z powodu awarii regionu. Wymaga to jednak większej złożoności, którą należy zarządzać za pomocą konfiguracji i procesów opisanych w temacie Modelowanie kondycji i obserwowanie obciążeń o znaczeniu krytycznym na platformie Azure.
Użyj infrastruktury jako kodu (IaC), aby wdrożyć obszary robocze i skojarzone funkcje oraz zarządzać nimi. Gdy automatyzujesz jak najwięcej wdrożeń i mechanizmów odporności i odzyskiwania w praktyce, gwarantuje to, że te operacje są niezawodne. Oszczędzasz krytyczny czas w procesach operacyjnych i minimalizujesz ryzyko błędu ludzkiego.

Upewnij się, że funkcje, takie jak zapisane zapytania dziennika, są również zdefiniowane za pośrednictwem IaC, aby odzyskać je do nowego regionu, jeśli jest wymagane odzyskiwanie.
Zaprojektuj reguły DCR z jedną zasadą odpowiedzialności, aby zachować proste reguły DCR.

Chociaż jeden kontroler domeny może zostać załadowany ze wszystkimi danymi wejściowymi, regułami i miejscami docelowymi dla systemów źródłowych, lepiej jest zaprojektować wąsko ukierunkowane reguły, które opierają się na mniejszej liczbie źródeł danych. Użyj kompozycji przypisań reguł, aby uzyskać żądany zakres obserwacji dla logicznego obiektu docelowego.

Ponadto zminimalizuj transformację w obiektach DCR		 W przypadku używania wąsko skoncentrowanych kontrolerów domeny minimalizuje ryzyko błędnej konfiguracji reguły o szerszym wpływie. Ogranicza to efekt tylko do zakresu, dla którego utworzono kontroler domeny. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące tworzenia reguł zbierania danych i zarządzania nimi w usłudze Azure Monitor.

Chociaż transformacja może być zaawansowana i konieczna w niektórych sytuacjach, może być trudne do przetestowania i rozwiązania problemów z pracą języka zapytań słów kluczowych (KQL). Jeśli to możliwe, zminimalizuj ryzyko utraty danych, pozyskiwając dane pierwotne i obsługujące przekształcenia podrzędne w czasie wykonywania zapytań.
Podczas ustawiania dziennego limitu lub zasad przechowywania upewnij się, że wymagania dotyczące niezawodności są utrzymywane przez pozyskiwanie i zachowywanie potrzebnych dzienników. Dzienny limit zatrzymuje zbieranie danych dla obszaru roboczego po osiągnięciu określonej ilości, co pomaga utrzymać kontrolę nad ilością pozyskiwania. Jednak tej funkcji należy używać tylko po dokładnym planowaniu. Upewnij się, że dzienny limit nie jest osiągany z regularnością. Jeśli tak się stanie, limit zostanie ustawiony zbyt restrykcyjnie. Należy ponownie skonfigurować dzienny limit, aby nie przegapić sygnałów krytycznych pochodzących z obciążenia.

Podobnie pamiętaj, aby starannie i przemyślanie zbliżyć się do obniżenia zasad przechowywania danych, aby upewnić się, że nie utracisz przypadkowo krytycznych danych.
Użyj szczegółowych informacji o obszarze roboczym usługi Log Analytics , aby śledzić wolumin pozyskiwania, pozyskiwane dane w porównaniu z limitem danych, nieodpowiadające źródła dzienników i nieodpowiedzialne zapytania między innymi danymi. Utwórz alerty o stanie kondycji , aby proaktywnie powiadamiać o niedostępności obszaru roboczego z powodu awarii centrum danych lub awarii regionalnej. Ta strategia gwarantuje, że można pomyślnie monitorować kondycję obszarów roboczych i aktywnie działać, jeśli kondycja jest zagrożona pogorszeniem. Podobnie jak w przypadku każdego innego składnika obciążenia, ważne jest, aby pamiętać o metrykach kondycji i identyfikować trendy w celu zwiększenia niezawodności w czasie.

Azure Policy

Platforma Azure nie oferuje żadnych zasad związanych z niezawodnością obszarów roboczych usługi Log Analytics. Zasady niestandardowe można tworzyć w celu tworzenia barier zgodności wokół wdrożeń obszaru roboczego, takich jak zapewnienie, że obszary robocze są skojarzone z dedykowanym klastrem.

Chociaż nie są bezpośrednio związane z niezawodnością obszarów roboczych usługi Log Analytics, istnieją zasady platformy Azure dla prawie każdej dostępnej usługi. Zasady zapewniają włączenie ustawień diagnostycznych dla tej usługi i sprawdzenie, czy dane dziennika usługi przepływają do obszaru roboczego usługi Log Analytics. Wszystkie usługi w architekturze obciążenia powinny wysyłać dane dziennika do obszaru roboczego usługi Log Analytics w celu uzyskania własnych potrzeb dotyczących niezawodności, a zasady mogą pomóc je wymusić. Podobnie zasady istnieją w celu zapewnienia, że platformy oparte na agentach, takie jak maszyny wirtualne i platforma Kubernetes, mają zainstalowanego agenta.

Azure Advisor

Platforma Azure nie oferuje żadnych zaleceń usługi Azure Advisor związanych z niezawodnością obszarów roboczych usługi Log Analytics.

Zabezpieczenia

Celem filaru zabezpieczeń jest zapewnienie poufności, integralności i gwarancji dostępności dla obciążenia.

Zasady projektowania zabezpieczeń zapewniają strategię projektowania wysokiego poziomu w celu osiągnięcia tych celów, stosując podejścia do projektowania technicznego wokół rozwiązania do monitorowania i rejestrowania.

Lista kontrolna projektu dotycząca zabezpieczeń

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu pod kątem zabezpieczeń i identyfikowania luk w zabezpieczeniach i mechanizmów kontroli w celu poprawy stanu zabezpieczeń. Rozszerz strategię, aby uwzględnić więcej podejść zgodnie z potrzebami.

  • Zapoznaj się z tematami Punkt odniesienia zabezpieczeń usługi Azure Monitor i Zarządzanie dostępem do obszarów roboczych usługi Log Analytics. Te tematy zawierają wskazówki dotyczące najlepszych rozwiązań w zakresie zabezpieczeń.
  • Wdróż obszary robocze przy użyciu segmentacji jako zasady podstaw. Zaimplementuj segmentację na poziomie sieci, danych i dostępu. Segmentacja pomaga zapewnić, że obszary robocze są odizolowane do odpowiedniego stopnia i są lepiej chronione przed nieautoryzowanym dostępem do najwyższego poziomu, jednocześnie spełniając wymagania biznesowe dotyczące niezawodności, optymalizacji kosztów, doskonałości operacyjnej i wydajności.
  • Upewnij się, że możesz przeprowadzić inspekcję operacji odczytu i zapisu obszaru roboczego oraz skojarzonych tożsamości. Osoby atakujące mogą korzystać z wyświetlania dzienników operacyjnych. Naruszona tożsamość może prowadzić do ataków polegających na wstrzyknięciu dziennika. Włącz inspekcję operacji uruchamianych w witrynie Azure Portal lub za pośrednictwem interakcji interfejsu API i skojarzonych użytkowników. Jeśli nie skonfigurowaliśmy inspekcji obszaru roboczego, może to spowodować, że organizacja będzie zagrożona naruszeniem wymagań dotyczących zgodności.
  • Implementowanie niezawodnych kontrolek sieci. Pomaga zabezpieczyć dostęp sieciowy do obszaru roboczego i dzienników za pośrednictwem funkcji izolacji sieci i zapory. Niewystarczająco skonfigurowane mechanizmy kontroli sieci mogą spowodować ryzyko uzyskania dostępu przez nieautoryzowanych lub złośliwych podmiotów.
  • Określ, jakie typy danych wymagają niezmienności lub długoterminowego przechowywania. Dane dziennika powinny być traktowane tak samo jak dane obciążeń w systemach produkcyjnych. Uwzględnij dane dziennika w praktykach klasyfikacji danych, aby upewnić się, że pomyślnie przechowujesz poufne dane dziennika zgodnie z wymaganiami dotyczącymi zgodności.
  • Ochrona danych dziennika magazynowanych za pomocą szyfrowania. Segmentacja sama nie będzie całkowicie chronić poufności danych dziennika. Jeśli wystąpi nieautoryzowany nieprzetworzone dostęp, zaszyfrowanie danych dziennika w spoczynku pomaga zapobiec używaniu tych danych poza obszarem roboczym.
  • Ochrona poufnych danych dziennika za pomocą zaciemnienia. Podobnie jak dane obciążeń znajdujące się w systemach produkcyjnych, należy podjąć dodatkowe środki w celu zapewnienia zachowania poufności informacji poufnych, które mogą być celowo lub przypadkowo obecne w dziennikach operacyjnych. W przypadku korzystania z metod zaciemniania pomaga ukryć poufne dane dziennika przed nieautoryzowanymi oczami.

Zalecenia dotyczące konfiguracji dotyczące zabezpieczeń

Zalecenie Korzyść
Użyj kluczy zarządzanych przez klienta, jeśli potrzebujesz własnego klucza szyfrowania w celu ochrony danych i zapisanych zapytań w obszarach roboczych.

Usługa Azure Monitor zapewnia, że wszystkie dane i zapisane zapytania są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez firmę Microsoft (MMK). Jeśli potrzebujesz własnego klucza szyfrowania i zbierz wystarczającą ilość danych dla dedykowanego klastra, użyj klucza zarządzanego przez klienta. Dane można szyfrować przy użyciu własnego klucza w usłudze Azure Key Vault, w celu kontrolowania cyklu życia klucza i możliwości odwoływanie dostępu do danych.

Jeśli używasz usługi Microsoft Sentinel, upewnij się, że znasz zagadnienia dotyczące konfigurowania klucza zarządzanego przez klienta usługi Microsoft Sentinel.		 Ta strategia umożliwia szyfrowanie danych przy użyciu własnego klucza w usłudze Azure Key Vault w celu kontrolowania cyklu życia klucza i możliwości odwoływanie dostępu do danych.
Skonfiguruj inspekcję zapytań dziennika , aby śledzić, którzy użytkownicy uruchamiają zapytania.

Skonfiguruj dzienniki inspekcji dla każdego obszaru roboczego, który ma zostać wysłany do lokalnego obszaru roboczego lub skonsoliduj w dedykowanym obszarze roboczym zabezpieczeń, jeśli rozdzielisz dane operacyjne i zabezpieczające. Użyj szczegółowych informacji o obszarze roboczym usługi Log Analytics , aby okresowo przeglądać te dane. Rozważ utworzenie reguł alertów dotyczących zapytań dziennika w celu proaktywnego powiadamiania o próbie uruchomienia zapytań przez nieautoryzowanych użytkowników.		 Inspekcja zapytań dzienników rejestruje szczegóły każdego uruchomienia zapytania w obszarze roboczym. Traktuj te dane inspekcji jako dane zabezpieczeń i odpowiednio zabezpiecz tabelę LAQueryLogs . Ta strategia wzmacnia stan zabezpieczeń, pomagając zapewnić, że nieautoryzowany dostęp jest przechwytywane natychmiast, jeśli kiedykolwiek się stanie.
Pomaga zabezpieczyć obszar roboczy za pomocą prywatnych sieci i miar segmentacji.

Użyj funkcji łącza prywatnego , aby ograniczyć komunikację między źródłami dzienników a obszarami roboczymi do sieci prywatnej.		 W przypadku korzystania z linku prywatnego umożliwia również kontrolowanie sieci wirtualnych, które mogą uzyskiwać dostęp do danego obszaru roboczego, dodatkowo wzmacniając zabezpieczenia za pośrednictwem segmentacji.
Użyj Tożsamość Microsoft Entra zamiast kluczy interfejsu API na potrzeby dostępu do interfejsu API obszaru roboczego, jeśli jest dostępny. Dostęp oparty na kluczu interfejsu API do interfejsów API zapytań nie pozostawia dziennika inspekcji poszczególnych klientów. Użyj wystarczająco ograniczonego dostępu opartego na identyfikatorze Entra , aby można było prawidłowo przeprowadzić inspekcję dostępu programowego.
Skonfiguruj dostęp dla różnych typów danych w obszarze roboczym wymaganym dla różnych ról w organizacji.

Ustaw tryb kontroli dostępu dla obszaru roboczego na użyj uprawnień zasobu lub obszaru roboczego. Ta kontrola dostępu umożliwia właścicielom zasobów używanie kontekstu zasobów do uzyskiwania dostępu do danych bez udzielenia jawnego dostępu do obszaru roboczego.

Użyj kontroli dostępu opartej na rolach na poziomie tabeli dla użytkowników, którzy wymagają dostępu do zestawu tabel w wielu zasobach.		 To ustawienie upraszcza konfigurację obszaru roboczego i pomaga zapewnić użytkownikom, że nie mogą uzyskiwać dostępu do danych operacyjnych, których nie powinni.

Przypisz odpowiednią wbudowaną rolę , aby udzielić uprawnień obszaru roboczego administratorom na poziomie subskrypcji, grupy zasobów lub obszaru roboczego w zależności od zakresu ich obowiązków.

Użytkownicy z uprawnieniami do tabeli mają dostęp do wszystkich danych w tabeli niezależnie od ich uprawnień do zasobów.

Aby uzyskać szczegółowe informacje na temat różnych opcji udzielania dostępu do danych w obszarze roboczym, zobacz Zarządzanie dostępem do obszarów roboczych usługi Log Analytics .
Eksportowanie dzienników wymagających długoterminowego przechowywania lub niezmienności.

Eksportowanie danych służy do wysyłania danych na konto usługi Azure Storage z zasadami niezmienności , aby chronić przed naruszeniami danych. Nie każdy typ dziennika ma takie samo znaczenie dla zgodności, inspekcji lub zabezpieczeń, więc określ określone typy danych, które mają być eksportowane.		 Możesz zbierać dane inspekcji w obszarze roboczym, które podlegają przepisom wymagającym długoterminowego przechowywania. Nie można zmienić danych w obszarze roboczym usługi Log Analytics, ale można je przeczyścić. Eksportowanie kopii danych operacyjnych na potrzeby przechowywania umożliwia utworzenie rozwiązania spełniającego wymagania dotyczące zgodności.
Określ strategię filtrowania lub zaciemnia poufnych danych w obszarze roboczym.

Możesz zbierać dane zawierające poufne informacje. Filtruj rekordy, które nie powinny być zbierane przy użyciu konfiguracji dla określonego źródła danych. Użyj przekształcenia , jeśli należy usunąć lub zaciemnić tylko określone kolumny w danych.

Jeśli masz standardy, które wymagają niezmodyfikowania oryginalnych danych, możesz użyć literału "h" w zapytaniach KQL, aby zaciemnić wyniki zapytania wyświetlane w skoroszytach.		 Zaciemnianie lub filtrowanie poufnych danych w obszarze roboczym pomaga zapewnić zachowanie poufności informacji poufnych. W wielu przypadkach wymagania dotyczące zgodności określają sposoby obsługi poufnych informacji. Ta strategia pomaga proaktywnie spełnić wymagania.

Azure Policy

Platforma Azure oferuje zasady związane z zabezpieczeniami obszarów roboczych usługi Log Analytics, które ułatwiają wymuszanie żądanego stanu zabezpieczeń. Przykłady takich zasad to:

Platforma Azure oferuje również wiele zasad ułatwiających wymuszanie konfiguracji łącza prywatnego, takich jak obszary robocze usługi Log Analytics, powinny blokować pozyskiwanie dzienników i wykonywanie zapytań z sieci publicznych, a nawet konfigurowanie rozwiązania za pomocą zasad DINE, takich jak Konfigurowanie zakresu Private Link usługi Azure Monitor w celu używania prywatnych stref DNS.

Azure Advisor

Platforma Azure nie oferuje żadnych zaleceń usługi Azure Advisor związanych z zabezpieczeniami obszarów roboczych usługi Log Analytics.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na wykrywaniu wzorców wydatków, określaniu priorytetów inwestycji w krytycznych obszarach i optymalizowaniu w innych w celu spełnienia budżetu organizacji przy jednoczesnym spełnieniu wymagań biznesowych.

Zasady projektowania optymalizacji kosztów zapewniają strategię projektowania wysokiego poziomu na potrzeby osiągnięcia tych celów biznesowych. Ułatwiają one również wprowadzanie kompromisów zgodnie z potrzebami w projekcie technicznym związanym z rozwiązaniem do monitorowania i rejestrowania.

Aby uzyskać więcej informacji na temat sposobu obliczania opłat za dane dla obszarów roboczych usługi Log Analytics, zobacz Obliczenia i opcje dotyczące kosztów dzienników usługi Azure Monitor.

Lista kontrolna projektu dotycząca optymalizacji kosztów

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu optymalizacji kosztów dla inwestycji i dostosuj projekt tak, aby obciążenie było dostosowane do budżetu przydzielonego dla obciążenia. Projekt powinien korzystać z odpowiednich funkcji platformy Azure, monitorować inwestycje i znajdować możliwości optymalizacji w czasie.

  • Wykonywanie ćwiczeń modelowania kosztów. Te exercizes pomagają zrozumieć bieżące koszty obszaru roboczego i prognozować koszty względem wzrostu obszaru roboczego. Przeanalizuj trendy wzrostu obciążenia i upewnij się, że rozumiesz plany rozszerzania obciążenia, aby prawidłowo prognozować przyszłe koszty rejestrowania operacyjnego.
  • Wybierz odpowiedni model rozliczeniowy. Użyj modelu kosztów, aby określić najlepszy model rozliczeń dla danego scenariusza. Jak obecnie używasz obszarów roboczych i jak planujesz ich używać w miarę rozwoju obciążenia, określa, czy model warstwy płatności zgodnie z rzeczywistym użyciem jest najlepszym rozwiązaniem dla danego scenariusza.

    Pamiętaj, że możesz wybrać różne modele rozliczeń dla każdego obszaru roboczego, a w niektórych przypadkach można łączyć koszty obszarów roboczych, dzięki czemu można je szczegółowo analizować i podejmować decyzje.
  • Zbierz tylko odpowiednią ilość danych dziennika. Regularnie przeprowadzaj zaplanowane analizy ustawień diagnostycznych w zasobach, konfiguracji reguły zbierania danych i rejestrowania niestandardowego kodu aplikacji, aby upewnić się, że nie zbierasz niepotrzebnych danych dziennika.
  • Traktuj środowiska nieprodukcyjne inaczej niż środowiska produkcyjne. Przejrzyj środowiska nieprodukcyjne, aby upewnić się, że ustawienia diagnostyczne i zasady przechowywania zostały odpowiednio skonfigurowane. Często mogą one być znacznie mniej niezawodne niż środowisko produkcyjne, szczególnie w środowiskach tworzenia i testowania lub piaskownicy.

Zalecenia dotyczące konfiguracji optymalizacji kosztów

Zalecenie Korzyść
Skonfiguruj warstwę cenową dla ilości danych, które zwykle zbiera każdy obszar roboczy usługi Log Analytics. Domyślnie obszary robocze usługi Log Analytics używają cen płatności zgodnie z rzeczywistym użyciem bez minimalnej ilości danych. Jeśli zbierzesz wystarczającą ilość danych, możesz znacznie zmniejszyć koszt przy użyciu warstwy zobowiązania, co pozwala zobowiązać się do dziennego minimum danych zebranych w zamian za niższą stawkę. Jeśli zbierzesz wystarczającą ilość danych między obszarami roboczymi w jednym regionie, możesz połączyć je z dedykowanym klastrem i połączyć zebrany wolumin przy użyciu cen klastra.

Aby uzyskać więcej informacji na temat warstw zobowiązań i wskazówek dotyczących określania, co jest najbardziej odpowiednie dla poziomu użycia, zobacz Obliczenia i opcje dotyczące kosztów dzienników usługi Azure Monitor. Aby wyświetlić szacowane koszty użycia w różnych warstwach cenowych, zobacz Użycie i szacowane koszty.
Konfigurowanie przechowywania i archiwizowania danych. W obszarze roboczym usługi Log Analytics są naliczane opłaty za przechowywanie danych poza domyślnym ustawieniem 31 dni. 90 dni, jeśli usługa Microsoft Sentinel jest włączona w obszarze roboczym i 90 dni dla danych usługi Application Insights. Weź pod uwagę konkretne wymagania dotyczące łatwo dostępnych danych dla zapytań dzienników. Możesz znacznie zmniejszyć koszt, konfigurując zarchiwizowane dzienniki. Zarchiwizowane dzienniki pozwalają przechowywać dane przez maksymalnie siedem lat i nadal uzyskiwać do niej dostęp od czasu do czasu. Dostęp do danych uzyskuje się przy użyciu zadań wyszukiwania lub przywracania zestawu danych do obszaru roboczego.
Jeśli używasz usługi Microsoft Sentinel do analizowania dzienników zabezpieczeń, rozważ zastosowanie oddzielnego obszaru roboczego do przechowywania tych dzienników. Jeśli używasz dedykowanego obszaru roboczego na potrzeby danych dziennika używanych przez usługę SIEM, może to pomóc w kontrolowaniu kosztów. Obszary robocze używane przez usługę Microsoft Sentinel podlegają cenom usługi Microsoft Sentinel. Wymagania dotyczące zabezpieczeń określają typy dzienników, które muszą zostać uwzględnione w rozwiązaniu SIEM. Możesz wykluczyć dzienniki operacyjne, które będą naliczane według standardowych cen usługi Log Analytics, jeśli są w osobnym obszarze roboczym.
Skonfiguruj tabele używane do debugowania, rozwiązywania problemów i inspekcji jako dzienniki podstawowe. Tabele w obszarze roboczym usługi Log Analytics skonfigurowanym dla dzienników podstawowych mają niższy koszt pozyskiwania w zamian za ograniczone funkcje i opłaty za zapytania dziennika. Jeśli wysyłasz zapytania do tych tabel rzadko i nie używasz ich do zgłaszania alertów, ten koszt zapytania może być większy niż przesunięcie przez obniżony koszt pozyskiwania.
Ogranicz zbieranie danych ze źródeł danych dla obszaru roboczego. Podstawowym czynnikiem kosztu usługi Azure Monitor jest ilość danych zbieranych w obszarze roboczym usługi Log Analytics. Upewnij się, że zbierasz nie więcej danych niż wymagane do oceny kondycji i wydajności usług i aplikacji. Dla każdego zasobu wybierz odpowiednie kategorie dla skonfigurowanych ustawień diagnostycznych, aby zapewnić ilość potrzebnych danych operacyjnych. Pomaga ona pomyślnie zarządzać obciążeniem i nie zarządzać ignorowanych danych.

Może wystąpić kompromis między kosztami a wymaganiami dotyczącymi monitorowania. Na przykład możesz szybciej wykryć problem z wydajnością z dużą częstotliwością próbkowania, ale możesz chcieć uzyskać niższą częstotliwość próbkowania, aby obniżyć koszty. Większość środowisk ma wiele źródeł danych z różnymi typami kolekcji, więc musisz zrównoważyć określone wymagania z celami kosztów dla każdego z nich. Zobacz Optymalizacja kosztów w usłudze Azure Monitor , aby uzyskać zalecenia dotyczące konfigurowania zbierania dla różnych źródeł danych.
Regularnie analizuj dane użycia obszaru roboczego w celu identyfikowania trendów i anomalii.

Użyj szczegółowych informacji o obszarze roboczym usługi Log Analytics , aby okresowo przeglądać ilość danych zebranych w obszarze roboczym. Dalsze analizowanie zbierania danych przy użyciu metod w temacie Analizowanie użycia w obszarze roboczym usługi Log Analytics w celu określenia, czy istnieją inne konfiguracje, które mogą jeszcze bardziej zmniejszyć użycie.		 Pomagając zrozumieć ilość danych zbieranych przez różne źródła, identyfikuje anomalie i trendy w górę w zbieraniu danych, które mogą spowodować przekroczenie kosztów. Ta kwestia jest ważna podczas dodawania nowego zestawu źródeł danych do obciążenia. Jeśli na przykład dodasz nowy zestaw maszyn wirtualnych, włącz nowe ustawienia diagnostyki platformy Azure w usłudze lub zmień poziomy dziennika w aplikacji.
Utwórz alert, gdy zbieranie danych jest wysokie. Aby uniknąć nieoczekiwanych rachunków, należy proaktywnie powiadamiać o nadmiernym użyciu. Powiadomienie umożliwia rozwiązanie wszelkich potencjalnych anomalii przed końcem okresu rozliczeniowego.
Należy wziąć pod uwagę dzienny limit jako środek zapobiegawczy, aby upewnić się, że nie przekroczysz określonego budżetu. Dzienny limit wyłącza zbieranie danych w obszarze roboczym usługi Log Analytics przez resztę dnia po osiągnięciu skonfigurowanego limitu. Nie należy używać tej praktyki jako metody obniżenia kosztów zgodnie z opisem w temacie Kiedy używać dziennego limitu, ale zamiast tego zapobiegać pozyskiwaniu uciekanych z powodu błędnej konfiguracji lub nadużyć.

Jeśli ustawisz dzienny limit, utwórz alert po osiągnięciu limitu. Pamiętaj również o utworzeniu reguły alertu po osiągnięciu pewnej wartości procentowej. Możesz na przykład ustawić regułę alertu dla momentu osiągnięcia 90 procent pojemności. Ten alert daje możliwość zbadania i rozwiązania przyczyny zwiększonej ilości danych przed wyłączeniem krytycznego zbierania danych z obciążenia.

Azure Policy

Platforma Azure nie oferuje żadnych zasad związanych z optymalizacją kosztów obszarów roboczych usługi Log Analytics. Możesz utworzyć niestandardowe zasady , aby tworzyć zabezpieczenia zgodności wokół wdrożeń obszaru roboczego, takie jak zapewnienie, że obszary robocze zawierają odpowiednie ustawienia przechowywania.

Azure Advisor

Usługa Azure Advisor udostępnia zalecenia dotyczące przenoszenia określonych tabel w obszarze roboczym do taniego planu danych dziennika w warstwie Podstawowa dla tabel, które otrzymują stosunkowo dużą ilość pozyskiwania. Zapoznaj się z ograniczeniami, korzystając z podstawowych dzienników przed przełączeniem. Aby uzyskać więcej informacji, zobacz Kiedy należy używać dzienników podstawowych?. Usługa Azure Advisor może również zalecić zmianę warstwy zobowiązania cenowego dla całego obszaru roboczego na podstawie ogólnego woluminu użycia.

Doskonałość operacyjna

Doskonałość operacyjna koncentruje się głównie na procedurach dotyczących praktyk programistycznych, możliwości obserwacji i zarządzania wydaniami.

Zasady projektowania doskonałości operacyjnej stanowią ogólną strategię projektowania na potrzeby realizacji tych celów w kierunku wymagań operacyjnych obciążenia.

Lista kontrolna projektowania dotycząca doskonałości operacyjnej

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu dotyczącej doskonałości operacyjnej, aby zdefiniować procesy umożliwiające obserwowanie, testowanie i wdrażanie związane z obszarami roboczymi usługi Log Analytics.

  • Użyj infrastruktury jako kodu (IaC) dla wszystkich funkcji związanych z obszarami roboczymi usługi Log Analytics obciążenia. Zminimalizuj ryzyko wystąpienia błędu ludzkiego w przypadku ręcznego administrowania kolekcją dzienników, pozyskiwaniem, przechowywaniem i wykonywaniem zapytań, w tym zapisanymi zapytaniami i pakietami zapytań, automatyzując jak najwięcej tych funkcji za pomocą kodu. Ponadto uwzględnij alerty, które zgłaszają zmiany stanu kondycji, oraz konfigurację ustawień diagnostycznych dla zasobów, które wysyłają dzienniki do obszarów roboczych w kodzie IaC. Dołącz kod do innego kodu związanego z obciążeniem, aby zapewnić utrzymanie bezpiecznych praktyk wdrażania na potrzeby zarządzania obszarami roboczymi.
  • Upewnij się, że obszary robocze są w dobrej kondycji i gdy wystąpią problemy, otrzymasz powiadomienie. Podobnie jak każdy inny składnik obciążenia, obszary robocze mogą napotkać problemy. Problemy mogą kosztować cenny czas i zasoby do rozwiązywania problemów i potencjalnie pozostawić zespół nieświadomy stanu obciążenia produkcyjnego. Możliwość proaktywnego monitorowania obszarów roboczych i eliminowania potencjalnych problemów pomaga zespołom operacyjnym zminimalizować czas, który poświęcają na rozwiązywanie i rozwiązywanie problemów.
  • Oddzielenie środowiska produkcyjnego od obciążeń nieprodukcyjnych. Unikaj niepotrzebnej złożoności, która może spowodować dodatkową pracę dla zespołu ds. operacji przy użyciu różnych obszarów roboczych dla środowiska produkcyjnego niż te, które są używane przez środowiska nieprodukcyjne. Dane przychodzące mogą również prowadzić do nieporozumień, ponieważ działania testowe mogą wydawać się zdarzeniami w środowisku produkcyjnym.
  • Preferuj wbudowane narzędzia i funkcje w przypadku rozwiązań innych niż microsoft Użyj wbudowanych narzędzi, aby rozszerzyć funkcjonalność systemów monitorowania i rejestrowania. Może być konieczne umieszczenie dodatkowych konfiguracji, aby obsługiwać wymagania, takie jak możliwość odzyskiwania lub niezależność danych, które nie są dostępne bez użycia w obszarach roboczych usługi Log Analytics. W takich przypadkach, gdy jest to praktyczne, użyj natywnej platformy Azure lub narzędzi firmy Microsoft, aby zachować liczbę narzędzi, które organizacja musi obsługiwać do minimum.
  • Traktuj obszary robocze jako składniki statyczne, a nie efemeryczne Podobnie jak w przypadku innych typów magazynów danych, obszary robocze nie powinny być brane pod uwagę wśród efemerycznych składników obciążenia. Struktura Well-Architected zwykle faworyzuje niezmienną infrastrukturę i możliwość szybkiego i łatwego zastępowania zasobów w ramach obciążeń w ramach wdrożeń. Jednak utrata danych obszaru roboczego może być katastrofalna i nieodwracalna. Z tego powodu zostawić obszary robocze poza pakietami wdrażania, które zastępują infrastrukturę podczas aktualizacji, i wykonują tylko uaktualnienia w miejscu w obszarach roboczych.
  • Upewnij się, że pracownicy operacyjni są przeszkoleni w język zapytań Kusto Trenowanie personelu w celu tworzenia lub modyfikowania zapytań w razie potrzeby. Jeśli operatory nie mogą pisać ani modyfikować zapytań, może spowolnić krytyczne rozwiązywanie problemów lub inne funkcje, ponieważ operatorzy muszą polegać na innych zespołach, aby wykonywać te czynności.

Zalecenia dotyczące konfiguracji dotyczące doskonałości operacyjnej

Zalecenie Korzyść
Zaprojektuj strategię obszaru roboczego, aby spełnić wymagania biznesowe.

Zobacz Projektowanie architektury obszaru roboczego usługi Log Analytics , aby uzyskać wskazówki dotyczące projektowania strategii dla obszarów roboczych usługi Log Analytics. Uwzględnij liczbę elementów, które należy utworzyć i gdzie je umieścić.

Jeśli obciążenie jest wymagane do korzystania ze scentralizowanej oferty zespołu platformy, upewnij się, że ustawiono cały niezbędny dostęp operacyjny. Ponadto skonstruuj alerty, aby zapewnić spełnienie wymagań dotyczących możliwości obserwacji obciążenia.		 Pojedyncza lub co najmniej minimalna liczba obszarów roboczych maksymalizuje wydajność operacyjną obciążenia. Ogranicza ona dystrybucję danych operacyjnych i zabezpieczających, zwiększa wgląd w potencjalne problemy, ułatwia identyfikowanie wzorców i minimalizuje wymagania dotyczące konserwacji.

W przypadku wielu obszarów roboczych, takich jak wiele dzierżaw, może być konieczne posiadanie obszarów roboczych w wielu regionach w celu obsługi wymagań dotyczących dostępności. Dlatego upewnij się, że masz odpowiednie procesy, aby zarządzać tą zwiększoną złożonością.
Użyj infrastruktury jako kodu (IaC) do wdrażania obszarów roboczych i skojarzonych funkcji oraz zarządzania nimi. Użyj infrastruktury jako kodu (IaC), aby zdefiniować szczegóły obszarów roboczych w szablonach usługi ARM, usłudze Azure BICEP lub Terraform. Umożliwia ona wdrażanie nowych obszarów roboczych i Azure Policy przy użyciu istniejących procesów DevOps w celu wymuszenia ich konfiguracji.

Colocating all of your IaC code with your application code (Kolokowanie całego kodu IaC za pomocą kodu aplikacji) pomaga zapewnić utrzymanie bezpiecznych praktyk wdrażania dla wszystkich wdrożeń.
Użyj szczegółowych informacji o obszarze roboczym usługi Log Analytics, aby śledzić kondycję i wydajność obszarów roboczych usługi Log Analytics oraz tworzyć znaczące i praktyczne alerty, aby proaktywnie otrzymywać powiadomienia o problemach operacyjnych.

Szczegółowe informacje o obszarze roboczym usługi Log Analytics udostępnia ujednolicony widok użycia, wydajności, kondycji, agentów, zapytań i dziennika zmian dla wszystkich obszarów roboczych.

Każdy obszar roboczy zawiera tabelę operacji , która rejestruje ważne działania wpływające na obszar roboczy.		 Przejrzyj informacje, które usługa Log Analytics udostępnia regularnie, aby śledzić kondycję i działanie poszczególnych obszarów roboczych. Korzystając z tych informacji, można łatwo tworzyć zrozumiałe wizualizacje, takie jak pulpity nawigacyjne lub raporty, których operacje i uczestnicy projektu mogą używać do śledzenia kondycji obszarów roboczych.

Utwórz reguły alertów na podstawie tej tabeli, aby proaktywnie otrzymywać powiadomienia w przypadku wystąpienia problemu operacyjnego. Aby uprościć tworzenie najbardziej krytycznych reguł alertów, możesz użyć zalecanych alertów dla obszaru roboczego .
Przećwicz ciągłe ulepszanie, często przeglądając ustawienia diagnostyczne platformy Azure w zasobach, regułach zbierania danych i szczegółowości dziennika aplikacji.

Upewnij się, że optymalizujesz strategię zbierania dzienników, często przeglądając ustawienia zasobów. Z punktu widzenia operacyjnego przyjrzyj się zmniejszeniu szumu w dziennikach, koncentrując się na tych dziennikach, które dostarczają przydatnych informacji o stanie kondycji zasobu.		 Dzięki optymalizacji w ten sposób można umożliwić operatorom badanie i rozwiązywanie problemów w przypadku ich wystąpienia lub wykonywanie innych rutynowych, improwizowanych lub awaryjnych zadań.

Po udostępnieniu nowych kategorii diagnostycznych dla typu zasobu przejrzyj typy dzienników emitowanych z tej kategorii, aby zrozumieć, czy włączenie tych kategorii może pomóc w optymalizacji strategii zbierania. Na przykład nowa kategoria może być podzbiorem większego zestawu przechwyconych działań. Nowy podzbiór może pozwolić zmniejszyć liczbę dzienników przychodzących, koncentrując się na działaniach, które są ważne dla operacji do śledzenia.

Azure Policy i Azure Advisor

Platforma Azure nie oferuje żadnych zasad ani zaleceń usługi Azure Advisor związanych z doskonałością operacyjną obszarów roboczych usługi Log Analytics.

Efektywność wydajności

Wydajność polega na zachowaniu środowiska użytkownika nawet wtedy, gdy występuje wzrost obciążenia dzięki zarządzaniu pojemnością. Strategia obejmuje skalowanie zasobów, identyfikowanie i optymalizowanie potencjalnych wąskich gardeł oraz optymalizowanie pod kątem szczytowej wydajności.

Zasady projektowania wydajności zapewniają strategię projektowania wysokiego poziomu w celu osiągnięcia tych celów pojemności w stosunku do oczekiwanego użycia.

Lista kontrolna projektu dotycząca wydajności

Rozpocznij strategię projektowania na podstawie listy kontrolnej przeglądu projektu pod kątem wydajności w celu zdefiniowania punktu odniesienia dla obszarów roboczych usługi Log Analytics i skojarzonych funkcji.

  • Zapoznaj się z podstawami opóźnienia pozyskiwania danych dziennika w usłudze Azure Monitor. Istnieje kilka czynników, które przyczyniają się do opóźnienia podczas pozyskiwania dzienników do obszarów roboczych. Wiele z tych czynników jest związanych z platformą Azure Monitor. Zrozumienie czynników i normalnego zachowania opóźnienia może pomóc w ustawieniu odpowiednich oczekiwań w zespołach operacyjnych obciążeń.
  • Oddzielaj obciążenia nieprodukcyjne i produkcyjne. Obszary robocze specyficzne dla środowiska produkcyjnego zmniejszają obciążenie, które mogą wprowadzać systemy nieprodukcyjne. Zmniejsza to ogólny ślad obszarów roboczych, co wymaga mniejszej liczby zasobów do obsługi przetwarzania danych dzienników.
  • Wybierz odpowiednie regiony wdrażania, aby spełnić wymagania dotyczące wydajności. Wdróż obszar roboczy usługi Log Analytics i punkty końcowe zbierania danych w pobliżu obciążenia. Wybór odpowiedniego regionu, w którym należy wdrożyć obszar roboczy i kontrolery domeny, powinny być informowane przez miejsce wdrożenia obciążenia. Może być konieczne rozważenie korzyści z wydajności wdrażania obszarów roboczych i kontrolerów DOMENY w tym samym regionie co obciążenie pod kątem wymagań dotyczących niezawodności, jeśli obciążenie zostało już wdrożone w regionie, który nie może obsługiwać tych wymagań dotyczących danych dziennika.

Zalecenia dotyczące konfiguracji dotyczące wydajności

Zalecenie Korzyść
Skonfiguruj inspekcję zapytań dzienników i użyj szczegółowych informacji o obszarze roboczym usługi Log Analytics, aby zidentyfikować powolne i nieefektywne zapytania.

Inspekcja zapytań dzienników przechowuje czas obliczeniowy wymagany do uruchomienia każdego zapytania i czasu do momentu zwrócenia wyników. Szczegółowe informacje o obszarze roboczym usługi Log Analytics używają tych danych do wyświetlania potencjalnie nieefektywnych zapytań w obszarze roboczym. Rozważ ponowne zapisywanie tych zapytań, aby zwiększyć ich wydajność. Zapoznaj się z artykułem Optymalizowanie zapytań dzienników w usłudze Azure Monitor, aby uzyskać wskazówki dotyczące optymalizowania zapytań dzienników.		 Zoptymalizowane zapytania zwracają wyniki szybciej i wykorzystują mniej zasobów na zapleczu, co sprawia, że procesy, które opierają się również na tych zapytaniach, są wydajniejsze.
Omówienie limitów usług dla obszarów roboczych usługi Log Analytics.

W niektórych implementacjach wysokiego ruchu możesz napotkać limity usług, które wpływają na wydajność i projekt obszaru roboczego lub obciążenia. Na przykład interfejs API zapytań ogranicza liczbę rekordów i wolumin danych zwracanych przez zapytanie. Interfejs API pozyskiwania dzienników ogranicza rozmiar każdego wywołania interfejsu API.

Aby uzyskać pełną listę limitów i limitów obszarów roboczych usługi Azure Monitor i Log Analytics specyficznych dla samego obszaru roboczego, zobacz Limity usługi Azure Monitor.		 Zrozumienie limitów, które mogą mieć wpływ na wydajność obszaru roboczego, pomaga odpowiednio zaprojektować je w celu ich ograniczenia. Możesz zdecydować się na użycie wielu obszarów roboczych, aby uniknąć osiągnięcia limitów skojarzonych z jednym obszarem roboczym.

Rozważ decyzje projektowe, aby ograniczyć limity usług względem wymagań i celów innych filarów.
Utwórz reguły DCR specyficzne dla typów źródeł danych w co najmniej jednym zdefiniowanym zakresie możliwości obserwacji. Utwórz oddzielne jednostki DCR pod kątem wydajności i zdarzeń, aby zoptymalizować wykorzystanie zasobów obliczeniowych przetwarzania zaplecza. W przypadku korzystania z oddzielnych tras DCR na potrzeby wydajności i zdarzeń pomaga ograniczyć wyczerpanie zasobów zaplecza. Dzięki żądaniom DCR, które łączą zdarzenia wydajności, wymusza ona na każdej skojarzonej maszynie wirtualnej przesyłanie, przetwarzanie i uruchamianie konfiguracji, które mogą nie być stosowane zgodnie z zainstalowanym oprogramowaniem. Nadmierne użycie zasobów obliczeniowych i błędy podczas przetwarzania konfiguracji mogą wystąpić i spowodować, że agent usługi Azure Monitor (AMA) przestanie odpowiadać.

Azure Policy i Azure Advisor

Platforma Azure nie oferuje żadnych zasad ani zaleceń usługi Azure Advisor związanych z wydajnością obszarów roboczych usługi Log Analytics.

Następny krok