Skip to content

Commit 23ad063

Browse files
ngayeriengayerie
authored
[Analytics] add Sentinel and Splunk troubleshooting pages (#33047)
* docs: add Sentinel and Splunk troubleshooting pages DEE-3780 Convert sentinel.mdx and splunk.mdx into folder-based sections and add a troubleshooting.mdx page for each. The support-scope callout is placeholder wording pending Product review. * docs(sentinel): recommend connector upgrade and cover CCF workbook - Fields missing/null: put 'upgrade the CCF solution' first, fall back to manual DCR/table edits. Mention BotDetectionIDs / dynamic. - New entry: CCF solution workbook does not populate (legacy Cloudflare_CL / CloudflareDataConnector references). * docs(sentinel): flag JSDetectionPassed and VerifiedBotCategory as unsupported * docs: align troubleshooting copy with style guide * docs: address troubleshooting review findings * docs(sentinel): link directly to Cloudflare CCF listing
1 parent 37ba133 commit 23ad063

4 files changed

Lines changed: 222 additions & 0 deletions

File tree

src/content/docs/analytics/analytics-integrations/sentinel.mdx renamed to src/content/docs/analytics/analytics-integrations/sentinel/index.mdx

File renamed without changes.

‎src/content/docs/analytics/analytics-integrations/sentinel/troubleshooting.mdx‎

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
---
2+
pcx_content_type: troubleshooting
3+
title: Troubleshooting
4+
description: Resolve common issues when integrating Cloudflare with Microsoft Sentinel.
5+
sidebar:
6+
order: 10
7+
products:
8+
- analytics
9+
- logs
10+
---
11+
12+
Use this guide to resolve common issues when integrating Cloudflare logs with [Microsoft Sentinel](/analytics/analytics-integrations/sentinel/) through the Codeless Connector Framework (CCF).
13+
14+
:::note[Support scope]
15+
Cloudflare Support can help you troubleshoot Cloudflare-side log delivery, including [Logpush](/logs/logpush/) job configuration. Configuring or troubleshooting your Microsoft Azure environment — including subscriptions, resource groups, role assignments, Log Analytics workspaces, or Data Collection Rules — is outside the scope of Cloudflare Support. Contact your Microsoft representative or your integration partner for assistance with those components.
16+
:::
17+
18+
## Connector deployment fails with `InternalServerError (HTTP 500)`
19+
20+
**Cause:** The Microsoft-managed service principal required by the Cloudflare CCF connector has not been provisioned in your Microsoft Entra ID tenant. This typically happens when the **Grant tenant-wide admin consent** button on the connector configuration page cannot complete the OAuth redirect — for example, due to browser extensions, a cached session, a conflicting signed-in account, a Conditional Access policy, or an unmet Multi-Factor Authentication (MFA) challenge.
21+
22+
**Fix:**
23+
24+
1. Confirm that the `Microsoft.SecurityInsights` resource provider is registered on your subscription:
25+
26+
```sh
27+
az provider show --namespace Microsoft.SecurityInsights --query "{state:registrationState}"
28+
```
29+
30+
The output should return `"state": "Registered"`.
31+
32+
2. In an **InPrivate/Incognito** browser session, sign in as a user holding one of these Microsoft Entra roles: **Privileged Role Administrator**, **Cloud Application Administrator**, **AI Administrator**, or **Application Administrator**.
33+
3. Open the direct tenant-wide admin consent URL for the Microsoft-managed application (App ID `4f05ce56-95b6-4612-9d98-a45c8cc33f9f`), replacing `{tenant-id}` with your Entra tenant ID:
34+
35+
```txt
36+
https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id=4f05ce56-95b6-4612-9d98-a45c8cc33f9f
37+
```
38+
39+
4. Complete the consent flow, including any MFA challenge.
40+
41+
**Verify:** Refresh the Cloudflare connector configuration page in Microsoft Sentinel. The **Service Principal ID** field should populate automatically, and the **Grant tenant-wide admin consent** button should no longer be displayed. Retry the connector deployment.
42+
43+
## Deployment fails with `InvalidTemplate` on `CreateDataFlowResources`
44+
45+
You see a deployment failure with an error similar to:
46+
47+
```txt
48+
Deployment template validation failed: 'The resource
49+
'Microsoft.Resources/deployments/CreateDataFlowResources'
50+
is not defined in the template.'
51+
```
52+
53+
**Cause:** The ARM template requires the Azure Blob Storage account and the Microsoft Sentinel workspace (and its underlying Log Analytics workspace) to reside in the **same Azure subscription and the same resource group**. When they are in different subscriptions or different resource groups, the nested `CreateDataFlowResources` sub-deployment cannot resolve the required resource references and validation fails.
54+
55+
A less common variant of this error occurs when the `Microsoft.EventGrid` resource provider is not registered in the target subscription.
56+
57+
**Fix:**
58+
59+
1. Confirm that both resources are co-located in the same Azure subscription and the same resource group. If they are not, redeploy or migrate them so they share both.
60+
2. Register the required resource providers on the target subscription:
61+
62+
```sh
63+
az provider register --namespace Microsoft.SecurityInsights
64+
az provider register --namespace Microsoft.EventGrid
65+
```
66+
67+
3. After deployment, confirm that the Microsoft-managed service principal holds these role assignments on the Storage account:
68+
- `Storage Blob Data Reader`
69+
- `Storage Queue Data Contributor`
70+
71+
4. Confirm that the Storage account's networking configuration allows the connector to access the Azure Storage Queue.
72+
73+
**Verify:** Redeploy the connector. The Deployments blade should show status **Succeeded**, and the connector should transition to **Connected**.
74+
75+
## Connector update fails with `Invalid output table schema`
76+
77+
You see a deployment failure with an error similar to:
78+
79+
```txt
80+
Failed to create required resources for data connector.
81+
Invalid output table schema: The following columns which exist
82+
in the current schema do not exist in the new schema or have
83+
different types.
84+
```
85+
86+
**Cause:** An earlier version of the Cloudflare CCF connector created a `CloudflareV2_CL` table in your Log Analytics workspace. When you deploy a newer connector version, the ARM template attempts to update this table schema. Azure Monitor rejects the update if the new schema omits columns that exist in the current table, or changes an existing column to an incompatible datatype.
87+
88+
**Fix:** Update the existing table schema directly through the Azure Monitor REST API before redeploying the connector. Run the update from Azure Cloud Shell using an account that holds the `Log Analytics Contributor` role on the workspace.
89+
90+
1. Download the latest `CloudflareV2_CL.json` schema definition from the Cloudflare CCF connector solution package (available in the [Microsoft Sentinel Content Hub](https://marketplace.microsoft.com/en-us/product/cloudflare.azure-sentinel-solution-cloudflare-ccf?tab=Overview)) and upload it to your Cloud Shell session.
91+
2. Request an Azure Resource Manager access token:
92+
93+
```sh
94+
az account get-access-token --resource https://management.azure.com/
95+
```
96+
97+
3. Apply the updated table schema, replacing the placeholders with your values:
98+
99+
```sh
100+
az rest --method PUT \
101+
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/tables/CloudflareV2_CL?api-version=2025-07-01" \
102+
--headers "Authorization=Bearer <access-token>" "Content-Type=application/json" \
103+
--body @CloudflareV2_CL.json
104+
```
105+
106+
**Verify:** The command returns the updated table definition as JSON. Redeploy the Cloudflare CCF connector — the deployment should complete without a schema validation error.
107+
108+
## Fields are missing or `null` in `CloudflareV2_CL`
109+
110+
**Cause:** The Data Collection Rule (DCR) schema is out of sync with the Cloudflare Logpush schema being delivered. Two variants are common:
111+
112+
- **Datatype mismatch:** A field is declared with the wrong Sentinel datatype in the DCR `streamDeclarations` — for example, a numeric field declared as `string`, or a variable-shape field such as `BotDetectionIDs` declared as anything other than `dynamic`. The record is ingested, but the mismatched column is populated with `null`.
113+
- **Reserved column name conflict:** A Cloudflare field name collides with a [Microsoft Sentinel reserved column name](https://learn.microsoft.com/azure/azure-monitor/logs/create-custom-table?tabs=azure-portal-1%2Cazure-portal-2%2Cazure-portal-3#add-or-delete-a-custom-column). For example, the Cloudflare Network Error Logging (NEL) dataset contains a `Type` field, but `Type` is reserved in Sentinel. Fields with reserved names cannot be stored under their original name.
114+
115+
**Fix:**
116+
117+
1. Upgrade the Cloudflare CCF solution to the latest version from the [Microsoft Sentinel Content Hub](https://marketplace.microsoft.com/en-us/product/cloudflare.azure-sentinel-solution-cloudflare-ccf?tab=Overview). New releases progressively correct field datatypes shipped by the connector and add support for new Cloudflare Logpush fields.
118+
2. If missing fields persist after upgrading — for example, because the DCR has been customized — apply a manual fix:
119+
- **For datatype mismatches:** Update the field's datatype in both the DCR `streamDeclarations` and the `CloudflareV2_CL` table definition to match the Cloudflare Logpush schema (for example, `real` for floating-point values such as `EdgeResponseCompressionRatio`, or `dynamic` for `BotDetectionIDs`).
120+
- **For reserved name conflicts:** Rename the field in the DCR `transformKql` transformation and add the renamed column to the `CloudflareV2_CL` table definition. For example, to preserve the NEL `Type` value:
121+
122+
```kusto
123+
source
124+
| extend NELType = Type
125+
| project-away Type
126+
```
127+
128+
Add a `NELType` column to `CloudflareV2_CL` with datatype `string`.
129+
130+
**Verify:** Send a fresh Logpush batch and query `CloudflareV2_CL` for the affected fields. Values should now be populated and no longer `null`.
131+
132+
:::note[Known unsupported fields]
133+
The `JSDetectionPassed` and `VerifiedBotCategory` fields are not currently ingested by the Cloudflare CCF connector, regardless of DCR or table configuration. Support for these fields requires changes to the connector implementation. This page will be updated when support is available.
134+
:::
135+
136+
## The Cloudflare CCF solution workbook does not populate
137+
138+
The Cloudflare workbook shipped with the CCF solution loads but shows no data, or its queries fail with an error indicating that the referenced table or connector does not exist.
139+
140+
**Cause:** In earlier releases, the workbook shipped with the Cloudflare CCF solution referenced the legacy `Cloudflare_CL` table and the legacy `CloudflareDataConnector`. The CCF connector ingests into `CloudflareV2_CL` through a parser, so workbook queries against the legacy table return no results even when logs are ingesting correctly.
141+
142+
**Fix:** Upgrade the Cloudflare CCF solution to a version whose workbook references the CCF connector's parser and the `CloudflareV2_CL` table. The latest solution release is available from the [Microsoft Sentinel Content Hub](https://marketplace.microsoft.com/en-us/product/cloudflare.azure-sentinel-solution-cloudflare-ccf?tab=Overview).
143+
144+
**Verify:** Reopen the workbook. Panels should populate with recent Cloudflare log data.
145+
146+
## Still not resolved
147+
148+
If your issue is not covered here:
149+
150+
- Consult the [Cloudflare CCF solution page](https://azuremarketplace.microsoft.com/marketplace/apps/cloudflare.azure-sentinel-solution-cloudflare-ccf) on the Azure Marketplace for the latest solution version and deployment prerequisites.
151+
- Review the [Cloudflare Logs change notices](/logs/reference/change-notices/) for recent schema changes that may affect your DCR or table definitions.
152+
- [Contact Cloudflare Support](/support/contacting-cloudflare-support/) for issues involving Cloudflare-side log delivery.
153+
- Contact your Microsoft representative or your integration partner for issues within your Azure environment.

src/content/docs/analytics/analytics-integrations/splunk.mdx renamed to src/content/docs/analytics/analytics-integrations/splunk/index.mdx

File renamed without changes.

‎src/content/docs/analytics/analytics-integrations/splunk/troubleshooting.mdx‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
---
2+
pcx_content_type: troubleshooting
3+
title: Troubleshooting
4+
description: Resolve common issues when analyzing Cloudflare Logs with the Cloudflare App for Splunk.
5+
sidebar:
6+
order: 10
7+
products:
8+
- analytics
9+
- logs
10+
---
11+
12+
Use this guide to resolve common issues when analyzing [Cloudflare Logs](https://www.cloudflare.com/products/cloudflare-logs/) through the [Cloudflare App for Splunk](/analytics/analytics-integrations/splunk/).
13+
14+
:::note[Support scope]
15+
Cloudflare Support can help you troubleshoot Cloudflare-side log delivery, including [Logpush](/logs/logpush/) job configuration. Configuring or troubleshooting your Splunk environment — including index administration, HTTP Event Collector (HEC) configuration, dashboards, or app deployment — is outside the scope of Cloudflare Support. Contact your Splunk representative or your integration partner for assistance with those components.
16+
:::
17+
18+
## Firewall Events carry incorrect `_time` values
19+
20+
Events under the `cloudflare:json` sourcetype for the Firewall Events dataset carry `_time` values that do not match the event's actual time, and `splunkd.log` shows entries similar to:
21+
22+
```txt
23+
WARN DateParserVerbose - Failed to parse timestamp.
24+
Defaulting to timestamp of previous event.
25+
```
26+
27+
**Cause:** In older versions of the Cloudflare App for Splunk, the `cloudflare:json` sourcetype extracts `_time` from the `EdgeStartTimestamp` JSON key, which only exists in HTTP requests logs. Firewall Events use a different key (`Datetime`), so timestamp extraction fails and Splunk silently falls back to the timestamp of the most recently indexed event.
28+
29+
**Fix:** Upgrade to the latest version of the [Cloudflare App for Splunk](https://splunkbase.splunk.com/app/4501/). The current release parses both `EdgeStartTimestamp` and `Datetime` under the `cloudflare:json` sourcetype.
30+
31+
If you cannot upgrade immediately, or if you maintain a customized `props.conf`, update the `cloudflare:json` stanza on your indexer or heavy forwarder to match both keys, then restart the Splunk service:
32+
33+
```conf
34+
[cloudflare:json]
35+
TRUNCATE = 100000
36+
TIME_PREFIX = "(?:EdgeStartTimestamp|Datetime)"\s*:\s*"
37+
TIME_FORMAT = %Y-%m-%dT%H:%M:%SZ
38+
MAX_TIMESTAMP_LOOKAHEAD = 150
39+
```
40+
41+
**Verify:** Newly indexed Firewall Events carry accurate `_time` values, and `DateParserVerbose` warnings no longer appear in `splunkd.log`. Events indexed before the fix retain their original `_time` values unless they are re-indexed.
42+
43+
## The Cloudflare Security (WAF) dashboard is empty
44+
45+
The `Cloudflare – Security (WAF)` dashboard in the Cloudflare App for Splunk loads without errors, but all panels are empty. Other dashboards (Overview, Performance, Reliability) populate normally, and running the WAF panels' underlying SPL directly in the search bar also returns zero results — even when WAF and security events are confirmed present in the target index.
46+
47+
**Cause:** In older versions of the Cloudflare App for Splunk, the WAF dashboard SPL references Cloudflare log fields that were [removed from the HTTP Requests dataset](/logs/reference/change-notices/2023-02-01-security-fields-updates/#http-requests-dataset-changes):
48+
49+
| Deprecated field | Current field |
50+
| :------------------------- | :------------------------ |
51+
| `FirewallMatchesRuleIDs{}` | `SecurityRuleIDs` |
52+
| `WAFRuleMessage` | `SecurityRuleDescription` |
53+
54+
Splunk does not raise an error when a search references a field that is absent from all indexed events — it completes the search and returns zero results, leaving every dashboard panel empty.
55+
56+
**Fix:** Upgrade to the latest version of the [Cloudflare App for Splunk](https://splunkbase.splunk.com/app/4501/). The current release references `SecurityRuleIDs` and `SecurityRuleDescription` throughout the WAF dashboard, saved searches, and macros.
57+
58+
If you maintain a customized fork of the app, replace all references to `FirewallMatchesRuleIDs{}` and `WAFRuleMessage` in your dashboard XML, saved searches, and macros with `SecurityRuleIDs` and `SecurityRuleDescription`, respectively.
59+
60+
**Verify:** Reload the `Cloudflare – Security (WAF)` dashboard. Panels should populate with recent WAF and security events. A direct search such as `index=<your-index> sourcetype=cloudflare:json SecurityRuleIDs=*` should also return matching events.
61+
62+
## Still not resolved
63+
64+
If your issue is not covered here:
65+
66+
- Consult the [Cloudflare App for Splunk page](https://splunkbase.splunk.com/app/4501/) on Splunkbase for the latest version and release notes.
67+
- Review the [Cloudflare Logs change notices](/logs/reference/change-notices/) for recent schema changes that may affect your searches or dashboards.
68+
- [Contact Cloudflare Support](/support/contacting-cloudflare-support/) for issues involving Cloudflare-side log delivery.
69+
- Contact your Splunk representative or your integration partner for issues within your Splunk environment.

0 commit comments

Comments
 (0)