企业网站系统的设计与开发教程,黄骅的网站,东莞企业营销型网站策划,做個app网站价格目录
前言
平台维度
docker运行状态
cAdvisor-日志采集者
Heapster-日志收集
metrics-server-出生决定成败
kube-state-metrics-不完美中的完美
应用维度
日志
部署方式
输出方式
工具选择
日志接入
监控
serviceMonitor Annotation Prometheus扩展性
Thanos
…目录
前言
平台维度
docker运行状态
cAdvisor-日志采集者
Heapster-日志收集
metrics-server-出生决定成败
kube-state-metrics-不完美中的完美
应用维度
日志
部署方式
输出方式
工具选择
日志接入
监控
serviceMonitor Annotation Prometheus扩展性
Thanos
方案一thanos sidecar thanos query
方案二thanos receive thanos query 总结 前言
运维体系中的日志和监控是个频率很高的知识点日志如何采集和收集监控如何采集和收集运行在容器云中的监控与云实例中的监控有什么本质区别本篇将为大家解读这些概念并对当前主流工具进行简单介绍。
首先要强调的一点是运行在容器云中业务的稳定性是由容器云平台稳定性和应用稳定性两部分决定的而前者是公有云实例场景中不需要考虑的也是容器云运维非常核心的一个模块。所以日志与监控也要按平台和应用两个维度来拆分。
平台维度
k8s是个很大的框架对于它的监控也是个很复杂的问题让我们从管理一个单独docker的视野开始感受下平台监控体系是如何生长的。
docker运行状态
docker运行状态怎么知道docker status命令可以知道容器运行的状态但它的缺点太多了只能手工敲命令不能http协议不能metric数据总之不符合自动化管理的理念。
cAdvisor-日志采集者
为了解决docker status的缺陷于是产生了cAdvisor。用工具替代手动它可以采集容器状态和CPU等资源指标核心分为machineInfo和containerInfo两个模块从模块名称可以看出不仅可以采集容器的指标还能采集宿主机的指标在K8S中集成在Kubelet里作为默认启动项每个node上运行一个cAdvisor。 cAdvisor帮我们解决了从手动到自动的过程BUT每个节点的cAdvisor指标需要单独采集不适合大规模集群。
Heapster-日志收集
cAdvisor虽然能提供有用的平台数据但其分散在每个node上Heapster负责把它们收集后统一处理。Heapster的本质就是一个收集者将每个Node上的cAdvisor的数据进行汇总然后导到第三方工具。 到此为止我们解决了监控的问题但还没有解决告警问题那就是Prometheus的天下了但Prometheus对监控数据格式有要求必须按照metric的格式来很遗憾Heapster不支持
metrics-server-出生决定成败 为了稳固Prometheus云原生监控一哥的地位Heapster被废弃metrics-server上位。可以说metrics-server要干的事跟Heapster要干的事基本是一样的但metrics-server通过 kube-apiserver ( /apis/metrics.k8s.io/可以将metric数据暴漏出来。
整个调用链是这样的Prometheus-metrics-server-kubelet-cAdvisor
kube-state-metrics-不完美中的完美
metrics-server并不是完美的有些k8s特定的场景它的监控指标并不能支持例如pod有没有重启过伸缩有没有成功所以新的帮手出现了kube-state-metrics
metric-server和kube-state-metrics是共生的关系它们侧重点不一样。metric-server关注的是k8s的资源监控指标kube-state-metrics关注于获取 k8s 各种资源的最新状态。 metric-server仅仅是获取、格式化现有数据写入特定的存储实质上是一个监控系统。而kube-state-metrics是将k8s的运行状况在内存中做了个快照并且获取新的指标但他没有能力导出这些指标
应用维度
日志
部署方式
应用日志采集在设计上分为DaemonSet和SideCar两种方式前者是运行在node上后者是运行在pod上那我们该如何取舍呢
DaemonSet在稳定性、侵入性、资源占用方面有优势但隔离性、性能方面SideCar方式更好。我们实践中会优先使用DaemonSet方式采集日志。如果某个服务日志量较大、吞吐量较高可以考虑为该服务的Pod配置Sidecar方式采集日志。
输出方式
应用日志的输出方式分为stdout和文件两种方式云原生12要素主推的是stdout但实际情况是做不到一方面需要研发团队愿意陪你改造另一方面确实有按场景输出到不同文件的需求。
工具选择
日志收集从古至今出现了不下于5种主流的角色loggie、Filebeat、Fluentd、Logstash、Flume我们该如何取舍呢
结论1工具没有好坏只有是否合适。结论2我们用的是loggie。出于性能上的考虑首先淘汰掉Logstash和Flume处于输出到文件的考虑又淘汰掉Filebeat和Fluentd所以留给我们的只有loggie了。 日志接入
容器云黑科技的接入基本都是通过CRDloggie也是这样实现的。定义了一种叫LogConfig的资源在它的manifest中通过spec.selector属性显式的定义了满足什么label的pod需要走什么样的pipeline。 监控
应用的监控就是面向服务的监控k8s中的服务就是service怎么能知道哪些service需要被Prometheus监控监控哪个入口service中动态的pod如何自动注册到Prometheus中来这一些列负载并且有关联的信息如何维护和管理答案还是CRD定义了一种叫serviceMonitor的资源
serviceMonitor 这里细节比较多展开来解释下首先定义一个serviceMonitor里面描述了满足什么条件的pod会去如何与Prometheus交互
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:labels:Service: demo-exportername: demo-exporternamespace: monitoring
spec:endpoints:## 与Prometheus交互的间隔- interval: 60s## 获取metrics数据的端口匹配的service中定义的端口名称port: demo-exporter-port## 获取metrics数据的pathpath: /metricsrelabelings:## 数据在Prometheus中打什么样的标签- sourceLabels: [__meta_kubernetes_pod_label_Cluster]targetLabel: Cluster- sourceLabels: [__meta_kubernetes_pod_label_Service]targetLabel: ServicenamespaceSelector:## 生效的命名空间列表matchNames:- prod- gray- canaryselector:matchLabels:## 生效pod的条件openMonitor: on
service中打开该开关即可
---
apiVersion: v1
kind: Service
metadata:name: foo-web-prodlabels:Cluster: fooService: foo-webopenMonitor: onnamespace: prod
spec:clusterIP: Noneselector:CPX: prodService: foo-webports:- port: 80name: httptargetPort: 80- port: 8088name: demo-exporter-porttargetPort: 8088
serviceMonitor的方式用起来还是不够爽有没有更简洁的接入方式呢有annotation Annotation
设计思路是我们不去专门为每个service提前定义描述文件而是让它们自己配置要怎么加入Prometheus例如
spec:template:metadata:annotations:prometheus.io/path: /stats/prometheus #指定pathprometheus.io/port: 8088 #指定端口prometheus.io/scrape: true #启用prometheus.io
这种设计需要改造两个地方一个是自动发现配置了annotation的就可以接入一个是标签可以保持pod自身的标签注入到Prometheus中。
参考文章Prometheus Operator高级配置 · 从 Docker 到 Kubernetes 进阶手册
这种设计思路虽然用起来贼爽但也有缺陷如果需要监控多个端口还得另想办法serviceMonitor就不存在这个问题它是支持多端口的endpoints配置是个列表。 Prometheus扩展性
从前面内容看得出无论是平台监控还是应用监控都离Prometheus但是咱这个云原生一哥也有他自身的缺陷那就是扩展性。Prometheus虽然性能强劲但是从设计出就是个单机产品算力、存储、网络吞吐都会成为压死骆驼的最后一根稻草在互联网级别的监控体系中需要“分布式”Prometheus才能扛得住生产的压力。
Thanos
为了解决Prometheus单机瓶颈Thanos横空出世。它也有两种落地方案各有优劣。
方案一thanos sidecar thanos query 方案二thanos receive thanos query sidecar方案优点落地简单只需要引入sidecar就好 sidecar方案缺点查询时Query效率不会太快Prometheus如果挂了可能会丢失近期数据。
receive方案优点结构清晰Prometheus无状态挂了不会丢数据Query效率比sidecar方案高且可扩展。 receive方案缺点需要新增和维护一套分布式存储Prometheus远程写带来的延时对使用有多大影响也需要评估。 总结
学习技术并不只是学会一个工具怎么用而是要学会一个工具是怎么来的它的前世今生和这个领域从古至今的历史。一个工具势必是为了解决某个问题而被发明的但它很可能又会在解决旧问题时引入新的缺陷。工具没有银弹方案设计就是根据自己场景选择优点忍受缺点的过程。
