Prometheus

Prometheus简介 Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 Prometheus简史 Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。 监控的目标 在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的： ***长期趋势分析：***通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断

分布式架构发展史： 单机小型机时代: 　　1969年，阿帕网诞生，最初是为了军事目的，后来衍变成Internet。2000年左右，互联网在中国开始盛行起来，但是那时候网民数较少，所以多数企业服务单一，采用集中式部署的方式就能满足需求 　　但是这样的部署方式带来了一定的问题，一旦小型机或者数据库出现问题，会导致整个系统的故障，而且功能修改发布也不方便，所以不妨把大系统拆分成多个子系统，比如“用户”，“商品”，“论坛“等，也就是”垂直拆分“，并且每个子系统都有各自的硬件 集群化负载均衡时代: 　　用户量越来越大，就意味着需要更多的小型机，价格昂贵，操作维护成本高，不妨把小型机换成普通的PC机，采用多台PC机部署同一个应用的方案，但是此时就需要对这些应用做负载均衡，因为客户端不知道请求哪一个。 　　负载均衡可以分为硬件和软件，硬件比如F5，软件比如LVS(Linux Virtual Server)，nginx，haproxy。负载均衡的思路是对外暴露一个统一的接口，然后根据用户的请求进行对应规则的转发。同时负载均衡还可以做健康检查、限流等有了负载均衡，后端的应用就可以根据流量的大小进行动态的扩缩容了，也就是“水平扩展”。 服务化时代: 　　此时发现在用户，商品和订单等中有重复的功能，比如登录、注册、邮件等。一旦项目大了，集群部署多了，这些重复的功能无疑是浪费资源，不妨把重复的功能抽取出来

不久前我们开源了基于 Kubernetes 的混沌测试工具 Chaos Mesh® ，Chaos Mesh 提供了模拟系统异常状况的能力，但这只是混沌工程中的一环，完整混沌工程核心原则包含了系统稳定状态的定义、提出假设、运行实验以及验证和改进。 本篇文章主要介绍我们是如何在 Chaos Mesh 和 Argo 的基础上打造自己的自动化测试平台 TiPocket （https://github.com/pingcap/tipocket） ，实现完全自动化的混沌测试，构成混沌测试完整闭环。 为什么需要 TiPocket? 为了确保用户的数据安全，我们需要确保给用户提供的每一个 TiDB 版本都已经经过了严格的测试，所以我们为 TiDB 设计了各种异常场景，并实现了数十个测试 Case，所以在我们的 Kubernetes 集群中，可能同时运行着十几个甚至几十个混沌实验，即使我们拥有了 Chaos Mesh 来帮助我们管理错误注入，但这还远不够，我们还需要去管理 TiDB 集群，需要去收集指标，需要去分析结果，同时进行如此多的混沌实验，另一方面，我们还需要对 TiDB 生态中的其他工具进行混沌测试，这是无法想象的，因此，我们开发了 TiPocket 来解放自己。 TiPocket 是一个基于 Kubernetes 和 Chaos Mesh 的完全自动化测试框架 ，目前我们主要使用它用来测试

Loki简介 Grafana Loki是可以组成功能齐全的日志记录堆栈的一组组件。 与其他日志记录系统不同，Loki是基于仅索引有关日志的元数据的想法而构建的：标签（就像Prometheus标签一样）。 然后，日志数据本身被压缩并存储在对象存储（例如S3或GCS）中的块中，甚至存储在文件系统本地。 小索引和高度压缩的块简化了操作，并大大降低了Loki的成本。 相较于EKL，Loki就显得很轻量级了；用了Loki以后，ELK突然不香了！哈哈~~~ Loki-stack组件 先放两张图 Promtail Promtail 是用来将容器日志发送到 Loki 或者 Grafana 服务上的日志收集工具，该工具主要包括发现采集目标以及给日志流添加上 Label 标签，然后发送给 Loki，另外 Promtail 的服务发现是基于 Prometheus 的服务发现机制实现的。 Loki Loki 是可以水平扩展、高可用以及支持多租户的日志聚合系统，使用了和 Prometheus 相同的服务发现机制，将标签添加到日志流中而不是构建全文索引。因此，从 Promtail 接收到的日志和应用的 metrics 指标就具有相同的标签集。它不仅提供了更好的日志和指标之间的上下文切换，还避免了对日志进行全文索引。 Grafana Grafana 是一个用于监控和可视化观测的开源平台，支持非常丰富的数据源，在

一、Grafana基础 Grafana是一个开源的指标量监测和可视化工具。官方网站为： https://grafana.com/， 常用于展示基础设施的时序数据和应用程序运行分析。Grafana的dashboard展示非常炫酷，绝对是运维提升逼格的一大利器。 官方在线的demo可以在这里找到: http://play.grafana.org/ Grafana是一个通用的可视化工具。这意味着Grafana不仅仅适用于展示zabbix下的监控数据，也同样适用于一些其他的数据可视化需求。在开始使用Grafana之前，我们首先需要明确一些Grafana下的基本概念，以帮助用户能够快速理解Grafana。 1、数据源（datasource ） 数据的存储源，它定义了将用什么方式来查询数据展示在grafana上面，不同的datasource拥有不同的查询语法，grafana支持多种数据源，官方支持以下数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch。 每个数据源的查询语言和能力各不同，我们可以将来自多个数据源的数据组合到一个仪表盘中，但是每个面板都绑定到属于特定组织的特定数据源。 2、仪表盘（Dashboard ） 通过数据源定义好可视化的数据来源之后，对于用户而言最重要的事情就是实现数据的可视化