This is an automated email from the ASF dual-hosted git repository.
cyyang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/hertzbeat.git
The following commit(s) were added to refs/heads/master by this push:
new 7dbdca849a [doc]: add monitoring documentation for various service
discovery methods (#3965)
7dbdca849a is described below
commit 7dbdca849ac7e6933f7d0a50fe740043afab8cde
Author: Logic <[email protected]>
AuthorDate: Thu Jan 15 21:27:42 2026 +0800
[doc]: add monitoring documentation for various service discovery methods
(#3965)
Co-authored-by: Yang Chen <[email protected]>
---
home/docs/help/consul_sd.md | 108 ++++++++++
home/docs/help/dns_sd.md | 223 ++++++++++++++++++++
home/docs/help/eureka_sd.md | 94 +++++++++
home/docs/help/http_sd.md | 228 +++++++++++++++++++++
home/docs/help/nacos_sd.md | 99 +++++++++
home/docs/help/zookeeper_sd.md | 122 +++++++++++
.../current/help/consul_sd.md | 108 ++++++++++
.../current/help/dns_sd.md | 223 ++++++++++++++++++++
.../current/help/eureka_sd.md | 94 +++++++++
.../current/help/http_sd.md | 228 +++++++++++++++++++++
.../current/help/nacos_sd.md | 99 +++++++++
.../current/help/zookeeper_sd.md | 122 +++++++++++
home/sidebars.json | 12 ++
13 files changed, 1760 insertions(+)
diff --git a/home/docs/help/consul_sd.md b/home/docs/help/consul_sd.md
new file mode 100644
index 0000000000..0b499eecb1
--- /dev/null
+++ b/home/docs/help/consul_sd.md
@@ -0,0 +1,108 @@
+---
+id: consul_sd
+title: Monitoring Consul Service Discovery
+sidebar_label: Consul Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring Consul service discovery]
+---
+
+> HertzBeat integrates with Consul registry to automatically discover service
instances and create monitoring tasks for them.
+
+### Overview
+
+Consul Service Discovery allows HertzBeat to connect to your Consul server and
automatically discover all registered service instances. When a new service
instance is registered or an existing instance goes offline, HertzBeat will
automatically create or delete corresponding monitoring tasks, achieving
automated monitoring in microservice environments.
+
+### PreRequisites
+
+#### Deploy Consul Server
+
+1. Deploy Consul server according to [Consul official
documentation](https://www.consul.io/docs/install).
+2. Ensure Consul server is accessible from HertzBeat.
+3. Verify that you can access Consul UI at `http://your-consul-server:8500/ui/`
+4. Ensure the Consul HTTP API is accessible (default port: 8500)
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|--------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique. |
+| Consul Host | Consul server IP address or domain name. Note⚠️Without
protocol header (eg: https://, http://). Example: `consul-server` or
`192.168.1.100` |
+| Consul Port | Port provided by the Consul server. The default is
8500 |
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds. |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here. |
+
+### Usage Steps
+
+1. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **Consul Service Discovery**
+ - Fill in the basic configuration parameters
+
+2. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - For example: If discovered instances are HTTP services, you can select
HTTP monitoring template
+ - Common template types: Port, HTTP, HTTPS, Ping, etc.
+
+3. **Automatic Discovery**
+ - HertzBeat will periodically query Consul server based on the collection
interval
+ - Automatically create monitoring tasks for newly registered service
instances
+ - Automatically delete monitoring tasks for offline service instances
+
+4. **View Discovered Instances**
+ - In the monitoring list, you can see all automatically created
sub-monitoring tasks
+ - Each sub-monitoring task corresponds to a discovered service instance
+
+### Example of usage
+
+Suppose your Consul server is running at `192.168.1.100:8500`, and you want to
automatically monitor all service instances registered in it.
+
+Configuration example:
+
+- **Target Name**: `Consul-Service-Discovery`
+- **Consul Host**: `192.168.1.100`
+- **Consul Port**: `8500`
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring (to detect instance
availability)
+
+After configuration:
+
+1. HertzBeat connects to Consul server via HTTP API
+2. Retrieves all registered service instances
+3. Automatically creates Port monitoring for each instance (e.g.,
`api-service-192.168.1.101:8080`)
+4. Every 60 seconds, checks for newly registered or offline services and
updates monitoring tasks accordingly
+
+### Notes
+
+- **Network Connectivity**: Ensure HertzBeat can access the Consul server
address and port (default: 8500)
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses, you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Recommended minimum interval is 60 seconds to avoid
excessive requests to Consul server
+- **ACL Token**: If Consul is configured with ACL (Access Control List), you
may need to configure the appropriate token
+- **Service Health**: Consul service discovery will discover both healthy and
unhealthy instances
+- **Datacenter**: By default, discovers services in the local datacenter. If
you need to discover services in a specific datacenter, additional
configuration may be required
+- **Instance Naming**: Automatically created monitoring tasks are named in the
format: `{ServiceName}-{Host}:{Port}`
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Microservice Architecture**: Automatically monitor all microservice
instances registered in Consul
+- **Service Mesh**: Monitor services using Consul Connect service mesh
+- **Multi-Datacenter**: Monitor service instances across multiple Consul
datacenters
+- **Dynamic Scaling**: Automatically adapt to service instances added/removed
due to autoscaling
+- **Health Check**: Combine with Consul's health check mechanism to monitor
service health status
+- **Service Governance**: Centrally manage monitoring of all services in the
Consul service ecosystem
+
+### Integration with Consul Features
+
+- **Service Health**: Consul service discovery can leverage Consul's health
check information
+- **Service Tags**: Service instances discovered from Consul may include tag
information
+- **KV Storage**: Can be used in conjunction with Consul KV storage to achieve
more flexible service discovery
+- **Service Mesh**: Supports service discovery in Consul Connect service mesh
environment
diff --git a/home/docs/help/dns_sd.md b/home/docs/help/dns_sd.md
new file mode 100644
index 0000000000..005415d252
--- /dev/null
+++ b/home/docs/help/dns_sd.md
@@ -0,0 +1,223 @@
+---
+id: dns_sd
+title: Monitoring DNS Service Discovery
+sidebar_label: DNS Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring DNS service discovery]
+---
+
+> HertzBeat integrates with DNS service to automatically discover service
instances through DNS records and create monitoring tasks for them.
+
+### Overview
+
+DNS Service Discovery allows HertzBeat to discover service instances by
querying DNS records. This is a simple and reliable service discovery method
that utilizes standard DNS infrastructure to find service instances. It is
particularly suitable for environments using DNS SRV records or environments
that need to discover services through DNS.
+
+### PreRequisites
+
+#### Configure DNS Records
+
+Ensure your DNS server has properly configured service discovery records.
Different record types have different formats:
+
+1. **SRV Records**: Used for service discovery, containing service host and
port information
+2. **A Records**: Return IPv4 addresses
+3. **AAAA Records**: Return IPv6 addresses
+4. **MX Records**: Mail server records
+5. **NS Records**: Name server records
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|--------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique. |
+| DNS Host | DNS server address. Example: `8.8.8.8` or
`192.168.1.1` |
+| DNS Port | DNS server port. The default is 53
|
+| Record Type | Type of DNS record to query. Options: `SRV`, `A`,
`AAAA`, `MX`, `NS` |
+| Record Name | Name of the DNS record to query. Example:
`_http._tcp.example.com` for SRV records |
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds. |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here. |
+
+### Usage Steps
+
+1. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **DNS Service Discovery**
+ - Fill in the basic configuration parameters
+
+2. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - For SRV records, commonly used templates include Port, HTTP, etc.
+ - For A/AAAA records, Ping or Port monitoring can be used
+
+3. **Automatic Discovery**
+ - HertzBeat will periodically query the DNS server based on the collection
interval
+ - Automatically create monitoring tasks for newly discovered service
instances
+ - Automatically delete monitoring tasks for disappeared service instances
+
+4. **View Discovered Instances**
+ - In the monitoring list, you can see all automatically created
sub-monitoring tasks
+ - Each sub-monitoring task corresponds to a discovered service instance
+
+### Example of usage
+
+#### Example 1: SRV Record Discovery
+
+Suppose you have an SRV record for your web service:
+
+- **SRV Record**: `_http._tcp.example.com`
+- **DNS Server**: `8.8.8.8`
+- **Expected discovery**: Automatically discover all HTTP service instances
+
+Configuration example:
+
+- **Target Name**: `DNS-SRV-Discovery`
+- **DNS Host**: `8.8.8.8`
+- **DNS Port**: `53`
+- **Record Type**: Select `SRV`
+- **Record Name**: `_http._tcp.example.com`
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring (using the port from SRV
record)
+
+After configuration:
+
+1. HertzBeat queries the SRV record for `_http._tcp.example.com`
+2. Extracts host and port information from the SRV record response
+3. Automatically creates Port monitoring for each service instance
+
+#### Example 2: A Record Discovery
+
+Discover service instances through A records:
+
+- **A Record**: `services.example.com`
+- This domain may resolve to multiple IP addresses
+
+Configuration example:
+
+- **DNS Host**: `192.168.1.1` (Internal DNS server)
+- **DNS Port**: `53`
+- **Record Type**: Select `A`
+- **Record Name**: `services.example.com`
+- **Monitoring Template**: Select `Ping` or `Port` monitoring
+
+#### Example 3: MX Record Discovery
+
+Discover mail servers through MX records:
+
+- **DNS Host**: `8.8.8.8`
+- **Record Type**: Select `MX`
+- **Record Name**: `example.com`
+- **Monitoring Template**: Select `Port` monitoring (port 25)
+
+### DNS Record Types
+
+#### SRV Records (Recommended)
+
+SRV records are the most commonly used record type for service discovery,
containing service name, port number, and priority information.
+
+Format: `_service._protocol.example.com`
+
+Example: `_http._tcp.example.com`
+
+Typical SRV record response contains:
+
+- Target domain name
+- Port number
+- Priority and weight
+
+#### A Records
+
+A records map domain names to IPv4 addresses. If a domain name resolves to
multiple IPs, all IPs can be discovered.
+
+Example: `services.example.com` → `192.168.1.10`, `192.168.1.11`,
`192.168.1.12`
+
+#### AAAA Records
+
+AAAA records map domain names to IPv6 addresses.
+
+Example: `services.example.com` → `2001:db8::1`
+
+#### MX Records
+
+MX records specify mail servers for a domain and include priority information.
+
+Example: `example.com` → `mail.example.com`
+
+#### NS Records
+
+NS records specify name servers for a domain.
+
+Example: `example.com` → `ns1.example.com`
+
+### Notes
+
+- **DNS Server**: Ensure the specified DNS server is accessible and contains
the service discovery records
+- **Record Name**: Record name must be accurate, including the service and
protocol prefix for SRV records
+- **Port Information**:
+ - SRV records contain port information
+ - A/AAAA records do not contain port information; a default port needs to be
specified in the monitoring template
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses; you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Recommended minimum interval is 60 seconds to avoid
excessive DNS queries
+- **DNS Caching**: DNS responses may be cached; the actual update frequency
depends on the DNS record's TTL value
+- **Network Connectivity**: Ensure HertzBeat can access the specified DNS
server and port (default: 53)
+- **Firewall**: Ensure firewalls allow DNS query traffic (UDP/TCP 53)
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Kubernetes Headless Services**: Discover Kubernetes pod instances through
DNS
+- **Cloud Services**: Discover cloud service instances (AWS Route53, Azure
DNS, GCP Cloud DNS)
+- **Traditional DNS**: Use existing DNS infrastructure for service discovery
+- **Load Balancing**: Discover all backend server instances
+- **Mail Servers**: Discover mail server instances through MX records
+- **Multi-Environment**: Use different DNS records for service discovery
across different environments
+
+### Common SRV Record Formats
+
+Different services use different SRV record formats:
+
+- **HTTP**: `_http._tcp.example.com`
+- **HTTPS**: `_https._tcp.example.com`
+- **LDAP**: `_ldap._tcp.example.com`
+- **FTP**: `_ftp._tcp.example.com`
+- **MySQL**: `_mysql._tcp.example.com`
+- **PostgreSQL**: `_postgresql._tcp.example.com`
+
+### Kubernetes Integration
+
+In Kubernetes clusters, DNS service discovery can be used to discover pod
instances:
+
+1. **Headless Services**: Kubernetes creates DNS A records for each pod of
headless services
+2. **Service Discovery**: Use DNS service discovery to monitor all pods of a
specific service
+
+Example:
+
+- **DNS Host**: Kubernetes cluster DNS service IP (usually `10.96.0.10`)
+- **Record Type**: `A`
+- **Record Name**: `my-service.default.svc.cluster.local`
+- **Monitoring Template**: `Port` monitoring
+
+### DNS Server Examples
+
+Commonly used DNS servers:
+
+- **Google Public DNS**: `8.8.8.8`, `8.8.4.4`
+- **Cloudflare DNS**: `1.1.1.1`, `1.0.0.1`
+- **Quad9 DNS**: `9.9.9.9`
+- **OpenDNS**: `208.67.222.222`, `208.67.220.220`
+- **Internal DNS**: Usually the enterprise's internal DNS server address
+
+### Best Practices
+
+1. **Use SRV Records**: SRV records are the recommended method for service
discovery as they contain complete host and port information
+2. **Set Proper TTL**: Set an appropriate DNS record TTL to balance real-time
performance and DNS server load
+3. **Redundancy**: Configure multiple DNS servers to ensure high availability
+4. **Monitoring**: Regularly check DNS record validity and availability
+5. **Security**: Ensure DNS queries are secure, consider using DNS over HTTPS
(DoH) or DNS over TLS (DoT)
diff --git a/home/docs/help/eureka_sd.md b/home/docs/help/eureka_sd.md
new file mode 100644
index 0000000000..41d886e075
--- /dev/null
+++ b/home/docs/help/eureka_sd.md
@@ -0,0 +1,94 @@
+---
+id: eureka_sd
+title: Monitoring Eureka Service Discovery
+sidebar_label: Eureka Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring Eureka service discovery]
+---
+
+> HertzBeat integrates with Eureka registry to automatically discover service
instances and create monitoring tasks for them.
+
+### Overview
+
+Eureka Service Discovery allows HertzBeat to connect to your Eureka server and
automatically discover all registered service instances. When a new service
instance is registered or an existing instance goes offline, HertzBeat will
automatically create or delete corresponding monitoring tasks, achieving
automated monitoring in microservice environments.
+
+### PreRequisites
+
+#### Deploy Eureka Server
+
+1. Deploy Eureka server according to [Eureka official
documentation](https://spring.io/guides/gs/service-registration-and-discovery/).
+2. Ensure Eureka server is accessible from HertzBeat.
+3. Verify that you can access Eureka dashboard at
`http://your-eureka-server:port/`
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|-------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique |
+| Eureka Service Discovery Url | Eureka server address. Example:
`http://eureka-server:8761/eureka`
|
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here |
+
+### Usage Steps
+
+1. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **Eureka Service Discovery**
+ - Fill in the basic configuration parameters
+
+2. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - For example: If discovered instances are HTTP services, you can select
HTTP monitoring template
+ - Common template types: Port, HTTP, HTTPS, etc.
+
+3. **Automatic Discovery**
+ - HertzBeat will periodically query Eureka server based on the collection
interval
+ - Automatically create monitoring tasks for newly registered service
instances
+ - Automatically delete monitoring tasks for offline service instances
+
+4. **View Discovered Instances**
+ - In the monitoring list, you can see all automatically created
sub-monitoring tasks
+ - Each sub-monitoring task corresponds to a discovered service instance
+
+### Example of usage
+
+Suppose your Eureka server is running at `http://192.168.1.100:8761/eureka`,
and you want to automatically monitor all service instances registered in it.
+
+Configuration example:
+
+- **Target Name**: `Eureka-Service-Discovery`
+- **Eureka Service Discovery Url**: `http://192.168.1.100:8761/eureka`
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring (to detect instance
availability)
+
+After configuration:
+
+1. HertzBeat connects to Eureka server
+2. Retrieves all registered application instances
+3. Automatically creates Port monitoring for each instance (e.g.,
`USER-SERVICE-192.168.1.101:8080`)
+4. Every 60 seconds, checks for newly registered or offline services and
updates monitoring tasks accordingly
+
+### Notes
+
+- **Network Connectivity**: Ensure HertzBeat can access the Eureka server
address
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses, you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Recommended minimum interval is 60 seconds to avoid
excessive requests to Eureka server
+- **Permission Requirements**: Eureka server does not require authentication
by default, but if authentication is configured, the URL needs to include
username and password
+- **Instance Naming**: Automatically created monitoring tasks are named in the
format: `{ApplicationName}-{Host}:{Port}`
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Microservice Architecture**: Automatically monitor all microservice
instances registered in Eureka
+- **Dynamic Scaling**: Automatically adapt to service instances added/removed
due to autoscaling
+- **Unified Monitoring**: Centrally manage monitoring of all services in the
microservice environment
+- **Operation and Maintenance**: Reduce manual configuration work and improve
operation efficiency
diff --git a/home/docs/help/http_sd.md b/home/docs/help/http_sd.md
new file mode 100644
index 0000000000..7b49cb66a8
--- /dev/null
+++ b/home/docs/help/http_sd.md
@@ -0,0 +1,228 @@
+---
+id: http_sd
+title: Monitoring HTTP Service Discovery
+sidebar_label: HTTP Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring HTTP service discovery]
+---
+
+> HertzBeat integrates with custom HTTP APIs to automatically discover service
instances and create monitoring tasks for them.
+
+### Overview
+
+HTTP Service Discovery allows HertzBeat to discover service instances by
calling your custom HTTP API. This is the most flexible service discovery
method, suitable for any system that can expose service instance information
via HTTP API. You only need to provide an HTTP endpoint that returns a list of
target addresses in the specified format.
+
+### PreRequisites
+
+#### Prepare HTTP API
+
+You need to provide or develop an HTTP API that meets the following
requirements:
+
+1. **HTTP Method**: Support GET requests
+2. **Response Format**: Return JSON format data
+3. **Response Structure**: Must contain a `targets` field, which is a string
array. Each string is a service instance address in the format `host:port`
+4. **Accessibility**: The API must be accessible from HertzBeat
+
+#### API Response Example
+
+```json
+{
+ "targets": [
+ "192.168.1.101:8080",
+ "192.168.1.102:8080",
+ "192.168.1.103:8080",
+ "api.example.com:443"
+ ]
+}
+```
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|--------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique. |
+| Service Discovery Url | HTTP API address for service discovery. Must start
with http:// or https://. Example: `http://api.example.com/services` |
+| Auth Type | Authentication method, optional values: `Bearer
Token`, `Basic Auth`, `Digest Auth`. Default: None |
+| Access Token | Token for authentication when Auth Type is Bearer
Token. |
+| Username | Username for authentication when Auth Type is Basic
Auth or Digest Auth. |
+| Password | Password for authentication when Auth Type is Basic
Auth or Digest Auth. |
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds. |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here. |
+
+### Usage Steps
+
+1. **Prepare HTTP API**
+ - Develop or configure an API endpoint that returns service instance list
+ - Ensure the API returns JSON data in the correct format
+ - Test the API accessibility and response format
+
+2. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **HTTP Service Discovery**
+ - Fill in the basic configuration parameters
+ - Configure authentication information if needed
+
+3. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - Common template types: Port, HTTP, HTTPS, Ping, etc.
+
+4. **Automatic Discovery**
+ - HertzBeat will periodically call your HTTP API based on the collection
interval
+ - Automatically create monitoring tasks for newly discovered service
instances
+ - Automatically delete monitoring tasks for disappeared service instances
+
+### Example of usage
+
+#### Example 1: API Without Authentication
+
+Suppose you have a service management API:
+
+- **API URL**: `http://service-manager.example.com/api/v1/services`
+- **Response**:
+
+ ```json
+ {
+ "targets": [
+ "10.0.1.10:8080",
+ "10.0.1.11:8080",
+ "10.0.1.12:8080"
+ ]
+ }
+ ```
+
+Configuration example:
+
+- **Target Name**: `HTTP-Service-Discovery`
+- **Service Discovery Url**:
`http://service-manager.example.com/api/v1/services`
+- **Auth Type**: Leave empty (no authentication)
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring
+
+#### Example 2: API With Bearer Token Authentication
+
+If your API requires Bearer Token authentication:
+
+- **API URL**: `https://api.example.com/services`
+- **Auth Type**: `Bearer Token`
+- **Access Token**: `your-bearer-token-here`
+
+Configuration example:
+
+- **Target Name**: `Secure-API-Discovery`
+- **Service Discovery Url**: `https://api.example.com/services`
+- **Auth Type**: Select `Bearer Token`
+- **Access Token**: Enter your token
+- **Monitoring Template**: Select `HTTP` monitoring
+
+#### Example 3: API With Basic Authentication
+
+If your API requires Basic authentication:
+
+- **API URL**: `http://api.internal.com/discover`
+- **Auth Type**: `Basic Auth`
+- **Username**: `admin`
+- **Password**: `password123`
+
+Configuration example:
+
+- **Target Name**: `Basic-Auth-Discovery`
+- **Service Discovery Url**: `http://api.internal.com/discover`
+- **Auth Type**: Select `Basic Auth`
+- **Username**: `admin`
+- **Password**: `password123`
+- **Monitoring Template**: Select appropriate template
+
+### Notes
+
+- **Response Format**: The API response must be in JSON format and contain a
`targets` field (string array)
+- **Address Format**: Each target address should be in the format `host:port`,
for example:
+ - `192.168.1.100:8080`
+ - `api.example.com:443`
+ - `localhost:3000`
+- **Network Connectivity**: Ensure HertzBeat can access the HTTP API address
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses, you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Set a reasonable collection interval based on API
performance and service change frequency
+- **Authentication**: Choose the appropriate authentication method according
to your API security requirements
+- **HTTPS**: If using HTTPS, ensure SSL certificates are properly configured
+- **API Performance**: Ensure the API can respond quickly to avoid affecting
HertzBeat performance
+- **Error Handling**: If the API returns an error or invalid format, HertzBeat
will keep the current monitoring tasks unchanged
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Custom Registry**: Integrate with your own service registry system
+- **Cloud Platform**: Discover services from cloud platforms (AWS, GCP, Azure)
+- **CMDB**: Integrate with CMDB systems to obtain service information
+- **Service Gateway**: Discover service instances through API gateway
+- **Container Platforms**: Obtain service lists from Kubernetes API or
container orchestration platforms
+- **Service Management Systems**: Integrate with existing service management
platforms
+- **Multi-Cloud Environments**: Unify service discovery across different cloud
platforms
+
+### Advanced Usage
+
+#### Response with Additional Metadata
+
+While the basic requirement is just the `targets` field, your API can include
additional metadata for future extensions:
+
+```json
+{
+ "targets": [
+ "192.168.1.10:8080"
+ ],
+ "labels": {
+ "env": "production",
+ "version": "1.0.0"
+ }
+}
+```
+
+Note: Currently, only the `targets` field is used for service discovery, but
future versions may support using label information.
+
+### API Implementation Examples
+
+#### Spring Boot Example
+
+```java
+@RestController
+@RequestMapping("/api/v1")
+public class ServiceDiscoveryController {
+
+ @GetMapping("/services")
+ public Map<String, Object> getServices() {
+ List<String> targets = Arrays.asList(
+ "192.168.1.10:8080",
+ "192.168.1.11:8080",
+ "192.168.1.12:8080"
+ );
+
+ Map<String, Object> response = new HashMap<>();
+ response.put("targets", targets);
+ return response;
+ }
+}
+```
+
+#### Node.js Express Example
+
+```javascript
+app.get('/api/services', (req, res) => {
+ const targets = [
+ '192.168.1.10:8080',
+ '192.168.1.11:8080',
+ '192.168.1.12:8080'
+ ];
+
+ res.json({
+ targets: targets
+ });
+});
+```
diff --git a/home/docs/help/nacos_sd.md b/home/docs/help/nacos_sd.md
new file mode 100644
index 0000000000..fb6aaefa29
--- /dev/null
+++ b/home/docs/help/nacos_sd.md
@@ -0,0 +1,99 @@
+---
+id: nacos_sd
+title: Monitoring Nacos Service Discovery
+sidebar_label: Nacos Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring Nacos service discovery]
+---
+
+> HertzBeat integrates with Nacos registry to automatically discover service
instances and create monitoring tasks for them.
+
+### Overview
+
+Nacos Service Discovery allows HertzBeat to connect to your Nacos server and
automatically discover all registered service instances. When a new service
instance is registered or an existing instance goes offline, HertzBeat will
automatically create or delete corresponding monitoring tasks, achieving
automated monitoring in microservice environments.
+
+### PreRequisites
+
+#### Deploy Nacos Server
+
+1. Deploy Nacos server according to [Nacos official
documentation](https://nacos.io/en-us/docs/quick-start.html).
+2. Ensure Nacos server is accessible from HertzBeat.
+3. Verify that you can access Nacos console at
`http://your-nacos-server:8848/nacos/`
+4. Default credentials: username `nacos`, password `nacos`
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|--------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique. |
+| Nacos Service Discovery Host | Nacos server IP address or domain name.
Note⚠️Without protocol header (eg: https://, http://). Example: `nacos-server`
or `192.168.1.100` |
+| Nacos Service Discovery Port | Port provided by the Nacos server. The
default is 8848
|
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds. |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here. |
+
+### Usage Steps
+
+1. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **Nacos Service Discovery**
+ - Fill in the basic configuration parameters
+
+2. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - For example: If discovered instances are HTTP services, you can select
HTTP monitoring template
+ - Common template types: Port, HTTP, HTTPS, etc.
+
+3. **Automatic Discovery**
+ - HertzBeat will periodically query Nacos server based on the collection
interval
+ - Automatically create monitoring tasks for newly registered service
instances
+ - Automatically delete monitoring tasks for offline service instances
+
+4. **View Discovered Instances**
+ - In the monitoring list, you can see all automatically created
sub-monitoring tasks
+ - Each sub-monitoring task corresponds to a discovered service instance
+
+### Example of usage
+
+Suppose your Nacos server is running at `192.168.1.100:8848`, and you want to
automatically monitor all service instances registered in it.
+
+Configuration example:
+
+- **Target Name**: `Nacos-Service-Discovery`
+- **Nacos Service Discovery Host**: `192.168.1.100`
+- **Nacos Service Discovery Port**: `8848`
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring (to detect instance
availability)
+
+After configuration:
+
+1. HertzBeat connects to Nacos server
+2. Retrieves all registered service instances (including healthy and unhealthy
instances)
+3. Automatically creates Port monitoring for each instance (e.g.,
`user-service-192.168.1.101:8080`)
+4. Every 60 seconds, checks for newly registered or offline services and
updates monitoring tasks accordingly
+
+### Notes
+
+- **Network Connectivity**: Ensure HertzBeat can access the Nacos server
address and port
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses, you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Recommended minimum interval is 60 seconds to avoid
excessive requests to Nacos server
+- **Namespace**: By default, discovers services in the public namespace. If
you need to discover services in a specific namespace, you may need to
configure it separately
+- **Health Check**: Nacos service discovery will discover all instances,
including unhealthy ones
+- **Instance Naming**: Automatically created monitoring tasks are named in the
format: `{ServiceName}-{Host}:{Port}`
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Spring Cloud Alibaba**: Automatically monitor all microservice instances
registered in Nacos
+- **Dynamic Scaling**: Automatically adapt to service instances added/removed
due to autoscaling
+- **Unified Monitoring**: Centrally manage monitoring of all services in the
microservice environment
+- **Multi-Environment**: Manage services across development, testing, and
production environments
+- **Service Governance**: Combine with Nacos service governance capabilities
for comprehensive service management
diff --git a/home/docs/help/zookeeper_sd.md b/home/docs/help/zookeeper_sd.md
new file mode 100644
index 0000000000..bf7887fb7f
--- /dev/null
+++ b/home/docs/help/zookeeper_sd.md
@@ -0,0 +1,122 @@
+---
+id: zookeeper_sd
+title: Monitoring Zookeeper Service Discovery
+sidebar_label: Zookeeper Service Discovery
+keywords: [open source monitoring tool, open source service discovery
monitoring tool, monitoring Zookeeper service discovery]
+---
+
+> HertzBeat integrates with Zookeeper to automatically discover service
instances stored in Zookeeper nodes and create monitoring tasks for them.
+
+### Overview
+
+Zookeeper Service Discovery allows HertzBeat to connect to your Zookeeper
server and automatically discover service instance information stored in
specific path nodes. This is commonly used in Dubbo and other RPC frameworks
that use Zookeeper as a registry center. When service instances change,
HertzBeat will automatically create or delete corresponding monitoring tasks.
+
+### PreRequisites
+
+#### Deploy Zookeeper Server
+
+1. Deploy Zookeeper server according to [Zookeeper official
documentation](https://zookeeper.apache.org/doc/current/zookeeperStarted.html).
+2. Ensure Zookeeper server is accessible from HertzBeat.
+3. Verify Zookeeper is running properly using Zookeeper client tools
+
+### Configuration parameter
+
+| Parameter name |
Parameter help description |
+|---------------------|--------------------------------------------------------------------------------------------------------------------------|
+| Target Name | Identify the name of this monitoring. The name needs
to be unique. |
+| Service Discovery Url | Zookeeper server connection address. Example:
`192.168.1.100:2181` or `zk1:2181,zk2:2181,zk3:2181` (cluster mode) |
+| Service Discovery Path Prefix | The path prefix in Zookeeper for service
discovery. Example: `/dubbo` or `/services`
|
+| Collection interval | Interval time of monitor periodic data collection,
unit: second, and the minimum interval that can be set is 30 seconds. |
+| Description remarks | For more information about identifying and describing
this monitoring, users can note information here. |
+
+### Usage Steps
+
+1. **Create Service Discovery Monitoring**
+ - In HertzBeat web UI, navigate to **Monitoring** → **New Monitoring**
+ - Select monitoring type: **Zookeeper Service Discovery**
+ - Fill in the basic configuration parameters
+
+2. **Configure Monitoring Template**
+ - After creating the service discovery monitoring, you need to specify a
monitoring template
+ - The template defines what type of monitoring to create for discovered
service instances
+ - For example: If discovered instances are Dubbo services, you can select
Port monitoring template
+ - Common template types: Port, HTTP, Ping, etc.
+
+3. **Automatic Discovery**
+ - HertzBeat will periodically query Zookeeper based on the collection
interval
+ - Automatically create monitoring tasks for newly discovered service
instances
+ - Automatically delete monitoring tasks for disappeared service instances
+
+4. **View Discovered Instances**
+ - In the monitoring list, you can see all automatically created
sub-monitoring tasks
+ - Each sub-monitoring task corresponds to a discovered service instance
+
+### Example of usage
+
+#### Example 1: Dubbo Service Discovery
+
+Suppose you have a Dubbo service registry running in Zookeeper at
`192.168.1.100:2181`, and service information is stored under the `/dubbo` path.
+
+Configuration example:
+
+- **Target Name**: `Zookeeper-Dubbo-Discovery`
+- **Service Discovery Url**: `192.168.1.100:2181`
+- **Service Discovery Path Prefix**: `/dubbo`
+- **Collection interval**: `60` seconds
+- **Monitoring Template**: Select `Port` monitoring
+
+After configuration:
+
+1. HertzBeat connects to Zookeeper
+2. Retrieves all child nodes under the `/dubbo` path
+3. Parses node information to extract service instance host and port
+4. Automatically creates Port monitoring for each service instance
+
+#### Example 2: Custom Service Discovery
+
+If you have a custom service registration mechanism using Zookeeper, and
service information is stored under the `/services` path:
+
+- **Service Discovery Url**: `zk1:2181,zk2:2181,zk3:2181` (Zookeeper cluster)
+- **Service Discovery Path Prefix**: `/services`
+
+HertzBeat will discover all service instances under this path.
+
+### Notes
+
+- **Node Format**: Zookeeper service discovery expects child nodes to contain
host:port information
+ - Example node name format: `192.168.1.101:8080` or similar formats
+- **Network Connectivity**: Ensure HertzBeat can access the Zookeeper server
address and port (default: 2181)
+- **Monitoring Templates**: Service discovery only discovers service instance
addresses, you need to configure appropriate monitoring templates to actually
monitor the instances
+- **Collection Interval**: Recommended minimum interval is 60 seconds to avoid
excessive requests to Zookeeper
+- **Path Prefix**: Ensure the path prefix is correct and HertzBeat has
permission to read nodes under this path
+- **Cluster Mode**: Supports Zookeeper cluster mode, multiple addresses can be
separated by commas
+- **Instance Naming**: Automatically created monitoring tasks are named based
on node information
+
+### Collection Metric
+
+#### Metric set: Monitor Target
+
+| Metric name | Metric unit | Metric help description |
+|-----------------|-------------|--------------------------------------------|
+| target | none | Discovered service instance target |
+| host | none | Service instance host address |
+| port | none | Service instance port number |
+
+### Use Cases
+
+- **Dubbo Services**: Automatically monitor Dubbo service providers and
consumers registered in Zookeeper
+- **RPC Frameworks**: Monitor RPC services using Zookeeper as a registry
+- **Custom Registration**: Monitor services using custom Zookeeper-based
service registration
+- **Distributed Systems**: Manage monitoring of distributed system components
using Zookeeper for coordination
+- **Service Governance**: Centrally manage monitoring of services in the
Zookeeper service ecosystem
+
+### Common Dubbo Path Structure
+
+For Dubbo services, typical Zookeeper path structures include:
+
+- `/dubbo/{serviceName}/providers` - Service provider addresses
+- `/dubbo/{serviceName}/consumers` - Service consumer addresses
+- `/dubbo/{serviceName}/routers` - Routing rules
+- `/dubbo/{serviceName}/configurators` - Configuration overrides
+
+When using Zookeeper service discovery with Dubbo, it's recommended to set the
path prefix to `/dubbo` to discover all Dubbo services.
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/consul_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/consul_sd.md
new file mode 100644
index 0000000000..737ef71d21
--- /dev/null
+++ b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/consul_sd.md
@@ -0,0 +1,108 @@
+---
+id: consul_sd
+title: 监控：Consul服务发现监控
+sidebar_label: Consul服务发现
+keywords: [开源监控系统, 开源服务发现监控, Consul服务发现监控]
+---
+
+> HertzBeat 集成 Consul 注册中心，自动发现服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+Consul 服务发现允许 HertzBeat 连接到您的 Consul
服务器并自动发现所有注册的服务实例。当新服务实例注册或现有实例下线时，HertzBeat 将自动创建或删除相应的监控任务，实现微服务环境下的自动化监控。
+
+### 监控前操作
+
+#### 部署 Consul 服务器
+
+1. 根据 [Consul 官方文档](https://www.consul.io/docs/install)部署 Consul 服务器。
+2. 确保 Consul 服务器可从 HertzBeat 访问。
+3. 验证您可以访问 Consul UI：`http://your-consul-server:8500/ui/`
+4. 确保 Consul HTTP API 可访问（默认端口：8500）
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述 |
+|--------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| Consul Host | Consul 服务器 IP 地址或域名。注意⚠️不带协议头(例如: https://,
http://)。示例：`consul-server` 或 `192.168.1.100` |
+| Consul 端口 | Consul 服务器对外提供的端口，默认为 8500 |
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**Consul服务发现**
+ - 填写基本配置参数
+
+2. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 例如：如果发现的实例是 HTTP 服务，可以选择 HTTP 监控模板
+ - 常用模板类型：端口、HTTP、HTTPS、Ping 等
+
+3. **自动发现**
+ - HertzBeat 会根据采集间隔定期查询 Consul 服务器
+ - 为新注册的服务实例自动创建监控任务
+ - 自动删除已下线服务实例的监控任务
+
+4. **查看发现的实例**
+ - 在监控列表中，您可以看到所有自动创建的子监控任务
+ - 每个子监控任务对应一个发现的服务实例
+
+### 使用示例
+
+假设您的 Consul 服务器运行在 `192.168.1.100:8500`，您希望自动监控其中注册的所有服务实例。
+
+配置示例：
+
+- **任务名称**：`Consul-Service-Discovery`
+- **Consul Host**：`192.168.1.100`
+- **Consul 端口**：`8500`
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控（检测实例可用性）
+
+配置完成后：
+
+1. HertzBeat 通过 HTTP API 连接到 Consul 服务器
+2. 获取所有已注册的服务实例
+3. 为每个实例自动创建端口监控（例如：`api-service-192.168.1.101:8080`）
+4. 每 60 秒检查一次新注册或下线的服务，并相应地更新监控任务
+
+### 注意事项
+
+- **网络连通性**：确保 HertzBeat 可以访问 Consul 服务器地址和端口（默认：8500）
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：建议最小间隔为 60 秒，避免对 Consul 服务器造成过多请求
+- **ACL 令牌**：如果 Consul 配置了 ACL（访问控制列表），可能需要配置相应的令牌
+- **服务健康状态**：Consul 服务发现会同时发现健康和不健康的实例
+- **数据中心**：默认发现本地数据中心的服务。如果需要发现特定数据中心的服务，可能需要额外配置
+- **实例命名**：自动创建的监控任务命名格式为：`{服务名}-{主机}:{端口}`
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **微服务架构**：自动监控 Consul 中注册的所有微服务实例
+- **服务网格**：监控使用 Consul Connect 服务网格的服务
+- **多数据中心**：监控多个 Consul 数据中心的服务实例
+- **动态伸缩**：自动适应因自动扩缩容而增减的服务实例
+- **健康检查**：结合 Consul 的健康检查机制监控服务健康状态
+- **服务治理**：集中管理 Consul 服务生态中所有服务的监控
+
+### 与 Consul 功能的集成
+
+- **服务健康**：Consul 服务发现可以利用 Consul 的健康检查信息
+- **服务标签**：从 Consul 发现的服务实例可能包含标签信息
+- **KV 存储**：可与 Consul KV 存储结合使用，实现更灵活的服务发现
+- **服务网格**：支持 Consul Connect 服务网格环境中的服务发现
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/dns_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/dns_sd.md
new file mode 100644
index 0000000000..7460c2b852
--- /dev/null
+++ b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/dns_sd.md
@@ -0,0 +1,223 @@
+---
+id: dns_sd
+title: 监控：DNS服务发现监控
+sidebar_label: DNS服务发现
+keywords: [开源监控系统, 开源服务发现监控, DNS服务发现监控]
+---
+
+> HertzBeat 集成 DNS 服务，通过 DNS 记录自动发现服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+DNS 服务发现允许 HertzBeat 通过查询 DNS 记录来发现服务实例。这是一种简单可靠的服务发现方法，利用标准 DNS
基础设施来查找服务实例。特别适用于使用 DNS SRV 记录或需要通过 DNS 发现服务的环境。
+
+### 监控前操作
+
+#### 配置 DNS 记录
+
+确保您的 DNS 服务器已正确配置服务发现记录。不同的记录类型有不同的格式：
+
+1. **SRV 记录**：用于服务发现，包含服务主机和端口信息
+2. **A 记录**：返回 IPv4 地址
+3. **AAAA 记录**：返回 IPv6 地址
+4. **MX 记录**：邮件服务器记录
+5. **NS 记录**：名称服务器记录
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述 |
+|--------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| DNS地址 | DNS 服务器地址。示例：`8.8.8.8` 或 `192.168.1.1` |
+| DNS端口 | DNS 服务器端口，默认为 53 |
+| 记录类型 | 要查询的 DNS 记录类型。选项：`SRV`、`A`、`AAAA`、`MX`、`NS` |
+| 记录名称 | 要查询的 DNS 记录名称。示例：SRV 记录为 `_http._tcp.example.com` |
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**DNS服务发现**
+ - 填写基本配置参数
+
+2. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 对于 SRV 记录，常用的模板包括端口、HTTP 等
+ - 对于 A/AAAA 记录，可以使用 Ping 或端口监控
+
+3. **自动发现**
+ - HertzBeat 会根据采集间隔定期查询 DNS 服务器
+ - 为新发现的服务实例自动创建监控任务
+ - 自动删除已消失服务实例的监控任务
+
+4. **查看发现的实例**
+ - 在监控列表中，您可以看到所有自动创建的子监控任务
+ - 每个子监控任务对应一个发现的服务实例
+
+### 使用示例
+
+#### 示例 1：SRV 记录发现
+
+假设您的 Web 服务有一个 SRV 记录：
+
+- **SRV 记录**：`_http._tcp.example.com`
+- **DNS 服务器**：`8.8.8.8`
+- **预期发现**：自动发现所有 HTTP 服务实例
+
+配置示例：
+
+- **任务名称**：`DNS-SRV-Discovery`
+- **DNS地址**：`8.8.8.8`
+- **DNS端口**：`53`
+- **记录类型**：选择 `SRV`
+- **记录名称**：`_http._tcp.example.com`
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控（使用 SRV 记录中的端口）
+
+配置完成后：
+
+1. HertzBeat 查询 `_http._tcp.example.com` 的 SRV 记录
+2. 从 SRV 记录响应中提取主机和端口信息
+3. 为每个服务实例自动创建端口监控
+
+#### 示例 2：A 记录发现
+
+通过 A 记录发现服务实例：
+
+- **A 记录**：`services.example.com`
+- 该域名可能解析到多个 IP 地址
+
+配置示例：
+
+- **DNS地址**：`192.168.1.1`（内部 DNS 服务器）
+- **DNS端口**：`53`
+- **记录类型**：选择 `A`
+- **记录名称**：`services.example.com`
+- **监控模板**：选择 `Ping` 或 `端口` 监控
+
+#### 示例 3：MX 记录发现
+
+通过 MX 记录发现邮件服务器：
+
+- **DNS地址**：`8.8.8.8`
+- **记录类型**：选择 `MX`
+- **记录名称**：`example.com`
+- **监控模板**：选择 `端口` 监控（端口 25）
+
+### DNS 记录类型
+
+#### SRV 记录（推荐）
+
+SRV 记录是最常用的服务发现记录类型，包含服务名称、端口号和优先级信息。
+
+格式：`_service._protocol.example.com`
+
+示例：`_http._tcp.example.com`
+
+典型的 SRV 记录响应包含：
+
+- 目标域名
+- 端口号
+- 优先级和权重
+
+#### A 记录
+
+A 记录将域名映射到 IPv4 地址。如果一个域名解析到多个 IP，则可以发现所有 IP。
+
+示例：`services.example.com` → `192.168.1.10`、`192.168.1.11`、`192.168.1.12`
+
+#### AAAA 记录
+
+AAAA 记录将域名映射到 IPv6 地址。
+
+示例：`services.example.com` → `2001:db8::1`
+
+#### MX 记录
+
+MX 记录指定域的邮件服务器，包含优先级信息。
+
+示例：`example.com` → `mail.example.com`
+
+#### NS 记录
+
+NS 记录指定域的名称服务器。
+
+示例：`example.com` → `ns1.example.com`
+
+### 注意事项
+
+- **DNS 服务器**：确保指定的 DNS 服务器可访问且包含服务发现记录
+- **记录名称**：记录名称必须准确，SRV 记录需要包含服务和协议前缀
+- **端口信息**：
+ - SRV 记录包含端口信息
+ - A/AAAA 记录不包含端口信息，需要在监控模板中指定默认端口
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：建议最小间隔为 60 秒，避免过多的 DNS 查询
+- **DNS 缓存**：DNS 响应可能被缓存，实际更新频率取决于 DNS 记录的 TTL 值
+- **网络连通性**：确保 HertzBeat 可以访问指定的 DNS 服务器和端口（默认：53）
+- **防火墙**：确保防火墙允许 DNS 查询流量（UDP/TCP 53）
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **Kubernetes Headless 服务**：通过 DNS 发现 Kubernetes Pod 实例
+- **云服务**：从云服务发现实例（AWS Route53、Azure DNS、GCP Cloud DNS）
+- **传统 DNS**：使用现有 DNS 基础设施进行服务发现
+- **负载均衡**：发现所有后端服务器实例
+- **邮件服务器**：通过 MX 记录发现邮件服务器实例
+- **多环境**：使用不同 DNS 记录在不同环境中进行服务发现
+
+### 常见 SRV 记录格式
+
+不同服务使用不同的 SRV 记录格式：
+
+- **HTTP**：`_http._tcp.example.com`
+- **HTTPS**：`_https._tcp.example.com`
+- **LDAP**：`_ldap._tcp.example.com`
+- **FTP**：`_ftp._tcp.example.com`
+- **MySQL**：`_mysql._tcp.example.com`
+- **PostgreSQL**：`_postgresql._tcp.example.com`
+
+### Kubernetes 集成
+
+在 Kubernetes 集群中，可以使用 DNS 服务发现来发现 Pod 实例：
+
+1. **Headless 服务**：Kubernetes 为 headless 服务的每个 Pod 创建 DNS A 记录
+2. **服务发现**：使用 DNS 服务发现监控特定服务的所有 Pod
+
+示例：
+
+- **DNS地址**：Kubernetes 集群 DNS 服务 IP（通常是 `10.96.0.10`）
+- **记录类型**：`A`
+- **记录名称**：`my-service.default.svc.cluster.local`
+- **监控模板**：`端口` 监控
+
+### DNS 服务器示例
+
+常用的 DNS 服务器：
+
+- **Google Public DNS**：`8.8.8.8`、`8.8.4.4`
+- **Cloudflare DNS**：`1.1.1.1`、`1.0.0.1`
+- **Quad9 DNS**：`9.9.9.9`
+- **OpenDNS**：`208.67.222.222`、`208.67.220.220`
+- **内部 DNS**：通常是企业内部 DNS 服务器地址
+
+### 最佳实践
+
+1. **使用 SRV 记录**：SRV 记录是推荐的服务发现方法，因为它包含完整的主机和端口信息
+2. **设置合理的 TTL**：设置适当的 DNS 记录 TTL 以平衡实时性能和 DNS 服务器负载
+3. **冗余配置**：配置多个 DNS 服务器以确保高可用性
+4. **监控**：定期检查 DNS 记录的有效性和可用性
+5. **安全性**：确保 DNS 查询安全，考虑使用 DNS over HTTPS (DoH) 或 DNS over TLS (DoT)
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/eureka_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/eureka_sd.md
new file mode 100644
index 0000000000..2bf5445231
--- /dev/null
+++ b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/eureka_sd.md
@@ -0,0 +1,94 @@
+---
+id: eureka_sd
+title: 监控：Eureka服务发现监控
+sidebar_label: Eureka服务发现
+keywords: [开源监控系统, 开源服务发现监控, Eureka服务发现监控]
+---
+
+> HertzBeat 集成 Eureka 注册中心，自动发现服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+Eureka 服务发现允许 HertzBeat 连接到您的 Eureka
服务器并自动发现所有注册的服务实例。当新服务实例注册或现有实例下线时，HertzBeat 将自动创建或删除相应的监控任务，实现微服务环境下的自动化监控。
+
+### 监控前操作
+
+#### 部署 Eureka 服务器
+
+1. 根据 [Eureka
官方文档](https://spring.io/guides/gs/service-registration-and-discovery/)部署 Eureka
服务器。
+2. 确保 Eureka 服务器可从 HertzBeat 访问。
+3. 验证您可以访问 Eureka 控制台：`http://your-eureka-server:port/`
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述 |
+|---------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| Eureka服务发现地址 | Eureka 服务器地址。示例：`http://eureka-server:8761/eureka` |
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**Eureka服务发现**
+ - 填写基本配置参数
+
+2. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 例如：如果发现的实例是 HTTP 服务，可以选择 HTTP 监控模板
+ - 常用模板类型：端口、HTTP、HTTPS 等
+
+3. **自动发现**
+ - HertzBeat 会根据采集间隔定期查询 Eureka 服务器
+ - 为新注册的服务实例自动创建监控任务
+ - 自动删除已下线服务实例的监控任务
+
+4. **查看发现的实例**
+ - 在监控列表中，您可以看到所有自动创建的子监控任务
+ - 每个子监控任务对应一个发现的服务实例
+
+### 使用示例
+
+假设您的 Eureka 服务器运行在 `http://192.168.1.100:8761/eureka`，您希望自动监控其中注册的所有服务实例。
+
+配置示例：
+
+- **任务名称**：`Eureka-Service-Discovery`
+- **Eureka服务发现地址**：`http://192.168.1.100:8761/eureka`
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控（检测实例可用性）
+
+配置完成后：
+
+1. HertzBeat 连接到 Eureka 服务器
+2. 获取所有已注册的应用实例
+3. 为每个实例自动创建端口监控（例如：`USER-SERVICE-192.168.1.101:8080`）
+4. 每 60 秒检查一次新注册或下线的服务，并相应地更新监控任务
+
+### 注意事项
+
+- **网络连通性**：确保 HertzBeat 可以访问 Eureka 服务器地址
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：建议最小间隔为 60 秒，避免对 Eureka 服务器造成过多请求
+- **权限要求**：Eureka 服务器默认不需要认证，但如果配置了认证，URL 需要包含用户名和密码
+- **实例命名**：自动创建的监控任务命名格式为：`{应用名称}-{主机}:{端口}`
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **微服务架构**：自动监控 Eureka 中注册的所有微服务实例
+- **动态伸缩**：自动适应因自动扩缩容而增减的服务实例
+- **统一监控**：集中管理微服务环境中所有服务的监控
+- **运维管理**：减少手动配置工作，提高运维效率
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/http_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/http_sd.md
new file mode 100644
index 0000000000..9fdafd2a1a
--- /dev/null
+++ b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/http_sd.md
@@ -0,0 +1,228 @@
+---
+id: http_sd
+title: 监控：HTTP服务发现监控
+sidebar_label: HTTP服务发现
+keywords: [开源监控系统, 开源服务发现监控, HTTP服务发现监控]
+---
+
+> HertzBeat 集成自定义 HTTP API，自动发现服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+HTTP 服务发现允许 HertzBeat 通过调用您的自定义 HTTP API 来发现服务实例。这是最灵活的服务发现方式，适用于任何可以通过 HTTP
API 暴露服务实例信息的系统。您只需提供一个返回指定格式目标地址列表的 HTTP 端点即可。
+
+### 监控前操作
+
+#### 准备 HTTP API
+
+您需要提供或开发一个满足以下要求的 HTTP API：
+
+1. **HTTP 方法**：支持 GET 请求
+2. **响应格式**：返回 JSON 格式数据
+3. **响应结构**：必须包含 `targets` 字段，该字段为字符串数组，每个字符串是一个服务实例地址，格式为 `host:port`
+4. **可访问性**：该 API 必须可从 HertzBeat 访问
+
+#### API 响应示例
+
+```json
+{
+ "targets": [
+ "192.168.1.101:8080",
+ "192.168.1.102:8080",
+ "192.168.1.103:8080",
+ "api.example.com:443"
+ ]
+}
+```
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述 |
+|------------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| 服务发现地址 | 用于服务发现的 HTTP API 地址，必须以 http:// 或 https://
开头。示例：`http://api.example.com/services` |
+| 认证方式 | 认证方式，可选值：`Bearer Token`、`Basic Auth`、`Digest Auth`。默认：无 |
+| 访问令牌 | 当认证方式为 Bearer Token 时用于认证的令牌 |
+| 用户名 | 当认证方式为 Basic Auth 或 Digest Auth 时用于认证的用户名 |
+| 密码 | 当认证方式为 Basic Auth 或 Digest Auth 时用于认证的密码 |
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **准备 HTTP API**
+ - 开发或配置一个返回服务实例列表的 API 端点
+ - 确保 API 返回正确格式的 JSON 数据
+ - 测试 API 的可访问性和响应格式
+
+2. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**HTTP服务发现**
+ - 填写基本配置参数
+ - 根据需要配置认证信息
+
+3. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 常用模板类型：端口、HTTP、HTTPS、Ping 等
+
+4. **自动发现**
+ - HertzBeat 会根据采集间隔定期调用您的 HTTP API
+ - 为新发现的服务实例自动创建监控任务
+ - 自动删除已消失服务实例的监控任务
+
+### 使用示例
+
+#### 示例 1：无需认证的 API
+
+假设您有一个服务管理 API：
+
+- **API 地址**：`http://service-manager.example.com/api/v1/services`
+- **响应**：
+
+ ```json
+ {
+ "targets": [
+ "10.0.1.10:8080",
+ "10.0.1.11:8080",
+ "10.0.1.12:8080"
+ ]
+ }
+ ```
+
+配置示例：
+
+- **任务名称**：`HTTP-Service-Discovery`
+- **服务发现地址**：`http://service-manager.example.com/api/v1/services`
+- **认证方式**：留空（无需认证）
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控
+
+#### 示例 2：使用 Bearer Token 认证的 API
+
+如果您的 API 需要 Bearer Token 认证：
+
+- **API 地址**：`https://api.example.com/services`
+- **认证方式**：`Bearer Token`
+- **访问令牌**：`your-bearer-token-here`
+
+配置示例：
+
+- **任务名称**：`Secure-API-Discovery`
+- **服务发现地址**：`https://api.example.com/services`
+- **认证方式**：选择 `Bearer Token`
+- **访问令牌**：输入您的令牌
+- **监控模板**：选择 `HTTP` 监控
+
+#### 示例 3：使用 Basic 认证的 API
+
+如果您的 API 需要 Basic 认证：
+
+- **API 地址**：`http://api.internal.com/discover`
+- **认证方式**：`Basic Auth`
+- **用户名**：`admin`
+- **密码**：`password123`
+
+配置示例：
+
+- **任务名称**：`Basic-Auth-Discovery`
+- **服务发现地址**：`http://api.internal.com/discover`
+- **认证方式**：选择 `Basic Auth`
+- **用户名**：`admin`
+- **密码**：`password123`
+- **监控模板**：选择合适的模板
+
+### 注意事项
+
+- **响应格式**：API 响应必须是 JSON 格式且包含 `targets` 字段（字符串数组）
+- **地址格式**：每个目标地址应为 `host:port` 格式，例如：
+ - `192.168.1.100:8080`
+ - `api.example.com:443`
+ - `localhost:3000`
+- **网络连通性**：确保 HertzBeat 可以访问 HTTP API 地址
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：根据 API 性能和服务变更频率设置合理的采集间隔
+- **认证方式**：根据您的 API 安全要求选择合适的认证方式
+- **HTTPS**：如果使用 HTTPS，确保 SSL 证书配置正确
+- **API 性能**：确保 API 能够快速响应，避免影响 HertzBeat 性能
+- **错误处理**：如果 API 返回错误或格式无效，HertzBeat 将保持当前监控任务不变
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **自定义注册中心**：与您自己的服务注册系统集成
+- **云平台**：从云平台（AWS、GCP、Azure）发现服务
+- **CMDB**：与 CMDB 系统集成获取服务信息
+- **服务网关**：通过 API 网关发现服务实例
+- **容器平台**：从 Kubernetes API 或容器编排平台获取服务列表
+- **服务管理系统**：与现有服务管理平台集成
+- **多云环境**：统一管理不同云平台的服务发现
+
+### 高级用法
+
+#### 包含额外元数据的响应
+
+虽然基本要求只是 `targets` 字段，但您的 API 可以包含额外的元数据以供未来扩展使用：
+
+```json
+{
+ "targets": [
+ "192.168.1.10:8080"
+ ],
+ "labels": {
+ "env": "production",
+ "version": "1.0.0"
+ }
+}
+```
+
+注意：目前仅使用 `targets` 字段进行服务发现，但未来版本可能支持使用标签信息。
+
+### API 实现示例
+
+#### Spring Boot 示例
+
+```java
+@RestController
+@RequestMapping("/api/v1")
+public class ServiceDiscoveryController {
+
+ @GetMapping("/services")
+ public Map<String, Object> getServices() {
+ List<String> targets = Arrays.asList(
+ "192.168.1.10:8080",
+ "192.168.1.11:8080",
+ "192.168.1.12:8080"
+ );
+
+ Map<String, Object> response = new HashMap<>();
+ response.put("targets", targets);
+ return response;
+ }
+}
+```
+
+#### Node.js Express 示例
+
+```javascript
+app.get('/api/services', (req, res) => {
+ const targets = [
+ '192.168.1.10:8080',
+ '192.168.1.11:8080',
+ '192.168.1.12:8080'
+ ];
+
+ res.json({
+ targets: targets
+ });
+});
+```
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/nacos_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/nacos_sd.md
new file mode 100644
index 0000000000..45eb38e669
--- /dev/null
+++ b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/nacos_sd.md
@@ -0,0 +1,99 @@
+---
+id: nacos_sd
+title: 监控：Nacos服务发现监控
+sidebar_label: Nacos服务发现
+keywords: [开源监控系统, 开源服务发现监控, Nacos服务发现监控]
+---
+
+> HertzBeat 集成 Nacos 注册中心，自动发现服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+Nacos 服务发现允许 HertzBeat 连接到您的 Nacos
服务器并自动发现所有注册的服务实例。当新服务实例注册或现有实例下线时，HertzBeat 将自动创建或删除相应的监控任务，实现微服务环境下的自动化监控。
+
+### 监控前操作
+
+#### 部署 Nacos 服务器
+
+1. 根据 [Nacos 官方文档](https://nacos.io/zh-cn/docs/quick-start.html)部署 Nacos 服务器。
+2. 确保 Nacos 服务器可从 HertzBeat 访问。
+3. 验证您可以访问 Nacos 控制台：`http://your-nacos-server:8848/nacos/`
+4. 默认凭证：用户名 `nacos`，密码 `nacos`
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述
|
+|-----------------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| Nacos服务发现Host | Nacos 服务器 IP 地址或域名。注意⚠️不带协议头(例如: https://,
http://)。示例：`nacos-server` 或 `192.168.1.100` |
+| Nacos服务发现Port | Nacos 服务器对外提供的端口，默认为 8848 |
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**Nacos服务发现**
+ - 填写基本配置参数
+
+2. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 例如：如果发现的实例是 HTTP 服务，可以选择 HTTP 监控模板
+ - 常用模板类型：端口、HTTP、HTTPS 等
+
+3. **自动发现**
+ - HertzBeat 会根据采集间隔定期查询 Nacos 服务器
+ - 为新注册的服务实例自动创建监控任务
+ - 自动删除已下线服务实例的监控任务
+
+4. **查看发现的实例**
+ - 在监控列表中，您可以看到所有自动创建的子监控任务
+ - 每个子监控任务对应一个发现的服务实例
+
+### 使用示例
+
+假设您的 Nacos 服务器运行在 `192.168.1.100:8848`，您希望自动监控其中注册的所有服务实例。
+
+配置示例：
+
+- **任务名称**：`Nacos-Service-Discovery`
+- **Nacos服务发现Host**：`192.168.1.100`
+- **Nacos服务发现Port**：`8848`
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控（检测实例可用性）
+
+配置完成后：
+
+1. HertzBeat 连接到 Nacos 服务器
+2. 获取所有已注册的服务实例（包括健康和不健康的实例）
+3. 为每个实例自动创建端口监控（例如：`user-service-192.168.1.101:8080`）
+4. 每 60 秒检查一次新注册或下线的服务，并相应地更新监控任务
+
+### 注意事项
+
+- **网络连通性**：确保 HertzBeat 可以访问 Nacos 服务器地址和端口
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：建议最小间隔为 60 秒，避免对 Nacos 服务器造成过多请求
+- **命名空间**：默认发现 public 命名空间下的服务。如果需要发现特定命名空间的服务，可能需要单独配置
+- **健康检查**：Nacos 服务发现会发现所有实例，包括不健康的实例
+- **实例命名**：自动创建的监控任务命名格式为：`{服务名}-{主机}:{端口}`
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **Spring Cloud Alibaba**：自动监控 Nacos 中注册的所有微服务实例
+- **动态伸缩**：自动适应因自动扩缩容而增减的服务实例
+- **统一监控**：集中管理微服务环境中所有服务的监控
+- **多环境管理**：管理开发、测试、生产环境中的服务
+- **服务治理**：结合 Nacos 服务治理能力实现全面的服务管理
diff --git
a/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/zookeeper_sd.md
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/zookeeper_sd.md
new file mode 100644
index 0000000000..666557c4d0
--- /dev/null
+++
b/home/i18n/zh-cn/docusaurus-plugin-content-docs/current/help/zookeeper_sd.md
@@ -0,0 +1,122 @@
+---
+id: zookeeper_sd
+title: 监控：Zookeeper服务发现监控
+sidebar_label: Zookeeper服务发现
+keywords: [开源监控系统, 开源服务发现监控, Zookeeper服务发现监控]
+---
+
+> HertzBeat 集成 Zookeeper，自动发现存储在 Zookeeper 节点中的服务实例并为发现的实例创建监控任务。
+
+### 概述
+
+Zookeeper 服务发现允许 HertzBeat 连接到您的 Zookeeper 服务器并自动发现存储在特定路径节点中的服务实例信息。这通常用于
Dubbo 和其他使用 Zookeeper 作为注册中心的 RPC 框架。当服务实例发生变化时，HertzBeat 将自动创建或删除相应的监控任务。
+
+### 监控前操作
+
+#### 部署 Zookeeper 服务器
+
+1. 根据 [Zookeeper
官方文档](https://zookeeper.apache.org/doc/current/zookeeperStarted.html)部署
Zookeeper 服务器。
+2. 确保 Zookeeper 服务器可从 HertzBeat 访问。
+3. 使用 Zookeeper 客户端工具验证 Zookeeper 运行正常
+
+### 配置参数
+
+| 参数名称 | 参数帮助描述
|
+|-----------------------|-----------------------------------------------------|
+| 任务名称 | 标识此监控的名称，名称需要保证唯一性 |
+| 服务发现地址 | Zookeeper 服务器连接地址。示例：`192.168.1.100:2181` 或
`zk1:2181,zk2:2181,zk3:2181`（集群模式） |
+| 服务发现路径前缀 | Zookeeper 中用于服务发现的路径前缀。示例：`/dubbo` 或 `/services`
|
+| 采集间隔 | 监控周期性采集数据间隔时间，单位秒，可设置的最小间隔为30秒 |
+| 描述备注 | 更多标识和描述此监控的备注信息，用户可以在这里备注信息 |
+
+### 使用步骤
+
+1. **创建服务发现监控**
+ - 在 HertzBeat Web 界面中，导航到 **监控** → **新增监控**
+ - 选择监控类型：**Zookeeper服务发现**
+ - 填写基本配置参数
+
+2. **配置监控模板**
+ - 创建服务发现监控后，需要指定一个监控模板
+ - 模板定义了为发现的服务实例创建什么类型的监控
+ - 例如：如果发现的实例是 Dubbo 服务，可以选择端口监控模板
+ - 常用模板类型：端口、HTTP、Ping 等
+
+3. **自动发现**
+ - HertzBeat 会根据采集间隔定期查询 Zookeeper
+ - 为新发现的服务实例自动创建监控任务
+ - 自动删除已消失服务实例的监控任务
+
+4. **查看发现的实例**
+ - 在监控列表中，您可以看到所有自动创建的子监控任务
+ - 每个子监控任务对应一个发现的服务实例
+
+### 使用示例
+
+#### 示例 1：Dubbo 服务发现
+
+假设您有一个运行在 Zookeeper 中的 Dubbo 服务注册中心，地址为 `192.168.1.100:2181`，服务信息存储在 `/dubbo`
路径下。
+
+配置示例：
+
+- **任务名称**：`Zookeeper-Dubbo-Discovery`
+- **服务发现地址**：`192.168.1.100:2181`
+- **服务发现路径前缀**：`/dubbo`
+- **采集间隔**：`60` 秒
+- **监控模板**：选择 `端口` 监控
+
+配置完成后：
+
+1. HertzBeat 连接到 Zookeeper
+2. 获取 `/dubbo` 路径下的所有子节点
+3. 解析节点信息提取服务实例的主机和端口
+4. 为每个服务实例自动创建端口监控
+
+#### 示例 2：自定义服务发现
+
+如果您有一个使用 Zookeeper 的自定义服务注册机制，服务信息存储在 `/services` 路径下：
+
+- **服务发现地址**：`zk1:2181,zk2:2181,zk3:2181`（Zookeeper 集群）
+- **服务发现路径前缀**：`/services`
+
+HertzBeat 将发现此路径下的所有服务实例。
+
+### 注意事项
+
+- **节点格式**：Zookeeper 服务发现期望子节点包含主机:端口信息
+ - 示例节点名称格式：`192.168.1.101:8080` 或类似格式
+- **网络连通性**：确保 HertzBeat 可以访问 Zookeeper 服务器地址和端口（默认：2181）
+- **监控模板**：服务发现仅发现服务实例地址，您需要配置合适的监控模板来实际监控这些实例
+- **采集间隔**：建议最小间隔为 60 秒，避免对 Zookeeper 造成过多请求
+- **路径前缀**：确保路径前缀正确，且 HertzBeat 有权限读取此路径下的节点
+- **集群模式**：支持 Zookeeper 集群模式，多个地址用逗号分隔
+- **实例命名**：自动创建的监控任务基于节点信息命名
+
+### 采集指标
+
+#### 指标集合：监控目标
+
+| 指标名称 | 指标单位 | 指标帮助描述 |
+|------|-------|---------------|
+| 目标 | 无 | 发现的服务实例目标 |
+| 主机 | 无 | 服务实例主机地址 |
+| 端口 | 无 | 服务实例端口号 |
+
+### 适用场景
+
+- **Dubbo 服务**：自动监控注册在 Zookeeper 中的 Dubbo 服务提供者和消费者
+- **RPC 框架**：监控使用 Zookeeper 作为注册中心的 RPC 服务
+- **自定义注册**：监控使用基于 Zookeeper 的自定义服务注册的服务
+- **分布式系统**：管理使用 Zookeeper 进行协调的分布式系统组件的监控
+- **服务治理**：集中管理 Zookeeper 服务生态中所有服务的监控
+
+### 常见 Dubbo 路径结构
+
+对于 Dubbo 服务，典型的 Zookeeper 路径结构包括：
+
+- `/dubbo/{serviceName}/providers` - 服务提供者地址
+- `/dubbo/{serviceName}/consumers` - 服务消费者地址
+- `/dubbo/{serviceName}/routers` - 路由规则
+- `/dubbo/{serviceName}/configurators` - 配置覆盖
+
+使用 Zookeeper 服务发现配合 Dubbo 时，建议将路径前缀设置为 `/dubbo` 以发现所有 Dubbo 服务。
diff --git a/home/sidebars.json b/home/sidebars.json
index 4c9a149072..665c6d336d 100755
--- a/home/sidebars.json
+++ b/home/sidebars.json
@@ -120,6 +120,18 @@
"help/alert_notification_template"
]
},
+ {
+ "type": "category",
+ "label": "service-discovery",
+ "items": [
+ "help/eureka_sd",
+ "help/nacos_sd",
+ "help/consul_sd",
+ "help/zookeeper_sd",
+ "help/http_sd",
+ "help/dns_sd"
+ ]
+ },
{
"type": "category",
"label": "service",
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
