skywalking 告警规则原理详解和复合告警规则设置注意事项和复合告警规则使用场景

转载自博客：Apache SkyWalking 告警配置指南

Apache SkyWalking是分布式系统的应用程序性能监视工具（Application Performance Management，APM），专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。

它提供了分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

Apache SkyWalking告警

Apache SkyWalking告警是由一组规则驱动，这些规则定义在config/alarm-settings.yml文件中。

告警规则的定义分为三部分。

告警规则：定义了触发告警所考虑的条件。
webhook：当告警触发时，被调用的服务端点列表。
gRPCHook：当告警触发时，被调用的远程gRPC方法的主机和端口。
Slack Chat Hook：当告警触发时，被调用的Slack Chat接口。
微信 Hook：当告警触发时，被调用的微信接口。
钉钉 Hook：当告警触发时，被调用的钉钉接口。

告警规则

告警规则有两种类型，单独规则（Individual Rules）和复合规则（Composite Rules），复合规则是单独规则的组合。

单独规则（Individual Rules）

单独规则主要有以下几点：

规则名称：在告警信息中显示的唯一名称，必须以_rule结尾。
metrics-name：度量名称，也是OAL脚本中的度量名。默认配置中可以用于告警的度量有：服务，实例，端点，服务关系，实例关系，端点关系。它只支持long,double和int类型。
include-names：包含在此规则之内的实体名称列表。
exclude-names：排除在此规则以外的实体名称列表。
include-names-regex：提供一个正则表达式来包含实体名称。如果同时设置包含名称列表和包含名称的正则表达式，则两个规则都将生效。
exclude-names-regex：提供一个正则表达式来排除实体名称。如果同时设置排除名称列表和排除名称的正则表达式，则两个规则都将生效。
include-labels：包含在此规则之内的标签。
exclude-labels：排除在此规则以外的标签。
include-labels-regex：提供一个正则表达式来包含标签。如果同时设置包含标签列表和包含标签的正则表达式，则两个规则都将生效。
exclude-labels-regex：提供一个正则表达式来排除标签。如果同时设置排除标签列表和排除标签的正则表达式，则两个规则都将生效。

标签的设置必须把数据存储在meter-system中，例如：Prometheus, Micrometer。以上四个标签设置必须实现LabeledValueHolder接口。

threshold：阈值。

对于多个值指标，例如percentile，阈值是一个数组。像value1 value2 value3 value4 value5这样描述。
每个值可以作为度量中每个值的阈值。如果不想通过此值或某些值触发警报，则将值设置为 -。
例如在percentile中，value1是P50的阈值，value2是P75的阈值，那么-，-，value3, value4, value5的意思是，没有阈值的P50和P75的percentile告警规则。

op：操作符，支持>, >=, <, <=, =。
period：多久告警规则需要被检查一下。这是一个时间窗口，与后端部署环境时间相匹配。
count：在一个周期窗口中，如果按op计算超过阈值的次数达到count，则发送告警。
only-as-condition：true或者false，指定规则是否可以发送告警，或者仅作为复合规则的条件。
silence-period：在时间N中触发报警后，在N -> N + silence-period这段时间内不告警。默认情况下，它和period一样，这意味着相同的告警（同一个度量名称拥有相同的Id）在同一个周期内只会触发一次。
message：该规则触发时，发送的通知消息。

举个例子：

rules:
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 2
    silence-period: 10
    message: 服务【{name}】的平均响应时间在最近10分钟内有2分钟超过1秒
  service_instance_resp_time_rule:
    metrics-name: service_instance_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 2
    silence-period: 10
    message: 实例【{name}】的平均响应时间在最近10分钟内有2分钟超过1秒
  endpoint_resp_time_rule:
    metrics-name: endpoint_avg
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: 端点【{name}】的平均响应时间在最近10分钟内有2分钟超过1秒

复合规则（Composite Rules）
复合规则仅适用于针对相同实体级别的告警规则，例如都是服务级别的告警规则：service_percent_rule && service_resp_time_percentile_rule。
不可以编写不同实体级别的告警规则，例如服务级别的一个告警规则和端点级别的一个规则：service_percent_rule && endpoint_percent_rule。

复合规则主要有以下几点：

规则名称：在告警信息中显示的唯一名称，必须以_rule结尾。

expression：指定如何组成规则，支持&&, ||, ()操作符。

message：该规则触发时，发送的通知消息。

rules:
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 2
    silence-period: 10
    message: 服务【{name}】的平均响应时间在最近10分钟内有2分钟超过1秒
  service_sla_rule:
    metrics-name: service_sla
    op: "<"
    threshold: 8000
    period: 10
    count: 2
    silence-period: 10
    message: 服务【{name}】的成功率在最近10分钟内有2分钟低于80％
composite-rules:
  comp_rule:
    expression: service_resp_time_rule && service_sla_rule
    message: 服务【{name}】在最近10分钟内有2分钟超过1秒平均响应时间超过1秒并且成功率低于80％

在复合告警中有个注意事项，上面中产生告警之后，会产生三个告警，服务【{name}】的平均响应时间在最近10分钟内有2分钟超过1秒、服务【{name}】的成功率在最近10分钟内有2分钟低于80％和service_resp_time_rule && service_sla_rule，我们有这样的一个需求，我们只发送全局的复合告警规则，不发送单独的告警规则，咋设置了，那就是需要在单独的告警规则中设置only-as-condition为true

底层源码逻辑代码：

1、先计算service_resp_time_rule，计算是否满足告警

2、在计算service_sla_rule，计算是否满足告警规则

3、如果上面两个满足告警，判断是否由上面两个规则组成的组合告警，如果有就发送组合的告警，如果没有设置only-as-condition，也会发送两个单独规则的告警

only-as-condition：true或者false，指定规则是否可以发送告警，或者仅作为复合规则的条件。

如果设置为true

复合告警规则2：转载自博客

[6]深入理解 SkyWalking 中的单独和复合告警规则

深入理解 SkyWalking 中的单独和复合告警规则

一、前言：

在现代的分布式系统架构中，微服务的广泛应用给系统的监控和调优带来了新的挑战。SkyWalking作为一款开源的分布式系统追踪与应用性能监控工具，提供了丰富的功能来帮助我们更好地理解和监控系统的状态。

其中，告警规则是SkyWalking的关键功能之一，通过定义特定指标的阈值和触发条件，帮助我们及时发现和解决系统中的问题。

下面我来带着大家看深入探讨下SkyWalking中的单独和复合告警规则，帮助大家更好地理解它们的概念、配置和实际应用。

官方数据：Alarm | Apache SkyWalking

二、单独告警规则

单独告警规则是SkyWalking中最常用的告警规则类型之一。它允许我们根据单个指标的数值来判断系统是否出现异常，并在满足条件时触发告警。

常见的单独告警指标包括错误率、响应时间、请求量等等。

配置单独告警规则需要指定监控的指标、阈值和触发条件等。

下面将详细介绍如何配置单独告警规则，并通过一个基于错误率的实例来演示配置过程。

定义告警指标：选择合适的指标来监控系统的健康状况。例如，我们可以选择错误率（error rate）作为监控指标，来判断系统中出现的错误比例。
设置阈值：根据实际需求和系统特点，设置合理的阈值来划定异常情况。例如，我们可以将错误率阈值设置为1%，表示当错误率超过1%时，就触发告警。
配置触发条件：根据实际需求配置触发告警的条件。例如，我们可以设置当错误率连续3个周期超过阈值时，触发告警。

单独规则主要有以下几点：

特点：单独规则是独立的监控告警规则，根据特定的指标或条件设置。它可以检测和监控单个指标的变化，并触发相应的告警。

场景示例：假设一个在线商城应用有一个单告警规则：如果订单处理（接口）的平均时间超过5秒，则触发告警。

示例：

规则名称：service_resp_time
条件：服务 {name} 的平均响应时间在最近1分钟内有2次超过5秒，则触发告警。

service_resp_time_rule:
  metrics-name: service_resp_time
  op: ">"
  threshold: 5000
  period: 1
  count: 2
  silence-period: 10
  message: 服务 {name} 的平均响应时间在最近1分钟内有2次超过5秒

这个规则可以帮助团队及时发现订单处理性能问题，并及时采取措施以提高用户体验。

三、复合告警规则
复合告警规则是SkyWalking中更为高级和灵活的规则类型。它允许我们结合多个指标和判断逻辑来定义更复杂的告警策略。

通过配置复合告警规则，我们可以实现更准确和精细的告警逻辑。下面详细介绍复合告警规则的定义和使用方法。

定义复合告警规则：复合告警规则由多个子规则组成，每个子规则可以单独定义一个条件。例如，我们可以定义两个子规则，一个用于监控错误率，另一个用于监控请求量。

设置逻辑关系：根据实际需求，设置不同的逻辑关系来判断整体的告警状态。常见的逻辑关系包括AND、OR和NOT等。例如，我们可以设置当错误率超过阈值，并且请求量低于某个值时，触发告警。

配置触发条件：根据实际需求配置触发告警的条件。例如，我们可以设置当以上两个子规则同时满足时，触发告警。

通过配置复合告警规则，我们可以更灵活地定义系统的异常情况，并及时采取相应的措施来解决问题。

重点理解：

都是服务级别的告警规则：service_percent_rule && service_resp_time_percentile_rule。✔️

编写不同实体级别的告警规则，服务级别的一个告警规则和端点级别的一个规则：service_percent_rule && endpoint_percent_rule。✖

示例场景：

支付失败率超过5%且平均响应时间超过2秒，则触发告警。

复合规则主要有以下几点：

规则名称：在告警信息中显示的唯一名称，必须以_rule结尾。

expression：指定如何组成规则，支持&&, ||, ()操作符。

&&：表示逻辑与（AND）操作符。当两个条件都满足时，条件表达式返回 true；否则返回 false。

||：表示逻辑或（OR）操作符。当至少一个条件满足时，条件表达式返回 true；否则返回 false。

()：用于分组条件，通过括号来指定优先级和逻辑关系。括号内的条件会首先进行计算，然后根据其结果在整个条件表达式中进行逻辑判断。

message：该规则触发时，发送的通知消息。

举个例子：

rules:
service_resp_time_rule:
  metrics-name: payment_failure_rate
  op: ">"
  threshold: 1000
  period: 1
  count: 2
  silence-period: 1
  message: 服务 {name} 的支付失败率在最近1分钟内有2次超过1秒
service_sla_rule:
  metrics-name: average_response_time
  op: ">"
  threshold: 2000
  period: 1
  count: 2
  silence-period: 10
  message: 服务 {name} 的响应时间最近1分钟内有2次大于2s
composite-rules:
 # 规则名称：在告警信息中显示的唯一名称，必须以_rule结尾
comp_rule:
   # 指定如何组成规则，支持&&, ||, ()操作符
  expression: payment_failure_rate && average_response_time
  message: 服务 {name} 支付失败率在最近1分钟内有2次超过1秒且响应时间最近1分钟内有2次大于2s

四、最佳实践和注意事项

Skywalking的单独规则：

根据具体需求选择指标：Skywalking 提供了丰富的监控指标，包括响应时间、错误率、吞吐量等。根据您的需求，选择适当的指标来设置告警规则。
针对单个指标设置阈值：针对每个指标，设置合理的阈值来触发告警。可以根据历史数据和实际经验进行调整，确保阈值能够准确地捕捉到潜在的问题。
考虑连续周期数：使用连续周期数来避免短暂的波动或噪声触发虚假告警。设置一个合适的连续周期数，只有当连续多个周期内指标超过阈值时才触发告警。
选择合适的动作：根据告警的紧急程度和重要性，选择合适的动作。常见的动作包括发送邮件、发送短信、钉钉群机器人通知等，确保相关人员及时获得告警信息。
定期评估和优化：定期评估告警规则的有效性，并根据实际情况进行优化。考虑调整阈值、连续周期数或动作，以适应系统的变化和不断提升告警的准确性和可靠性。

Skywalking的复合规则：

分析多个指标的关联性：当需要同时监控多个指标时，考虑它们之间的关联性。例如，在判断服务质量时，可以同时监控响应时间和错误率，以便全面评估系统的运行状态。
定义合理的条件组合：根据业务需求，定义合理的条件组合来触发告警。可以使用逻辑运算符（如与、或）来组合多个条件，并设置相应的阈值。
注意条件之间的影响：条件之间的顺序和组合方式可能会影响告警结果。确保理解和测试条件之间的逻辑关系，并注意它们的顺序以及可能导致的结果差异。
使用分级告警策略：根据告警的紧急程度和重要性，使用分级告警策略。将不同级别的告警分别处理和通知给对应的团队成员，以便更快地响应和解决问题。
实时监控和分析：Skywalking 提供实时监控和分析功能，可以通过仪表盘、图表和报表等方式实时查看指标和告警状态。利用这些功能进行及时的监控和分析，有助于快速定位和解决问题。

五、实际应用场景

实际应用场景数据的敏感性和多样性，以下是对监控告警规则的解释和一些可能的真实应用场景的说明：

单独规则的解释及应用场景：

单独规则用于监控单个指标是否超过或低于阈值，并触发相应的告警。规则中包含条件部分和动作部分。

条件部分：定义了要监控的指标、运算符、阈值和连续周期数。例如，错误率超过1.0%连续3个周期时触发告警。
动作部分：定义了触发告警时执行的操作。可以是发送通知、记录日志、启动自动化脚本等。

应用场景示例：

网络服务质量监控：监控网络服务的响应时间是否超过阈值，例如超过500毫秒连续3个周期时触发告警。
硬盘使用率监控：监控服务器硬盘使用率是否超过阈值，例如超过90%时触发告警。
温度监控：监控温室内的温度是否超过阈值，例如超过30摄氏度时触发告警。

复合规则的解释及应用场景：

复合规则用于监控多个条件的组合是否同时满足，并触发相应的告警。规则中包含多个条件和一个动作。

条件部分：每个条件定义了要监控的指标、运算符和阈值。所有条件都需要同时满足才会触发告警。
动作部分：定义了触发告警时执行的操作。

应用场景示例：

服务器故障监控：监控服务器的 CPU 利用率超过80%且内存利用率超过90%时触发告警。
网站访问质量监控：监控网站的平均响应时间超过500毫秒且错误率超过1%时触发告警。
数据库性能监控：监控数据库的连接数超过100且慢查询数量超过50时触发告警。

以下是其中一些企业场景中对应的 YAML 数据示例：

单独规则的 YAML 数据示例：

高响应时间告警：

高响应时间告警：

high_response_time_rule:
metric: response_time
op: ">"
threshold: 5000
period: 5m
count: 2
silencePeriod: 15m
message: "检测到高响应时间（> 5000ms）"
actions:
  - name: NotifyEmail
    config:
      recipient: example@example.com

如果过去的 5 分钟内响应时间超过 5000ms，且这个条件至少满足两次，就会触发告警。之后，在沉默期间为 15 分钟，将发送一封电子邮件通知给 example@example.com。

低可用性告警：

low_availability_rule:
metric: availability
op: "<"
threshold: 99.9
period: 10m
count: 1
silencePeriod: 30m
message: "检测到低可用性（< 99.9%）"
actions:
  - name: NotifySlack
    config:
      webhook: https://example.slack.com/webhook

如果过去的 10 分钟内可用性低于 99.9%，只需满足这个条件一次，就会触发告警。之后，在沉默期间为 30 分钟，将使用提供的 Webhook URL 发送 Slack 通知。

高错误率告警：

high_error_rate_rule:
metric: error_rate
op: ">"
threshold: 5
period: 1h
count: 3
silencePeriod: 1h
message: "检测到高错误率（> 5%）"
actions:
  - name: RunScript
    config:
      scriptPath: /path/to/script.sh

如果过去的 1 小时内错误率超过 5%，且这个条件至少满足三次，就会触发告警。之后，在沉默期间为 1 小时，将执行指定路径下的自定义脚本。

复合规则的 YAML 数据示例：

高响应时间和高错误率告警：

high_resp_time_and_error_rate_rule:
compositeConditions:
  - metric: response_time
    op: ">"
    threshold: 5000
  - metric: error_rate
    op: ">"
    threshold: 5
period: 5m
count: 2
silencePeriod: 15m
message: "检测到高响应时间（> 5000ms）和高错误率（> 5%）"
actions:
  - name: NotifyEmail
    config:
      recipient: example@example.com

高 CPU 使用率和低内存告警：

high_cpu_usage_and_low_memory_rule:
compositeConditions:
  - metric: cpu_usage
    op: ">"
    threshold: 90
  - metric: memory_usage
    op: "<"
    threshold: 20
period: 10m
count: 1
silencePeriod: 30m
message: "检测到高 CPU 使用率（> 90%）和低内存（< 20%）"
actions:
  - name: NotifySlack
    config:
      webhook: https://example.slack.com/webhook

高请求量和低成功率告警：

high_request_count_and_low_success_rate_rule:
compositeConditions:
  - metric: request_count
    op: ">"
    threshold: 1000
  - metric: success_rate
    op: "<"
    threshold: 90
period: 1h
count: 3
silencePeriod: 1h
message: "检测到高请求量（> 1000）和低成功率（< 90%）"
actions:
  - name: RunScript
    config:
      scriptPath: /path/to/script.sh

六、结论

通过对SkyWalking中的单独和复合告警规则的深入理解，我们可以更好地配置和使用这些规则，帮助我们及时发现和解决系统中的问题，提升系统的稳定性和性能。

我强调了最佳实践和注意事项，并提供了实际应用场景来帮助大家更好地理解和应用告警规则。

希望大家通过本文对SkyWalking中的告警规则有更深入的认识，并在实际应用中获得更好的效果。

在上面的告警规则的设置过程中，需要注意的几个点：

1、# 规则名称：在告警信息中显示的唯一名称，必须以_rule结尾。告警规则的名称必须是_rule结尾，比如service_resp_time_rule、service_sla_rule:

2、第二告警中的metrics-name: payment_failure_rate。这个metrics-name指标名称是skywalking在oal文件中定位的指标名称，默认提供了多种指标名称，也可以项目组自己定义

基于SkyWalking的自定义监控告警

转载自博客：

SkyWalking的监控告警方案--自定义告警

一、为什么需要自定义告警？

1、满足不同的监控需求；
2、结合链路追踪及告警规则，更高效解决问题；

二、场景定义

2.1、需求

场景描述：公司主营业务为在线购物网站，那么 HTTP 服务的可用性就非常重要。如果某个服务出现故障，则可能会导致用户无法访问网站，从而影响用户体验和业务收入。因此，需要借助 SkyWalking 自定义告警功能来监控异常 HTTP 状态码，及时发现和解决问题，提高服务质量和系统可用性。

2.2、需求分析

当接口返回状态码为 404，500, 502, 503, 504 其中一个，就发送告警。

如果要添加自定义告警，首先需要在 oal 文件中添加一个指标。

Helm包文件目录：skywalking/files/conf.d 下面有个 README.md 文件，主要是为了介绍如何去自定义。

If you don't want to use the default configuration files packed into the Docker image,
put your own configuration files under this directory in the corresponding component subdirectory,
`oap`, `ui`, etc.

Files under `oap/*` will override the counterparts under the Docker image's `/skywalking/config/*`, with the directory structure retained, here are some examples:

| File under `files/config.d/oap` directory | Overrides the file under Docker image's `/skywalking/config/` |
| ---- | -------- |
| `files/config.d/oap/application.yml`                 | `/skywalking/config/application.yml`                 |
| `files/config.d/oap/log4j2.xml`                     | `/skywalking/config/log4j2.xml`                       |
| `files/config.d/oap/alarm-settings.yml`             | `/skywalking/config/alarm-settings.yml`               |
| `files/config.d/oap/endpoint-name-grouping.yml`     | `/skywalking/config/endpoint-name-grouping.yml`       |
| `files/config.d/oap/oal/core.oal`                   | `/skywalking/config/oal/core.oal`                     |
| `files/config.d/oap/oal/browser.oal`                 | `/skywalking/config/oal/browser.oal`                 |
| `files/config.d/oap/oc-rules/oap.yaml`               | `/skywalking/config/oc-rules/oap.yaml`               |
| `...`                                               | `...`                                                 |

Files under `satellite/*` will override the counterparts under the Docker image's `/skywalking/configs/*`, with the directory structure retained, here are some examples:

| File under `files/config.d/satellite` directory | Overrides the file under Docker image's `/skywalking/configs/` |
| ---- | -------- |
| `files/config.d/satellite/satellite_config.yaml` | `/skywalking/configs/satellite_config.yaml` |
| `...`                                           | `...`                                       |

2.3、修改 `core.oal`

复制早先的所有内容，按照如上规则 files/config.d/oap/oal/core.oal 进行新告警添加。

Ps：如有es-init报错可先忽略；

/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/

// For services using protocols HTTP 1/2, gRPC, RPC, etc., the cpm metrics means "calls per minute",
// for services that are built on top of TCP, the cpm means "packages per minute".

// All scope metrics
all_percentile = from(All.latency).percentile(10); // Multiple values including p50, p75, p90, p95, p99
all_heatmap = from(All.latency).histogram(100, 20);

// Service scope metrics
service_resp_time = from(Service.latency).longAvg();
service_sla = from(Service.*).percent(status == true);
service_cpm = from(Service.*).cpm();
service_percentile = from(Service.latency).percentile(10); // Multiple values including p50, p75, p90, p95, p99
service_apdex = from(Service.latency).apdex(name, status);
service_mq_consume_count = from(Service.*).filter(type == RequestType.MQ).count();
service_mq_consume_latency = from((str->long)Service.tag["transmission.latency"]).filter(type == RequestType.MQ).filter(tag["transmission.latency"] != null).longAvg();

// Service relation scope metrics for topology
service_relation_client_cpm = from(ServiceRelation.*).filter(detectPoint == DetectPoint.CLIENT).cpm();
service_relation_server_cpm = from(ServiceRelation.*).filter(detectPoint == DetectPoint.SERVER).cpm();
service_relation_client_call_sla = from(ServiceRelation.*).filter(detectPoint == DetectPoint.CLIENT).percent(status == true);
service_relation_server_call_sla = from(ServiceRelation.*).filter(detectPoint == DetectPoint.SERVER).percent(status == true);
service_relation_client_resp_time = from(ServiceRelation.latency).filter(detectPoint == DetectPoint.CLIENT).longAvg();
service_relation_server_resp_time = from(ServiceRelation.latency).filter(detectPoint == DetectPoint.SERVER).longAvg();
service_relation_client_percentile = from(ServiceRelation.latency).filter(detectPoint == DetectPoint.CLIENT).percentile(10); // Multiple values including p50, p75, p90, p95, p99
service_relation_server_percentile = from(ServiceRelation.latency).filter(detectPoint == DetectPoint.SERVER).percentile(10); // Multiple values including p50, p75, p90, p95, p99

// Service Instance relation scope metrics for topology
service_instance_relation_client_cpm = from(ServiceInstanceRelation.*).filter(detectPoint == DetectPoint.CLIENT).cpm();
service_instance_relation_server_cpm = from(ServiceInstanceRelation.*).filter(detectPoint == DetectPoint.SERVER).cpm();
service_instance_relation_client_call_sla = from(ServiceInstanceRelation.*).filter(detectPoint == DetectPoint.CLIENT).percent(status == true);
service_instance_relation_server_call_sla = from(ServiceInstanceRelation.*).filter(detectPoint == DetectPoint.SERVER).percent(status == true);
service_instance_relation_client_resp_time = from(ServiceInstanceRelation.latency).filter(detectPoint == DetectPoint.CLIENT).longAvg();
service_instance_relation_server_resp_time = from(ServiceInstanceRelation.latency).filter(detectPoint == DetectPoint.SERVER).longAvg();
service_instance_relation_client_percentile = from(ServiceInstanceRelation.latency).filter(detectPoint == DetectPoint.CLIENT).percentile(10); // Multiple values including p50, p75, p90, p95, p99
service_instance_relation_server_percentile = from(ServiceInstanceRelation.latency).filter(detectPoint == DetectPoint.SERVER).percentile(10); // Multiple values including p50, p75, p90, p95, p99

// Service Instance Scope metrics
service_instance_sla = from(ServiceInstance.*).percent(status == true);
service_instance_resp_time= from(ServiceInstance.latency).longAvg();
service_instance_cpm = from(ServiceInstance.*).cpm();

// Endpoint scope metrics
endpoint_cpm = from(Endpoint.*).cpm();
endpoint_avg = from(Endpoint.latency).longAvg();
endpoint_sla = from(Endpoint.*).percent(status == true);
endpoint_percentile = from(Endpoint.latency).percentile(10); // Multiple values including p50, p75, p90, p95, p99
endpoint_mq_consume_count = from(Endpoint.*).filter(type == RequestType.MQ).count();
endpoint_mq_consume_latency = from((str->long)Endpoint.tag["transmission.latency"]).filter(type == RequestType.MQ).filter(tag["transmission.latency"] != null).longAvg();

// Endpoint relation scope metrics
endpoint_relation_cpm = from(EndpointRelation.*).filter(detectPoint == DetectPoint.SERVER).cpm();
endpoint_relation_resp_time = from(EndpointRelation.rpcLatency).filter(detectPoint == DetectPoint.SERVER).longAvg();
endpoint_relation_sla = from(EndpointRelation.*).filter(detectPoint == DetectPoint.SERVER).percent(status == true);
endpoint_relation_percentile = from(EndpointRelation.rpcLatency).filter(detectPoint == DetectPoint.SERVER).percentile(10); // Multiple values including p50, p75, p90, p95, p99

database_access_resp_time = from(DatabaseAccess.latency).longAvg();
database_access_sla = from(DatabaseAccess.*).percent(status == true);
database_access_cpm = from(DatabaseAccess.*).cpm();
database_access_percentile = from(DatabaseAccess.latency).percentile(10);

// zhdya 20230625
endpoint_abnormal = from(Endpoint.*).filter(responseCode in [404, 500, 502, 503, 504]).count();

上面的endpoint_relation_resp_time就是skywalking默认提供的单独的响应时间计算指标，endpoint_abnormal就是自定义的异常响应指标

更新部署

## 更新
$ helm upgrade skywalking skywalking -n devops --values ./skywalking/values.yaml
2.4、验证
# kubectl exec -it skywalking-oap-5b6f5b69-drh28 -ndevops -- cat /skywalking/config/oal/core.oal |grep -C 3 zhdya
Defaulted container "oap" out of: oap, wait-for-elasticsearch (init)
// zhdya 20230630
三、增加告警rules
修改helm文件中的rules配置，新增如下rules

三、增加告警rules
修改helm文件中的rules配置，新增如下rules

[skywalking/templates]# vim oap-configmap.yaml
...
    endpoint_abnormal_rule:
      metrics-name: endpoint_abnormal
      threshold: 1
      op: ">="
      period: 2
      count: 1
      message: 接口：{name}\n 指标：接口异常\n 详情：最近2分钟内至少1次\n

posted on 2023-08-23 19:45 luzhouxiaoshuai 阅读(2466) 评论(0) 编辑收藏举报

刷新页面返回顶部

luzhouxiaoshuai