zabbix使用一段時間後總是報zabbix agent不可到達，報錯文字如下：
zabbix server messages: problem: zabbix agent on zabbix server is unreachable for 5 minutes
首先檢視zabbix agent的日志，找到關鍵出錯資訊，日志如下：
來自：/tmp/zabbix_agentd.log
mysqladmin: connect to server at 'localhost' failed
error: 'can't connect to local mysql server through socket '/tmp/mysql.sock' (2)'
check that mysqld is running and that the socket: '/tmp/mysql.sock' exists!
由此可見，zabbix agent無法連接配接資料庫（作為管理者應該清楚zabbix agent是不會連接配接資料庫的），具體的是無法通過/tmp/mysql.sock連接配接到本地資料庫伺服器，由于這是一個socket檔案，它的預設權限對其他使用者或使用者組是開發讀寫權限的。例如檢視目前的配置：
而且資料庫服務是正在運作的，而且socket檔案的确存在，權限也是正常的。而且通過指令行可以驗證通過socket檔案确實可以連接配接。
問題分析與解決思路：
資料庫伺服器是一直正常的，這個作為管理者即使不運作任何指令也能做到心中有數，應該不是資料庫伺服器自身的問題，但不能排除跟用戶端的連接配接方式有關。
檢視mysql資料庫的配置檔案
[root@chris ~]# delsc /etc/my.cnf
[client]
port = 3306
socket = /tmp/mysql.sock
[mysqld]
datadir = /usr/local/mysql/var
skip-external-locking
skip-name-resolve
key_buffer_size = 384m
max_connections = 5000
max_allowed_packet = 1m
table_open_cache = 64k
sort_buffer_size = 128m
net_buffer_length = 8k
read_buffer_size = 256k
read_rnd_buffer_size = 512k
myisam_sort_buffer_size = 128m
slow-query-log = 0
tmp_table_size = 8g
max_heap_table_size = 8g
table_cache = 512
binlog_cache_size = 6144m
query_cache_type = 1
query_cache_size = 128m
query_cache_limit = 128m
query_cache_min_res_unit = 1024
myisam-recover-options = backup
innodb_data_home_dir = /usr/local/mysql/var
innodb_data_file_path = ibdata1:10m:autoextend
innodb_log_group_home_dir = /usr/local/mysql/var
innodb_buffer_pool_size = 8g
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 16
innodb_file_format = barracuda
innodb_log_file_size = 512m
innodb_log_buffer_size = 64m
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = o_direct
innodb_lock_wait_timeout = 50
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
innodb_use_sys_malloc = 0
innodb_additional_mem_pool_size = 2g
innodb_file_per_table = 1
[mysqld_safe]
log-error = /usr/local/mysql/var/mysql-error.log
pid-file = /usr/local/mysql/var/mysql.pid
[mysqldump]
quick
max_allowed_packet = 16m
[mysql]
no-auto-rehash
[myisamchk]
key_buffer_size = 512m
sort_buffer_size = 512m
read_buffer = 8m
write_buffer = 8m
[mysqlhotcopy]
interactive-timeout
[root@chris ~]#
發現在[client]中存在socket = /tmp/mysql.sock一行，可能（可能性的情況參照下文）會預設導緻mysql用戶端連接配接時會自動使用socket進行連接配接。
檢視zabbix agent的配置檔案，觀察是否有通過socket連接配接mysql的配置資訊（前面提到，作為管理者應該清楚zabbix agent是不會連接配接資料庫的，此時應該準确的說預設是不會連接配接資料庫，如下圖所示zabbix agent添加了一個與mysql有關的監控項，裡面用到了mysql程式，但沒寫socket選項（事實上使用localhost作為連接配接主機名将會使用socket））。
為了縮小問題範圍，先将/etc/my.cnf檔案中關于[client]中的socket那段先注釋掉（事先應該知道沒有其他用戶端連接配接）。注意：如果把[client]中的socket注釋掉，則在本機mysql用戶端程式（包括mysqladmin,mysqldump等）時都需要指定主機名、端口和密碼，否則用戶端程式會查找socket的預設位置“/var/lib/mysql/mysql.sock”，而這個socket檔案的位置并不一定是這個。
mysql連接配接通過套接字連接配接和通過端口号連接配接有什麼不同？unix平台上的mysql用戶端能夠以兩種不同的方式連接配接到mysql伺服器：通過檔案系統中的檔案（預設為/tmp/mysql.sock）使用unix套接字進行連接配接，或通過端口号使用tcp/ip進行連接配接。unix套接字檔案的連接配接速度比tcp/ip快，但僅能在與相同計算機上的伺服器相連時使用。如果未指定指定主機名或指定了特殊的主機名localhost（注意此處，如果指定了連接配接的主機名為localhost将使用socket連接配接），将使用unix套接字。套接字連接配接可以了解為指定了ip+端口。
是以按照上述理論将localhost換成127.0.0.1，取消socket連接配接方式，改用tcp/ip連接配接。其實反過來回想，假如指定了連接配接的主機名（除了localhost）或ip位址、端口号，就不用再使用socket，是以可以将socket那個注釋給去掉，這樣友善管理者平時連接配接調試。
因為zabbix server是要連接配接資料庫的，是以也順便檢查一下。果然有收獲：關于dbport有一個有用的注釋“database port when not using local socket. ignored for sqlite.”意思是說如果socket不使用則使用dbport，而預設dbport是不使用而優先使用socket的。
是以也将這個dbport設定成啟用狀态。
其他可能影響因素：
iptables的規則-a input -p tcp -m state --state new -m tcp --dport 3306 -j accept也是正常的，15 accept tcp -- 0.0.0.0/0 0.0.0.0/0 state new tcp dpt:3306 。
selinux是事先關閉好了的。
但修改完上述所提到的後發現問題依然，zabbix依然報錯（zabbix server messages: problem: zabbix agent on zabbix server is unreachable for 5 minutes），檢視zabbix server的日志後發現有這麼一條資訊（後來發現還有報資料庫跑飛的資訊）：
由上圖可知，盡管能擷取到ntp[pool.ntp.org]資料，但花費的時間比較長，但是沒有在zabbix web管理界面中找到跟逾時相關的設定，是以可以考慮換一個ntp伺服器或者幹脆禁用掉。後來也發現這個key擷取不到資料時就會導緻觸發zabbix agent不可到達的報警。
對于第二個報錯：問題可能比較複雜，例如資料庫所允許傳遞的包的大小（max_allowed_packet），資料庫查詢逾時時間，（connect_timeout、wait_timeout）等。原始配置資料：
是以将max_allowed_packet = 1m改的大一些，例如改成max_allowed_packet = 2m。
經曆了以上幾個個操作後，發現zabbix server 不再産生zabbix agent不可到達的報警。
小總結：
（1）盡可能快速和有效地縮小問題範圍，利用靈活方法減少故障時間。
（2）能先解決問題，就不要慢慢去研究；但能慢慢解決問題，就要仔仔細細去研究。
（3）遇到小問題一定要像面對大問題一樣對待，免得小問題發展成大問題。
（4）要想快速定位問題，需要對自己的伺服器環境、整個工作環境中的每一個元件、元件與元件之間的關系都需要了如指掌。
（5）如果不是自己在維護這些服務，一定要及時與同僚做好溝通。
（6）做好問題記錄，溫故而知新，哪怕花時間寫成一篇博文也是值得的。
--end--