Docs

Volcengine Kubernetes Engine

Network observation

DNS service observability

DNS is the foundation of service discovery in Kubernetes clusters, and the performance and stability of cluster DNS service discovery are closely related to application quality. This topic describes how to configure DNS service observability.

Background information

In large-scale scenarios, a large number of DNS requests can put significant pressure on DNS add-ons in the cluster, which causes increased DNS latency and subsequent impact on application performance. Therefore, you need to leverage the cluster observability capabilities to promptly gain insights into the operational status of the DNS add-ons in the cluster, receive alerts, and take corrective actions when necessary.

VKE supports the CoreDNS add-on and the NodeLocal DNSCache add-on. They offer standard cluster DNS service discovery and node DNS cache proxy capabilities. The relevant add-ons include:

core-dns. The CoreDNS add-on delivers service discovery and domain name resolution services for the internal environment of the cluster.

node-local-dns. The NodeLocal DNSCache add-on (a caching solution) provides DNS cache proxy capabilities for nodes, improving the performance and stability of DNS service discovery across the entire cluster.

tip

For more information about the add-ons, see Managing add-ons.

Prerequisites

Cloud-native observability has been enabled. For details, see Enabling observability.

The VKE observability feature has been enabled. For details, see VKE observability.

The core-dns or node-local-dns add-on has been installed. For details, see core-dns and node-local-dns.

(Optional) An alert notification policy has been created in the Observability Platform or VMP. For details, see Creating notification policies and Creating alert notification policies.

(Optional) An alert aggregation policy has been created in the Observability Platform or VMP. For details, see Creating aggregation policies and Creating alert aggregation policies.

Enabling observability

Step 1: Configure observability items

In the left navigation bar, click Cluster. Find the target cluster and click its name.

In the left navigation pane of the cluster management page, click Observability settings, and select the Basic observability tab.

Find the DNS service card and click Enable observation to go to the observability item configuration page.

The system automatically checks the necessary conditions for enabling observability, such as the workspace configuration and add-on status.

For the Observation item parameter, select observability items for which you want to collect metrics. For items for which metric collection is not enabled, the system will not collect the corresponding metrics, and the system will prompt you to install the related add-ons. You can decide whether to install the related add-ons and select the corresponding observability items based on your business requirements.

After the configuration is complete, click Next to go to the metric configuration page.

Step 2: Configure metric collection

On the metric configuration page, view the collection interval and metric quantity corresponding to the enabled observability items.

Click Edit metrics. This enables you to select or discard specific metrics of the add-on, modify the collection interval, and configure metric relabeling.

For Collection interval, select a collection interval for the metrics of the add-on. The supported collection intervals vary for different add-ons.

In the metric list, select a metric to collect. To stop collecting a metric, uncheck it. Click the All, Basic metrics, or Other metrics tab to filter metrics by type.

tip

The impact of adjusting the metric collection interval is as follows. Adjust the interval as needed:

Reducing the collection interval: This increases the number of metrics reported per unit time and improves monitoring accuracy. However, the cost of standard VMP workspaces increases.

Increasing the collection interval: This decreases the number of metrics reported per unit time and lowers the cost of standard VMP workspaces. However, this decreases monitoring accuracy.

Cloud service metrics are categorized into Basic metrics and Other metrics. The billing method varies based on different types of metrics. For details, see VMP billing.

In the metricRelabelings section, click Add rule to configure metric relabeling rules. This allows you to rewrite the labels of each metric after collection and before writing to storage. Common use cases include modifying label values, adding new labels, and renaming labels to standardize label naming for queries. For details, see Metric relabeling.

No.	Feature	Replacement value	Description
①	Action type	action	The action to apply to the metrics. Currently, only replace is supported. The logic is as follows: If the values of targetLabel and sourceLabels are the same, sourceLabels is overwritten. If the key specified by targetLabel does not exist, a new label is created by default.
②	Source labels	sourceLabels	Specify one or more source labels, separated by \| if multiple labels are provided. The system reads the values of these labels for matching or extraction.
③	Regular expression	regex	The regular expression pattern used to match source label values. The default is (.*), which matches any value. You can use capture groups such as (.+) to extract partial content.
④	Replacement value	replacement	The value written to the target label after a successful match. The default is $1, which refers to the content of the first capture group in the regular expression. A fixed string is also supported.
⑤	Target label	targetLabel	The name of the target label to which the processing result is written. If the target label already exists, its existing value is overwritten. If the target label does not exist, a new label is created.

After the configuration is complete, click Next to go to the alert and notification configuration page.

Step 3: Configure alerts and notifications

In the Alert and notification step, select the platform to receive alerts. Currently, Unified Alert Center and The original VMP alarm strategy are supported.

For the Notification strategy name parameter, select the created alert notification policy and specify the notification object and Notification method parameters based on different alert levels.

tip

If you do not need to configure alerts for a certain level, you can unselect the corresponding alert level.

If the existing notification policies do not meet your needs, you can select vke_default_notify_policy (automatically created) for the Notification strategy name parameter, and specify the notification object and Notification method parameters for the required alert levels. After you save the configuration, the system will automatically create a custom notification policy named vke_default_notify_policy in the unified Alert Center or VMP.

In the Alerting aggregation policy section, select the created alert aggregation policy.

Configure preset alert rules.

Enable or disable the switch next to a preset alert rule. After it is enabled, the system detects metrics based on the configured trigger conditions and generates alerts. When it is disabled, the rule will no longer trigger new alerts.

Click View PromQL to view the description and corresponding PromQL statement of the current preset alert rule.

Click the name of the preset rule that you want to configure to expand the preset alert rule configuration page, and configure the trigger conditions for alerts of different levels (P0, P1, or P2) in the Triggering condition section.

Parameter	Description
Alert level	Select the check box in the Enable column that corresponds to each alert level (P0, P1, or P2) to activate its trigger condition. If you do not select an option, alerts at this level are not configured.
Comparison condition	Specify the comparison condition between the PromQL statement and the threshold. You can configure multiple comparison conditions, including Greater than, Greater than or equal to, Less than, Less than or equal to, Equal to, and Not equal to.
Threshold	Configure the metric threshold.
The duration of the condition	Configure the duration for which the metric continuously meets the trigger condition. The system triggers the alert at the corresponding level only if the metric continuously meets the comparison condition within this duration.
Label	Configure the label of the alert rule. It is mainly used for alert identification, grouping, deduplication, and routing matching. A label consists of a key and a value. Where: Key: A string. It can start with a letter or an underscore (_), but cannot start with a double underscore (__). It can contain letters, digits, and underscores (_) and can be 1 to 256 characters in length. Value: A string. It can contain Chinese characters, English letters, digits, and special characters, and can be 1 to 512 characters in length. Common configuration example: labels: severity: critical # The alert level. business: pay # The business line. alert_type: resource # The alert type.
Annotation	Configure the annotation of the alert rule. It is mainly used to display key information. An annotation consists of a key and a value. Where: Key: A string. It can start with a letter or an underscore (_), but cannot start with a double underscore (__). It can contain letters, digits, and underscores (_) and can be 1 to 256 characters in length. Value: A string. It can contain Chinese characters, English letters, digits, and special characters, and can be 1 to 512 characters in length. Common configuration example: annotations: summary: "High CPU usage on instance {{ $labels.instance }}" description: "Current CPU usage is {{ $value \| humanizePercentage }}, threshold is 80%" runbook_url: "https://xxx/docs/cpu-alert" dashboard_url: "https://grafana/xxx"

Click Complete the configuration.

Description

In addition to using preset alert templates to configure alert rules directly, you can customize the template configurations or directly use PromQL statements to configure alert rules. For details, see Alert configuration overview.

Details of the preset alert rule templates, including rule descriptions, PromQL configurations, and common alert handling procedures. See Preset alert templates.

Observability dashboards

tip

The built-in dashboards provide features such as period-over-period comparisons of monitoring data and the ability to copy dashboard queries. For details, see Usage of dashboards.

core-dns monitoring

You can query the monitoring information for all or specified core-dns instances. This information includes DNS requests, DNS error rates, DNS forwarding, and DNS cache hit rates. You can specify a custom time range for querying information and set the information refresh mode to manual refresh or automatic refresh.

In the left navigation pane of the cluster management page, click Monitoring center > Dashboard.

In the left dashboard list, click Network services monitoring > Core-DNS monitoring to view the monitoring dashboard.

node-local-dns monitoring

You can query the monitoring information for all or specified node-local-dns instances. This information includes DNS requests, DNS error rates, DNS forwarding, and DNS cache hit rates. You can specify a custom time range for querying information and set the information refresh mode to manual refresh or automatic refresh.

In the left navigation pane of the cluster management page, click Monitoring center > Dashboard.

In the left dashboard list, click Network services monitoring > Node-local-dns monitoring to view the monitoring dashboard.

View metrics

To query integrated or non-integrated metrics in the cluster, or to understand metric meanings, see Querying metrics.

You can use the Explore feature of VMP to quickly query and display metric data. For details, see Querying metrics.

Last updated: 2026.10.22 17:24:38