grafana

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探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的： ***长期趋势分析：***通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断

理想很丰满，现实很骨感，线上业务系统，绝对不会万事如意，外在因素太多，总会出现这样那样的问题，所以，智能监控和报警，变得尤为重要；线上问题永远都是最重要的问题，必须尽早发现尽早解决。 一、背景 一张网络图，比较形象的描述线上业务系统的状况，虽然有点儿夸张，但这不假： 二、大纲 业务监控系统架构分析 监控模块的设计与优化 监控智能化的一些尝试 三、业务监控系统架构 没有完美的架构，任何架构都是平衡妥协的结果 3.1 设计背景 监控项不完善，需要快速完善监控项(痛点:快速实施) 运营活动频繁，报警收到麻木(痛点:报警太多) 上线调整时无实时直观的参考(痛点:不及时，不直观) 3.2 主流架构 3.2.1 案例 阿里： 蘑菇街： 3.2.2 特点 架构的核心关键字是:海量、实时 侧重于大数据的处理，报警分析偏弱，没有解决当时的痛点问题 公司已有大数据部门在做类似的事情 监控人手紧张且缺乏相关经验，存在一定风险 思考:大数据是否应该属于监控系统的一部分? 3.3 趣店当前监控架构 基于现有业务监控开发，利用已有资源 利用队列将系统拆分成不同模块，方便升级 利用现有的优秀开源软件 四、监控模块设计与优化 各个模块可以随时被更优的方案替换 4.1 采样模块 采集源： SQL、API、ElasticSea ch (实时日志收集)、其他更多 运行方式： crontab定时运行

理想很丰满，现实很骨感，线上业务系统，绝对不会万事如意，外在因素太多，总会出现这样那样的问题，所以，智能监控和报警，变得尤为重要；线上问题永远都是最重要的问题，必须尽早发现尽早解决。 一、背景 一张网络图，比较形象的描述线上业务系统的状况，虽然有点儿夸张，但这不假： 二、大纲 业务监控系统架构分析 监控模块的设计与优化 监控智能化的一些尝试 三、业务监控系统架构 没有完美的架构，任何架构都是平衡妥协的结果 3.1 设计背景 监控项不完善，需要快速完善监控项(痛点:快速实施) 运营活动频繁，报警收到麻木(痛点:报警太多) 上线调整时无实时直观的参考(痛点:不及时，不直观) 3.2 主流架构 3.2.1 案例 阿里： 蘑菇街： 3.2.2 特点 架构的核心关键字是:海量、实时 侧重于大数据的处理，报警分析偏弱，没有解决当时的痛点问题 公司已有大数据部门在做类似的事情 监控人手紧张且缺乏相关经验，存在一定风险 思考:大数据是否应该属于监控系统的一部分? 3.3 趣店当前监控架构 基于现有业务监控开发，利用已有资源 利用队列将系统拆分成不同模块，方便升级 利用现有的优秀开源软件 四、监控模块设计与优化 各个模块可以随时被更优的方案替换 4.1 采样模块 采集源： SQL、API、ElasticSea ch (实时日志收集)、其他更多 运行方式： crontab定时运行

今天对Kuma来说是个大日子！Kuma 1.0现在已经具备了70多个特性和改进，可以在生产环境中使用和部署，为运行在多个集群、云（包括Kubernetes和基于VM的工作负载）上的每个应用程序创建现代分布式服务网格。 在我们了解这个版本之前，非常感谢社区和用户，感谢他们的贡献和反馈。 不要忘记关注 GitHub 上的Kuma，并在 社区slack 询问任何问题。 https://github.com/kumahq/kuma https://kuma.io/community/ Kuma 1.0为Grafana提供了65个以上的图表，尽管你也可以通过TrafficLog和TrafficMetrics策略从任何其他系统收集数据。 这个新版本在以下方面提供了显著的新特性和改进： 多域🌎 简化多区域部署，自动生成“区域（Zone）”资源。 本地感知负载平衡，减少多区域延迟和降低出口成本。 通过新的“Ingress”DP类型自动同步Ingress数据平面代理到全球CP。 服务和政策🚀 增加了对显式外部服务的支持。 增加了对一个新的“服务（Service）”资源的支持，该资源对每个“kuma.io/service”的多个数据平面代理进行分组。 增加了对Kafka协议的支持。 “网格（Mesh）”资源中的可配置直通控制能力。 性能📊 在任务关键的SLA执行的企业环境中进行战斗测试。

Chaos Mesh 是一个云原生的混沌测试平台，在去年的最后一天，我们开源了这个项目，以帮助大家更好的进行混沌实验。从开源到现在近一年的时间里，Chaos Mesh 在所有贡献者的共同努力下，在不断完善新功能的同时，也在易用性和稳定性上取得了阶段性的成果。 今天，我们自豪的宣布 Chaos Mesh 1.0 正式发布！ Chaos Mesh 1.0 是一个里程碑，不仅支持更多混沌注入的类型，提高了框架组件的稳定性，并且增加了 Chaos Dashboard 组件用来改善 Chaos Mesh 的易用性。下面请跟随我们的脚步梳理 Chaos Mesh 1.0 有什么样的惊喜。 核心亮点 1. 丰富易用的混沌实验类型 混沌实验的核心是注入故障，Chaos Mesh 从分布式系统的出发，充分考虑分布式系统可能出现的故障，提供更加全面、细粒度的故障类型，能全方位的帮用户对网络、磁盘、文件系统、操作系统等进行故障注入。同时，使用 Chaos Mesh，不需要应用做任何修改，做到真正的被测试系统无感知。Chaos Mesh 目前支持的故障注入有： pod-kill：模拟 Kubernetes Pod 被 kill。 pod-failure：模拟 Kubernetes Pod 持续不可用，可以用来模拟节点宕机不可用场景。 container-kill：模拟 Container 被 kill。

不久前我们开源了基于 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有自带的配置功能，提供用户根据Lucene查询语法搭配使用，可以做到动态查询，废话不多说，上菜 首先，看板数据已经准备好，如下，统计仓库中的issue信息，我们要做的是根据关键字进行模糊查询 第一步： 先配置查询的参数，查询方式为term,根据特定字段这边是gitee_repo这个是和编辑面板中模糊匹配的名称一致（{"find":"term","field":"gitee_repo"}），如下图 第二步：gitee_repo:http*$gitee_repo*， Lucene支持在Term中使用通配符来支持模糊查询，其中*匹配多个字符，？匹配单个字符，具体情况大家可以随意发挥， 第三步，已经配置完成，检查一下效果，搜索关键词mep,结果如下图： 至此，任务完成，其中用到的查询方式为term,为什么要用term呢，因为我们查询仓库的信息是单个关键词，同时呢，我们又不能把整个仓库的链接全打上，因此，这边选择term查询，顺便普及一下通用的几种查询的区别，方便大家对号使用 term: 在倒排索引中查找确定的词组，它不会分词，通常适用于 keyword、 numeric、date 等类型的值 term：查询某个文档含有多个关键词 mathc：对查询的字符串会进行分词，类如　"hello babay"，

前提条件 正确安装配置Kubernetes集群 CentOS Linux release 7.5.1804 安装 下载istio 1.1版本 [root@vm157 ~]# wget https://github.com/istio/istio/releases/download/1.1.1/istio-1.1.1-linux.tar.gz …… 2019-03-26 09:39:06 (483 KB/s) - ‘istio-1.1.1-linux.tar.gz’ saved [15736205/15736205] Istio安装有多种方式，本文根据helm template生成istio部署的配置文件，其他部署方式请参考官方文档。 [root@vm157 ~]# cd istio-1.1.1/ [root@ruffy istio-1.1.1]# helm template ../install/kubernetes/helm/istio-init --name istio-init --namespace istio-system > istio-init.yaml [root@ruffy istio-1.1.1]# kubectl get crds | grep 'istio.io\|certmanager.k8s.io' | wc -l [root@ruffy istio-1

近几天Istio1.1的发布引起了技术界巨大的反响，为了让更多技术爱好者能够亲自体验Istio1.1，公司的技术大佬赶出了这篇尝鲜教程，其中包括环境、安装、可能遇到的问题及解决方式等，希望对大家有所帮助。 环境 已经安装了 Kubernetes 集群，有1个 master 和4个 node。操作系统都是 CentOS Linux 7。 下载 Istio 安装文件 curl -L https: // git.io/getLatestIstio | ISTIO_VERSION=1.1.0 sh - export PATH = " $PATH:/root/istio-1.1.0/bin " 安装 Tiller 这里选择在 Helm 和 Tiller 的环境中使用 helm install 命令进行安装的方式。 kubectl apply -f install/kubernetes/helm/helm-service-account.yaml 　假如已经安装过，结果如下： helm init --service-account tiller 安装 istio-init chart 更新 Helm 的本地包缓存： helm repo add istio.io "https://gcsweb.istio.io/gcs/istio-prerelease/daily-build/release-1