最近項(xiàng)目需要為大數(shù)據(jù)平臺(tái)配備監(jiān)控告警系統(tǒng)，雖說(shuō)之前折騰過(guò)很長(zhǎng)時(shí)間的nagios，對(duì)其中的原理比較了解，但是最終還是決定選擇zabbix，

原因有兩點(diǎn)：

1、nagios的開(kāi)源的UI實(shí)在是慘不忍睹，而客戶特別是不懂技術(shù)的門外漢對(duì)產(chǎn)品的要求往往都集中在UI上；zabbix的UI設(shè)計(jì)可以直接很省心；

2、動(dòng)態(tài)性，nagios的告警機(jī)制非常靈活，配置項(xiàng)也很靈活，但是它修改配置需要去重啟，不如zabbix，修改后無(wú)需重啟服務(wù)；

選擇采用docker-compose的方式部署zabbix，持續(xù)穩(wěn)定運(yùn)行了一段時(shí)間后發(fā)現(xiàn)，zabbix-server一直處于restarting狀態(tài)， 采用docker-compose logs

--tail=100 (注意，當(dāng)日志太多的時(shí)候，--tail很有用)發(fā)現(xiàn)是CacheSize設(shè)置太?。ㄖ挥?M，果斷修改成1028M），然后把配置文件docker cp到容器里，奇怪的事情發(fā)生了，zabbix-server仍然是處于restarting，日志也還是跟原來(lái)沒(méi)有變化，難道不是cachesize的問(wèn)題？

苦惱啊，繼續(xù)google了一陣，沒(méi)有別的解釋

突然想到，難道配置沒(méi)有修改成功，把容器里面的配置文件zabbix-server.conf? ?拷貝出來(lái)一看，發(fā)現(xiàn)果然，CacheSize? ?配置不見(jiàn)了，太詭異了；

找另外一個(gè)zabbix進(jìn)行測(cè)試，確定這種方式修改配置沒(méi)有問(wèn)題，那是什么原因呢？

猜想如下：

1、docker把修改好的配置文件給改了

2、其它程序把修改好的配置文件給改了

如何確定了？最好的還是日志，繼續(xù)向上看日志，發(fā)現(xiàn)了貓膩，居然每次CacheSize的配置都被update了，難怪沒(méi)有用？到底是誰(shuí)干的？

經(jīng)過(guò)分析發(fā)現(xiàn)容器的入口文件docker-entry.sh有重大嫌疑，找到對(duì)應(yīng)的文件，果然就是它，為了防止配置被修改，它每次都會(huì)檢查，而它

執(zhí)行的時(shí)機(jī)是容器啟動(dòng)的時(shí)候，容器一直在restarting，它就被反復(fù)執(zhí)行，也就是說(shuō)zabbix-server.conf文件一直是它在修改。