Waarschuwingsquery's voor zoeken in logboeken optimaliseren

Artikel
02/21/2024

In dit artikel wordt beschreven hoe u waarschuwingen voor zoeken in logboeken schrijft en converteert om optimale prestaties te bereiken. Geoptimaliseerde query's verminderen de latentie en belasting van waarschuwingen, die regelmatig worden uitgevoerd.

Beginnen met het schrijven van een waarschuwingslogboekquery

Waarschuwingsquery's beginnen bij het uitvoeren van query's op de logboekgegevens in Log Analytics die het probleem aangeeft. Zie Query's gebruiken in Azure Monitor Log Analytics voor meer informatie over wat u kunt detecteren. U kunt ook aan de slag met het schrijven van uw eigen query.

Query's die het probleem aangeven en niet de waarschuwing

De waarschuwingsstroom is gebouwd om de resultaten te transformeren die aangeven dat het probleem zich voor een waarschuwing voordoet. Bijvoorbeeld in het geval van een query zoals:

SecurityEvent
| where EventID == 4624

Als de bedoeling van de gebruiker is om een waarschuwing te geven wanneer dit gebeurtenistype plaatsvindt, wordt de waarschuwingslogica count toegevoegd aan de query. De query die wordt uitgevoerd, is:

SecurityEvent
| where EventID == 4624
| count

U hoeft geen waarschuwingslogica toe te voegen aan de query en dit kan zelfs problemen veroorzaken. Als u in het voorgaande voorbeeld uw query opneemt count , resulteert dit altijd in de waarde 1, omdat de waarschuwingsservice dat doet countcount.

Limiet vermijden en operators nemen

Het gebruik limit en take in query's kan de latentie en belasting van waarschuwingen verhogen, omdat de resultaten na verloop van tijd niet consistent zijn. Gebruik ze alleen als dat nodig is.

Beperkingen voor logboekquery's

Logboekquery's in Azure Monitor beginnen met een tabel of searchunion operator.

Query's voor waarschuwingsregels voor zoeken in logboeken moeten altijd beginnen met een tabel om een duidelijk bereik te definiëren, waardoor de queryprestaties en de relevantie van de resultaten worden verbeterd. Query's in waarschuwingsregels worden regelmatig uitgevoerd. Het gebruik search en union kan leiden tot overmatige overhead die latentie toevoegt aan de waarschuwing, omdat het scannen in meerdere tabellen vereist. Deze operators verminderen ook de mogelijkheid van de waarschuwingsservice om de query te optimaliseren.

We bieden geen ondersteuning voor het maken of wijzigen van waarschuwingsregels voor zoeken in logboeken die gebruikmaken search van of union operators, met uitzondering van query's voor meerdere resources.

De volgende waarschuwingsquery is bijvoorbeeld gericht op de tabel SecurityEvent en zoekt naar een specifieke gebeurtenis-id. Dit is de enige tabel die door de query moet worden verwerkt.

SecurityEvent
| where EventID == 4624

Waarschuwingsregels voor zoeken in logboeken met behulp van unionquery's voor meerdere resources worden niet beïnvloed door deze wijziging, omdat query's voor meerdere resources een type gebruiken, waardoor het querybereik wordt beperkt tot specifieke resources. Het volgende voorbeeld is een geldige waarschuwingsquery voor zoeken in logboeken:

union
app('00000000-0000-0000-0000-000000000001').requests,
app('00000000-0000-0000-0000-000000000002').requests,
workspace('00000000-0000-0000-0000-000000000003').Perf

Notitie

Query's voor meerdere resources worden ondersteund in de nieuwe scheduledQueryRules-API. Als u nog steeds de verouderde Log Analytics-waarschuwings-API gebruikt voor het maken van waarschuwingen voor zoeken in logboeken, raadpleegt u Verouderde regels bijwerken naar de huidige API voor geplande queryregels van Azure Monitor voor meer informatie over het overschakelen.

Voorbeelden

De volgende voorbeelden zijn logboekquery's die worden gebruikt search en union. Ze bieden stappen die u kunt gebruiken om deze query's te wijzigen voor gebruik in waarschuwingsregels.

Voorbeeld 1

U wilt een waarschuwingsregel voor zoeken in logboeken maken met behulp van de volgende query waarmee prestatiegegevens worden opgehaald met behulp van search:

search *
| where Type == 'Perf' and CounterName == '% Free Space'
| where CounterValue < 30

Als u deze query wilt wijzigen, gebruikt u eerst de volgende query om de tabel te identificeren waartoe de eigenschappen behoren:
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
Het resultaat van deze query zou laten zien dat de eigenschap CounterName afkomstig is uit de tabel Perf .
Gebruik dit resultaat om de volgende query te maken die u voor de waarschuwingsregel zou gebruiken:
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Voorbeeld 2

U wilt een waarschuwingsregel voor zoeken in logboeken maken met behulp van de volgende query waarmee prestatiegegevens worden opgehaald met behulp van search:

search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Als u deze query wilt wijzigen, gebruikt u eerst de volgende query om de tabel te identificeren waartoe de eigenschappen behoren:
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
Het resultaat van deze query zou laten zien dat de eigenschappen ObjectName en CounterName afkomstig zijn uit de tabel Perf .

Gebruik dit resultaat om de volgende query te maken die u voor de waarschuwingsregel zou gebruiken:

Perf
| where ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage=avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Voorbeeld 3

U wilt een waarschuwingsregel voor zoeken in logboeken maken met behulp van de volgende query die zowel search prestatiegegevens gebruikt als union om prestatiegegevens op te halen:

search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| where Computer !in (
    union *
    | where CounterName == "% Processor Utility"
    | summarize by Computer)
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Als u deze query wilt wijzigen, gebruikt u eerst de volgende query om de tabel te identificeren waartoe de eigenschappen in het eerste deel van de query behoren:
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
Het resultaat van deze query zou laten zien dat al deze eigenschappen afkomstig zijn uit de tabel Perf .
Gebruik union deze opdracht withsource om te bepalen welke brontabel elke rij heeft bijgedragen:
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
Het resultaat van deze query zou laten zien dat deze eigenschappen ook afkomstig zijn uit de tabel Perf .

Gebruik deze resultaten om de volgende query te maken die u voor de waarschuwingsregel zou gebruiken:

Perf
| where ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total"
| where Computer !in (
    (Perf
    | where CounterName == "% Processor Utility"
    | summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Voorbeeld 4

U wilt een waarschuwingsregel voor zoeken in logboeken maken met behulp van de volgende query waarmee de resultaten van twee search query's worden samengevoegd:

search Type == 'SecurityEvent' and EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
    search in (Heartbeat) OSType == 'Windows'
    | summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
    | project Hour , Computer
) on Hour

Als u de query wilt wijzigen, gebruikt u eerst de volgende query om de tabel te identificeren die de eigenschappen aan de linkerkant van de join bevat:
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Het resultaat geeft aan dat de eigenschappen aan de linkerkant van de join behoren tot de tabel SecurityEvent .
Gebruik de volgende query om de tabel te identificeren die de eigenschappen aan de rechterkant van de join bevat:
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Het resultaat geeft aan dat de eigenschappen aan de rechterkant van de join behoren tot de Heartbeat-tabel .