Delen via

Perspectief van Azure Well-Architected Framework op Log Analytics

  • Artikel

de functionaliteit en prestaties van Well-Architected Framework-workloads moeten op verschillende manieren en om verschillende redenen worden bewaakt. Azure Monitor Log Analytics-werkruimten zijn de primaire sink voor logboeken en metrische gegevens voor een groot deel van de bewakingsgegevens. Werkruimten ondersteunen meerdere functies in Azure Monitor, waaronder ad-hocquery's, visualisaties en waarschuwingen. Zie Richtlijnen voor bewaking en diagnose voor algemene bewakingsprincipes. De richtlijnen bieden algemene bewakingsprincipes. De verschillende typen gegevens worden geïdentificeerd. Het identificeert de vereiste analyse die Azure Monitor ondersteunt en identificeert ook de gegevens die zijn opgeslagen in de werkruimte die de analyse mogelijk maakt.

In dit artikel wordt ervan uitgegaan dat u de principes van het systeemontwerp begrijpt. U hebt ook praktische kennis nodig van Log Analytics-werkruimten en -functies in Azure Monitor waarmee operationele workloadgegevens worden gevuld. Zie Overzicht van Log Analytics-werkruimte voor meer informatie.

Belangrijk

Het gebruik van deze handleiding

Elke sectie bevat een ontwerpcontrolelijst met aandachtsgebieden voor de architectuur, samen met ontwerpstrategieën die zijn gelokaliseerd in het technologiebereik.

Ook zijn aanbevelingen opgenomen over de technologische mogelijkheden of implementatietopologieën die kunnen helpen bij het materialiseren van deze strategieën. De aanbevelingen vormen geen volledige lijst met alle configuraties die beschikbaar zijn voor Log Analytics-werkruimten en de bijbehorende Azure Monitor-resources. In plaats daarvan worden de belangrijkste aanbevelingen vermeld die zijn toegewezen aan de ontwerpperspectieven. Gebruik de aanbevelingen om uw proof-of-concept te bouwen, uw omgeving voor workloadbewaking te ontwerpen of uw bestaande oplossing voor workloadbewaking te optimaliseren.

Technologiebereik

Deze handleiding is gericht op de onderling gerelateerde beslissingen voor de volgende Azure-resources.

  • Log Analytics-werkruimten
  • Operationele logboekgegevens van werkbelasting
  • Diagnostische instellingen voor Azure-resources in uw workload

Betrouwbaarheid

Het doel van de betrouwbaarheidspijler is om doorlopende functionaliteit te bieden door voldoende tolerantie te bouwen en de mogelijkheid om snel te herstellen van storingen.

De ontwerpprincipes voor betrouwbaarheid bieden een ontwerpstrategie op hoog niveau die wordt toegepast op afzonderlijke onderdelen, systeemstromen en het systeem als geheel.

De betrouwbaarheidssituaties die u moet overwegen voor Log Analytics-werkruimten zijn:

  • Beschikbaarheid van de werkruimte.
  • Bescherming van verzamelde gegevens in het zeldzame geval van een storing in een Azure-datacenter of -regio.

Er is momenteel geen standaardfunctie voor failover tussen werkruimten in verschillende regio's, maar er zijn strategieën die moeten worden gebruikt als u bepaalde vereisten hebt voor beschikbaarheid of naleving.

Ontwerpcontrolelijst voor betrouwbaarheid

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor betrouwbaarheid en bepaal de relevantie ervan voor uw bedrijfsvereisten, waarbij u rekening houdt met de SKU's en functies van virtuele machines (VM's) en hun afhankelijkheden. Breid de strategie zo nodig uit met meer benaderingen.

  • Bekijk servicelimieten voor Log Analytics-werkruimten. De sectie servicelimieten biedt inzicht in beperkingen voor het verzamelen en bewaren van gegevens en andere aspecten van de service. Deze limieten helpen u te bepalen hoe u uw strategie voor waarneembaarheid van workloads op de juiste manier ontwerpt. Controleer de servicelimieten van Azure Monitor , omdat veel van de functies die hierin worden besproken, zoals query's, hand in hand werken met Log Analytics-werkruimten.
  • Plan tolerantie en herstel van werkruimten. Log Analytics-werkruimten zijn regionaal, zonder ingebouwde ondersteuning voor regionale redundantie of replicatie. Daarnaast zijn de opties voor redundantie van de beschikbaarheidszone beperkt. Als zodanig moet u de betrouwbaarheidsvereisten van uw werkruimten bepalen en strategieën bepalen om aan deze doelen te voldoen. Uw vereisten kunnen bepalen dat uw werkruimte bestand moet zijn tegen datacenterfouten of regionale storingen, of dat u uw gegevens moet kunnen herstellen naar een nieuwe werkruimte in een failoverregio. Voor elk van deze scenario's moeten extra resources en processen worden geïmplementeerd om succesvol te zijn. Daarom moet u zorgvuldig overwegen om uw betrouwbaarheidsdoelen in balans te brengen met kosten en complexiteit.
  • Kies de juiste implementatieregio's om te voldoen aan uw betrouwbaarheidsvereisten. Implementeer uw Log Analytics-werkruimte en DCE's (eindpunten voor gegevensverzameling) op dezelfde locatie als de workloadonderdelen die operationele gegevens verzenden. Uw keuze van de juiste regio waarin u uw werkruimte en uw DCE's wilt implementeren, moet worden geïnformeerd door de locatie waar u uw workload implementeert. Mogelijk moet u de regionale beschikbaarheid van bepaalde Log Analytics-functionaliteit, zoals toegewezen clusters, afwegen tegen andere factoren die meer van belang zijn voor de betrouwbaarheid, kosten en prestatievereisten van uw workload.
  • Zorg ervoor dat uw waarneembaarheidssystemen in orde zijn. Net als elk ander onderdeel van uw workload moet u ervoor zorgen dat uw bewakings- en logboekregistratiesystemen goed werken. Om dit te bereiken, schakelt u functies in die gezondheidsgegevenssignalen verzenden naar uw operationele teams. Stel signalen voor statusgegevens in die specifiek zijn voor uw Log Analytics-werkruimten en bijbehorende resources.

Configuratieaanbeveling voor betrouwbaarheid

Aanbeveling Voordeel
Neem uw Log Analytics-werkruimten niet op in het kritieke pad van uw workload. Uw werkruimten zijn belangrijk voor een functionerend waarneembaarheidssysteem, maar de functionaliteit van uw workload mag er niet van afhankelijk zijn. Als u uw werkruimten en bijbehorende functies buiten het kritieke pad van uw workload houdt, wordt het risico geminimaliseerd op problemen die van invloed zijn op uw waarneembaarheidssysteem, waardoor de runtime-uitvoering van uw workload niet wordt beïnvloed.
Als u hoge duurzaamheid van werkruimtegegevens wilt ondersteunen, implementeert u Log Analytics-werkruimten in een regio die ondersteuning biedt voor gegevenstolerantie. Gegevenstolerantie is alleen mogelijk door de werkruimte te koppelen aan een toegewezen cluster in dezelfde regio. Wanneer u een toegewezen cluster gebruikt, kunt u de gekoppelde werkruimten verdelen over beschikbaarheidszones, die bescherming bieden tegen storingen in datacenters. Als u nu niet voldoende gegevens verzamelt om een toegewezen cluster te rechtvaardigen, ondersteunt deze preventieve regionale keuze toekomstige groei.
Kies uw werkruimte-implementatie op basis van de nabijheid van uw workload.

Gebruik eindpunten voor gegevensverzameling (DCE) in dezelfde regio als de Log Analytics-werkruimte.		 Implementeer uw werkruimte in dezelfde regio als de exemplaren van uw workload. Als uw werkruimte en DCE's zich in dezelfde regio bevinden als uw workload, vermindert u het risico op gevolgen door storingen in andere regio's.

DCE's worden gebruikt door de Azure Monitor-agent en de Api voor opname van logboeken om operationele gegevens van workloads te verzenden naar een Log Analytics-werkruimte. Mogelijk hebt u meerdere DCE's nodig, ook al heeft uw implementatie slechts één werkruimte. Zie How to set up data collection endpoints based on your deployment (Eindpunten voor gegevensverzameling instellen op basis van uw implementatie) voor meer informatie over het configureren van DCE's voor uw specifieke omgeving.<Br
Als uw workload is geïmplementeerd in een actief-actief-ontwerp, kunt u overwegen om meerdere werkruimten en DCE's te gebruiken, verspreid over de regio's waarin uw workload wordt geïmplementeerd.

Het implementeren van werkruimten in meerdere regio's voegt complexiteit toe aan uw omgeving. Balanceer de criteria die worden beschreven in Een Log Analytics-werkruimtearchitectuur ontwerpen met uw beschikbaarheidsvereisten.
Als u wilt dat de werkruimte beschikbaar is in een regiofout of als u onvoldoende gegevens verzamelt voor een toegewezen cluster, configureert u gegevensverzameling om kritieke gegevens naar meerdere werkruimten in verschillende regio's te verzenden. Deze procedure wordt ook wel logboek-multicasting genoemd.

Configureer bijvoorbeeld DCR's voor meerdere werkruimten voor Azure Monitor-agent die wordt uitgevoerd op VM's. Configureer meerdere diagnostische instellingen om resourcelogboeken van Azure-resources te verzamelen en de logboeken naar meerdere werkruimten te verzenden.
Op deze manier zijn operationele gegevens van de workload beschikbaar in de alternatieve werkruimte als er een regionale fout optreedt. Maar weet dat resources die afhankelijk zijn van de gegevens, zoals waarschuwingen en werkmappen, niet automatisch worden gerepliceerd naar de andere regio's. Overweeg om Azure Resource Manager-sjablonen (ARM) op te slaan voor kritieke waarschuwingsresources met configuratie voor de alternatieve werkruimte of deze in alle regio's te implementeren, maar ze uit te schakelen om redundante waarschuwingen te voorkomen. Beide opties ondersteunen snelle inschakeling in een regionale fout.

Afweging: deze configuratie resulteert in dubbele opname- en bewaarkosten, dus gebruik deze alleen voor kritieke gegevens.
Als u wilt dat gegevens worden beveiligd in een datacentrum of regiofout, configureert u gegevensexport vanuit de werkruimte om gegevens op een alternatieve locatie op te slaan.

Deze optie is vergelijkbaar met de vorige optie voor het multicasten van de gegevens naar verschillende werkruimten. Maar deze optie kost minder omdat de extra gegevens naar de opslag worden geschreven.

Gebruik opties voor Azure Storage-redundantie, waaronder geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS), om deze gegevens verder te repliceren naar andere regio's.

Gegevensexport biedt geen tolerantie tegen incidenten die van invloed zijn op de regionale opnamepijplijn.		 Hoewel de historische operationele logboekgegevens mogelijk niet gemakkelijk kunnen worden opgevraagd in de geëxporteerde status, zorgt dit ervoor dat de gegevens een langdurige regionale storing overleven en kunnen worden geopend en gedurende langere tijd kunnen worden bewaard.

Als u het exporteren van tabellen wilt die niet worden ondersteund door gegevensexport, kunt u andere methoden voor het exporteren van gegevens gebruiken, waaronder Logic Apps, om uw gegevens te beveiligen.

Deze strategie werkt alleen als een levensvatbaar herstelplan, moet u processen hebben om diagnostische instellingen voor uw resources in Azure en voor alle agents die gegevens leveren, opnieuw te configureren. U moet ook van plan zijn om uw geëxporteerde gegevens handmatig te rehydrateeren in een nieuwe werkruimte. Net als bij de eerder beschreven optie moet u ook processen definiëren voor resources die afhankelijk zijn van de gegevens, zoals waarschuwingen en werkmappen.
Voor bedrijfskritieke workloads waarvoor hoge beschikbaarheid is vereist, kunt u overwegen om een federatief werkruimtemodel te implementeren dat gebruikmaakt van meerdere werkruimten om hoge beschikbaarheid te bieden als er een regionale storing is. Bedrijfskritiek biedt richtlijnen voor prescriptieve best practices voor het ontwerpen van zeer betrouwbare toepassingen in Azure. De ontwerpmethodologie omvat een federatief werkruimtemodel met meerdere Log Analytics-werkruimten om hoge beschikbaarheid te bieden als er meerdere fouten zijn, waaronder het mislukken van een Azure-regio.

Deze strategie elimineert uitgaande kosten tussen regio's en blijft operationeel met een regiofout. Maar het vereist meer complexiteit die u moet beheren met configuratie en processen die worden beschreven in Statusmodellering en waarneembaarheid van bedrijfskritieke workloads in Azure.
Gebruik infrastructuur als code (IaC) om uw werkruimten en bijbehorende functies te implementeren en te beheren. Wanneer u zoveel mogelijk implementaties en mechanismen voor tolerantie en herstel automatiseert als praktisch, zorgt dit ervoor dat deze bewerkingen betrouwbaar zijn. U bespaart kritieke tijd in uw operationele processen en minimaliseert het risico op menselijke fouten.

Zorg ervoor dat functies zoals opgeslagen logboekquery's ook worden gedefinieerd via uw IaC om ze te herstellen naar een nieuwe regio als herstel is vereist.
Ontwerp DCR's met één verantwoordelijkheidsprincipe om DCR-regels eenvoudig te houden.

Hoewel één DCR kan worden geladen met alle invoer, regels en doelen voor de bronsystemen, is het beter om regels met een beperkte focus te ontwerpen die afhankelijk zijn van minder gegevensbronnen. Gebruik de samenstelling van regeltoewijzingen om het gewenste bereik voor waarneembaarheid voor het logische doel te bereiken.

Minimaliseer ook transformatie in DCR's		 Wanneer u nauw gerichte DCR's gebruikt, wordt het risico geminimaliseerd dat een onjuiste configuratie van een regel een breder effect heeft. Hiermee wordt het effect beperkt tot alleen het bereik waarvoor de DCR is gebouwd. Zie Best practices voor het maken en beheren van regels voor gegevensverzameling in Azure Monitor voor meer informatie.

Hoewel transformatie in sommige situaties krachtig en noodzakelijk kan zijn, kan het lastig zijn om het KQL-werk (Keyword Query Language) te testen en op te lossen. Minimaliseer indien mogelijk het risico op gegevensverlies door de onbewerkte gegevens op te nemen en transformaties downstream tijdens query's te verwerken.
Wanneer u een daglimiet of bewaarbeleid instelt, moet u ervoor zorgen dat u uw betrouwbaarheidsvereisten handhaaft door de logboeken op te nemen en te bewaren die u nodig hebt. Een daglimiet stopt het verzamelen van gegevens voor een werkruimte zodra een opgegeven hoeveelheid is bereikt, zodat u de controle over het opnamevolume kunt behouden. Maar gebruik deze functie alleen na een zorgvuldige planning. Zorg ervoor dat uw daglimiet niet regelmatig wordt bereikt. Als dat gebeurt, is de limiet te beperkend ingesteld. U moet de daglimiet opnieuw configureren, zodat u geen kritieke signalen mist die afkomstig zijn van uw workload.

Zorg er ook voor dat u het verlagen van uw beleid voor gegevensretentie zorgvuldig en zorgvuldig benadert om ervoor te zorgen dat u niet per ongeluk kritieke gegevens kwijtraakt.
Gebruik Inzichten in Log Analytics-werkruimten om het opnamevolume, opgenomen gegevens versus uw gegevenslimiet, niet-reagerende logboekbronnen en mislukte query's naast andere gegevens bij te houden. Maak statuswaarschuwingen om u proactief te waarschuwen als een werkruimte niet meer beschikbaar is vanwege een datacentrum of een regionale storing. Deze strategie zorgt ervoor dat u de status van uw werkruimten met succes kunt bewaken en proactief kunt handelen als de status het risico loopt te verslechteren. Net als elk ander onderdeel van uw workload is het essentieel dat u op de hoogte bent van metrische gegevens over de status en trends kunt identificeren om uw betrouwbaarheid in de loop van de tijd te verbeteren.

Azure Policy

Azure biedt geen beleid met betrekking tot de betrouwbaarheid van Log Analytics-werkruimten. U kunt aangepaste beleidsregels maken om nalevingsrails te bouwen rond uw werkruimte-implementaties, zoals ervoor zorgen dat werkruimten zijn gekoppeld aan een toegewezen cluster.

Hoewel het niet rechtstreeks te maken heeft met de betrouwbaarheid van Log Analytics-werkruimten, zijn er Azure-beleidsregels voor bijna elke beschikbare service. Het beleid zorgt ervoor dat diagnostische instellingen zijn ingeschakeld voor die service en valideren dat de logboekgegevens van de service naar een Log Analytics-werkruimte stromen. Alle services in de workloadarchitectuur moeten hun logboekgegevens verzenden naar een Log Analytics-werkruimte voor hun eigen betrouwbaarheidsbehoeften, en het beleid kan helpen dit af te dwingen. Op dezelfde manier bestaat er beleid om ervoor te zorgen dat de agent is geïnstalleerd op platforms op basis van agents, zoals VM's en Kubernetes.

Azure Advisor

Azure biedt geen Aanbevelingen van Azure Advisor met betrekking tot de betrouwbaarheid van Log Analytics-werkruimten.

Beveiliging

Het doel van de beveiligingspijler is om vertrouwelijkheid, integriteit en beschikbaarheidsgaranties te bieden voor de workload.

De ontwerpprincipes voor beveiliging bieden een ontwerpstrategie op hoog niveau om deze doelen te bereiken door benaderingen toe te passen op het technische ontwerp rond uw bewakings- en logboekregistratieoplossing.

Ontwerpcontrolelijst voor beveiliging

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor beveiliging en identificeer beveiligingsproblemen en besturingselementen om de beveiligingspostuur te verbeteren. Breid de strategie zo nodig uit met meer benaderingen.

  • Bekijk de onderwerpen Azure Monitor-beveiligingsbasislijn en Toegang tot Log Analytics-werkruimten beheren. Deze onderwerpen bieden richtlijnen voor aanbevolen beveiligingsprocedures.
  • Implementeer uw werkruimten met segmentatie als hoeksteenprincipe. Implementeer segmentatie op netwerk-, gegevens- en toegangsniveaus. Segmentatie zorgt ervoor dat uw werkruimten in de juiste mate worden geïsoleerd en beter worden beschermd tegen onbevoegde toegang tot de hoogst mogelijke mate, terwijl u nog steeds voldoet aan uw bedrijfsvereisten voor betrouwbaarheid, kostenoptimalisatie, operationele uitmuntendheid en prestatie-efficiëntie.
  • Zorg ervoor dat u lees- en schrijfactiviteiten en bijbehorende identiteiten in de werkruimte kunt controleren. Aanvallers kunnen profiteren van het weergeven van operationele logboeken. Een gecompromitteerde identiteit kan leiden tot aanvallen met logboekinjectie. Schakel controle in van bewerkingen die worden uitgevoerd vanuit de Azure-portal of via API-interacties en de bijbehorende gebruikers. Als u niet bent ingesteld om uw werkruimte te controleren, loopt u mogelijk het risico dat uw organisatie de nalevingsvereisten schendt.
  • Implementeer robuuste netwerkbesturingselementen. Helpt bij het beveiligen van uw netwerktoegang tot uw werkruimte en uw logboeken via netwerkisolatie en firewallfuncties. Onvoldoende geconfigureerde netwerkbesturingselementen kunnen het risico lopen dat u wordt geopend door onbevoegde of kwaadwillende actoren.
  • Bepaal welke typen gegevens onveranderbaarheid of langetermijnretentie nodig hebben. Uw logboekgegevens moeten met dezelfde strengheid worden behandeld als workloadgegevens in productiesystemen. Neem logboekgegevens op in uw procedures voor gegevensclassificatie om ervoor te zorgen dat u gevoelige logboekgegevens opslaat volgens de nalevingsvereisten.
  • Beveilig logboekgegevens-at-rest met versleuteling. Met segmentatie alleen worden de vertrouwelijkheid van uw logboekgegevens niet volledig beschermd. Als onbevoegde onbewerkte toegang plaatsvindt, helpt het versleutelen van de logboekgegevens at rest om te voorkomen dat kwaadwillenden die gegevens buiten uw werkruimte gebruiken.
  • Bescherm gevoelige logboekgegevens door middel van verduistering. Net als workloadgegevens die zich in productiesystemen bevinden, moet u extra maatregelen nemen om ervoor te zorgen dat de vertrouwelijkheid wordt bewaard voor gevoelige informatie die opzettelijk of onbedoeld aanwezig kan zijn in operationele logboeken. Wanneer u verdoezelingsmethoden gebruikt, kunt u gevoelige logboekgegevens verbergen voor onbevoegde ogen.

Configuratieaanbeveling voor beveiliging

Aanbeveling Voordeel
Gebruik door de klant beheerde sleutels als u uw eigen versleutelingssleutel nodig hebt om gegevens en opgeslagen query's in uw werkruimten te beveiligen.

Azure Monitor zorgt ervoor dat alle gegevens en opgeslagen query's in rust worden versleuteld met behulp van door Microsoft beheerde sleutels (MMK). Als u uw eigen versleutelingssleutel nodig hebt en voldoende gegevens verzamelt voor een toegewezen cluster, gebruikt u door de klant beheerde sleutel. U kunt gegevens versleutelen met behulp van uw eigen sleutel in Azure Key Vault, voor controle over de levenscyclus van de sleutel en de mogelijkheid om de toegang tot uw gegevens in te trekken.

Als u Microsoft Sentinel gebruikt, zorg er dan voor dat u bekend bent met de overwegingen in Door de klant beheerde microsoft Sentinel-sleutel instellen.		 Met deze strategie kunt u gegevens versleutelen met behulp van uw eigen sleutel in Azure Key Vault, voor controle over de levenscyclus van de sleutel en de mogelijkheid om de toegang tot uw gegevens in te trekken.
Logboekquerycontrole configureren om bij te houden welke gebruikers query's uitvoeren.

Configureer de auditlogboeken voor elke werkruimte die naar de lokale werkruimte moeten worden verzonden of voeg deze samen in een toegewezen beveiligingswerkruimte als u uw operationele en beveiligingsgegevens scheidt. Gebruik Inzichten in Log Analytics-werkruimten om deze gegevens periodiek te controleren. Overweeg waarschuwingsregels voor logboekquery's te maken om u proactief te waarschuwen als onbevoegde gebruikers query's proberen uit te voeren.		 Logboekquerycontrole registreert de details voor elke query die in een werkruimte wordt uitgevoerd. Behandel deze controlegegevens als beveiligingsgegevens en beveilig de LAQueryLogs-tabel op de juiste manier. Deze strategie versterkt uw beveiligingspostuur door ervoor te zorgen dat onbevoegde toegang onmiddellijk wordt betrapt als dit ooit gebeurt.
Beveilig uw werkruimte via privénetwerken en segmentatiemetingen.

Gebruik private link-functionaliteit om de communicatie tussen logboekbronnen en uw werkruimten te beperken tot privénetwerken.		 Wanneer u private link gebruikt, kunt u hiermee ook bepalen welke virtuele netwerken toegang hebben tot een bepaalde werkruimte, waardoor uw beveiliging verder wordt versterkt door middel van segmentatie.
Gebruik Microsoft Entra ID in plaats van API-sleutels voor toegang tot de werkruimte-API, indien beschikbaar. Toegang op basis van API-sleutels tot de query-API's laat geen audittrail per client achter. Gebruik op Entra ID gebaseerde toegang met voldoende bereik, zodat u de programmatische toegang goed kunt controleren.
Configureer toegang voor verschillende typen gegevens in de werkruimte die vereist zijn voor verschillende rollen in uw organisatie.

Stel de toegangsbeheermodus voor de werkruimte in op Resource- of werkruimtemachtigingen gebruiken. Met dit toegangsbeheer kunnen resource-eigenaren resourcecontext gebruiken om toegang te krijgen tot hun gegevens zonder expliciete toegang tot de werkruimte te krijgen.

Gebruik RBAC op tabelniveau voor gebruikers die toegang nodig hebben tot een set tabellen in meerdere resources.		 Deze instelling vereenvoudigt de configuratie van uw werkruimte en zorgt ervoor dat gebruikers geen toegang hebben tot operationele gegevens die ze niet mogen gebruiken.

Wijs de juiste ingebouwde rol toe om werkruimtemachtigingen te verlenen aan beheerders op abonnements-, resourcegroep- of werkruimteniveau, afhankelijk van hun bereik van verantwoordelijkheden.

Gebruikers met tabelmachtigingen hebben toegang tot alle gegevens in de tabel, ongeacht hun resourcemachtigingen.

Zie Toegang tot Log Analytics-werkruimten beheren voor meer informatie over de verschillende opties voor het verlenen van toegang tot gegevens in de werkruimte.
Exporteer logboeken waarvoor langetermijnretentie of onveranderbaarheid is vereist.

Gebruik gegevensexport om gegevens te verzenden naar een Azure Storage-account met beleid voor onveranderbaarheid om u te beschermen tegen manipulatie van gegevens. Niet elk type logboek heeft dezelfde relevantie voor naleving, controle of beveiliging, dus bepaal de specifieke gegevenstypen die moeten worden geëxporteerd.		 U kunt controlegegevens in uw werkruimte verzamelen die onderhevig zijn aan regelgeving die de langetermijnretentie ervan vereist. Gegevens in een Log Analytics-werkruimte kunnen niet worden gewijzigd, maar kunnen wel worden opgeschoond. Als u een kopie van de operationele gegevens exporteert voor bewaardoeleinden, kunt u een oplossing bouwen die voldoet aan uw nalevingsvereisten.
Bepaal een strategie om gevoelige gegevens in uw werkruimte te filteren of te verbergen.

Mogelijk verzamelt u gegevens die gevoelige informatie bevatten. Filter records die niet mogen worden verzameld met behulp van de configuratie voor de specifieke gegevensbron. Gebruik een transformatie als alleen bepaalde kolommen in de gegevens moeten worden verwijderd of verborgen.

Als u standaarden hebt die vereisen dat de oorspronkelijke gegevens ongewijzigd blijven, kunt u de letterlijke 'h' in KQL-query's gebruiken om queryresultaten die in werkmappen worden weergegeven, te verbergen.		 Door gevoelige gegevens in uw werkruimte te verbergen of eruit te filteren, zorgt u ervoor dat u vertrouwelijk blijft over gevoelige informatie. In veel gevallen bepalen nalevingsvereisten de manieren waarop u gevoelige informatie kunt verwerken. Deze strategie helpt u proactief aan de vereisten te voldoen.

Azure Policy

Azure biedt beleidsregels met betrekking tot de beveiliging van Log Analytics-werkruimten om uw gewenste beveiligingspostuur af te dwingen. Voorbeelden van dergelijke beleidsregels zijn:

Azure biedt ook talloze beleidsregels om private link-configuratie af te dwingen, zoals Log Analytics-werkruimten moeten logboekopname en query's vanuit openbare netwerken blokkeren of zelfs de oplossing configureren via DINE-beleid, zoals Azure Monitor Private Link Bereik configureren voor het gebruik van privé-DNS-zones.

Azure Advisor

Azure biedt geen Aanbevelingen van Azure Advisor met betrekking tot de beveiliging van Log Analytics-werkruimten.

Kostenoptimalisatie

Kostenoptimalisatie is gericht op het detecteren van uitgavenpatronen, het prioriteren van investeringen in kritieke gebieden en het optimaliseren van andere uitgaven om te voldoen aan het budget van de organisatie en tegelijkertijd te voldoen aan de bedrijfsvereisten.

De ontwerpprincipes van Cost Optimization bieden een ontwerpstrategie op hoog niveau om deze bedrijfsdoelen te bereiken. Ze helpen u ook om zo nodig compromissen te maken in het technische ontwerp met betrekking tot uw bewakings- en logboekregistratieoplossing.

Zie Kostenberekeningen en opties voor Azure Monitor-logboeken voor meer informatie over de berekening van gegevenskosten voor uw Log Analytics-werkruimten.

Ontwerpcontrolelijst voor kostenoptimalisatie

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Kostenoptimalisatie voor investeringen en verfijn het ontwerp, zodat de workload wordt afgestemd op het budget dat voor de workload is toegewezen. Uw ontwerp moet gebruikmaken van de juiste Azure-mogelijkheden, investeringen bewaken en mogelijkheden vinden om in de loop van de tijd te optimaliseren.

  • Voer kostenmodelleringsoefeningen uit. Met deze exercizes krijgt u inzicht in uw huidige kosten voor werkruimten en kunt u uw kosten voorspellen ten opzichte van de groei van de werkruimte. Analyseer uw groeitrends in uw workload en zorg ervoor dat u plannen voor workloaduitbreiding begrijpt om uw toekomstige kosten voor operationele logboekregistratie goed te voorspellen.
  • Kies het juiste factureringsmodel. Gebruik uw kostenmodel om het beste factureringsmodel voor uw scenario te bepalen. Hoe u uw werkruimten momenteel gebruikt en hoe u deze wilt gebruiken naarmate uw workload zich ontwikkelt, bepaalt of een model voor betalen per gebruik of een toezeggingslaag het beste bij uw scenario past.

    Houd er rekening mee dat u verschillende factureringsmodellen kunt kiezen voor elke werkruimte en dat u in bepaalde gevallen werkruimtekosten kunt combineren, zodat u gedetailleerd kunt zijn in uw analyse en besluitvorming.
  • Verzamel precies de juiste hoeveelheid logboekgegevens. Voer regelmatig geplande analyses uit van uw diagnostische instellingen voor uw resources, configuratie van regels voor gegevensverzameling en aangepaste logboekregistratie van toepassingscode om ervoor te zorgen dat u geen onnodige logboekgegevens verzamelt.
  • Behandel niet-productieomgevingen anders dan productie. Controleer uw niet-productieomgevingen om ervoor te zorgen dat u uw diagnostische instellingen en bewaarbeleid op de juiste manier hebt geconfigureerd. Deze kunnen vaak aanzienlijk minder robuust zijn dan productie, met name voor ontwikkel-/test- of sandbox-omgevingen.

Configuratieaanbeveling voor Kostenoptimalisatie

Aanbeveling Voordeel
Configureer de prijscategorie voor de hoeveelheid gegevens die doorgaans door elke Log Analytics-werkruimte wordt verzameld. Log Analytics-werkruimten gebruiken standaard prijzen voor betalen per gebruik zonder minimaal gegevensvolume. Als u voldoende gegevens verzamelt, kunt u uw kosten aanzienlijk verlagen door een toezeggingslaag te gebruiken, waarmee u zich kunt vastleggen op een dagelijks minimum aan gegevens die worden verzameld in ruil voor een lager tarief. Als u voldoende gegevens verzamelt in werkruimten in één regio, kunt u deze koppelen aan een toegewezen cluster en het verzamelde volume combineren met behulp van clusterprijzen.

Zie Kostenberekeningen en opties voor Azure Monitor-logboeken voor meer informatie over toezeggingslagen en richtlijnen voor het bepalen van wat het meest geschikt is voor uw gebruiksniveau. Als u de geschatte kosten voor uw gebruik in verschillende prijscategorieën wilt bekijken, raadpleegt u Gebruik en geschatte kosten.
Gegevensretentie en -archivering configureren. Er worden kosten in rekening gebracht voor het bewaren van gegevens in een Log Analytics-werkruimte na de standaardwaarde van 31 dagen. Het duurt 90 dagen als Microsoft Sentinel is ingeschakeld voor de werkruimte en 90 dagen voor Application Insights-gegevens. Houd rekening met uw specifieke vereisten om gegevens direct beschikbaar te hebben voor logboekquery's. U kunt uw kosten aanzienlijk verlagen door gearchiveerde logboeken te configureren. Met gearchiveerde logboeken kunt u gegevens maximaal zeven jaar bewaren en deze nog af en toe openen. U hebt toegang tot de gegevens met behulp van zoektaken of het herstellen van een set gegevens naar de werkruimte.
Als u Microsoft Sentinel gebruikt om beveiligingslogboeken te analyseren, kunt u overwegen om een afzonderlijke werkruimte te gebruiken om deze logboeken op te slaan. Wanneer u een toegewezen werkruimte gebruikt voor logboekgegevens die uw SIEM gebruikt, kan dit u helpen de kosten te beheersen. De werkruimten die Door Microsoft Sentinel worden gebruikt, zijn onderhevig aan de prijzen van Microsoft Sentinel. Uw beveiligingsvereisten bepalen welke typen logboeken moeten worden opgenomen in uw SIEM-oplossing. U kunt mogelijk operationele logboeken uitsluiten, die in rekening worden gebracht tegen de standaardprijzen voor Log Analytics als ze zich in een afzonderlijke werkruimte bevinden.
Configureer tabellen die worden gebruikt voor foutopsporing, probleemoplossing en controle als basislogboeken. Tabellen in een Log Analytics-werkruimte die is geconfigureerd voor Basic-logboeken , hebben lagere opnamekosten in ruil voor beperkte functies en kosten voor logboekquery's. Als u deze tabellen niet vaak opvraagt en deze niet gebruikt voor waarschuwingen, kunnen deze querykosten meer dan gecompenseerd worden door de lagere opnamekosten.
Beperk het verzamelen van gegevens uit gegevensbronnen voor de werkruimte. De primaire factor voor de kosten van Azure Monitor is de hoeveelheid gegevens die u verzamelt in uw Log Analytics-werkruimte. Zorg ervoor dat u niet meer gegevens verzamelt dan u nodig hebt om de status en prestaties van uw services en toepassingen te beoordelen. Selecteer voor elke resource de juiste categorieën voor de diagnostische instellingen die u configureert om de hoeveelheid operationele gegevens op te geven die u nodig hebt. Het helpt u uw workload te beheren en niet bij het beheren van genegeerde gegevens.

Er kan een afweging zijn tussen de kosten en uw bewakingsvereisten. U kunt bijvoorbeeld een prestatieprobleem sneller detecteren met een hoge steekproeffrequentie, maar misschien wilt u een lagere samplefrequentie om kosten te besparen. De meeste omgevingen hebben meerdere gegevensbronnen met verschillende soorten verzamelingen, dus u moet uw specifieke vereisten in balans houden met uw kostendoelen voor elke omgeving. Zie Kostenoptimalisatie in Azure Monitor voor aanbevelingen voor het configureren van verzamelingen voor verschillende gegevensbronnen.
Analyseer regelmatig gebruiksgegevens van werkruimten om trends en afwijkingen te identificeren.

Gebruik Inzichten in Log Analytics-werkruimte om periodiek de hoeveelheid gegevens te controleren die in uw werkruimte worden verzameld. Analyseer gegevensverzameling verder met behulp van methoden in Gebruik analyseren in Log Analytics-werkruimte om te bepalen of er andere configuraties zijn die uw gebruik verder kunnen verminderen.		 Doordat u inzicht krijgt in de hoeveelheid gegevens die door verschillende bronnen worden verzameld, worden afwijkingen en opwaartse trends in gegevensverzameling geïdentificeerd die tot te hoge kosten kunnen leiden. Deze overweging is belangrijk wanneer u een nieuwe set gegevensbronnen toevoegt aan uw workload. Als u bijvoorbeeld een nieuwe set vm's toevoegt, nieuwe diagnostische Azure-instellingen voor een service inschakelt of logboekniveaus wijzigt in uw toepassing.
Een waarschuwing maken wanneer de gegevensverzameling hoog is. Om onverwachte facturen te voorkomen, moet u proactief op de hoogte worden gesteld wanneer u overmatig gebruik ondervindt. Met Melding kunt u mogelijke afwijkingen voor het einde van uw factureringsperiode verhelpen.
Beschouw een daglimiet als een preventieve maatregel om ervoor te zorgen dat u een bepaald budget niet overschrijdt. Met een daglimiet wordt het verzamelen van gegevens in een Log Analytics-werkruimte de rest van de dag uitgeschakeld nadat de geconfigureerde limiet is bereikt. Gebruik deze procedure niet als een methode om de kosten te verlagen, zoals beschreven in Wanneer u een daglimiet gebruikt, maar in plaats daarvan om weggelopen opname vanwege onjuiste configuratie of misbruik te voorkomen.

Als u een daglimiet instelt, maakt u een waarschuwing wanneer de limiet is bereikt. Zorg ervoor dat u ook een waarschuwingsregel maakt wanneer een bepaald percentage is bereikt. U kunt bijvoorbeeld een waarschuwingsregel instellen voor wanneer de capaciteit van 90 procent is bereikt. Deze waarschuwing biedt u de mogelijkheid om de oorzaak van de verhoogde gegevens te onderzoeken en aan te pakken voordat de limiet het verzamelen van kritieke gegevens van uw workload uitschakelt.

Azure Policy

Azure biedt geen beleid met betrekking tot kostenoptimalisatie van Log Analytics-werkruimten. U kunt aangepaste beleidsregels maken om nalevingsrails te bouwen rond uw werkruimte-implementaties, bijvoorbeeld om ervoor te zorgen dat uw werkruimten de juiste bewaarinstellingen bevatten.

Azure Advisor

Azure Advisor doet aanbevelingen voor het verplaatsen van specifieke tabellen in een werkruimte naar het goedkope Basic Log-gegevensabonnement voor tabellen die een relatief hoog opnamevolume ontvangen. Krijg inzicht in de beperkingen door basislogboeken te gebruiken voordat u overschakelt. Zie Wanneer moet ik Basislogboeken gebruiken? voor meer informatie. Azure Advisor kan ook aanraden om de prijstoezeggingscategorie voor de hele werkruimte te wijzigen op basis van het totale gebruiksvolume.

Operationele topprestaties

Operational Excellence richt zich voornamelijk op procedures voor ontwikkelprocedures, waarneembaarheid en releasebeheer.

De ontwerpprincipes van Operational Excellence bieden een ontwerpstrategie op hoog niveau om deze doelen te bereiken met betrekking tot de operationele vereisten van de workload.

Ontwerpcontrolelijst voor Operational Excellence

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Operational Excellence voor het definiëren van processen voor waarneembaarheid, testen en implementatie met betrekking tot Log Analytics-werkruimten.

  • Gebruik infrastructuur als code (IaC) voor alle functies die betrekking hebben op de Log Analytics-werkruimten van uw workload. Minimaliseer het risico op menselijke fouten die kunnen optreden bij het handmatig beheren en uitvoeren van uw functies voor logboekverzameling, opname, opslag en query's, inclusief opgeslagen query's en querypakketten, door zoveel mogelijk van deze functies te automatiseren via code. Neem ook waarschuwingen op die wijzigingen in de status melden en de configuratie van diagnostische instellingen voor resources die logboeken naar uw werkruimten verzenden in uw IaC-code. Voeg de code toe aan uw andere workloadgerelateerde code om ervoor te zorgen dat uw veilige implementatieprocedures worden gehandhaafd voor het beheer van uw werkruimten.
  • Zorg ervoor dat uw werkruimten in orde zijn en dat u een melding krijgt wanneer er problemen optreden. Net als elk ander onderdeel van uw workload kunnen uw werkruimten problemen ondervinden. De problemen kunnen kostbare tijd en resources kosten om het probleem op te lossen en uw team mogelijk niet op de hoogte te houden van de status van de productieworkload. Door werkruimten proactief te kunnen bewaken en potentiële problemen te verhelpen, kunnen uw operationele teams de tijd die ze besteden aan het oplossen van problemen minimaliseren.
  • Scheid uw productie van niet-productieworkloads. Vermijd onnodige complexiteit die extra werk kan veroorzaken voor een operations-team door andere werkruimten voor uw productieomgeving te gebruiken dan de werkruimten die worden gebruikt door niet-productieomgevingen. Comingled-gegevens kunnen ook leiden tot verwarring, omdat testactiviteiten gebeurtenissen in productie lijken te zijn.
  • Liever ingebouwde hulpprogramma's en functies dan niet-Microsoft-oplossingen Gebruik ingebouwde hulpprogramma's om de functionaliteit van uw bewakings- en logboekregistratiesystemen uit te breiden. Mogelijk moet u aanvullende configuraties implementeren ter ondersteuning van vereisten zoals herstelbaarheid of gegevenssoevereine die niet out-of-the-box beschikbaar zijn met Log Analytics-werkruimten. Gebruik in deze gevallen, wanneer dit praktisch is, systeemeigen Azure- of Microsoft-hulpprogramma's om het aantal hulpprogramma's dat uw organisatie moet ondersteunen tot een minimum te beperken.
  • Uw werkruimten behandelen als statisch in plaats van tijdelijke onderdelen Net als andere typen gegevensarchieven moeten werkruimten niet worden beschouwd als een van de tijdelijke onderdelen van uw workload. Het Well-Architected Framework biedt over het algemeen de voorkeur aan onveranderbare infrastructuur en de mogelijkheid om snel en eenvoudig resources binnen uw workload te vervangen als onderdeel van uw implementaties. Maar het verlies van werkruimtegegevens kan catastrofaal en onomkeerbaar zijn. Laat daarom werkruimten buiten implementatiepakketten die de infrastructuur tijdens updates vervangen en voer alleen in-place upgrades uit op de werkruimten.
  • Zorg ervoor dat operations-personeel wordt getraind op Kusto-querytaal Personeel trainen om query's te maken of te wijzigen wanneer dat nodig is. Als operators geen query's kunnen schrijven of wijzigen, kan dit kritieke probleemoplossing of andere functies vertragen, omdat operators afhankelijk moeten zijn van andere teams om dat werk voor hen uit te voeren.

Configuratieaanbeveling voor Operational Excellence

Aanbeveling Voordeel
Ontwerp een werkruimtestrategie die voldoet aan uw bedrijfsvereisten.

Zie Een Log Analytics-werkruimtearchitectuur ontwerpen voor hulp bij het ontwerpen van een strategie voor uw Log Analytics-werkruimten. Geef op hoeveel er moeten worden gemaakt en waar u ze wilt plaatsen.

Als u wilt dat uw workload gebruikmaakt van een gecentraliseerd platformteam, moet u ervoor zorgen dat u alle benodigde operationele toegang instelt. Maak ook waarschuwingen om ervoor te zorgen dat aan de waarneembaarheidsbehoeften van workloads wordt voldaan.		 Eén of minimaal aantal werkruimten maximaliseert de operationele efficiëntie van uw workload. Het beperkt de distributie van uw operationele en beveiligingsgegevens, vergroot het inzicht in mogelijke problemen, maakt patronen gemakkelijker te identificeren en minimaliseert uw onderhoudsvereisten.

Mogelijk hebt u vereisten voor meerdere werkruimten, zoals meerdere tenants, of hebt u werkruimten in meerdere regio's nodig om uw beschikbaarheidsvereisten te ondersteunen. Zorg er dus voor dat u over de juiste processen beschikt om deze verhoogde complexiteit te beheren.
Gebruik infrastructuur als code (IaC) om uw werkruimten en bijbehorende functies te implementeren en te beheren. Gebruik infrastructuur als code (IaC) om de details van uw werkruimten te definiëren in ARM-sjablonen, Azure BICEP of Terraform. Hiermee kunt u uw bestaande DevOps-processen gebruiken om nieuwe werkruimten te implementeren en Azure Policy om hun configuratie af te dwingen.

Als u al uw IaC-code samen met uw toepassingscode verplaatst, zorgt u ervoor dat uw veilige implementatieprocedures worden gehandhaafd voor alle implementaties.
Gebruik Inzichten in Log Analytics-werkruimten om de status en prestaties van uw Log Analytics-werkruimten bij te houden en zinvolle en bruikbare waarschuwingen te maken om proactief op de hoogte te worden gesteld van operationele problemen.

Inzichten in Log Analytics-werkruimten bieden een uniforme weergave van het gebruik, de prestaties, de status, agents, query's en het wijzigingenlogboek voor al uw werkruimten.

Elke werkruimte heeft een bewerkingstabel die belangrijke activiteiten registreert die van invloed zijn op de werkruimte.		 Bekijk regelmatig de informatie die Log Analytics Insights biedt om de status en werking van elk van uw werkruimten bij te houden. Wanneer u deze informatie gebruikt, kunt u eenvoudig te begrijpen visualisaties zoals dashboards of rapporten maken die bewerkingen en belanghebbenden kunnen gebruiken om de status van uw werkruimten bij te houden.

Maak waarschuwingsregels op basis van deze tabel om proactief te worden gewaarschuwd wanneer er een operationeel probleem optreedt. U kunt aanbevolen waarschuwingen voor de werkruimte gebruiken om het maken van de meest kritieke waarschuwingsregels te vereenvoudigen.
Oefen continue verbetering door regelmatig de diagnostische instellingen van Azure te raadplegen voor uw resources, regels voor gegevensverzameling en uitgebreidheid van toepassingslogboeken.

Zorg ervoor dat u de strategie voor het verzamelen van logboeken optimaliseert door regelmatig uw resource-instellingen te controleren. Vanuit operationeel oogpunt kunt u de ruis in uw logboeken verminderen door u te richten op die logboeken die nuttige informatie bieden over de status van een resource.		 Door op deze manier te optimaliseren, stelt u operators in staat om problemen te onderzoeken en op te lossen wanneer deze zich voordoen, of om andere routinetaken, geïmproviseerde of noodtaken uit te voeren.

Wanneer er nieuwe diagnostische categorieën beschikbaar worden gesteld voor een resourcetype, controleert u de typen logboeken die met deze categorie worden verzonden om te begrijpen of het inschakelen ervan u kan helpen uw verzamelingsstrategie te optimaliseren. Een nieuwe categorie kan bijvoorbeeld een subset zijn van een grotere set activiteiten die worden vastgelegd. Met de nieuwe subset kunt u mogelijk het aantal binnenkomende logboeken verminderen door u te richten op de activiteiten die belangrijk zijn voor het bijhouden van uw bewerkingen.

Azure Policy en Azure Advisor

Azure biedt geen beleid en aanbevelingen van Azure Advisor met betrekking tot de operationele uitmuntendheid van Log Analytics-werkruimten.

Prestatie-efficiëntie

Prestatie-efficiëntie gaat over het handhaven van de gebruikerservaring, zelfs wanneer de belasting toeneemt door capaciteit te beheren. De strategie omvat het schalen van resources, het identificeren en optimaliseren van mogelijke knelpunten en het optimaliseren van piekprestaties.

De ontwerpprincipes voor prestatie-efficiëntie bieden een ontwerpstrategie op hoog niveau om deze capaciteitsdoelen te bereiken ten opzichte van het verwachte gebruik.

Ontwerpcontrolelijst voor prestatie-efficiëntie

Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Prestatie-efficiëntie voor het definiëren van een basislijn voor uw Log Analytics-werkruimten en bijbehorende functies.

  • Wees bekend met de basisprincipes van latentie van logboekgegevensopname in Azure Monitor. Er zijn verschillende factoren die bijdragen aan latentie bij het opnemen van logboeken in uw werkruimten. Veel van deze factoren zijn inherent aan het Azure Monitor-platform. Inzicht in de factoren en het normale latentiegedrag kan u helpen bij het stellen van de juiste verwachtingen binnen uw teams voor workloadbewerkingen.
  • Scheid uw niet-productie- en productieworkloads. Productiespecifieke werkruimten verminderen eventuele overhead die niet-productiesystemen kunnen veroorzaken. Het vermindert de algehele footprint van uw werkruimten, waardoor er minder resources nodig zijn voor het verwerken van logboekgegevens.
  • Kies de juiste implementatieregio's om te voldoen aan uw prestatievereisten. Implementeer uw Log Analytics-werkruimte en eindpunten voor gegevensverzameling (DCE's) dicht bij uw workload. Uw keuze van de juiste regio waarin u uw werkruimte en uw DCE's wilt implementeren, moet worden geïnformeerd door waar u de workload implementeert. Mogelijk moet u de prestatievoordelen van het implementeren van uw werkruimten en DCE's in dezelfde regio als uw workload afwegen tegen uw betrouwbaarheidsvereisten als u uw workload al hebt geïmplementeerd in een regio die deze vereisten voor uw logboekgegevens niet kan ondersteunen.

Configuratieaanbeveling voor prestatie-efficiëntie

Aanbeveling Voordeel
Configureer logboekquerycontrole en gebruik Log Analytics-werkruimte-inzichten om trage en inefficiënte query's te identificeren.

Logboekquerycontrole slaat de rekentijd op die nodig is om elke query uit te voeren en de tijd totdat de resultaten worden geretourneerd. Inzichten in Log Analytics-werkruimten gebruiken deze gegevens om mogelijk inefficiënte query's in uw werkruimte weer te geven. Overweeg deze query's te herschrijven om de prestaties te verbeteren. Raadpleeg Logboekquery's optimaliseren in Azure Monitor voor hulp bij het optimaliseren van uw logboekquery's.		 Geoptimaliseerde query's retourneren sneller resultaten en gebruiken minder resources op de back-end, waardoor de processen die afhankelijk zijn van deze query's ook efficiënter worden.
Meer informatie over servicelimieten voor Log Analytics-werkruimten.

In bepaalde implementaties met veel verkeer kunt u servicelimieten tegenkomen die van invloed zijn op uw prestaties en het ontwerp van uw werkruimte of workload. De query-API beperkt bijvoorbeeld het aantal records en het gegevensvolume dat door een query wordt geretourneerd. De LOGBOEKopname-API beperkt de grootte van elke API-aanroep.

Zie Azure Monitor-servicelimieten voor een volledige lijst met limieten en limieten voor Azure Monitor- en Log Analytics-werkruimten die specifiek zijn voor de werkruimte zelf.		 Als u de limieten begrijpt die van invloed kunnen zijn op de prestaties van uw werkruimte, kunt u deze op de juiste manier ontwerpen om deze te beperken. U kunt ervoor kiezen om meerdere werkruimten te gebruiken om te voorkomen dat de limieten voor één werkruimte worden bereikt.

Weeg de ontwerpbeslissingen om servicelimieten te beperken tegen vereisten en doelen voor andere pijlers.
Maak DDR's die specifiek zijn voor gegevensbrontypen binnen een of meer gedefinieerde waarneembaarheidsbereiken. Maak afzonderlijke DCR's voor prestaties en gebeurtenissen om het rekengebruik van de back-endverwerking te optimaliseren. Wanneer u afzonderlijke DCR's gebruikt voor prestaties en gebeurtenissen, helpt dit de uitputting van back-endresources te beperken. Door DCR's te hebben die prestatiegebeurtenissen combineren, dwingt het elke gekoppelde virtuele machine om configuraties over te dragen, te verwerken en uit te voeren die mogelijk niet van toepassing zijn op basis van de geïnstalleerde software. Een overmatig verbruik van rekenresources en fouten bij het verwerken van een configuratie kunnen optreden, waardoor de Azure Monitor-agent (AMA) niet meer reageert.

Azure Policy en Azure Advisor

Azure biedt geen beleid of aanbevelingen van Azure Advisor met betrekking tot de prestaties van Log Analytics-werkruimten.

Volgende stap