Linux中实现Zabbix监控及mysqlMHA相关问题解答

Sorrow is hushed into peace in my heart like the evening among the silent trees.

忧思在我的心里平静下去，正如暮色降临在寂静的山林中

---

目录

## 问题一、

### ①一个业务架构中为什么需要监控系统？

### ②其用来解决什么问题？

### ③监控服务器运行情况通过sar/top不是就可以了吗？

## 问题二、

### ① zabbix监控一台8C16G的VM的system.cpu.load时候，指标该如何设置，load到多少应该告警，为什么？

####  设置方法

### ②同时监控两万台8核16GB和16核32GB虚拟机（VM）的system.cpu.load，该如何设置？

### ③监控VM的system.cpu.load出现告警的时候，代表了什么意思，该如何定位并解决问题？

## 问题三、

 ### ①除了zabbix，还有哪些监控方案可以选择？

 ### ②zabbix系统架构中存在着哪些问题？

 ### ③ 如果你是zabbix监控系统的维护者，你该如何解决zabbix存在的一些缺陷问题？

#### 主要优化

#### 次要优化

## 问题四、

 ### mysql数据库为什么需要做主从同步，用来解决什么问题

---

## 问题一、

### ①一个业务架构中为什么需要监控系统？

• 故障发现和恢复

        监控系统可以实时监测系统的运行状态，一旦发现异常情况或故障，可以立即发出警报，并提供详细的故障信息。这有助于开发人员快速定位问题，及时进行修复，从而确保业务的连续性。

• 资源利用和容量规划

        监控系统可以提供关于系统资源利用情况的数据，如CPU使用率、内存占用、磁盘空间等。这些数据可以帮助管理人员了解系统的负载情况，预测未来的资源需求，从而进行合理的容量规划和资源分配。

• 网络流量管理

        随着互联网业务的不断扩张，公司网络的流量也在不断增加。通过监控系统，可以实时监测网络流量的情况，合理分配带宽资源，提高网络的运行效率。同时，监控系统还可以发现网络中存在的异常流量和攻击行为，及时进行防范和处理，保障网络的稳定性和安全性。

• 性能监控和优化

        监控系统可以实时收集和分析应用程序的性能数据，包括响应时间、吞吐量、错误率等。这些数据可以帮助开发人员识别性能瓶颈和问题，并及时进行优化，从而提高系统的稳定性和效率。

• 安全性和合规性

        监控系统可以实时监测系统的安全事件和违规行为，如未经授权的访问、恶意攻击等。这有助于及时发现并应对安全威胁，保护业务数据的安全性和完整性。同时，监控系统还可以帮助组织满足相关的合规性要求，如数据保护法规、审计要求等。

• 业务洞察和决策支持

        通过收集和分析大量的业务数据，监控系统可以提供有关业务运行状况的深度洞察。这些洞察可以帮助管理人员了解业务的运行状态、用户行为、市场趋势等，从而做出更明智的决策。

### ②其用来解决什么问题？

• 实时监控与管理

       通过收集和分析各种业务数据，监控系统可以帮助企业实时了解业务的运行状态。监控系统能够实时监测服务器、应用程序、数据库、网络设备等各种IT资源的状态，并在发现问题时立刻发出告警，如CPU使用过高、内存不足、磁盘空间满载、网络带宽饱和等情况，确保问题能得到及时解决，减少业务中断的风险。

• 故障发现与报警

        监控系统能够实时监测业务运行中的异常和故障及系统各个环节（包括硬件设备、操作系统、中间件、应用程序、数据库、网络等）的运行状态，并通过设定规则和阈值进行预警。一旦发现异常情况，系统可以及时发送告警通知，以便运维团队能够迅速发现和定位问题，采取行动防止故障演变为严重的服务中断，减少故障对业务的影响。

• 性能优化与资源分配

        监控系统收集的性能指标可以帮助分析系统性能瓶颈，比如CPU使用率、内存使用、I/O吞吐量、网络流量等，通过分析这些数据可以优化系统资源配置，提升业务处理效率，确保业务系统在高并发或大流量情况下仍然保持稳定性能。此外，监控系统还可以提供关于资源利用情况的数据，帮助企业预测未来的资源需求，进行合理的容量规划和资源分配。

• 业务决策支持

        对于关键业务流程和SLA（服务水平协议）要求高的系统，监控系统确保能够实时了解业务健康状况，提前预警潜在风险，确保业务连续性不受影响。

• 资源利用率和成本控制

        通过精细的资源监控，企业可以更好地管理和优化IT资源的使用，避免资源浪费，同时确保在需求增加时能够及时调配资源，平衡成本与性能的关系。

• 用户体验监控

        监控系统还可以监控用户访问网站或应用程序的体验，如页面加载速度、API响应时间、用户行为等，帮助提升用户体验，增强用户粘性。

• 合规与审计

        对于需要符合行业法规、内部规定或安全标准的业务，监控系统可以记录和保存必要的系统操作记录和日志，满足审计需求。

• 决策支持与优化

        通过长期的数据积累和分析，监控系统提供的洞察力可用于业务决策支持，比如未来扩容计划、IT投资决策等。

•  全局视角与跨系统协调

        对于分布式、微服务架构等复杂系统，监控系统能够提供全局的视角，跟踪多个服务器、容器或服务之间的交互和依赖关系，确保整个业务链路的健康运行。

### ③监控服务器运行情况通过sar/top不是就可以了吗？

linux中cpu相关指标sar、top、vmstat、mpstat等常见使用方法学习地址：https://blog.51cto.com/u_8065096/9326955

        在业务架构中，虽然命令行工具如 sar 和 top 可以提供实时的服务器性能数据，但仅仅依靠它们并不足以满足复杂的业务监控需求。sar 和 top 主要是用来查看服务器级别的系统活动和进程状态，如CPU、内存、磁盘、网络等资源的使用情况，它们在一定程度上可以帮助识别服务器的局部问题。

        成熟的业务监控系统通常会集成众多工具和组件，实现更全面、智能的监控能力，而不仅仅局限于使用 sar 或 top 这样的基础工具。对于现代企业级业务架构，特别是大型分布式系统、微服务架构、容器化环境等，其需要的是全面、立体、多维度的监控解决方案，其中包括：

• 全栈监控

        不仅监控服务器底层资源，还包括中间件、数据库、应用层、API接口、用户体验等全栈层面的监控。

• 实时告警

        根据预设的阈值进行实时告警，而非仅靠人工定期查看。

• 历史数据存储与分析

        存储长期的历史数据以进行趋势分析、性能瓶颈挖掘、容量规划等。

• 可视化展示

        提供仪表盘、图表等形式，将复杂的数据转化为易于理解和分析的可视化界面。

• 跨系统关联监控

        在微服务或分布式系统中，需要能够追踪跨多个服务器、服务之间的调用关系和性能瓶颈。

• 自动化运维

        与自动化运维工具集成，实现故障自动恢复、资源自动伸缩等功能。

## 问题二、

### ① zabbix监控一台8C16G的VM的system.cpu.load时候，指标该如何设置，load到多少应该告警，为什么？

      load，其全称是Linux system load averages ，即linux系统负载平均值。注意两个关键词：一个是“负载”，它衡量的是task（linux 内核中用于描述一个进程或者线程）对系统的需求（CPU、内存、IO等等），第二个关键词是“平均”，它计算的是一段时间内的平均值，分别为 1、5 和 15 分钟值。system load average由内核负载计算并记录在/proc/loadavg 文件中， 用户态的工具（比如uptime，top等等）读的都是这个文件。

我们一般认为：

• 1、如果load接近0，意味着系统处于空闲状态；

• 2、如果 1min 平均值高于 5min 或 15min 平均值，则负载正在增加；

• 3、如果 1min 平均值低于 5min 或 15min 平均值，则负载正在减少；

• 4、如果它们高于系统 CPU 的数量，那么系统很可能遇到了性能问题（视情况而定）。

计算load核心算法：

        指数加权移动平均法

        a1 = a0 * factor + a * (1 - factor)，其中a0是上一时刻的值，a1是当前时刻的值，factor是一个系数，取值范围是[0,1]，a是当前时刻的某个指标采样值。

        1、指数移动加权平均法，是指各数值的加权系数随时间呈指数式递减，越靠近当前时刻的数值加权系数就越大，更能反映近期变化的趋势；

        2、计算时不需要保存过去所有的数值，这对内核非常重要。

        system.cpu.load表示的是CPU的总体负载平均值，其代表系统总的负载情况，而非单个CPU核心的负载

        Zabbix监控8核16GB虚拟机（VM）的system.cpu.load时，指标设置和告警阈值取决于多个因素，包括但不限于：

• 系统并发处理能力

        如果该系统主要处理高并发任务，且已经做了良好的并发优化，理论上单核CPU的负载在0.7左右（即大约80%的CPU利用率）被认为是健康的，这意味着所有CPU核心都被充分利用但不至于过载。在此情况下，对于8核的VM，总体CPU负载在5.6（=0.7*8）以下可以接受。

        CPU负载的处理规则如下：

        0.70:  需要注意并排查原因 。 如果平均负载保持在> 0.70以上，那么应该在情况变得更糟之前进行调查。

        1.00: 不紧急，需要处理。如果平均负载保持在1.00以上，需要查找问题原因并立即解决。否则，你的服务器可能在任何时候出现性能问题。

        5.00：紧急状态，立即处理。如果平均负载高于5.00，那么你的系统马上就要崩溃了，很有可能系统挂机或者hang死。因此需要立即处理这种情况，千万不要让你的系统负载达到5！

        在多处理器系统上，负载是相对于可用处理器核心数量的。在单核系统上，“ 100％利用率”表示负载为1.00，在双核系统上是2.00，在四核系统上是4.00，依此类推。

        与CPU相同：在单核服务器上1.00的负载表示CPU利用率为100％。在双核服务器上，负载为2.00才代表100％CPU使用率。

        CPU 负载处理规则添加：

        “核数=最大负载”：在多核系统上，您的负载不应超过可用核数。

        “Core就是Core”的经验法则：CPU Core的性能与CPU上的分布方式无关。两个四核等于四个双核等于八个单核。他们的性能与八个Core的性能等同。

        

• 系统类型与业务特点

        如果是数据库服务器、Web服务器、计算密集型应用等，可能需要更低的CPU负载阈值以留出应对突发峰值的缓冲空间；而对于一般的应用服务器，可以适当放宽阈值。

• 业务增长预期

        如果预期业务量会快速增长，设置告警阈值时应留出一定余量，以免短期内就需要频繁调整阈值。

• 系统性能与稳定性要求

       对于关键业务系统，为了避免CPU过载导致的性能下降或服务不稳定，可能需要将告警阈值设置得更为保守，比如总负载达到4.0（即单核50%）就开始告警，以尽早发现并处理潜在问题。 

####  设置方法

• 创建触发器：{Template_VM_CPU_load:system.cpu.load[all,avg5].last()} >= 4.0

        该语句表示：在系统平均CPU负载超过4.0时收到告警。

        "avg5"表示过去5分钟内的平均负载，可以根据实际情况调整时间段。此外，"all"表示监控所有CPU核心的总负载。

### ②同时监控两万台8核16GB和16核32GB虚拟机（VM）的system.cpu.load，该如何设置？

• 模块化管理

        创建或使用现有的适用于Linux操作系统的模板，其中包含对system.cpu.load的监控项定义。

        为8核和16核的VM分别设置不同的CPU负载告警阈值触发器。

• 动态阈值

        可以考虑使用低级别发现（LLD）功能，根据实际CPU核心数动态生成监控项和触发器，例如通过用户宏或预处理脚本动态计算告警阈值。

• 对于8核VM，设置触发器类似 {Template_VM_8C:system.cpu.load[all,avg5].last()} >= 8 * 0.7 表示当5分钟平均CPU负载超过5.6时告警。
• 对于16核VM，设置触发器类似 {Template_VM_16C:system.cpu.load[all,avg5].last()} >= 16 * 0.7 表示当5分钟平均CPU负载超过11.2时告警。

•  主机群组备份

        将两万台虚拟机按照CPU核心数划分为不同的主机群组，将对应的模板应用到各自群组中。

•  批量操作

        使用Zabbix的批量操作功能，一次性将模板应用到所有相关主机上，确保监控覆盖到每台虚拟机。

•  优化告警策略

        为了防止大量的告警淹没真正的关键问题，可结合业务需求和历史数据，设置适当的抑制规则和告警依赖关系，优化告警策略。

•  资源调度与负载均衡

        对于大规模的集群环境，应考虑整体资源调度和负载均衡策略，确保告警阈值既能够反映单个VM的负载情况，又能反映整个集群的健康状态。

•  监控与告警可视化

利用Zabbix仪表板或图形展示，将整体CPU负载情况和告警状态进行可视化呈现，方便运维人员一眼看出集群整体健康状况和热点问题。

• 持续优化与调整 

         随着业务的发展和资源使用情况的变化，应持续收集监控数据，根据实际运行情况调整告警阈值，以确保告警的有效性和准确性。

 ### ③监控VM的system.cpu.load出现告警的时候，代表了什么意思，该如何定位并解决问题？

        出现告警意味着至少有一部分虚拟机的CPU负载超过了预设的安全阈值，反映的问题：

• 资源紧张

        当系统CPU load过高时，说明虚拟机上的进程请求处理器资源的需求超过了当前可用的处理能力，可能导致响应变慢、进程排队等待执行，进而影响整体的服务性能。

• 潜在瓶颈

        可能是由于应用程序过于繁忙、并发任务过多、某个进程或服务耗尽CPU资源，如存在CPU密集型运算、循环逻辑效率低下、数据库查询频繁或其他资源争抢问题。

•  配置不合理

        如果虚拟机分配的CPU核心数与其实际所需资源不匹配，可能会导致CPU资源不足，即使物理硬件资源充足，也可能因为虚拟化层资源配置不当而产生高负载。

•  系统或程序故障

        存在死循环、递归错误、内存泄漏转而消耗大量CPU资源的情况，或者是恶意攻击、病毒木马等安全事件导致CPU使用异常。

 定位并解决问题的方法：

• 1.实时监控

        查看具体的CPU load数值和趋势图，判断是短期突发还是长期偏高，以及是否有周期性规律。

        使用系统工具（如top、htop、vmstat、iostat、sar等）或云服务商提供的监控工具，找出占用CPU资源最多的进程。

• 2. 深入分析

        对占用CPU资源较高的进程进行进一步分析，检查其日志文件，确定是否存在异常行为或错误信息。

• 3. 资源调整

        根据实际情况增加虚拟机的CPU资源配额，或者优化应用配置使其更有效地利用现有资源。调整程序设计，避免不必要的同步和阻塞，优化算法提高执行效率。

• 4. 扩容或迁移

        如果负载无法有效降低，可能需要考虑增加物理服务器资源，或者将部分负载转移到其他机器上实现负载均衡。

• 5. 应急措施

        在排查过程中，如果发现严重影响业务的服务，可以考虑暂时关闭非关键服务，释放CPU资源，确保核心业务稳定运行。

• 6. 预防措施

        建立长期的性能基线，定期审计和优化系统配置，实施资源使用限制和自动伸缩策略，预防未来可能出现的类似问题。

## 问题三、

 ### ①除了zabbix，还有哪些监控方案可以选择？

在Linux中，除了Zabbix之外，还有多种监控方案可以选择。以下是一些常用的监控工具：

• 1. Nagios

        是一款开源的免费网络监视工具，能有效监控Windows、Linux和Unix的状态，以及交换机、路由器等网络设备和打印机等，在系统或服务状态异常时发出邮件或短信报警时间通知运维人员，在状态恢复后发出正常的邮件或短信通知。它提供了丰富的插件和扩展功能，可以自定义监控项和报警方式，同时提供一个可选的基于浏览器的WEB界面以方便系统管理人员查看网络状态，各种系统问题，以及日志等等。

        主要功能：①监视网络服务(SMTP、POP3、HTTP、NNTP、PING等)；②监视主机资源(进程、磁盘等)；③简单的插件设计可以轻松扩展Nagios的监视功能；④服务等监视的并发处理；⑤错误通知功能(通过email、pager或其他用户自定义的方法)。

• 2. SeaLion

        是一个基于云的Linux服务器监控工具，通过统一的仪表盘监控所有服务器指标，它只需几分钟即可完成设置。它具有即时报警功能，可快速接收通知和每日数据摘要等。

• 3. Icinga

        是一个免费的开源监控系统，可以检查服务器资源的可用性，并记录服务器问题，在停机时发送通知。它提供了强大的监控功能和灵活的报警机制。

• 4. Munin

        是一个网络和系统监控工具，可帮助分析服务器资源趋势。它提供了直观的图表和报告，方便用户了解系统的性能和资源使用情况。它旨在成为一个即插即用的解决方案，安装后无需太多额外工作即可收集关键信息。Munin主要功能是有效分析服务器资源优势，属于网络及系统监控的工具。

• 5. Monit

        是一个用于管理和监控Unix系统的开源工具。它可以监控系统的各种资源和服务，并在出现问题时发送报警通知。其可以进行自动维护和维修，如果出现错误情况，Monit可以自动触发保护行为。

• 6. Performance Co-Pilot (PCP)：

        是一个系统性能分析框架，用于收集、存储和分析系统性能数据，可以通过它观察指标走向的趋势，以帮助快速识别异常所在点。它提供了丰富的工具和库，方便用户进行性能监控和分析。它提供API，可依据此来开发自定义的监控和报告解决方案。

• 7. Grafana

        是一个可视化和数据分析平台，可以配合多种数据源如Prometheus、InfluxDB、Elasticsearch等进行监控数据展示和告警。

• 8. Prometheus--常用

        是一款用于系统监控和时间序列数据处理的开源系统，非常适合微服务和云原生环境，它内置了强大的数据模型和查询语言PromQL。

• 9. Cacti

        是一个基于PHP、MySQL、SNMP及RRDTool设计的网络流量监测图形分析工具，通过snmpget来获取数据，使用RRDTool绘画图形，提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结 构、host以及任何一张图，还可以与LDAP结合进行用户验证，同时也能自己增加模板，功能非常强大完善。cacti是用php语言实现的一个软件，它的主要功能是用snmp服务获取数据，然后用RRDtool储存和更新数据，当用户需要查看数据的时候用rrdtool生成图表呈现给用户。因此，snmp和RRDtool是cacti的关键。

• 10. Ganglia

        是一个集群监控软件，可以监视和显示集群中的节点的各种状态信息，比如：CPU、mem、硬盘利用率、I/O负载、网络流量情况等，同时可以将历史数据以曲线方式通过php页面呈现，此软件主要是用来监控系统性能的软件，通过曲线可以很容易见到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能起到重要作用。它是分布式的监控系统，有两个Daemon，是一个Linux下图形化监控系统运行性能的软件，界面美观、丰富，功能强大。

        RRDtool是系统存放和显示time-series (即网络带宽、温度、人数、服务器负载等) 。并且它提出有用的图表由处理数据强制执行有些数据密度。

• 11. Collectd

        是一款轻量级的系统统计数据收集守护进程，支持多种插件以收集不同类型的数据，并能将数据转发给Graphite、InfluxDB等后端存储。

• 12. Telegraf

        是InfluxData公司出品的一款轻量级数据收集代理，支持多种输入插件和输出插件，可将系统和应用程序指标发送到多种数据存储后端。

• 13. Check_MK

        是基于Nagios的一个监控解决方案，增强了Nagios的用户体验，简化了配置和管理。

• 14. Icinga

        是Nagios的一个分支，提供了更现代化的界面和更灵活的扩展机制。

• 15. Netdata

        是一个实时的、分布式的、高性能的Linux系统和应用程序监视工具，提供漂亮的实时仪表盘。

• 16. Zenoss

        是一款智能监控软件，允许IT管理员依靠单一的WEB控制台来监控网络架构的状态和健康度。Zenoss Core同时也是开源的网络与系统管理软件。

Zenoss提供功能丰富的产品，以监测整个IT基础设施：

        网络 -路由器，交换机，防火墙，接入点

        服务器 -微软的Windows ， Linux ， Unix系统，惠普， NetApp，戴尔

        虚拟化 -完整虚拟机虚拟化基础架构( VI3 )管理， XenSource监测

        应用领域 -Process(程序)，Port，网络应用服务， Web服务，数据库，中间件，商业企业应用方案

• 17. Argus

        是一个网络连接监控器，可以利用它来定制监控网络中符合某种条件的计算机，例如网络空闲、断开等。

 ### ②zabbix系统架构中存在着哪些问题？

        在zabbix的使用过程中，随着监控对象的增多，历史数据量逐日相应的增加，zabbix-server服务器性能方面会出现瓶颈，从而让zabbix工程师面临管理的难题。

        当zabbix性能低时会出现多种状况，Zabbix的前端页面出现无响应、卡顿、列队无法更新，zabbix图形中经常出现断图，无图。一些item获取不到数据。列队中出现大多被延迟的item。

 查看问题：

        可以通过zabbix本机自带模版监控查看性能变化图，其中左侧纵坐标代表通过zabbix服务器每秒处理的值，图形中用绿色表示；右侧纵坐标代表需要处理写入数据库的列队值，图形中用红色表示。等待列队逐渐增多，说明性能越来越差。

        还可以通过看zabbix对于本身server列队的监控，来确定是什么类型的监控项造成的性能问题。等待的列队越多、时间越长，说明zabbix-server性能越差。

• 数据收集延迟

        zabbix主要使用pull方式收集数据，即服务器主动从被监控设备获取数据。当被监控设备数量众多时，数据的收集可能会出现延迟，导致监控结果不准确或无法及时发现问题。

•  大规模监控下的性能瓶颈

        当监控规模变得非常庞大，尤其是当需要监控成千上万个节点时，Zabbix Server可能会遭遇性能瓶颈，包括数据库压力增大、CPU和内存使用率上升等。在这种情况下，如果没有合理地配置和优化，可能导致数据处理延迟、响应速度下降。

•  集中式架构的局限性

        原始架构中，所有的数据都需要通过Zabbix Server处理，这在大规模环境下可能会导致单点故障风险增加，以及网络带宽的压力。虽然可以通过添加Proxy来缓解这个问题，但这也增加了架构复杂度。

•  数据库--主要问题

        默认的单表方式对后期的维护极为不方便，特别是清理历史数据，如果前期不做好架构后面会相当痛苦。        

        Zabbix高度依赖于关系型数据库（通常是MySQL或PostgreSQL）来存储历史数据和配置信息。随着数据量的增长，数据库维护和优化成为一个关键任务，否则可能会影响整个系统的性能和稳定性。

•  报警与通知机制

        默认的报警与通知机制可能不能满足所有企业的具体需求，比如复杂的触发器逻辑、多样化的通知渠道和自定义通知模板等，可能需要二次开发或额外集成才能达到期望效果。

•  资源消耗

        在大规模部署的情况下，Agent在客户端上的资源消耗也是一个考虑因素，特别是在计算资源有限的设备上。

•  复杂性与学习曲线

        Zabbix的功能虽多，但也意味着配置和管理相对复杂，对于新用户来说，可能存在一定的学习门槛。

•  Web界面响应速度

        随着监控数据的增多，尤其是对于长时间范围内的历史数据查询，Web界面可能会出现响应变慢的情况。

•  自动化和集成能力

        虽然Zabbix提供了API接口，但与其他系统和服务的深度集成有时可能需要额外的工作。

### ③ 如果你是zabbix监控系统的维护者，你该如何解决zabbix存在的一些缺陷问题？

        作为维护者，需要深入了解Zabbix的功能特性和业务需求，结合实际环境不断优化和调整，同时借助社区力量和行业最佳实践，持续提升Zabbix监控系统的性能、稳定性和用户体验。

参考链接：https://blog.51cto.com/u_175002/2713780

#### 主要优化

• zabbix分布式架构

        可以针对受影响的监控类型做调整，比如调整监控项的时间间隔，或者根据监控类型定制模版，将模版写到最简。如果以上方法还是没有效果，那么就说明zabbix server压力过大，采用搭建proxy分布式架构，将server的压力分担给proxy。

        多使用ps和top系统命令查看zabbix进程性能，用watch结合ps一起使用观察zabbix工作。

        # 每0.2秒运行ps一次查看zabbix进程活动

        例：watch -n 0.2 ps -fu zabbix

• zabbix配置文件优化

        Zabbix自带模版还会监控各工作进程的状态，可对数据收集过程中的性能做分析，见下图，数据采集过程和使用缓存的空间容量。需要特别注意的有：

        Zabbix busy housekeeper processes,in %##管家处理数据占缓存的百分比

        Zabbix busy history syncer processes,in %##写入数据库的同步程序占缓存的百分比

        Zabbix busy poller processes,in % ## zabbix轮询进程占比

        Zabbix busy unreachable poller processes in %##不可达的轮询进程占比

        Zabbix配置文件可以调整大部分进程与缓存，以获得最佳的工作性能。编辑zabbix-server配置文件。

[root@localhost ~]# vim /etc/zabbix/zabbix_server.conf
#配置文件前面内容为初始安装zabbix时需要配置的基本参数。找到高级配置这一行开始，涉及优化内容用红色标识填充
############ ADVANCED PARAMETERS #################
### Option: StartPollers
# Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
StartPollers=5
#填写范围0-1000，默认5 。轮询处理监控项的进程数，增加太大会影响服务器本身性能，保持此参数的值尽可能低，20000个监控项大概控制在80左右即可。
StartIPMIPollers=0
#IPMI轮询进程实例个数，服务器使用IPMI协议监控时需要更改此项，默认0为关闭
StartPollersUnreachable=10
#不可达主机轮询数量。此值特别耗费性能，设置在10-20之间即可，默认1
StartTrappers=5
#负责处理agents和proxy推送过来的数据的进程数，默认为5，如果zabbix-agent监控类型较多需要加大此参数
StartPingers=1
# ICMP- ping进程轮询实例数，默认为1.，建议更改为20-50之间，根据业务填写即可。
StartDiscoverers=1
#自动发现子进程实例数，默认为1，范围0-250
StartHTTPPollers=1
#HTTP进程轮询实例个数，默认1，范围0-1000，web监控不多选择默认即可
HousekeepingFrequency=1
#zabbix执行管家的频率，从数据库中删除过期的数据。为了防止 housekeeper 过载(例如, 当历史和趋势周期大大减小时), 对于每一个item，不会在一个housek周期内删除超过4倍HousekeepingFrequency 的过时信息. 因此, 如果 HousekeepingFrequency 是1, 一个周期内不会删除超过4小时的过时信息，为了降低server压力，kousekeeping延后server启动30分钟，默认为1，最大24，为0时关闭使用。
MaxHousekeeperDelete=5000
#执行一个Housekeeping周期时，默认删除的数据条目数。默认5000条。如果设置为0，不限制删除的行数，这种情况数据库多数会崩溃。
CacheSize=8M
#缓存大小，单位字节。用于存储主机、监控项、触发器数据的共享内存大小，默认8M最大8G。根据自身zabbix业务需求配置合理的参数。
CacheUpdateFrequency=60
#zabbix缓存更新频率，单位秒。设置范围1-3600
HistoryCacheSize=1024M
#历史数据缓存大小，单位字节
TrendCacheSize=256M
#趋势数据缓存大小，单位字节。用于存储趋势数据的共享内存大小
ValueCacheSize=1024M
#历史数据缓存大小, 单位bytes.缓存item历史数据请求的共享内存大小.0即禁止缓存（不建议这么做）
Timeout=3
#agent, SNMP 设备或外部检查的超时时长(单位秒),填写范围1-30

以上为配置优化主要参数，其他内容配置文件中均有简要说明，可根据业务需求更改优化。对配置参数进行合理的设置会使zabbix处于正常的工作状态。值越大，越高消耗的CPU和内存越多。修改配置文件后，需要重启zabbix-server进程。加载新配置生效

• zabbix数据库优化

        数据库可以说是zabbix调优中最重要的部分，zabbix在很大程度上取决于数据库引擎的可用性和性能。使用最快的数据库引擎，即MySQL或PostgreSQL，使用InnoDB表结构。将数据库表保留在不同的硬盘上，或者做数据库分表，根据mysql的存储引擎，一般采用日期（range）类型的方式将几张大表进行表分区。

        用mysql存储过程，使用外部脚本来管理分区。定期按日期创建新的表分区删除旧的数据表，操作均由mysql独立完成，关闭HouerKeeper,减轻zabbix负担。建议需求量还没达到特别大，对MySQL也不精通的朋友，不要进行zabbix分表。zabbix表与表之间关联关系很大，随时可以因为删掉某一条数据，造成数据库无法启动的状况。

        对于数据库本身的参数进行优化，修改my.cnf调整数据库配置。下面列举比较重要的几个参数作为参考：

[root@localhost /]# vim /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
max_connections = 600
# 最大并发连接数。增加太大会影响数据库本身性能，根据业务选择适当范围即可
max_allowed_packet = 32M
# 接受的数据包大小
max_heap_table_size =128M
# 定义了用户可以创建的内存表的大小
read_rnd_buffer_size = 512K
# MySQL的随机读缓冲区大小
sort_buffer_size = 1M
# MySQL执行排序使用的缓冲大小
join_buffer_size = 1M
# 批量查询操作使用的缓冲区大小
query_cache_size = 2048M
#MySQL的查询缓冲大小
query_cache_limit = 32M
#指定单个查询能够使用的缓冲区大小
innodb_open_files =2048
# nnodb能打开的表的数据，如果库里的表特别多的情况，请增加这个。这个值默认是300
innodb_buffer_pool_size = 10G
# nnoDB使用一个缓冲池来保存索引和原始数据
innodb_thread_concurrency = 32
# 默认设置为 0,表示不限制并发数，
thread_cache_size = 10
# 线程缓存
table-cache = 5000
# 所有线程打开的表的数目。增大该值可以增加mysql需要的文件描述符的数量
back_log = 300
# 接收队列，对于没建立tcp连接的请求队列放入缓存中

数据库当然还有其他调优部分：如日志大小，日志缓存，慢查询日志等。均能对zabbix-server造成不同程度的提升。

• zabbix前端优化

        减少history的保存时间，减少item的获取间隔时间，大部分的item是不需要间隔时间太短的，尽量减少无意义的监控项。将Items的检测方式修改为主动模式（默认为被动模式）。为了提高性能或者环境需要，可将所有的Items都设置为主动模式。主动模式由于是Agent将采集到的数据主动发送给Server，而不需要Server每次连接Agent等待采集，所以采用主动模式会使Zabbix-Server具有更好的性能。

•  其他

        

        选用更好的硬件配置和快速的磁盘配置等工作应该是在规划之前进行的，如选用快速的RAID存储、SSD固态硬盘、多核CPU、大容量内存等硬件优化。通常，在优化软件无效的情况下，换更好的硬件会有非常明显的效果，但大多情况下，我们还是以优化软件为主。

        使用最新的操作系统，定制化操作系统内核，排除内核中不必要的功能。应该有些作用，但是效果肯定不明显。

        可能由于zabbix本身对某些方面的性能并未满足我们的需求，需要从代码级别进行二次开发优化。这需要根据自身需求来改进。

#### 次要优化

• 1.大规模监控优化

• 分布式部署：利用Zabbix Proxy将监控任务分散到多个节点，减轻Zabbix Server的压力，同时降低网络带宽需求。
• 数据库优化：根据实际监控规模调整数据库配置，如索引优化、分区表、合理清理历史数据等，确保数据库性能。
• 负载均衡与横向扩展：考虑在Zabbix Server前面增设负载均衡器，根据需要增加Server实例，实现水平扩展。

• 2. 报警与通知机制

• 定制触发器与动作：细化触发器规则，优化报警阈值，避免无效报警。定制动作模版，支持更多类型的告警通道，如微信、钉钉、短信等。
• 告警降噪：通过设置告警抑制、依赖关系等功能，减少重复或无关紧要的告警。

• 3. 资源消耗

• Agent优化：根据实际监控需求，精简Agent配置，只启用必要的监控项，降低Agent在客户端的资源消耗。
• API调用优化：合理利用API进行数据获取和处理，避免大量实时查询导致的资源浪费。

• 4. 复杂性与学习曲线

• 提供培训与文档：编写详细的用户手册、操作指南和最佳实践文档，定期开展培训课程，帮助用户快速上手和深入使用。
• 界面优化：如果可能的话，对Zabbix Web界面进行优化，使其更加直观易用，降低操作复杂度。

• 5. 自动化与集成能力

• API扩展：增强Zabbix API功能，使其能够更好地支持与其他系统和服务的集成。
• 自动化运维：利用Zabbix的自动化特性，结合Ansible、Puppet、Chef等自动化运维工具，实现监控与运维一体化。

• 6. 性能瓶颈分析与优化

• 性能监控与调优：对Zabbix自身的运行情况进行监控，定期分析性能瓶颈并进行针对性的优化。
• 技术社区支持与反馈：密切关注Zabbix官方社区和更新，及时跟进官方发布的bug修复和性能优化版本，对遇到的问题进行反馈和寻求解决方案。

## 问题四、

 ### mysql数据库为什么需要做主从同步，用来解决什么问题？

主从同步配置网址：Linux & Centos 7 & Mysql 主从同步的作用、搭建_mysql centos 7的好处-CSDN博客      

主从同步简述：

1. 将一台服务器（主）的 Mysql 数据同步到另外一台服务器（从）的 Mysql 这一过程就叫主从同步。
2. 一个主服务器可以对应 N 台从（子）服务器

好处

1. 读写分离，减轻数据库压力，其主服务器负责写数据，从服务器负责读数据。
2. 去中心化，多台服务器保证了不用在担心某台服务器的 Mysql 挂掉而导致整个系统奔溃。

缺陷

    操作不当就容易出现主从不同步情况，对于有强制数据的一致性的需求来说是不适用的。

        MySQL数据库的主从同步机制是提升系统可用性、扩展性、数据安全性以及实现读写分离、容灾备份等重要功能的关键技术手段。其解决问题方面有：

• 高可用性

        主从同步可以实现数据库的冗余备份，主服务器出现故障时，从服务器可以迅速切换成为新的主服务器，继续对外提供服务，从而确保数据服务的高可用性，降低服务中断的风险。

        主服务器如果遇到硬件故障、软件错误或网络中断等情况，可能导致服务中断。通过主从同步建立的备库可以在主库发生故障时立即接管服务，保证数据服务的连续性和可用性。

• 负载均衡 

         读写分离是数据库优化的一种常见策略。主服务器负责处理写入请求（INSERT、UPDATE、DELETE等操作），而从服务器可以处理读取请求(SELECT操作)。这样可以减轻主服务器的压力，提高整个系统的处理能力，尤其是在读取密集型的业务场景中，显著提升了系统的响应速度。

• 数据备份与恢复

        主从同步实现了数据的实时备份，即使主服务器发生灾难性故障导致数据丢失，从服务器上仍有一份最新的数据副本，可以直接用于恢复，极大地降低了数据丢失的风险。

•  容灾恢复

       主从架构允许在不同的地理位置部署从库，当主服务器所在的数据中心发生故障时，分布在其他数据中心的从服务器可以接管服务，保障业务连续性。

•  数据分析与报表生成

        主从架构允许在不同的地理位置部署从库，即使主数据中心出现故障，位于其他地区的从库也可以继续提供服务，确保业务连续性。从服务器可以用于执行耗时较长的分析查询或者生成报表，而不影响主服务器处理实时的生产事务，避免了对主服务器性能的影响。

• 扩展性

        随着业务增长，数据量和访问量的增长，可以通过增加从服务器的方式进行水平扩展，满足更大规模的数据处理和访问需求。