监控目标
每个人由于所在的行业、公司、业务、岗位不同，对监控的理解也不尽相同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。
- 对系统不间断的实时监控：实际上是对系统不间断的实时监控；
- 实时反馈系统当前状态：我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障。
- 保证服务可靠性安全性：我们监控的目的就是要保证系统、服务、业务正常运行
- 保证业务持续稳定运行：如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。
监控方法
1.了解监控对象：我们要监控的对象你是否了解呢？比如CPU到底是如何工作的？
2.性能基准指标：我们要监控这个东西的什么属性？比如CPU的使用率、负载、用户态、内核态、上下文切换。
3.报警阈值定义：怎么样才算是故障，要报警呢？比如CPU的负载到底多少算高，用户态、内核态分别跑多少算高？
4.故障处理流程：收到了故障报警，我们怎么处理呢？有什么更高效的处理流程吗？
监控核心
- 发现问题：当系统发生故障报警，我们会收到故障报警的信息。
- 定位问题：故障邮件一般都会写某某主机故障、具体故障的内容，我们需要对报警内容进行分析。比如一台服务器连不上，我们就需要考虑是网络问题、还是负载太高导致长时间无法连接，又或者某开发触发了防火墙禁止的相关策略等，我们就需要去分析故障具体原因。
- 解决问题：当然我们了解到故障的原因后，就需要通过故障解决的优先级去解决该故障。
- 总结问题：当我们解决完重大故障后，需要对故障原因以及防范进行总结归纳，避免以后重复出现。
监控工具
自研
监控流程
- 数据采集：
- 数据存储：
- 数据分析：当我们事后需要复盘分析故障时，Zabbix能给我们提供图形以及时间等相关信息，方面我们确定故障所在；
- 数据展示：Web界面展示、(移动APP、java_php开发一个Web界面也可以)；
- 监控报警：电话报警、邮件报警、微信报警、短信报警、报警升级机制等（无论什么报警都可以）；
- 报警处理：当接收到报警，我们需要根据故障的级别进行处理，比如:重要紧急、重要不紧急，等。根据故障的级别，配合相关的人员进行快速处理。
监控指标
硬件监控
系统监控
CPU有几个重要的概念：上下文切换、运行队列和使用率。这也是我们CPU监控的几个重点指标。
通常情况，每个处理器的运行队列不要高于3，CPU 利用率中用“户态/内核态”比例维持在70/30，空闲状态维持在50%，上下文切换要根据系统繁忙程度来综合考量。
针对CPU常用的工具有：htop、top、vmstat、mpstat、dstat、glances
内存：通常我们需要监控内存的使用率、SWAP使用率、同时可以通过Zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。
针对内存常用的工具有：free、top、vmstat、glances。
IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外，日常监控只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度，网络也是监控网卡流量即可。常用工具有：iostat、iotop、df、iftop、sar、glances。
应用监控
**
把硬件监控和系统监控研究明白后，我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务，都需要监控起来。
应用服务监控也是监控体系中比较重要的内容，例如：
LVS、HAProxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、RabbitMQ等，相关的服务都需要监控起来。
网络监控
流量分析
日志监控
**通常情况下，随着系统的运行，操作系统会产生系统日志，应用程序会产生应用程序的访问日志、错误日志，运行日志，网络日志，我们可以使用ELK来进行日志监控。
对于日志监控来说，最见的需求就是收集、存储、查询、展示，开源社区正好有相对应的开源项目：Logstash（收集）+ElasticSearch（存储+搜索）+Kibana（展示）。
我们将这三个组合起来的技术称之为ELK Stack，所以说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。
安全监控
API监控
业务监控
监控报警
报警处理
若有收获，就点个赞吧
0 人点赞
