开发者学堂课程【云原生实践公开课：监控和日志管理的最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/698/detail/12272
监控和日志管理的最佳实践
内容介绍：
一、背景
二、监控实践
三、日志实践
四、总结
一、背景
云原生监控和日志管理
云原生可观测性主要由监控与日志两大部分组成，监控系统可以帮助开发者查看系
统的运行状态，而日志系统可以协助问题的排查和诊断。
本课程将根据阿里云容器服务的实践经验，总结最佳实践，便于观众快速切入主
题、应用到具体实践中，增强云原生系统建设以及管理能力。
Kubernetes的监控体系–常用的监控方式
资源监控
CPU、内存、网络等资源类的指标，常以数值、百分比为单位进行统计，是最常见的资源监控方式。
K8s业务监控
Deployment, Pod等K8s资源监控，Apiserver/Scheduler/
Controller-Manager等K8s业务指标监控。
性能监控
应用的内部监控，通常是通过Hook的机制在虚拟机层、字节码执行层隐式回调，或者在应用层显示注入，获取更深层次的监控指标，常用来应用诊断与调优。
安全监控
针对安全进行的一系列监控策略，例如越权管理、安全漏洞扫描等等。
事件监控
Kubernetes 中一种另类的监控方式，紧密贴合Kubernetes的设计理念，补充常规监控方案的缺欠与弊端。
二、监控实践
Prometheus监控K8s的架构
创建Prometheus监控系统实践
演示创建Prometheus 监控系统过程。
后面以该系统的配置为例讲解最佳实践。
具体过程包括:
1.监控对象开发，透出指标
2.部署Prometheus监控系统，配置Prometheus监控对象
3.通过PromQL查询采集到的指标数据
Prometheus最佳实践–Time Series, Metric, Label,Samples
时间序列:
streams of timestamped values belonging to the same metric and the same set of labeled dimensions.Metric和Label的不同键值对对应一个唯一的时间序列。
Metric Names and Labels:
Every time series is uniquely identified by its metric name and optional key-value pairs called labels.
样本( Samples) :
Samples form the actual time series data.Each sample consists of:
a float64 value
a millisecond-precision(毫秒精度) timestamp
时间序列标记:
{=,.}
时间序列例子:
api_http_requests_total{method="POST", handler="/messages"}
Prometheus最佳实践–监控对象Metric和Label的设计以及透出
最佳实践：不要把label作为指标名字的部分，避免混淆
最佳实践：不要使用label保存高维度的信息（例如用户ID，邮箱等），否则会显著增加保存数据量。每一组的key-value组合对应一个时间序列。https:/lgithub.com/prometheus/client_golang/blob/master/examples/random/main.go
1. 定义指标
var {
//Create a summary to track fictional interservice RPC latencies for three
//distinct services with different latency distributions.These services are
// differentiated via a "service" label.
rpcDurations = prometheus.NewSummaryVec(
prometheus.SummaryOpts{
Name:“rpc_durations_seconds",
Help:“RPC latency distributions.",
Objectives: map[float64]float64{0.5:0.05,0.9:0.01,0.99:0.001},//分位数以及容忍误差
},
[]string{"service"},
）
2。注册指标func init(){
//Register the summary and the histogram with Prometheus's default registry.
prometheus.MustRegister(rpcDurations)
}
3.更新指标值
//Periodically record some sampke latencies for the three services.
go func(){
for {
v := rand.Float64()**uniformDomain
rpcDurations.WithLabelValues("uniform").Observe(v)
time.Sleep(time.Duration(100*oscillationFactor())
*time.Millisecond)
}
}（）
4.HTTP服务对外透出指标
//Expose the registered metrics via HTTP.
http.Handle(" /metrics", promhttp.HandlerFor(
prometheus.DefaultGatherer,
promhttp.HandlerOpts{
//Opt into OpenMetrics to support exemplars.
EnableOpenMetrics: true,
},
））
log.Fatal(http.ListenAndServe(*addr, nil))
Prometheus最佳实践-Kubernetes配置服务发现
https://qithub.com/prometheus/prometheus/blob/release-2.20/documentation/examples/prometheus-kubernetes.yml
- Node
适用于与主机相关的监控资源，如节点中运行的Kubernetes组件cadvisor状态、节点上运行的容器状态等
- Service
适用于通过黑盒监控的场景，如对服务的可用性以及服务质量的监控地址可以是K8s Service DNS域名＋端口
- Pod
适用于Pod，并暴露Pod的容器为目标( Target )
- Ingress
适用于通过黑盒监控的场景，如对服务的可用性以及服务质量的监控.
- Endpoints
发现 Service后端的Endpoints
Prometheus最佳实践–配置relabel_configs和
metric_relabel_configs
采集生命周期:
服务发现->配置->relabel_configs->采集
(Scrape)->metrics_relabel_configs
relabel_configs在采集之前完成，metrics_relabel_configs在采集之后、保存到存储系统之前完成。
determines the relabeling action to take:
replace : Match regex against the concatenated source_labels
. Then, set target_label to
replacement , with match group references( $i1}，${2},..) in replacement substituted by their value. fregex does not match, no replacement takes place.
keep : Drop targets for which regex does not matcconcatenated source_labels .drop : Drop targets for which regex matches the concatenated
source_labels .
hashmod : Set target_label to the modulus of a hash of the
concatenated
source_labels .
labelmap : Match regex against all label names. Then copy
the values of
the matching labels to label
names given by replacement with match group references($i1}，${2} ...) in replacement substituted bytheir value.
labeldrop : Match regex against all label names. Any label
that matches
will be removed from the set oflabels.
labelkeep : Match regex against all label names.Any label
that does not match will be removed from theset of labels
- job_name: 'kubernetes-state-metrics'
kubernetes_sd_configs:
- role: service ll#服务发现方式是service
scheme: http
tls_config:
ca_file:/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.iolserviceaccount/token
relabel_configs:
-source_labels: [_meta_kubernetes_namespace,_meta_kubernetes_service_name,meta_kubernetes_service_port_name]
action: keep ###选择符合{namespace=monitoring;servicename=kube-
-state-metrics;serivceport=http-metrics}的对象
regex: monitoring;kube-state-metrics;http-metrics
最佳实践:对于采集数据量大的情况，为节省存储空间，只采集需要的metrics。
metric_relabel_configs:
- source_labels: [_name__]
action: keep
regex: (i)(apiserver_request_count|apiserver_current_inflight _requests|apiserver _dropped_requests_total)
Prometheus最佳实践–联邦集群
最佳实践:使用Federation的一种场景是-当多个LeafPrometheus同时存在于不同DC/集群，可以通过Federation将数据聚合到Global Prometheus，进行集中的数据处理（例如监控大盘，告警等
- scrape_config:
- job_name: dc_prometheushonor_labels: true
metrics_path: /federateparams:
match[]:
- 'l_name_=~"Njob:.*"}’# Request all job-level time series
static_configs:
- targets:
- dc1-prometheus:9090
- dc2-prometheus:9090
Prometheus最佳实践–水平分片vs 联邦集群
最佳实践:
当监控对象规模太大，单个Prometheus所在主机资源无法承担（表现为经常Prometheus持续OOM)，可以水平扩展为多个分片，也就是若干个主机上
Prometheus共同采集，每个Prometheus负责采集集群的子集监控数据。
Prometheus局限性->诞生大规模化场景下的
Thanos/Cortex方案
Prometheus最佳实践-K8s 监控系统设计原则
1. 资源估算∶根据监控集群的规模、分布、网络、以及未来发展趋势，估算Prometheus需要的磁盘、内存、带宽等资源。
2. 架构设计:合理拆分Prometheus的监控域，设计架构
- 单集群监控/多集群监控
- 单地域/跨多地域
- Prometheus 水平分片/联邦集群·是否使用Prometheus Operator
- prometheus/AlertManager是否HA架构
3.告警设计:在多级Prometheus架构中，告警能力需要下沉到Leaf Prometheus，这样子可以有效降低告警链路的时延;并对告警时延有完整的阶段分析，计算出系统最差情况下的告警时延;为提升告警可靠性，可以使用多副本AlertManager提升HA高可用性。
4.可视化设计:基于Grafana设计不同业务/资源维度的监控大盘，已经基于大盘的告警，可以非常直观的看到抖动、毛刺、请求错误已以及异常，帮助业务保障、压测等。
5.数据分析∶监控数据是非常宝贵的资源，可以作为AlOps的输入进行算法训练以及预测等高级用法，也是目前非常火热的技术方向。
三、日志实践
Kubernetes中日志的分类
主机内核的日志:
主机内核日志可以协助开发者诊断例如:网络栈异常，驱动异常，文件系统异常，影响节点（内核）稳定的异常。
Runtime的日志:
最常见的运行时是Docker，可以通过Docker的日志排查例如删除Pod Hang等问题。
核心组件的日志:
APIServer日志可以用来审计，Scheduler日志可以诊断调度，etcd日志可以查看存
储状态，Ingress日志可以分析接入层流量。
部署应用的日志:
可以通过应用日志分析查看业务层的状态，诊断异常。
Kubernetes中日志的采集方式
日志最佳实践–审计日志
审计（Audit)日志功能，审计（Audit ）提供了安全相关的时序操作记录（包括时
间、来源、操作结果、发起操作的用户、操作
的资源以及请求/响应的详细信息等），通过审计日志，我们能够非常清晰的知道
K8s集群到底发生了什么事情，包括但不限
于∶
1. 当前/历史上集群发生了哪些变更事件。
2. 这些变更操作者是谁，是系统组件还是用户，是哪个系统组件/用户。
3. 重要变更事件的详细内容是什么，比如修改了POD中的哪个参数。
4. 事件的结果是什么，成功还是失败。
5. 操作用户来自哪里，集群内还是集群外。
阿里云审计日志方案:
https://developer.aliyun.com/article/686982
四、总结
云原生可观测性是为了更全面、更快速、更准确地发现系统的问题，核心目标是为了提高系统的稳定性，提升系统稳定性不能只依赖可观测性的滞后的运维操作，而是要把怎么减少出现问题并降低影响范围，怎么准确快速定位问题整合起来。
