InfluxDB

GPE监控预警系统（Grafana+Prometheus+Exporter） GPE监控预警系统结构图 一： Grafana 1：简介 大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具、目前已经支持绝大部分常用的时序数据库。 Grafana支持许多不同的数据源。每个数据源都有一个特定的查询编辑器,该编辑器定制的特性和功能是公开的特定数据来源。 官方支持以下数据源:Graphite，Elasticsearch，InfluxDB，Prometheus，Cloudwatch，MySQL和OpenTSDB等 2：安装 ==linux下安装== Step1：下载 wget https://dl.grafana.com/oss/release/grafana-6.5.1-1.x86_64.rpm sudo yum localinstall grafana-6.5.1-1.x86_64.rpm Step2：启动 sudo service grafana-server start Step3：访问 安装成功后浏览器输入 localhost:3000 可以访问grafana主页,grafana默认端口3000、默认用户名和密码为admin/admin Step1：下载 wget https://s3-us-west-2.amazonaws.com/grafana

题记 今年是我个人从事软件测试工作的第六个年头，职业生涯至今经历了功能-接口-自动化-性能测试岗位的变迁。 18年下半年开始以团队owner的角色进行工作开展，不过当时团队技术体系建设已经步入正轨，对我个人而言，并没有太多沉淀。 19年跳槽后，有幸从零开始主导我司的性能测试体系建设工作，个人之前的很多想法得以落地实现。 这也许是除了薪资之外，对我个人而言获得的最大成就感。。。 导图 演进 基础建设 1、文档建设 前段时间知乎回答了一个问题： 做技术人是不是都反感写文字类的东西，比如需求文档，需求分析等等？ 之前的博客也写过类似的内容： 性能测试从零开始实施指南——文档建设篇 。 我个人认为无论是作为个人学习笔记抑或一个Team的累积沉淀，文档建设的工作必不可少，而且是重中之重。原因如下： 1） 降低“口头说明”带来的风险； 2）文档是很重要的记录和交流介质； 3） 便于事前、事中、事后快速回溯追踪； 4） 降低工作交接、沟通的成本，提高效率； 5）文档是一次梳理思路，review的方式； 6）文档是很重要的工作产出，自我价值诉求的重要手段（KPI）； 当然，现在有很多在线协同文档工具，如confluence、语雀（参考- 工具汇总 ）。我司性能团队文档类目如下： 2、资源管理 这里的资源主要指压测资源，包含如下几项： 1）压测机 2）压测场景 3）压测脚本 4）压测数据

背景 在上篇文章中，我们曾介绍过饿了么的 全链路压测的探索与实践 ，重点是业务模型的梳理与数据模型的构建，在形成脚本之后需要人工触发执行并分析数据和排查问题，整个过程实践下来主要还存在以下问题： 测试成本较高，几乎每个环节都需要人力支撑，费时费力。 由于测试用例较多，涉及的测试机范围较广，手工执行容易犯错，线上测试尤其危险。 记录结果和测试报告极不方便，需要二次加工、填写和上传。 测试过程中靠手工监控，覆盖不全且定位问题困难。 基于这些因素，我们决定推进全链路压测的自动化进程。这篇我们主要介绍全链路压测平台的实践。 目标 为了解决以上核心痛点，平台至少需要保证以下方面的功能： 用例管理：用户建立测试用例，上传资源文件，系统进行分类管理。 压测执行：一键触发已有测试用例，可指定线程数、预热时间、测试周期和测试机等，可以自动切分数据，分布式执行。 实时结果(热数据)：响应时间、吞吐量、错误率等数据以图表形式实时显示。 测试结果(冷数据)：平均响应时间、平均吞吐量，90/95/99线等数据以图表形式在测试结束后显示。 测试机集群监控：监控测试集群的使用状态，提示用户可用的测试机。 安全保障：平台应该对用户操作进行适当限制，并能自我应对一些异常情况。 主要功能与实现概要 压测平台是典型的B/S类型Java Web项目，基于Spring Boot开发，前端使用AngularJS

掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、AR/VR/MR以及现今最火的5G，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门1对1新的机遇。随着业务规模进一步扩大，流量进一步暴增，微服务体系下，业务服务新增和迭代频率大大加快，运维和业务人员经常需要熬夜人工上线，疲劳状态下容易产生生产事故，运维成本和业务成本也将大大上升。在此背景下，基础架构部推出可以白天安全上线，流量无损的微服务灰度蓝绿发布智能化系统，并通过强有力的各种监控手段来保证流量的精确制导和调拨，提升技术驱动能力。 关于Solar Solar作为掌门1对1下一代基础微服务体系，2019年11月开始筹划，2020年1月4日推出第一版，2020年4月15日发布1.2.0 & 2.2.0里程碑稳定版，兼容Spring Cloud Edgware版、Finchley版、Greenwich版、Hoxton版本。基于三层体系而构建： 基础公共组件。Solar的基础组件，基础公共组件一般呈原子层面的独立存在，组件间也可适当耦合，基本上可达到一个组件被移除，不影响另外一个组件的运行的特征。 基础公共框架。Solar的基础框架，依托Spring Cloud服务体系，以框架形式对外暴露

上篇文章中，已经完成了基于kubeadm安装的kubernetes集群，本文将基于上述的集群环境，搭建dashboard组件。 安装环境及版本 kubernetes版本及基础组件版本可参考前一篇安装集群环境的文章 dashboard组件：kubernetes-dashboard-v1.10.1 需准备的镜像： k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1 k8s.gcr.io/heapster-amd64:v1.5.4 k8s.gcr.io/heapster-influxdb-amd64:v1.5.2 k8s.gcr.io/heapster-grafana-amd64:v5.0.4 #!/bin/ bash DASHDOARD_VERSION =v1. 10.1 HEAPSTER_VERSION =v1. 5.4 GRAFANA_VERSION =v5. 0.4 INFLUXDB_VERSION =v1. 5.2 username =registry.cn-hangzhou.aliyuncs.com/ google_containers images = ( kubernetes -dashboard- amd64:${DASHDOARD_VERSION} heapster -grafana- amd64:${GRAFANA

由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod......等等服务，以达到随时掌握Kubernetes集群的内部状况。 此文章是Prometheus监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任kubernetes集群监控的架构。 k8s监控方案调研 1、cAdvisor + InfluxDB + Grafana 2、Heapster + InfluxDB + Grafana 3、Promethus + kube-state-metrics + Grafana Grafana : 开源DashBoard，后端支持多种数据库，如：Influxdb、Prometheus...，插件也比较多，功能强大。非常适合用于做展示。 InfluxDB : 开源时间序列数据库，性能高效 cAdvisor : 来自 Google 的容器监控工具，也是 Kubelet 内置的容器资源收集工具。它会自动收集本机容器 CPU、内存、网络和文件系统的资源占用情况，并对外提供 cAdvisor 原生的 API。随 kubelet 启动 --cadvisor-port

POD资源： requests:需求，最低保障 limits:限制，硬限制 CPU： 一颗逻辑CPU（一个核心） 1=1000微核，millicores 500m=0.5CPU 内存： E、P、T、G、M、K Ei、Pi、Ti、Gi、Mi、Ki、 Qos： Guranteed：最高优先级， 确保、保证 同时设置了CPU和内存的requests和limits， cpu.limits=cpu. requests memory.limits=memory.limits Burstable：中间优先级， 至少有一个容器设置CPU或者内存资源requests的属性，当内存资源比较紧缺时将requests分配占用较大的停止 cpu.limits>cpu. requests memory.limits>memory.limits BestEffort：最低优先级， 自动配置，当内存资源比较紧缺时，BestEffort会被优先退出，确保其他类型的正常运行 没有任何一个设置 resources: limits: memory: 1024Mi cpu: 2 requests: cpu: 500m memory: 512Mi HeapSter：（新版本被整合在kubernetes内部，kube1.1后废弃） cAdvisor：收集各node节点上面内存，硬盘，cpu的资源，可以在单节点上面查看采集的结果