Monitor log source health with SFM events

• Latest Dynatrace
• How-to guide
• 11-min read
• Updated on Aug 26, 2026

OneAgent version 1.333+

The Log module features a built-in self-monitoring and troubleshooting functionality. The functionality is called Log module self-monitoring events (SFM events).

The Log module provides the list of monitored log sources along with their statuses and metadata. The log source status shows whether a log source is detected correctly and is configured to be ingested, as well as informs about the source type (for example, whether a log source was detected automatically or provided by a user).

The functionality also warns about suspicious issues and malfunctions. In case such an issue appears, the context (for example, the log source name or host ID) is provided along with the information on where to find more help and how to examine and solve the issue. Each type of a malfunction is communicated using a specific SFM event type.

Availability and state

Prerequisites

Configure SFM events via API

SFM events are enabled by default. To customize this functionality, update your configuration via the Settings API. Use the builtin:logmonitoring.log-sfm-settings schema ID. If you're familiar with configuring log ingest rules, the same workflow applies here.

Prerequisites for SFM event configuration

Configuration scopes

You can configure SFM event rules for the following scopes:

We recommend configuring the SFM event rules at the highest appropriate scope for easier management. Use fewer, broader rules instead of many small, overlapping rules.

Exclude a particular SFM event type

If you've enabled all SFM events but need to exclude a particular SFM event type, create an additional exclusion SFM event rule.

This exclusion rule must have a higher priority than the rule that enables all SFM events. To add the exclusion rule at the top of the rule list, set insertAfter to an empty value in the payload. If you don't include the insertAfter parameter, the rule is placed at the bottom of the rule list and can be overridden by all other rules within the given configuration scope. See the POST an object parameters for more information.

Follow the instructions in Enable SFM events, but use the following example payload.

[
{
  "schemaId": "builtin:logmonitoring.log-sfm-settings",
  "scope": "tenant",
  "insertAfter": "",
  "value": {
    "enabled": true,
    "config-item-title": "Suppress warning about the absence of timestamp pattern",
    "send-to-storage": false,
    "matchers": [{ "attribute": "event.type", "operator": "MATCHES", "values": ["timestamp.no_pattern"]}]
  }
}
]

By creating this additional rule, you exclude the timestamp.no_pattern SFM event type on the tenant configuration scope.

There can be situations when you don't want to suppress an SFM event type everywhere, but you only want to suppress it for one log source you already know about, while still being notified if the same event occurs elsewhere.

For example, suppose one of your log sources, a.log, has no timestamp in its content. You're aware of that and don't want to be notified about it. However, you still want to be notified about the timestamp.no.pattern event for any other log source.

To do this, create an exclusion rule similar to the one above, but add a second matcher for log.source:

[
  {
    "schemaId": "builtin:logmonitoring.log-sfm-settings",
    "scope": "tenant",
    "insertAfter": "",
    "value": {
      "enabled": true,
      "config-item-title": "Suppress 'no timestamp pattern' warning only for a.log",
      "send-to-storage": false,
      "matchers": [
        { "attribute": "event.type", "operator": "MATCHES", "values": ["timestamp.no_pattern"] },
        { "attribute": "log.source", "operator": "MATCHES", "values": ["*a.log"] }
      ]
    }
  }
]

Both matchers must match for the rule to apply, so the event is suppressed only when its type is timestamp.no.pattern and its log source is a.log. The event is still raised for every other log source.

Delete all types of SFM events

To delete all SFM event types, use the DELETE an object endpoint. This operation doesn't require a JSON payload.

curl -X DELETE \
"<environment_url>/api/v2/settings/objects/<objectId>" \
-H "Authorization: Api-Token <token>"

To get the required object ID, use the GET objects endpoint.

Create or update SFM event rules

SFM events are enabled by default. If you've deleted your SFM event rules and want to re-enable them, follow these steps.

To create or update SFM event rules:

Explore the self-monitoring dashboard

Log module SFM events are stored in Grail under dt.system.events. The ready-made Log ingest overview dashboard provides a dedicated view with SFM sections: OneAgent log module for Hosts and OneAgent log module for Kubernetes.

To open the dashboard, go to Dashboards and search for Log ingest overview.

To query SFM events with DQL, use the following example:

fetch dt.system.events, from: now() - 24h
| filter event.provider == "Log Module" and event.type != "log_source.status"
| dedup event.id, sort: { timestamp desc }
| filter event.status == "Active"

Log ingest overview dashboard

The following filters apply only to the OneAgent log module sections of the dashboard:

Dashboard features

The OneAgent log modules area of the dashboard contains two sections based on Log module SFM events, one for each deployment type.

OneAgent log module for Hosts

The OneAgent log module for Hosts section helps you identify and investigate ingestion issues on hosts and VMs. It contains the following tiles:

OneAgent log module for Kubernetes

The OneAgent log module for Kubernetes section helps you identify and investigate ingestion issues on Kubernetes log sources. It contains the same Currently active issues (last 24h), Self-monitoring events over time, and Log sources status over time tiles as the Hosts section above, plus the following Kubernetes-specific tiles:

Use SFM events to resolve log-related issues

The SFM event types and required actions are described below.