Ứng dụng RexUniNLU trong Vận hành Thông minh: Phát hiện Lỗi nhật ký
Vào lúc nửa đêm ba giờ, điện thoại đột ngôn vang lên với âm báo động chói tai. Kỹ sư vận hành anh Tảo từ trên giường bật dậy, mắt còn ngái ngủ nhìn vào màn hình - lại là một dịch vụ cốt lõi có lượng nhật ký tăng đột biến, hệ thống cảnh báo "bất thường", nhưng vấn đề cụ thể và nguyên nhân gốc rễ ở đâu thì hệ thống chỉ đưa ra một thông báo mơ hồ "lỗi không xác định". Anh Tảo phải tự đăng nhập vào máy chủ, lọc qua hàng chục GB tệp nhật ký như tìm kim đáy bể, dùng các lệnh grep, awk kết hợp liên tục, cho đến khi tìm thấy câu quan trọng "hết kết nối cơ sở dữ liệu" thì dịch vụ đã ngừng hoạt động trong mười lăm phút.
Tình huống như vậy không phải là hiếm gặp trong công việc vận hành truyền thống. Nhật ký, người ghi chép trung thành nhất của hệ thống khi vận hành, chứa đựng sự thật về sự cố, nhưng đặc tính khối lượng lớn và dạng văn bản phi cấu trúc của nó khiến việc định vị vấn đề trở nên vô cùng khó khăn. Phù hợp quy tắc thường có nhiều bỏ sót và báo sai, lọc từ khóa không đủ thông minh, trong khi phân tích thủ công lại kém hiệu quả.
Hôm nay, chúng ta sẽ cùng thảo luận về một hướng tiếp cận mới: làm thế nào để sử dụng công nghệ hiểu ngôn ngữ tự nhiên, cho phép máy móc "đọc hiểu" nhật ký giống như các chuyên gia vận hành giàu kinh nghiệm, thực hiện phát hiện bất thường và phân tích nguyên nhân gốc thông minh. Chúng ta sẽ tập trung vào một mô hình hiểu ngôn ngữ tự nhiên toàn tên là RexUniNLU, xem nó mang lại những thay đổi gì cho lĩnh vực vận hành thông minh.
1. Điểm nghẽn trong Vận hành Thông minh và giải pháp từ RexUniNLU
Trước khi đi vào chi tiết kỹ thuật, hãy xem xét việc phân tích nhật ký truyền thống đang gặp phải trở ngại ở đâu.
Thứ nhất, nhật ký là dữ liệu văn bản phi cấu trúc điển hình. Một dòng nhật ký có thể trông như thế này: 2024-01-15 03:14:07,123 ERROR [http-nio-8080-exec-5] com.example.service.OrderService - Không thể xử lý đơn hàng 12345: Hết thời gian chờ kết nối cơ sở dữ liệu sau 30000ms. Thử lại.... Dòng này chứa dấu thời gian, mức độ nhật ký, luồng, tên lớp, tên phương thức và thông tin lỗi định dạng tự do. Các công cụ giám sát truyền thống giỏi trong việc xử lý các chỉ số có cấu trúc (như sử dụng CPU, chiếm dụng bộ nhớ), nhưng khả năng hiểu thông tin ngữ nghĩa trong văn bản bán cấu trúc như "hết thời gian chờ", "thử lại" là hạn chế.
Thứ hai, nguyên nhân gốc rễ vấn đề thường ẩn chứa trong mối quan hệ thực thể. Một mục nhật ký bất thường đơn lẻ có thể chỉ là biểu hiện. Vấn đề thực sự cần liên kết nhiều dòng nhật ký, xác định các thực thể quan trọng (như ID đơn hàng: 12345, dịch vụ: OrderService, nguồn: kết nối cơ sở dữ liệu) và mối quan hệ giữa chúng (như xử lý đơn hàng thất bại gây ra hết thời gian chờ kết nối cơ sở dữ liệu). Điều này đòi hỏi mô hình có khả năng trích xuất thông tin mạnh mẽ.
Cuối cùng, kịch bản vận hành phức tạp và thay đổi liên tục. Dịch vụ mới được triển khai, loại lỗi mới xuất hiện, hệ thống phát hiện dựa trên quy tắc cố định cần liên tục bảo trì và cập nhật cơ sở quy tắc, tốn kém chi phí.
Đây chính là nơi RexUniNLU có thể thể hiện sức mạnh. Theo mô tả trong bài báo của nó, RexUniNLU là một giải pháp "hiểu ngôn ngữ tự nhiên toàn diện", với đổi mới cốt lõi là "hướng dẫn mẫu thức rõ ràng". Nói đơn giản, nó không giống như các mô hình tùy chỉnh truyền thống, nơi mỗi nhiệm vụ (như nhận thực thể có tên, trích xuất quan hệ) cần đào tạo một mô hình riêng. RexUniNLU thông qua một framework thống nhất, có thể hoàn thành các nhiệm vụ trích xuất thông tin và phân loại văn bản trong trường hợp không có mẫu hoặc có ít mẫu.
Đối với phân tích nhật ký vận hành, điều này có nghĩa là chúng ta có thể sử dụng một mô hình duy nhất, linh hoạt định nghĩa các nhiệm vụ phân tích khác nhau:
- Nhiệm vụ một (trích xuất thực thể): Tìm ra tất cả "loại lỗi", "tên dịch vụ", "IP máy chủ", "khoảng thời gian" từ nhật ký.
- Nhiệm vụ hai (trích xuất quan hệ): Xác định xem "dịch vụ A" và "lỗi B" có tồn tại mối quan hệ "gây ra" hay không.
- Nhiệm vụ ba (phân loại văn bản): Xác định dòng nhật ký này thuộc "vấn đề mạng", "vấn đề cơ sở dữ liệu", "lỗi mã ứng dụng" hay "cạn kiệt tài nguyên".
Và khi xuất hiện một mô tả lỗi hoàn toàn mới, chúng ta chỉ cần cập nhật "mô tả nhiệm vụ", không cần thu thập lại dữ liệu để đào tạo một mô hình mới, điều này nâng cao đáng kể khả năng thích ứng và tốc độ phản hồi của hệ thống vận hành.
2. Nguyên lý kỹ thuật RexUniNLU: Làm thế nào để máy móc hiểu nhật ký
Bạn có thể tò mò, RexUniNLU làm thế nào để đạt được sự linh hoạt và phổ quát như vậy? Chúng ta sẽ尽量避免 các công thức toán học phức tạp, lấy ví dụ bằng kịch bản nhật ký vận hành để giải thích.
Hãy tưởng tượng, bạn cần dạy một nhân viên vận hành mới cách phân tích nhật ký. Bạn sẽ không để anh ta học thuộc lòng hàng ngàn mẫu nhật ký, mà sẽ cho anh ta một bộ "phương pháp phân tích" và "danh sách kiểm tra".
1. Hướng dẫn mẫu thức rõ ràng: Cung cấp "danh sách kiểm tra" rõ ràng "Hướng dẫn mẫu thức rõ ràng" của RexUniNLU tương đương với danh sách kiểm tra này. Khi mô hình đối mặt với một dòng nhật ký, chúng ta sẽ nói rõ với nó: "Hãy chú ý đến các điểm sau: tìm 'mức độ lỗi', tìm 'thời gian xảy ra', tìm 'mô-đun dịch vụ bị ảnh hưởng', xác định 'thể loại nguyên nhân gốc rễ của lỗi'". Mô hình khi hiểu văn bản nhật ký, sẽ luôn lấy danh sách này như một ràng buộc, đảm bảo thông tin trích xuất là chính xác và phù hợp với kỳ vọng, tránh đầu ra không liên quan do "tự do phát triển".
Về mặt kỹ thuật, "mẫu thức" này sẽ được mã hóa thành một đoạn văn bản gợi ý đặc biệt, cùng với văn bản nhật ký gốc được nhập vào mô hình, dẫn dắt mô hình thực hiện hiểu định hướng và trích xuất thông tin.
2. Thiết kế truy vấn đệ quy: Như một thám tử đào sâu từng bước Một số vấn đề phức tạp không thể tìm thấy câu trả lời trong một bước. Ví dụ, một dòng nhật ký nói "gọi dịch vụ thất bại", nguyên nhân có thể là dịch vụ hạ cơ sở dữ liệu hết thời gian chờ, và cơ sở dữ liệu hết thời gian chờ lại có thể do mạng bị giật. Khả năng "truy vấn đệ quy" của RexUniNLU cho phép nó thực hiện lý luận đa bước.
Chúng ta có thể thiết kế truy vấn đầu tiên: "Trích xuất tất cả sự kiện 'gọi dịch vụ thất bại' từ nhật ký." Mô hình trích xuất sự kiện A. Tiếp theo, dựa trên kết quả của sự kiện A, khởi tạo truy vấn thứ hai: "Tìm các mục nhật ký mô tả 'hết thời gian chờ' hoặc 'từ chối' gần gũi về mặt thời gian với sự kiện A." Mô hình có thể tìm thấy sự kiện hết thời gian chờ cơ sở dữ liệu B. Sau đó, truy vấn thứ ba: "Tìm nhật ký trước và sau sự kiện B, có nhật ký về 'tỷ lệ mất gói mạng' hay 'băng thông' không?" Thông qua các truy vấn đệ quy, chuỗi như vậy, mô hình có thể mô phỏng logic khắc phục sự cố của chuyên gia vận hành, nối các điểm nhật ký rời rạc thành chuỗi sự cố.
3. Đại diện thông tin thống nhất: Đóng gói các kết quả phân tích khác nhau vào cùng một hộp Dù là trích xuất một thực thể (như "OrderService"), hay xác định một thể loại (như "vấn đề cơ sở dữ liệu"), hay thiết lập một mối quan hệ (như "gây ra"), RexUniNLU đều sử dụng một phương thức biểu thức thống nhất để xử lý bên trong. Điều này giống như đội ngũ vận hành sử dụng mẫu báo cáo sự cố thống nhất, dù là phát hiện từ nhóm mạng, nhóm cơ sở dữ liệu hay nhóm ứng dụng, tất cả đều có thể được tổng hợp ở định dạng nhất quán, thuận tiện cho phân tích liên quan và tạo báo cáo sau này.
Cơ chế này cho phép RexUniNLU sử dụng một kiến trúc mô hình để xử lý nhiều nhu cầu phân tích đa dạng trong vận hành, thay vì triển khai một mô hình độc lập cho từng nhiệm vụ nhỏ, đơn giản hóa kiến trúc hệ thống và nâng cao hiệu suất xử lý.
3. Thực chiến: Xây dựng mẫu phát hiện lỗi nhật ký và phân tích nguyên nhân gốc
Lý thuyết nói nhiều, không bằng tự xem xét thực tế. Chúng ta sẽ thiết kế một kịch bản đơn giản, minh họa cách sử dụng RexUniNLU để xây dựng một mô-đun phân tích nhật ký thông minh. Giả sử chúng ta có một ứng dụng vi dịch vụ, thường xuyên có cảnh báo "xử lý đơn hàng chậm".
Bước đầu: Chuẩn bị môi trường và gọi mô hình Chúng ta có thể sử dụng mô hình được đào tạo sẵn damo/nlp_deberta_rex-uninlu_chinese-base từ nền tảng ModelScope. Dưới đây là ví dụ gọi Python cơ bản:
from modelscope.pipelines import pipeline
from modelscope.preprocessors import NLPTokenizer
# Tạo đường ống trích xuất ngữ nghĩa
analyzer_pipeline = pipeline('rex-uninlu',
model='damo/nlp_deberta_rex-uninlu_chinese-base',
model_revision='v1.2.1')
# Xác định cấu trúc phân tích chúng ta quan tâm (Mẫu thức)
# Mẫu thức này nói cho mô hình: Hãy trích xuất "thực thể sự cố" và "nguyên nhân có thể" từ văn bản, và thiết lập "quan hệ" giữa chúng.
analysis_schema = {
"phân tích_sự_cố": {
"thực_thể_sự_cố": ["dịch_vụ", "giao_diện", "nguồn_lực"],
"nguyên_nhân_có_thể": ["dịch_vụ_hạ", "trung_gian", "cơ_sở_hạ_tầng", "lỗi_mã"],
"quan_hệ": ["gây_ra", "liên_quan"]
}
}
# Mô phỏng một dòng nhật ký
log_entry = "Cảnh báo thời gian phản hồi(P99) của giao diện truy vấn đơn hàng /api/order/query liên tục vượt quá 2000ms, nghi ngờ do thời gian gọi dịch vụ getUserInfo của người dùng quá cao, và tỷ lệ hit cache Redis giảm xuống còn 70%."
# Thực hiện phân tích
result = analyzer_pipeline(input=log_entry, schema=analysis_schema)
print(result)
Bước hai: Phân tích kết quả và rút ra thông tin Sau khi chạy đoạn mã trên, mô hình sẽ trả về kết cấu cấu trúc. Chúng ta có thể nhận được kết quả tương tự như sau (đã đơn giản hóa để rõ ràng):
{
"phân tích_sự_cố": {
"thực_thể_sự_cố": [
{"text": "giao diện truy vấn đơn hàng /api/order/query", "type": "giao_diện", "span": [0, 15]},
{"text": "thời gian phản hồi(P99)", "type": "nguồn_lực", "span": [16, 25]}
],
"nguyên_nhân_có_thể": [
{"text": "dịch vụ getUserInfo của người dùng", "type": "dịch_vụ_hạ", "span": [35, 45]},
{"text": "Redis cache", "type": "trung_gian", "span": [55, 60]}
],
"quan_hệ": [
{"head": "dịch vụ getUserInfo của người dùng", "relation": "gây_ra", "tail": "thời gian phản hồi(P99) quá cao"},
{"head": "tỷ lệ hit cache Redis giảm", "relation": "liên_quan", "tail": "trì hoãn phản hồi giao diện"}
]
}
}
Như bạn thấy, mô hình tự động từ một đoạn văn, nhận ra các giao diện và nguồn lực gặp vấn đề, tìm thấy hai nguyên nhân có thể (dịch vụ hạ và cache trung gian), và còn suy luận ra mối quan hệ ảnh hưởng giữa chúng. Điều này phong phú và chính xác hơn nhiều so với việc chỉ khớp từ khóa "tốn thời gian", "cảnh báo".
Bước ba: Mở rộng ra phân tích luồng nhật ký hàng loạt Phân tích một dòng nhật ký chỉ là khởi đầu. Trong hệ thống thực tế, chúng ta cần xử lý luồng nhật ký thời gian thực. Cách tiếp cận là:
- Phân cụm nhật ký: Đầu tiên, dùng quy tắc đơn giản hoặc thuật toán phân cụm, nhóm các lỗi tương tự trong thời gian ngắn thành một "sự cố bất thường".
- Trích xuất ngữ cảnh quan trọng: Từ loại nhật ký này, chọn ra vài dòng văn bản gốc đại diện nhất.
- Gọi RexUniNLU để phân tích sâu: Như ví dụ trên, nhập các câu đại diện và cấu trúc phân tích vận hành đã định nghĩa.
- Tạo báo cáo phân tích: Tự động điền các thực thể, nguyên nhân, quan hệ mô hình trích xuất vào mẫu báo cáo, nhanh chóng tạo báo cáo sơ bộ chứa "nguyên nhân nghi ngờ", "phạm vi ảnh hưởng", "thành phần liên quan", gửi đến nhân viên vận hành.
4. Hiệu quả và Giá trị: Không chỉ là độ chính xác
Vậy, trong ứng dụng thực tế, phương pháp này mang lại những lợi ích cụ thể gì?
Thứ nhất, là cải thiện độ chính xác và độ bao phủ của phát hiện. Hệ thống dựa trên quy tắc, đối với lỗi đã thấy trong tập huấn luyện, phù hợp biểu thức chính quy, có thể đạt độ chính xác cao. Nhưng đối với các lỗi mới, diễn đạt phức tạp (ví dụ, "trong quá trình cập nhật cuộn, do sự khác biệt cấu hình giữa phiên bản cũ và mới dẫn đến lỗi tuần tự hóa một phần yêu cầu"), quy tắc thường không làm được. Các mô hình hiểu như RexUniNLU, thông qua hiểu ngữ nghĩa, có thể khái quát tốt hơn với các mô tả lỗi chưa từng thấy, giảm bỏ sót. Theo đánh giá trên các nhiệm vụ trích xuất thông tin và phân loại văn bản phổ quát, trong điều kiện không có mẫu hoặc có ít mẫu, giá trị F1 của nó có lợi thế đáng kể so với phương pháp truyền thống, điều này có nghĩa là trong lĩnh vực vận hành, nó có khả năng nhận ra các mẫu bất thường đa dạng và ẩn giấu hơn.
Thứ hai, là rút ngắn thời gian khắc phục sự cố trung bình. Đây là chỉ số cốt lõi nhất trong vận hành. Quy trình truyền thống là: cảnh báo → nhân viên vận hành đăng nhập máy chủ → xem nhật ký → tìm từ khóa → đoán dựa trên kinh nghiệm → kiểm tra đoán. Khi đưa vào phân tích thông minh, quy trình trở thành: cảnh báo → hệ thống tự động phân tích nhật ký liên quan → tạo báo cáo chứa "định vị nguyên nhân gốc: thời gian gọi dịch vụ người dùng tăng đột biến" và "bằng chứng liên quan: tỷ lệ hit cache Redis giảm đồng thời" → nhân viên vận hành trực tiếp khắc phục nguyên nhân gốc. Điều này có thể rút ngắn MTTR từ cấp giờ hoặc thậm chí cấp ngày xuống cấp phút.
Cuối cùng, là giải phóng đội ngũ vận hành. Giải phóng kỹ sư khỏi công việc "khảo cổ nhật ký" phức tạp và kém hiệu quả, để họ có thể tập trung vào công việc có giá trị cao hơn như tối ưu hóa kiến trúc, quy hoạch dung lượng và thiết kế kế hoạch ứng phó sự cố. Nhân viên mới cũng có thể sử dụng "trợ lý AI" này để nhanh chóng hiểu các mẫu sự cố hệ thống, thúc đẩy quá trình phát triển.
5. Triển vọng và Đề xuất
Việc áp dụng các mô hình NLU như RexUniNLU vào vận hành thông minh hiện vẫn là một hướng đi đầy tiềm năng cần khám phá. Khi triển khai thực tế, tôi có vài gợi ý chưa chín muồi:
Bắt đầu từ kịch bản nhỏ, xác nhận giá trị. Đừng cố gắng dùng AI để phân tích nhật ký của tất cả hệ thống công ty ngay từ đầu. Có thể bắt đầu với một dịch vụ hoặc loại sự cố cụ thể có điểm đau rõ ràng và chất lượng nhật ký tương đối cao (ví dụ: "sự cố liên quan đến kết nối cơ sở dữ liệu") làm thử nghiệm. Xác định rõ các chỉ số đánh giá (ví dụ: so sánh sự nhất quán giữa báo cáo phân tích AI và kết quả phân tích của chuyên gia giàu kinh nghiệm), nhanh chóng xác minh tính khả thi của hướng đi kỹ thuật.
Chú trọng chuẩn hóa nhật ký. Mô hình thông minh nhất cũng sợ "dữ liệu bẩn". Thúc đẩy việc thực hiện quy chuẩn nhật ký ở tầng ứng dụng, khuyến khích nhà phát triển đầu ra nhật ký có cấu trúc rõ ràng và thông tin phong phú hơn (ví dụ, thống nhất chứa request_id để nối nhật ký上下游), sẽ tạo nền tảng vững chắc cho phân tích thông minh sau này. Điều này quan trọng hơn bất kỳ mô hình phức tạp nào.
Hiểu được giới hạn của mô hình. RexUniNLU mạnh trong hiểu ngữ nghĩa và khái quát không có mẫu, nhưng nó không phải là "chìa khóa vạn năng". Đối với các phân tích nguyên nhân gốc sâu cần tính toán chính xác giá trị số, lý luận đồ thị phức tạp hoặc phụ thuộc vào kiến thức lĩnh vực nghiêm ngặt, có thể cần kết hợp các công nghệ khác như đồ thức tri thức, phát hiện bất thường chuỗi thời gian, để xây dựng giải pháp tổng hợp.
Chú trọng chi phí và hiệu suất. Chi phí tính toán của mô hình sâu cao hơn so với khớp quy tắc. Cần xem xét phân tích được thực hiện thời gian thực hay gần thời gian thực/hệ thống. Đối với lượng nhật ký khổng lồ, có thể先用 quy tắc nhẹ hoặc mô hình đơn giản để lọc, chỉ gọi mô hình lớn để phân tích sâu các đoạn nhật ký đáng ngờ, đạt được sự cân bằng giữa độ chính xác và hiệu suất.
Tìm hiểu thêm về AI镜像
Muốn khám phá thêm các AI镜像 và kịch bản ứng dụng? Truy cập CSDN星图镜像广场, cung cấp các镜像 được định sẵn phong phú, bao gồm suy luận mô hình lớn, tạo hình ảnh, tạo video, điều chỉnh mô hình và nhiều lĩnh vực khác, hỗ trợ triển khai một cú nhấp chuột.