• Các hoạt động kiểm tra được thực hiện bởi các plugin cho máy phục vụ Nagios
và các mô đun client trên các thiết bị của người dùng cuối, Nagios chỉ định kỳ nhận
các thông tin từ các plugin và xử lý những thông tin đó (thông báo cho người quản lý,
ghi vào tệp log, hiển thi lên giao diện web ).
• Thiết kế plugin đơn giản cho phép người dùng có thể tự định nghĩa và phát triển
các plugin kiểm tra các dịch vụ theo nhu cầu riêng bằng các công cụ lập trình như shell
scripts, C/C++, Perl, Ruby, Python, PHP, C#.
• Có khả năng kiểm tra song song trạng thái hoạt động của các dịch vụ( đồng thời
kiểm tra nhiều dịch vụ).
Hỗ trợ khai báo kiến trúc mạng. Nagios không có khả năng nhật dạng được
topo của mạng. toàn bộ các thiết bị, dịch vụ muốn được giám sát đều phải khai báo và
định nghĩa trong cấu hình.
• Gửi thông báo đến người/nhóm người được chỉ định sẵn khi dịch vụ/host được
giám sát gặp vấn đề và khi chúng khôi phục hoạt động bình thường.(qua e-mail, pager,
SMS, IM )
• Khả năng định nghĩa bộ xử lý sự kiện thực thi ngay khi có sự kiện sảy ra với
host/ dịch vụ.
• Giao diện web cho phép xem trạng thái của mạng, thông báo, history, tệp log.
76 trang |
Chia sẻ: lethao | Lượt xem: 3910 | Lượt tải: 2
Bạn đang xem trước 20 trang tài liệu Đồ án Nghiên cứu triển khai hệ thống giám sát quản trị mạng (Trên nền tảng hệ thống mã nguồn mở NAGIOS), để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
host thứ 2 rồi thu thập kết quả trả về.
4.3.1. Giám sát web server
4.3.1.1. Tổng quan
Nagios sử dụng plugin check_http trong việc giám sát dịch vụ HTTP trên web
server. Check_http có thể nhận biết được các thông tin sau:
• Thời gian trả lời của web server.
• Mã lỗi trả về của dịch vụ http (403 : không tìm thấy tệp, 404: lỗi xác
thực).
• Nội dung chuỗi trả về của http có chứa chuỗi s cho trước không.
• Một URL nào đó có còn nằm trên web server hay không.
4.3.2.2. Cấu hình giám sát
Tất cả các dịch vụ đều được cung cấp bởi một host nào đó. Mọi định nghĩa dịch
vụ giám sát đều phải khai báo host cung cấp. Định nghĩa host cung cấp nếu nó chưa
được định nghĩa (định nghĩa vào một tệp cấu hình bất kì được khai báo trong tệp cấu
hình chính nagios.cfg). Ví dụ định nghĩa một host cung cấp:
define host{
use generic-host ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost ; Tên của host
alias Some Remote Host ; Tên khác của host
address 192.168.1.50 ; địa chỉ IP của host
hostgroups allhosts ; Nhóm của host
}
19
Định nghĩa một dịch vụ đơn giản cho việc giám sát dịch vụ HTTP trên máy ở xa
như sau:
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description HTTP
check_command check_http
}
Định nghĩa dịch vụ này sẽ giám sát dịch vụ HTTP chạy trên máy ở xa. Nó sẽ tạo
cảnh báo nếu web server không trả lời sau 10 giây hoặc web server trả về mã
lỗi(403,404…)
Lưu ý:
Để giám sát ở mức sâu hơn bạn có thể xem hướng dẫn check_http plugin với
tham số dòng lệnh là --help. Cú pháp --help có ở tất cả các plugin.
Dưới đây là một định nghĩa dịch vụ ở mức sâu hơn. Nó sẽ kiểm tra xem
/download/index.php URI có chứa chuỗi "latest-version.tar.gz" hay không. Thông báo
lỗi nếu không tìm thấy, URI không hợp lệ, hay là web server trả lời sau 5 giây.
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description Product Download Link
check_command check_http!-u /download/index.php
-t 5 -s "latest-version.tar.gz"
}
4.3.2. Giám sát proxy server
Từ cách thức phục vụ của một web proxy, chúng ta có thể sử dụng plugin
check_http để thực hiện việc truy vấn đến proxy yêu cầu dịch vụ và nhận kết quả trả
về.
Giám sát hoạt động bằng cách truy vấn đến proxy, yêu cầu một địa chỉ URL như
sau
nagios@linux:nagios/libexec$ ./check_http -H www.swobspace.de \
-I 192.168.1.13 -p 3128 -u
20
HTTP OK HTTP/1.0 200 OK -2553 bytes in 0.002 seconds
Trong đó –I : là tham số địa chỉ của proxy cần kiểm tra
-H tên của host cung cấp URL cần lấy
-u URL muốn lấy
Định nghĩa lệnh:
define command{
command_name check_proxy
command_line $USER1$/check_http -H www.google.de \
-u -I $HOSTADDRESS$ -p $ARG1$
}
Định nghĩa host proxy được giám sát
define service{
service_description Webproxy
host_name linux01
check_command check_proxy!3128
...
}
4.3.3. Giám sát file server
Khi bạn cần giám sát FTP server, bạn sử dụng check_ftp plugin. Tệp
commands.cfg có sẵn định nghĩa lệnh sử dụng plugin này:
define command{
command_name check_ftp
command_line $USER1$/check_ftp -H
$HOSTADDRESS$ $ARG1$
}
Dưới đây là định nghĩa dịch vụ đơn giản cho việc giám sát PTF server từ xa:
define service{
21
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description FTP
check_command check_ftp
}
Định nghĩa dịch vụ này sẽ giám sát dịch vụ PTP và tạo ra thông báo nếu server
không trả lời sau 10 giây.
Còn dưới đây là một định nghĩa dịch vụ ở mức sâu hơn. Dịch vụ sẽ kiểm tra FTP
server chạy trên cổng 1023 của host ở xa. Nó sẽ tạo ra thông báo nếu server không trả
lời sau 5 giây hoặc thông điệp server trả lời không có chuỗi "Pure-FTPd [TLS]".
define service{
use generic-service ; Inherit default values
from a template
host_name remotehost
service_description Special FTP
check_command check_ftp!-p 1023 -t 5 -e "Pure-FTPd
[TLS]"
}
4.3.4. Giám sát mail server
4.3.4.1. Giám sát dịch vụ smtp
check_smtp plugin được sử dụng để giám sát email server. Tệp commands.cfg
chứa định nghĩa lệnh sử dụng check_smtp plugin:
define command{
command_name check_smtp
command_line $USER1$/check_smtp -H
$HOSTADDRESS$ $ARG1$
}
Dưới đây là định nghĩa dịch vụ đơn giản cho việc giám sát SMTP server
define service{
22
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description SMTP
check_command check_smtp
}
Định nghĩa dịch vụ này sẽ giám sát dịch vụ SMTP server và tạo ra thông báo nếu
SMTP server không trả lời sau 10 giây.
Còn định nghĩa dưới đây sẽ kiểm tra SMTP server và tạo ra thông báo nếu server
không trả lời sau 5 giây và thông điệp trả về từ server không chứa đoạn
"mygreatmailserver.com".
define service{
use generic-service ; kế thừa giá trị mặc định
từ mẫu
host_name remotehost
service_description SMTP Response Check
check_command check_smtp!-t 5 -e
"mygreatmailserver.com"
}
4.3.4.2. Giám sát dịch vụ POP3
check_pop plugin được sử dụng để giám sát dịch vụ POP3 trên mail server . Tệp
commands.cfg chứa định nghĩa lệnh sử dụng check_pop plugin:
define command{
command_name check_pop
command_line $USER1$/check_pop -H
$HOSTADDRESS$ $ARG1$
}
Dưới đây là định nghĩa dịch vụ đơn giản cho việc giám sát dịch vụ POP3 trên
host ở xa:
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description POP3
check_command check_pop
23
}
Định nghĩa dịch vụ này sẽ giám sát dịch vụ POP3 và tạo ra thông báo nếu POP3
không trả lời sau 10 giây.
Còn định nghĩa dưới đây sẽ kiểm tra dịch vụ POP3 và tạo ra thông báo nếu server
không trả lời sau 5 giây và thông điệp trả về từ server không chứa đoạn
"mygreatmailserver.com".
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description POP3 Response Check
check_command check_pop!-t 5 -e
"mygreatmailserver.com"
}
4.3.4.3. Giám sát dịch vụ IMAP
check_imap plugin được sử dụng để giám sát dịch vụ IMAP4 trên mail server .
Tệp commands.cfg chứa định nghĩa lệnh sử dụng check_imap plugin:
define command{
command_name check_imap
command_line $USER1$/check_imap -H
$HOSTADDRESS$ $ARG1$
}
Dưới đây là định nghĩa dịch vụ đơn giản cho việc giám sát dịch vụ IMAP4 trên
host ở xa:
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description IMAP
check_command check_imap
}
Định nghĩa dịch vụ này sẽ giám sát dịch vụ IMAP4 và tạo ra thông báo nếu
IMAP4 không trả lời sau 10 giây.
24
Còn định nghĩa dưới đây sẽ kiểm tra dịch vụ IMAP4 và tạo ra thông báo nếu
server không trả lời sau 5 giây và thông điệp trả về từ server không chứa đoạn
"mygreatmailserver.com".
define service{
use generic-service ; kế thừa giá trị mặc
định từ mẫu
host_name remotehost
service_description IMAP4 Response Check
check_command check_imap!-t 5 -e
"mygreatmailserver.com"
}
Khởi động lại Nagios. Chú ý là mỗi lần bạn thêm một định nghĩa dịch vụ mới
vào tệpc cấu hình thì bạn phải kiểm chứng lại tệp đó, và khởi động lại Nagios. Nếu
quá trình kiểm chứng có lỗi thì phải cấu hình lại cho đúng đến khi không còn lỗi thì
mới khởi động lại Nagios.
4.3.5. Giám sát Các dịch vụ khác
Ngoài những dịch vụ trên Nagios còn sẵn có plugin cung cấp việc giám sát các
dịch vụ: SSH, LDAP, DHCP, DNS, database, cổng TCP, cổng UDP… Phần cài đặt và
định nghĩa các dịch vụ này có thể tham khảo ở phần phụ lục.
4.4. Cảnh báo cho người quản trị
Không phải lúc nào người quản trị cũng có thể dõi theo và nắm bắt mọi hoạt
động của mạng qua giao diện của hệ thống giám sát. Bởi vậy bất cứ hệ thống giám sát
mạng nào cũng cần cung cấp chức năng thông báo cho người quản trị qua các phương
tiện truyền tin như email, sms, IM… Nagios cung cấp một hệ thống thông báo linh
hoạt và qua nhiều phương tiện truyền tin khác nhau. Trong nagios, thông báo sảy ra
khi host/dịch vụ thay đổi từ trạng thái này sang trạng thái khác. Tuy nhiên không phải
bất cứ host/dịch vụ nào cũng có thể nhận thông báo. Thông báo trước khi đến được các
liên lạc nó phải qua nhiều bộ lọc khác nhau. Khi một sự kiện sảy ra với một host/dịch
vụ nào đó thì trước khi quyết định ra một thông báo cho người quản trị, Nagios sẽ thực
hiện kiểm tra:
- Cấu hình của Nagios có cho phép gửi thông báo hay không.(tùy chọn
enable_notifications)
- Host/dịch vụ được kiểm tra có trong thời gian được lập lịch ngừng hoạt
động không (downtime). Nếu host/dịch vụ đang trong thời gian downtime thì cách
25
hành động kiểm tra host/dịch vụ đó vẫn được thực thi. Kết quả được lưu lại trong
Nagios còn thông báo thì sẽ không được gửi đi.
- Host/dịch vụ được kiểm tra có đang bị Flapping không (nếu cấu hình bật
tùy chọn phát hiện flap). Chi tiết về tình trạng Flapping có trong chương 5.
- Từng host/dịch vụ có thể được cấu hình để chỉ thông báo cho người quản
trị một số tình trạng nhất định.
- Mỗi host/dịch vụ có thể được định nghĩa một chu kì thời gian cho thông
báo. Nếu khoảng thời gian thông báo được tạo không nằm trong giới hạn này thì thông
báo cũng bị loại.
- Thời gian từ lần thông báo trước đến thời điểm hiện tại kiểm tra đã lớn
hơn khoảng thời gian được khai báo trong tùy chọn hay chưa.
Đây là tùy chọn cấu hình khoảng thời gian giữa hai lần thông báo kề nhau.
- Cuối cùng Nagios kiểm tra cấu hình xem những người dùng Nagios nào
được nhận thông báo về tình trạng của host/dịch vụ đang được kiểm tra .
Chi tiết cấu hình gửi thông báo có trong phần phụ lục của tài liệu.
4.5. Tổng hợp báo cáo
Ngoài chức năng giám sát và cảnh báo các trạng thái hiện thời của các thành
phần mạng Nagios còn có thể lập báo cáo về tình trạng hoạt động của các thành phần
mạng trong một khoảng thời gian nhất định. Báo cáo có thể được lập với từng
host/dịch vụ, từng nhóm hoặc toàn bộ mạng với các bộ lọc trạng thái(SORT/HARD),
tình trạng(OK, WARNING, CRITICAL, UNKNOWN). Từ các số liệu trong báo cáo
người quản trị nắm được tình trạng hoạt động của các thành phần mạng trong một
khoảng thời gian nhất định, đánh giá được độ ổn định của các thành phần mạng. Việc
tổng hợp báo cáo được thực hiện khá đơn giản qua giao diện web.
26
Chương 5. Các vấn đề liên quan
5.1. Các khái niệm cơ bản trong Nagios
5.1.1. Kiểm tra host
Host được kiểm tra bởi Nagios daemon khi:
* Trong khoảng thời gian được định nghĩa trong tùy chọn check_interval
(khoảng thời gian giữa hai lần kiểm tra kế tiếp) và retry_interval (Khoảng thời gian
thực hiện kiểm tra lại để xác nhận khi phát hiện host thay đổi trạng thái) của định
nghĩa cấu hình host.
* Khi dịch vụ mà host đó cung cấp thay đổi trạng thái. Thường thì khi dịch vụ
thay đổi trạng thái thì host cũng thay đổi trạng thái. Ví dụ nếu Nagios phát hiện ra dịch
vụ HTTP thay đổi trạng thái từ CRITICAL sang OK, thì rất có thể là host cung cấp
dịch vụ này vừa khởi động lại và đang chạy.
* Khi có host con của host đó bị đặt vào trạng thái UNREARCHABLE. Đó là
trạng thái mà Nagios không liên lạc được với host đó hay có thể hiểu là mất đường
truyền đến host đó.
Nagios phân loại host ra ba trạng thái:
* UP : hoạt động bình thường.
* DOWN: tạm dừng hoạt động.
* UNREACHABLE: không tìm thấy.
5.1.2. Kiểm tra dịch vụ
Dịch vụ được kiểm tra bởi Nagios daemon khi:
* Trong khoảng thời gian được định nghĩa trong tùy chọn check_interval
(khoảng thời gian giữa hai lần kiểm tra kế tiếp) và retry_interval (Khoảng thời gian
thực hiện kiểm tra lại để xác nhận khi phát hiện dịch vụ thay đổi trạng thái) của định
nghĩa cấu hình dịch vụ.
Nagios phân loại dịch vụ thành bốn trạng thái:
•OK: Hoạt động bình thường.
•WARNING: Có thể hoạt động nhưng chưa chính xác hoặc có thể không hoạt
động.
•UNKNOWN: Không xác định được.
•CRITICAL: Không hoạt động.
5.1.3. Khái niệm trạng thái SORT/HARD
Ví dụ ta có một định nghĩa kiểm tra dịch vụ DNS như sau
define service{
host_name proxy
27
service_description DNS
...
normal_check_interval 5
retry_check_interval 1
max_check_attempts 5
...
}
Trong đó
normal_check_interval: khoảng thời gian giữa các lần kiểm tra bình thường(là 5
phút).
retry_check_interval: nếu gặp lỗi, sau 1 phút kiểm tra lại để xác nhận (soft state).
max_check_attempts: thực hiện kiểm tra lại 5 lần, nếu lỗi vẫn sảy ra. Nagios kết
luận chắc chắn dịch vụ thay đổi trạng thái (hard state).
- Vậy khi Nagios chắc chắn về trạng thái của một host/dịch vụ thì nó đặt là
HARD STATE. Thông thường khi bắt đầu phát hiện host/dịch vụ thay đổi trạng thái
Nagios thực hiện lại vài lần kiểm tra để xác nhận, tùy vào cấu hình. Trong khoảng thời
gian đó host/dịch vụ được đặt là SOFT STATE. Khi host/dịch vụ được đặt vào tình
trạng SOFT STATE hoặc khi nó khôi phục lại trạng thái cũ từ tình trạng SOFT
STATE thì không có bất cứ thông báo nào được gửi. Tuy nhiên những sự kiện này vẫn
được ghi vào tệp log và có thể xem được qua giao diện chương trình.
5.1.4. Khái niệm FLAP
Nếu trạng thái của host/ dịch vụ không ổn định, thay đổi liên tục. Người quản trị
sẽ nhận được rất nhiều thông báo trong một khoảng thời gian ngắn. Nó không chỉ gây
khó chịu mà còn làm rối loạn việc xác định vấn đề lỗi. Nagios có thể phát hiện vấn đề
này và đặt trạng thái đó là flapping.
Để phát hiện tình trạng flap của một dịch vụ, Nagios lưu lại 21 kết quả kiểm tra
dịch vụ gần nhất, tức là tối đa lưu lại 20 lần thay đổi trạng thái của dịch vụ. Hình dưới
đây mô tả sự thay đổi trạng thái của một dịch vụ:
28
Từ hình trên ta có thể thấy là trong 20 lần kiểm tra, dịch vụ thay đổi trạng thái 12
lần. Nagios dựa vào số liệu này để thông báo dịch vụ đang rơi vào tình trạng flapping
hoặc thoát khởi tình trạng flapping. Khi flapping sảy ra, Nagios sẽ ghi sự kiện này vào
tệp log, đặt thông tin flap vào phần comment của dịch vụ và dừng hành động thông
báo trạng thái dịch vụ.
Phát hiện flap được cấu hình ở 2 vị trí; tệp cấu hình chính nagios.cfg (cài đặt cấu
hình nói chung) và trong định nghĩa của từng dịch vụ cụ thể.
Trong tệp cấu hình chính:
#/etc/nagios/nagios.cfg
...
enable_flap_detection=1 // cho phép phát hiện flap.
low_service_flap_threshold=5.0 //ngưỡng dưới flap
high_service_flap_threshold=20.0 //ngưỡng trên flap
...
Đoạn cấu hình trên có nghĩa là nếu có từ 5 lần trở lên dịch vụ được ghi nhận là
thay đổi trong 20 lần kiểm tra thì dịch vụ đó được đặt vào tình trạng flapping.
Chúng ta có thể thiết đặt tùy chọn phát hiện flapping và đặt ngưỡng flap cho từng
dịch vụ trong phần định nghĩa đối tượng dịch vụ.
define service{
host_name linux01
…
flap_detection_enabled 1
low_flap_threshold 6.0
high_flap_threshold 20.0
...
}
Tương tự phát hiện flapping đối với host.
29
5.1.5. Mối quan hệ cha/con giữa các host và phân biệt trạng thái
down/unrearchable
Nagios là phần mềm chưa có khả năng tự phát hiện ra các node và kiến trúc của
mạng. Công việc này do người dùng tự định nghĩa và quyết định theo quy tắc nhất
định. Nagios được coi là trung tâm giám sát. Các thiết bị(A) có đường kết nối vật lý
trực tiếp đến server Nagios được có mối quan hệ là con của Nagios. Các thiết bị kết
nối trực tiếp đến A được coi là con của A.. Cứ như vậy kiến trúc mạng được định
nghĩa và mở rộng qua mối quan hệ cha/con này, với Nagios là trung tâm.
Hình 5.1 Mối quan hệ host cha/con.
Ví dụ mạng có kiến trúc như trên. Khi đó ta có Switch1 được coi là con của
Nagios. Web, FTP, Router1 là con của Switch1, Switch2 được coi là con của Router1
… Tất cả mối quan hệ này đều phải do người dùng định nghĩa qua tùy chọn parents
trong mỗi định nghĩa đối tượng. ví dụ:
define host{
host_name
…
30
}define host{
host_name Switch1
…
parents Nagios
}
define host{
host_name Web
…
parents Switch1
}
Như ví dụ hình bên dưới, ta tắt host web và router1. Một hành động kiểm tra
được thực hiện và trả về kết quả cho Nagios. Trường hợp này Nagios kết luận host
web và router1 ở trạng thái DOWN bởi vì host cha Switch1 hoạt động bình thường.
Trong khi đó các host nằm sau router1 được kết luận là UNREACHABLE<Không xác
định>. Vì Nagios không thể liên lạc được với chúng vì router1 bị tắt kéo theo mất
đường kết nối đến các host này.
31
Hình 5.2 Phân biệt DOWN-UNREACHABLE.
Việc phân biệt trạng thái DOWN-UNREACHABLE của host giúp các nhà quản
trị dễ dàng hơn trong việc xác định được nguyên nhân và vị trí của lỗi sảy ra trên mạng
khi nhận được thông báo sự cố. Ta xét một ví dụ như sau: Khi giám sát dịch vụ DNS
trên một mạng được định nghĩa như hình 5.2. Giả sử tình huống khi Nagios phát hiện
DNS không trả lời truy vấn của nó. Nó thực hiện kiểm tra host cung cấp dịch vụ DNS(
ở đây là proxy). Proxy không trả lời. Host cha của proxy là switch2 được kiểm tra.
Switch2 không trả lời. Host cha của Switch2 là switch1 được kiểm tra. Switch1 trả lời.
Từ đó Nagios kết luận Switch1 UP. Con của nó là switch2 DOWN. Con của switch bị
DOWN là UNREARCHABLE. DNS không hoạt động : CRITICAL. Kết luận như
hình 5.3
32
Router1
down kéo
theo các host
con của nó
mất liên lạc
với phần còn
lại của mạng
Hình 5.3 Ví dụ Xác định lỗi 1.
Hình 5.4 Ví dụ xác định lỗi 2.
Vậy trong trường hợp này khi khắc phục sự cố DNS, người quản trị đã xác định
được ngay nguyên nhân đầu tiên dẫn đến sự cố là do switch2 bị DOWN.
33
5.1.6. Lập lịch downtime
Có những thiết bị chỉ hoạt động vào những khoảng thời gian nhất định trong
ngày và ngoài khoảng thời gian đó nó được tắt đi. Hành động tắt bật được thực hiện có
tính chu kỳ và thường xuyên. Ví dụ như thiết bị văn phòng, máy in … Hoặc có những
server cần dừng hoạt động, nâng cấp, sửa chữa. Tóm lại là trong thực tế có nhiều
trường hợp trạng thái của thiết bị mạng thay đổi do sự chủ động từ phía người quản trị
hoặc người quản trị có thể kiểm soát được. Với những trường hợp này việc gửi cảnh
báo cho người quản trị là không cần thiết. Vì thế Nagios cho phép người quản trị lập
lịch thời gian ngừng kiểm tra cho từng host/dịch vụ. Khoảng thời gian này được gọi là
downtime. Trong khoảng thời gian này không có bất cứ thông báo nào của host/dịch
vụ được lập lịch được gửi đi. Việc lập lịch downtime cho host/dịch vụ khá đơn giản và
được thực hiện ngay trên giao diện web của chương trình.
5.2. Bộ xử lý sự kiện
Khi trạng thái của host/dịch vụ thay đổi, nagios có thể chạy một chương trình bất
kì được định sẵn với bộ xử lý sự kiện (event handler) để xử lý tình huống mà không
cần sự can thiệp của người quản trị.
5.2.1. Thời gian chạy bộ xử lý sự kiện
Khi host/dịch vụ :
•ở trong trạng thái mềm
•bắt đầu vào trạng thái cứng
•Bắt đầu khôi phục lại bình thường từ trạng lỗi(mềm hoặc cứng)
5.2.2. Ví dụ event handler
Ví dụ định nghĩa một script khởi động lại máy in khi máy in bắt đầu rơi vào trạng
thái lỗi và kiểm tra lại đến lần thứ 3 tình trạng lỗi vẫn sảy ra.
Sửa định nghĩa dịch vụ giám sát máy in, khai báo lệnh xử lý sự kiện restart-lpd
define service{
host_name printserver
service_description LPD
...
event_handler restart-lpd
34
...
}
Định nghĩa trong tệp lệnh lệnh restart-lpd:
define command{
command_name restart-lpd
command_line $USER1$/eventhandler/restart-lpd.sh \
$SERVICESTATE$ $SERVICESTATETYPE$
$SERVICEATTEMPT$
}
Lệnh này sẽ gọi một script có tên là restart-lpd.sh đặt trong thư mục
/usr/local/nagios/libexec/eventhandler (thông thường các script được đặt trong thư mục
/usr/local/nagios/libexec/). Script này nhận 3 macro làm tham số đó là trạng thái hiện
thời của dịch vụ $SERVICESTATE$ (OK,WARNING, CRITICAL, hoặc
UNKNOWN), loại trạng thái $SERVICESTATETYPE$ (mềm hoặc cứng), và số lần
kiểm tra lại hiện thời $SERVICEATTEMPT$ ). Đối với host thì các macro này là
$HOSTSTATE$, $HOSTSTATETYPE$, và $HOSTATTEMPT$.
2.3. Script xử lý
#!/bin/bash
#/usr/local/nagios/libexec/eventhandlers/restart-lpd.sh
#$1= Status, $2 =status type, $3 =attempt
case $1 in
OK)
;;
WARNING)
;;
CRITICAL)
if [$2=="HARD" ]||[[$2=="SOFT" && $3 -eq 3]]; then
echo "Restarting lpd service"
/usr/bin/sudo /etc/init.d/lpd restart
35
fi
;;
UNKNOWN)
;;
esac
exit 0
Với script này nếu trạng thái dịch vụ là critical, loại trạng thái là HARD hoặc loại
trạng thái là SOFT và đã kiểm tra lại đến lần thứ 3 thì dịch vụ lpd được gọi với tham
số là restart. Script này được thực thi với quyền của người dùng Nagios (có thể không
có quyền tạm dừng hoặc khởi động lại dịch vụ hệ thống). Vì vậy phải sử dụng lệnh
sudo để dùng quyền root khởi động lại dịch vụ lpd.
Nếu như bạn muốn người dùng nagios có quyền với dịch vụ lpd thì thực hiện như
sau:
linux:˜ # visudo
Thêm dòng sau và tệp cấu hình
nagios nagsrv=(root)NOPASSWD: /etc/init.d/lpd
Dòng này cho phép người dùng nagios có quyền chạy lệnh /etc/init.d/lpd trên
host nagsrv và không cần mật khẩu.
Nếu bạn khởi động lại dịch vụ khi nó đang ở trạng thái mềm thì người quản trị sẽ
không nhận được bất kì thông báo nào. Tuy nhiên sự kiện vẫn được ghi lại vào tệp log.
5.3. Giám sát phân tán
5.3.1. Kiểm tra chủ động
Khi Nagios cần kiểm tra trạng thái của host/dịch vụ nó gọi một plugin thực hiện
hành động kiểm tra đó. Nagios sẽ nhận kết quả từ plugin được gọi. Đây là cách thức
kiểm tra cơ bản của Nagios. Trong trường hợp này Nagios quyết định khi nào hành
động kiểm tra được thực hiện. Kiểm tra chủ động là phương thức kiểm tra cơ bản và
được sử dụng nhiều. Tuy nhiên nó vẫn còn có một số nhược điểm ví dụ như nó có thời
gian timeout của mỗi hành động kiểm tra là được định trước. Trong một số trường hợp
thời gian đó có thể không đủ để có kết quả chính xác.
36
5.5 Kiểm tra chủ động
5.3.2. Kiểm tra bị động
Hành động kiểm tra host/dịch vụ được thực hiện bởi một ứng dụng/tiến trình bên
ngoài. Kết quả kiểm tra sẽ được gửi về cho Nagios xử lý.
Kiểm tra bị động được dùng khi giám sát ở các vùng mạng khác nhau có tường
lửa ngăn cách, dùng trong giám sát phân tán…
Cách thức kiểm tra bị động: Một ứng dụng bên ngoài thực hiện hành động kiểm
tra host/dịch vụ. Kết quả đó được ghi ra tệp lệnh ngoại trú. Nagios định kỳ lấy kết quả
kiểm tra từ tệp này và xử lý.
37
Hình 5.6 Kiểm tra bị động
5.3.3. Giám sát phân tán
Nagios có thể phân tán việc giám sát trên những mạng lớn bằng cách sử dụng
một server trung tâm và nhiều server con phân tán trên các mạng con(mạng con ở đây
có thể là một mạng WAN, các vùng mạng ngăn cách bởi tường lửa…). Nagios gọi mỗi
mạng con này là một “cluster”.
Server trung tâm: nhận và xử lý kết quả kiểm tra từ server con phân tán (passive
check), các kết quả tự nó kiểm tra qua plugin (active check).
Server con phân tán: thực hiện các kiểm tra chủ động (active check) host/dịch vụ
và gửi kết quả về cho server trung tâm. Thường thì với mỗi cluster nên đặt một server
con Nagios.
Server con gửi kết quả kiểm tra về server trung tâm bằng một plugin có tên
NSCA. Chi tiết cách thức cài đặt, giao tiếp của NSCA tham khảo phần phụ lục cuối tài
liệu
38
CHƯƠNG 6. KẾT QUẢ TRIỂN KHAI THỰC TẾ TRÊN
MẠNG CỦA TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
6.1 Giới thiệu hệ thống mạng của trường ĐH công
nghệ(CTnet)
Trường Đại học Công nghệ hiện có 19 khối/đơn vị bao gồm các phòng ban, các
khoa, các trung tâm, phòng thí nghiệm, phòng thực hành… Tất cả các đơn vị của
trường đều được trang bị đều được trang bị các hệ thống máy tính phục vụ công tác
điều hành, quản lý, học tập, giảng dạy và nghiên cứu.
Hình 6.1 : Sơ đồ hệ thống mạng CTnet
Ngoài các hệ thống phòng máy phục vụ điều hành, học tập, giảng dạy và nghiên
cứu thì trường cũng đang duy trì một số server và dịch vụ hệ thống:
- Server Web, 1 CPU P.4, 1 GB RAM, 2 ổ cứng 36 GB (từ phòng HCQT)
- Server quản lý người dùng, 1 CPU P.4, 1 GB RAM, 1 ổ cứng 36 GB
- Server phục vụ tệp, 1 CPU P.4, 512 MB RAM, 3 ổ cứng 36 GB
- Server phục vụ các tiện ích, 1 CPU P.4, 512 MB RAM, 1 ổ cứng 36 GB )
- Server mail, cung cấp dịch vụ thư điện tử cho cán bô, sinh viên trong trường.
- Các server hỗ trợ dns, proxy…
Mạng CTnet là một mạng có quy mô và cần phải có sự quản lý chặc chẽ.
39
Switch
Các phòng làm việc
và phòng máy tính trong
tòa nhà E3
Các phòng làm việc
và phòng máy tính
trong tòa nhà E4
Các phòng làm việc
và phòng máy tính
trong tòa nhà G2
Internet
VNUnet Router
Các trường
Thành viên và
các đơn vị trực
thuộc ĐHQG
Phần mạng Trường ĐHCN
6.2. Cài đặt triển khai
Hệ thống Nagios bắt đầu được cài đặt và giám sát những dịch vụ đầu tiên vào
ngày 27/03/2009 trên server có địa chỉ mạng nội bộ là 10.10.0.22 và địa chỉ Internet là
210.86.230.113. Địa chỉ truy cập vào hệ thống là Với mục
đích thử nghiệm việc phân giám sát lên ngoài server này hệ thống còn cài đặt một
server Nagios khác tại tại trung tâm máy tính nhà G2. Server này giám sát các thiết bị,
máy đầu cuối của trung tâm máy tính và gửi kết quả về cho server trung tâm tại đặt tại
10.10.0.22.
Đến nay hệ thống đã được cấu hình giám sát hầu hết tất cả các dịch vụ của cụm
máy chủ của trường đại học công nghệ như web,
Các file đính kèm theo tài liệu này:
- 56462218-NGHIEN-CỨU-TRIỂN-KHAI-HỆ-THỐNG-GIAM-SAT-QUẢN-TRỊ-MẠNG-TREN-NỀN-TẢNG-HỆ-THỐNG-MA-NGUỒN-MỞ-NAGIOS.pdf