Nghiên cứu và phát triển phương pháp truy vết phân tích và đánh giá luồng dịch vụ trong môi trường điện toán đám mây

Nghiên cứu và phát triển phương pháp truy vết phân tích và đánh giá luồng dịch vụ trong môi trường điện toán đám mây Nghiên cứu và phát triển phương pháp truy vết phân tích và đánh giá luồng dịch vụ trong môi trường điện toán đám mây luận văn tốt nghiệp thạc sĩ

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI Nguyễn Trọng Vĩnh NGHIÊN CỨU VÀ PHÁT TRIỂN PHƯƠNG PHÁP TRUY VẾT, PHÂN TÍCH VÀ ĐÁNH GIÁ LUỒNG DỊCH VỤ TRONG MƠI TRƯỜNG ĐIỆN TỐN ĐÁM MÂY Chun ngành: Hệ thống thông tin LUẬN VĂN THẠC SĨ KHOA HỌC HỆ THỐNG THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC Tiến sĩ Nguyễn Bình Minh Hà Nội – Năm 2019 MỤC LỤC MỤC LỤC LỜI CẢM ƠN LỜI CAM ĐOAN TÓM TẮT DANH MỤC CÁC THUẬT NGỮ CHÍNH DANH MỤC CÁC BẢNG DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ I PHẦN MỞ ĐẦU 10 Lý chọn đề tài 10 Hiểu biết lĩnh vực nghiên cứu lựa chọn 11 Mục đích, đối tượng, phạm vi nghiên cứu luận văn 11 3.1 Ý nghĩa khoa học 12 3.2 Ứng dụng thực tiễn 12 Tóm tắt đọng luận điểm đóng góp tác giả 12 Phương pháp nghiên cứu 12 5.1 Lý thuyết 12 5.2 Mô 13 5.3 Thực nghiệm 13 II NỘI DUNG 14 Cơ sở lý thuyết 14 1.1 Kiến trúc phần mềm truyền thống – monolithic 14 1.2 Kiến trúc phần mềm hướng dịch vụ – microservices 16 1.3 Quan sát – Observability 19 Các nghiên cứu liên quan 25 Mơ hình liệu đề xuất 27 3.1 Hướng tiếp cận 27 3.2 Mô hình liệu 29 3.3 Tích hợp liệu thông tin từ log, metrics trace 30 3.4 Biểu diễn liệu từ nguồn, đặc tính mơ hình liệu 31 Thử nghiệm đánh giá 34 4.1 Kịch 34 4.2 Mơ hình thử nghiệm tổng quan 34 4.3 Mơ hình triển khai thực tế 35 4.4 Kết thu 38 4.5 Đánh giá 41 III KẾT LUẬN 42 Những kết luận 42 Đóng góp kiến nghị sử dụng kết nghiên cứu luận văn 42 Hướng phát triển hoàn thiện kết tương lai 42 IV DANH MỤC CÁC TÀI LIỆU THAM KHẢO 44 V CHỈ MỤC 45 LỜI CẢM ƠN Trong trình học tập, nghiên cứu thực luận văn Thạc sỹ khoa học này, nhận nhiều dẫn tham vấn Xin gửi lời cảm ơn chân thành đến thày, cô giảng viên cán hỗ trợ giảng dạy thuộc trường Đại học Bách khoa Hà Nội, đặc biệt thày, cô giảng viên Viện Công nghệ Thông tin Truyền thông Đồng thời, xin gửi lời cảm ơn đến Tiến sĩ Nguyễn Bình Minh người hướng dẫn trực tiếp cho luận văn thạc sỹ tơi Cùng với đó, tơi xin gửi lời cảm ơn đến học viên khóa học có chia sẻ, phản biện q báu giúp tơi có nhìn nhiều chiều đề tài nghiên cứu Bên cạnh đó, hỗ trợ nhiệt tình đến từ đồng nghiệp (đến từ cơng ty Fujitsu Việt Nam Tập đồn Cơng nghiệp - Viễn thông Quân đội Viettel) hai năm vừa qua hỗ trợ lớn, nhờ có hỗ trợ đồng nghiệp mà tơi có tài nguyên ứng dụng thực tế để áp dụng phần nghiên cứu Ngồi ra, xin cảm ơn cộng đồng Open Infrastructure (trước VietOpenStack) Việt Nam dẫn dắt phát triện điện toán đám mây Việt Nam năm gần Nhờ mà tơi có hội gặp gỡ thảo luận với nhiều người có kiến thức khoa học ứng dụng thực tế liên quan đến cloud computing Việt Nam Cuối cùng, gia đình yếu tố khơng thể kể đến q trình tơi nghiên cứu hoàn thiện luận văn Xin gửi lời cảm ơn chân thành đến thành viên gia đình hỗ trợ động viên tinh thần cho gần hai năm vừa qua Hà Nội, tháng 04 năm 2019 LỜI CAM ĐOAN Tôi – Nguyễn Trọng Vĩnh – cam kết luận văn cơng trình nghiên cứu thân tơi hướng dẫn Tiến sĩ Nguyễn Bình Minh Các kết nghiên cứu nêu luân vặn trung thực, khơng chép cơng trình cơng bố khác Tất trích dẫn tham chiếu ghi rõ ràng Hà Nội, tháng 04 năm 2019 Xác nhận người hướng dẫn Tác giả luận văn Tiến sĩ Nguyễn Bình Minh Nguyễn Trọng Vĩnh TÓM TẮT Hiện nay, với phát triển ứng dụng mạnh mẽ hạ tầng cơng nghệ thơng tin, điện tốn đám mây dần trở thành yêu cầu tất yếu doanh nghiệp có quy mơ vừa trở lên đến lớn (như nhà mạng, nhà cung cấp dịch vụ hạ tầng công nghệ thông tin) Hạ tầng công nghệ thông tin phát triển đồng nghĩa với ứng dụng chạy hạ tầng cởi trói phát triển mạnh mẽ nhằm tận dụng tối đa lợi mà hạ tầng mang lại Trước đây, ứng dụng thường thiết kế với kiến trúc monolithics (nguyên khối) tất thành phần phục vụ logic nghiệp vụ phát triển đóng gói đầy đủ để triển khai Kiến trúc đơn giản để phát triển, nhiên, ứng dụng trở nên lớn dần theo thời gian, để phục vụ nhiều người sử dụng, nhiều chức kiến trúc tỏ khơng cịn phù hợp Để tận dụng sức mạnh, mềm dẻo, tính linh hoạt hạ tầng điện toán đám mây, khái niệm ứng dụng cloudnative (Cloud Native Computing Foundation, 2019) đời Trong đó, kiến trúc ứng dụng microservices tiêu chí giúp ứng dụng sẵn sàng chạy tảng điện toán đám mây hiệu Để đánh giá mức độ hiệu phù hợp với tảng điện tốn đám mây, khơng thể khơng kể đến theo dõi (monitoring) quan sát (observability) Monitoring chủ đề nói đến nhiều trước cơng trình nghiên cứu Tuy nhiên, gần đây, observability lại chủ đề dần quan tâm Đối với ứng dụng nay, việc ghi nhật ký ứng dụng (log), đo đạc thơng số ứng dụng q trình chạy (metrics) truy vết luồng dịch vụ (trace) công việc thiếu, chúng thay Log, metrics trace ba trụ cột Observability Trước đây, với ứng dụng phát triển theo kiến trúc monolithic, log metrics cung cấp phần thông tin giúp đội ngũ phát triển vận hành xử lý vấn đề xảy với hệ thống ứng dụng Tuy nhiên, với ứng dụng cloud-native nay, ứng dụng khơng cịn phát triển ngun khối, khơng triển khai đơn vị phần cứng mà nhiều đơn vị khác mặt logic, chí khác mặt địa lý Từ phân tán này, có log metrics liệu tồn thể ứng dụng rời rạc Ngay có giải pháp thu thập lưu trữ log, metrics cách tập trung việc thiếu thơng tin mối quan hệ dịch vụ nằm tổng thể ứng dụng gây khó khăn lớn cho đội ngũ phát triển vận hành Do đó, nhu cầu thu thập thiết lập mối tương quan ba trụ cột observability trở nên cần thiết Trong nghiên cứu này, cá nhân đưa đề xuất mơ hình liệu thể tính tương quan từ ba nguồn liệu riêng biệt kể trên, ứng dụng mơ hình liệu vào ứng dụng thực tế Kết thu từ nghiên cứu đề tài giúp đội ngũ phát triển vận hành tối ưu thời gian DANH MỤC CÁC THUẬT NGỮ CHÍNH STT 10 11 12 13 14 15 16 17 18 Thuật ngữ Diễn giải Open Infrastructure Hạ tầng xây dựng phần mềm, giải pháp mã nguồn mở cloud computing Điện toán đám mây monolithics Kiến trúc phần mềm nguyên khối truyền thống microservices Kiến trúc phần mềm hướng dịch vụ, chia nhỏ thành phần phần mềm thành nhiều dịch vụ nhỏ cloud native Công nghệ liên quan đến ứng dụng đại, chạy môi trường điện toán đám mây monitoring Giám sát ứng dụng, thường thực tự động observability Quan sát, thường có tương tác người logging Ghi nhật ký ứng dụng, hệ thống metrics Đo đạc thông số ứng dụng triển khai tracing Truy vết dịch vụ distributed tracing Truy vết dịch vụ môi trường phân tán bare metal Máy thật, server vật lý virtual machine Máy ảo container Giải pháp ảo hóa dựa container JVM Java Virtual Machine – Máy ảo chạy mã Java CI/CD Continuous Integration/Continuous Delivery/ Continuous Deployment – Tích hợp liên tục/Chuyển giao liên tục/Triển khai liên tục DAG Directed Acyclic Graph – Đồ có hương khơng có chu trình tree Cây, đồ thị có hướng khơng có chu trình, nút có nút cha, riêng nút gốc khơng có cha DANH MỤC CÁC BẢNG Bảng Tổng hợp nghiên cứu liên quan 26 Bảng Biểu diễn mơ hình liệu mã JSON 32 Bảng Một ví dụ cho mơ hình liệu 33 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ Hình Một ứng dụng web truyền thống sử dụng kiến trúc nguyên khối (Richardson, 2018) 15 Hình Ứng dụng thiết kế theo mơ hình kiến trúc hướng dịch vụ (Richardson, 2018) 18 Hình Các thành phần liên quan đến kiến trúc microservices (Richardson, 2018) 19 Hình Biểu diễn kết ghi log hệ thống 21 Hình Mức độ sử dụng nhớ JVM thời gian gần 23 Hình Một trace với thơng tin thể hình ảnh 23 Hình Luân chuyển metadata theo request qua dịch vụ (Shkuro, 2019) 25 Hình Luồng gỡ rối, sửa lỗi ứng dụng tiêu biểu (Loki, 2018) 27 Hình Mơ hình liệu đề xuất, kết hợp thông tin từ metrics, log trace 29 Hình 10 Thu thập nguồn liệu tích hợp vào mơ hình chung 31 Hình 11 Mơ hình thử nghiệm hệ thống tổng quan 34 Hình 12 Mơ hình triển khai thực tế để kiểm chứng 35 Hình 13 Bên máy ảo chạy dịch vụ microservices 36 Hình 14 Mơ hình triển khai, liên kết dịch vụ hệ thống 37 Hình 15 Thơng tin liên quan đến log, metrics trace thu 39 Hình 16 Một request có lỗi liên quan đến timeout 40 I PHẦN MỞ ĐẦU Lý chọn đề tài Hiện nay, hệ thống phân tán phát triển mạnh mẽ Kèm theo đó, nhiều mơ hình phân tán phát triển triển khai Điều xuất phát từ nhu cầu tính tốn, xử lý thông tin, liệu quy mô lớn hệ thống mở rộng dịch vụ quy mơ lớn tồn cầu nhà cung cấp dịch vụ trực tuyến Tính phân tán xu tất yếu việc triển khai hệ thống phần mềm Trong hệ thống có tính phân tán, dịch vụ hoạt động nhiều nơi khác Về mặt hạ tầng cho ứng dụng, khác mức máy ảo (virtual machine), máy thật (computer, bare metal) Về mặt địa lý, khác mức địa phương hay châu lục Trước đây, ứng dụng công nghệ thông tin thường phát triển triển khai theo kiến trúc nguyên khối (monolithic) Hiện nay, với xu tất yếu việc triển khai phân tán để tối ưu tốt hiệu sử dụng tài nguyên hạ tầng điện tốn đám mây kiến trúc monolithic trở nên khơng cịn phù hợp Các ứng dụng phát triển theo hướng tối ưu lợi mà hạ tầng điện toán đám mây mang lại (cloud-native applications) dần xuất để khỏa lấp vào chỗ trống kể Một yếu tố để thể ứng dụng sẵn sàng tối ưu chạy tảng điện tốn đám mây kiến trúc ứng dụng hướng dịch vụ (microservices) Để phát triển vận hành ứng dụng, cho dù theo kiến trúc monolithic hay microservice thường thực ghi nhật ký ứng dụng (log), thu thập liệu đo đạc từ ứng dụng trình vận hành (metrics), thực truy vết luồng dịch vụ (trace) Đối với hệ thống theo kiến trúc monolithic, thông thường, log metrics cung cấp phần thông tin phục vụ trình phát triển vận hành Tuy nhiên, ứng dụng phát triển theo kiến trúc microservices hai phần chưa đủ Log metrics có tính địa phương (local) nơi mà nguồn liệu sinh (log ghi ứng dụng, metrics thu thập nơi mà ứng dụng triển khai) Hai nguồn liệu thiếu thông tin quan trọng mối liên quan dịch vụ luồng liệu hệ thống Khi đó, trace nguồn liệu bổ trợ tốt cho việc phát triển vận hành hệ thống ứng dụng 10 Để giải vấn đề nêu trên, cá nhân đồng nghiệp thực thu thập metrics thời điểm mà log trace sinh sau ghi nhận chung vào phần kết thu thập để có đầy đủ log, metrics vả trace để tiến hành gửi hệ thống lưu trữ phân tích tập trung Hình 10 Thu thập nguồn liệu tích hợp vào mơ hình chung 3.4 Biểu diễn liệu từ nguồn, đặc tính mơ hình liệu Mơ hình liệu đề xuất có đảm bảo thơng tin liên quan đến log, metrics trace Khi có đủ thông tin liên quan đế ba trụ cột observability, việc đưa định xử lý vấn đề trở nên nhanh chóng 31 Về mặt tổng quan, ghi mơ hình liệu chứa thông tin liên quan đến ba nguồn log, metrics, trace (đối với hệ thống ứng dụng thử nghiệm mơ hình liệu tùy biến cho phù hợp) { // Trace information "traceID": uuid, "spanID": uuid, "startTime": Timestamp, "duration": int, // Metrics & other information "tags": [ { "key": string, "type": string, "value": any }, ], // Log "logs": [ { "timestamp": Timestamp, "fields": [ { "key": string, "type": string, "value": any }, ] }, ] } Bảng Biểu diễn mơ hình liệu mã JSON Với mơ hình này, ghi tương ứng liệu có ghi nhận đủ thông tin log, metrics, trace đơn vị ghi Minh họa cho ghi liệu liên quan tham khảo (trong ghi bao gồm đủ liệu liên quan liệu phụ trợ khác triển khai thực tế): { "traceID": "f47e640e4c4a160b", "spanID": "f47e640e4c4a160b", "flags": 1, "operationName": "POST", "references": [], "startTime": 1553611594540000, "duration": 74541, "tags": [ { "key": "hikaricp.connections.timeout", "type": "string", 32 "value": "180" }, ], "logs": [ { "timestamp": 1553611594543000, "fields": [ { "key": "level", "type": "string", "value": "INFO" }, { "key": "logger", "type": "string", "value": "gateway.filter.pre.LogUserAgentFilter" }, { "key": "message", "type": "string", "value": "user 'TEST' use android with user-agent: Dalvik" }, { "key": "thread", "type": "string", "value": "http-nio-8060-exec-20" } ] }, ], "processID": "p1", "warnings": null } Bảng Một ví dụ cho mơ hình liệu Cách biểu diễn liệu chất cách thức mà trace lưu trữ sở liệu Điểm khác biệt lớn thơng tin liên quan đến log, metrics coi thông tin với trace, thơng tin có trường lưu trữ định nghĩa riêng biệt Việc biểu diễn dựa cách thức lưu trữ liệu Jaeger Tracing (Shkuro, 2019) Như ví dụ trên, metrics ghi nhận thành nhiều phần nhỏ mảng liệu Trong ví dụ có lưu lại metrics đến từ thông tin timeout dành cho kết nối đến cớ sở liệu, ngồi ra, thơng tin liên quan đến log thời điểm log ghi lại đầy đủ Với mơ hình liệu tính hợp thơng tin này, đưa thêm thông số liên quan đến metrics log vào tùy theo nhu cầu ý muốn Đội ngũ phát 33 triển đưa thêm thơng tin liên quan đến metrics khác mà họ quan tâm, kể đến thông tin liên quan đến CPU, RAM, chí I/O Thử nghiệm đánh giá Để khẳng định mơ hình liệu nêu có hiệu quả, cá nhân đồng nghiệp thực ứng dụng mơ hình liệu cho hệ thống phần mềm hoạt động thực tế công ty Hệ thống thiết kế theo kiến trúc microservices, có thực thu thập biểu diễn thông tin cách riêng rẽ đến từ ba nguồn log, metrics trace 4.1 Kịch Mặc dù hệ thống thiết kế để phục vụ nhiều nhu cầu giám sát, theo dõi, quan sát thực tế Tuy nhiên, để minh họa rõ nét cho nghiên cứu tập trung vào luồng xử lý lỗi mà Kịch sau: Nhận thông tin cảnh báo Thực quan sát thơng tin hệ thống có tích hợp mơ hình liệu Đưa định Thực xử lý 4.2 Mơ hình thử nghiệm tổng quan Hình 11 Mơ hình thử nghiệm hệ thống tổng quan 34 Thực kiểm chứng mơ hình liệu với hệ thống chạy theo kiến trúc microservices điển hình Trong đó, bên cạnh thành phần hệ thống theo kiến trúc microservices cịn có thành phần phụ trợ khác Load Balancer (dùng để san tải cho hệ thống), hệ thống dành cho observability bao gồm log, metrics trace với hệ thống lưu trữ 4.3 Mơ hình triển khai thực tế Hình 12 Mơ hình triển khai thực tế để kiểm chứng Theo mơ hình thành phần hệ thống kiểm chứng bao gồm sau: • Người dùng từ bên ngồi Internet • Public Load Balancer để phân tải cho hệ thống • Cụm API Gateway phục vụ cho hệ thống microservices phía sau • Cụm service discovery phục vụ từ điển dành cho API Gateway • Các cấu hình lưu trữ tập trung Centralize Configuration service • Hệ thống lưu trữ mã nguồn • Private Load Balancer dịch vụ nội giao tiếp với • Hệ thống phục vụ nhu cầu thu thập phân tích log riêng biệt • Hệ thống phục vụ nhu cầu thu thập metrics • Hệ thống phục vụ nhu cầu thu thập traces • Các dashboard để hiển thị trình diễn thơng tin cách trực quan, nguồn liệu từ hệ thống log, trace, metrics 35 • Các microservices triển khai máy ảo ứng dụng liên quan có cài đặt đầy đủ agent để thu thập log, metrics traces Hình 13 Hình 13 Bên máy ảo chạy dịch vụ microservices Trong máy ảo dịch vụ, có thành phần sau: • Container runtime (dùng docker) • Các container chạy dịch vụ hệ thống • Các container hỗ trợ khác liên quan đến observability: • Fluentd – thu thập log tồn hệ thống • Jaeger – thu thập thông tin trace ứng dụng • Các exporter – thu thập thơng tin liên quan đến metrics hệ thống 36 Hình 14 Mơ hình triển khai, liên kết dịch vụ hệ thống Hạ tầng triển khai thực tế có thơng số phần cứng • 14 VMs = services x VMs cấu hình CPU, GB RAM chạy dịch vụ • VMs cấu hình CPU, GB RAM chạy discovery service • VMs cấu hình CPU, GB RAM chạy configuration service • VMs chạy CPU, GB RAM API gateway • VMs cấu hình CPU, GB RAM cho trace collectors • VMs cấu hình CPU, GB RAM cho trace UI trace query • cặp LB public • cặp LB private • Back end lưu log trace chạy Elasticsearch cluster multinode • Back end lưu metrics chạy Prometheus nodes • Các containers chạy dịch vụ phụ trợ khác Kibana UI, Grafana 37 4.4 Kết thu Đối với trường hợp hệ thống hoạt động bình thường, thơng số rõ ràng khơng có khả nghi Hình 15 Ta quan sát kết logs metrics lưu trữ ổn định Đối với thông tin liên quan đến trace khơng có phần phát sinh vấn đề, thực khoảng thời gian ngắn cho phép Đối với trường hợp hệ thống gặp vấn đề, ta quan sát hình phía Các thông tin thể rõ vấn đề xảy hệ thống liệu Điều giúp cho đội ngũ phát triển nhanh chóng tìm vấn đề đưa phương án xử lý Thay phải vào thành phần riêng rẽ để theo dõi Hình 4, Hình 5, Hình 38 Hình 15 Thông tin liên quan đến log, metrics trace thu 39 Trong trường hợp này, dựa vào log nhiều thời gian để xác định vấn đề timeout gây Hình 16 Một request có lỗi liên quan đến timeout 40 4.5 Đánh giá Với mơ hình liệu này, thông tin liên quan đến log, metrics trace tổng hợp ghi Đội ngũ phát triển đưa thêm nguồn thông tin mà họ quan tâm vào phần mơ hình liệu đề cập trước tính khả mở linh hoạt mơ hình liệu Nhờ đó, hệ thống có vấn đề xảy ra, người vận hành cần nhìn vào phần liệu chung có tương đối đủ thơng tin để đưa định xử lý phù hợp 41 III KẾT LUẬN Những kết luận Như vậy, nghiên cứu hoàn thiện tính phù hợp mơ hình liệu thống Bước đầu, mơ hình chứng minh hiệu ứng dụng thực tế Trong trình gần hai năm thực đề tài, cá nhân trình bày số phần liên quan tới nghiên cứu 03 kiện công nghệ quốc tế liên quan đến hạ tầng đám mây (OpenStack Summit Sydney1 – Úc 2017, Vancouver2 – Canada 2018, Berlin3 – Đức 2018), xuất 01 trích dẫn trình bày (OpenStack Summit Boston4 – Mỹ 2017) – phần trình bày ghi hình đăng tải trang thức kiện, 01 workshop5 Đóng góp kiến nghị sử dụng kết nghiên cứu luận văn Kết luận văn hy vọng giúp nhóm nghiên cứu sau thực hồn thiện Bên cạnh đó, kết hỗ trợ cho đội ngũ phát triển ứng dụng dựa kiến trúc microservices triển khai tảng hạ tầng điện toán đám mây Hướng phát triển hoàn thiện kết tương lai Trong tương lai, để có nhiều thơng tin trực quan hơn, cá nhân nghiên cứu định hướng tiếp tục: • đẩy thêm phần thơng tin quan trọng vào mơ hình liệu (mở rộng thông tin) OpenStack OSprofiler ft CNCF OpenTracing: Distributed tracing from cloud through container – https://www.openstack.org/videos/summits/sydney-2017/openstack-osprofiler-ft-cncf-opentracing-distributedtracing-from-cloud-through-container OpenStack OSProfiler Overview: What is it? How does it work? – https://www.openstack.org/videos/summits/vancouver-2018/openstack-osprofiler-overview-what-is-it-howdoes-it-work Distributed Tracing in OpenStack - A new step forward – https://www.openstack.org/videos/summits/berlin2018/distributed-tracing-in-openstack-a-new-step-forward OSprofiler: Evaluating OpenStack – https://www.openstack.org/videos/summits/boston-2017/osprofilerevaluating-openstack Request tracing - Another RCA Approach for Multi-ring DHT Chord-based Environment – Workshop on IoT and WSN in Vietnam at USTH 2017 42 • thực tạo lập mối tương quan nguồn liệu, không dừng lại mức đưa nguồn liệu mối (nghiên cứu phương pháp) • tiếp tục thực làm cho kết trở nên trực quan (ứng dụng) Hy vọng, kết trợ giúp nhiều ứng dụng tương lai 43 IV DANH MỤC CÁC TÀI LIỆU THAM KHẢO Cantrill, B (2018, December 10) Visualizing Distributed Systems with Statemaps Observability Practitioners Summit at KubeCon/CloudNativeCon NA, USA Retrieved from https://sched.co/HfG2 Cloud Native Computing Foundation (2019) What is cloud native? Retrieved from Cloud Native Computing Foundation: https://www.cncf.io/about/faq/ Fowler, M (2014, March 25) Microservices Retrieved from https://www.martinfowler.com/articles/microservices.html Minh, N B., Phan, H., Ha, D Q., & Nguyen, G (2018) An Information-centric Approach for Slice Monitoring from Edge Devices to Clouds Procedia Computer Science, 130, 326 - 335 doi:https://doi.org/10.1016/j.procs.2018.04.046 Richardson, C (2018) Microservices Patterns Manning Publications Sambasivan, R R., Shafer, I., Mace, J., Sigelman, B H., Fonseca, R., & Ganger, G R (2016) Principled workflow-centric tracing of distributed systems In K A Marcos, C Brian, & D Yanlei, Proceedings of the Seventh ACM Symposium on Cloud Computing (pp 401-414) New York, NY, USA: ACM Shkuro, Y (2019) Mastering Distributed Tracing: analyzing performance in microservices and complex systems (A Waldron, S Jain, T Jacob, J Lovell, & G Gavas, Eds.) Packt Publishing Sigelman, B H., Barroso, L A., Burrows, M., Stephenson, P., Plakal, M., Beaver, D., Shanbhag, C (2010) Dapper, a Large-Scale Distributed Systems Tracing Infrastructure Google, Inc Retrieved from https://research.google.com/archive/papers/dapper-2010-1.pdf Sridharan, C (2018) Distributed Systems Observability O'Reilly Media, Inc 44 V CHỈ MỤC API gateway, 17 back-end, 16 bare metal, 10 CI/CD, 17 cloud-native, 5, 10, 16 computer, 10 Container, 30 containers, 16 DAG, 24 đám mây, 5, 10, 11, 12, 13, 16, 41 dashboard, 13, 35 data model, 12 database, 16 Database, 29 distributed tracing, 11 Filebeat, 20 Fluentd, 13, 20 gRPC, 16 HTTP, 16 JVM, 22, 29 local, 10 log, 5, 10, 11, 12, 13, 18, 19, 20, 21, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 38, 39, 40 log shipper, 20 logic, 5, 14, 18, 23, 24 Logstash, 20 metrics, 5, 10, 11, 12, 13, 18, 19, 22, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 37, 38, 40 microservices, 5, 10, 11, 13, 16, 17, 18, 19, 20, 24, 29, 30, 34, 35, 41 monitoring, monolithic, 5, 10, 14 monolithics, NTP, 20 obervability, 11 observability, 5, 6, 12, 18, 19, 25, 31, 35 OpenStack, 11, 13, 41 OpenTracing, 25, 26, 41 phân tán, 5, 10, 11, 12, 23 REST, 16, 17 service discovery, 35 service meshes, 16 Span, 30 Timestamp, 30, 32 trace, 5, 10, 11, 12, 13, 19, 21, 23, 25, 26, 28, 29, 30, 31, 32, 33, 34, 35, 37, 38, 40 Trace, 26, 30, 32 traces, 23, 25, 35 tracing, 18, 23, 24, 25, 26, 27, 41 Tracing, 13, 23, 24, 33, 41 web, 14, 15, 16 45 ... gồm điểm liệt kê • Nghiên cứu phương pháp truy vết luồng dịch vụ hệ thống phân tán • Nghiên cứu kết hợp với thành tựu đạt chủ đề truy? ??n thống sử dụng log (ghi nhật ký), metrics (giám sát số hệ thống)... người phát triển vận hành hệ thống ứng dụng tảng điện tốn đám mây • Ứng dụng data model nghiên cứu vào ứng dụng triển khai thực tế phục vụ hàng ngàn người sử dụng Viettel 5.1 Phương pháp nghiên cứu. .. số ứng dụng triển khai tracing Truy vết dịch vụ distributed tracing Truy vết dịch vụ môi trường phân tán bare metal Máy thật, server vật lý virtual machine Máy ảo container Giải pháp ảo hóa dựa