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

ĐẠ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 hoàn thành sở nghiên cứu, tổng hợp phát triển nghiên cứu giải pháp tốt quy trình xử lý tích hợp liệu có Luận văn mới, đề xuất luận văn thực hiện, qua trình nghiên cứu đưa không chép nguyên từ nguồn tài liệu 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 xin gửi lời cảm ơn chân thành biết ơn sâu sắc tới TS Nguyễn Văn Nam, người thầy bảo hướng dẫn tận tình cho suốt trình nghiên cứu khoa học thực luận văn Tôi xin chân thành cảm ơn giúp đỡ góp ý nhiệt tình Anh/Chị/Em trung tâm phần mềm FIS-Bank thuộc công ty Hệ thống thông tin FPT tạo điều kiện thuận lợi cho thời gian hoàn thành môn học suốt trình làm luận văn tốt nghiệp Và cuối cùng, xin gửi lời cảm ơn tới gia đình, người thân bạn bè – Những người bên lúc khó khăn nhất, động viên khuyến khích sống 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 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 liệu lớn không đồng 1.1.1 Log - liệu không đồng 1.1.2 Các cấp độ log [2][3] 1.1.3 Chi tiết Log File [1][4][5] 1.1.4 Tại phân tích liệu log 1.2 Khó khăn việc thực hệ thống tích hợp liệu không đồng 11 1.3 Khó khăn thực xử lý tích hợp 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 quản lý tích hợp liệu tập trung 14 2.2.1 Vòng đời xử lý hệ thống tích hợp không đồng [1][11] 14 2.2.2 Chi tiết thu thập liệu Shipper 16 2.2.3 Chi tiết hàng đợi 18 2.2.4 Chi tiết phân giải liệu Parser 19 2.2.5 Chi tiết Database 20 2.2.6 Chi tiết Client 22 2.3 Nền tảng từ hệ thống 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 liệu log sinh 30 2.4.2 Đọc 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ữ liệu 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 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 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 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ở 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 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 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 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 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 MỞ ĐẦU Đặt vấn đề Ngày nay, việc thực giám sát máy chủ server hành động thực cần thiết quan trọng, giúp cho quản trị hệ thống theo dõi hoạt động người sử dụng nhằm cải thiện khả quản lý hệ thống, quản lý người dùng, quản lý vấn đề cân tải để phát công DDoS Thông thường, việc giám sát, theo dõi máy chủ server dựa vào nhật ký file liệu ghi lại Tuy nhiên, hệ thống quản lý liệu coi đắt đỏ cho việc thu thập, tích hợp, lưu trữ, tìm kiếm phân tích liệu Trong luận văn trình bày phương pháp xây dựng hệ thống quản lý tích hợp liệu tập trung với hiệu suất tối ưu, viết tắt eLMS (Efficient Log Management System) – Một hệ thống có kiến trúc thiết kế nhẹ nhàng, mềm dẻo có khả mở rộng Trong eLMS, file liệu thu thập từ nhiều nguồn từ nhiều server khác Lưu trữ mô hình có khả kết hợp thêm nhiều Plug-in, tích hợp việc lập mục index phân tích liệu nhanh chóng Hệ thống eLMS hoạt động chế độ online offline, cung cấp giao diện hiển thị thông số giám sát, thống kê dựa liệu thời gian thực Hiệu suất eLMS đánh giá tổng thể vài trường hợp nghiên cứu Cơ sở khoa học thực tiễn luận văn dựa vấn đề tích hợp xử lý liệu không đồng – Log, xml, meta-data liệu tương tự Để tổng quát kiểu liệu luận văn đề cập tới vấn đề xử lý tích hợp liệu log tập trung Log coi liệu lớn kích thước thường xuyên tăng trưởng theo thời gian Việc quản lý log ứng dụng xử lý liệu lớn mà thường hay biết đến với tảng Hadoop Tuy nhiên, Hadoop chủ yếu hỗ trợ hệ thống có quy mô lớn Google, Yahoo, Đối với hệ thống cỡ vừa nhỏ, Hadoop trở nên cồng kềnh, đắt đỏ, không thực tế để thực Hơn nữa, Nó không đủ nhanh cho việc lý liệu online Luận văn hướng đến xây dựng hệ thống quản lý tích hợp nhẹ xử lý thời gian thực để việc sử dụng có ích 52 Thành phần cung cấp chức theo dõi tình trạng liệu file đánh dấu trạng thái Nó sử dụng công nghệ streaming để vận chuyển dòng liệu tích hợp tới thành phần eLMS-parser Ngoài xử lý chạy file liệu offline với dung lượng lớn Chúng ta sử dụng file cấu hình quản lý tiến trình eLMS-shipper chạy ngầm client, nơi mà thực giám sát liệu tích hợp Nó bao gồm thông tin Kafka server eLMS-parser server Ngoài ra, bao gồm thông tin định nghĩa regex cho lọc, tag nhãn liệu để lọc liệu dòng liệu, chuyển định dạng key value json thành phần xử lý eLMS-parser Layer 2: Message Queue [9] Bởi nhiều ưu điểm tảng đến từ Apache Kafka trình bày bên Hệ thống eLMS sử dụng Apache Kafka đóng vai trò hàng đợi thay Redis eLMS-shipper thực nhiệm vụ gửi luồng liệu đẩy vào Kafka Nó nhận tất liệu đến từ client lưu tạm vào phân vùng cụ thể công cụ Zookeeper Tại thời điểm, xảy nhiều trường hợp eLMS-parser bận xử lý quay lại kéo liệu từ kafka để xử lý Thì liệu giữ lại Kafka Do mà eLMS đảm bảo liệu không bị mát Trừ ổ đĩa bị tràn dung lượng Chi tiết hàng đợi sử dụng hệ thống eLMS: eLMS không sử dụng hàng đợi DB lưu trữ liệu tạm thời giống Redis mà áp dụng giải pháp xử lý quay vòng Kafka 53 Hình 3.2: Xử lý vòng tròn Với mô hình này, eLMS-shipper thực gửi luồng liệu task nhỏ tới thành phần gọi Message Cycle Nó nhận tất liệu từ eLMS-shipper gửi sang lưu tạm vào phân vùng cụ thể, nối đuôi theo thứ tự thời gian chúng gửi tới Hình 3.3: Lưu trữ Message Cycle Tại thời điểm eLMS-parser bận xử lý chưa thể nhận thêm liệu Message Cylce coi gói tin gói tin đến thực lưu lại lần vào phân vùng Điều xảy quay vòng giống đập nước [20] 54 Hình 3.4 Quay vòng phân vùng lưu trữ liệu Bởi sử dụng công nghệ streaming, eLMS-parser quay lại xử lý, có liệu thời gian thực Khi có bất thường xảy eLMS-parser Message Cycle tiếp tục đẩy liệu sang, vòng liệu nói tới phình to Tuy nhiên, tới ngưỡng định mà cấu hình server Có thể tạm dừng không nhận thêm liệu từ eLMS-shipper lệnh cho eLMS-shipper ngưng hoạt động Message Cycle Queue có khác Mô hình sau giải thích rõ chế module Hình 3.5: Hàng đợi Queue Hình 3.6: Message Cycle Layer 3: eLMS-parser Chúng ta phát triển thành phần dựa mã nguồn Logstash Nó giữ lại thư viện lọc grok theo regex, xử lý đầu tới Elasticsearch Và tùy biến thành xử lý riêng biệt controller Việc xử lý controller luồng bao gồm thành phần sau: 1/ Receiver: Thành phần nhận liệu trực tiếp từ eLMS-shipper kéo liệu từ hàng đợi Kafka để xử lý Việc lắng nghe liệu eLMS-parser kết nối tới thành phần eLMS-shipper Kafka, để thành phần có liệu bên xử lý Receiver nhận 2/ Bussiness: Thành phần xử lý nghiệp vụ hệ thống Nó cung cấp xử lý nhiệm vụ nặng nề: Lọc liệu grok, format cấu trúc chung, đánh dấu thẻ tags (success, error, warn) thực phân loại vào category 55 khác dựa phân lớp mô hình Data Mining xây dựng sẵn từ liệu khứ Việc xử lý cuối thành phần trả lại liệu định dạng JSON, chứa liệu với trường có ý nghĩa dạng key-value Ví dụ, thành phần business nhận đầu vào với dòng liệu log sau: 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 Qua xử lý thành phần business, nhận liệu đầu với định dạng JSON sau: { "Datetime": "3/12/2015 1:04:04 PM", "Thread" : "17", "Host" : "192.167.26.1", "Facility": "16", "severity": "6", "datetransfer": "Mar 12 13:03:58", "message": "pf: 00:00:00.004827 rule" } 3/ DAE (Data Access Easticsearch): Thành phần cung cấp thư viện API cho mục đích read/write/query với Elasticsearch Do phải sử dụng thêm file cấu hình server cho thành phần, nên có vài ghi tới file cấu hình với tham số quan trọng cho thành phần sau: Ghi 1/ Receiver: {shipper_port, kafka_port} Việc gửi liệu từ eLMS-shipper  eLMS-parser từ hàng đợi Kafka  eLMS-parser sử dụng tới hai cổng khác nhau, giống tùy ý Chúng ta xây dựng tiện ích quản lý cổng dashboard để bật/tắt việc kết nối từ eLMS-shipper  KafKa từ Kafka  eLMS-parser Mặc định eLMS-parser mở cổng riêng cho thành phần eLMSshipper cổng khác cho thành phần Kafka Ví dụ: shipper_port=1234, kafka_port=5678 Điều cho phép chạy song song, app-server dùng hàng đợi Kafka app-server khác không sử dụng hàng đợi kiến trúc Ngoài giúp ích cho việc ưu tiên đẩy nhanh liệu quan trọng lên 56 Ghi Elasticsearch{flush_size, idle_flush_time, replication} flush_size: Nhằm tăng hiệu suất đánh số index ES, thành phần Business xử lý đủ khối lượng liệu gửi đến thực gọi API Bulk để lưu trữ vào ES Ví dụ: flush_size = 10 10 dòng liệu xử lý xong đẩy vào ES idle_flush_time: Khi mà flush_size chưa nhận đủ số lượng, thành phần Business xử lý vượt khoảng thời gian định Thì để đảm bảo tỷ lệ truyền tải liệu không đồng đều, không đợi việc xử lý lâu, vượt ngưỡng thời gian mà idle_flush_time khai báo thực đẩy liệu vào ES Replication: Thiết lập loại Replication mà ES sử dụng có hai loại “async” “notsync” Nếu khai báo “async” việc yêu cầu đánh số index thực sau liệu ghi vào sharding ES Nếu khai báo “notsync”, hệ thống không tự động đánh index Mặc định, eLMS khai báo replication =“async” Ghi Dành cho việc triển khai hệ thống Nếu không không sử dụng thành phần Kafka việc triển khai hệ thống, việc cấu hình thành phần: eLMS-shipper, eLMS-parser ES Khi việc triển khai eLMS-parser ES server chung, sử dụng nhãn "embedded" để khai báo việc sử dụng trực tiếp thư viện jar ES Mặt khác, việc triển khai cài đặt eLMS-parser Elasticsearch khác server, cần phải có thông tin địa host, mật truy cập để vận chuyển đẩy liệu vào ES Trường hợp khác, sử dụng cài đặt thành phần Kafka, tham số cấu hình tương tự Nhưng eLMS-parser ngắt kết nối tới thành phần eLMSshipper kết nối tới thành phần Kafka Việc triển khai mạng network có hiệu tối ưu Khi khác mạng network, phải xây dựng thêm chế bảo mật xử lý vấn đề liên quan đến tường lửa Layer 4: Elasticsearch Thành phần lưu trữ đánh số index liệu Việc đánh index liệu sử dụng số tăng dần, định dạng năm, tháng, ngày YYYYMMDD, với số ngày tăng đặn Bên cạnh đó, với ES thiết lập để lưu trữ liệu node: Hot, warm, cold 57 Node “Hot”: Là liệu cập nhật thời gian thực có khoảng thời gian refresh lại thấp cho index, việc query liệu node "hot" làm cho nhớ cache query ES nhiều ý nghĩa Node “Warm”: Các index warm cập nhật vào đêm, tuần thiết lập người dùng Nó lưu trữ liệu cập nhật gần thường xuyên truy vấn Node “Cold”: Khi liệu lưu trữ vượt ngưỡng thời gian định chuyển trạng thái từ node warm sang node cold Nó lưu trữ liệu cho tháng lâu truy vấn cho việc tìm kiếm liệu Ví dụ: "index.routing.allocation.Exclude.tag" : "hot" "index.routing.allocation.include.tag" : "warm", "index.routing.allocation.include.tag" : "cold" Layer 5: Analayzer library and Dashboard [8] Trên dashboard, hệ thống cho phép hiển thị liệu, đồ thị thống kê, quản lý thông tin eLMS-shipper theo dõi, quản lý file cấu hình Ngoài ra, thành phần gọi controller Analayzer  business  DAE để truy vấn tới ES trả liệu để thống kê người sử dụng Chúng ta sử dụng vài công nghệ truyền tải liệu giống Websocket từ server xuống client Cứ ES có thêm liệu đẩy vào tự động gửi thành phần Analyzer để hiển thị liệu thời gian thực Công nghệ tương tự chế phần mềm chat trực tuyến Ở thành phần Analayzer cần thực câu lệnh truy vấn để lập biểu đồ thống kê sử dụng công nghệ Node.js (gửi liệu xuống biểu đồ) Nó hỗ trợ chế truyền tải công nghệ comet hay Websocket Và sử dụng công nghệ d3.js chart.js để tạo lập biểu đồ 58 3.1.2 eLMS đơn luồng Hình 3.7: Mô hình eLMS đơn luồng Với kiểu mô hình kiến trúc này, đơn giản lược bỏ thành phần trung gian hàng đợi Tập trung vào cải thiện, nâng cấp phần cứng server Các server chủ yếu cài đặt thành phần eLMS-parser Elasticsearch Một eLMS-parser đủ mạnh, bắt kịp tốc độ xử lý với liệu chuyển đến trực tiếp việc đọc file liệu coi xử liệu thời gian thực Với mô hình lớn hơn, server cài đặt eLMS-parser không đủ xử lý, hoàn toàn triển khai với hai nhiều server khác cài đặt thêm eLMS-parser Tất nhiên, giải thích trên, việc sử dụng mô nhằm đạt hiệu suất thời gian tối ưu Thì nhược điểm gặp phải mát liệu trình xử lý Nếu điều chấp nhận được, mô hình triển khai 59 Triển khai mô hình sở eLMS Với việc xây dựng eLMS với kiến trúc trên, lựa chọn giải pháp phát triển layer dạng plugin 3.2 Hình 3.8: eLMS với thành phần plug-in Kiến trúc thiết kế chia thành plug-in để mềm dẻo dễ dàng mở rộng Chúng ta xây dựng kiến trúc eLMS dựa plug-in tích hợp bao gồm layer File config.inf thiết lập client, đọc thành phần ẩn eLMS-shipper Lấy thông tin tất plug-in địa host Elasticsearch File cấu hình có nội dung chứa thông tin cụ thể sau: 1/ Inputs: Danh sách nguồn liệu client: Như đường dẫn file log, thư mục log, cổng TCP, UDP… 2/ eLMS-grok: Khai báo thành phần regex mẫu mà liệu cần phải matching để thực chuẩn cấu trúc phân loại liệu 3/ Kafka: Thiết lập thông tin server Kafka Nếu không sử dụng Kafka, khai báo không cần thiết Nếu sử dụng, hệ thống cung cấp khai báo hai lựa chọn cho: {“embedded” “ip”} 4/ eLMS-parser: Tùy chọn thiết lập server cài đặt thành phần eLMS-parser, cung cấp hai lựa chọn cho người dùng: {“embedded” “ip”} Ngoài ra, sử dụng thêm file cấu hình server chứa lựa chọn thông tin eLMS-parser kết nối tới Elasticsearch 60 Như vậy, hệ thống eLMS bước thay đổi giải pháp hệ thống ELK số giai đoạn xử lý liệu nhận tối ưu như: Bổ sung giải pháp đọc liệu lớn (offline) Cải tiến grok thành phần eLMS-parser, việc xử lý matching tối ưu Thay đổi chế hàng đợi, việc sử dụng Apache Kafka nói liệu bảo toàn so với việc sử dụng hàng đợi Queue Redis Thay đổi cấu trúc ELK, chia nhỏ cho trường hợp sử dụng, loại bỏ thành phần, đoạn mã không phù hợp Thay đổi cấu trúc file cấu hình client đọc eLMSshipper Chương trình eLMS-shipper chạy dịch vụ ngầm định, không bật hình console logstash (đóng console có nghĩa kết thúc việc giám sát) Cải thiện vấn đề gán số index cho liệu Thực xây dựng thành phần font-end sử dụng thành phần Analayzer để truy vấn tới ES kiến trúc xây dựng chức giao diện hiển thị Bổ sung chế xóa tự động Elasticsearch (mô hình ELK chế này) Mở rộng plugin hàng đợi (có thể sử dụng lại plugin có ELK) 3.3 Thực nghiệm Hệ thống eLMS triển khai thực nghiệm với mô hình nhỏ, sử dụng appserver có nguồn log server tập trung cài đặt chung hai thành phần eLMSparser ES Hình 3.9: Sơ đồ thực nghiệm 61 Thực thử nghiệm với file log từ 100kb tới 100Mb, sử dụng công cụ benchmark để đo hiệu xử lý hai hệ thống ELK eLMS Kết thu sau (tham khảo file excel đính kèm) : Hình 3.10: Thông số kết Thực vẽ đồ thị với công cụ gnuplot, màu đỏ biểu diễn thời gian mà hệ thống eLMS sử dụng để đọc file đẩy vào Elasticsearch Màu xanh thời gian mà hệ thống ELK sử dụng với chế hàng đợi đẩy liệu vào Elasticsearch Hình 3.11: Biểu đồ thời gian so sánh Cách thức đo thời gian thực thi, với hệ thống ELK thực viết kịch sau: 62 module Tests class FileSize1MbToRedis def initialize require "logstash/pipeline" @pipeline = LogStash::Pipeline.new( "C:/logfile/logsize1Mb.log" start_position => "beginning" } } output { redis { host => "127.0.0.1" data_type => "list" key => "logsize1Mb" } } CONFIG @queue = @pipeline.instance_eval { @filter_to_output } @worker = Thread.new { @pipeline.outputworker } end def run(event) @queue.push(event) end end class RedisToElasticSearch def initialize require "logstash/pipeline" @pipeline = LogStash::Pipeline.new( "list" key => "logsize1Mb" } } output { elasticsearch { embedded => true } } CONFIG @queue = @pipeline.instance_eval { @filter_to_output } @worker = Thread.new { @pipeline.outputworker } end def run(event) @queue.push(event) end end end Benchmark.bm |bm| tests = [ [Tests::RedisToElasticSearch.new, 31995] ] tests.each |test, count| bm.report(test.to_s) event = LogStash::Event.new i = count while i > test.run(event) i -= end 63 end end end Lưu tên filetest.rb mở công cụ command line, trỏ vào thư mục bin công cụ logstash thực lệnh sau bin/logstash rspec scripts/filetest.rb Với hệ thống eLMS, sử dụng thư viện benchmark để đo thời gian thực thi hàm đẩy liệu trực tiếp từ shipper tới Elasticsearch require 'benchmark' def pushlog Benchmark.bm |bm| bm.report(test.to_s) Parser.new.pushlog end end end 3.4 Kết luận  Việc xử lý log nhanh toán phổ biến hệ thống liệu lớn không đồng  Có nhiều giải pháp như: Hadoop, Splunk, ELK Các giải pháp có nhiều nhược điểm: Cồng kềnh, đắt đỏ khó xử lý thời gian thực  Chúng đề xuất mô hình eLMS đơn giản, nhanh, hiệu cách tối ưu hóa module hệ thống liệu lớn không đồng  Thực nghiệm với liệu nhiều kích cỡ khác cho thấy eLMS xử lý nhanh, gần với thời gian thực nhiều (10~15 lần) so với hệ thống có  Với kết đạt được, thực submit báo với tiêu đề: “An Efficient Log Management Framework” kỉ niệm 20 năm thành lập khoa công nghệ thông tin 3.5 Các công việc  Việc thử nghiệm eLMS cần tiếp tục với liệu có kích cỡ lớn vài hệ thống Cloud 64   eLMS cần cải tiến việc xử lý hàng đợi (Queue) việc lưu trữ (Storage) mức độ hệ thống lớn nhiều Cải tiến thuật toán phân loại liệu, áp dụng số giải thuật Data Mining 65 KẾT LUẬN Luận văn đề cập tới vấn đề tích hợp quản lý tích hợp liệu tập trung, mục đích thu thập phân tích thời gian thực mức mô hình tối ưu hóa Đây vấn đề quan tâm nghiên cứu nhằm giúp khai thác sử dụng thông tin nhật ký nhằm thông báo, cảnh báo dự báo tình mà hệ thống gặp phải Về lý thuyết, luận văn trình bày tổng quan nguồn gốc liệu không đồng nhất, lý giải cần thiết phải tích hợp liệu tập trung, nêu rõ khó khăn gặp phải thực hệ thống cuối đề xuất giải pháp từ kiến trúc mô hình, lựa chọn công nghệ xây dựng phần mềm quản lý thời gian thực Về thử nghiệm, luận văn có thực xây dựng chương trình quy mô nhỏ, lắng nghe liệu log vài server khác nhau, thực bước filter/format/tag để đưa cấu trúc chung nguồn log vận chuyển trực tiếp đến Elasticsearch để lưu trữ, cho phép người dùng tìm kiếm, dự đoán cung cấp giao diện hiển thị thông tin tình trạng hệ thống hoạt động Trong trình thực luận văn cố gắng tập trung tìm hiểu vấn đề cốt lõi đề tài Tuy nhiên trình độ có hạn thời gian không cho phép nên không tránh có hạn chế thiếu sót Tôi mong nhận nhận xét góp ý thầy cô giao, bạn bè, đồng nghiệp người quan tâm để hoàn thiện nghiên cứu 66 TÀI LIỆU THAM KHẢO [1] The Logstash Book Version v1.4.3 Publisher by You Lulu Inc James Turnbull 2014 [2] A Gentle Introduction to ROS, chapter 4: Log messages Publisher by CreateSpace Independent Publishing Platform Jason M O’Kane 2013 [3] Oracle JDBC Logging using java.util.logging, An Oracle White Paper 2009 [4] I Heart Logs Publisher [5] System Logging and Log Analysis (AKA: Everything we know and hate about system logging Marcus J Ranum 2014 [6] Patricio Córdova Analysis of Real Time Stream Processing Systems Considering Latency University of Toronto patricio@cs.toronto.edu 2015 [7] Centralised logging with rsyslog Peter Matulis 2009 [8] Radomır Sohlich, Jakub Janostık, Frantisek Spacek Centralized logging system based on WebSockets protocol 13th International Conference on telecommunications and informatics, Istanbul,Turkey 2014 [9] Jay Kreps , Neha Narkhede , Jun Rao Kafka: a Distributed Messaging System for Log Processing LinkedIn Corp 2015 [10] Arhs Cerebro Real-Time Engine, Business Analytics For All, http://www.ba4all.be [11] Centralized logging architecture series, http://logs101.com [12] Tom White 2009 Hadoop: The Definitive Guide (1st ed.) O'Reilly Media, Inc [13] Splunk system, Splunk® Inc Headquarters, http://www.splunk.com [14] Alberto Paro 2013 Elasticsearch Cookbook Packt Publishing [15] MIT College of Engineering University of Pune Real Time Generalized Log File Management and Analysis using Pattern Matching and Dynamic Clustering International Journal of Computer Applications (0975 8887) Volume 91 - No 16, April 2014 [16] Monitor everything part 3, Logstash Improvements https://ianunruh.com [17] Johnvey Hwang 2009 Splunk, innovation behind In Proceedings of the Symposium on Computer Human Interaction for the Management of Information Technology (CHiMiT '09) ACM, New York, NY, USA, , pages DOI=http://dx.doi.org/10.1145/1641587.1814304 [18] Alien Vault, Life Cycle of a Log, 2014, https://www.alienvault.com/doc-repo/usm/securityintelligence/AlienVault_Life_cycle_of_a_log.pdf Large Scale Log Analytics With Solr, Sematext group, http://blog.sematext.com In-stream big data processing, Ilya Katsov, Highly Scalable Blog, https://highlyscalable.wordpress.com [19] [20] by O'Reilly Media; edition Jay Kreps 2014 [...]... 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... 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... 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... 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... 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 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. .. 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 độ... 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... 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,... đồ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 ... tiễn đề tài Giải pháp tảng cho hệ thống tích hợp liệu lớn không đồng nhất Bố cục luận văn Luận văn chia làm chương: Chương 1: Sự cần thiết phải xử lý tích hợp liệu không đồng Chương giải thích...ĐẠ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... quản lý tích hợp liệu gặp phải khó khăn cần thiết phải quản lý tích hợp liệu tập trung Mở đầu cho vấn đề mà luận văn đề 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Ì?