Zabbix 作为他们的监控解决方案时最容易犯的五个错误

① 数据库的配置
       出于一些原因，用户在他们的环境中，从各种来源、docker容器或其他任意方式安装Zabbix服务器时，他们决定要用哪个数据库引擎。我们可以进一步了解一下这方面的内容,Zabbix中所支持的数据库大家都熟知了，目前并没有什么新的类型加入，哪么到底选择哪一个？哪一个更好？我们认为你应该选择一个你最熟悉的数据库去操作，因为你会在上面进行工作，如果数据库或其性能哪里出了问题，你需要做调优、做故障排除。然后，当你在配置你的数据库时，你必须要对配置文件做调优，如果数据库是MYSQL，配置文件是my.cnf；也有可能有其他情况，可能数据库是MariaDB的不同版本，可能是不同的文件和文件名称，你必须要对配置文件做调优，要做到什么程度呢，越多越好。你可以在网上找到很好文档和指南，教你如何去调优你的数据库，我这边不建议你们特地地搜索“如何调优Zabbix的数据库？”你只需调优你的数据库以支持在实际生产环境中进行大量的插入、读取操作。充分使用你的计算机内存和CPU，因为通常用户只会安装MYSQL的默认配置文件，产生了启动问题、性能问题后，他们一再的添加内存，问题仍然存在，最终，他们数据库的服务器上，大约有500G的内存，且性能还是不行，这是为什么呢？因为数据库配置文件没有优化。是的，尽管你的服务器上有500G，但是数据库不会使用这些资源中的任何一个，只因为配置文件是默认值。

② Zabbix server配置文件
       当你在执行一个全新的安装操作，你可能会认为，我为Zabbix配备有一个强大的服务器，我们再举一个例子，还是以500G,32核或者类似的配置，即使我不是一个Zabbix的专家，我也能清楚的了解自己的物理服务器或者虚拟机的性能，哪么用户会怎么做？有时他们会打开配置Zabbix的文件，你知道配置文件中有很多参数，并且你可以增加大多数:内部进程、数据采集进程、历史数据同步、告警、计时器、pollers、trappers和其他进程的数量。出于这些原因，用户认为自己的服务器是强大的，他将所有的参数都调到最大值，比如：1000个trappers,1000个pollers,100个历史数据同步进程。最终，产生200NVPS，性能也会变得很差，记住！因为你有内存资源而最大化进程的数量和进程的缓存容量，并不是一个解决办法；相反，这是错误的。这些参数应该基于前端展示的Zabbix自身的性能图表。如果你不明白我的话，请打开你的前端，前往monitoring中的graph,选择Zabbix服务器主机，然后检查三个图表：Zabbix内部进程、Zabbix数据收集和Zabbix缓存使用情况。如果你看到poller不断在70%、80%繁忙状态，那么就增加poller，如果10%左右的话，那就没必要增加,如果有人在你之前已经修改了配置文件，并且你看到只有1%繁忙状态，且你有300个poller,那么试试其减少到150个，可能性能仍旧良好，但是请记住，进程越多并不意味着性能越好。

③ 使用模板功能
       在我刚开始探索Zabbix世界时，对我来说模板也是一个大问题。任何地方你都会看到说，模板是最好的实践，会是，当你刚刚开始探索前端的东西时，你可能会觉得，为什么我需要模板呢？我可以直接在host上创建相同的监控项和触发器，这对我来说更容易，不过，你的环境越大，你就会有更多的主机，如果这些主机没有模板来维护和管理，所有的操作将会变得非常复杂，如果你有一个模板，将其应用到1000台你需要修改的主机，比如模板中对触发器阙值的一次改变，它会一次性生效到1000台主机，如果你没有模板，那么，你可能必须要分别在各个主机上修改阙值。

④过度思考
       这是我在使用过程中体会到的一个情况，有时候人们真的会过度思考，我并不特指配置参数或其他东西，他们在Zabbix安装设计和架构上过度思考了，如果你们搭建了一套较小的环境，有500个主机，50个NVPS,且并不是应用于一级核心系统，也不是监控一级软件和服务的话，在配置上没有必要过度考虑，此外，注意所有的负载均衡，不要在Zabbix服务器trafffic上设置负载均衡，用多个前端是OK的，Zabbix服务器必须是只有一个。Zabbix服务器在高可用设置下工作，仅作为主动—被动。除此之外，维护1个Zabbix服务器，1个前端，1个数据库，是比较简单的，虽然它们可能在不同主机上，要知道不是所有的Zabbix安装都需要考虑大规模负载均衡设置，通过VPN设置active\active proxy，通过nginx设置负载均衡访问多个前端界面，自定义配置等复杂的情况。有些情况下，这样会很有用，便是在大部分案例中，这样做的话会使管理理复杂，如果你把这些负载均衡用在Zabbix服务器上，其性能将只会更差。

⑤ Triggers
       这可能是在任何监控环境和软件中最重要的点之一，比如你收集数据，当然还有你所有创建的触发器，将会，也应该在问题出现时及时给你告警，不幸的是，由于没有大量的操作经验，用户倾向于创建一些非常基础的触发器，last value高于5，低于10，这类设置到最后，当你的环境不断扩大，考虑一下那些触发器的敏感性，last value会高于一些东西，最后，你可能会收到来自监控系统关于问题的数百、甚至一千封电子邮件，实际上很多问题并不是你需要关心的，你会收到像"CPU负载高于85%"这样的邮件，你每天都会收到50封这样的告警邮件，你甚至都不用去在意这些，比起简单的使用last函数，你可以使用更多复杂的触发器，对于last checksr的值使用一些平均函数，比如最近两小时的平均值，执行异常检查并把平均值和昨天相同的两个小时的平均值进行比较，如果高出了2倍，我才会触发动作并执行，计算百分比来评估日志监控项中的字符串，在触发器表达中加入多个监控项和多个主机，比如说，Web引擎的CPU利用率要2倍高于过去两个小时中的平均值，与此同时，我们正在监控网页上的在线用户数，假设CPU负载较高且用户数量高于200，那这些都不是问题，因为200 个用户同时在线，这就是我们的网站引擎可以提供的，所以它算不上问题，或者说直接创建更加复杂的触发器，思考一下你的触发器，利用现有的数据，利用主机监控项，加入多个表达式，此外，也要注意误报，没有人想要每天收到上千个告警，如果每天都收到大量的告警的话，当真正的问题发生进，你就有可能忽视它了，因为你每天要收到50个关于它的告警。