由于每个服务都有单独负责的运维人员和钉钉告警群,但是某些服务的告警信息很多,都一起丢过去会导致运维人员需要手动去找哪个是自己负责的服务,效率就很低,不知道可不可以根据服务来对告警信息进行分组,让群里的运维人员只看见自己所负责的服务
rules:
service_old_gc_count_rule:
metrics-name: instance_jvm_young_gc_count
op: ">"
threshold: 1
period: 1
count: 1
silence-period: 1
message: old gc count of service instance {name} is more than 3 in 2 minutes of last 5 minutes.
service_old_gc_count_rule:
metrics-name: instance_jvm_young_gc_count
op: ">"
threshold: 1
period: 1
count: 1
silence-period: 1
message: old gc count of service instance {name} is more than 3 in 2 minutes of last 5 minutes.
dingtalkHooks:
textTemplate: |-
{
"msgtype": "text",
"text": {
"content": "Apache SkyWalking 111 告警: \n%s."
}
}
webhooks:
- url: https://oapi.dingtalk.com/robot/send?access_token=xxx
secret: xxx
- url: https://oapi.dingtalk.com/robot/send?access_token=yyy
secret: yyy
- url: https://oapi.dingtalk.com/robot/send?access_token=zzz
secret: zzz
这是测试用的告警规则与钉钉钩子,钩子有好几个,都是不同的群,我想让每个群里负责服务的运维人员只看见他们自己负责服务的告警信息,不需要在很多无效信息里手动查找
Skywalking 是一个APM系统,即应用性能监控系统,为微服务架构和云原生架构系统设计。它通过探针自动收集所需的指标,并进行分布式追踪。通过这些调用链路以及指标,Skywalking APM会感知应用间关系和服务间关系,并进行相应的指标统计。目前支持链路追踪和监控应用组件如下,基本涵盖主流框架和容器,如国产PRC Dubbo和motan等,国际化的spring boot,spring cloud都支持了
SkyWalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8S、Mesos)架构而设计
SkyWalking是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案
Skywalking Agent: 采集tracing
(调用链数据)和metric
(指标)信息并上报,上报通过HTTP或者gRPC方式发送数据到Skywalking Collector
Skywalking Collector : 链路数据收集器,对agent传过来的tracing
和metric
数据进行整合分析通过Analysis Core
模块处理并落入相关的数据存储中,同时会通过Query Core
模块进行二次统计和监控告警
Storage: Skywalking的存储,支持以ElasticSearch
、Mysql
、TiDB
、H2
等作为存储介质进行数据存储
UI: Web可视化平台,用来展示落地的数据,目前官方采纳了RocketBot作为SkyWalking的主UI