update en images for flashmonit

Author: UlricQin

flashduty/en/3. Monitors/1. Getting Started/1. Introduction.md

@@ -1,31 +1,31 @@
 ---
-title: "Alert Engine (Monitors) Introduction"
-description: "The Alert Engine (Monitors) integrates with various metric and log data sources, performs threshold evaluation based on user-configured alert rules through periodic data queries, generates alert events, and finally pushes them to Flashduty On-call for aggregation and delivery."
+title: "Alerting Engine (Monitors) Introduction"
+description: "The Alerting Engine (Monitors) integrates with various metric and log data sources, performs threshold evaluation based on user-configured alert rules through periodic data queries, generates alert events, and finally pushes them to Flashduty On-call for aggregation and delivery."
 date: "2025-11-07T18:49:47.055+08:00"
 url: "https://docs.flashcat.cloud/en/flashduty/monitors/introduction?nav=01JCQ7A4N4WRWNXW8EWEHXCMF5"
 ---
 
-## What is the Alert Engine (Monitors)?
+## What is the Alerting Engine (Monitors)?
 
-The Alert Engine (Monitors) integrates with various metric and log data sources, performs threshold evaluation based on your configured alert rules through periodic data queries, generates alert events, and finally pushes them to Flashduty On-call for aggregation and delivery.
+The Alerting Engine (Monitors) integrates with various metric and log data sources, performs threshold evaluation based on your configured alert rules through periodic data queries, generates alert events, and finally pushes them to Flashduty On-call for aggregation and delivery.
 
-Flashduty Monitors can replace the alerting capabilities of products like Nightingale, vmalert, and elastalert. The Monitors alert engine is designed to be extremely flexible and deeply integrated with On-call products, capable of meeting various complex alerting requirements.
+Flashduty Monitors can replace the alerting capabilities of products like Nightingale, vmalert, and elastalert. The Monitors alerting engine is designed to be extremely flexible and deeply integrated with On-call products, capable of meeting various complex alerting requirements.
 
-## Alert Engine (Monitors) Architecture Design
+## Alerting Engine (Monitors) Architecture Design
 
-Flashduty is a SaaS service that cannot access data sources within users' private networks from the SaaS side. Therefore, the Alert Engine (Monitors) consists of two parts:
+Flashduty is a SaaS service that cannot access data sources within users' private networks from the SaaS side. Therefore, the Alerting Engine (Monitors) consists of two parts:
 
 - **SaaS Server**: Responsible for managing alert rules and permissions
 - **monitedge**: Deployed within users' private networks, synchronizes alert rules from SaaS, performs periodic data queries and threshold evaluation, generates alert events and pushes them to the SaaS side
 
 The architecture diagram is shown below:
 
-![Flashduty Monitors Architecture Diagram](https://docs-cdn.flashcat.cloud/imges/mon/a4341737494509d131b637a74399a43c.png)
+![Flashduty Monitors Architecture Diagram](https://docs-cdn.flashcat.cloud/imges/mon/810c0f78abf52714ee32cee84461cdcc.png)
 
 The diagram assumes that the customer has two data centers, East US and South China. Each data center has a `monitedge` instance deployed, responsible for alert evaluation of data sources within their respective data centers and pushing alert events to the SaaS side.
 
 If you only have one data center, or if the network quality between data centers is good, you can also deploy only one `monitedge` instance to handle alert evaluation for all data sources.
 
 If you are concerned about single point of failure risks when deploying one `monitedge`, you can also deploy multiple `monitedge` instances to form a cluster. For example, deploy 2 `monitedge` instances in the East US data center to form a cluster, setting the same cluster name through the `--alerter.clusterName meidong` parameter when starting the instances; deploy 2 `monitedge` instances in the South China data center to form another cluster, setting another cluster name through the `--alerter.clusterName huanan` parameter when starting these two instances.
 
-Multiple instances in an alert engine cluster will automatically shard the processing of alert rules. For example, if this cluster needs to process 100 alert rules, the system will automatically balance the load, allowing each `monitedge` instance to process 50 rules respectively. If one instance fails, another instance will take over the processing of all 100 alert rules, ensuring high availability while avoiding duplicate alert event delivery.
+Multiple instances in an alerting engine cluster will automatically shard the processing of alert rules. For example, if this cluster needs to process 100 alert rules, the system will automatically balance the load, allowing each `monitedge` instance to process 50 rules respectively. If one instance fails, another instance will take over the processing of all 100 alert rules, ensuring high availability while avoiding duplicate alert event delivery.

flashduty/en/3. Monitors/1. Getting Started/2. Quick Start.md

@@ -48,28 +48,28 @@ The following details the various configurations of alert rules. Each field usua
 
 ### Basic Configuration
 
-![Basic Configuration](https://docs-cdn.flashcat.cloud/imges/mon/3a2978a22d7a23dd862fdbd409adf663.png)
+![Basic Configuration](https://docs-cdn.flashcat.cloud/imges/mon/90942addfba10594e6fd97944fc20d43.png)
 
 - **Rule Name**: The name of the alert rule, for easy identification and management. Variable references are not supported because names may be used for filtering, aggregation and other operations in the future, and fixed names are more convenient for processing.
 - **Additional Labels**: Similar to `labels` in Prometheus alert rules, they will be attached to all alert events generated by this rule, facilitating filtering, routing, inhibition and other operations in On-call.
 
 ### Data Source Selection
 
-![Data Source Selection](https://docs-cdn.flashcat.cloud/imges/mon/9971af45b4bc19bfe807898bf1bf10a0.png)
+![Data Source Selection](https://docs-cdn.flashcat.cloud/imges/mon/1f183f153a46a42486573c672c457afc.png)
 
 Monitors can make one rule effective for multiple data sources, and wildcards can be used, such as `db-*`, indicating that this rule will apply to all data sources whose names start with `db-`.
 
 > ⚠️ Note: Because wildcards need to be supported here for data sources, data source names are stored instead of data source IDs. If the data source name is modified, it will affect the effectiveness of alert rules. Please be cautious when modifying data source names.
 
 ### Query Detection Method
 
-![Query Detection Method](https://docs-cdn.flashcat.cloud/imges/mon/4e38b46952d6cbbfb97c2d28843dcdbe.png)
+![Query Detection Method](https://docs-cdn.flashcat.cloud/imges/mon/7726c726d684559c181129a2cac1b8a4.png)
 
 This section is used to configure how to query data from data sources and how to determine alert conditions. This functionality is designed to be very flexible, which also brings higher complexity. Please read the usage instructions on the right side of **Query Detection Method** on the page to understand the configuration method.
 
 ### Detection Frequency & Effective Time
 
-![Detection Frequency & Effective Time](https://docs-cdn.flashcat.cloud/imges/mon/0980d71a653985a1706243fc6795685e.png)
+![Detection Frequency & Effective Time](https://docs-cdn.flashcat.cloud/imges/mon/535c3e683411a3af3acae8b4415e622d.png)
 
 - **Detection Frequency**: Usually periodic detection, also supports configuring `cron` expressions. The `cron` expressions in Monitors are accurate to the second.
 - **Effective Time**: Configure the effective time period for alert rules. Alerts will not be triggered during non-effective time periods.
@@ -88,18 +88,18 @@ This section is used to configure how to query data from data sources and how to
 
 After completing the above configuration, if alert conditions are triggered, alert events will be generated, and the status in front of the alert rule will also change to `Triggered`.
 
-![Alert Rules List Page](https://docs-cdn.flashcat.cloud/imges/mon/6f1fad7d65b5aee6b89bf0f0a564a1be.png)
+![Alert Rules List Page](https://docs-cdn.flashcat.cloud/imges/mon/38ba91252ee84a69b081d2e1e9ee65ea.png)
 
 Clicking `Triggered` will show the alert events generated by this rule (you can also view them in On-call):
 
-![Alert Events List](https://docs-cdn.flashcat.cloud/imges/mon/3a307bf41012c5e085d81ca8b2dc443b.png)
+![Alert Events List](https://docs-cdn.flashcat.cloud/imges/mon/53463829edad49f876a182cd320bcee8.png)
 
 Continue clicking on the alert event title to see the alert event details, divided into three tabs: **Alert Overview**, **Timeline**, **Associated Events**. These are all functions of the On-call system, and the meaning of each field is also quite obvious, so they will not be described one by one here.
 
 ## 5. Import Alert Rules
 
 If you already have a batch of Prometheus alert rules and want to quickly import them into Monitors for use, you can use the alert rule import function. Menu entry: Alert Rules → Import.
 
-![Import Alert Rules](https://docs-cdn.flashcat.cloud/imges/mon/a613b20d1aeaf7321be5ab43bf07a83f.png)
+![Import Alert Rules](https://docs-cdn.flashcat.cloud/imges/mon/a475df96e4fc0efa0896b51af4134b52.png)
 
 The requirement is to import Prometheus alert rule YAML format text, in the standard Prometheus alert rule file format with `groups` as the root node. The YAML indentation must be correct, otherwise the import will fail.