ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN VĂN CƯỜNG

GIẢI PHÁP NỀN TẢNG CHO HỆ THỐNG
TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG NHẤT

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

Hà Nội - 2015


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN VĂN CƯỜNG

GIẢI PHÁP NỀN TẢNG CHO HỆ THỐNG
TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG NHẤT
Ngành: Công nghệ Thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60 48 01 03

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC
TS. NGUYỄN VĂN NAM

Hà Nội - 2015

LỜI CAM ĐOAN
Tôi xin cam đoan luận văn được hoàn thành trên cơ sở nghiên cứu, tổng hợp và
phát triển các nghiên cứu về các giải pháp tốt nhất về quy trình xử lý tích hợp dữ
liệu hiện có.
Luận văn này là mới, các đề xuất trong luận văn do chính tôi thực hiện, qua
quá trình nghiên cứu đưa ra và không sao chép nguyên bản từ bất kỳ một nguồn tài
liệu nào khác.

Hà Nội, ngày

tháng

năm 2015

Học viên

Trần Văn Cường


LỜI CẢM ƠN
Lời đầu tiên tôi xin gửi lời cảm ơn chân thành và biết ơn sâu sắc tới TS. Nguyễn
Văn Nam, người thầy đã chỉ bảo và hướng dẫn tận tình cho tôi trong suốt quá trình
nghiên cứu khoa học và thực hiện luận văn này.
Tôi xin chân thành cảm ơn sự giúp đỡ và góp ý rất nhiệt tình của các
Anh/Chị/Em trong trung tâm phần mềm FIS-Bank thuộc công ty Hệ thống thông tin
FPT đã tạo mọi điều kiện thuận lợi cho tôi trong thời gian hoàn thành các môn học
cũng như trong suốt quá trình làm luận văn tốt nghiệp.
Và cuối cùng, tôi xin gửi lời cảm ơn tới gia đình, người thân và bạn bè – Những
người luôn ở bên tôi những lúc khó khăn nhất, luôn động viên khuyến khích tôi trong

cuộc sống và trong công việc.


MỤC LỤC
LỜI CAM ĐOAN....................................................................................................... .
LỜI CẢM ƠN ............................................................................................................ .
MỤC LỤC .................................................................................................................. .
DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ................................................ .
DANH MỤC CÁC HÌNH VẼ.................................................................................... .
MỞ ĐẦU ................................................................................................................... 1
CHƯƠNG 1: SỰ CẦN THIẾT PHẢI XỬ LÝ TÍCH HỢP DỮ LIỆU TẬP TRUNG
................................................................................................................................... 4
1.1 Tổng quan về dữ liệu lớn và không đồng nhất ............................................... 4
1.1.1 Log - dữ liệu không đồng nhất .................................................................. 5
1.1.2 Các cấp độ của log [2][3] ............................................................................. 6
1.1.3 Chi tiết về Log File [1][4][5] ......................................................................... 7
1.1.4 Tại sao phân tích dữ liệu log ..................................................................... 9
1.2 Khó khăn của việc thực hiện hệ thống tích hợp dữ liệu không đồng nhất ... 11
1.3 Khó khăn khi thực hiện xử lý tích hợp dữ liệu thời gian thực ..................... 12
1.4 Kết luận ......................................................................................................... 13
CHƯƠNG 2: HỆ THỐNG TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG
NHẤT LÀ GÌ? ........................................................................................................ 13
2.1 User Case ...................................................................................................... 13
2.2 Thực hiện quản lý tích hợp dữ liệu tập trung ............................................... 14
2.2.1 Vòng đời xử lý của hệ thống tích hợp và không đồng nhất [1][11] ........... 14
2.2.2 Chi tiết bộ thu thập dữ liệu Shipper ........................................................ 16
2.2.3 Chi tiết về hàng đợi ................................................................................. 18
2.2.4 Chi tiết về bộ phân giải dữ liệu Parser .................................................... 19
2.2.5 Chi tiết về Database ................................................................................ 20
2.2.6 Chi tiết về Client ..................................................................................... 22

2.3 Nền tảng từ các hệ thống hiện có.................................................................. 23
2.3.1 Hệ thống Hadoop [12] ............................................................................... 23


2.3.2 Hệ thống Splunk [13] ................................................................................ 24
2.3.3 Hệ thống ELK [14] .................................................................................... 26
2.4 Các vấn đề tiếp cận ....................................................................................... 30
2.4.1 Đọc dữ liệu log mới sinh ra..................................................................... 30
2.4.2 Đọc dữ liệu từ file lớn ............................................................................. 32
2.4.3 Các mô hình nghiên cứu ......................................................................... 33
2.4.4 Lưu trữ dữ liệu và chỉ số index [14] .......................................................... 37
2.4.5 Filter – Format – Tag [18] ......................................................................... 39
2.4.6 Vấn đề xếp hàng đợi Queue [14][16] .......................................................... 43
2.4.7 Vận chuyển dữ liệu tới server tập trung[20] ............................................. 47
2.5 Kết luận ......................................................................................................... 50
CHƯƠNG 3: ĐỀ XUẤT eLMS – HỆ THỐNG TÍCH HỢP GỌN NHẸ, THỜI
GIAN THỰC ........................................................................................................... 51
3.1 Xây dựng giải pháp ....................................................................................... 51
3.1.1 eLMS đa luồng ........................................................................................ 51
3.1.2 eLMS đơn luồng ..................................................................................... 58
3.2 Triển khai mô hình cơ sở eLMS ................................................................... 59
3.3 Thực nghiệm ................................................................................................. 60
3.4 Kết luận ......................................................................................................... 63
3.5 Các công việc tiếp theo ................................................................................. 63
KẾT LUẬN ............................................................................................................. 65
TÀI LIỆU THAM KHẢO ....................................................................................... 66


DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT


Tên viết tắt

Diễn giải

DB

Cơ sở dữ liệu

ELK

Hệ thống Elasticsearch – Logstash - Kibana

eLMS

Hệ thống xây dựng (Efficient Log Management System)

Tag

Gán nhãn dữ liệu

ES

Elasticsearch


DANH MỤC CÁC HÌNH VẼ

HÌNH 1.1 GHI DỮ LIỆU LOG MỚI SINH RA
HÌNH 1.2 KIẾN TRÚC XỬ LÝ DỮ LIỆU THỜI GIAN THỰC
HÌNH 2.1 VÒNG ĐỜI XỬ LÝ CỦA HỆ THỐNG TÍCH HỢP VÀ KHÔNG ĐỒNG

NHẤT
HÌNH 2.2 KIẾN TRÚC HADOOP
HÌNH 2.3 KIẾN TRÚC SPLUNK
HÌNH 2.4 SƠ ĐỒ LƯU TRỮ VÀ ĐÁNH CHỈ MỤC INDEX CỦA SPLUNK
HÌNH 2.5 KIẾN TRÚC ELK
HÌNH 2.6 GIẢI PHÁP ELMS
HÌNH 2.7 MÔ HÌNH XỬ LÝ DỮ LIỆU CƠ BẢN NHẤT
HÌNH 2.8 KIẾN TRÚC TRIỂN KHAI 2 SERVER VỚI ELK
HÌNH 2.9 KIẾN TRÚC LOẠI BỎ HÀNG ĐỢI REDIS
HÌNH 2.11 MÔ HÌNH XỬ LÝ DỮ LIỆU LỊCH SỬ
HÌNH 2.12 MÔ HÌNH TIẾP CẬN
HÌNH 2.13 GÁN CHỈ SỐ INDEX THEO NGÀY
HÌNH 2.14 GÁN CHỈ SỐ INDEX THEO PHÂN LOẠI CATEGORY
HÌNH 2.15 MÔ HÌNH XỬ LÝ PARSER CỦA ELK
HÌNH 2.16 THƯ VIỆN REGEX SỬ DỤNG TRONG LOGSTASH (GROK)
HÌNH 2.17 KIẾN TRÚC ELK
HÌNH 2.18 KIẾN TRÚC ELK VỚI 2 HÀNG ĐỢI
HÌNH 2.19 KIẾN TRÚC CỦA SEMATEXT
HÌNH 2.20 HIỆU NĂNG SỬ DỤNG HÀNG ĐỢI
HÌNH 2.21 VẬN CHUYỂN DỮ LIỆU TỚI PARSER
HÌNH 2.22 CƠ CHẾ HOẠT ĐỘNG CỦA BATCH JOB
HÌNH 2.23 SƠ ĐỒ MICRO BATCH JOB THỰC HIỆN TẠO DÒNG DỮ LIỆU
HÌNH 2.24 VÍ DỤ VỀ MỘT DÒNG DỮ LIỆU ĐƯỢC TẠO RA
HÌNH 2.25 SƠ ĐỒ HOẠT ĐỘNG CỦA STREAM
HÌNH 3.1 MÔ HÌNH ELMS ĐA LUỒNG
HÌNH 3.2 XỬ LÝ VÒNG TRÒN

7
12
15

26
27
28
29
30
35
36
37
38
39
39
41
43
44
46
48
49
49
50
53
53
53
54
55
57


HÌNH 3.3 LƯU TRỮ CỦA MỘT MESSAGE CYCLE
HÌNH 3.4 QUAY VÒNG CÁC PHÂN VÙNG LƯU TRỮ DỮ LIỆU
HÌNH 3.5 HÀNG ĐỢI QUEUE

HÌNH 3.6 MESSAGE CYCLE
HÌNH 3.7 MÔ HÌNH ELMS ĐƠN LUỒNG
HÌNH 3.8 ELMS VỚI CÁC THÀNH PHẦN PLUG-IN
HÌNH 3.9 SƠ ĐỒ THỰC NGHIỆM
HÌNH 3.10 THÔNG SỐ KẾT QUẢ
HÌNH 3.11 BIỂU ĐỒ THỜI GIAN SO SÁNH

57
58
58
58
63
64
66
67
67


1

MỞ ĐẦU

1. Đặt vấn đề
Ngày nay, việc thực hiện giám sát các máy chủ server là một hành động thực
sự cần thiết và quan trọng, có thể giúp cho các quản trị hệ thống theo dõi các hoạt
động của người sử dụng nhằm cải thiện khả năng quản lý hệ thống, quản lý người
dùng, quản lý các vấn đề về cân bằng tải cũng như để phát hiện ra các cuộc tấn công
DDoS. Thông thường, việc giám sát, theo dõi các máy chủ server dựa vào nhật ký
file dữ liệu ghi lại. Tuy nhiên, hệ thống quản lý dữ liệu luôn được coi là và đắt đỏ
cho việc thu thập, tích hợp, lưu trữ, tìm kiếm và phân tích dữ liệu.

Trong luận văn này sẽ trình bày các phương pháp xây dựng một hệ thống quản
lý và tích hợp dữ liệu tập trung với hiệu suất tối ưu, viết tắt là eLMS (Efficient Log
Management System) – Một hệ thống có kiến trúc được thiết kế nhẹ nhàng, mềm dẻo
và có khả năng mở rộng. Trong eLMS, các file dữ liệu có thể được thu thập từ nhiều
nguồn từ nhiều server khác nhau. Lưu trữ trong một mô hình có khả năng kết hợp
thêm nhiều Plug-in, tích hợp việc lập chỉ mục index và có thể phân tích dữ liệu nhanh
chóng. Hệ thống eLMS hoạt động trên cả chế độ online và offline, cung cấp một giao
diện hiển thị các thông số giám sát, thống kê dựa trên dữ liệu thời gian thực. Hiệu
suất của eLMS được đánh giá tổng thể ở một vài trường hợp nghiên cứu.
Cơ sở khoa học và thực tiễn của luận văn dựa trên các vấn đề về tích hợp và
xử lý các dữ liệu không đồng nhất – Log, xml, meta-data hoặc các dữ liệu tương tự.
Để tổng quát kiểu dữ liệu như vậy luận văn chỉ đề cập tới các vấn đề xử lý tích hợp
dữ liệu log tập trung.
Log cũng được coi như là dữ liệu lớn bởi vì kích thước thường xuyên tăng
trưởng theo thời gian. Việc quản lý log cũng là một ứng dụng xử lý dữ liệu lớn mà
chúng ta thường hay biết đến với nền tảng Hadoop. Tuy nhiên, Hadoop chủ yếu hỗ
trợ các hệ thống có quy mô rất lớn như Google, Yahoo, ... Đối với hệ thống cỡ vừa
và nhỏ, Hadoop trở nên cồng kềnh, đắt đỏ, không thực tế để thực hiện. Hơn nữa, Nó
cũng không đủ nhanh cho việc dữ lý dữ liệu online. Luận văn hướng đến xây dựng
một hệ thống quản lý tích hợp nhẹ hơn và xử lý thời gian thực để việc sử dụng có ích


2

cho cho các tổ chức, các công ty vừa và nhỏ nhưng lại chiếm đa số. Cũng có thể sử
dụng ở mô hình lớn hơn với việc mở rộng ở tương lai. Hệ thống quản lý log eLMS
được dựa trên 3 thành phần mã nguồn mở: Logstash, Elasticsearch và Kibana thuộc
trên nền tảng công nghệ Elastic. Logstash được sử dụng để vận chuyển và cấu trúc
lại nội dung dữ liệu. Elasticsearch có trách nhiệm đánh chỉ mục index, cung cấp khả
năng tìm kiếm full-text search. Kibana cung cấp một giao diện web để phân tích và

hiển thị nội dung kết quả. Kể từ khi Elastic đưa dự án thành mã nguồn mở, các thành
phần không còn được hoạt động trơn tru, vẫn có nhiều sai sót và tiềm tàng nhiều lỗi
phát sinh. Một khi gặp các vấn đề về lỗi chúng ta phải trả chi phí để nhận được sự
giúp đỡ từ đội phát triển cũng như chi phí thuê chuyên gia. Và bởi vì là mã nguồn
mở nên rất khó có thể triển khai hệ thống ở môi trường production.
Những đóng góp và nghiên cứu trong luận văn này là để xây dựng hệ thống
eLMS kế thừa một vài thành phần từ nền tảng Elastic, tối ưu hóa và phát triển hệ
thống theo những đề xuất riêng của bản thân dựa vào những nghiên cứu trong thời
gian qua.
Để thực hiện xây dựng hệ thống eLMS, luận văn trình bày từng bước tối ưu
hóa nền tảng từ Elastic. Đầu tiên là việc đơn giản hóa việc xếp hàng đợi dữ liệu giúp
cho hệ thống giảm thiểu việc tiêu thụ nguồn tài nguyên của máy tính như CPU và
RAM. Thứ hai, đề xuất một số kỹ thuật đọc log ở từng máy server riêng lẻ. Thứ ba,
đề cập tới vấn đề thay đổi kiến trúc và các chiến lược đánh index dữ liệu ở trong DB.
Thứ tư, cải thiện cơ chế trích lọc, định dạng cấu trúc và thực hiện tag dữ liệu. Do
vậy, hệ thống eLMS xây dựng bằng các giải pháp tốt nhất cho từng giai đoạn xử lý
dữ liệu của hệ thống.
Luận văn dựa trên cơ sở khoa học và thực tiễn của đề tài “Giải pháp nền tảng
cho hệ thống tích hợp dữ liệu lớn và không đồng nhất” .
2. Bố cục luận văn
Luận văn chia làm 3 chương:
Chương 1: Sự cần thiết phải xử lý tích hợp dữ liệu không đồng nhất
Chương này sẽ giải thích các khuôn dạng dữ liệu, nêu nên tầm quan trọng và
khó khăn của việc tích hợp dữ liệu tập trung.


3

Chương 2: Hệ thống tích hợp dữ liệu lớn và không đồng nhất là gì?.
Chương này trình bày tổng quan về các trường hợp use-case của hệ thống. Nêu

lên chi tiết các xử lý của từng thành phần trong sơ đồ vòng đời hệ thống tích hợp dữ
liệu lớn và không đồng nhất. Tiếp cận các hệ thống hiện có và đưa ra một số phương
pháp tiếp cận để xây dựng hệ thống eLMS.
Chương 3: Đề xuất eLMS – Hệ thống tích hợp gọn nhẹ, thời gian thực.
Chương này đưa ra mô hình kiến trúc cho hệ thống xử lý dữ liệu tập trung, trình
bày chi tiết các thành phần trong kiến trúc và thực hiện đánh giá mô hình.
Đồng thời đưa gia biểu đồ so sánh thời gian xử lý của hệ thống eLMS với hệ
thống Elastic ở một vài trường hợp nghiên cứu.


4

CHƯƠNG 1: SỰ CẦN THIẾT PHẢI XỬ LÝ TÍCH HỢP DỮ LIỆU TẬP
TRUNG
1.1 Tổng quan về dữ liệu lớn và không đồng nhất
Dữ liệu đến từ nhiều nguồn khác nhau và định dạng dữ liệu khác nhau.
 Các nguồn dữ liệu lớn (big data) là “lớn” về:
Kích cỡ không xác định: Dữ liệu được tích lũy hàng ngày, hàng giờ,
và tăng trưởng theo thời gian.
Sự đa dạng: Có thể xuất phát là từ các trạm quan sát, trên mạng
internet, ở các hệ thống dữ liệu,…
Tốc độ khác nhau: Có dữ liệu tĩnh (dưới dạng các file), dữ liệu động
(streaming),…
 Dữ liệu không đồng nhất:
Khác nhau về khuôn dạng: XML, metadata, weblog, ….
Khác nhau về nội dung: Có thể là weblog, syslog, window log,
database, ….
Lý do là các nguồn dữ liệu khác nhau, định dạng khác nhau và cấu trúc khác
nhau như vậy, cho nên giữa chúng không có bản ghi chung. Việc tham chiếu từ dữ
liệu nguồn này tới dữ liệu nguồn kia hầu như là thủ công và không thể thực hiện khi

khối lượng dữ liệu quá lớn. Ngay cả khi chúng cùng định dạng, cùng nguồn, cùng
cấu trúc nhưng bị khuyết thiếu một vài trường dữ liệu. Vì thế nên việc tích hợp các
dữ liệu trên nhằm đưa về một cấu trúc chuẩn chung là một bài toán khó nhưng rất
cần thiết. Khi dữ liệu là một khối tích hợp, nó phục vụ trực tiếp cho việc truy vấn dữ
liệu từ một trường bản ghi này có thể tham chiếu sẵn tới các dữ liệu xung quanh nó
đang chỉ định tới vấn đề liên quan, đưa tới một kết luận, báo cáo đầy đủ hơn.
Có rất nhiều loại dữ liệu lớn và không đồng nhất như vậy. Luận văn không thể
đề cập tới việc xử lý hết tất cả các loại dữ liệu mà chỉ lấy một vài thể loại dữ liệu
không đồng nhất trình bày đặc trưng. Nhưng với hệ thống eLMS mà luận văn đề cập
tới cũng sẽ dễ dàng mở rộng các loại plugin dành riêng cho mỗi loại dữ liệu không
đồng nhất và khác định dạng tương tự gặp phải trong tương lai.


5

Các dữ liệu lớn và không đồng nhất điển hình như sau:
File and directories: Là các file dữ liệu hoặc các thư mục chứa các file dữ liệu
như: file log sinh ra theo thời gian, file dữ liệu kết xuất từ database, các file xml...
Các thư mục này có thể chứa nhiều loại file dữ khác nhau như: File log error, file
xml transaction, file database csv…
Network Events: Là các file dữ liệu sinh ra bởi các webserver, các router,
firewall và các ứng dụng của an toàn thông tin.
Window sources: Là các file dữ liệu sinh ra bởi các ứng dụng trên hệ điều hành
window.
Other sources: Có rất nhiều nguồn dữ liệu khác nhau, mỗi nền tảng, mỗi ứng
dụng đều sinh ra các kiểu dữ liệu khác nhau. Dữ liệu có thể là file, xml, meta-data,
các file log đã mã hóa…
Để cụ thể về một loại dữ liệu không đồng nhất. Ở đây, chúng ta đề cập chi tiết
hơn về dữ liệu log sinh ra theo thời gian và các bước xử lý. Log có thể đại diện được
cho phần lớn các loại dữ liệu lớn và không đồng nhất khác như: XML, Meta-data,

File database csv, file txt,… trong vòng đời xử lý của hệ thống tích hợp được trình
bày ở bên dưới.
1.1.1 Log - dữ liệu không đồng nhất

Log là một bản ghi sự kiện xảy ra trong phạm vi mạng lưới hệ thống của một tổ
chức và được coi như là một hộp đen nhằm phản ánh tình trạng của bất cứ hệ thống
nào. Nó thực hiện ghi lại mọi thứ đã xảy ra trên hệ thống một cách cực kỳ chi tiết,
cho phép chúng ta biết được cái gì hệ thống đã làm tốt cũng như vấn đề gì xảy ra.
Hầu như khi hoạt động, mọi xử lý trên hệ thống đều sinh ra log. Ví dụ như các
sự kiện của router, firewall, các giao dịch database, các cuộc tấn công, các kết nối,
các hoạt động của người dùng...
Có rất nhiều nguồn sinh ra log, ngay cả khi có một nguồn log này, từ nó cũng
sinh ra các nguồn log khác và cũng có rất nhiều loại. Ví dụ như các file log của host
(Unix, Linux, Windows, VMS...), là khác biệt hoàn toàn so với log của các ứng dụng


6

network (switch, route, hoặc các thiết bị mạng khác của Cisco, Nortel, Lucent...).
Tương tự như vậy, các log của ứng dụng an toàn thông tin (Firewall, IDS, thiết bị
chống DDoS, hệ thống phòng bị...) cũng rất khác nhau trên cả phương diện host và
các log từ network.
Một dòng log sinh ra bởi máy tính con người có thể đọc hiểu được. Hầu hết các
log sinh ra có cấu trúc nội dung như sau:
LOG = TIMESTAMP + DATA [1]

Timestamp ghi lại nhật ký thời gian dòng log được ghi, Data chứa các nội dung
mà hệ thống đã xử lý bao gồm tất cả các thông tin về những sự việc hợp lệ và không
hợp lệ. Làm thế nào để chúng ta có thể tìm được đâu là những sự việc không được
cho phép và làm thế nào chúng ta có thể học được về những sai lầm trong quá khứ

từ log và có thể dự báo trước được tương lai. Chúng ta có thể hoàn toàn hy vọng vào
việc tìm kiếm trong hàng gigabytes từ nhiều file log khác nhau để trích lọc ra những
hoạt động không được phép xảy ra không? Câu trả lời nằm ở vấn đề cần thiết phải
xử lý dữ liệu log tập trung.
Các cấp độ của log [2][3]
Hầu hết các hệ thống, các nền tảng framework đều sử dụng các thiết lập tiêu
chuẩn để đo mức độ của log, dưới đây là các cấp độ log cơ bản:
1.1.2

[FATAL | ERROR | WARN | INFO | DEBUG | TRACE]
Trong hệ thống môi trường production, log thường được thiết lập ở cấp độ
WARN. Cấp độ chi tiết hơn chỉ được bật khi có một vài vấn đề nảy sinh hoặc lập
trình viên muốn có thêm thông tin chi tiết của log sinh ra trong một thời gian nhất
định.


7

FATAL – Những thứ gây ra cho các phần mềm không thể bắt đầu hoặc bắt đầu
bằng một ngoại lệ. Ví dụ “không thể nạp dll” hoặc “out of memory”. Nếu ứng dụng
cố gắng hoạt động hoặc bắt đầu bằng một sự cố như vậy, thì một người nào đó có thể
thực hiện xem log và tìm thấy một dòng FATAL và nói rằng “khi nào” và “vấn đề
tại sao”.
ERROR – Có nghĩa rằng việc thực thi một vài nhiệm vụ không hoàn thành. Ví
dụ như “không thể kết nối tới (DB, LDAP, file server...)”, “cố gắng lưu file nhưng
không thể”, “một email không được gửi đi”, “vài dữ liệu không thể lưu trữ vào DB”,
và những thứ tương tự như vậy dẫn thẳng đến lỗi. Những dòng log cấp ERROR cần
được điều tra và phải có hành động từ một ai đó để giải quyết vấn đề.
WARN – Ở cấp độ này, sẽ đặt bất cứ điều gì đó bất ngờ xảy ra là một vấn đề
tạm thời và việc thi hành vẫn tiếp tục. Ví dụ như “Một tập tin đã mất nhưng mặc

định đã được sử dụng”. WARN tạo ra cảnh báo cho đến khi nó cố gắng thực hiện
xong nhiệm vụ. Nó thường là dấu hiệu cho thấy sẽ có một lỗi ERROR rất sớm.
INFO – Các nhiệm vụ được thực hiện và kết thúc bình thường nhưng ở vài
bước quan trọng chúng ta cần ghi lại nhật ký của hoạt động để đánh dấu tình trạng.
Ví dụ “hệ thống bắt đầu, hệ thống dừng, batch job bắt đầu kích hoạt”. Nó không phải
là một chuỗi xử lý liên tục, không cần ghi vào log quá nhiều chi tiết. Nếu không sẽ
là dư thừa các thông tin không cần thiết.
DEBUG - Ở cấp độ này sẽ ghi lại sự kiện mà mỗi lần lập trình viên thực hiện
tìm kiếm lỗi trong một đoạn mã ở khoảng thời gian nhất định.
TRACE – Ít khi sử dụng. Cấp độ này sẽ ghi lại cực kỳ chi tiết từng dòng mà
thông thường chúng ta không muốn kích hoạt ngay cả trong quá trình phát triển.
1.1.3 Chi tiết về Log File [1][4][5]

1.1.3.1
Nội dung và định dạng của file log
Thông thường file log được định dạng kiểu “plain text” và định dạng file kết
thúc bằng “.log”, do đó log có thể được xem bởi công cụ Notepad và một số công cụ
tương tự.


8

Log là một đơn sự kiện được lưu trữ bởi một dòng đơn ghi trong file log. Tuy
nhiên ở nhiều trường hợp, log có thể là sự kiện lưu trữ ở nhiều dòng và có chung
thông tin về nhật ký thời gian.
Nội dung của một dòng log cụ thể thông thường các trường sẽ được phân định
rõ ràng bằng một vài ký tự đặc biệt. Do đó, dễ dàng cho việc trích lọc các thông tin.
Các ký tự phân cách thông thường là dấu thẳng đứng “|” , dấu phẩy “,” hoặc dấu cách
“ ”. Không sử dụng độ dài cố định cho một dòng log và nếu một trường thông tin bị
khuyết, thì sẽ phải sử dụng một ký tự để thay thế nó (ví dụ log của Apache sử dụng

dấu gạch ngang “–” ).
Các thông tin mật khẩu, email và một số thông tin nhạy cảm không bao giờ
được viết vào nội dung log do các vấn đề bảo mật thông tin chung. Khuyến khích ghi
các nội dung chi tiết như thông tin người dùng, thông tin mạng (ví dụ như địa chỉ IP)
hay các thông tin liên quan đến vấn đề xác thực ở mức cụ thể nơi thông điệp, sự kiện
đến, do class/method nào sinh ra.

Dưới đây là một ví dụ về một dòng log:
3/12/2015 1:04:04 PM [20] From: (192.167.26.1) Fac:16 Sev:6 Msg >>> Mar 12 13:03:58
pf:
101.26.180.73.20532 > 117.6.95.159.42988: UDP, length 101

Ở ví dụ này, người không hiểu về đoạn log nói về nội dung gì nhưng cũng dễ
dàng nhận ra một vài trường thông tin cách biệt:
@timestamp @from: (@ip) @event @source @destination @protocol @length

1.1.3.2
Vòng đời dữ liệu của file log
Việc ghi lại nhật ký các hoạt động vào file log cũng là một dữ liệu quý giá để
đánh giá được nhiều việc. Tuy nhiên với ứng dụng càng lớn, người dùng càng nhiều
thì log mà hệ thống sinh ra cũng sẽ phình to nhanh chóng. Trong quá trình chạy các
dịch vụ trên server, nó phát sinh ra các thông tin trong quá trình chạy (các thông báo
lỗi, các cảnh báo, các sự kiện liên quan tới vấn đề chạy dịch vụ, ... ). Và những thông


9

tin đó sẽ được lưu trữ vào một hoặc nhiều file log. Sau một thời gian sử dụng, file
log có kích cỡ rất lớn.
Về cơ bản dữ liệu log sẽ được ghi nối đuôi theo dòng thời gian, như hình bên

dưới.

Hình 1.1: Ghi dữ liệu log mới sinh ra [4]
Mỗi hình chữ nhật đánh số, tượng trưng cho một bản ghi được thêm vào log.
Các dữ liệu log được ghi lần lượt theo thứ tự thời gian. Mỗi dịch vụ có thể sẽ phải
cấu hình sẵn tham số kích cỡ lớn nhất của file log có thể chứa đựng. Tránh tình trạng
các file log làm đầy ổ cứng khiến hệ thống không thể chạy được. Sự kiện, thông điệp
sinh ra có thể ghi đè vào dữ liệu log cũ hoặc ghi mới một đến nhiều file log khác.
Tuy nhiên để hiệu quả, hầu hết các máy chủ server hiện nay đều sử dụng một vài
công cụ giúp nén các file log này lại và cắt bỏ những log đã được nén đi hoặc sử
dụng cơ chế tương tự như công cụ Logrotate – Đưa nội dung của các file log quá lớn
sang một file khác để tránh tình trạng các file log chiếm dung lượng ổ cứng một cách
không cần thiết.
1.1.4 Tại sao phân tích dữ liệu log

Câu trả lời đơn giản nhất là chỉ có duy nhất dữ liệu log mới phản ánh được tình
trạng của các hệ thống. Nó chứa đựng các thông tin mà các DB khác không có được.
Rất nhiều lý do đặt vào các hoàn cảnh khác nhau để giải thích cho việc tại sao phải


10

nhìn vào và phân tích dữ liệu log. Dưới đây trình bày một số lý do thường thấy cho
vấn đề này:

Phân tích dữ liệu log là con đường thực tế và duy nhất để hiểu được cách
thức mà hệ thống hoạt động ra làm sao và khách hàng đã sử dụng nó như
thế nào.

Không phải mất nhiều thời gian lãng phí cho việc thu thập từng file text,

file log có kích cỡ lớn nhỏ từ nhiều nguồn khác nhau.

Có thể truy cập và đọc được nội dung các file log tức thì mà không làm
ảnh hưởng đến các vấn đề bảo mật cũng như tính toàn vẹn của dữ liệu log.

Vấn đề trích lọc và phân tích nội dung log là phức tạp, cần phải được thực
hiện sớm giúp cho việc dự đoán và ra quyết định ngay khi hệ thống ở trong
một tình trạng khẩn cấp.

Log chứa các thông tin quan trọng cho phép chúng ta tìm ra những mối
nguy hại xấu trước khi các vấn đề đó trở lên rõ ràng và phát sinh.

Log là rất quan trọng trong việc hiểu hệ thống và các ứng dụng giao tiếp
với khách hàng thường xuyên như thế nào. Từ đó có thể tìm ra những trở
ngại trong việc vận hành các ứng dụng trong cơ sở hạ tầng của chúng ta,
cũng như cách thức mà khách hàng đã sử dụng các ứng dụng đó như thế
nào.

Có thể việc phân tích log được sinh ra ở một server là không đủ để đưa tới
một kết luận, mà phải tập hợp tất cả các dữ liệu log từ các server khác trong
phạm vi một hoặc liên kết nhiều tổ chức để xử lý.

Bởi việc phân tích và tập hợp các dữ liệu log giúp ích cho việc thống kê.
Chúng ta có thể chuyển giao các sản phẩm dịch vụ liên quan thành tiền bạc
đồng thời giúp chúng ta trả lời được rất nhiều câu hỏi như:
Có bao nhiêu khách hàng mà chúng ta đã bị mất bởi vì các vấn đề
không ổn định của hệ thống.
Có khách hàng nào sử dụng nhiều dịch vụ hơn so với số tiền họ chi
trả hay không?
Phiên bản triển khai cuối cùng của hệ thống đã thực sự cải thiện trong

quá trình đáp ứng khách hàng hay chưa?
Có bao nhiều khách hàng sử dụng các tính năng mới phát triển.


11

Phân tích log, hay là phân tích một khối dữ liệu lớn các thông tin chúng ta sẽ có
thể lấy được nhiều giá trị to lớn giúp ích cho công ty, tổ chức. Giải pháp tích hợp dữ
liệu log là rất quan trọng cũng như chúng ta đang giám sát các hệ thống đó làm việc
như thế nào. Điều này luôn là điều cần thiết cho bất cứ tổ chức nào sử dụng các dịch
vụ về công nghệ thông tin.
Khó khăn của việc thực hiện hệ thống tích hợp dữ liệu không đồng nhất
Trong một tổ chức có rất nhiều hệ điều hành (Linux, Windows, Mac OSX...)
các phần mềm, dịch vụ và các ứng dụng khác sinh ra dữ liệu khác nhau và lưu trữ
chúng dưới nhiều định dạng. Điều này gây khó khăn trong vấn đề quản lý dữ liệu và
đưa ra báo cáo bởi những lý do cơ bản sau:

Có rất nhiều nguồn dữ liệu khác nhau nhưng có mối quan hệ vì thế cần xử
lý tích hợp. Nó nằm trên các máy chủ khác nhau trong phạm vi bao trùm
tổ chức cho nên việc quản lý tích hợp đòi hỏi cần phải thực hiện trên toàn
bộ tổ chức. Hơn nữa, từ một nguồn dữ liệu này có thể phải quản lý hàng
trăm file dữ liệu kích cỡ lớn nhỏ, nội dung khác nhau.

Nội dung dữ liệu không đồng nhất: Mỗi loại nguồn của dữ liệu lại có một
giá trị khác nhau. Giả sử từ nguồn dữ liệu thứ nhất có chứa địa chỉ IP nhưng
không có username, trong khi cũng bản ghi đó nhưng nguồn dữ liệu thứ
hai lại có username nhưng lại không chứa địa chỉ IP, gây ra khó khăn cho
việc liên kết các bản ghi lại với nhau bởi vì chúng không có các bản ghi
chứa giá trị chung.


Định dạng dữ liệu không đồng nhất: Có rất nhiều loại nguồn dữ liệu sử
dụng các định dạng khác nhau như syslog, databases, SNMP, XML, binary
file, meta-data dẫn đến khó khăn trong việc chuẩn hóa cấu trúc chung cho
tất cả các dữ liệu.

Bảo vệ dữ liệu đảm bảo tính bí mật, toàn vẹn và phải luôn sẵn sàng cho
việc điều tra, phân tích. Để làm được việc này tổ chức cần thiết lập các quy
trình, chính sách riêng cho hệ thống. Vậy bài toán đặt ra và cần giải quyết
ở đây là dữ liệu cần phải được truyền qua một kênh an toàn đến nơi lưu
trữ, phải có một kênh riêng để đảm bảo tính sẵn sàng trong vận hành chứ
không phải đính kèm hay mở rộng từ các ứng dụng đang chạy.

Nguồn nhân lực để phân tích dữ liệu: Đây là vấn đề quan trọng, không thể
tách rời. Tất cả mọi giải pháp, công nghệ áp dụng cho hệ thống quản lý dữ
1.2


12

liệu tập trung sẽ vô nghĩa khi thiếu đội ngũ đáp ứng được việc phân tích
và truy vấn dữ liệu lớn ở server trung tâm. Yêu cầu đặt ra là cần phải có
một đội ngũ có kỹ năng, chuyên môn cao để xử lý nhanh tình huống xảy
ra dựa vào các dữ liệu thu được từ hệ thống quản lý.
Khó khăn khi thực hiện xử lý tích hợp dữ liệu thời gian thực
Việc xử lý dữ liệu ở thời gian thực được xem là rất phức tạp và khó khăn. Như
chúng ta đã biết, Big Data thường được tổ chức bởi khối lượng, vận tốc và một khối
dữ liệu khổng lồ. Thực thi nhiệm vụ ở thời gian thực yêu cầu phải có tốc độ xử lý dữ
liệu cực kỳ tốt, mà vấn đề xử lý vận tốc của Big Data không phải là một nhiệm vụ dễ
dàng.
1.3


Đầu tiên, hệ thống có thể sẽ thu thập dữ liệu thời gian thực từ các dòng dữ liệu
đầu vào với tốc độ hàng triệu message mỗi giây.
Thứ hai, cần phải thực hiện song song nhiệm vụ xử dữ liệu ngay khi nó đang
được thu thập.
Thứ ba, cần phải có phương thức trích lọc dữ liệu để trích xuất và sàng lọc ra
các thông tin có nghĩa. Chưa kể việc định dạng lại cấu trúc dữ liệu để quy về một cấu
trúc chuẩn chung.
Cả ba bước trên là ba bước cơ bản đều yêu cầu phải có ở một hệ thống thu gom
và xử lý dữ liệu thời gian thực.

Hình 1.2: Kiến trúc xử lý dữ liệu thời gian thực [10]


13

Hình 1.2 ở trên mô tả các bước khác nhau của một hệ thống xử lý dữ liệu thời
gian thực. Luồng dữ liệu có thể thu thập từ nhiều nguồn khác nhau, tập trung xếp vào
hàng đợi. Các thành phần Data Process tiếp tục xử lý luồng dữ liệu và thêm một bước
xếp hàng đợi đầu ra để lưu trữ các dữ liệu đã được xử lý vào thành phần đích. Thường
là các bộ DB điển hình như là NoSQL, DBMS, hoặc là đầu vào của một ứng dụng
khác.
Để giải quyết thách thức vấn đề xử lý thời gian thực phức tạp này, luận văn trình
bày và đề xuất một vài giải pháp xử lý. Với mô hình trên đây, eLMS sẽ thực hiện lưu
trữ vào Elasticsearch.
1.4

Kết luận
Trong chương này, chúng ta trình bày các vấn đề cơ bản về kiểu dữ liệu không
đồng nhất. Trình bày tổng quan về các loại dữ liệu khác nhau. Trình bày cụ thể về

một kiểu dữ liệu đại diện là dữ liệu log. Hiểu được các nội dung cơ bản đó mà chúng
ta thấy được rằng việc quản lý và tích hợp dữ liệu sẽ gặp phải khó khăn gì và tại sao
cần thiết phải quản lý tích hợp dữ liệu tập trung. Mở đầu cho vấn đề mà luận văn
đang đề cập tới.
CHƯƠNG 2: HỆ THỐNG TÍCH HỢP DỮ LIỆU LỚN VÀ KHÔNG ĐỒNG
NHẤT LÀ GÌ?
2.1 User Case
Tầm quan trọng của việc phân tích và quản lý dữ liệu từ các nguồn khác nhau
để chuyển về server tập trung là rất quan trọng. Chúng ta hiểu rằng cần phải tìm ra
một giải pháp mà sẽ phải giải quyết được các trường hợp sau đây:

Tích hợp tất cả các dữ liệu định dạng khác nhau từ tất cả các server và lưu
trữ ở một nơi duy nhất.

Cung cấp chức năng tìm kiếm nhanh chóng để phát hiện ra các lỗi và tìm
ra các cảnh báo chứa trong dữ liệu được chuyển về ở một thời gian cụ thể.

Phải dễ dàng phân tích các file dữ liệu lớn từ nhiều nguồn khác nhau.

Sẵn sàng chia sẻ các dữ liệu ở server trung tâm mỗi khi cần cho đội phát
triển mà không cần cung cấp cho họ quyền truy cập trực tiếp vào server
chính.


14






Trích lọc ra các dữ liệu liên quan trực tiếp tới vấn đề đang gặp phải.
Thống kê các dữ liệu lỗi, các giao dịch bất thường, đưa các vấn đề chi tiết
từ yêu cầu của người quản trị.
Phải có thông báo từ hệ thống quản lý trong trường hợp có các lỗi tương
tự xảy ra.

2.2

Thực hiện quản lý tích hợp dữ liệu tập trung
Việc xử lý tích hợp dữ liệu từ đa dạng các nguồn, định dạng khác nhau có hai
vấn đề cơ bản:

Cấu hình server tập trung sẽ thu thập, xử lý, sàng lọc và hiển thị dữ liệu
sau khi đã được tích hợp, trích lọc.

Cấu hình các máy trạm để gửi dữ liệu về tới server tập trung, lựa chọn các
đích lưu trữ dữ liệu tạm thời và bảo mật trong khi vận chuyển.
Việc xây dựng một hệ thống quản lý tích hợp dữ liệu tập trung, phân tích và
hiển thị giúp tổ chức có cái nhìn cụ thể và chi tiết về từng sản phẩm, dịch vụ mà các
hệ thống đang hoạt động. Những vấn đề về bảo mật, lỗi kỹ thuật hay các vấn đề về
lỗi vận hành hoặc khi có sự cố bất ngờ xảy ra. Các giải pháp quản lý tích hợp dữ liệu
tập trung phải sẵn sàng cung cấp thông tin chi tiết về vấn đề đang gặp phải, và có
quan điểm rõ ràng hơn về các hướng giải quyết.
Ngoài ra cần đảm bảo tính toàn vẹn của dữ liệu ở server trung tâm, phục vụ cho
việc điều tra phân tích hệ thống.
Việc tập trung một khối lượng dữ liệu lớn cho phép có thể khai thác và đưa ra
dự đoán, quyết định.
2.2.1 Vòng đời xử lý của hệ thống tích hợp và không đồng nhất [1][11]

Có thể thấy rằng, ngày này có rất nhiều sản phẩm về tích hợp dữ liệu dữ liệu

tập trung sẵn sàng đáp ứng cho các nhu cầu quản lý và cũng có rất nhiều loại hình
với nhiều kiểu cấu trúc xử lý khác nhau. Nhưng về cơ bản, chúng có cùng bản chất
khi đều là tích hợp và xử lý dữ liệu tập trung. Cho nên, các kiến trúc đều có chung
một vòng đời xử lý như sau:


15

Hình 2.1: Vòng đời xử của hệ thống tích hợp và không đồng nhất
Bước 1: Ứng dụng sinh ra các dữ liệu
Một sự kiện được sinh ra bởi một ứng dụng. Vòng đời bắt đầu với một dữ liệu
được ghi và lưu trữ trên một server. Có thể có rất nhiều loại dữ liệu khác nhau, nhưng
chủ yếu là thuộc phạm vi các loại dữ liệu đã đề cập ở bên trên.
Bước 2: Bộ thu thập dữ liệu (shipper)
Nội dung dữ liệu được thu thập bởi một công cụ được xây dựng gọi là các
shipper. Các shipper thực hiện đẩy dữ liệu từ các máy trạm và gửi đến các hàng đợi
hoặc đẩy dữ liệu trực tiếp về trung tâm. Thành phần shipper sẽ thực hiện đọc các tập
tin, các nguồn dữ liệu và lấy các dữ liệu mới sinh ra, để gửi tới thành phần hàng đợi
hoặc đẩy trực tiếp vào bộ phân giải dữ liệu (parser). Có điều quan trọng là các shipper
phải được thiết kế nhẹ, hiệu quả, chiếm ít tài nguyên và có thể chạy song song với
các ứng dụng máy chủ mà không gây ra bất kỳ vấn đề hiệu suất nào. Ví dụ một vài
thành phần shipper như: Beaver, Logstash-forwarder, Log-courier, Splunk universal
forwarder.
Bước 3: Hàng đợi lưu trữ các dữ liệu tạm thời
Khi chúng ta bắt đầu thực hiện thu thập các dữ liệu từ nhiều nguồn và nhiều
server, có thể tạo ra một lưu lượng dữ liệu khổng lồ mà ở thành phần parser xử lý
phân tích, trích lọc và định dạng chuẩn cấu trúc chung... không thể theo kịp, gây ra
mất dữ liệu tại đây. Trong trường hợp đó, chúng ta sẽ phải đưa ra một thành phần
trung gian đóng vai trò là một hàng đợi. Nó lưu trữ dữ liệu tạm thời và cho phép việc
xử lý dữ liệu ở bộ phân giải dữ liệu (parser) thực hiện tuần tự theo tốc độ riêng của

nó. Việc đọc và xóa liên tục ở hàng đợi mà parser xử lý là tốn nhiều thời gian, dẫn


16

tới hệ thống có độ trễ nhất định. Ví dụ các Message Queues: ZeroMQ, RabbitMQ,
Redis.
Bước 4: Bộ phân giải dữ liệu (Parser)
Khi nhận dữ liệu từ các thành phần khác chuyển tới, chúng ta đưa ra một thành
phần xử lý dữ liệu chính của luồng dữ liệu được gọi là bộ phân giải dữ liệu parser.
Khi thành phần parser nhận dữ liệu từ hàng đợi hoặc trực tiếp từ shipper chuyển
tới, nó sẽ thực hiện các nhiệm vụ phân tích như: Trích lọc những thông tin có ích,
đọc từng dòng dữ liệu và định dạng lại về dữ liệu có cấu trúc, chuyển về định dạng
dữ liệu json, tags các thông tin quan trọng... Và cuối cùng, parser sẽ thực hiện đẩy
tất cả dữ liệu đã xử lý vào trong DB. Một số parser như: Logstash, Heka, Fluentd,
Splunk Indexer.
Bước 5: Client – Giao diện
Cung cấp chức năng xem nội dung thông tin dữ liệu sau khi đã được tích hợp
và xử lý, lập biểu đồ thống kê, truy vấn và tìm kiếm thông tin. Cũng có thể xử lý bởi
các thuật toán bởi Data Mining nhằm đưa ra một vài quyết định hay kết luận có ý
nghĩa từ dữ liệu đã thu thập được. Điển hình như Kibana, Graphite, Splunk Web-UI,
Grafana.
Bước 6: Xóa dữ liệu cũ ra khỏi Database
Tất nhiên chúng ta có thể giữ tất cả dữ liệu ở trong DB mãi mãi. Nhưng trong
nhiều trường hợp, việc lưu trữ cộng với giá thành của phần cứng quá cao mà các dữ
liệu cũ ngày càng trở lên không có giá trị gì nữa. Vì vậy, để chỉ giữ lại những dữ liệu
cần thiết, chúng ta cần thêm một xử lý phân loại dữ liệu đẩy vào các thể loại category
khác nhau theo mức độ quan trọng của chúng trước khi lưu trữ vào trong DB. Mỗi
category sẽ phải xác định số lượng, thời gian mà dữ liệu được lưu trữ hoặc cũng có
thể lưu trữ tối đa kích cỡ category ở trong DB. Theo lập lịch ở cấu hình mà DB sẽ

tạo ra một xử lý chạy ngầm để xóa các dữ liệu cũ, giữ cho DB nhẹ nhàng, sạch sẽ và
chỉ lưu trữ các dữ liệu cần thiết.
2.2.2 Chi tiết bộ thu thập dữ liệu Shipper
Với các nguồn dữ liệu chúng ta muốn nhanh chóng thu thập, vận chuyển nó tới
một server tập trung, trong thời gian thực. Chúng ta sẽ phải sử dụng các thành phần