ทำให้การค้นหารหัสโดยใช้รหัสข้อความที่ไม่ซ้ำกันทั่วโลก

รูปแบบทั่วไปสำหรับการค้นหาจุดบกพร่องตามสคริปต์นี้:

1. สังเกตความแปลกประหลาดเช่นไม่มีเอาต์พุตหรือโปรแกรมหยุดทำงาน
2. ค้นหาข้อความที่เกี่ยวข้องในบันทึกหรือผลลัพธ์ของโปรแกรมเช่น "ไม่พบ Foo" (ข้อมูลต่อไปนี้เกี่ยวข้องเฉพาะในกรณีที่เป็นเส้นทางที่ใช้ในการค้นหาจุดบกพร่องหากการติดตามสแต็กหรือข้อมูลการดีบักอื่น ๆ พร้อมใช้งานนั่นเป็นอีกเรื่องหนึ่ง)
3. ค้นหารหัสที่ข้อความถูกพิมพ์
4. ตรวจแก้จุดบกพร่องรหัสระหว่างสถานที่แรกที่ Foo ป้อน (หรือควรป้อน) รูปภาพและที่พิมพ์ข้อความ

ขั้นตอนที่สามนั้นเป็นขั้นตอนที่กระบวนการดีบั๊กมักจะหยุดชะงักเนื่องจากมีหลายสถานที่ในรหัสที่พิมพ์ "ไม่พบ Foo" (หรือสตริงเทมเพลตCould not find {name}) ในความเป็นจริงการสะกดผิดหลายครั้งช่วยให้ฉันค้นหาตำแหน่งจริงได้เร็วกว่าที่ฉันคาดไว้ - ทำให้ข้อความที่ไม่ซ้ำกันในทั้งระบบและบ่อยครั้งทั่วโลกส่งผลให้เครื่องมือค้นหาที่เกี่ยวข้องเข้าชมทันที

ข้อสรุปที่ชัดเจนจากสิ่งนี้คือเราควรใช้รหัสข้อความที่ไม่ซ้ำกันทั่วโลกในรหัสการเข้ารหัสอย่างหนักเป็นส่วนหนึ่งของสตริงข้อความและอาจตรวจสอบว่ามีการเกิดขึ้นเพียงครั้งเดียวของแต่ละ ID ในฐานรหัส ในแง่ของการบำรุงรักษาชุมชนนี้คิดว่าอะไรคือข้อดีและข้อเสียที่สำคัญที่สุดของวิธีการนี้และคุณจะใช้งานวิธีนี้อย่างไรหรือจะทำให้แน่ใจได้อย่างไรว่าการดำเนินการนั้นไม่จำเป็นเลย (สมมติว่าซอฟต์แวร์

โดยรวมนี่เป็นกลยุทธ์ที่ถูกต้องและมีคุณค่า นี่คือความคิดบางอย่าง

กลยุทธ์นี้เป็นที่รู้จักกันในนาม "telemetry" ในแง่ที่ว่าเมื่อข้อมูลดังกล่าวถูกรวมเข้าด้วยกันพวกเขาช่วย "ระบุตำแหน่ง" การติดตามการดำเนินการและอนุญาตให้ผู้แก้ไขปัญหาเข้าใจถึงสิ่งที่ผู้ใช้ / แอปพลิเคชันพยายามทำให้สำเร็จ .

ข้อมูลสำคัญบางอย่างที่ต้องรวบรวม (ซึ่งเราทุกคนรู้) คือ:

• ตำแหน่งของโค้ดเช่น call stack และบรรทัดของโค้ดโดยประมาณ
  • ไม่จำเป็นต้องใช้ "บรรทัดรหัสโดยประมาณ" หากฟังก์ชั่นการย่อยสลายอย่างสมเหตุสมผลเป็นหน่วยขนาดเล็ก
• ข้อมูลใด ๆ ที่เกี่ยวข้องกับความสำเร็จ / ความล้มเหลวของฟังก์ชัน
• คำสั่ง "ระดับสูง" ซึ่งสามารถสรุปสิ่งที่ผู้ใช้ / เอเจนต์ภายนอก / ผู้ใช้ API พยายามทำให้สำเร็จ
  • แนวคิดก็คือซอฟต์แวร์จะยอมรับและประมวลผลคำสั่งที่มาจากที่ใดที่หนึ่ง
  • ในระหว่างกระบวนการนี้อาจมีการเรียกใช้ฟังก์ชันหลายสิบถึงหลายร้อยถึงพันครั้ง
  • เราต้องการให้ telemetry ใด ๆ ที่สร้างขึ้นตลอดกระบวนการนี้สามารถตรวจสอบย้อนกลับไปยังคำสั่งระดับสูงสุดซึ่งเป็นต้นเหตุของกระบวนการนี้
  • สำหรับระบบบนเว็บคำขอ HTTP ดั้งเดิมและข้อมูลจะเป็นตัวอย่างของ "ข้อมูลคำขอระดับสูง" ดังกล่าว
  • สำหรับระบบ GUI ผู้ใช้คลิกบนสิ่งที่เหมาะกับคำอธิบายนี้

บ่อยครั้งที่วิธีการบันทึกแบบดั้งเดิมมักจะสั้นเนื่องจากความล้มเหลวในการติดตามข้อความบันทึกระดับต่ำกลับไปที่คำสั่งระดับสูงสุดที่เรียกใช้ การติดตามสแต็กจะจับเฉพาะชื่อของฟังก์ชันที่สูงขึ้นซึ่งช่วยจัดการกับคำสั่งระดับสูงสุดไม่ใช่รายละเอียด (ข้อมูล) ที่บางครั้งจำเป็นต้องใช้เพื่อระบุลักษณะของคำสั่งนั้น

ปกติซอฟต์แวร์ไม่ได้ถูกเขียนขึ้นเพื่อใช้ข้อกำหนดการตรวจสอบย้อนกลับชนิดนี้ สิ่งนี้ทำให้สัมพันธ์ข้อความระดับต่ำกับคำสั่งระดับสูงยากขึ้น ปัญหานั้นยิ่งแย่กว่านั้นในระบบที่มีหลายเธรดอย่างอิสระซึ่งการร้องขอและการตอบกลับจำนวนมากสามารถทับซ้อนกันได้และการประมวลผลอาจถูกถ่ายโอนไปยังเธรดอื่นที่แตกต่างจากเธรดที่รับคำร้องขอดั้งเดิม

ดังนั้นเพื่อให้ได้รับประโยชน์สูงสุดจากระบบวัดระยะไกลจึงต้องมีการเปลี่ยนแปลงสถาปัตยกรรมซอฟต์แวร์โดยรวม อินเทอร์เฟซและการเรียกใช้ฟังก์ชันส่วนใหญ่จะต้องได้รับการแก้ไขเพื่อยอมรับและเผยแพร่อาร์กิวเมนต์ "ผู้ติดตาม"

แม้แต่ฟังก์ชั่นยูทิลิตี้ก็จำเป็นต้องเพิ่มอาร์กิวเมนต์ "ตัวติดตาม" ดังนั้นหากล้มเหลวข้อความบันทึกจะอนุญาตให้ตัวเองมีความสัมพันธ์กับคำสั่งระดับสูงบางอย่าง

ความล้มเหลวอื่นที่จะทำให้การติดตาม telemetry ยากคือการอ้างอิงวัตถุหายไป (ตัวชี้หรือการอ้างอิง null) เมื่อข้อมูลที่สำคัญบางส่วนหายไปอาจเป็นไปไม่ได้ที่จะรายงานสิ่งที่มีประโยชน์สำหรับความล้มเหลว

ในแง่ของการเขียนข้อความบันทึก:

• บางโครงการซอฟต์แวร์อาจต้องใช้การแปลเป็นภาษาท้องถิ่น (แปลเป็นภาษาต่างประเทศ) แม้จะมีข้อความบันทึกเฉพาะสำหรับผู้ดูแลระบบเท่านั้น
• บางโครงการซอฟต์แวร์อาจต้องการการแยกที่ชัดเจนระหว่างข้อมูลที่มีความละเอียดอ่อนและข้อมูลที่ไม่ไวต่อความรู้สึกแม้กระทั่งเพื่อการบันทึกและผู้ดูแลระบบจะไม่มีโอกาสเห็นข้อมูลที่ละเอียดอ่อนบางอย่างโดยไม่ตั้งใจ
• อย่าพยายามทำให้งงข้อความผิดพลาด ที่จะทำลายความไว้วางใจของลูกค้า ผู้ดูแลระบบของลูกค้าคาดว่าจะอ่านบันทึกเหล่านั้นและทำให้เข้าใจได้ อย่าทำให้พวกเขารู้สึกว่ามีความลับกรรมสิทธิ์ที่ต้องซ่อนจากผู้ดูแลระบบของลูกค้า
• อย่าคาดหวังว่าลูกค้าจะนำบันทึกการตรวจสอบระยะไกลและย่างเจ้าหน้าที่ฝ่ายสนับสนุนด้านเทคนิคของคุณ พวกเขาคาดหวังที่จะรู้ ฝึกอบรมเจ้าหน้าที่ฝ่ายสนับสนุนด้านเทคนิคของคุณเพื่ออธิบายบันทึกการโทรมาตร

จินตนาการว่าคุณมีฟังก์ชั่นยูทิลิตี้เล็ก ๆ น้อย ๆ ที่ใช้ในหลายร้อยแห่งในรหัสของคุณ

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

ถ้าเราทำตามที่คุณแนะนำเราอาจเขียน

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

ข้อผิดพลาดที่อาจเกิดขึ้นคือถ้าอินพุตเป็นศูนย์ สิ่งนี้จะส่งผลให้เกิดการหารด้วยข้อยกเว้นเป็นศูนย์

สมมติว่าคุณเห็น 27349262 ในผลลัพธ์หรือบันทึกของคุณ คุณมองหารหัสที่ส่งผ่านค่าศูนย์ที่ไหน โปรดจำไว้ว่าฟังก์ชั่น - ที่มี ID เฉพาะ - มีการใช้งานในหลายร้อยแห่ง ดังนั้นในขณะที่คุณอาจรู้ว่าการหารด้วยศูนย์เกิดขึ้นคุณไม่มีความคิด0ว่ามันคืออะไร

ดูเหมือนว่าถ้าคุณกำลังจะรำคาญการบันทึกรหัสข้อความคุณก็อาจบันทึกการติดตามสแต็ค

ถ้า verbosity ของการติดตามสแต็กเป็นสิ่งที่รบกวนจิตใจคุณคุณไม่จำเป็นต้องดัมพ์มันเป็นสตริงตามที่ runtime มอบให้คุณ คุณสามารถปรับแต่งมัน ตัวอย่างเช่นหากคุณต้องการสแต็กการติดตามแบบย่อที่มีnระดับเพียงระดับเดียวคุณสามารถเขียนสิ่งนี้ (ถ้าคุณใช้ 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()
        );
    }
}

และใช้มันเช่นนี้

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)
            );  
        }
    }
}

เอาท์พุท:

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

อาจจะง่ายกว่าการรักษา ID ข้อความและยืดหยุ่นมากกว่า

ขโมยรหัสของฉันจาก DotNetFiddle

SAP NetWeaver กำลังทำสิ่งนี้มานานหลายทศวรรษ

มันพิสูจน์แล้วว่าเป็นเครื่องมือที่มีค่าเมื่อแก้ไขข้อผิดพลาดในโค้ดขนาดใหญ่ซึ่งเป็นระบบ SAP ERP โดยทั่วไป

ข้อความผิดพลาดได้รับการจัดการในพื้นที่เก็บข้อมูลส่วนกลางที่แต่ละข้อความถูกระบุโดยระดับข้อความและหมายเลขข้อความ

เมื่อคุณต้องการ ouput ข้อความแสดงข้อผิดพลาดคุณจะระบุตัวแปรคลาสจำนวนความรุนแรงและเฉพาะข้อความเท่านั้น การแสดงข้อความของข้อความถูกสร้างขึ้นที่รันไทม์ คุณมักจะเห็นคลาสข้อความและหมายเลขในบริบทใด ๆ ที่ข้อความปรากฏขึ้น สิ่งนี้มีเอฟเฟกต์เรียบร้อยหลายประการ:

• คุณสามารถค้นหาบรรทัดของรหัสใด ๆ โดยอัตโนมัติใน ABAP codebase ซึ่งสร้างข้อความแสดงข้อผิดพลาดเฉพาะ

• คุณสามารถตั้งค่าเบรกพอยต์ดีบักเกอร์แบบไดนามิกที่เรียกใช้เมื่อมีการสร้างข้อความแสดงข้อผิดพลาดเฉพาะ

• คุณสามารถค้นหาข้อผิดพลาดในบทความฐานความรู้ของ SAP และรับผลการค้นหาที่เกี่ยวข้องมากขึ้นกว่าการค้นหา "ไม่พบ Foo"

• การแทนข้อความของข้อความสามารถแปลได้ ดังนั้นด้วยการสนับสนุนการใช้ข้อความแทนที่จะเป็นสตริงคุณจะได้รับความสามารถของ i18n

ตัวอย่างของป๊อปอัพข้อผิดพลาดพร้อมหมายเลขข้อความ:

ค้นหาข้อผิดพลาดนั้นในที่เก็บข้อผิดพลาด:

ค้นหาได้ใน codebase:

อย่างไรก็ตามมีข้อเสียคือ อย่างที่คุณเห็นรหัสบรรทัดเหล่านี้ไม่ใช่การจัดทำเอกสารด้วยตนเองอีกต่อไป เมื่อคุณอ่านซอร์สโค้ดและดูMESSAGEคำสั่งเช่นเดียวกับที่อยู่ในภาพหน้าจอด้านบนคุณสามารถอนุมานจากบริบทว่ามันหมายถึงอะไรจริงๆ นอกจากนี้บางคนก็ใช้ตัวจัดการข้อผิดพลาดที่กำหนดเองซึ่งได้รับคลาสข้อความและหมายเลขที่รันไทม์ ในกรณีนั้นจะไม่พบข้อผิดพลาดโดยอัตโนมัติหรือไม่สามารถพบได้ในสถานที่ที่เกิดข้อผิดพลาดจริง วิธีแก้ปัญหาสำหรับปัญหาแรกคือทำให้มันเป็นนิสัยที่จะเพิ่มความคิดเห็นในซอร์สโค้ดที่บอกผู้อ่านว่าข้อความนั้นมีความหมายอย่างไร วิธีที่สองได้รับการแก้ไขโดยการเพิ่มรหัสที่ตายแล้วเพื่อให้แน่ใจว่าการค้นหาข้อความอัตโนมัติทำงานได้ ตัวอย่าง:

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

แต่มีบางสถานการณ์ที่ไม่สามารถทำได้ มีตัวอย่างเช่นเครื่องมือสร้างแบบจำลองกระบวนการทางธุรกิจบน UI ที่คุณสามารถกำหนดค่าข้อความแสดงข้อผิดพลาดให้ปรากฏเมื่อละเมิดกฎธุรกิจ การติดตั้งเครื่องมือเหล่านี้นั้นใช้ข้อมูลเป็นหลักดังนั้นข้อผิดพลาดเหล่านี้จะไม่ปรากฏในรายการที่ใช้ นั่นหมายถึงการพึ่งพามากเกินไปในรายการที่ใช้เมื่อพยายามค้นหาสาเหตุของข้อผิดพลาดอาจเป็นปลาเฮอริ่งแดง

ปัญหาของวิธีการนี้คือมันนำไปสู่การบันทึกอย่างละเอียดมากขึ้น 99.9999% ที่คุณจะไม่มีวันได้ดู

แต่ฉันขอแนะนำให้จับภาพสถานะที่กำหนดกระบวนการของคุณและความสำเร็จ / ความล้มเหลวของกระบวนการ

สิ่งนี้จะช่วยให้คุณสามารถสร้างข้อผิดพลาดซ้ำ ๆ ภายในเครื่องโดยใช้รหัสและ จำกัด การบันทึกของคุณไว้ที่สองแห่งต่อกระบวนการ เช่น.

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

ตอนนี้ฉันสามารถใช้สถานะเดียวกันที่แน่นอนบนเครื่อง dev ของฉันเพื่อทำซ้ำข้อผิดพลาดโดยใช้รหัสในโปรแกรมดีบั๊กและเขียนการทดสอบหน่วยใหม่เพื่อยืนยันการแก้ไข

นอกจากนี้ฉันสามารถทำได้ถ้าต้องการหลีกเลี่ยงการบันทึกเพิ่มเติมโดยการบันทึกล้มเหลวหรือรักษาสถานะไว้ที่อื่น (ฐานข้อมูลคิวข้อความหรือไม่)

เห็นได้ชัดว่าเราต้องระมัดระวังเป็นพิเศษเกี่ยวกับการบันทึกข้อมูลที่ละเอียดอ่อน ดังนั้นวิธีนี้จะทำงานได้ดีเป็นพิเศษหากโซลูชันของคุณใช้คิวข้อความหรือรูปแบบที่เก็บเหตุการณ์ ในขณะที่บันทึกจำเป็นต้องพูดว่า "Message xyz Failed"

ฉันขอแนะนำให้บันทึกไม่ได้เป็นวิธีที่จะไปเกี่ยวกับเรื่องนี้ แต่สถานการณ์นี้ถือว่าเป็นพิเศษ (มันล็อคโปรแกรมของคุณ) และข้อยกเว้นควรจะโยน สมมติว่ารหัสของคุณคือ:

public Foo GetFoo() {

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

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

     return aFoo;
}

ดูเหมือนว่าคุณไม่ได้ตั้งรหัสเพื่อจัดการกับความจริงที่ว่า Foo ไม่มีอยู่และคุณควรจะเป็น:

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

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

     return aFoo;
}

และสิ่งนี้จะส่งคืนการติดตามสแต็กพร้อมกับข้อยกเว้นที่สามารถใช้เพื่อช่วยในการดีบัก

อีกทางเลือกหนึ่งถ้าเราคาดหวังว่า Foo จะเป็นโมฆะเมื่อทำการเรียกคืนและไม่เป็นผลเราจำเป็นต้องแก้ไขไซต์การโทร:

void DoSomeFoo(Foo aFoo) {

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

    ... operations on Foo...
}

ความจริงที่ว่าซอฟต์แวร์ของคุณแฮงค์หรือทำตัว 'แปลก' ภายใต้สถานการณ์ที่ไม่คาดคิดดูเหมือนจะผิดกับฉัน - ถ้าคุณต้องการ Foo และไม่สามารถจัดการกับมันไม่ได้อยู่ที่นั่นแล้วมันก็ดูจะดีกว่าพังพยายามกว่าเส้นทางที่อาจ ระบบของคุณเสียหาย

ไลบรารีการบันทึกที่เหมาะสมมีกลไกของส่วนขยายดังนั้นหากคุณต้องการทราบวิธีการที่ข้อความบันทึกเกิดขึ้นพวกเขาสามารถทำสิ่งนั้นนอกกรอบได้ มันมีผลกระทบกับการดำเนินการเนื่องจากกระบวนการต้องการสร้างการติดตามสแต็กและการข้ามผ่านจนกว่าคุณจะออกจากไลบรารีการบันทึก

ที่กล่าวว่าขึ้นอยู่กับสิ่งที่คุณต้องการให้ ID ของคุณทำเพื่อคุณ:

• เชื่อมโยงข้อความแสดงข้อผิดพลาดที่ผู้ใช้มีต่อบันทึกของคุณหรือไม่
• ให้สัญกรณ์ว่ารหัสใดกำลังทำงานเมื่อมีการสร้างข้อความ
• ติดตามชื่อเครื่องและอินสแตนซ์ของบริการ?
• ติดตาม id เธรดหรือไม่

ทุกสิ่งเหล่านี้สามารถทำได้นอกกรอบด้วยซอฟต์แวร์บันทึกที่เหมาะสม (เช่นไม่ใช่Console.WriteLine()หรือDebug.WriteLine())

โดยส่วนตัวแล้วสิ่งที่สำคัญกว่าคือความสามารถในการสร้างเส้นทางการทำงานใหม่ นั่นคือสิ่งที่เครื่องมืออย่างZipkinออกแบบมาให้สำเร็จ หนึ่ง ID เพื่อติดตามพฤติกรรมของการกระทำของผู้ใช้หนึ่งคนทั่วทั้งระบบ โดยการวางบันทึกของคุณในเครื่องมือค้นหากลางคุณสามารถไม่เพียงพบการกระทำที่ยาวที่สุดที่ใช้ แต่เรียกบันทึกที่ใช้กับการกระทำที่หนึ่ง (เช่นสแต็ค ELK )

รหัสทึบแสงที่เปลี่ยนไปกับทุกข้อความไม่มีประโยชน์มาก ID ที่สอดคล้องกันใช้ในการติดตามพฤติกรรมผ่านชุดไมโครไซต์ทั้งหมด ... มีประโยชน์อย่างมาก