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

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.. Log có thể đại diện được cho phần lớn các loại dữ liệu lớn và không

ĐẠ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

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

ELK Hệ thống Elasticsearch – Logstash - Kibana

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

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

H ÌNH 3.3 LƯU TRỮ CỦA MỘT MESSAGE CYCLE 57

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

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

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

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

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

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

1.1.2 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:

[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

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]

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ự

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

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

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

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

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

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ữ

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ý

1.3 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

Đầ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]

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

 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:

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

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

shipper Nó là một ứng dụng nhẹ được thực hiện để thu thập các dữ liệu sinh ra từ nhiều nguồn khác nhau và gửi đến một hoặc nhiều đích đầu ra

Ứng dụng chạy nền shipper: Một shipper tốt là một thành phần ẩn, sử dụng

CPU, bộ nhớ, các tài nguyên I\O ít nhất có thể và không bao giờ gây xung đột với các ứng dụng đang chạy trên server Trong nhiều trường hợp, có thể một shipper đọc rất nhiều file ở cùng một thời điểm trên cùng một server mà các ứng dụng đang chạy

đó đang cố gắng ghi thêm dữ liệu mới vào các file hay các nguồn đang bận xử lý trước đó Khi thực hiện đọc các file, shipper không được khóa file để cho việc ghi thêm dữ liệu không bị xung đột Nếu chúng ta cảm thấy shipper ảnh hưởng tới các ứng dụng đang chạy, thì nên cân nhắc sử dụng một shipper khác hoặc tìm một giải pháp khác cho việc gửi dữ liệu tới server tập trung

Gửi dữ liệu an toàn: Thành phần shipper sẽ gửi các dữ liệu tới một hoặc nhiều

đích và để thực hiện điều này, nó cần truy cập được vào network ở các đích đến đó

Để bảo vệ các ứng dụng và tầng mạng network, thì chúng ta nên chắc chắn rằng chỉ

mở các cổng cần thiết cho việc kết nối Luôn luôn sử dụng một firewall để bảo vệ cho các hệ thống

Trong một vài trường hợp, dữ liệu chứa các thông tin nhạy cảm mà chúng ta sẽ

có ý định mã hóa dữ liệu này trước khi gửi đi Tránh trường hợp xấu nhất là hệ thống

có thể bị tấn công và bị lộ các thông tin đó gây ra thiệt hại lớn Hầu hết các shipper của một vài ứng dụng quản lý dữ liệu log hiện như ELK đều hỗ trợ mã hóa SSL Vì thế chúng ta luôn phải sử dụng khi gửi dữ liệu qua mạng, trừ khi có một vài trường hợp với lý do chính đáng

Hệ thống quản lý tích hợp dữ liệu sử dụng một cổng duy nhất để truyền tải dữ liệu giữa shipper và parser, các dữ liệu có thể được mã hóa trước khi gửi để đảm bảo vấn đề bảo mật thông tin

Vậy sự khác biệt giữa một shipper và một parser là gì? Cả hai thành phần này

có chức năng tương tự là đều thực hiện thu thập dữ liệu từ các nguồn và gửi dữ liệu tới các đích đến Trong một vài trường hợp các parser được sử dụng như là các shipper, nhưng có một điều quan trọng khác nhau giữa chúng: Parser luôn được sử

dụng để thực hiện xử lý trích lọc, quy về dữ liệu có cấu trúc, tags các thông tin từ các

dữ liệu thu thập được và việc xử lý này tốn rất nhiều tài nguyên CPU Chạy các parser cùng với các ứng dụng trên cùng một server sẽ gây ra các việc xử lý quá tải không cần thiết Trong một vài trường hợp cụ thể mà chúng ta chủ định thực hiện triển khai chúng trên cùng một server, điều cần thiết là phải ước lượng và kiểm soát được rằng không ảnh hưởng tới hiệu năng của các ứng dụng hiện tại

2.2.3 Chi tiết về hàng đợi

Hàng đợi Queue: Đóng vai trò như là người gác cổng và bảo vệ các thành

phần parser trong tình trạng quá tải với việc xử lý quá nhiều dữ liệu đến Số lượng

dữ liệu luôn ở mức tối đa mà parser có thể xử lý trong một giây và khi vượt qua ngưỡng này, các parser có thể bị mất các dữ liệu do các luồng xử lý bị quá tải và phát sinh các lỗi ngoại lệ Để giải quyết vấn đề này, việc sử dụng một thành phần hàng đợi là bắt buộc

Kéo và đẩy dữ liệu: Khi chúng ta gửi các dữ liệu trực tiếp tới thành phần parser

bằng shipper, về cơ bản là đang thực hiện đẩy các dữ liệu và mong chờ các parser có thể xử lý cùng với tốc độ mà các dữ liệu đang đẩy vào nó Nhưng thực tế thì luôn là chậm hơn, vì parser phải xử lý quá nhiều việc Ở đây, chúng ta lựa chọn sử dụng một hàng đợi queue, để các parser thực hiện kéo các dữ liệu ra ở tốc độ mà nó có thể xử

lý Khi tỷ lệ này là quá cao và việc parser không thể kéo tất cả các dữ liệu xử lý đồng thời, thì các dữ liệu sẽ được lưu trữ vào một hàng đợi Chờ khi parser quay trở lại sẽ tiếp tục kéo các dữ liệu từ hàng đợi ra để xử lý và thực hiện xóa đi các dữ liệu ở hàng đợi Việc bổ sung thêm hàng đợi là giải pháp tốt nhất cho việc giải quyết các vấn đề quá tải tạm thời cho server tập trung

Database phát sinh vấn đề: Trong trường hợp server DB bị dừng lại hoặc bị

lỗi trong thời gian đang thực hiện xử lý, các parser sẽ không tìm thấy đích hợp lệ để gửi dữ liệu đi Lúc này đầu vào của parser càng lúc càng nhận được nhiều dữ liệu từ thành phần shipper gửi sang và bắt đầu xảy ra mất mát dữ liệu Tất cả các dữ liệu tiếp theo được sinh ra và gửi đến đây đều bị mất Trong trường hợp này, hàng đợi queue lại cho thấy được vai trò quan trọng của nó, cho phép các parser dừng kéo các

dữ liệu cho việc xử lý và để cho nó lưu trữ trong hàng đợi Khi các phiên làm việc của DB hoạt động trở lại, nó sẽ khôi phục lại tất cả các dữ liệu, kéo ra để tiếp tục xử

lý với parser và gửi chúng tới DB Có thể mất nhiều thời gian cho parser làm việc với lưu lượng hàng đợi lớn như vậy nhưng kết quả là giữ được các dữ liệu sinh ra ở các thời gian tiếp theo không bị mất đi

Một lớp đệm an toàn: Trong một số trường hợp các file dữ liệu có thể bị

phân tán ở các server khác nhau và chúng ta muốn gửi chúng tới một server tập trung Bằng cách sử dụng một hàng đợi dữ liệu, có thể giữ cho dữ liệu được an toàn Gửi dữ liệu mã hóa và hạn chế truy cập tới một cổng mở duy nhất trên server

xử lý hàng đợi Điều này là quan trọng cho việc bảo mật các dữ liệu với giải pháp tích hợp dữ liệu tập trung và đặc biệt là khi đề cập tới môi trường sử dụng các

server phân tán

2.2.4 Chi tiết về bộ phân giải dữ liệu Parser

Parser đôi khi cũng được gọi là Indexer (tương tự Logstash indexer) Là thành phần tâm điểm cho vòng đời xử lý dữ liệu Chịu trách nhiệm phân tách từng giá trị

có ý nghĩa ở trên mỗi bản ghi dữ liệu, trích lọc và làm cho các dữ liệu trở lên có cấu trúc

Thông thường, nếu số lượng dữ liệu là vừa phải, chúng ta sẽ gửi tất cả tới một thành phần parser duy nhất để thực hiện phân tích nội dung của từng bản ghi dữ liệu

và xử lý nó Quá trình này sẽ tiêu tốn rất nhiều tài nguyên CPU như đã nói ở trên và bởi vì lý do này, thành phần parser nên được cài đặt và cấu hình ở một server riêng biệt mà không có các thành phần khác Nếu chúng ta cảm thấy rằng server cài đặt thành phần parser đủ mạnh và các dữ liệu đầu vào từ thành phần shippser là không lớn Chúng ta có thể bỏ qua thành phần hàng đợi để giảm thiểu thời gian tiêu tốn ở các bước trung gian

Sau khi parser kết thúc việc xử lý dữ liệu, nó sẽ chuyển sang cho bộ lưu trữ Để thực hiện quá trình này hiệu quả, nên triển khai cài đặt database và server parser trên cùng một mạng để đạt tốc độ tối đa việc trao đổi dữ liệu mà không xảy ra vấn đề mất mát dữ liệu

Vậy chính xác thành phần parser làm những gì? Ở đây, chúng ta sẽ sử dụng hai dòng dữ liệu log bên dưới để có thể hiểu được cách thức mà parser làm việc

3/12/2015 1:04:04 PM [18] From: (192.167.26.1) Fac:16 Sev:6 Msg >>> Mar 12 13:03:58 pf: 154.45.216.159.1043 > 117.6.95.159.49751: UDP, length 94

3/12/2015 1:04:04 PM [17] From: (192.167.26.1) Fac:16 Sev:6 Msg >>> Mar 12

13:03:58 pf: 00:00:00.004827 rule 5/0(match): block in on pppoe0: (tos 0x0, ttl 46,

id 41412, offset 0, flags [DF], proto UDP (17), length 122)

Parser thực hiện kéo các dữ liệu log từ hàng đợi và chạy luồng xử lý phân tích

sử dụng một bộ lọc filter được khai báo trước trong cấu hình Cuối cùng parser sẽ trích lọc và định dạng lại các thông tin trong dữ liệu log thành các trường dưới dạng key-value:

2.2.5 Chi tiết về Database

Đối với việc thống kê và phân tích các dữ liệu tích hợp, chúng ta cần phải lưu các thông tin vào trong một DB Thành phần DB được chọn phải hiệu quả trong việc nhận dữ liệu tới và gửi các dữ liệu đi, hỗ trợ việc tìm kiếm nhanh, dễ dàng cho việc phân tích

Để chia sẻ gánh nặng gây ra bởi các file dữ liệu lớn, chúng ta lựa chọn bổ sung thêm trong kiến trúc với nhiều thành phần hàng đợi và nhiều thành phần xử lý phân tích parser Và cuối cùng chúng ta muốn tất cả các dữ liệu, không cần biết nó đến từ đâu đều phải được gửi tập trung vào cùng một DB Có nghĩa rằng DB mà chúng ta lựa chọn cần phải đảm bảo có hiệu suất cao

Các dữ liệu liên tục đọc ghi vào trong DB, vì thế nó cần sử dụng rất nhiều bộ nhớ RAM, tài nguyên CPU và hiệu suất cao của ổ cứng Nếu nhận thấy rằng DB luôn luôn trong tình trạng quá tải và bắt đầu mất dữ liệu, đó là thời điểm chúng ta cần xem xét nâng cấp phần cứng hoặc lựa chọn ghi với khối dữ liệu nhỏ hơn Đôi khi cũng gặp phải trường hợp không thể nâng cấp phần cứng để giải quyết vấn đề thì chúng ta

có thể lựa chọn giải pháp phân cụm cluster Elasticsearch cho phép chúng ta chia sẻ cùng một DB giữa các server khác nhau

Một lượng lớn các dữ liệu tích hợp trở nên vô ích nếu không có ai thể truy cập

và lấy thông tin từ chúng Để đọc các dữ liệu được lưu trữ trong DB, chúng ta sẽ sử dụng một hoặc nhiều client kết nối đến nhằm thực hiện truy vấn thông tin Sự phức tạp và số lượng của các câu lệnh truy vấn đồng thời sẽ quyết định sử dụng bao nhiêu tài nguyên của CPU để xử lý Ngoài ra, các câu lệnh truy vấn cũng sẽ tiêu tốn tài nguyên khi đọc dữ liệu từ ổ đĩa, điều này có thể ảnh hưởng tới hiệu suất ghi các dữ liệu đến Nếu sử dụng lập lịch cho các câu lệnh truy vấn để giám sát các loại dữ liệu lỗi và cảnh báo Các truy vấn này sẽ làm tăng tải trọng của trên máy chủ DB, do đó chúng ta luôn luôn phải để mắt tới DB sẽ bị ảnh hưởng như thế nào do các lệnh truy vấn gây ra

Trong DB có rất nhiều thông tin và nó cần lưu trữ với hình thức càng cô lập càng tốt để có thể bảo vệ chống lại bất kỳ mối đe dọa nào từ bên ngoài Chúng ta nên cấu hình cho phép truy cập duy nhất một cổng cho thành phần parser và client sử dụng

Sau một thời gian hệ thống chạy sẽ có rất nhiều dữ liệu được lưu trữ trong DB Nhiều dữ liệu quá cũ trở thành dư thừa và không có ý nghĩa Để giữ cho DB luôn

được kiểm soát và hiệu quả, chúng ta nên lập lịch cho một nhiệm vụ quét dọn để xóa các nội dung dữ liệu cũ theo các loại dữ liệu đã được phân loại

2.2.6 Chi tiết về Client

Sau khi triển khai một hệ thống giải pháp tích hợp dữ liệu với bất kỳ mô hình kiến trúc nào mà chúng ta sử dụng, để đảm bảo tính ổn định thì các thành phần trong kiến trúc đó không được thay đổi quá nhiều, đôi khi là không được phép thay đổi Nói đến thành phần client hiển thị dữ liệu ở đây chúng ta sẽ phải cung cấp một công

cụ front-end đủ linh hoạt, dễ dàng cho việc truy vấn dữ liệu Thông thường sẽ là một ứng dụng web chạy trên trình duyệt với giao diện trực quan để thực hiện các câu lệnh truy vấn theo mục đích của người sử dụng

Do client có thể truy cập từ nhiều địa điểm và các máy khác nhau, chúng ta cần cài đặt nó trên một web server Để đảm bảo vấn đề bảo mật nội bộ, chúng ta nên sử dụng việc quản lý người dùng và phân quyền cho những người sử dụng liên quan truy cập

Với mỗi một nhiệm vụ mà thực hiện ở client sẽ bắt đầu chạy câu lệnh truy vấn vào trong DB Để đơn giản việc tìm kiếm dữ liệu, cũng như không đổ ra client một khối dữ liệu quá lớn Chúng ta luôn cần giới hạn tìm kiếm bởi bộ lọc thời gian và nhật ký ngày tháng sinh ra các dữ liệu tích hợp đó Vì lý do đó nên việc đánh index theo thời gian luôn có ích cho việc tìm kiếm nhanh hơn Ngoài ra cũng cần phải lựa chọn một ngôn ngữ truy vấn linh hoạt và cũng cần phải viết các câu lệnh truy vấn đó

ở mức tối ưu nhất

Một đồ thị có thể thể hiện được một đến vài trăm ngàn dữ liệu, do vậy việc tạo

ra các đồ thị thống kê cũng sẽ cũng giúp chúng ta khả năng tìm kiếm nhanh hơn So sánh trực quan và có thể biểu hiện được các xu hướng trong dữ liệu Từ đó mà có thể nhanh chóng thực hiện các nhiệm vụ điều chỉnh, ra quyết định, thêm một phát hiện mới hay đưa tới một kết luận ý nghĩa

Việc tìm kiếm theo lịch trình cũng rất là quan trọng, bằng cách lập lịch tìm kiếm tự động giúp cho ta luôn thể hiện được dữ liệu mới ở trên client và có thể giúp chúng ta nhận thấy xu hướng của dữ liệu ngay khi hệ thống được bắt đầu

Một trường hợp nữa cần thực hiện ở client đó là việc tạo ra dữ liệu mới từ các dữ liệu cũ ở trong DB Trong một số trường hợp, chúng ta phải thực hiện một lệnh tính toán phức tạp trên một tập dữ liệu lớn và nó trở thành một nhiệm vụ nặng

nề cho DB thực hiện Có thể mất vài giờ mới ra được kết quả mà chúng ta mong muốn Giải pháp là chúng ta chạy cùng một câu lệnh truy vấn nhiều lần trên một số tập dữ liệu nhỏ và sau đó lưu trữ lại kết quả với chỉ số index mới vào trong DB Việc truy vấn sẽ trở nên rất nhẹ nhàng do chúng ta sẽ lấy trực tiếp kết quả này và ghép với các kết quả khác tương tự

Các kết quả phân tích, ở client cũng cần thiết phải có thêm một số tiện ích như: Báo cáo tình trạng thống kê, gửi email thông báo, hoặc cảnh báo thông qua SMS khi có một kết quả tự động mà hệ thống phân tích nhận được là bất thường

2.3 Nền tảng từ các hệ thống hiện có

2.3.1 Hệ thống Hadoop [12]

Chúng ta đều biết đến Hadoop là nền tảng mã nguồn mở đang phát triển và trưởng thành trong vài năm gần đây với nền tảng xử lý dữ liệu offline tuyệt vời cho BigData Hadoop là một hệ thống thông lượng cao mà có thể xử lý một khối lượng lớn các dữ liệu bằng cách sử dụng mô hình phân tán và xử lý song song, được gọi

là map-reduce

Hình 2.2: Kiến trúc Hadoop

Đối với các hệ thống tích hợp và phân tích cỡ lớn như: Google, Yahoo thì Hadoop thực sự là một nền tảng tuyệt vời Tuy nhiên, các hệ thống cỡ lớn lại thuộc thành phần số ít và đa số chúng ta bắt gặp đều là những hệ thống nhỏ và cỡ tầm trung

Ở các lĩnh vực khác nhau đều cần thiết phải có một hệ thống giám sát, tích hợp

và phân tích dữ liệu mà yêu cầu phải đáp trả dữ liệu thời gian thực hoặc cho phép ở một độ trễ rất thấp gần với thời gian thực nhất Mục đích cơ bản là phục vụ cho việc đưa ra quyết định và dự báo nhanh hơn Ví dụ với các trường hợp như: Phân tích lừa đảo thẻ tín dụng, dự đoán lỗi mạng từ dữ liệu cảm biến, dự báo mối an ninh mạng Rất cần thiết phải xử lý thời gian thực để đưa ra cảnh báo hoặc một vài quyết định ngăn chặn, giảm thiểu rủi ro thiệt hại Hadoop với kiến trúc như trên thì lại không thích hợp cho các tình huống như vậy, nó trở nên cồng kềnh, tốn chi phí và không thực tế Hơn nữa cũng không đủ nhanh để xử lý dữ liệu online

2.3.2 Hệ thống Splunk [13]

Splunk là một phần mềm thương mại tốt nhất hiện nay Nó cho phép thu thập, đánh chỉ mục index bất kỳ loại dữ liệu nào, từ bất kỳ nguồn máy tính nào Bao gồm cấu trúc, không có cấu trúc, các dữ liệu phức tạp đa dòng, lưu trữ đánh chỉ mục, liên kết, phân tích, báo cáo và xem chi tiết về một vấn đề Nó tập trung đầy đủ giải pháp tích hợp cho quản lý dữ liệu, và mở rộng ra nhiều loại dữ liệu khác, lưu trữ và phân tích trực quan

Hình 2.3: Kiến trúc Splunk

Ưu điểm lớn nhất mà hệ thống Splunk có được là phương thức lưu trữ và đánh chỉ mục index

Hình 2.4: Sơ đồ lưu trữ và đánh chỉ mục index của Splunk

Đôi nét về kiểu lưu trữ này như sau:

Splunk lưu trữ tất cả dữ liệu trong các thư mục trên server được gọi là Buckets Một Buckets sẽ thực hiện di chuyển qua vài giai đoạn sau theo kiểu trạng thái thời tiết sử dụng là Hot, Warm, Cold, và Frozen

Hot – Đây là thư mục chứa tất cả các dữ liệu gần đây nhất được lưu trữ, thư

mục này có quyền đọc/ghi và không backup

Warm – Là giai đoạn tiếp theo, chỉ có quyền đọc, tìm kiếm và có backup Cold – Là thư mục chứa dữ liệu đã cũ, hiếm khi thực hiện tìm kiếm hoặc có thể

đã được nén lại và vẫn cung cấp khả năng tìm kiếm, có backup và được coi là tầng lưu trữ

Frozen – Thư mục chứa dữ liệu gần như được coi là xóa và đóng băng trên hệ

thống Tuy nhiên có thể khôi phục và cho phép đẩy dữ liệu trở lại về tầng Hot Nhược điểm của Splunk là chỉ thiết kế để xử lý dữ liệu online và chỉ sử dụng

nó như một dịch vụ Hơn nữa đây là một giải pháp đắt tiền, bản quyền và tất nhiên

là mã nguồn đóng Dịch vụ này chỉ hợp cho những doanh nghiệp giàu có Trong môi trường ở Việt Nam, bỏ qua vấn đề ngôn ngữ tiếng anh thì Splunk cũng vẫn là cái tên dịch vụ quá xa vời

Hình 2.5: Kiến trúc ELK

Nhược điểm là một hệ thống mã nguồn mở thay đổi theo từng ngày, mã nguồn không ổn định Tiềm ần nhiều lỗi mà khi phát sinh, chúng ta cũng phải trả phí dịch

vụ hỗ trợ, sửa lỗi Đa số các plug-in đi theo, hoạt động không được trơn tru Cần phải

có hành động kiểm tra mã nguồn và kiểm thử kỹ lưỡng trước khi sử dụng tránh các đoạn mã độc Lựa chọn ELK miễn phí để triển khai một dịch vụ thử nghiệm và học hỏi từ mô hình không phải là một sự lựa chọn tệ hại Nhưng khi chúng ta cần một dịch vụ thực tế trong môi trường production thì ELK có lẽ chưa sẵn sàng để thực thi

Đôi khi chúng ta bỏ tiền và tìm

kiếm một giải pháp khác rẻ hơn và

cũng có thể sử dụng miễn phí Hệ

thống eLMS tiếp cận các giải pháp mã

nguồn mở liên quan từ hệ thống ELK

tối ưu và xây dựng mô hình ổn định

2.4 Các vấn đề tiếp cận

Chúng ta đưa ra vấn đề tiếp cận đọc các file dữ liệu Điển hình ở đây là file log Các file xml, metadata, csv hay các kiểu dữ liệu khác cũng sẽ sử dụng chung phương pháp đọc dữ liệu như vậy Trường hợp các dữ liệu khá đặc biệt như file đã

bị mã hóa hay định dạng khó đọc bằng phương pháp thông thường eLMS cho phép người dùng tự định nghĩa bộ đọc và thu thập Shipper dưới dạng plugin Để tổng quát hóa kiểu dữ liệu file không đồng nhất Ở đây, chúng ta đưa ra các chiến lược đọc một file dữ liệu log như thế nào

2.4.1 Đọc dữ liệu log mới sinh ra

Phương pháp 1: Lập lịch cho hệ thống quản lý log eLMS thực hiện truy vấn

các files log cứ x phút một lần cho dữ liệu mới Phương pháp đơn giản nhất là đọc file log và lặp qua tất cả các dòng từ thời điểm khai báo, cố gắng tìm kiếm những dòng log mới sinh ra trong x phút đó Chúng ta phải thực hiện xác định các mốc điểm thời gian bắt đầu và nó sẽ chỉ ra những dòng log mới thêm trong x phút

Có 2 cách xác định điểm thời gian:

 Cách 1: Xác định điểm thời gian bắt đầu ghi log Start và kết thúc

ở thời điểm Start + x phút: Start = Điểm bắt đầu, End = Start + x*60

 Cách 2: Xác định thời điểm kết thúc ghi log End (now) và bắt đầu ở thời điểm End – x phút: End = Thời điểm kết thúc, Start = End –

x*60

Với 2 cách như trên, về mặt xử lý chung là giống nhau tuy nhiên sẽ khác nhau

về cách xác định mốc là tham số và cũng khác nhau về mặt ý nghĩa Với cách thứ nhất xác định thời điểm bắt đầu thực hiện đọc và xác định thời điểm kết thúc (có thể không phải là thời gian hiện tại) để lấy được dữ liệu sinh ra trong khoảng x phút Còn với cách thứ hai, có nghĩa rằng đã có dữ liệu ghi vào trong x phút cuối cùng Hệ thống sẽ thực hiện đọc và lấy dữ liệu đó mà không cần phải quan tâm tới thời điểm bắt đầu ghi log

Để hình dung vấn đề này trong lập trình cơ bản sẽ tương tự như 2 đoạn mã sau:

@log= File.open( path )

@starting_at = (constant)

@ending_at = Time.parse( starting_at + x*60 )