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

为什么说 Prometheus 是足以取代 Zabbix 的监控神器？ Kuberneteschina 致力于提供最权威的 Kubernetes 技术、案例与Meetup！ ​关注他 12 人赞同了该文章 作者：陈晓宇 来源： dbaplus 社群 校对： Bot （才云）、 星空下的文仔 （才云） Kubernetes 自从 2012年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊。Kubernetes 是 Google Borg 系统的开源实现，于此对应，Prometheus 则是 Google BorgMon 的开源实现。 Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库。从字面上理解，Prometheus 由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。 2016 年，由 Google 发起的 Linux 基金会旗下的云原生计算基金会（CNCF）将 Prometheus 纳入作为其第二大开源项目。Prometheus 在开源社区也十分活跃，在 GitHub 上拥有两万多 Star，并且系统每隔一两周就会有一个小版本的更新。 各种监控工具对比 其实，在 Prometheus 之前，市面已经出现了很多的监控系统，如 Zabbix、Open-Falcon、Nagios 等。那么 Prometheus

[toc] 本文参考： 《Prometheus官方文档》 ，或网盘下载 《Prometheus操作指南.pdf》 (提取码：1l8m) 一、Prometheus安装部署 1. 简介 Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从 2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。 2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布 了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且 超过120+项的第三方集成。 监控的目的 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间 增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过 监控能够方便的对系统进行跟踪和比较。 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员

cpu利用率 　　方法一： 100 - (avg(increase(node_cpu_seconds_total{mode= " idle " }[1m])) by (instance) / 60 ) * 100 　　方法二： 100 - avg(rate(node_cpu_seconds_total{mode= " idle " }[1m])) by (instance) * 100 　　方法三： 100 - avg(irate(node_cpu_seconds_total{mode= " idle " }[1m])) by (instance) * 100 计算cpu是通过/proc/stat中第四列的idle的cpu时间片计算的 root@Prometheus:~# cat /proc/stat cpu 148499 3877 89516 481390579 39919 0 1641 1151 0 0 cpu0 42643 1845 26582 120310710 36391 0 447 215 0 0 cpu1 31605 729 18455 120360192 757 0 426 200 0 0 cpu2 43326 353 26240 120349498 1838 0 371 434 0 0 cpu3 30924 948 18237 120370177 931 0

Q：我现在需要监控几十个模块的http请求状态码，用web场景好呢，还是在自定义监控用curl好？用web场景的话是不是资源消耗很大，因为我的zabbix-server是部署在aws上的docker里面的 A：消耗资源大小，和你采集状态码的次数有关，如果你一分钟采集频繁采集，资源消耗肯定大的 Q：这样呀，那我暂时用web场景去做吧，谢谢啦，采集频率间隔大概多久比较好，我现在是30秒 A：这个要按实际情况来设置，如果是一些应用到业务环境的页面，设置采集间隔短一点比较好，如果是一些你们内部使用的页面，那么采集间隔长一点比较好 Q：好哒，非常感谢 Q：进入这个界面怎么退出啊， 哪个组合键都不管用呢？ A：按esc键 Q：按了，不管用哦 A：先按esc，然后按q Q：按了，都是不管用，记得有几次是修改 CON 配置文件的时候是可以用，后来都不管用了呢？我现在用 屏幕键盘操作的，咋也是不管用啊 A： Q：就是根据这个 来的，就是不管用 所以才问啦 Q：刚才又试了一下，：W，然后：Q shift+enter，就可以了 创建这个源，然后执行 dbf -y install mariadb-server mariadb-client， 提示如截图 A：你不是在装zabbix吗？为什么又是mongodb? Q：zabbix的数据库用mongodb，对，就是用你的 方法 直接安装 mariadb 数据啊

前言 阿里云监控为云上用户提供常用云产品的监控数据和用户自定义上报的监控数据。在可视化展示层面，除了在云监控控制台查看监控图表外，您还可以将云监控的数据添加到Grafana中展示。 阿里云SLB监控展示 <!-- more --> Grafana 部署 aliyun-cms-grafana 插件 1、本文略过 Grafana 部署 2、安装 aliyun-cms-grafana 插件 假如 Grafana 插件安装目录为 /var/lib/grafana/plugins/ 执行以下命令安装插件 $ cd /var/lib/grafana/plugins/ $ git clone https://github.com/aliyun/aliyun-cms-grafana.git 3、重启 Grafana 服务 # CentOS6 rpm 安装可以使用下面方式重启 $ service grafana-server restart # CentOS7 rpm 安装可以使用下面方式重启 $ systemctl restart grafana-server # k8s 部署 Grafana 可以直接删除 Grafana Pod，k8s会自动在创建一个新的 Pod 注意：此插件版本目前不支持对监控数据设置报警。 Grafana 中配置 aliyun-cms-grafana 数据源 1、登录

Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警 前言 这次主要分享通过Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警方案。通过执行耗时，定位哪些接口拖累了服务的性能；通过请求频次，设置适当的限流和熔断机制，拦截非法或不合理的请求，保障服务的可用性。 InfluxDB 官网： https://www.influxdata.com/ 按照官方的说法，InfluxDB是一个开源分布式时序、事件和指标数据库。使用 Go 语言编写，无需外部依赖。其设计目标是实现分布式和水平伸缩扩展。 下载地址： https://portal.influxdata.com/downloads ，解压后的目录如下 打开配置文件，设置数据存储路径 [data] # The directory where the TSM storage engine stores TSM files. #dir = "/var/lib/influxdb/data" dir = "C:/Users/001wa/Desktop/software/influxdb-1.2.2-1/data" # The directory where the TSM storage engine stores WAL files. #wal

Prometheus Prometheus介绍 Prometheus新一代开源监控解决方案。 github地址 Prometheus主要功能 多维 数据模型 （时序由 metric 名字和 k/v 的 labels 构成）。 灵活的查询语句（ PromQL ）。 无依赖存储，支持 local 和 remote 不同模型。 采用 http 协议，使用 pull 模式，拉取数据，简单易懂。 监控目标，可以采用服务发现或静态配置的方式。 支持多种统计数据模型，图形化友好。 Prometheus核心组件 Prometheus Server ， 主要用于抓取数据和存储时序数据，另外还提供查询和 Alert Rule 配置管理。 client libraries ，用于对接 Prometheus Server, 可以查询和上报数据。 push gateway ，用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。 各种汇报数据的 exporters ，例如汇报机器数据的 node_exporter, 汇报 MongoDB 信息的 MongoDB exporter 等等。 用于告警通知管理的 alertmanager 。 Prometheus安装 二进制安装 cd /opt wget https://github.com/prometheus/prometheus/releases

花了两天部署了一套监控服务 prometheus+node-exporter+grafana，公司的gitlab服务器准备部署node-exporter的时候突然发现gitlab已经有了这些服务， 也懒得去研究gitlab为啥要这些服务，既然gitlab服务器已经包含了node-exporter服务，我直接使用不就得了。 1.首先浏览器测试下接口并不能使用：http://ip:9100/metrics； 2.既然浏览器不能使用，那去gitlab服务器测试下：curl 127.0.0.1:9100/metrics -s | head 　　 　　发现 node-exporter 服务正常 3.node-exporter服务正常，那基本是网络问题了，继续排除下： 　　netstat -anp | grep node 　　ps -ef | grep node 　　 　　发现 node-exporter 监听的是 localhost:9100 导致只能本地访问（红框是我改后的），那就修改监听地址吧 4.查看下监听地址是在哪里修改的，在gitlab目录下 ：grep :9100 * -r 　　 　　发现好多地方有这个值（0.0.0.0:9100这个是已经修改后的，修改前看到的是localhost:9100)，经过简单的排除再尝试，确认可以直接在缺省配置文件里面配置 ： embedded

Prometheus简介 什么是 Prometheus Prometheus是一个开源监控报警系统和时序列数据库 主要功能 多维数据模型（时序由 metric 名字和 k/v 的 labels 构成） 灵活的查询语句（PromQL） 无依赖存储，支持 local 和 remote 不同模型 采用 http 协议，使用 pull 模式，拉取数据，简单易懂 监控目标，可以采用服务发现或静态配置的方式 支持多种DashBoard，图形化友好 核心组件 Prometheus Server， 主要用于抓取数据和存储时序数据，另外还提供查询和 Alert Rule 配置管理。 client libraries，用于对接 Prometheus Server, 可以查询和上报数据。 push gateway ，用于批量，短期的监控数据的汇总节点，主要用于业务数据汇报等。 各种汇报数据的 exporters ，例如汇报机器数据的 node_exporter, 汇报 MongoDB 信息的 MongoDB exporter 等等。 用于告警通知管理的 alertmanager 。 基础架构 主要模块包含： Server, Exporters, Pushgateway, PromQL, Alertmanager, WebUI 等。 Prometheus Server：主要是负责存储、抓取、聚合、查询方面