Monitor Cloudflare edge network performance with HTTP traffic, DNS analytics, Workers metrics, firewall events, and notification history.
The Cloudflare platform is built to improve the security, performance, and reliability of systems connected to the internet, primarily by serving as a reverse proxy for your web traffic. Your traffic flows through Cloudflare, where rules and optimizations are applied to meet its goals. Because of its position, Cloudflare has great visibility into your traffic and web performance.
Through the Cloudflare extension, Dynatrace can collect this information and make it available in Dynatrace for use monitoring and analytics purposes in context with the rest of your Dynatrace information.
The Dynatrace Cloudflare extension queries various APIs to collect notification history and various metrics from your Cloudflare accounts for ingestion into Dynatrace.
Find Cloudflare in the in-product Extensions or Hub page and activate (if offline, you can download the extension from this Hub page in the Release notes section and install as you would a custom extension).
Once the extension is activated in your environment, you can create monitoring configurations. Each monitoring configuration can have one or more Cloudflare account.
Select the ActiveGate group that will run the monitoring configuration.
API Token
Account.Account Settings, Account.Account Analytics, and Zone.Analytics permissions for the desired accounts.Accounts
Note: Multiple accounts can be monitored in one monitoring configuration, but they must share an API token for access
Notification retrieval frequency
Frequency that notifications will be retrieved from Cloudflare and reported. Set to 0 to disable. Applies to all configured accounts.
Review the available feature sets to determine which you want to enable and collect. The enabled feature sets will effect which APIs are called.
Review the list of feature sets to see which metrics are collected depending on the enabled feature sets.
Notification history: If enabled, a log event will be ingested for each notification event that shows up within your notification history.
There is no charge to use the extension. You are only charged for the data that the extension ingests.
The Cloudflare extension ingests custom metrics, which consume Davis Data Units (DDUs) (Dynatrace classic license) or Metrics powered by Grail (DPS), according to your license model.
License consumption is based on the number of metric data points ingested per minute by feature set. Note that many of these depend on the nature of the traffic being received by Cloudflare and so may change significantly over time.
DNS Analytics
(1 * <dnsQueryLocation> * <dnsQueryResponseCode>)
HTTP Traffic
6 + (1 * <sslProtocolVersion>) + (1 * <edgeResponseContentType>) + (4 * <clientCountryName>) + (1 * <edgeResponseStatus>) + (1 * <threatPathingName>)
Workers
15 * <scriptName> * <status> * <usageModel> * <environmentName>
Log records are ingested for notifications in the notification history of monitored Cloudflare accounts.
In the Dynatrace Platform Subscription, metric ingestion consumes Metrics powered by Grail according to the number of ingested metric data points.
To calculate the approximate yearly consumption, apply the following calculation: <metric data points per minute> * 60 minutes * 24 hours * 365 days.
For logs, regular consumption applies. See Log Management and Analytics.
In the classic licensing model, metric ingestion consumes Davis Data Units (DDUs) at the rate of .001 DDUs per metric data point. Multiply the above formula for annual data points by .001 to estimate annual DDU usage.
For logs, regular DDU consumption applies. See DDU consumption for Log Management and Analytics or DDUs for Log Monitoring Classic.
The DDU cost above does not include any possible log events or custom events that are triggered by the extension. For more information, see DDU events.
When activating your extension using a monitoring configuration, you can limit monitoring to one of the feature sets. To work properly, the extension has to collect at least one metric after the activation.
In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.
All metrics that aren't categorized into any feature set are considered to be the default and are always reported.
A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.
| Metric name | Metric key | Description |
|---|---|---|
| Number of Cloudflare notifications | cloudflare.notifications | The number of notifications that have been pulled from Cloudflare |
| Metric name | Metric key | Description |
|---|---|---|
| Total requests | cloudflare.http.total_requests | Total requests in this zone |
| Cached requests | cloudflare.http.cached_requests | Requests satisfied by the cache |
| Bytes | cloudflare.http.bytes | Total bytes returned to the client |
| Cached bytes | cloudflare.http.cached_bytes | Bytes returned to client from cache |
| Encrypted bytes | cloudflare.http.encrypted_bytes | Bytes returned to client using SSL/TLS protocol |
| Threats | cloudflare.http.threats | Requests classified as threats |
| Requests by SSL protocol | cloudflare.http.requests_by_ssl_protocol | Requests broken down by SSL protocol version |
| Requests by content type | cloudflare.http.requests_by_content_type | Requests broken down by retuend content type |
| Bytes by country | cloudflare.http.bytes_by_country | Bytes returned to client broken down by country |
| Requests by country | cloudflare.http.requests_by_country | Requests broken down by country |
| Threats by country | cloudflare.http.threats_by_country | Requests classified as threats broken down by country |
| Threats by pathing name | cloudflare.http.threats_by_pathing_name | Requests classified as requests broken down by threat type |
| Metric name | Metric key | Description |
|---|---|---|
| Worker requests | cloudflare.workers.requests | Total worker requests |
| Worker subrequests | cloudflare.workers.subrequests | Total worker subrequests |
| Worker errors | cloudflare.workers.errors | Total worker errors |
| Worker duration | cloudflare.workers.duration | Worker duration |
| Worker duration 50th percentile | cloudflare.workers.duration_p50 | Worker duration 50th percentile |
| Worker duration 99th percentile | cloudflare.workers.duration_p99 | Worker duration 99th percentile |
| Worker wall time | cloudflare.workers.wall_time | Worker wall time |
| Worker wall time 50th percentile | cloudflare.workers.wall_time_p50 | Worker wall time 50th percentile |
| Worker wall time 99th percentile | cloudflare.workers.wall_time_p99 | Worker wall time 99th percentile |
| Worker CPU time 50th percentile | cloudflare.workers.cpu_time_p50 | Worker CPU time 50th percentile |
| Worker CPU time 99th percentile | cloudflare.workers.cpu_time_p99 | Worker CPU time 99th percentile |
| Metric name | Metric key | Description |
|---|---|---|
| DNS query count | cloudflare.dns.queries | Total DNS queries |
Why do some of the metrics appear delayed?
Testing has shown that some APIs that have the minute-level data show up reliably only after several minutes. To avoid missing or partial data being reported, we query these types of metrics with a 5-minute delay.