Collect notification history and various metrics from your Cloudflare accounts.





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 Cloudfare 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 Cloudfare 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 for obtaining the extension, only for the data (metrics & events) that the extension ingests.
The details of license consumption depend on which licensing model you are using:
License consumption is based on the number of metric data points ingested. The following formula will provide approximate annual data points ingested by feature set. Note that many of these depend on the nature of the traffic being recieved by Cloudflare and so may change significanly over time.
Feature sets:
DNS Analytics
((1 * <dnsQueryLocation> * <dnsQueryResponseCode>)) * 525.6
HTTP Traffic
(6 + (1 * <sslProtocolVersion>) + (1 * <edgeResponseContentType) + (4 * <clientCountryName>) + (1 * <edgeResponseStatus>) + (1 * <threatPathingName)) * 525.6
Workers
((15 * <scriptName> * <status> * <usageModel> * <environmentName>) * 525.6
Log records will be ingested for notifications in the notification history of monitored Cloudflare accounts.
Log management and analytics (powered by Grail):
License consumption is based on the size (in bytes) of data ingested & processed, retained, and queried so there is not a single formula to estimate the total consumption from this extension. Consult the log management and analytics documentation for details on the other dimensions that will effect license consumption.
Classic licensing:
In the classic licensing model, log record ingestion will consume Davis Data Units (DDUs) at the rate of 100 DDUs per Gigabyte of log records ingested.
In log monitoring classic, license consumption is based on the number of ingested log records.
In the classic licensing model, log record ingestion will consume Davis Data Units (DDUs) at the rate of .0005 DDUs per ingested log record. To estimate DDU usage from log records, multiply estimated ingested log records by .0005.
When activating your extension using 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 |
|---|---|---|
| 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 |
|---|---|---|
| Number of Cloudflare notifications | cloudflare.notifications | The number of notifications that have been pulled from Cloudflare |
| Metric name | Metric key | Description |
|---|---|---|
| DNS query count | cloudflare.dns.queries | Total DNS queries |
| 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 |
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.