整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
SpringCloud问世以来，微服务以席卷之势风靡全球，企业架构都在从传统SOA向微服务转型。然而微服务这把双刃剑在带来各种优势的同时，也给运维、性能监控、错误的排查带来的极大的困难。
在大型项目中，服务架构会包含数十乃至上百个服务节点。往往一次请求会设计到多个微服务，想要排查一次请求链路中经过了哪些节点，每个节点的执行情况如何，就成为了亟待解决的问题。于是分布式系统的APM管理系统应运而生。
APM系统可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，这就是APM系统，全称是（Application Performance Monitor）。
谷歌公开的论文提到的Google Dapper可以说是最早的APM系统了，给google的开发者和运维团队帮了大忙，所以谷歌公开论文分享了Dapper。
而后，很多的技术公司基于这篇论文的原理，设计开发了很多出色的APM框架，例如Pinpoint、SkyWalking等。
而SpringCloud官网也集成了一套这样的系统：Spring Cloud Sleuth，结合Zipkin。
APM的基本原理
目前大部分的APM系统都是基于Google的Dapper原理实现，我们简单来看看Dapper中的概念和实现原理。
先来看一次请求调用示例：
如何才能实现跟踪呢？
Google的Dapper设计了下面的几个概念用来记录请求链路：
Span：请求中的基本工作单元，每一次链路调用（RPC、Rest、数据库调用）都会创建一个Span。大概结构如下：
type Span struct {
TraceID int64 // 用于标示一次完整的请求id
Name string // 单元名称
ID int64 // 当前这次调用span_id
ParentID int64 // 上层服务的span_id,最上层服务parent_id为null，代表根服务
Annotation []Annotation // 注释，用于记录调用中的详细信息，例如时间
}一次请求的每个链路，通过spanId、parentId就能串联起来：
当然，从请求到服务器开始，服务器返回response结束，每个span存在相同的唯一标识trace_id。
目前主流的APM框架都会包含下列几个组件来完成链路信息的收集和展示：
因此，要筛选一款合格的APM框架，就是对比各个组件的使用差异，主要对比项：
主要是agent对服务的吞吐量、CPU和内存的影响。如果探针在收集微服务运行数据时，对微服务的运行产生了比较大的性能影响，相信没什么人愿意使用。
能够水平扩展以便支持大规模服务器集群，保证收集器的高可用特性。
数据的分析要快 ，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应，最好提供代码级别的可见性以便轻松定位失败点和瓶颈。
即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
自动检测应用拓扑，帮助你搞清楚应用的架构
接下来，我们就对比下目前比较常见的三种APM框架的各项指标，分别是：
三者对比如下：
可见，zipkin的探针性能、开发透明性、数据分析能力都不占优，实在是下下之选。
而pinpoint在数据分析能力、开发透明性上有较大的优势,不过Pinpoint的部署相对比较复杂，需要的硬件资源较高。
Skywalking的探针性能和开发透明性上具有较大优势，数据分析能力上也还不错，重要的是其部署比较方便灵活，比起Pinpoint更适合中小型企业使用。
因此，本文会带着大家学习Skywalking的使用。
SkyWalking 创建于2015年，提供分布式追踪功能。从5.x开始，项目进化为一个完成功能的Application Performance Management系统。 他被用于追踪、监控和诊断分布式系统，特别是使用微服务架构，云原生或容积技术。提供以下主要功能：
主要的特征：
先来看下Skywalking的官方给出的结构图：
大致分四个部分：
Skywalking支持windows或者Linux环境部署。这里我们选择在Linux下安装Skywalking，大家要先确保自己的Linux环境中有elasticsearch在启动中。
接下来的安装分为三步：
安装包可以在Skywalking的官网下载，
目前最新版本是8.0.1版本：
下载好的安装包：
将下载好的安装包解压到Linux的某个目录下：
tar xvf apache-skywalking-apm-es7-8.0.1.tar.gz然后对解压好的文件夹重命名：
mv apache-skywalking-apm-es7 skywalking进入解压好的目录：
cd skywalking查看目录结构：
几个关键的目录：
这里要修改config目录中的application.yml文件，详细配置见官网。
进入config目录，修改application.yml，主要是把存储方案从h2改为elasticsearch
可以直接使用下面的配置：
cluster:
selector: ${SW_CLUSTER:standalone}
standalone:
core:
selector: ${SW_CORE:default}
default:
role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator
restHost: ${SW_CORE_REST_HOST:0.0.0.0}
restPort: ${SW_CORE_REST_PORT:12800}
restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
gRPCPort: ${SW_CORE_GRPC_PORT:11800}
gRPCSslEnabled: ${SW_CORE_GRPC_SSL_ENABLED:false}
gRPCSslKeyPath: ${SW_CORE_GRPC_SSL_KEY_PATH:""}
gRPCSslCertChainPath: ${SW_CORE_GRPC_SSL_CERT_CHAIN_PATH:""}
gRPCSslTrustedCAPath: ${SW_CORE_GRPC_SSL_TRUSTED_CA_PATH:""}
downsampling:
- Hour
- Day
- Month
# Set a timeout on metrics data. After the timeout has expired, the metrics data will automatically be deleted.
enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.
dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute
recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day
metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day
# Cache metric data for 1 minute to reduce database queries, and if the OAP cluster changes within that minute,
# the metrics may not be accurate within that minute.
enableDatabaseSession: ${SW_CORE_ENABLE_DATABASE_SESSION:true}
topNReportPeriod: ${SW_CORE_TOPN_REPORT_PERIOD:10} # top_n record worker report cycle, unit is minute
# Extra model column are the column defined by in the codes, These columns of model are not required logically in aggregation or further query,
# and it will cause more load for memory, network of OAP and storage.
# But, being activated, user could see the name in the storage entities, which make users easier to use 3rd party tool, such as Kibana->ES, to query the data by themselves.
activeExtraModelColumns: ${SW_CORE_ACTIVE_EXTRA_MODEL_COLUMNS:false}
# The max length of service + instance names should be less than 200
serviceNameMaxLength: ${SW_SERVICE_NAME_MAX_LENGTH:70}
instanceNameMaxLength: ${SW_INSTANCE_NAME_MAX_LENGTH:70}
# The max length of service + endpoint names should be less than 240
endpointNameMaxLength: ${SW_ENDPOINT_NAME_MAX_LENGTH:150}
storage:
selector: ${SW_STORAGE:elasticsearch7}
elasticsearch7:
nameSpace: ${SW_NAMESPACE:""}
clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}
trustStorePath: ${SW_STORAGE_ES_SSL_JKS_PATH:""}
trustStorePass: ${SW_STORAGE_ES_SSL_JKS_PASS:""}
dayStep: ${SW_STORAGE_DAY_STEP:1} # Represent the number of days in the one minute/hour/day index.
user: ${SW_ES_USER:""}
password: ${SW_ES_PASSWORD:""}
secretsManagementFile: ${SW_ES_SECRETS_MANAGEMENT_FILE:""} # Secrets management file in the properties format includes the username, password, which are managed by 3rd party tool.
indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:1} # The index shards number is for store metrics data rather than basic segment record
superDatasetIndexShardsFactor: ${SW_STORAGE_ES_SUPER_DATASET_INDEX_SHARDS_FACTOR:5} # Super data set has been defined in the codes, such as trace segments. This factor provides more shards for the super data set, shards number = indexShardsNumber * superDatasetIndexShardsFactor. Also, this factor effects Zipkin and Jaeger traces.
indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0}
# Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html
bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # Execute the bulk every 1000 requests
flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # flush the bulk every 10 seconds whatever the number of requests
concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # the number of concurrent requests
resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000}
metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:5000}
segmentQueryMaxSize: ${SW_STORAGE_ES_QUERY_SEGMENT_SIZE:200}
profileTaskQueryMaxSize: ${SW_STORAGE_ES_QUERY_PROFILE_TASK_SIZE:200}
advanced: ${SW_STORAGE_ES_ADVANCED:""}
h2:
driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource}
url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db}
user: ${SW_STORAGE_H2_USER:sa}
metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000}
receiver-sharing-server:
selector: ${SW_RECEIVER_SHARING_SERVER:default}
default:
authentication: ${SW_AUTHENTICATION:""}
receiver-register:
selector: ${SW_RECEIVER_REGISTER:default}
default:
receiver-trace:
selector: ${SW_RECEIVER_TRACE:default}
default:
sampleRate: ${SW_TRACE_SAMPLE_RATE:10000} # The sample rate precision is 1/10000. 10000 means 100% sample in default.
slowDBAccessThreshold: ${SW_SLOW_DB_THRESHOLD:default:200,mongodb:100} # The slow database access thresholds. Unit ms.
receiver-jvm:
selector: ${SW_RECEIVER_JVM:default}
default:
receiver-clr:
selector: ${SW_RECEIVER_CLR:default}
default:
receiver-profile:
selector: ${SW_RECEIVER_PROFILE:default}
default:
service-mesh:
selector: ${SW_SERVICE_MESH:default}
default:
istio-telemetry:
selector: ${SW_ISTIO_TELEMETRY:default}
default:
envoy-metric:
selector: ${SW_ENVOY_METRIC:default}
default:
acceptMetricsService: ${SW_ENVOY_METRIC_SERVICE:true}
alsHTTPAnalysis: ${SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS:""}
prometheus-fetcher:
selector: ${SW_PROMETHEUS_FETCHER:default}
default:
active: ${SW_PROMETHEUS_FETCHER_ACTIVE:false}
receiver_zipkin:
selector: ${SW_RECEIVER_ZIPKIN:-}
default:
host: ${SW_RECEIVER_ZIPKIN_HOST:0.0.0.0}
port: ${SW_RECEIVER_ZIPKIN_PORT:9411}
contextPath: ${SW_RECEIVER_ZIPKIN_CONTEXT_PATH:/}
receiver_jaeger:
selector: ${SW_RECEIVER_JAEGER:-}
default:
gRPCHost: ${SW_RECEIVER_JAEGER_HOST:0.0.0.0}
gRPCPort: ${SW_RECEIVER_JAEGER_PORT:14250}
query:
selector: ${SW_QUERY:graphql}
graphql:
path: ${SW_QUERY_GRAPHQL_PATH:/graphql}
alarm:
selector: ${SW_ALARM:default}
default:
telemetry:
selector: ${SW_TELEMETRY:none}
none:
prometheus:
host: ${SW_TELEMETRY_PROMETHEUS_HOST:0.0.0.0}
port: ${SW_TELEMETRY_PROMETHEUS_PORT:1234}
configuration:
selector: ${SW_CONFIGURATION:none}
none:
grpc:
host: ${SW_DCS_SERVER_HOST:""}
port: ${SW_DCS_SERVER_PORT:80}
clusterName: ${SW_DCS_CLUSTER_NAME:SkyWalking}
period: ${SW_DCS_PERIOD:20}
apollo:
apolloMeta: ${SW_CONFIG_APOLLO:http://106.12.25.204:8080}
apolloCluster: ${SW_CONFIG_APOLLO_CLUSTER:default}
apolloEnv: ${SW_CONFIG_APOLLO_ENV:""}
appId: ${SW_CONFIG_APOLLO_APP_ID:skywalking}
period: ${SW_CONFIG_APOLLO_PERIOD:5}
zookeeper:
period: ${SW_CONFIG_ZK_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds.
nameSpace: ${SW_CONFIG_ZK_NAMESPACE:/default}
hostPort: ${SW_CONFIG_ZK_HOST_PORT:localhost:2181}
# Retry Policy
baseSleepTimeMs: ${SW_CONFIG_ZK_BASE_SLEEP_TIME_MS:1000} # initial amount of time to wait between retries
maxRetries: ${SW_CONFIG_ZK_MAX_RETRIES:3} # max number of times to retry
etcd:
period: ${SW_CONFIG_ETCD_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds.
group: ${SW_CONFIG_ETCD_GROUP:skywalking}
serverAddr: ${SW_CONFIG_ETCD_SERVER_ADDR:localhost:2379}
clusterName: ${SW_CONFIG_ETCD_CLUSTER_NAME:default}
consul:
# Consul host and ports, separated by comma, e.g. 1.2.3.4:8500,2.3.4.5:8500
hostAndPorts: ${SW_CONFIG_CONSUL_HOST_AND_PORTS:1.2.3.4:8500}
# Sync period in seconds. Defaults to 60 seconds.
period: ${SW_CONFIG_CONSUL_PERIOD:1}
# Consul aclToken
aclToken: ${SW_CONFIG_CONSUL_ACL_TOKEN:""}
exporter:
selector: ${SW_EXPORTER:-}
grpc:
targetHost: ${SW_EXPORTER_GRPC_HOST:127.0.0.1}
targetPort: ${SW_EXPORTER_GRPC_PORT:9870}
要确保已经启动了elasticsearch，并且防火墙开放8080、11800、12800端口。
进入bin目录，执行命令即可运行：
./startup.sh默认的UI端口是8080
现在，Skywalking的服务端已经启动完成，我们还需要在微服务中加入服务探针，来收集数据。
首先，将课前资料给的压缩包解压：
将其中的agent解压到某个目录，不要出现中文，可以看到其结构如下：
其中有一个skywalking-agent.jar就是一我们要用的探针。
如果是运行一个jar包，可以在运行时输入参数来指定探针：
java -jar xxx.jar -javaagent:C:/lesson/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name=ly-registry -Dskywalking.collector.backend_service=192.168.150.101:11800本例中，我们用开发工具来运行和配置。
使用IDEA开发工具打开一个你的项目，在IDEA工具中，选择要修改的启动项，点击右键，选择Edit Configuration：
然后在弹出的窗口中，点击Environment，选择VM options后面对应的展开按钮：
在展开的输入框中，输入下面的配置：
-javaagent:C:/lesson/skywalking-agent/skywalking-agent.jar
-Dskywalking.agent.service_name=ly-registry
-Dskywalking.collector.backend_service=192.168.150.101:11800注意：
Skywalking的探针会在项目启动前对class文件进行修改，完成探针植入，对业务代码零侵入，所以我们只需要启动项目，即可生效了。
启动项目，然后对项目中的的业务接口访问，探针就开始工作了。
访问：192.168.150.101:8080可以看到统计数据已经出来了：
服务实例的性能监控：
服务拓扑图：
某次请求的链路追踪信息：
表格视图：
整个系统分为三部分：
本次提供了8.0.0和6.6.0的部署文件，主要是3个镜像文件。由于官方提供的部署方式是Helm的，所以我们自己去Docker Hub上找到官方镜像，编写yaml文件来部署
选择ui和oap相匹配的版本，注意oap有es版本，因为官方默认也是用es来做存储的，所以我们也采用es的版本
由于agent官方是没有提供镜像的，需要我们去官方发行版中找到agent的文件，自己制作镜像
下载地址 skywalking.apache.org/downloads/ 选择对应的版本下载
关于镜像需要了解的点就这些
通过deployment部署 OAP 和 UI服务，通过Side Car模式把agent挂载到微服务应用里面，对应用代码零侵入，而且不限制原来应用的语言。OAP需要提供的配置文件通过ConfigMap注入，包括
端口映射，主要是grpc和rest
grpc是代理接入，数据推送和远程调用需要使用到的，比较重要
rest是使用官方GraphQL API的端口，详情查看 github.com/apache/skyw…
ports:
- containerPort: 11800
name: grpc
protocol: TCP
- containerPort: 12800
name: rest
protocol: TCP
复制代码环境变量
如果是部署6.X版本，需要加上这句话
- name: SW_L0AD_CONFIG_FILE_FROM_VOLUME
value: "true"
复制代码原因是在6.X的官方镜像中，启动脚本docker-entrypoint.sh中，有这么一段逻辑
if [[ -z "$SW_L0AD_CONFIG_FILE_FROM_VOLUME" ]] || [[ "$SW_L0AD_CONFIG_FILE_FROM_VOLUME" != "true" ]]; then
generateApplicationYaml
echo "Generated application.yml"
echo "-------------------------"
cat ${var_application_file}
echo "-------------------------"
fi
复制代码没有环境变量的话，将使用系统生成的配置文件，我们注入的配置文件就失效了，会导致服务无法启动
skywalking的数据采集是采用服务推送的模式，数据指标推送给OAP服务处理。有多种实现方式，基于代理的实现方式是对系统侵入比较小的，通过Side Car模式来实现代理也是微服务架构中常用的模式
制作镜像的时候，我们只需要把文件复制到镜像中就行了
FROM busybox:latest
RUN mkdir -p /opt/skywalking/agent/
ADD agent/ /opt/skywalking/agent/
WORKDIR /
复制代码使用agent，通过initContainers把agent挂载到volume中
initContainers:
- name: init-agent
image: xxx.com/skywalking-agent:latest
command:
- 'sh'
- '-c'
- 'set -ex;mkdir -p /skywalking/agent;cp -r /opt/skywalking/agent/* /skywalking/agent;'
volumeMounts:
- name: agent
mountPath: /skywalking/agent
复制代码然后通过commod覆盖容器的启动命令
command: ["/bin/bash", "-c", "java -javaagent:/opt/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_name=xxx-user -Dskywalking.collector.backend_service=$SKYWALKING_ADDR -jar /app.jar"]
复制代码这里涉及到Docker的ENTRYPOINT，CMD 和 k8s yaml 的 command 和 agrs的运用，
由于命令和参数分割比较难处理，推荐统一使用命令，因为服务也不会存在加参数的情况。
Docker的ENTRYPOINT就对应了yaml的command，通过commod来覆盖容器本身的启动命令，
所以需要注意的就是容器启动有没有什么特殊性，比如是通过脚本启动的，直接通过java -jar的方式还不行，根据实际情况做调整
参数含义：
agent本身的配置
主要是对agent如何采集数据的配置，这个配置在agent/config/agent.config下，所以在镜像构建的时候就要配置好，也可以通过环境变量注入
环境变量注入思路：agent.config可以读取环境变量的值，所以我们在dockerfile或者yaml中注入环境变量可以替换agent的参数
配置参考：github.com/VanLiuZhi/d…
这样就可以忽略 healthy/** 端点
下面对配置文件做一个概述，我们可以参考原始镜像的目录来调整挂载路径，最好不要把整个目录都覆盖了，只挂载需要替换的配置文件是比较合理的做法。具体的配置文件可以从镜像内部获取，或者参考官方发行版的配置
cluster 配置
主要是配置OAP服务的部署模式，这里采用k8s来部署集群，通过修改副本数就可以实现服务高可用
kubernetes:
watchTimeoutSeconds: ${SW_CLUSTER_K8S_WATCH_TIMEOUT:60}
namespace: ${SW_CLUSTER_K8S_NAMESPACE:skywalking-min}
labelSelector: ${SW_CLUSTER_K8S_LABEL:app=oap}
uidEnvName: ${SW_CLUSTER_K8S_UID:SKYWALKING_COLLECTOR_UID}
复制代码修改选择标签到对应的OAP deployment。另外注意使用k8s作为集群模式，需要提供k8s RBAC 访问权限，经过测试，在8.0.0版本下，没有访问权限的话无法使用k8s来部署集群
storage 配置，数据存储位置
注意是es的地址和账号密码，nameSpace的作用是在索引前面加前缀，方便区分集群中的其它索引。调整副本和分片数，指定数据存储时间recordDataTTL
storage:
elasticsearch7:
nameSpace: "eos_sw"
clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:10.90.xx.xx:9200}
protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}
# trustStorePath: ${SW_SW_STORAGE_ES_SSL_JKS_PATH:"../es_keystore.jks"}
# trustStorePass: ${SW_SW_STORAGE_ES_SSL_JKS_PASS:""}
user: ${SW_ES_USER:"elastic"}
password: ${SW_ES_PASSWORD:"123456"}
indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:1}
indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:1}
# Those data TTL settings will override the same settings in core module.
recordDataTTL: ${SW_STORAGE_ES_RECORD_DATA_TTL:3} # Unit is day
otherMetricsDataTTL: ${SW_STORAGE_ES_OTHER_METRIC_DATA_TTL:45} # Unit is day
monthMetricsDataTTL: ${SW_STORAGE_ES_MONTH_METRIC_DATA_TTL:18} # Unit is month
# Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html
bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # Execute the bulk every 1000 requests
flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # flush the bulk every 10 seconds whatever the number of requests
concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # the number of concurrent requests
resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000}
metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:5000}
segmentQueryMaxSize: ${SW_STORAGE_ES_QUERY_SEGMENT_SIZE:200}
复制代码关于application的配置需要注意的一点就是各个版本的配置是有一定出入的，比如8.X和6.X版本的es存储配置就不一样，所以建议从官方发行版下载文件，参考文件来修改
告警配置
举例：监控服务响应时间
# 规则名称
service_instance_resp_time_rule:
# 指定采集度量，service_instance_resp_time 是通过OAL查询定义的一个度量
metrics-name: service_instance_resp_time
op: ">"
# 阈值
threshold: 10
# 周期
period: 10
# 次数
count: 2
# 告警后静默时间
silence-period: 5
message: Response time of service instance {name} is more than 10ms in 2 minutes of last 10 minutes
复制代码官方的描述：阈值被设置为10毫秒，基本请求很容易到达阈值。周期是10分钟，次数是2次。最近2分钟内的平均响应时间超过10毫秒就告警，告警触发后，沉默5分钟后才会告警
官方的描述中，总觉得period周期这个概念没有体现，当然也可能是中文翻译的问题，上面的message部分就是官方原文描述，个人结合实际测试的理解：
period是周期，是评判的范围，单位是分钟，现在设置为10，那么count次数就是在10分钟内如果有2次指标超过阈值，就会触发告警，然后静默5分钟， 继续循环。10分钟的范围，假设前30秒就有2次达到阈值，那么就会触发告警，接着进入沉默期，然后继续判断。 如果10分钟的范围内只有1次，等待11分钟的时候又有一次，那么不告警。沉默期为0也不会马上发，最少间隔1分钟
实际测试的结果：
silence-period 的配置，这个配置决定了告警后静默时间，假如当前服务一直有问题，而且silence-period = 0 ，那么1分钟推送一次告警。如果silence-period = 1，那么就是2分钟推送一次告警(建立在当前服务一直有问题的前提下)
可以监控的指标：
OAL示例：
// 计算 Endpoint1 和 Endpoint2 的 p99 值
Endpoint_p99 = from(Endpoint.latency).filter(name in ("Endpoint1", "Endpoint2")).summary(0.99)
// 计算端点名以 `serv` 开头的端点的 p99 值
serv_Endpoint_p99 = from(Endpoint.latency).filter(name like ("serv%")).summary(0.99)
// 计算每个端点的响应平均时长
Endpoint_avg = from(Endpoint.latency).avg()
// 计算每个端点 p50, p75, p90, p95 and p99 的延迟柱状图, 每隔 50 毫秒一条柱
Endpoint_percentile = from(Endpoint.latency).percentile(10)
// 统计每个服务响应状态为 true 的百分比
Endpoint_success = from(Endpoint.*).filter(status = "true").percent()
// 统计每个服务响应码在 [200, 299] 之间的百分比
Endpoint_200 = from(Endpoint.*).filter(responseCode like "2%").percent()
// 统计每个服务响应码在 [500, 599] 之间的百分比
Endpoint_500 = from(Endpoint.*).filter(responseCode like "5%").percent()
// 统计每个服务的调用总量
EndpointCalls = from(Endpoint.*).sum()
disable(segment);
disable(endpoint_relation_server_side);
disable(top_n_database_statement);
复制代码在6.5.0之后的版本中，可以通过配置中心来动态修改告警规则配置
官方中文翻译：github.com/SkyAPM/docu…
快速搭建：skywalking.apache.org/zh/blog/202…
-Dskywalking.agent.service_name=skywalking-test-local -Dskywalking.collector.backend_service=127.0.0.1:11800 -javaagent:D:\JavaLearProject\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
Backend的gRPC相关的API可访问0.0.0.0/11800，rest相关的API可访问0.0.0.0/12800
启动模式 在不同的部署工具（如K8S）中，可能需要不同的启动模式。 我们还提供另外两种可选的启动模式。
默认模式 默认模式。如果需要，进行初始化工作，启动监听并提供服务。
运行 /bin/oapService.sh(.bat) 来启动这个模式。也可以在使用 startup.sh(.bat)来启动。
初始化模式 在此模式下，OAP服务器启动以执行初始化工作，然后退出。 您可以使用此模式初始化存储，例如ElasticSearch索引、MySQL和TIDB表，和init数据。
运行 /bin/oapServiceInit.sh(.bat) 来启动这个模式。
非初始化模式 在此模式下，OAP服务器不进行初始化。 但它等待存在弹性搜索索引、mysql和tidb表，开始倾听并提供服务。意味着此OAP服务希望别的OAP服务器进行初始化。
运行 /bin/oapServiceNoInit.sh(.bat) 来启动这个模式。
application.yml 作为核心配置文件
Level 1, 模块名。模块定义项。 Level 2, 模块类型。 设置模块类型。 Level 3. 类型属性。
storage:
selector: mysql # the mysql storage will actually be activated, while the h2 storage takes no effect
h2:
driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource}
url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db}
user: ${SW_STORAGE_H2_USER:sa}
metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000}
mysql:
properties:
jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/swtest"}
dataSource.user: ${SW_DATA_SOURCE_USER:root}
dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root@1234}
dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true}
dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250}
dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048}
dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true}
metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000}
# other configurations
复制代码storage is the 模块名 selector 模块类型. default 模块默认属性. driver, url, ... metadataQueryMaxSize 类型属性.
同时，模块包括必修模块和可选模块，必修模块提供后端框架， 即使模块化支持可插拔，删除这些模块是没有意义的，对于可选模块，其中一些有 一个名为“none”的提供程序实现，这意味着它只提供一个没有实际逻辑的shell，典型的例子是telemetry。 将“-”设置为“selector”意味着在运行时将排除整个模块。 我们强烈建议您不要尝试更改这些模块的api，除非你非常了解SkyWalking项目及其代码。
必须的模块列表
Core。做所有数据分析和流调度的基本和主要框架。 Cluster。管理集群中的多个后端实例，这可以提供高吞吐量的处理能力。 Storage。持久化分析结果。 Query。提供查询接口给UI。 对于Cluster 和Storage 有多个实现者(提供者), 查看 Cluster management 和 Choose storage 的link list文档。
一些receiver 模块也提供了。 Receiver是一个模块，负责接受后端的传入数据请求。大多数（所有）通过一些rpc协议，如GRPC和HTTPrestful提供。 Receiver有许多不同的模块名，你可以阅读link list中的Set receivers文档。
java -Dapp.id=spring-demo -javaagent:/opt/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_name=spring-demo -Dskywalking.collector.backend_service=oap:11800 -jar /app/app.jar
实体名称 定义范围和实体名称之间的关系.
服务: 服务名称 实例: {服务名称} 的 {实例名称} 端点: {服务名称} 中的 {端点名称} 数据库: 数据库服务名 服务关系: {源服务名称} 到 {目标服务名称} 实例关系: {源服务名称} 的 {源实例名称} 到 {目标服务名称} 的 {目标实例名称} 端点关系: {源服务名称} 中的 {源端点名称} 到 {目标服务名称} 中的 {目标端点名称}
触发告警条件：由周期，次数，沉默期来共同决定
官方描述：
端点平均响应时间在最近 2 分钟内超过1秒
service_instance_resp_time_rule:
metrics-name: service_instance_resp_time
op: ">"
threshold: 1000
period: 10
count: 2
silence-period: 5
message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes
复制代码举例：监控服务响应时间
metrics-name: service_instance_resp_time
op: ">"
threshold: 10
period: 10
count: 2
silence-period: 5
复制代码阈值被设置为10毫秒，基本请求很容易到达阈值。周期是10分钟，次数是2次。最近2分钟内的平均响应时间超过10毫秒就告警，告警触发后，沉默5分钟后才会告警，这是官方的描述
个人结合实际测试的理解：period是周期，是评判的范围，单位是分钟，现在设置为10，那么count次数就是在10分钟内如果有2次指标超过阈值，就会触发告警，然后静默5分钟。继续循环
10分钟的范围，假设前30秒就有2次达到阈值，那么就会触发告警，接着进入沉默期，然后继续判断 如果10分钟的范围内只有1次，等待11分钟的时候又有一次，那么不告警。沉默期为0也不会马上发，最少间隔1分钟
实际测试的结果：
silence-period 的配置，这个配置决定了告警后静默时间，假如当前服务一直有问题，而且silence-period = 0 ，那么1分钟推送一次告警。如果silence-period = 1，那么就是2分钟推送一次告警(建立在当前服务一直有问题的前提下)
CPM: 每分钟请求调用的次数 SLA: 服务等级协议（简称：SLA，全称：service level agreement）
是在一定开销下为保障服务的性能和可用性。
网站服务可用性SLA，9越多代表全年服务可用时间越长服务更可靠，停机时间越短
1年 = 365天 = 8760小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
从以上看来，全年停机5.26分钟才能做到99.999%，即5个9
百分位数：skywalking中有P50，P90，P95这种统计口径，就是百分位数的概念。
例如，p99 520 表示过去 1% 请求的平均延迟为 0.52 秒，99%的请求低于 0.52；p95 300 表示 95%的请求响应时间低于 0.3 秒
应用性能指数（APDEX）通过计算分数来反映系统状况，计算规则由多个指标组成
总共用到下面这几个文件，目前官方的部署是基于helm来做的，只能自己编写yaml文件了
使用官方最新版 8.0.0 版本镜像，8.0.0-es7(oap) 8.0.0(ui)
skywalking-min-oap-configmap.yaml skywalking-min-oap-deployment.yaml skywalking-min-oap-namespace.yaml skywalking-min-oap-service.yaml skywalking-min-oap-serviceaccount.yaml skywalking-min-ui-deployment.yaml skywalking-min-ui-service.yaml
具体分为两个模块，oap和ui
其中ui比较简单，连接oap:12800服务即可
oap涉及到两个端口，暴露这两个端口
然后挂载配置文件，从源码上拷贝配置文件，并通过configmap挂载，注意只挂载自己需要的，具体挂载文件内容和路径参考容器自身情况 一般只需要挂载配置文件和告警规则文件，如果需要定制日志，那么再挂载log配置文件
配置文件注意：
主要是storage存储配置，这里采用es，需要修改es配置
然后集群模式采用k8s的服务发现，为此需要k8s rbac服务，在yaml中有定义一个service-account，不然没有访问权限无法使用k8s做集群模式
具体参考es部分
PUT /_cluster/settings
{
"persistent": {
"cluster": {
"max_shards_per_node":10000
}
}
}
复制代码链接：https://juejin.cn/post/7031823173498699784
在本教程中，我们有一个使用 HTML、CSS 和 JS 制作的待办事项列表应用程序，我们将把它与 Cerbos 集成以向应用程序添加授权。授权确定用户是否可以执行特定操作或访问某些资源或数据。它使组织能够控制和保护对敏感数据库、私人和个人数据以及公司资源的访问。在我们的 JS 应用程序中，授权将定义用户可以执行的操作（创建待办事项并阅读待办事项）以及管理员可以执行的操作（创建、阅读和删除待办事项）。
基于角色的访问控制 (RBAC)是一种访问控制方法，它根据最终用户的组织角色为其分配权限。RBAC 提供细粒度的控制，提供了一种简单、易于管理的访问管理方法，与单独分配权限相比，这种方法不容易出错。
使用 RBAC 的优点是管理授权权限变得更加容易，因为系统管理员可以批量管理用户和权限，而不是逐个管理。
我们已经定义了 RBAC 策略，并将集成 Cerbos 以根据用户身份授权创建、读取和删除待办事项。我们对谁可以做什么的业务要求如下：
Cerbos 是一个开源授权层，可让您轻松实现应用程序的授权。在Cerbos，我们提供细粒度的访问控制来增强安全性，同时使您的应用程序更快、更具可扩展性。使用 Cerbos 进行授权具有使用严格的 JS 代码无法获得的各种优势
当组织采用 RBAC 访问模型时，必须遵守有关安全和管理的最佳实践，并致力于不断改进其访问协议以防范新出现的威胁。
以下列表包含一些您必须遵循的 RBAC 最佳实践：
我们将在示例代码中使用这些角色来演示访问控制如何工作。
使用 Cerbos，访问规则始终面向资源，您编写的策略会映射到系统中的这些资源。资源可以是任何东西，而您建模策略的方式则由您决定 — 您可以通过多种方式实现相同的逻辑结果：以操作为主导、以角色为主导、以属性为主导或以它们的组合为主导。
话虽如此，有些模式更适合特定场景——让我们看看一些不同的方法。考虑这个权限模型：
Actions | Roles | ||||
CPO | CTO | Exec-1 | Exec-2 | Exec-3 | |
View | Allowed | Allowed | Allowed | Allowed | Allowed |
Add | Allowed | Allowed | Allowed | Allowed | Allowed |
Delete | Allowed | Allowed | Not Allowed | Not Allowed | Not Allowed |
我们将描述以行动为主导的政策，因为我们已经为我们的 JS 应用程序实施了以行动为主导的政策。
在这里，我们关注一个动作并列出可以执行该动作的所有角色。为了更好地理解这一点，我们文档中列出了一个示例，如下所示：
# Principals in the following three roles can perform the `run` action
- actions:
- "run"
effect: EFFECT_ALLOW
roles:
- JR_MANAGER
- SR_MANAGER
- CFO
# All principals can perform the `view` action
- actions:
- "view"
effect: EFFECT_ALLOW
roles:
- ["*"]
如果您的系统符合以下任一情况，则此方法可能适用：
构建成功后，您应该会看到网页在浏览器的localhost:5500上加载。
目前，没有任何策略，此应用程序中的 CPO 和 CTO 被授予删除待办事项的权限，而高管（1、2 和 3）只能查看和添加待办事项。但是，由于我们尚未将 Cerbos 与应用程序集成以进行权限管理，因此 CTO 和 CPO 无法删除待办事项。成功集成 Cerbos 后，CTO 和 CPO 将能够删除待办事项。
要将 Cerbos 集成到我们的 JavaScript 应用程序中，我们首先要启动 Cerbos Docker 容器。在根目录 (/to-dolist-cerbos) 中使用以下命令运行 Docker 容器：
docker run --rm --name cerbos -d -v $(pwd)/cerbos/policies:/policies -p 3592:3592 -p 3593:3593 ghcr.io/cerbos/cerbos:0.34.0
Cerbos Playground是一款用于在线创建和测试策略的实用程序。Cerbos Playground 是了解策略创建甚至生成可用策略的绝佳方式：https://play.cerbos.dev/new ?generator 。
如何使用 RBAC 策略生成器为我们的 javascript 应用程序生成策略？
我们有两个角色：用户和管理员（其中 CTO/CPO 是管理员，而高管是用户）。添加操作并根据我们要授予的权限选择复选框。
根据偏好选择后，我们可以点击**生成**按钮，生成一个名为to-dos.yaml的YAML策略文件。
使用生成器生成策略后，只需将其复制并添加到应用程序的文件结构中即可。策略生成器还会生成一个 to-dos_test.yaml 文件，该文件旨在帮助自动测试访问控制策略。确保测试文件始终以 _test 后缀结尾。以下是它通常包含的内容和功能：
现在我们已经将 Cerbos 与 JS 应用程序集成，我们将运行它来检查策略是否按预期工作。
让我们使用测试文件和 Cerbos RBAC 策略生成器生成的 _testdata _ 来测试策略文件。
您可以使用此 Docker 命令（在 PowerShell 终端中）来运行测试：
docker run -i -t -v "$(Get-Location)/cerbos/policies:/policies" ghcr.io/cerbos/cerbos:latest compile /policies
运行此命令后，测试成功执行。
如果高管（具有角色：用户）尝试删除待办事项：
随着政策的实施，高管不得删除待办事项；他们会收到一条警告：您无权删除此待办事项。该权限仅授予 CPO 和 CTO 角色。
根据政策，高管可以将待办事项添加到列表中：
将任务添加到文本框并单击添加待办事项按钮将其添加到待办事项列表中。
CPO 已授权，待办事项已成功删除。
这个实际演示成功地描绘了 Cerbos 与我们的 JS 应用程序的集成。
Q1. 制定 RBAC 政策时我们必须考虑哪些最佳实践？
A1：当组织采用 RBAC 访问模型时，必须遵守有关安全和管理的最佳实践，并致力于不断改进其访问协议，以防范新出现的威胁。
以下列表包含 RBAC 最佳实践的公平样本：
问题 2：在政策生效之前，可以使用 Cerbos 进行测试吗？
A2：是的，可以在策略生效之前使用 Cerbos 对其进行测试。Cerbos 提供强大的策略测试功能，允许您在将访问控制规则部署到生产环境之前对其进行验证。使用 Cerbos Policy Generator 中提供的 Cerbos 测试框架，您可以确保策略强制执行所需的访问控制规则并避免实际场景中的潜在问题。这种部署前测试有助于维护访问控制策略的完整性和安全性，降低未经授权访问的风险并确保遵守组织的安全准则。
您已通过以下关键步骤成功将 Cerbos 集成到演示待办事项列表应用程序中：
*请认真填写需求信息，我们会在24小时内与您取得联系。
