My logs went silent ,where do I start?

[noel_david]

• Summary
• Problem
• Troubleshooting steps
• What's next
• Related reading

Summary

 A structured first-response workflow for when logs that previously worked suddenly stop. Covers component health, SFM events, source verification, ingest-rule coverage, and ActiveGate scope checks.

Problem

Use this article when logs from a source that previously worked have suddenly stopped arriving in Dynatrace.

This is a first-response workflow. It does not cover logs that were never visible if the source has never appeared in Dynatrace, start with Log source not detected or not ingested: Troubleshoot source discovery and ingest-rule coverage instead.

Availability note: The Log module self-monitoring dashboard and SFM events are generally available at OneAgent version 1.339+ and SaaS version 1.340+. For earlier versions, SFM events require opt-in via the Settings API (builtin:logmonitoring.log-sfm-settings). Log Monitoring Classic customers can also opt in. Verify availability for the affected environment before following this workflow.

Troubleshooting steps

Check the source first.

1. Open the original log file, container output, or upstream system.
2. Confirm it contains records written after the issue started.
3. Record the exact source timestamp and timezone of a recent record.
4. Check whether any of the following changed recently:
   • File path, file name, or log destination
   • Application logging configuration
   • File ownership, permissions, or mount/volume configuration
   • Encoding, compression, or rotation behaviour
   • Timestamp format or timezone
   • Host, container identity, or Kubernetes workload

If the source itself has stopped writing records, the issue is in the application or logging framework investigate that first.

---

Step 1: Open the Log module self-monitoring dashboard

The Log module self-monitoring dashboard is the fastest way to see whether Dynatrace has already detected the problem and raised an event.

Note: From Dynatrace version 1.342+, SFM event tiles will be built into the Log ingest overview dashboard. Until then, import the dashboard manually  see Monitor log source health with SFM events for the JSON import instructions.

On the dashboard, look at:

• Currently active issues (24 hours)  grouped by severity (ERROR, WARN, INFO) and event type
• Active issues – host-based log modules  start time, event type, affected file path, host, and process entity
• Active issues – Kubernetes log modules affected container or Kubernetes entity

If an event is listed for the affected source or host, go to Step 2 to act on it.

If no event is listed, go to Step 4.

---

Step 2: Read the SFM event and match it to the remediation below

SFM events are stored in Grail. To retrieve them directly:

fetch dt.system.events

Filter by the affected entity or log source as needed.

Each event includes context: the affected log source path or host ID, and a condition type. Act only on the condition the event actually reports  do not assume a common cause without reading it.

SFM event quick-reference

Source status (log_source.status INFO)

Generated for every known log source. Use log.source.file_status and log.source.ingest_status to decide what to do.

file_status value	Action
OK	File is accessible check ingest_status and ingest rules
Not Exist (custom source only)	Check the file path pattern for typos; verify the Log module filesystem access; check dtuser (Linux) or OneAgent service account (Windows) permissions
Binary	Check for binary content in matched files; adjust the custom log source pattern or enable Allow binary files if binary content is intentional
Sensitive Masking Timeout	See ingest.masking_timeout below

If ingest_status is not as expected, review the active and inherited ingest rules:

• Rules are evaluated top-to-bottom; the first match wins
• The effective rule list concatenates rules from all configuration scopes
• The log source matcher matches the log source name, not the file path (e.g. /path/a.2026.log does not match a source named /path/a.#.log)

 

Timestamp events

Event type	Severity	Action
timestamp.no_pattern	WARNING	Configure a non-standard timestamp format in log monitoring settings, or rely on Log module timestamping; review boundary detection if multiline records are present
timestamp.multiple_patterns	INFO	No action if expected; configure the timestamp format explicitly if the Log module misidentifies message content as a timestamp
timestamp.invalid_timezone	ERROR	Correct the timezone configuration in log monitoring settings to match the timezone the source writes in

 

Ingest pipeline events

Event type	Severity	Action
ingest.access_flag	WARNING	Run oneagentctl --set-app-log-content-access=true on the affected host; for a new deployment, enable the flag during installation
ingest.masking_timeout	ERROR	Review masking rules for the source  the most likely cause is an inefficient regular expression; ingestion resumes after correcting the configuration or restarting the Log module
ingest.log_source_blocked	WARNING	Review OneAgent security rules and adjust them to permit access to the blocked path

 

Data loss events

Event type family	Severity	Action
data_loss.network	ERROR/WARNING	Review network connectivity between the Log module and its delivery endpoint (Environment ActiveGate or Dynatrace endpoint); check for interruptions during the affected window
data_loss.* (general)	ERROR/WARNING	Read the full event for the specific condition; do not assume a sub-type without reading it

 

Process group events

Event type	Severity	Action
pgi.multiple_pgis	WARNING	Determine if intentional (shared sink log file) or unintentional (PGI transition); refine the custom log source definition or process group configuration if unintentional
pgi.lgi_explosion	ERROR	Create a custom log source rule with a wildcard pattern covering all log files written by the process group instance

---

Step 3: Apply the remediation and validate

After applying the fix:

1. Write a unique, identifiable test record to the original source.
2. Record its source timestamp and timezone.
3. Wait for the next Log module polling cycle.
4. Check whether the same SFM event is still active on the dashboard.
5. Search for the test record in the Logs app, filtered by host, workload, or source.

---

Step 4: If no SFM event is active

Check source coverage:

Settings app > Collect and capture > Log monitoring > Configure log module > Sources

Confirm whether the source is:

• Listed under the expected entity
• Covered by an active or inherited ingest rule
• Matched by a rule whose scope and matcher correspond to the current source attributes

If the source is missing or uncovered, continue with Log source not detected or not ingested: Troubleshoot source discovery and ingest-rule coverage.

---

Step 5: Check for short, unexplained gaps

The OneAgent Log module has built-in resilience. A dedicated watchdog process monitors the Log module: if it does not respond within 15 minutes, the watchdog restarts it. Restart retry delays start at 10 seconds and double on each failure, capping at 1 hour. The delay resets after the module runs successfully for 20 minutes. There is no limit on restart attempts.

Short, isolated ingestion gaps without a persistent SFM event can indicate a module restart cycle. If logs resumed without configuration changes and no event persists, a restart is a likely explanation. No action is required unless the gap is recurring or the SFM dashboard shows persistent issues.

---

Step 6: If an Environment ActiveGate is involved

If the affected source uses an Environment ActiveGate and multiple sources on the same ActiveGate are affected simultaneously:

• Check ActiveGate connectivity and health
• Review resource pressure on the ActiveGate during the incident window
• Consult the official sizing guidance: ActiveGate resource management and sizing for Kubernetes

If only one source through the ActiveGate is affected, continue with source-level investigation.

What's next

Opening a support case with below details 

• Environment, region, and deployment type (SaaS / Managed)
• Affected host, host group, Kubernetes cluster, namespace, workload, or source path
• Approximate start time and timezone
• Screenshot or export from the Log module self-monitoring dashboard showing active issues
• Exact SFM event type, severity, and any source or entity context from the event
• Source coverage state from the Sources view
• Applicable active and inherited ingest rules with matchers and scopes
• Sanitized sample record from the affected source
• Confirmation that the original source writes new records
• Unique-record test result (found / not found)
• Recent changes: application, logging, permissions, path, encoding, rotation, deployment, or Dynatrace configuration
• OneAgent, Dynatrace Operator, and Environment ActiveGate versions

Related reading

• Monitor log source health with SFM events
• Log module self-monitoring events – Log Monitoring Classic
• Log source not detected or not ingested
• Improve log ingest health with smarter log management
• Dynatrace Logs Troubleshooting Map