随着京东业务的快速发展，MySQL数据库的使用越来越普及，服务器数量增长迅速。这对京东的MySQLDBA团队提出了越来越高的要求。监控系统为数据库的管理和维护提供了准确的数据依据，是数据库运维人员的千里眼和耳朵。准确、及时、有效的监控可以让运维人员对生产服务系统的运行情况了如指掌。通过分析获得的监控信息，判断被监控数据库的运行状态，预测可能出现的问题，及时制定合适的优化方案，保证整个系统的正常高效运行。这样在很大程度上保证了数据库的安全，避免了一些不必要的损失。因此，我们有必要对Zabbix系统有更深入的了解和认识。一、Zabbix功能介绍Zabbix是一个基于WEB界面，提供分布式系统监控和网络监控功能的企业级开源解决方案。Zabbix可以监控各种网络参数，保证服务器系统的安全运行；并提供灵活的通知机制，让系统管理员可以快速定位/解决各种问题。这是百度百科上对zabbix的定义。市面上监控软件很多，为什么选择zabbix？让我们来看看它的一些功能：1.自动发现服务器和网络设备。这个功能有点鸡肋，在多种应用和多设备混合场景下不太实用，给zabbix的整体运维管理带来不便。实际使用中也存在各种问题，尤其是在设备种类繁多、设备数量多的情况下。不推荐使用该功能。Zabbix监控和添加设备结合CMDB完成，这样定位设备使用情况和添加模板会更加准确；2、底层自动发现。这个非常方便实用，比如内置自动发现系统分区，自动发现多个网卡等。这个功能也可以自定义，比如监控一台主机上的MySQL多实例服务，可以通过此功能轻松完成；3、分布式监控系统，集中web管理。Zabbix支持主动监控和被动监控两种模式（模式是相对于客户端，主动将监控数据推送到服务端或者从服务端拉取监控数据，建议使用主动模式，减少服务端压力），并且能够做到秒级监控对于一些监控软件来说是不可能的，但是对于重要的业务来说却非常重要；4.支持范围广。支持监控目前市场上常见的各种设备和各种OS、服务、日志等。可以使用内置代理监控或免代理监控等监控方式，如SNMP；5、监控项设置灵活。Zabbix本身已经支持很多常见的监控项。用户还可以编写脚本灵活定制监控项，可以灵活组合多个告警阈值进行准确告警。例如，可以设置监控硬盘的报警阈值达到硬盘空间的80%，剩余空间低于50G时报警；6、高层业务视图监控资源，监控状态展示可纵横展示。比如在一组数据库的分片中，可以将所有主库的某个性能指标做成一个Graphs，可以很方便的比较各个主库的负载是否均衡。也可以将多个Graphs做成一个Screen，然后在一个Screen中可以看到各种性能指标的各种情况，比较方便直观；7.灵活的用户权限设置。支持自定义事件和邮件发送，也支持告警升级和日志审计；8、基于zabbix告警的故障自愈。Zabbix有规范的故障处理流程，对告警进行分级分类，可以自动处理一些低级故障，采用固定的处理方式，达到故障快速恢复的效果。这个非常重要。如果做得好，可以最大程度保证业务的可用性和稳定性，降低人为失误的风险和人员成本；9.强大的内置API。几乎所有的zabbixserver端网页配置操作都可以通过自带的API完成，用户可以方便地对其进行二次开发，满足自己的自动化运维需求。Zabbix***的缺点之一应该是没有合并告警的功能。极端情况下会出现告警风暴。但是很多监控软件应该都没有实现这个功能。用户可以对其进行二次开发，达到组合告警的效果。2、Zabbix的优化很多企业使用zabbix监控一两百台设备。跑了半年，性能极差。打开监控地图需要很长时间，甚至打不开。这个问题比较普遍，主要是没有对zabbix进行合理的规划和优化。如果能对zabbix进行合理的优化和架构规划，zabbix监控上万台设备还是很容易的。1、配置文件参数优化针对大型海量设备的监控，需要调整zabbix相关参数，主要包括进程数、缓存大小、超时时间等。Adjusttheparametersofzabbixitselfaccordingtotheactualmonitoringsituation.禁用掉如VMware、Java等方面不使用的监控方式：StartPollers=200StartPollersUnreachable=100StartTrappers=200StartPingers=100StartTimers=50StartDBSyncers=100Timeout=30TrapperTimeout=30StartProxyPollers=50HistoryTextCacheSize=1024MTrendCacheSize=1024MHistoryCacheSize=1024M2、监控项和报警项的优化监控项越多，对zabbix数据库和自身性能的考验越大。精简监控项，只监控必要的监控项，对运维没有帮助的监控项可以取消，减少系统资源的浪费。最典型的MySQL监控模板就是网上流行的percona官方出品的zabbix监控模板。监控项有200多个，基本包括了showglobalstatus中的所有项。很多监控项对于运维来说是没有意义的，但对数据库和zabbix本身的性能有严重的影响。当监控级别达到一定程度时，性能差距可想而知。监控项的类型最好使用数字，尽量避免使用字符。characters在数据库中占用大量存储空间，设置触发器相对麻烦，zabbix本身处理数字的效率比较高。如果业务需要监控字符类型的项目，可以适当减少数据采集的时间间隔，提高处理效率。在Trigger中，正则表达式函数last()和nodata()是最快的，而min()、max()和avg()是最慢的。在使用过程中，尽量选择速度较快的功能。在配置Trigger的时候，也要注意使用正确的逻辑。错误的逻辑可能会导致数据库查询变慢。3、zabbix数据库优化需要对数据库进行分区，方便删除历史数据。同时关闭zabbix自身设置删除历史数据。如果不设置分区和删除规则，随着时间的推移，zabbix自身和二次开发的查询性能会变得很低，甚至查询不到数据。表分区的相关内容可以参考如下文档：https://www.zabbix.org/wiki/Docs/howto/mysql_partition。关闭zabbix自身删除历史数据的SQL语句如下：UPDATEconfigSEThk_events_trigger=60,hk_events_internal=60,hk_events_discovery=60,hk_events_autoreg=60,hk_audit=60,hk_sessions=60,hk_history=30,hk_history_mode=0,hk_history_mode=obbistory_mode0,hk_trends_global=1,hk_trends=730,hk_services=60;设置在页面上的位置为：建议在历史表中的时间字段添加索引，二次开发时使用的可能性更大。建议对历史数据表开启innodb压缩，如下：/*开启innodb压缩，设置历史表开启压缩*/SETGLOBALinnodb_file_format='barracuda';SETGLOBALinnodb_file_format_max='barracuda';/*innodb_file_format和innodb_file_format_max要写入my.cnfconfiguration文件中*/ALTERTABLEhistoryROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_logROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_strROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_str_syncROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_textROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_uintROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_uint_syncROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8;ALTERTABLEhistory_strROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8；ALTERTABLEhistory_uint_syncROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8；ALTERTABLEtrendsROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8；ALTERTABLEtrends_uintROW_FORMAT=COMPRESSEDKEY_BLOCK_SIZE=8；MySQL的版本建议使用PerconaDB5.6，设置thread_handling=pool-of-threads，启用线程池。MySQL配置文件其他参数的优化这里就不多说了，可以参考链接中的配置文件：http://wangwei007.blog.51cto.com/68019/1623329。4、zabbix监控系统架构优化Zabbix架构优化，主要原则是将server端的压力分担给proxy端，将proxy端的压力分担给agent端。监控项采用被动方式。Server端和Proxy端都是高可用的，防止单点监控不可用。下面是zabbix的架构和流程图，仅供参考：3.Zabbix自动化运维自动化的本质是解放、简化、方便运维人员的工作，提高效率，减少人为故障。运维的基本思路是能自动出故障，坚决不手动出故障，运维人员要养成“偷懒”的好习惯。自动化的基础是基础信息的准确性和各种配置信息规则的规范化。1、监控自动化规范规定主机名规范，以达到知名知义的效果。看到主机名，大概可以知道这个设备使用的是什么业务，作用是什么。当出现问题时，运维也可以快速知道影响的范围和严重程度，方便运维。主机规格一般可以包括机房信息、企业信息、企业注册、企业中的角色信息、IP等相关信息；约定主机组名，主要是方便同业务同研发查看自己主机的监控和接收告警信息，也方便zabbix自己做组图展示在屏幕上，并制作性能比较图表。比如数据库的sharding集群可以定义一个hostgroup，然后做一个Graphs汇总图，方便研发，直观比较各个shard上的性能指标是否均衡；告警级别的规范主要是用来区分告警发给谁，如何发送的，也可以根据级别和监控项自动处理，高级别先处理，低级别先处理集中方式；主机维护暂停报警的规范。告警很重要，暂停监控需要谨慎。不建议使用内置的Maintenance预维护，主要是处于维护状态的主机仍然会显示在监控首页。虽然有标记，但是在主机数量多的时候不方便运维查看和监控。.建议进行二次开发，约定主机维护状态关闭触发器，维护结束后自动开启；不建议手动修改主机监控的各种配置，容易忘记，手动效率低，容易造成各种设置和规则。困惑，后续问题堆积起来，使事情变得更加复杂，可维护性差。对zabbix进行二次开发时，配置变更需要记录修改原因、生效时间段等信息；监控增删改查全部自动完成，各种规范受程序约束，由程序自动完成。2.自动化部署配置Zabbix的server和client的部署比较简单，网上教程也很多。整个部署过程脚本化，然后结合CMDB，自动批量部署，添加主机到监控。部署过程可以参考这个链接：http://wangwei007.blog.51cto.com/68019/1047953。3、日常运维自动化Zabbix本身提供了丰富的API接口，您可以通过调用这些API对zabbix进行标准化的配置。可以到http://www.zabbix.com/documentation.php查看各个版本的说明，包括zabbix的各种操作；在API的描述中，也描述了zabbix数据库中表的数据库字典，每个字段代表Everything，都有详细说明。zabbix的二次开发和自动化运维主要是通过调用zabbixAPI和读取zabbix数据库来完成的。不建议直接直接写入zabbix数据库的原表，一般也没有必要。可以参考这个python写的API：http://wangwei007.blog.51cto.com/68019/1139982。4.告警的自动处理Zabbix可以在action中设置和调用系统命令。在确保安全的情况下，您可以使用该功能自动处理指定的告警。设置如下图所示：用户可以对常见的告警进行归纳，对一些固定处理方式的告警进行脚本化处理。当达到一定阈值时，自动处理，如定点清除日志等，达到告警快速恢复的目的。5、LLD的使用Zabbix中的LLD是一个非常好的扩展，方便监控主机上MySQL、Redis等服务的多个实例、端口、硬盘分区、多个网卡。用户可自定义发现规则，可自动生成指定项、触发器、图表等，更加灵活，极大方便了监控的运维。6、zabbix的二次开发Zabbix的二次开发主要是对监控数据的二次分析，可以最大限度的发挥这些数据的作用，从而更好的服务和指导运维。Zabbix的详细历史数据按照数据采集的类型存在于如下表中：history、history_log、history_str、history_str_sync、history_sync、history_text、history_uint、history_uint_sync，eventszabbix的趋势数据存储在trends两个表中和trends_uint。趋势数据由详细的监控数据计算得出，每个监控项每小时都会产生最小值、最大值和平均值。利用这些历史数据，可以自动生成一些性能参数的统计汇总报表，比如对某项性能指标压力较大的***00，方便运维排查安全隐患。通过分析告警历史，找出经常告警的监控项，评估易用性。***，感谢我们DBA团队老大范建刚，范老师对本文的指导和建议，也感谢他对MySQL监控的关注和支持。【本文为专栏作家王薇原创文章，转载请联系作者获得授权】点此阅读作者更多好文
