Truy tìm phân tán là một chủ đề gây chia rẽ. Từng là , công nghệ này được kỳ vọng sẽ cách mạng hóa khả năng quan sát. thành công của mọi KubeCon Tua nhanh 5 năm, sự cường điệu đã phần nào lắng xuống, có và việc áp dụng ở mức vừa phải. Trong khi đó, tiếp tục có hoạt động ổn định xung quanh việc mở rộng và tiêu chuẩn hóa công nghệ - Open Telemetry (dựa trên OpenTracing) là sau Kubernetes. Vì vậy, thỏa thuận với Truy tìm phân tán là gì? Có nên triển khai ngay hay chờ xem? nhiều lời bàn tán hơn về nỗi đau dự án CNCF lớn thứ 2 Trong bài viết này, hãy cùng tìm hiểu sâu về Truy tìm phân tán Điều gì đặc biệt về Truy tìm phân tán và tại sao chúng ta cần nó? Các vấn đề với theo dõi phân tán ngày nay là gì? Những phát triển sắp tới là gì và làm thế nào để họ giải quyết những thách thức hiện tại? Giới thiệu - Cách hoạt động của Truy vết phân tán Đối với những người không quen biết, Truy tìm phân tán là một công nghệ cho phép chúng tôi theo dõi một yêu cầu duy nhất khi nó đi qua một số thành phần/vi dịch vụ khác nhau của môi trường phân tán. Mỗi cuộc gọi mạng được thực hiện trong đường dẫn của yêu cầu được ghi lại và biểu thị dưới dạng một khoảng. Để kích hoạt tính năng này, các công cụ theo dõi được phân phối sẽ chèn ngữ cảnh theo dõi duy nhất (ID theo dõi) vào từng tiêu đề của yêu cầu và triển khai các cơ chế để đảm bảo rằng bối cảnh theo dõi được lan truyền trong toàn bộ đường dẫn yêu cầu. Cách theo dõi phân tán biểu thị đường dẫn yêu cầu Tại sao chúng ta cần Truy tìm phân tán ngay từ đầu Theo dõi phân tán là duy nhất bởi vì nó tập trung vào một làm đơn vị cho khả năng quan sát. Trong nền tảng giám sát/số liệu, một (ví dụ: dịch vụ, máy chủ) là đơn vị cơ bản đang được quan sát. Người ta có thể đặt câu hỏi cho các nền tảng này về toàn bộ hành vi của đơn vị này theo thời gian. Ví dụ: tình trạng/thông lượng/tỷ lệ lỗi của dịch vụ này trong một khung thời gian cụ thể là bao nhiêu? yêu cầu thành phần Với nhật ký, đơn vị cơ bản được quan sát là một - ví dụ: bất cứ khi nào một sự kiện xảy ra trong quá trình thực thi mã, hãy in một số thông tin. Những "sự kiện" này được các nhà phát triển xác định một cách chủ quan trong khi viết mã. Thách thức đối với nhật ký là tất cả chúng đều rời rạc, với mỗi thành phần in dạng thông điệp tường trình riêng biệt, không có cách nào dễ dàng để kết nối chúng lại với nhau sao cho hợp lý. sự kiện Ngược lại, với theo dõi phân tán, những gì đang được quan sát là một yêu cầu duy nhất khi nó đi qua một số thành phần. Điều này cho phép chúng tôi đặt câu hỏi về toàn bộ hệ thống phân tán và hiểu điều gì đã xảy ra ở đâu trong một hệ thống phức tạp, được kết nối với nhau. Trường hợp cơ bản cho theo dõi phân tán nằm ở lập luận rằng định hướng xung quanh các yêu cầu này là . Và kết quả là, đây cũng là cách trực quan nhất để chúng tôi kiểm tra và khắc phục sự cố các kiến trúc phân tán. gần nhất với cuối trải nghiệm của người dùng Sự phát triển của Truy tìm phân tán Truy tìm phân tán đã tăng tầm quan trọng do việc áp dụng rộng rãi các kiến trúc phần mềm phân tán trong thập kỷ qua. Kiến trúc dựa trên vi dịch vụ hiện đại là sự phát triển từ câu chuyện phát triển internet vào cuối những năm 90, khi việc sử dụng các hệ thống trở nên phổ biến. phản hồi yêu cầu "Vào cuối những năm 90 và sự phát triển bùng nổ của internet, đã dẫn đến sự phát triển mạnh mẽ của , chẳng hạn như trang web hai tầng, với giao diện máy chủ web và phần phụ trợ cơ sở dữ liệu... Yêu cầu là một khía cạnh mới để suy luận về hệ thống , trực giao với bất kỳ một máy hoặc quy trình tổng hợp nào." các hệ thống phản hồi yêu cầu - Theo dõi phân tán trong thực tế, O'Reilly Media Trong các kiến trúc vi dịch vụ này, mỗi yêu cầu đơn lẻ kết thúc với nhiều (10 hoặc thậm chí 100 vi dịch vụ), thực hiện một số cuộc gọi mạng ở giữa. Tham khảo bên dưới để biết kiến trúc vi dịch vụ của Uber, có hơn 3000 dịch vụ. Kiến trúc vi dịch vụ của Uber từ năm 2018. Nguồn: https://www.uber.com/en-IN/blog/microservice-architecture/ Trong các hệ thống phức tạp như vậy, theo dõi phân tán trở nên quan trọng đối với bất kỳ hình thức khắc phục sự cố nào. Do đó, Truy tìm phân tán đã được tiên phong bởi các công ty lớn, những người sớm chấp nhận sử dụng các môi trường phân tán, phức tạp, rộng lớn. Bài báo Dapper của Google phát hành năm 2010 là bước khởi đầu của theo dõi phân tán Trong vài năm tới, hai công ty nữa đã mở mã nguồn hệ thống theo dõi phân tán của riêng họ (Zipkin mã nguồn mở Twitter năm 2012 và Jaeger mã nguồn mở Uber năm 2017). Zipkin và Jaeger tiếp tục là một trong những công cụ theo dõi phân tán phổ biến nhất cho đến tận ngày nay Kể từ năm 2016, đã có một nỗ lực đáng kể để chuẩn hóa theo dõi phân tán giữa các thành phần thông qua dự án OpenTracing. OpenTracing cuối cùng đã trở thành vào năm 2019. OpenTelemetry phổ biến rộng rãi và có hàng nghìn người đóng góp trên toàn cầu OpenTelemetry Giờ đây, Truy tìm phân tán được nhiều người coi là "trụ cột" thứ ba của khả năng quan sát bên cạnh số liệu và nhật ký. Hầu hết những người chơi theo dõi và quan sát chính đều cung cấp các công cụ theo dõi phân tán như một phần sản phẩm của họ. Trạng thái truy tìm phân tán: Lý thuyết so với thực tế Tuy nhiên, bất chấp lời hứa, sự phấn khích và nỗ lực của cộng đồng, việc áp dụng theo dõi phân tán ngày nay là khoảng ~25%. Không có gì lạ khi tìm thấy các công ty sử dụng kiến trúc vi dịch vụ đang làm việc với nhật ký và số liệu, mặc dù rõ ràng họ cần theo dõi phân tán. Đồng thời, các lỗi sản xuất có thời gian trung bình để giải quyết đang gia tăng trên thế giới ngày nay. để giải quyết các vấn đề sản xuất ngày hôm nay. 73% công ty báo cáo rằng phải mất hơn một giờ Hãy hỏi bất kỳ nhà phát triển nào về những khoảnh khắc đau đớn nhất trong cuộc đời họ và họ sẽ nói về thời gian dành cho việc sửa lỗi Sev-1 trong quá trình sản xuất với cảm giác giống như vài trăm người đang thở dốc. Sau đó, có vẻ như bất kỳ công ty nào quan tâm đến MTTR của mình (gần như mọi công ty) nên sử dụng theo dõi phân tán và việc áp dụng lẽ ra đã tăng vọt trong môi trường này. Nhưng những con số thực tế không hỗ trợ điều đó - vậy thì sao? Những thách thức với Truy tìm phân tán ngày nay Ngày nay, có một số vấn đề với việc theo dõi phân tán mà các công ty phải vượt qua để đạt được giá trị - tất cả những vấn đề này không được thảo luận rộng rãi trong các câu chuyện chính thống. 1. Thực hiện khó! Để triển khai theo dõi phân tán trong một dịch vụ ngày hôm nay, chúng tôi cần thực hiện thay đổi mã và phát hành. Mặc dù thực hiện thay đổi mã là một yêu cầu đủ phổ biến để có thể quan sát được, nhưng thách thức cụ thể với theo dõi phân tán là điều này - cần được cung cấp công cụ để có được dấu vết phân tán hoặc phá vỡ dấu vết. chính dịch vụ hoặc thành phần Người ta không thể chỉ bắt đầu với một dịch vụ duy nhất - như người ta có thể làm với việc giám sát hoặc ghi nhật ký - và nhận ra giá trị. Theo dõi phân tán yêu cầu thiết bị trên một để tạo ra các dấu vết có thể sử dụng được. tập hợp các dịch vụ Điều này yêu cầu sự phối hợp giữa một số nhóm và chủ sở hữu dịch vụ để thực hiện các thay đổi trong dịch vụ của họ. Vì vậy, nó trở thành một vấn đề của tổ chức - hãy tưởng tượng có 100 nhóm sử dụng dịch vụ của họ trong vài tháng trước khi bạn có thể nhận ra giá trị. Đây là thách thức lớn nhất với theo dõi phân tán ngày nay. 2. Cần các quyết định lấy mẫu phức tạp Tiếp theo, khối lượng dữ liệu theo dõi do Truy tìm phân tán tạo ra có thể quá tải. Hãy tưởng tượng hàng trăm dịch vụ, mỗi dịch vụ phát ra một lượng nhỏ dữ liệu theo dõi cho . Đây sẽ là hàng triệu yêu cầu mỗi giây và làm cho việc theo dõi phân tán trở nên đắt đỏ cả về dung lượng lưu trữ và băng thông mạng. mỗi yêu cầu Mặc dù việc ghi nhật ký cũng thực hiện điều tương tự (và tạo ra cho mỗi yêu cầu, sau đó được quản lý bởi các công cụ tổng hợp nhật ký lớn), điểm khác biệt là hầu hết các công ty ngày nay tính năng ghi nhật ký. Giới thiệu thêm một loại dữ liệu sẽ lớn gần bằng việc ghi nhật ký là một nhiệm vụ khó khăn và có khả năng sẽ tăng gấp đôi chi tiêu. nhiều dữ liệu hơn đều đã có Để xử lý vấn đề về chi phí này, tất cả các hệ thống theo dõi phân tán ngày nay đều sử dụng và chỉ ghi lại một tập hợp con các dấu vết. Tỷ lệ lấy mẫu phổ biến trong thực tế hiện nay là từ 0,1% đến 2%. Cơ sở lý luận là thậm chí 1% mẫu cũng đủ để đưa ra một bức tranh tổng hợp hợp lý về vị trí tắc nghẽn hiệu suất. phương pháp lấy mẫu Hầu hết các nền tảng ngày nay đều cho phép khách hàng chọn chiến lược lấy mẫu và tự đánh đổi chi phí theo khả năng hiển thị. Tuy nhiên, quy trình quyết định này làm tăng thêm chi phí hoạt động vốn đã phức tạp của thiết bị và quản lý hệ thống theo dõi phân tán. 3. Nhưng lấy mẫu làm giảm giá trị một cách có ý nghĩa Giả sử một công ty nỗ lực thiết lập mọi dịch vụ/thành phần và sau đó quyết định chiến lược lấy mẫu để đảm bảo họ không phá vỡ ngân hàng. Bây giờ thì sao - chúng ta có nên mong đợi MTTR giảm đáng kể không? Không, bởi vì các nhà phát triển không thể sử dụng theo dõi phân tán để thực sự khắc phục sự cố do lấy mẫu. Hãy tưởng tượng trải nghiệm của nhà phát triển - "Tôi không thể tìm thấy sự cố là có. Tôi đã tạo ra lỗi nhưng tôi không thể tìm thấy dấu vết tương ứng". mà tôi biết Vì vậy, những gì xảy ra? Các nhà phát triển ngừng tin tưởng vào chất lượng của dữ liệu theo dõi được phân phối và hoàn nguyên về các phương pháp gỡ lỗi/xử lý sự cố thông thường của họ (nghĩa là sử dụng nhật ký) 4. Việc sử dụng của nhà phát triển có tần suất thấp Với những ràng buộc này, ngày nay, Truy tìm Phân tán chủ yếu được bán như một cách để khắc phục . sự cố hiệu suất Hãy nhớ rằng một dấu vết phân tán cơ bản thực sự chỉ cho chúng ta biết ai đã gọi ai và mỗi khoảng thời gian kéo dài bao lâu. Dấu vết phân tán không cho chúng tôi biết gây ra lỗi/độ trễ cao. Để làm được điều đó, các nhà phát triển vẫn phải xem thông báo tường trình và/hoặc tạo lại vấn đề cục bộ để gỡ lỗi. điều gì đã xảy ra trong dịch vụ Trong một công ty điển hình, các vấn đề về hiệu suất có thể xảy ra <10% trên tổng số. Vì vậy, trên thực tế, theo dõi phân tán chỉ hữu ích cho phần vấn đề nhỏ này. Nhà phát triển trung bình vận chuyển và sở hữu dịch vụ đang sử dụng công cụ theo dõi phân tán có thể 2-3 lần một năm. Tác động của tất cả những thách thức này Tóm tắt: Truy tìm phân tán khó thực hiện Truy tìm phân tán cần lấy mẫu rộng rãi để kiểm soát chi phí Nhưng lấy mẫu làm giảm giá trị đáng kể Do đó, các nhà phát triển chỉ sử dụng theo dõi cho trường hợp sử dụng hiệu suất một lần lẻ Tất cả điều này làm cho trường hợp RoI đối với truy vết phân tán trở nên khá mờ nhạt. Trong một chu kỳ cường điệu điển hình, những gì chúng ta có thể nói là chúng ta hiện đã qua giai đoạn thổi phồng kỳ vọng và sự vỡ mộng bắt đầu hình thành. Tuy nhiên, nếu chúng ta nghĩ về trạng thái cuối, nếu tương lai của các hệ thống máy tính được phân phối, thì theo dõi phân tán đương nhiên là vectơ cơ bản nhất cho khả năng quan sát. Trong thế giới đó, bất kỳ công ty nào có kiến trúc phân tán đều sử dụng theo dõi làm cơ chế chính để khắc phục sự cố bất kỳ điều gì xảy ra trong quá trình sản xuất - "khả năng quan sát" thực sự - so với việc giám sát thụ động các hệ thống mà chúng ta có ngày nay. Tuy nhiên, trước khi chúng tôi có thể đạt đến trạng thái cuối cùng đó, chúng tôi sẽ cần một số cải tiến so với hiện trạng. Tin tốt là phần lớn điều này đã được tiến hành. Hãy xem xét từng người trong số họ. Vì vậy, những gì chúng ta có thể mong đợi để xem trong tương lai? Tương lai của theo dõi phân tán Thiết bị ngay lập tức không có thay đổi mã Hãy tưởng tượng đến một đại lý và có thể bao quát toàn bộ hệ thống phân tán (tất cả các dịch vụ, thành phần) trong một lần mà không cần thay đổi mã. Điều này có vẻ thực tế có thể xảy ra trong 2-3 năm tới. của OpenTelemetry đã kích hoạt tính năng này cho một số ngôn ngữ lập trình (tuy nhiên lại thiếu các ngôn ngữ được biên dịch như Go). Đồng thời, đang phát triển để . Giữa hai điều này, chúng ta có thể mong đợi một cách an toàn rằng vấn đề thiết bị sẽ được giải quyết trong một vài năm. Các thư viện công cụ tự động các công nghệ như eBPF kích hoạt thiết bị trên toàn hệ thống mà không cần thay đổi mã Lấy mẫu nhường chỗ cho lựa chọn yêu cầu quan tâm dựa trên AI Trong thế giới LLM, việc lấy mẫu ngẫu nhiên bắt đầu giống như một di tích từ thời kỳ đen tối. Lý tưởng nhất là chúng ta có thể xem xét 100% dấu vết, xác định bất kỳ thứ gì có vẻ bất thường và lưu trữ để kiểm tra trong tương lai. Không lấy mẫu ngẫu nhiên nữa. Nếu chúng tôi nghĩ về nó, chúng tôi không thực sự quan tâm đến ~ 95% "yêu cầu hài lòng". Chúng tôi chỉ quan tâm đến ~5% dấu vết bất thường - lỗi, ngoại lệ, độ trễ cao hoặc một số dạng lỗi mềm. Vì vậy, chúng tôi chỉ cần một cách để xem xét 100% và chọn ra 5% thú vị. Ngày nay, có những cơ chế như nhằm mục đích thực hiện điều này. Trong lấy mẫu dựa trên đuôi, hệ thống đợi cho đến khi tất cả các khoảng trong yêu cầu được hoàn thành, sau đó dựa trên dấu vết đầy đủ, quyết định xem có phải giữ lại yêu cầu đó hay không. lấy mẫu dựa trên đuôi Thách thức chính với việc lấy mẫu dựa trên đuôi là bạn phải lưu trữ tất cả các khoảng của một dấu vết cho đến khi hoàn thành toàn bộ yêu cầu và sau đó quyết định có nên giữ/loại bỏ dấu vết hay không. Điều này có nghĩa là chúng tôi lưu trữ mọi yêu cầu đơn lẻ, với tất cả các khoảng thời gian, trong một khoảng thời gian nhất định (cho đến khi yêu cầu hoàn tất) - điều này yêu cầu một kiến trúc dữ liệu riêng biệt với các thành phần để cân bằng tải, lưu trữ và xử lý rất phức tạp và tốn kém. OpenTelemetry có , tuy nhiên, nó vẫn chưa hoàn thiện và có một số (do sự cố được đề cập ở trên). Trong khi đó, một số công ty bao gồm đang nghiên cứu sử dụng AI để phát hiện sự bất thường hiệu quả và có thể mở rộng. bộ sưu tập lấy mẫu dựa trên đuôi thách thức về khả năng mở rộng ZeroK.ai Với tốc độ phát triển nhanh chóng trong không gian này, chúng ta có thể kỳ vọng một cách hợp lý rằng vấn đề này cũng sẽ được giải quyết trong 3-5 năm tới. Sự xuất hiện của các dấu vết phân tán "phong phú" cho phép gỡ lỗi tất cả Một bước nhảy vọt thực sự trong thế hệ theo dõi tiếp theo sẽ là khi việc theo dõi phát triển từ lĩnh vực "chỉ các vấn đề về hiệu suất" thành "tất cả các vấn đề". Đó là khi sức mạnh thực sự của theo dõi phân tán được giải phóng. Để có thể thực hiện được điều này, mỗi dấu vết cần phải có ngữ cảnh phong phú. Hãy tưởng tượng một kịch bản trong đó mỗi nhịp trong mỗi dấu vết có: Tải trọng yêu cầu và phản hồi (với mặt nạ PII) Dấu vết ngăn xếp cho mọi trường hợp ngoại lệ Nhật ký Sự kiện Kubernetes Trạng thái nhóm Và bất cứ điều gì khác đã xảy ra dọc theo khoảng thời gian đó Tất cả trong một dòng chảy tích hợp, liền mạch. Và hãy tưởng tượng nếu dấu vết mà một người đang tìm kiếm cực kỳ dễ tìm - không có lỗ hổng dữ liệu liên quan đến lấy mẫu, các vấn đề được loại trừ & nhóm lại và có thể được lọc qua nhiều thứ nguyên. Sau đó, đây là tất cả những gì nhà phát triển cần để gỡ lỗi bất kỳ sự cố phần mềm nào. Và có khả năng, tất cả một mô hình AI cần chẩn đoán và chỉ cho nhà phát triển biết điều gì đang xảy ra. Trong thế giới này, dấu vết trở thành trục chính cho khả năng quan sát, . Đó là trạng thái cuối cùng của theo dõi phân tán có thể trông như thế nào - mặc dù nó chưa có ở đây, nhưng nó có thể nhìn thấy từ vị trí của chúng ta ngày nay. thay thế việc ghi nhật ký Rào cản chính để thực hiện điều này là sự bùng nổ về khối lượng dữ liệu mà việc lưu trữ tất cả dữ liệu ngữ cảnh này sẽ gây ra. Chúng tôi sẽ yêu cầu sự đổi mới sâu sắc trong kiến trúc lưu trữ và xử lý dữ liệu để có thể thực hiện được điều này. Vẫn còn sớm và chúng ta phải chờ xem điều gì sẽ xảy ra ở đây. Bản tóm tắt Tóm lại, Truy tìm phân tán là một chế độ xem cần thiết và trực quan cần có để có thể quan sát kiến trúc ứng dụng phân tán trong sản xuất. Thế hệ truy tìm phân tán đầu tiên, mặc dù đầy hứa hẹn, nhưng đã gặp phải một số thách thức khiến các công ty khó thu được giá trị từ việc truy vết, điều này đã phần nào cản trở việc áp dụng. Tuy nhiên, một số phát triển thú vị đang diễn ra trong không gian được kỳ vọng sẽ giúp việc theo dõi dễ dàng hơn, đơn giản hơn và mạnh mẽ hơn những gì chúng ta có ngày nay, giúp khả năng quan sát trở nên liền mạch hơn trong tương lai.
