| 监控===监测+控制 |
| 生活中的监控：事故追责 |
| 运维中的监控：事后追责，事前预警，性能分析，实时报警 |
| |
| 随着用户的增多，服务随时可能会被系统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 ~]# cat mem_alter.sh |
| #!/bin/bash |
| MEM=`free -m|awk 'NR==2{print $NF}'` |
| if [ $MEM -lt 100 ];then |
| echo "web服务器 192.168.2.104 可用内存不足,当前可用内存 |
| $MEM" | mail -s "web服务器内存不足" 29262626@qq.com |
| fi |
缺点：效率低，不能实现集中报警，不能分析历史数据
什么时候用shell：我只有一台云主机需要监控，适合shell脚本+定时任务
| 一个监控系统的组成大体可以分为两个部分： |
| 数据采集部分（agent；客户端） |
| 数据存储分析告警展示部分（server；服务端） |
| 按照支持的协议方式，监控系统数据采集可以分为两种： |
| 专用客户端采集（私有协议） |
| 公用协议采集（SNMP,IPMI,SSH等） |
| 监控系统的数据采集模式，一般可分为两种模式： |
| 被动模式：以不变应万变（从服务端到客户端的数据采集） |
| 主动模式：客户端主动上报数据到服务端。 |
| |
| 通常来讲大多数监控系统都应该能够同时支持着两种模式。 |
| 一般来讲，被动模式对于server服务器资源开销较大，适合小规模监控环境。 |
| 主动模式对于server服务器资源开销较小，合适大规模监控环境 |
| 监控项目 |
监控内容 |
| 主机 |
内存，磁盘（使用空间/剩余空间），系统启动时间，进程数，负载等 |
| 网卡 |
ping的响应时间，数据包的收发成功率，网卡的流入&流出量和错误的数据包数量 |
| 文件 |
大小，文件指纹信息等 |
| URL |
指定URL访问过程中的返回码，下载时间及文件大小等 |
| 应用程序 |
服务状态，端口和内存使用率，cpu使用率，请求数量，并发访问请求等 |
| 数据库 |
指定数据库中的表空间，数据库的游标数，会话数，事务数等 |
| 日志 |
错误日志，特定字符串匹配 |
| 硬件 |
温度，风扇转速，电压，电源，主板控制器，磁盘阵列等 |
| 在agent采集数据后，会将数据上传到server服务器，server服务器程序会将接收到的数据进行存储。 |
| 存储的目的就是为了追溯问题（故障）根源。 |
| 一般来讲，监控系统进行数据存储采用以下几种方式： |
| |
| 本地存储。使用本地磁盘，基于文件的方式存储。 |
| 使用数据库管理系统进行数据存储。 |
| 使用NoSQL数据库进行数据存储。 |
| |
| 使用时序数据库进行数据存储。 |
| 使用列存储数据库进行数据存储。 |
| 使用全文搜索引擎数据库进行数据存储。 |
| 监控系统的重要功能（告警功能）是根据我们认为设定的阈值进行告警的。 |
| 监控cpu温度--->阈值=90℃--->告警 |
| 指的是，监控系统本身具有良好的扩展性，包括监控方式的扩展，监控能力的扩展，监控数据存储的扩展，分布式支持等。 |
与同类产品作比较，选择zabbix的原因有一下几点：
| 1.zabbix是一个自由开放源码的产品 |
| 2.安装和配置简单 |
| 3.搭建环境简单 |
| 4.可以将采集到的的数据持久化的存储到数据库中 |
| 5.具有很强的扩展性 |
| 6.采用开源社区的运行模式 |
| 7.zabbix的授权公司提供完整的商业服务支持 |
| 1.数据采集 |
| 2.灵活的触发器 |
| 3.高度可定制的告警 |
| 4.实时绘图功能 |
| 5.web监控功能 |
| zabbix可以模拟浏览器请求访问一个指定站点，并检查返回值和响应时间 |
| 6.多种可视化展示 |
| 7.历史数据储存 |
| 8.配置非常容易 |
| 9.使用模块 |
| 10.网络发现 |
| 11.快速访问接口 |
| 12.api功能 |
| 13.系统权限 |
| 14.大型环境支持 |
zabbix有几个主要的软件组件构成，这些组件的功能如下。
| 所有配置信息和Zabbix收集到的数据都被存储在数据库中。 |
| 1.为了从任何地方和任何平台都可以轻松的访问Zabbix, 我们提供基于Web的Zabbix界面。该界面是Zabbix Server的一部分，通常(但不一定)跟Zabbix Server运行在同一台物理机器上。 |
| |
| 2.如果使用SQLite,Zabbix Web界面必须要跟Zabbix Server运行在同一台物理机器上。 |
| Zabbix proxy 可以替Zabbix Server收集性能和可用性数据。Proxy代理服务器是Zabbix软件可选择部署的一部分；当然，Proxy代理服务器可以帮助单台Zabbix Server分担负载压力。 |
| Zabbix agents监控代理 部署在监控目标上，能够主动监控本地资源和应用程序，并将收集到的数据报告给ZabbixServer |
| 此外，了解Zabbix内部的数据流同样很重要。监控方面，为了创建一个监控项(item)用于采集数据，必须先创建一个主机（host）。告警方面，在监控项里创建触发器（trigger），通过触发器（trigger）来触发告警动作（action）。 |
| 因此，如果想收到Server XCPU负载过高的告警，必须完成以下几个动作: |
| |
| 1.为Server X创建一个host并关联一个用于对CPU进行监控的监控项（Item）。 |
| |
| 2.创建一个Trigger，设置成当CPU负载过高时会触发 |
| 3.Trigger被触发，发送告警邮件 |
| |
| 虽然看起来有很多步骤，但是使用模板的话操作起来其实很简单，Zabbix这样的设计使得配置机制非常灵活易用。 |
| - 主机的逻辑组；它包含主机和模板。一个主机组里的主机和模板之间并没有任何直接的关联。通常在给不同用户组的主机分配权限时候使用主机组。 |
| - 一个被用于定义问题阈值和“评估”监控项接收到的数据的逻辑表达式当接收到的数据高于阈值时，触发器从“OK”变成“Problem”状态。当接收到的数据低于阈值时，触发器保留/返回一个“OK”的状态。 |
| 单次发生的需要注意的事情，例如触发器状态改变或发现有监控代理自动注册 |
| - 一个对事件做出反应的预定义的操作。 |
| 一个动作由操作(例如发出通知)和条件(当时操作正在发生)组 |
| - 一个在动作内执行操作的自定义场景; 发送通知/执行远程命令的序列 |
| - 利用已选择的媒体途径把跟事件相关的信息发送给用户 |
| - 一个预定义好的，满足一些条件的情况下，可以在被监控主机上自动执行的命令 |
| - 一组可以被应用到一个或多个主机上的实体（监控项，触发器，图形，聚合图形，应用，LLD，Web场景）的集合模版的任务就是加快对主机监控任务的实施；也可以使监控任务的批量修改更简单。模版是直接关联到每台单独的主机上。 |
| - Zabbix API允许你使用JSON RPC协议来创建、更新和获取Zabbix对象（如主机、监控项、图形和其他）信息或者执行任何其他的自定义的任务 |
| - Zabbix软件实现监控的核心程序，主要功能是与Zabbix proxies和Agents进行交互、触发器计算、发送告警通知；并将数据集中保存等 |
| - 一个部署在监控对象上的，能够主动监控本地资源和应用的程序 |
| - 一个帮助Zabbix Server收集数据，分担Zabbix Server的负载的程序 |
