Prometheus

作者 | 邱戈川（了哥） 阿里云智能云原生应用平台部高级技术专家 本文根据云栖大会全面上云专场演讲内容整理，关注阿里巴巴云原生公众号，回复“ 迁移 ”获得本文 PPT 今天上午王坚博士讲了一句话我比较有感触，大家做系统的时候，一定要想下你的系统的数据是怎么流转，这些系统的数据是怎么形成闭环。我们在设计阿里云的 K8s 容器服务 ACK 的时候也是融入了这些思考。 容器迁云解决方案一览 首先是和大家先看一下整个容器上云的解决方案。首先因为你已经做过容器，所以当你容器上云的时候，实际上这个事情是非常简单的，我们只需要提供的相应的工具，帮助大家把容器镜像迁入阿里云同时通过工具把 K8s 的配置迁到阿里云，以及可以用 DTS 工具把数据库迁入到阿里云。这样我们就可以完成一个完整的容器化上云的过程。 所以这个过程其实非常简单，但是上完云之后，不是说我们的 K8s 原来怎么玩现在还是怎么玩。我们希望大家从上云的过程中有些收益，所以我们希望提供一些更高效敏捷的一些方式给到大家，包括怎么去做 DevOps，包括我们怎么去做安全的软件供应链，以及我们做灰度发布。 同时我们希望成本更优一点，关键是大家上完云之后的成本怎么去核算，以及怎么去节约。所以容器上云后我们怎么去做更好的弹性伸缩、做自动化的运维，这个是大家需要在上云的过程中去考虑的问题。同时我们需要更好的管理我们的系统，一定要做到更好的高可用

我们在发布一个 go 应用时，默认都会启用两个 http handler: 一个是 pprof，方便线上动态追踪问题；另外一个是 prometheus 的 metrics，这样就可以通过 grafana 准实时的监控当前 runtime 信息，及时预警。就像下面这样： package router import ( "net/http" _ "net/http/pprof" "github.com/prometheus/client_golang/prometheus/promhttp" ) func InitAdmin () { adminRouter := http . DefaultServeMux adminRouter . Handle ( "/metrics" , promhttp . Handler ()) adminServer = & http . Server { Addr : ":8081" , Handler : adminRouter , } go func () { if err := adminServer . ListenAndServe (); err != nil { println ( "ListenAndServe admin: " , err . Error ()) } }() } 最近我在优化一个 push 服务的时候，便观察到了一个

需求 公司项目采用微服务的架构，服务很多，每个服务都有自己的日志，分别存放在不同的服务器上。当查找日志时需要分别登录不同的服务器，有大量的请求的情况下，在日志文件中查找信息十分困难。想要搭建一个日志系统，ELK分布式日志系统对于中小型公司来说开发维护成本太高，经过调研，选择Loki轻量级日志系统。 Loki简介 Loki 是一个水平可扩展，高可用性，多租户日志聚合系统,灵感来自 Prometheus ，其设计非常经济高效，易于操作。它不索引日志的内容，而是为每个日志流设置一组标签。 Loki与其他日志聚合系统差别： 不对日志进行全文本索引。通过存储压缩的，非结构化的日志以及仅索引元数据，Loki更加易于操作且运行成本更低。 使用与Prometheus相同的标签对日志流进行索引和分组，从而使您能够使用与Prometheus相同的标签在指标和日志之间无缝切换。 特别适合存储Kubernetes Pod日志。诸如Pod标签之类的元数据会自动被抓取并建立索引。 在Grafana中原生支持（需要Grafana v6.0及以上）。 Loki的日志系统的组件： Promtail是代理，负责收集日志并将其发送给Loki。 Loki是主服务器，负责存储日志和处理查询。 Grafana用于查询和显示日志。 搭建步骤 本文采用的搭建方式是分别下载各个组件并安装。也可以参考官方的文档进行搭建安装。

今天，我们兴奋地宣布作为迄今为止最强大的Linkerd版本，Linkerd 2.9已经正式推出！此版本将Linkerd的零配置双向TLS（mTLS）支持扩展到所有TCP连接当中，使得Linkerd在集群安装完成之后即可透明加密并验证集群中的全部TCP连接。2.9版本还增加了对ARM架构的支持，包括引入新的多核代理运行时以提高吞吐量，同时支持Kubernetes服务拓扑等。 此版本源自50多位贡献者的不懈努力，在这里感谢Abereham G Wodajie，Alexander Berger，Ali Ariff，Arthur Silva Sens，Chris Campbell，Daniel Lang，David Tyler，Desmond Ho，Dominik Münch，George Garces，Herrmann Hinz，Hu Shuai，Jeffrey N. Davis，Joakim Roubert，Josh Soref，Lutz Behnke，MaT1g3R，Marcus Vaal，Markus，Matei David，Matt Miller，Mayank Shah，Naseem，Nil，OlivierB，Olukayode Bankole，Paul Balogh，Rajat Jindal，Raphael Taylor-Davies，Simon Weald，Steve

前言 最近老黄一直在弄双11相关的东西，所以博客和github都没怎么更新，这期间在公司也弄了不少东西。 下面就简单分享一下最近做的业务监控相关的内容吧。 先来说一下背景。 某业务在双11第一波大促的时候因为没有提供实时的业务看板，总结会的时候技术同事被相关领导和业务人员投诉，说是没办法清晰的了解到当时的情况，不能及时有效的调整对应的策略。 事后老黄了解到，那个业务是比较老的业务了，资源比较紧张，不敢去实时怼数据库(单点)，怕数据库挂了，业务就全凉了。 为了避免尴尬的现状，不想再一次挨批，只能搞呀。 分析现状 3个应用，.NET Framework的项目，都是windows服务器，没有容器化。 离双11只有几天，不能改动太大，而且还要应对业务部门新的需求。 当时能想到的方案 业务埋点，接入prometheus，结合grafana 业务发MQ，消费数据到ES，前端做个面板 业务埋点，接入日志服务，结合仪盘表 大致分析 方案1，业务团队对prometheus几乎是0认知，了解相关概念都要花不少时间，pass 方案2，MQ目前用的是腾讯云的CMQ，被坑过2次了，也不能很好的hold住ES，pass 方案3，有按内部规范打日志，业务方只要在关键地方加一行对应的日志，然后交由logtail去采集，上传到日志服务 所以在这三种方案中，老黄还是选了 方案三 。

1、pv 简单介绍 PersistenVolume（PV）：对存储资源创建和使用的抽象，使得存储作为集群中的资源管理 PV分为静态和动态，动态能够自动创建PV • PersistentVolumeClaim（PVC）：让用户不需要关心具体的Volume实现细节 容器与PV、PVC之间的关系，可以如下图所示： 总的来说，PV是提供者，PVC是消费者，消费的过程就是绑定。 参考网址：1、https://www.cnblogs.com/weifeng1463/p/10037803.html 2、https://blog.csdn.net/qq_25611295/article/details/86065053 2、nfs 搭建： yum install nfs-utils vim /etc/exports /data/k8s/ 172.16.1.0/24(sync,rw,no_root_squash) systemctl start nfs; systemctl start rpcbind systemctl enable nfs 测试： yum install nfs-utils showmount -e 172.16.1.131 3、PersistentVolume 静态绑定 （手工创建PV、PVC） [root@VM_0_48_centos prometheus]# cat