Tạo mã có thể tìm thấy bằng cách sử dụng ID tin nhắn duy nhất trên toàn cầu

Một mô hình phổ biến để định vị một lỗi theo kịch bản này:

1. Quan sát sự kỳ lạ, ví dụ, không có đầu ra hoặc chương trình treo.
2. Xác định vị trí thông báo có liên quan trong nhật ký hoặc đầu ra chương trình, ví dụ: "Không thể tìm thấy Foo". (Điều sau đây chỉ có liên quan nếu đây là đường dẫn được thực hiện để xác định lỗi. Nếu theo dõi ngăn xếp hoặc thông tin gỡ lỗi khác có sẵn thì đó là một câu chuyện khác.)
3. Xác định vị trí mã nơi tin nhắn được in.
4. Gỡ lỗi mã giữa nơi đầu tiên Foo nhập (hoặc nên nhập) hình ảnh và nơi thông báo được in.

Bước thứ ba đó là nơi quá trình gỡ lỗi thường bị đình trệ vì có nhiều vị trí trong mã nơi "Không thể tìm thấy Foo" (hoặc một chuỗi templated Could not find {name}) được in. Trên thực tế, nhiều lần một lỗi chính tả đã giúp tôi tìm vị trí thực tế nhanh hơn nhiều so với cách khác - nó làm cho thông điệp trở nên độc nhất trên toàn hệ thống và thường trên toàn thế giới, dẫn đến một công cụ tìm kiếm có liên quan ngay lập tức.

Kết luận rõ ràng từ điều này là chúng ta nên sử dụng ID tin nhắn duy nhất trên toàn cầu trong mã, mã hóa cứng như một phần của chuỗi tin nhắn và có thể xác minh rằng chỉ có một lần xuất hiện của mỗi ID trong cơ sở mã. Về khả năng bảo trì, cộng đồng này nghĩ gì là ưu và nhược điểm quan trọng nhất của phương pháp này và bạn sẽ thực hiện điều này như thế nào hoặc đảm bảo rằng việc thực hiện nó không bao giờ trở nên cần thiết (giả sử rằng phần mềm sẽ luôn có lỗi)?

Nhìn chung đây là một chiến lược hợp lệ và có giá trị. Dưới đây là một số suy nghĩ.

Chiến lược này còn được gọi là "đo từ xa" theo nghĩa là khi tất cả các thông tin đó được kết hợp, chúng sẽ giúp "tam giác hóa" dấu vết thực thi và cho phép người khắc phục sự cố hiểu được những gì người dùng / ứng dụng đang cố gắng thực hiện và những gì thực sự đã xảy ra .

Một số phần dữ liệu thiết yếu phải được thu thập (mà tất cả chúng ta đều biết) là:

• Vị trí của mã, tức là ngăn xếp cuộc gọi và dòng mã gần đúng
  • "Dòng mã gần đúng" là không cần thiết nếu các chức năng được phân tách hợp lý thành các đơn vị nhỏ phù hợp.
• Bất kỳ mẩu dữ liệu nào phù hợp với sự thành công / thất bại của chức năng
• Một "lệnh" cấp cao có thể hiểu được những gì người dùng / tác nhân bên ngoài / người dùng API đang cố gắng thực hiện.
  • Ý tưởng là một phần mềm sẽ chấp nhận và xử lý các lệnh đến từ đâu đó.
  • Trong quá trình này, hàng chục đến hàng trăm đến hàng ngàn cuộc gọi chức năng có thể đã diễn ra.
  • Chúng tôi muốn bất kỳ từ xa nào được tạo ra trong suốt quá trình này để có thể truy nguyên trở lại lệnh cấp cao nhất kích hoạt quy trình này.
  • Đối với các hệ thống dựa trên web, yêu cầu HTTP gốc và dữ liệu của nó sẽ là một ví dụ về "thông tin yêu cầu cấp cao" như vậy
  • Đối với các hệ thống GUI, người dùng nhấp vào một cái gì đó sẽ phù hợp với mô tả này.

Thông thường, các cách tiếp cận ghi nhật ký truyền thống bị thiếu, do không theo dõi được thông điệp nhật ký cấp thấp trở lại lệnh cấp cao nhất kích hoạt nó. Dấu vết ngăn xếp chỉ ghi lại tên của các hàm cao hơn giúp xử lý lệnh cấp cao nhất, chứ không phải các chi tiết (dữ liệu) đôi khi cần để mô tả lệnh đó.

Thông thường phần mềm không được viết để thực hiện loại yêu cầu truy xuất nguồn gốc này. Điều này làm cho việc tương quan giữa thông điệp cấp thấp với lệnh cấp cao trở nên khó khăn hơn. Vấn đề đặc biệt tồi tệ hơn trong các hệ thống đa luồng tự do, trong đó nhiều yêu cầu và phản hồi có thể chồng lấp và quá trình xử lý có thể được chuyển sang một luồng khác với luồng nhận yêu cầu ban đầu.

Do đó, để có được giá trị cao nhất từ ​​đo từ xa, sẽ cần thay đổi kiến ​​trúc phần mềm tổng thể. Hầu hết các giao diện và lời gọi hàm sẽ cần phải được sửa đổi để chấp nhận và truyền bá một đối số "theo dõi".

Ngay cả các hàm tiện ích cũng cần thêm một đối số "theo dõi", để nếu nó không thành công, thông báo nhật ký sẽ cho phép chính nó được tương quan với một lệnh cấp cao nhất định.

Một thất bại khác sẽ làm cho việc theo dõi từ xa trở nên khó khăn là thiếu các tham chiếu đối tượng (con trỏ null hoặc tham chiếu). Khi một số dữ liệu quan trọng bị thiếu, có thể không thể báo cáo bất cứ điều gì hữu ích cho sự thất bại.

Về mặt viết thông điệp tường trình:

• Một số dự án phần mềm có thể yêu cầu bản địa hóa (dịch sang tiếng nước ngoài) ngay cả đối với các thông điệp tường trình chỉ dành cho quản trị viên.
• Một số dự án phần mềm có thể cần phân tách rõ ràng giữa dữ liệu nhạy cảm và dữ liệu không nhạy cảm, ngay cả cho mục đích ghi nhật ký và quản trị viên sẽ không có cơ hội vô tình nhìn thấy dữ liệu nhạy cảm nhất định.
• Đừng cố làm xáo trộn thông báo lỗi. Điều đó sẽ làm suy yếu niềm tin của khách hàng. Quản trị viên của khách hàng mong đợi đọc những nhật ký đó và hiểu ý nghĩa của nó. Đừng làm cho họ cảm thấy rằng có một số bí mật độc quyền phải được ẩn khỏi quản trị viên của khách hàng.
• Đừng hy vọng rằng khách hàng sẽ mang đến một mẩu nhật ký từ xa và nướng nhân viên hỗ trợ kỹ thuật của bạn. Họ mong đợi để biết. Huấn luyện nhân viên hỗ trợ kỹ thuật của bạn để giải thích chính xác nhật ký từ xa.

Hãy tưởng tượng bạn có một hàm tiện ích tầm thường được sử dụng ở hàng trăm vị trí trong mã của bạn:

decimal Inverse(decimal input)
{
    return 1 / input;
}

Nếu chúng tôi làm như bạn đề xuất, chúng tôi có thể viết

decimal Inverse(decimal input)
{
    try 
    {
        return 1 / input;
    }
    catch(Exception ex)
    {
        log.Write("Error 27349262 occurred.");
    }
}

Một lỗi có thể xảy ra là nếu đầu vào bằng không; điều này sẽ dẫn đến một sự phân chia bằng không ngoại lệ.

Vì vậy, giả sử bạn nhìn thấy 27349262 trong đầu ra hoặc nhật ký của bạn. Nơi nào bạn tìm kiếm để tìm mã đã vượt qua giá trị 0? Hãy nhớ rằng, hàm-- với ID duy nhất của nó-- được sử dụng ở hàng trăm nơi. Vì vậy, trong khi bạn có thể biết rằng phép chia bằng 0 xảy ra, bạn không biết 0đó là số chia.

Có vẻ với tôi nếu bạn định đăng nhập ID tin nhắn, bạn cũng có thể đăng nhập theo dõi ngăn xếp.

Nếu tính dài dòng của dấu vết ngăn xếp là điều làm phiền bạn, thì bạn không phải kết xuất nó thành một chuỗi theo cách mà bộ thực thi cung cấp cho bạn. Bạn có thể tùy chỉnh nó. Ví dụ: nếu bạn muốn một dấu vết ngăn xếp viết tắt chỉ đến ncấp độ, bạn có thể viết một cái gì đó như thế này (nếu bạn sử dụng c #):

static class ExtensionMethods
{
    public static string LimitedStackTrace(this Exception input, int layers)
    {
        return string.Join
        (
            ">",
            new StackTrace(input)
                .GetFrames()
                .Take(layers)
                .Select
                (
                    f => f.GetMethod()
                )
                .Select
                (
                    m => string.Format
                    (
                        "{0}.{1}", 
                        m.DeclaringType, 
                        m.Name
                    )
                )
                .Reverse()
        );
    }
}

Và sử dụng nó như thế này:

public class Haystack
{
    public static void Needle()
    {
        throw new Exception("ZOMG WHERE DID I GO WRONG???!");
    }

    private static void Test()
    {
        Needle();
    }

    public static void Main()
    {
        try
        {
            Test();
        }
        catch(System.Exception e)
        {
            //Get 3 levels of stack trace
            Console.WriteLine
            (
                "Error '{0}' at {1}", 
                e.Message, 
                e.LimitedStackTrace(3)
            );  
        }
    }
}

Đầu ra:

Error 'ZOMG WHERE DID I GO WRONG???!' at Haystack.Main>Haystack.Test>Haystack.Needle

Có thể dễ dàng hơn việc duy trì ID tin nhắn và linh hoạt hơn.

Ăn cắp mã của tôi từ DotNetFiddle

SAP NetWeaver đang làm điều này trong nhiều thập kỷ.

Nó đã được chứng minh là một công cụ có giá trị khi khắc phục các lỗi trong hệ thống mã khổng lồ là hệ thống SAP ERP điển hình.

Thông báo lỗi được quản lý trong một kho lưu trữ trung tâm nơi mỗi thông báo được xác định bởi lớp thông báo và số thông báo của nó.

Khi bạn muốn thông báo lỗi, bạn chỉ trạng thái lớp, số, mức độ nghiêm trọng và các biến cụ thể của thông báo. Các đại diện văn bản của tin nhắn được tạo ra trong thời gian chạy. Bạn thường thấy lớp tin nhắn và số trong bất kỳ bối cảnh nào xuất hiện tin nhắn. Điều này có một số hiệu ứng gọn gàng:

• Bạn có thể tự động tìm bất kỳ dòng mã nào trong cơ sở mã ABAP tạo thông báo lỗi cụ thể.

• Bạn có thể đặt các điểm dừng gỡ lỗi động kích hoạt khi thông báo lỗi cụ thể được tạo.

• Bạn có thể tra cứu lỗi trong các bài viết cơ sở kiến ​​thức của SAP và nhận được kết quả tìm kiếm phù hợp hơn so với khi bạn tìm kiếm "Không thể tìm thấy Foo".

• Các đại diện văn bản của tin nhắn có thể dịch. Vì vậy, bằng cách khuyến khích sử dụng tin nhắn thay vì chuỗi, bạn cũng có được khả năng của i18n.

Một ví dụ về cửa sổ bật lên lỗi với số tin nhắn:

Tra cứu lỗi đó trong kho lỗi:

Tìm nó trong cơ sở mã:

Tuy nhiên, có những hạn chế. Như bạn có thể thấy, những dòng mã này không còn tự ghi lại nữa. Khi bạn đọc mã nguồn và thấy một MESSAGEtuyên bố giống như trong ảnh chụp màn hình ở trên, bạn chỉ có thể suy ra từ ngữ cảnh thực sự có nghĩa là gì. Ngoài ra, đôi khi mọi người thực hiện các trình xử lý lỗi tùy chỉnh nhận lớp tin nhắn và số khi chạy. Trong trường hợp đó, lỗi không thể được tìm thấy tự động hoặc không thể tìm thấy ở vị trí xảy ra lỗi. Cách giải quyết cho vấn đề đầu tiên là tạo thói quen luôn luôn thêm một bình luận trong mã nguồn cho người đọc biết thông điệp đó có nghĩa gì. Thứ hai được giải quyết bằng cách thêm một số mã chết để đảm bảo tra cứu tin nhắn tự động hoạt động. Thí dụ:

" Do not use special characters
my_custom_error_handler->post_error( class = 'EU' number = '271').
IF 1 = 2.
   MESSAGE e271(eu).
ENDIF.    

Nhưng có một số tình huống mà điều này là không thể. Ví dụ, có một số công cụ mô hình hóa quy trình nghiệp vụ dựa trên giao diện người dùng nơi bạn có thể định cấu hình thông báo lỗi xuất hiện khi quy tắc kinh doanh bị vi phạm. Việc triển khai các công cụ đó hoàn toàn dựa trên dữ liệu, vì vậy những lỗi này sẽ không hiển thị trong danh sách được sử dụng. Điều đó có nghĩa là phụ thuộc quá nhiều vào danh sách được sử dụng khi cố gắng tìm ra nguyên nhân gây ra lỗi có thể là cá trích đỏ.

Vấn đề với cách tiếp cận đó là nó dẫn đến việc ghi nhật ký chi tiết hơn bao giờ hết. 99.9999% trong số đó bạn sẽ không bao giờ nhìn vào.

Thay vào đó, tôi khuyên bạn nên nắm bắt trạng thái khi bắt đầu quá trình của bạn và thành công / thất bại của quy trình.

Điều này cho phép bạn tái tạo lỗi cục bộ, bước qua mã và giới hạn việc đăng nhập của bạn ở hai nơi trên mỗi quy trình. ví dụ.

OrderPlaced {id:xyz; ...order data..}
OrderPlaced {id:xyz; ...Fail, ErrorMessage..}

Bây giờ tôi có thể sử dụng chính xác trạng thái trên máy dev của mình để tạo lại lỗi, chuyển qua mã trong trình gỡ lỗi của mình và viết một bài kiểm tra đơn vị mới để xác nhận sửa lỗi.

Ngoài ra, tôi có thể nếu được yêu cầu tránh đăng nhập nhiều hơn bằng cách chỉ đăng nhập thất bại hoặc giữ trạng thái ở nơi khác (cơ sở dữ liệu? Hàng đợi tin nhắn?)

Rõ ràng chúng ta phải hết sức cẩn thận về việc đăng nhập dữ liệu nhạy cảm. Vì vậy, điều này đặc biệt hiệu quả nếu giải pháp của bạn đang sử dụng hàng đợi tin nhắn hoặc mẫu lưu trữ sự kiện. Vì nhật ký chỉ cần nói "Tin nhắn xyz không thành công"

Tôi sẽ đề nghị rằng đăng nhập không phải là cách để giải quyết vấn đề này, mà là tình huống này được coi là ngoại lệ (nó khóa chương trình của bạn) và nên ném một ngoại lệ. Nói mã của bạn là:

public Foo GetFoo() {

     //Expecting that this should never by null.
     var aFoo = ....;

     if (aFoo == null) Log("Could not find Foo.");

     return aFoo;
}

Có vẻ như bạn gọi mã không được thiết lập để đối phó với thực tế là Foo không tồn tại và bạn có thể có khả năng là:

public Foo GetFooById(int id) {
     var aFoo = ....;

     if (aFoo == null) throw new ApplicationException("Could not find Foo for ID: " + id);

     return aFoo;
}

Và điều này sẽ trả về một dấu vết ngăn xếp cùng với ngoại lệ có thể được sử dụng để giúp gỡ lỗi.

Thay vào đó, nếu chúng tôi hy vọng rằng Foo có thể là null khi được truy xuất và điều đó là tốt, chúng tôi cần sửa các trang web gọi điện:

void DoSomeFoo(Foo aFoo) {

    //Guard checks on your input - complete with stack trace!
    if (aFoo == null) throw new ArgumentNullException(nameof(aFoo));

    ... operations on Foo...
}

Việc phần mềm của bạn bị treo hoặc hoạt động 'kỳ lạ' trong những trường hợp bất ngờ dường như là sai đối với tôi - nếu bạn cần một Foo và không thể xử lý nó không ở đó, thì có vẻ như bị sập hơn là cố gắng đi theo con đường có thể hệ thống của bạn bị hỏng

Các thư viện ghi nhật ký thích hợp cung cấp các cơ chế mở rộng, vì vậy nếu bạn muốn biết phương thức xuất phát thông điệp tường trình, họ có thể thực hiện việc đó ngay lập tức. Nó có tác động đến việc thực thi do quá trình yêu cầu tạo ra dấu vết ngăn xếp và duyệt qua nó cho đến khi bạn ra khỏi thư viện ghi nhật ký.

Điều đó nói rằng, nó thực sự phụ thuộc vào những gì bạn muốn ID của bạn làm cho bạn:

• Tương quan thông báo lỗi cung cấp cho người dùng vào nhật ký của bạn?
• Cung cấp ký hiệu về mã nào đã được thực thi khi thông báo được tạo?
• Theo dõi tên máy và dịch vụ?
• Theo dõi id chủ đề?

Tất cả những điều này có thể được thực hiện ngoài hộp với phần mềm ghi nhật ký thích hợp (nghĩa là không Console.WriteLine()hoặcDebug.WriteLine() ).

Cá nhân, điều quan trọng hơn là khả năng xây dựng lại các đường dẫn thực hiện. Đó là những công cụ như Zipkin được thiết kế để thực hiện. Một ID để theo dõi hành vi của một hành động người dùng trên toàn hệ thống. Bằng cách đặt nhật ký của bạn vào công cụ tìm kiếm trung tâm, bạn không chỉ tìm thấy các hành động chạy dài nhất mà còn gọi các nhật ký áp dụng cho một hành động đó (như ngăn xếp ELK ).

ID mờ thay đổi theo mọi tin nhắn không hữu ích lắm. ID nhất quán được sử dụng để theo dõi hành vi thông qua toàn bộ bộ dịch vụ siêu nhỏ ... vô cùng hữu ích.