Summary
Determine whether a source is producing records, autodiscovered by Dynatrace, and covered by the intended active or inherited ingest rule.
Use this article when an expected log source isn't shown in Dynatrace, or when the source is autodiscovered but isn't covered by an ingest rule.
The Sources tab in the Log Module configuration provides an environment-level view of autodiscovered host groups, Kubernetes clusters, hosts, and log sources. It also shows source coverage and allows active and inherited rules to be reviewed together
Problem
You might observe one or more of the following symptoms:
- The expected file or source isn't listed anywhere in Dynatrace.
- One host discovers the source while another doesn't.
- A source disappeared after a path, deployment, or permission change.
- The source is shown but isn't covered by an ingest rule.
- A rule exists, but it applies at an unexpected scope.
- Logs stopped after a matcher or source-attribute change.
Troubleshooting steps
Treat source availability, discovery, and ingestion as separate checks:
| Stage | Question | Where to check |
|---|---|---|
| 1. Source availability | Is the application or system creating new records? | The source system itself |
| 2. Source discovery | Does Dynatrace know the source exists? | Sources tab in Log module config |
| 3. Ingest-rule coverage | Is an applicable rule covering the source? | Sources tab — coverage column |
| 4. Record availability | Can the ingested record be found in Dynatrace? | Logs app |
Verify each stage in order. A source can pass stage 2 and still fail stage 3. Do not assume a detected source is automatically ingested.
Step 1: Confirm the source is active
- Confirm that the file, container output, or source exists on the system.
- Confirm that the application writes new records to it.
- Record the exact path or source identity.
- Generate a uniquely identifiable test record for example, write a known string such as
DT-TEST-1234to the source. - Confirm the test record appears at the original source before continuing.
If the source doesn't produce new records, investigate the application or logging framework first. Dynatrace cannot ingest what isn't written.
Step 2: Open the Sources tab
Open:
Settings app > Collect and capture > Log monitoring > Configure log module > Sources
Select the relevant host group, Kubernetes cluster, host, or workload. Search for the expected source path or name.
Step 3: If the source is not detected
If the source does not appear in the Sources tab, the Log module has not discovered it. Compare the source with the monitored entity and review the following verified change areas:
- Source path or file name change
- Application logging destination change
- Host, container, or workload identity change
- File ownership or permission change
- Mount or volume configuration change
- Remote or network filesystem (disabled for log monitoring by default)
- Log Monitoring security rules blocking the path
- Custom source configuration path pattern typos, filesystem scope mismatch
Use these existing articles when applicable:
- Enable Log Visibility in Dynatrace for initial enablement checks
- Troubleshooting Missing Log Files Due to OneAgent Log Monitoring Security Rules when a security rule may be blocking the path
- Troubleshooting Missing Logs in Log Module for individual sources missing from the Log module
After correcting a verified discovery condition, generate another unique test record and check whether the source appears in the Sources tab.
Step 4: Use SFM events to confirm discovery state
If SFM events are enabled (OneAgent 1.339+ / SaaS 1.340+), query the current state of the source directly without navigating the Settings UI:
fetch dt.system.events
| filter event.type == "log_source.status"
| filter log.source == "/var/log/your-expected-source.log"
Key attributes returned:
| Attribute | What it tells you |
|---|---|
log.source.file_status |
OK, Not Exist, Binary, or Sensitive Masking Timeout |
log.source.ingest_status |
Fully ingested, Partially ingested, or Not ingested |
log.source.origin |
Automatically detected or Custom log source |
- No results returned → the source has not been discovered at all. Continue with Step 3.
file_status: Not Exist→ the Log module knows the source name but cannot find the file. Check path, permissions, and filesystem access.ingest_status: Not ingested→ the source is discovered but not covered by a rule. Continue with Step 5.
Note: SFM events are reported with a delay of up to 90 seconds from the actual state change.
Step 5: If the source is detected, review coverage
If the source appears in the Sources tab but is not covered, no ingest rule applies to it. Records are not being collected.
- Review the source attributes shown in the Sources view.
- Identify the intended ingest rule.
- Compare its matcher with the current source attributes.
Critical distinction: The log source matcher matches the log source name, not the file path.
- Example: a matcher
/path/a.2026.logdoes not match a source named/path/a.#.log, even if the file/path/a.2026.logexists in the filesystem.
- Review the rule's scope confirm it applies at the correct level (environment, host group, host).
- Correct or create the rule according to the intended collection policy.
Step 6: Review active and inherited rules together
The effective rule list for any source is a concatenation of all rules from all applicable configuration scopes environment, host group, and host. Rules are evaluated top-to-bottom and the first match decides the outcome. For more details check here.
When reviewing coverage, confirm:
- The expected rule is present at the expected scope
- Its matcher matches the current source name (not the file path)
- Its scope corresponds to the intended entity
- No higher-priority rule from a broader scope overrides it with an exclude action
- A recent matcher, source, or deployment change did not break the match
Avoid broadening a matcher just to make one test source appear. Confirm the intended policy and scope first.
Step 7: Validate with a unique record
- Write the unique test string to the source (e.g.,
DT-TEST-1234). - Record the source timestamp and timezone.
- Wait for the next Log module polling cycle.
- Search for the unique string in the Logs app.
- Filter by the affected host, workload, or available source attributes.
- Confirm the record's timestamp and source attributes match what you expect.
Step 8: If the source is covered but the record is still missing
If coverage is confirmed but records still don't appear, continue based on the observed symptom:
| Symptom | Next step |
|---|---|
| Unhealthy component or source status event | My logs went silent where do I start? |
| Records arrive but with a delay | Troubleshooting Log Ingest Delay in Log Module |
| Rotation-related gaps or duplicates | Troubleshooting Log Rotation Issues in Log Module |
| Timestamp or boundary issues | Timestamps in Logs with OneAgent 1.313+ |
| Records visible but content, attributes, or timestamps are wrong | What do log ingest warnings on my records mean? |
What's next
- Opening a support case with below details
- Exact or sanitized source path or source name
- Affected host, host group, Kubernetes cluster, namespace, or workload
- Confirmation that the source writes new records
- Screenshot or details from the Sources tab showing coverage state
- Applicable active and inherited rules with matchers and scopes
- SFM
log_source.statusquery result for the affected source (if SFM is enabled) - Sanitized sample record
- Unique-record search result (found / not found, with timestamp)
- Recent changes: application, deployment, permissions, file path, or Dynatrace configuration
- Applicable OneAgent version or Dynatrace Operator version
Related reading
- Monitor log source health with SFM events
- Log module self-monitoring events Log Monitoring Classic
- My logs went silent where do I start?
- Improve log ingest health with smarter log management
- Dynatrace Logs Troubleshooting Map
