gdb 調試zabbix_server解決zabbix_sender不成功的問題

先說下環境及使用版本：

Red hat Enterprise Linux 64位系統，zabbix 1.8.5

zabbix server端，agent，web等都搞定了，就剩下一個zabbix_sender，死活搞不定。讓人郁悶的是，zabbix server debug的log中，什麼都沒有寫，一切似乎都很正常！于是，一怒之下，用gdb調試zabbix_server來看看究竟是怎麼回事。

使用zabbix_sender發送時，資訊如下：

[root@localhost tmp]# zabbix_sender -k "online_users" -o "456" -T -vv  -c /etc/zabbix/zabbix_agentd.conf  -s iPilot-80 -z 10.10.136.83

zabbix_sender [20644]: DEBUG: answer [{

        "response":"success",

        "info":"Processed 0 Failed 1 Total 1 Seconds spent 0.308953"}]

Info from server: "Processed 0 Failed 1 Total 1 Seconds spent 0.308953"

sent: 1; skipped: 0; total: 1

把zabbix_server的config檔案中的debuglevel改成debug，然後在日志中搜尋online_users，可以看到有類似下面的日志：

78276-  6460:20111212:220318.043 Trapper got [{

78277-  “request”:”sender data”,

78278-  “data”:[

78279-          {

78280-                  “host”:”iPilot-80″,

78281:                  “key”:”onlines”,

78282-                  “value”:”456″}]}] len 104

78283-  6460:20111212:220318.043 In recv_agenthistory()

78284-  6460:20111212:220318.043 In process_hist_data()

78285-  6460:20111212:220318.043 In process_mass_data()

78286-  6460:20111212:220318.043 In DCinit_nextchecks()

78287-  6460:20111212:220318.043 In DCflush_nextchecks()

78288-  6460:20111212:220318.043 End of process_mass_data()

78289-  6460:20111212:220318.043 In zbx_send_response()

78290-  6460:20111212:220318.043 zbx_send_response() ‘{

78291-  “response”:”success”,

78292-  “info”:”Processed 0 Failed 1 Total 1 Seconds spent -0.000000″}’

78293-  6460:20111212:220318.043 End of zbx_send_response():SUCCEED

78294-  6460:20111212:220318.043 End of recv_agenthistory()

這裡，我們可以清晰的看到函數執行時的調用順序。

ok，gdb出場了。

首先，編譯zabbix_server時，在Makefile中，把

zabbix_server_CFLAGS = -DZABBIX_DAEMON

改成

# zabbix_server_CFLAGS =

重新編譯，啟動編譯後的zabbix_server；

然後，使用gdb attach到zabbix_server上；

當你使用ps aux時，你會發現有很多個（通常有20多個）zabbix_server程序在運作，怎麼辦？

ok，修改zabbix server的配置檔案，把Start開始的程序數配置都改成最小，其中，StartTrappers一定要改成1，我的配置檔案修改後，如下：

[root@redhat5 tmp]# cat /etc/zabbix/zabbix_server.conf | grep Start | grep -v ^#

StartPollers=0

StartIPMIPollers=0

StartPollersUnreachable=0

StartTrappers=1

StartPingers=0

StartDiscoverers=0

StartHTTPPollers=0

StartDBSyncers=1

StartProxyPollers=0

靠

重新開機重新編譯後的zabbix_server，用gdb ./zabbix_server來調試（假設目前目錄的zabbix_server的編譯目錄）。

ps aux | grep zabbix_server時，一般會有10個左右的zabbix_server程序，這時，一般第3個程序是trapper的程序，如何判斷是不是trapper的程序？

當你attch zabbix_server程序pid後，使用bt指令，顯示出函數堆棧，trapper的如下：

(gdb) bt

#0  0xb7f2a410 in __kernel_vsyscall ()

#1  0x005b88c1 in select () from /lib/libc.so.6

#2  0x08093e2b in zbx_tcp_accept (s=0xbfd8b90c) at comms.c:971

#3  0x08064eeb in main_trapper_loop (p=1 '\001', s=0xbfd8b90c) at trapper.c:437

#4  0x08055d02 in MAIN_ZABBIX_ENTRY () at server.c:645

#5  0x0808803b in daemon_start (allow_root=0) at daemon.c:252

#6  0x080551a6 in main (argc=16, argv=0x0) at server.c:437

(gdb)

讓

根據上面zabbix server的日志，設定zabbix server的breakpoint：

b process_hist_data

b process_mass_data

當一步一步跟蹤下去之後，發現問題出在這個函數身上：

zbx_tcp_check_security

這個函數用來檢查zabbix_sender端是否被允許發送資料。

終于搞清楚了，zabbix-sender的文檔僅僅說了zabbix_sender的用法，其中，在web界面上，配置zabbix_sender的item時，需要注意：

1、類型一定要是zabbix_trap類型；

2、allowed ip要填寫zabbix_sender的ip位址，如果有多個，使用,分割；

3、zabbix_sender指令中的-s參數hostname要和server的web界面上一緻；

注意了這幾點，基本上就沒問題了。

本文轉自 liqius 51CTO部落格，原文連結：http://blog.51cto.com/szgb17/1888995，如需轉載請自行聯系原作者