Log Monitoring Classic
Dynatrace Log Monitoring gives you the ability to create log events based on log data and use them in problem detection.
Log event pricing is based on the Davis data units (DDUs) model. Check DDUs for custom Davis events to find out how you can estimate and track DDU consumption for log events.
When Dynatrace ingests log data, it applies the query specified in the log event definition. Every matched occurrence triggers a log event that can be configured to individually create a problem for each triggered log event or can be merged into one problem.
Go to Settings > Log Monitoring > Events extraction and select Add log event.
Enter the Summary.
The summary acts as the display name of the log event configuration. The summary must be unique for all configurations.
Enter the Log query.
Enter the Log Monitoring query to filter the log data for your log event. For details, see Log viewer.
If you switched to Dynatrace Grail, you may begin using the DQL functions in your Log Monitoring queries. For details, see Log processing.
Configure the Event template.
Provide the Title of the event to trigger. If this log event triggers a problem, this title will also be the title of the problem.
Provide the Description of the event. Note that you can have one or more placeholders in the description (see Placeholders below for details).
Select the Event Type. Event types indicate the severity of the event. See Settings API - Log events schema table.
Choose whether to Allow merge.
If two or more events are triggered, Dynatrace could merge these events into a single problem. This option lets you choose to disable this behavior, which can result in more reported problems.
Add Properties.
A property is a key/value pair that is set on every triggered event. You can have one or more placeholders as a value that will be extracted from the log data. For example, a property with Key set to PGI
and a Value of placeholder {dt.entity.process_group_instance}
will extract the process group instance value from log data once the event is triggered. If the placeholder substitution fails, both the key and the value will not be available.
To see how to get the full list of properties, go to Events API v2 - GET all event properties. The description
field in the API response body explains how each property works. For example: In the dt.event.allow_davis_merge
, the description says :"Allow Davis AI to merge this event into existing problems (true) or force creating a new problem (false)"
.
Log events have a default timeout of 15 minutes. The timeout defines how frequently the event source must refresh the log event to keep it active. The maximum time allowed for a log event is six hours.
15
minutes).To set a custom timeout
dt.event.timeout
.12
).To verify that a custom timeout was added for an event triggered on the host level
Placeholders are log entry attributes that can be used to extract the actual value from the log data.
{dt.process.name}
).In this example, we create a log event based on ingested log data. This log event will be triggered when the ingested log entry matches the log query. The log query will search for status error
on the 555f5555-555a-5dd5-55f555a5b55d
host. We add log event properties (attributes) that will extract values from the log data and include it in the problem summary.
syslog-agent log event
status="error" AND host.name="555f5555-555a-5dd5-55f555a5b55d"
[Log] log events demo
{content}
Custom alert
K8 Id
with value {dt.kubernetes.config.id}
Process Name
with value The process name is -> {dt.process.name}
If a match is found, this log event will create a problem with each triggered log event.
The problem created as a result of a triggered log event will contain the information mapped from your log event configuration. The problem title is the Event title and the impact section reflects your Event type settings and additional information you configured in the description and properties of the log event.
Note that, in this example, while we have configured two properties (K8 Id
and Process Name
), only one appears on the problem page. This is because only the {dt.process.name}
placeholder had a value in the ingested log data. The {dt.kubernetes.config.id}
value was not found in that particular log entry and the defined property was ignored.