| 监控===监测+控制 |
| 生活中的监控:事故追责 |
| 运维中的监控:事后追责,事前预警,性能分析,实时报警 |
| 监控是整个产品周期中最重要的一环,及时预警减少故障避免影响扩大,根据历史数据可以追溯问题根源,并且分析监控数据,可以找出用户体验优化方案。 |
| |
| 随着用户的增多,服务随时可能会被系统oom(out of memory内存溢出) |
| 后果:kill -9 mysql |
| 如何判断?,web服务是因为用户访问过多,达到了瓶颈? 还是程序代码bug导致的,内存过多? |
| 上线一个新网站:压力测试 2000并发,oom(out of memeory) |
| 按照层次划分可简单分为: |
| 应用层:nginx,mysql,java。。 |
| 运行层:Windows,linux。。 |
| 硬件层:内存,cpu,磁盘,网络。。 |
cpu、内存、磁盘、网络
| 1.top 系统时间 登录用户 负载 进程 cpu 内存 swap 进程详细信息 |
| 2.htop(eple) 系统时间 登录用户 负载 进程 cpu 内存 swap 进程详细信息 支持鼠标 树状 快捷键 |
| 3.uptime 当前系统时间、登录用户、负载 |
| 4.free 监控内存 |
| 5.vmstat 程、虚存、页面交换空间及 CPU |
| 5.iostat 磁盘I/O统计 |
| 6.df 硬盘 -h block -i inode |
| 7.iftop 流量监控工具 |
| 8.nethogs 查看进程占用的网络带宽 |
| 9.iotop 进程占用的硬盘I/O |
没有监控工具的时候,shell脚本+定时任务
| [root@k8s ~] |
| |
| MEM=`free -m|awk 'NR==2{print $NF}'` |
| if [ $MEM -lt 100 ];then |
| echo "web服务器 192.168.15.1 可用内存不足,当前可用内存 |
| $MEM" | mail -s "web服务器内存不足" 212121@qq.com |
| fi |
缺点:效率低,不能实现集中报警,不能分析历史数据
什么时候用shell:我只有一台云主机需要监控,适合shell脚本+定时任务
监控项目 |
监控内容 |
主机 |
内存,磁盘(使用空间/剩余空间),系统启动时间,进程数,负载等 |
网卡 |
ping的响应时间,数据包的收发成功率,网卡的流入&流出量和错误的数据包数量 |
文件 |
大小,文件指纹信息等 |
URL |
指定URL访问过程中的返回码,下载时间及文件大小等 |
应用程序 |
服务状态,端口和内存使用率,cpu使用率,请求数量,并发访问请求等 |
数据库 |
指定数据库中的表空间,数据库的游标数,会话数,事务数等 |
日志 |
错误日志,特定字符串匹配 |
硬件 |
温度,风扇转速,电压,电源,主板控制器,磁盘阵列等 |
| Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包 。自2012年成立以来,许多公司和组织都采用了Prometheus,该项目拥有非常活跃的开发人员和用户社区。现在,它是一个独立的开源项目,并且独立于任何公司进行维护。为了强调这一点并阐明项目的治理结构,Prometheus 在2016年加入了 Cloud Native Computing Foundation,这是继Kubernetes之后的第二个托管项目 |
| |
| Prometheus(由go语言(golang)开发)是一套开源的监控&报警&时间序列数据库的组合。 |
| |
| Prometheus 是一款基于时序数据库的开源监控告警系统,非常适合Kubernetes集群的监控。Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态,任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统,比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用,比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。 |
| |
| prometheus和K8S一样属于CNCF |
| 官网地址:https://prometheus.io/ |
| github地址:https://github.com/prometheus |
| Retrieval |
| 获取监控数据 |
| |
| TSDB: |
| 时间序列数据库(Time Series Database),我们可以简单的理解为一个优化后用来处理时间序列数据的软件,并且数据中的数组是由时间进行索引的。具备以下特点: |
| 大部分时间都是顺序写入操作,很少涉及修改数据 |
| 删除操作都是删除一段时间的数据,而不涉及到删除无规律数据 |
| 读操作一般都是升序或者降序 |
| |
| HTTP Server |
| 为告警和出图提供查询接口 |
| Exporters: |
| Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据,并将其转化为Prometheus支持的格式。与传统的数据采集组件不同的是,它并不向中央服务器发送数据,而是等待中央服务器主动前来抓取 |
| 用于暴露已有的第三方服务的 metrics 给 Prometheus。 |
| |
| Pushgateway |
| 用于网络不可直达或者生命周期比较短的数据采集job,居于exporter与server端的中转站,将多个节点数据汇总到Push Gateway,再统一推送到server。 |
| Kubernetes_sd |
| 支持从Kubernetes中自动发现服务和采集信息。而Zabbix监控项原型就不适合Kubernets,因为随着Pod的重启或者升级,Pod的名称是会随机变化的。 |
| |
| file_sd |
| 通过配置文件来实现服务的自动发现 |
| 从 Prometheus server 端接收到 alerts(告警) 后,会进行去除重复数据,分组,并路由到对收的接受方式,发出报警。常见的接收方式有:电子邮件,pagerduty,OpsGenie, webhook 等。 |
| 通过ProQL语句查询指标信息,并在页面展示。虽然Prometheus自带UI界面,但是大部分都是使用Grafana出图。另外第三方也可以通过 API 接口来获取监控指标。 |
| 1、Prometheus server 定期从配置好的 jobs 或者 exporters(出口) 中拉metrics(指标),或者接收来自 Pushgateway 发过来的 metrics(指标),或者从其他的 Prometheus server 中拉 metrics(指标)。 |
| 2、默认使用的拉取方式是pull,也可以使用pushgateway提供的push方式获取各个监控节点的数据。 |
| 3、将获取到的数据存入TSDB,一款时序型数据库。 |
| 4、此时prometheus已经获取到了监控数据,可以使用内置的PromQL进行查询。 |
| 5、它的报警功能使用Alertmanager提供,Alertmanager是prometheus的告警管理和发送报警的一个组件。 |
| 6、prometheus原生的图标功能过于简单,可将prometheus数据接入grafana,由grafana进行统一管理。 |
| 1、非常少的外部依赖,安装使用超简单 |
| 2、已经有非常多的系统集成 例如:docker HAProxy Nginx JMX等等 |
| 3、服务自动化发现 |
| 4、直接集成到代码 |
| 5、设计思想是按照分布式、微服务架构来实现的 |
| 1、一个多维数据模型,其中包含通过度量标准名称和键/值对标识的时间序列数据 |
| |
| 2、PromQL,一种灵活的查询语言 ,可利用此维度 |
| |
| 3、不依赖分布式存储;单服务器节点是自治的 |
| |
| 4、时间序列收集通过HTTP上的拉模型进行 |
| |
| 5、通过中间网关支持推送时间序列 |
| |
| 6、通过服务发现或静态配置发现目标 |
| |
| 7、多种图形和仪表板支持模式 |
| 1、Prometheus 是基于 Metric 的监控,不适用于日志(Logs)、事件(Event)、调用链(Tracing)。 |
| |
| 2、Prometheus 默认是 Pull 模型,合理规划你的网络,尽量不要转发。 |
| |
| 3、对于集群化和水平扩展,官方和社区都没有银弹,需要合理选择 Federate、Cortex、Thanos 等方案。 |
| |
| 4、监控系统一般情况下可用性大于一致性,容忍部分副本数据丢失,保证查询请求成功。这个后面说 Thanos 去重的时候会提到。 |
| |
| 5、Prometheus 不一定保证数据准确,这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断,产生一些反直觉的结果,这个后面会详细展开。二来查询范围过长要做降采样,势必会造成数据精度丢失,不过这是时序数据的特点,也是不同于日志系统的地方。 |