This is an automated email from the ASF dual-hosted git repository.
wusheng pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/skywalking.git
The following commit(s) were added to refs/heads/master by this push:
new 0ac9874e79 Change alarm to alerting (#9212)
0ac9874e79 is described below
commit 0ac9874e79e1826e352f2c4a05c93aed7234700e
Author: 吴晟 Wu Sheng <[email protected]>
AuthorDate: Tue Jun 14 11:23:48 2022 +0800
Change alarm to alerting (#9212)
---
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}