This is an automated email from the ASF dual-hosted git repository. wusheng pushed a commit to branch alerting-doc in repository https://gitbox.apache.org/repos/asf/skywalking.git
commit be880a9584f488516b1ebfb17f4abfede0a27c10 Author: Wu Sheng <[email protected]> AuthorDate: Tue Jun 14 10:34:38 2022 +0800 Change alarm to alerting --- README.md | 10 +++++----- docs/en/setup/backend/backend-alarm.md | 22 +++++++++++----------- docs/menu.yml | 2 +- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index eeb890f14a..2dae4a8882 100644 --- a/README.md +++ b/README.md @@ -18,19 +18,19 @@ microservices, cloud native and container-based architectures. in Cloud Native architecture. The core features are following. -- Service, service instance, endpoint metrics analysis +- Service, service instance, endpoint(URI) metrics analysis - Root cause analysis. Profile the code on the runtime powered by in-process agent and ebpf profiler. - Service topology map analysis -- Service, service instance and endpoint dependency analysis +- Service instance and endpoint(URI) dependency analysis - Slow services and endpoints detecting - Performance optimization - Distributed tracing and context propagation - Database access metrics. Detect slow database access statements(including SQL statements) - Message Queue performance and consuming latency monitoring -- Alarm - Browser performance monitoring - Infrastructure(VM, network, disk etc.) monitoring - Collaboration across metrics, traces, and logs +- Alerting <img src="https://skywalking.apache.org/images/home/architecture.svg?t=20220513"/> @@ -40,11 +40,11 @@ including 1. Java, .NET Core, NodeJS, PHP, and Python auto-instrument agents. 2. Go, C++, and Rust SDKs. 3. [Agent profiling](https://skywalking.apache.org/docs/main/latest/en/concepts-and-designs/sdk-profiling/) for Java and Python. -4. [ebpf profiling](https://github.com/apache/skywalking-rover) C, C++, Golang, and Rust. +4. [ebpf profiling](https://github.com/apache/skywalking-rover) for C, C++, Golang, and Rust. 5. LUA agent especially for Nginx, OpenResty and Apache APISIX. 6. Browser agent. 7. Service Mesh Observability. Control plane and data plane. -8. Metrics system, including Prometheus, OpenTelemetry, Spring Sleuth(Micrometer), Zabbix. +8. Metrics system, including Prometheus, OpenTelemetry, Micrometer(Spring Sleuth), Zabbix. 9. Logs. 10. Zipkin v1/v2 trace.(No Analysis) diff --git a/docs/en/setup/backend/backend-alarm.md b/docs/en/setup/backend/backend-alarm.md index 1dc48259d7..87243d270d 100644 --- a/docs/en/setup/backend/backend-alarm.md +++ b/docs/en/setup/backend/backend-alarm.md @@ -1,9 +1,9 @@ -# Alarm -The alarm core is driven by a collection of rules defined in `config/alarm-settings.yml.` -There are three parts to alarm rule definitions. -1. [Alarm rules](#rules). They define how metrics alarm should be triggered and what conditions should be considered. -1. [Webhooks](#webhook). The list of web service endpoints, which should be called after an alarm is triggered. -1. [gRPCHook](#grpchook). The host and port of the remote gRPC method, which should be called after an alarm is triggered. +# Alerting +The alerting core is driven by a collection of rules defined in `config/alarm-settings.yml.` +There are three parts to alerting rule definitions. +1. [alerting rules](#rules). They define how metrics alerting should be triggered and what conditions should be considered. +1. [Webhooks](#webhook). The list of web service endpoints, which should be called after an alerting is triggered. +1. [gRPCHook](#grpchook). The host and port of the remote gRPC method, which should be called after an alerting is triggered. ## Entity name Defines the relation between scope and entity name. @@ -18,7 +18,7 @@ Defines the relation between scope and entity name. ## Rules **There are two types of rules: individual rules and composite rules. A composite rule is a combination of individual rules.** ### Individual rules -An alarm rule is made up of the following elements: +An alerting rule is made up of the following elements: - **Rule name**. A unique name shown in the alarm message. It must end with `_rule`. - **Metrics name**. This is also the metrics name in the OAL script. Only long, double, int types are supported. See the [list of all potential metrics name](#list-of-all-potential-metrics-name). Events can also be configured as the source @@ -48,7 +48,7 @@ For example, in **percentile**, `value1` is the threshold of P50, and `-, -, val By default, it works in the same manner as **period**. The same Alarm (having the same ID in the same metrics name) may only be triggered once within a period. ### Composite rules -**NOTE**: Composite rules are only applicable to alarm rules targeting the same entity level, such as service-level alarm rules (`service_percent_rule && service_resp_time_percentile_rule`). Do not compose alarm rules of different entity levels, such as an alarm rule of the service metrics with another rule of the endpoint metrics. +**NOTE**: Composite rules are only applicable to alerting rules targeting the same entity level, such as service-level alarm rules (`service_percent_rule && service_resp_time_percentile_rule`). Do not compose alarm rules of different entity levels, such as an alarm rule of the service metrics with another rule of the endpoint metrics. A composite rule is made up of the following elements: - **Rule name**. A unique name shown in the alarm message. Must end with `_rule`. @@ -300,9 +300,9 @@ welinkHooks: ``` ## Update the settings dynamically -Since 6.5.0, the alarm settings can be updated dynamically at runtime by [Dynamic Configuration](dynamic-config.md), +Since 6.5.0, the alerting settings can be updated dynamically at runtime by [Dynamic Configuration](dynamic-config.md), which will override the settings in `alarm-settings.yml`. -In order to determine whether an alarm rule is triggered or not, SkyWalking needs to cache the metrics of a time window for -each alarm rule. If any attribute (`metrics-name`, `op`, `threshold`, `period`, `count`, etc.) of a rule is changed, +In order to determine whether an alerting rule is triggered or not, SkyWalking needs to cache the metrics of a time window for +each alerting rule. If any attribute (`metrics-name`, `op`, `threshold`, `period`, `count`, etc.) of a rule is changed, the sliding window will be destroyed and re-created, causing the Alarm of this specific rule to restart again. diff --git a/docs/menu.yml b/docs/menu.yml index 694e2c9d78..33fc87253b 100644 --- a/docs/menu.yml +++ b/docs/menu.yml @@ -127,7 +127,7 @@ catalog: path: "/en/setup/backend/spring-sleuth-setup" - name: "Prometheus Metrics" path: "/en/setup/backend/prometheus-metrics" - - name: "Alarm" + - name: "Alerting" path: "/en/setup/backend/backend-alarm" - name: "Logging" catalog:
![https://skywalking.apache.org/images/home/architecture.svg?t=20220513"/](https://skywalking.apache.org/images/home/architecture.svg?t=20220513"/){kind=link}