refinery
v2.8.4
สำหรับรายการรายละเอียดของคำขอดึงที่เชื่อมโยงที่รวมอยู่ในแต่ละรุ่นให้ดูที่ changelog.md สำหรับข้อมูลที่อ่านได้เพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงล่าสุดโปรดดู release_notes.md
โรงกลั่นเป็นพร็อกซีการสุ่มตัวอย่างแบบหางและทำงานในระดับการติดตามทั้งหมด โรงกลั่นตรวจสอบร่องรอยทั้งหมดและใช้การตัดสินใจสุ่มตัวอย่างอย่างชาญฉลาดกับการติดตามแต่ละครั้ง การตัดสินใจเหล่านี้จะพิจารณาว่าจะเก็บหรือวางข้อมูลการติดตามในข้อมูลตัวอย่างที่ส่งต่อไปยังรังผึ้งหรือไม่
รูปแบบการสุ่มตัวอย่างแบบหางช่วยให้คุณสามารถตรวจสอบการติดตามทั้งหมดในครั้งเดียวและตัดสินใจที่จะสุ่มตัวอย่างตามเนื้อหา ตัวอย่างเช่นข้อมูลของคุณอาจมีช่วงรูทที่มีรหัสสถานะ HTTP เพื่อให้บริการสำหรับการร้องขอและช่วงอื่นที่มีข้อมูลว่าข้อมูลนั้นถูกเสิร์ฟจากแคชหรือไม่ การใช้โรงกลั่นคุณสามารถเลือกที่จะเก็บร่องรอยที่มีรหัสสถานะ 500 และเสิร์ฟจากแคช
โรงกลั่นสนับสนุนการสุ่มตัวอย่างหางหลายชนิด:
http.status_code คุณสามารถรวมไว้ในข้อมูลตัวอย่างของคุณ:2xx4xx5xxโรงกลั่นช่วยให้คุณรวมเทคนิคทั้งหมดข้างต้นเพื่อให้บรรลุพฤติกรรมการสุ่มตัวอย่างที่คุณต้องการ
โรงกลั่นได้รับการออกแบบให้นั่งอยู่ในโครงสร้างพื้นฐานของคุณซึ่งร่องรอยทั้งหมดสามารถเข้าถึงได้ โรงกลั่นสามารถเรียกใช้แบบสแตนด์อโลนหรือนำไปใช้ในคลัสเตอร์ของกระบวนการโรงกลั่นสองกระบวนการขึ้นไปที่สามารถเข้าถึงได้ผ่านตัวโหลดบาลานซ์แยกต่างหาก
กระบวนการโรงกลั่นจะต้องสามารถสื่อสารซึ่งกันและกันเพื่อให้มีสมาธิกับร่องรอยบนเซิร์ฟเวอร์เดี่ยว
ภายในแอปพลิเคชันของคุณ (หรือแหล่งเหตุการณ์ Honeycomb อื่น ๆ ) คุณจะกำหนดค่า API Host ให้เป็น http(s)://load-balancer/ ทุกอย่างอื่นยังคงเหมือนเดิมเช่นคีย์ API ชื่อชุดข้อมูลและอื่น ๆ เนื่องจากทุกสิ่งที่อาศัยอยู่กับไคลเอนต์ต้นกำเนิด
ทุกอินสแตนซ์ของโรงกลั่นควรมีขั้นต่ำ:
linux/amd64 หรือ linux/arm64ในหลายกรณีโรงกลั่นต้องการเพียงหนึ่งโหนด หากประสบปริมาณการรับส่งข้อมูลจำนวนมากคุณอาจต้องขยายขนาดเป็นหลายโหนดและอาจต้องมีอินสแตนซ์ Redis ขนาดเล็กเพื่อจัดการกับการปรับขนาด
เราขอแนะนำให้เพิ่มปริมาณ RAM และจำนวนแกนหลังจากการตั้งค่าเริ่มต้นของคุณ สามารถใช้ RAM และ CPU เพิ่มเติมได้โดยการเพิ่มค่าการกำหนดค่า โดยเฉพาะอย่างยิ่ง CacheCapacity เป็นค่าการกำหนดค่าที่สำคัญ ระบบ Stress Relief ของโรงกลั่นให้ข้อบ่งชี้ที่ดีว่าโรงกลั่นทำงานหนักแค่ไหนและเมื่อถูกเรียกใช้บันทึก (เป็น reason ) ชื่อของค่าการกำหนดค่าโรงกลั่นที่ควรเพิ่มขึ้นเพื่อลดความเครียด ใช้เอกสารการปรับขนาดและการแก้ไขปัญหาของเราเพื่อเรียนรู้เพิ่มเติม
โรงกลั่นมีให้บริการเป็นแผนภูมิหางเสือในที่เก็บ Honeycomb Helm
คุณสามารถติดตั้งโรงกลั่นด้วยคำสั่งต่อไปนี้ซึ่งใช้ไฟล์ค่าเริ่มต้น:
helm repo add honeycomb https://honeycombio.github.io/helm-charts
helm install refinery honeycomb/refineryอีกทางเลือกหนึ่งจัดหาไฟล์ค่าที่กำหนดเองของคุณเอง:
helm install refinery honeycomb/refinery --values /path/to/refinery-values.yaml โดยที่ /path/to/refinery-values.yaml เป็นเส้นทางของไฟล์
เมื่อดำเนินการในคลัสเตอร์โรงกลั่นคาดว่าจะรวบรวมช่วงทั้งหมดในการติดตามลงบนอินสแตนซ์เดียวเพื่อให้สามารถตัดสินใจตามร่องรอย เนื่องจากแต่ละช่วงมาถึงอย่างอิสระแต่ละอินสแตนซ์ของโรงกลั่นจะต้องสามารถสื่อสารกับเพื่อนร่วมงานทั้งหมดเพื่อกระจายร่องรอยไปยังอินสแตนซ์ที่ถูกต้อง
การสื่อสารนี้สามารถจัดการได้สองวิธี: ผ่านรายการเพื่อนที่ชัดเจนในไฟล์การกำหนดค่าหรือโดยใช้การลงทะเบียนตนเองผ่านแคช Redis ที่ใช้ร่วมกัน โดยทั่วไปการติดตั้งควรใช้ Redis แม้ในการติดตั้งขนาดใหญ่การโหลดบนเซิร์ฟเวอร์ Redis นั้นค่อนข้างเบาโดยแต่ละอินสแตนซ์จะมีการร้องขอเพียงไม่กี่ครั้งต่อนาที อินสแตนซ์ Redis เดียวที่มี CPU เศษส่วนมักจะเพียงพอ
การกำหนดค่าถูกควบคุมโดยไฟล์การกำหนดค่าสองไฟล์ของโรงกลั่นซึ่งโดยทั่วไปเรียกว่า config.yaml สำหรับการกำหนดค่าทั่วไปและ rules.yaml สำหรับการกำหนดค่าการกำหนดค่า ไฟล์เหล่านี้สามารถโหลดได้จากระบบไฟล์ที่เข้าถึงได้หรือโหลดด้วยคำขอรับที่ไม่ผ่านการตรวจสอบจาก URL
เรียนรู้เพิ่มเติมเกี่ยวกับ config.yaml และพารามิเตอร์ทั้งหมดที่ควบคุมการทำงานของโรงกลั่นในเอกสารการกำหนดค่าโรงกลั่นของเรา
เรียนรู้เพิ่มเติมเกี่ยวกับ rules.yaml การกำหนดค่า YAML และ Sampler ในเอกสารวิธีการสุ่มตัวอย่างโรงกลั่นของเรา
มันถูกต้องในการระบุแหล่งที่มาการกำหนดค่ามากกว่าหนึ่งแหล่ง ตัวอย่างเช่นมันเป็นไปได้ที่จะมีไฟล์การกำหนดค่าทั่วไปรวมทั้งไฟล์แยกต่างหากที่มีปุ่มเท่านั้น ในบรรทัดคำสั่งระบุหลายไฟล์โดยทำซ้ำสวิตช์บรรทัดคำสั่ง ในตัวแปรสภาพแวดล้อมให้แยกตำแหน่งการกำหนดค่าหลายตำแหน่งด้วยเครื่องหมายจุลภาค
โรงกลั่นเป็นแอปพลิเคชันบรรทัดคำสั่ง Linux-style ทั่วไปและรองรับสวิตช์บรรทัดคำสั่งหลายตัว
refinery -h จะพิมพ์ข้อความช่วยเหลือเพิ่มเติมรายการตัวเลือกบรรทัดคำสั่งทั้งหมดและตัวแปรสภาพแวดล้อมที่รองรับ
โรงกลั่นสนับสนุนตัวแปรสภาพแวดล้อมที่สำคัญต่อไปนี้ โปรดดูความช่วยเหลือบรรทัดคำสั่งหรือเอกสารออนไลน์สำหรับรายการทั้งหมด สวิตช์บรรทัดคำสั่งมีความสำคัญกว่าการกำหนดค่าไฟล์และตัวแปรสภาพแวดล้อมมีความสำคัญกว่าทั้งสอง
| ตัวแปรสภาพแวดล้อม | ฟิลด์การกำหนดค่า |
|---|---|
REFINERY_GRPC_LISTEN_ADDRESS | GRPCListenAddr |
REFINERY_REDIS_HOST | PeerManagement.RedisHost |
REFINERY_REDIS_USERNAME | PeerManagement.RedisUsername |
REFINERY_REDIS_PASSWORD | PeerManagement.RedisPassword |
REFINERY_HONEYCOMB_API_KEY | HoneycombLogger.LoggerAPIKey |
REFINERY_HONEYCOMB_METRICS_API_KEY | LegacyMetrics.APIKey |
REFINERY_HONEYCOMB_API_KEY | LegacyMetrics.APIKey |
REFINERY_QUERY_AUTH_TOKEN | QueryAuthToken |
หมายเหตุ: REFINERY_HONEYCOMB_METRICS_API_KEY มีความสำคัญเหนือกว่า REFINERY_HONEYCOMB_API_KEY สำหรับการกำหนดค่า LegacyMetrics.APIKey
การส่งข้อมูลไปยัง Honeycomb ต้องแนบปุ่ม API กับ telemetry เพื่อให้การจัดการ telemetry ง่ายขึ้นโรงกลั่นสนับสนุนตัวเลือก ReceiveKeys และการกำหนด SendKey พร้อมกับ AcceptOnlyListedKeys และ SendKeyMode ในชุดค่าผสมต่าง ๆ พวกเขามีพลังที่แสดงออกมากมาย โปรดดูเอกสารการกำหนดค่าสำหรับรายละเอียดเกี่ยวกับวิธีการตั้งค่าพารามิเตอร์เหล่านี้
การเริ่มต้นอย่างรวดเร็วสำหรับสถานการณ์เฉพาะด้านล่าง:
SendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น allSendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น nonblankReceiveKeys ในรายการข้อยกเว้นSendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น unlistedSendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น missingonlyReceiveKeysAcceptOnlyListedKeys เป็น trueSendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น listedonlyAcceptOnlyListedKeys เป็น falseReceiveKeys เป็นคีย์ที่ควรเปลี่ยนSendKey เป็นปุ่ม Honeycomb ที่ถูกต้องSendKeyMode เป็น listedonly + หมายเหตุ + + เมื่อใช้ beelines กับคีย์ API แบบคลาสสิกเพื่อส่งข้อมูลไปยังโรงกลั่นให้แน่ใจว่า SendKey ยังเป็นคีย์คลาสสิกไม่ใช่คีย์สภาพแวดล้อมและบริการ (E&S)
เมื่อเริ่มต้นใช้งานโรงกลั่นหรือเมื่ออัปเดตกฎการสุ่มตัวอย่างอาจเป็นประโยชน์ในการตรวจสอบว่ากฎนั้นทำงานตามที่คาดไว้ก่อนที่คุณจะเริ่มการรับส่งข้อมูล ในการทำเช่นนั้นให้ใช้โหมด Dry Run ในโรงกลั่น
เปิดใช้งานโหมด Dry Run โดยการเพิ่ม DryRun = true ในไฟล์การกำหนดค่าของคุณ ( config.yaml ) จากนั้นใช้ตัวสร้างแบบสอบถามใน Honeycomb UI เพื่อเรียกใช้แบบสอบถามเพื่อตรวจสอบผลลัพธ์ของคุณและตรวจสอบว่ากฎนั้นทำงานตามที่ตั้งใจไว้
เมื่อเปิดใช้งานโหมด Dry Run แล้ว Metric trace_send_kept จะเพิ่มขึ้นสำหรับการติดตามแต่ละครั้งและตัวชี้วัดสำหรับ trace_send_dropped จะยังคงอยู่ 0 ซึ่งสะท้อนให้เห็นว่าเรากำลังส่งร่องรอยทั้งหมดไปยังรังผึ้ง
โรงกลั่นใช้คิวที่มีขอบเขตและบัฟเฟอร์แบบวงกลมเพื่อจัดการการจัดสรรร่องรอยดังนั้นแม้ภายใต้การใช้หน่วยความจำระดับสูงไม่ควรขยายอย่างมาก อย่างไรก็ตามเนื่องจากร่องรอยจะถูกเก็บไว้ในบัฟเฟอร์แบบวงกลมเมื่อปริมาณงานของร่องรอยเกินขนาดของบัฟเฟอร์สิ่งต่าง ๆ จะเริ่มผิดพลาด หากคุณมีการกำหนดค่าสถิติตัวนับชื่อ collect_cache_buffer_overrun จะเพิ่มขึ้นทุกครั้งที่เกิดขึ้น อาการของสิ่งนี้คือร่องรอยจะหยุดสะสมเข้าด้วยกันและแทนที่จะเป็นช่วงที่ควรเป็นส่วนหนึ่งของร่องรอยเดียวกันจะได้รับการปฏิบัติเป็นสองร่องรอยแยกกัน ร่องรอยทั้งหมดจะยังคงถูกส่ง (และตัวอย่าง) แต่การตัดสินใจสุ่มตัวอย่างบางอย่างจะทำกับข้อมูลที่ไม่สมบูรณ์ ขนาดของบัฟเฟอร์แบบวงกลมเป็นตัวเลือกการกำหนดค่าชื่อ CacheCapacity ในการเลือกมูลค่าที่ดีคุณควรพิจารณาปริมาณงานของร่องรอย (ตัวอย่างเช่นร่องรอย / ครั้งที่สองเริ่มต้น) และคูณด้วยระยะเวลาสูงสุดของการติดตาม (เช่น 3 วินาที) จากนั้นคูณด้วยบัฟเฟอร์ขนาดใหญ่ (อาจจะ 10x) . การประมาณการนี้จะให้หัวที่ดี
การกำหนดจำนวนเครื่องจักรที่จำเป็นในคลัสเตอร์ไม่ใช่วิทยาศาสตร์ที่แน่นอนและได้รับอิทธิพลที่ดีที่สุดจากการดูบัฟเฟอร์ overruns แต่สำหรับฮิวริสติกคร่าวๆนับบนเครื่องเดียวโดยใช้หน่วยความจำประมาณ 2GB เพื่อจัดการเหตุการณ์ที่เข้ามา 5,000 ครั้งและติดตามร่องรอยย่อย 500 ครั้งต่อวินาที (สำหรับการติดตามเต็มรูปแบบยาวนานน้อยกว่าหนึ่งวินาทีและขนาดเฉลี่ย 10 ช่วงต่อการติดตาม) .
โรงกลั่นนำเสนอกลไกที่เรียกว่า Stress Relief ที่เพิ่มความเสถียรภายใต้ภาระหนัก ตัวชี้วัด stress_level เป็นตัวชี้วัดสังเคราะห์ในระดับตั้งแต่ 0 ถึง 100 ที่สร้างขึ้นจากตัวชี้วัดโรงกลั่นหลายแห่งที่เกี่ยวข้องกับขนาดคิวและการใช้หน่วยความจำ ภายใต้การดำเนินการปกติค่าของมันควรอยู่ในหลักเดียว ในระหว่างการระเบิดของการจราจรสูงระดับความเครียดอาจคืบคลานขึ้นแล้วลดลงอีกครั้งเมื่อปริมาณลดลง เมื่อเข้าใกล้ 100 จึงมีโอกาสมากขึ้นที่โรงกลั่นจะเริ่มล้มเหลวและอาจผิดพลาด
Stress Relief เป็นระบบที่สามารถตรวจสอบตัวชี้วัด stress_level และโหลดหลั่งเมื่อความเครียดกลายเป็นอันตรายต่อความมั่นคง เมื่อถึงระดับ ActivationLevel โหมด Stress Relief จะเปิดใช้งาน ในสถานะนี้ โรงกลั่นจะกำหนดตัวอย่างแต่ละช่วงตาม TraceID โดยไม่ต้องเก็บส่วนที่เหลือของการติดตามหรือประเมินเงื่อนไขกฎ Stress Relief จะยังคงทำงานอยู่จนกว่าความเครียดจะต่ำกว่าการปิด DeactivationLevel ที่ระบุไว้ในการกำหนดค่า
การตั้งค่าการบรรเทาความเครียดคือ:
Mode - การตั้งค่าเพื่อระบุวิธี Stress Relief never ระบุว่า Stress Relief จะไม่เปิดใช้งาน monitor หมายถึง Stress Relief จะเปิดใช้งานเมื่อ ActivationLevel และปิดการใช้งานเมื่อถึง หมายความว่าโหมด Stress Relief จะมีส่วนร่วมอย่างต่อ always โหมด always มีไว้สำหรับใช้ในสถานการณ์ฉุกเฉินActivationLevel - เมื่อระดับความเครียดสูงกว่าเกณฑ์นี้โรงกลั่นจะเปิดใช้งาน Stress ReliefDeactivationLevel - เมื่อระดับความเครียดต่ำกว่าเกณฑ์นี้โรงกลั่นจะปิด Stress ReliefSamplingRate - อัตราที่ตัวอย่างโรงกลั่นในขณะที่ Stress Relief ทำงานอยู่ ปัจจุบัน stress_level เป็นพร็อกซีที่ดีที่สุดสำหรับการโหลดโดยรวมในโรงกลั่น แม้ว่า Stress Relief จะไม่ทำงาน แต่ถ้า stress_level สูงกว่า 50 แต่ก็เป็นตัวบ่งชี้ที่ดีที่โรงกลั่นต้องการทรัพยากรมากขึ้น - ซีพียูมากขึ้นหน่วยความจำมากขึ้นหรือโหนดมากขึ้น ในทางกลับกันหาก stress_level ไม่เคยเข้าไปในตัวเลขสองหลักก็มีแนวโน้มว่าโรงกลั่นจะถูก overprovisioned
โรงกลั่นออกมาจำนวนหนึ่งของตัวชี้วัดเพื่อให้ข้อบ่งชี้เกี่ยวกับสุขภาพของกระบวนการ ตัวชี้วัดเหล่านี้ควรถูกส่งไปยังรังผึ้งโดยทั่วไปจะมี telemetry แบบเปิดและยังสามารถสัมผัสกับโพร สิ่งที่น่าสนใจที่จะดูคือ:
[incoming|peer]_router_* : มีกี่เหตุการณ์ (ไม่มีข้อมูลการติดตาม) เทียบกับ Spans (มีข้อมูลการติดตาม) ได้รับการยอมรับและมีกี่คนที่ส่งไปยังเพื่อนcollect_cache_buffer_overrun : สิ่งนี้น่าจะเป็นศูนย์ ค่าบวกบ่งชี้ถึงความจำเป็นที่จะต้องขยายขนาดของบัฟเฟอร์การติดตามแบบวงกลมของโรงกลั่น (ผ่านการกำหนดค่า CacheCapacity )process_uptime_seconds : บันทึกเวลาการทำงานของแต่ละกระบวนการ มองหาการรีสตาร์ทที่ไม่คาดคิดเป็นกุญแจสู่ข้อ จำกัด ของหน่วยความจำ ระดับการบันทึกเริ่มต้นของ warn นั้นค่อนข้างเงียบ ระดับ debug ปล่อยข้อมูลมากเกินไปที่จะใช้ในการผลิต แต่มีข้อมูลที่ยอดเยี่ยมในสภาพแวดล้อมก่อนการผลิตรวมถึงข้อมูลการตัดสินใจติดตาม info อยู่ที่ไหนสักแห่งระหว่าง การตั้งค่าระดับการบันทึกเพื่อ debug ในระหว่างการกำหนดค่าเริ่มต้นจะช่วยให้เข้าใจสิ่งที่ทำงานและสิ่งที่ไม่ได้ แต่เมื่อปริมาณการจราจรเพิ่มขึ้นควรตั้งค่าเป็น warn หรือแม้แต่ error บันทึกอาจถูกส่งไปยัง stdout หรือ honeycomb
โรงกลั่นตรวจสอบการกำหนดค่าเมื่อเริ่มต้นหรือเมื่อมีการโหลดการกำหนดค่าใหม่และจะปล่อยการวินิจฉัยสำหรับปัญหาใด ๆ ในการเริ่มต้นมันจะปฏิเสธที่จะเริ่ม; ในการโหลดซ้ำมันจะไม่เปลี่ยนการกำหนดค่าที่มีอยู่
ตรวจสอบการกำหนดค่าที่โหลดโดยใช้หนึ่งในจุดสิ้นสุด /query จากบรรทัดคำสั่งบนเซิร์ฟเวอร์ที่สามารถเข้าถึงโฮสต์โรงกลั่น
จุดสิ้นสุด /query ได้รับการป้องกันและสามารถเปิดใช้งานได้โดยการระบุ QueryAuthToken ในไฟล์การกำหนดค่าหรือระบุ REFINERY_QUERY_AUTH_TOKEN ในสภาพแวดล้อม คำขอทั้งหมดไปยังจุดสิ้นสุด /query ใด ๆ จะต้องรวมถึงส่วนหัว X-Honeycomb-Refinery-Query ที่ตั้งค่าเป็นค่าของโทเค็นที่ระบุ
สำหรับการกำหนดค่าตามไฟล์ (ประเภทเดียวที่รองรับในปัจจุบัน) ค่า hash นั้นเหมือนกับค่าที่สร้างโดยคำสั่ง md5sum สำหรับไฟล์การกำหนดค่าที่กำหนด
สำหรับคำสั่งเหล่านี้ทั้งหมด:
$REFINERY_HOST ควรเป็น URL ของโรงกลั่นของคุณ$FORMAT สามารถเป็นหนึ่งใน yaml , toml หรือ json$DATASET เป็นชื่อของชุดข้อมูลที่คุณต้องการตรวจสอบเพื่อดึงการกำหนดค่ากฎทั้งหมด:
curl --include --get $REFINERY_HOST/query/allrules/$FORMAT --header "x-honeycomb-refinery-query: my-local-token"
ในการดึงชุดกฎที่โรงกลั่นใช้สำหรับชุดข้อมูลที่ระบุซึ่งจะถูกส่งคืนเป็นแผนที่ของประเภทตัวอย่างไปยังชุดกฎ:
curl --include --get $REFINERY_HOST/query/rules/$FORMAT/$DATASET --header "x-honeycomb-refinery-query: my-local-token"
ในการดึงข้อมูลเกี่ยวกับการกำหนดค่าที่ใช้อยู่ในปัจจุบันรวมถึงการประทับเวลาเมื่อโหลดการกำหนดค่าล่าสุด:
curl --include --get $REFINERY_HOST/query/configmetadata --header "x-honeycomb-refinery-query: my-local-token"
โรงกลั่นสามารถส่ง telemetry ที่มีข้อมูลที่สามารถช่วยแก้ไขข้อบกพร่องการตัดสินใจสุ่มตัวอย่างที่ทำ หากต้องการเปิดใช้งานในไฟล์การกำหนดค่าให้ตั้ง AddRuleReasonToTrace เป็น true สิ่งนี้จะทำให้เกิดร่องรอยที่ส่งไปยัง Honeycomb เพื่อรวม meta.refinery.reason ซึ่งจะมีข้อความระบุว่ากฎใดที่ได้รับการประเมินซึ่งทำให้เกิดการติดตาม
โรงกลั่นยังไม่ได้มีร่องรอยบัฟเฟอร์หรือการตัดสินใจสุ่มตัวอย่างลงในดิสก์ เมื่อคุณรีสตาร์ทกระบวนการร่องรอยทั้งหมดในเที่ยวบินจะถูกล้าง (ส่งต้นน้ำไปยังรังผึ้ง) แต่คุณจะสูญเสียบันทึกการตัดสินใจตามร่องรอยที่ผ่านมา เมื่อเริ่มสำรองข้อมูลจะเริ่มต้นด้วยกระดานชนวนที่สะอาด
ภายในแต่ละไดเรกทอรีอินเทอร์เฟซการส่งออกการพึ่งพาอยู่ในไฟล์ที่มีชื่อเดียวกับไดเรกทอรีและจากนั้น (ส่วนใหญ่) ไฟล์อื่น ๆ แต่ละไฟล์เป็นทางเลือกอื่นของอินเทอร์เฟซนั้น ตัวอย่างเช่นใน logger , /logger/logger.go มีคำจำกัดความอินเตอร์เฟสและ logger/honeycomb.go มีการใช้งานอินเตอร์เฟส logger ที่จะส่งบันทึกไปยัง Honeycomb
main.go ตั้งค่าแอพและเลือกตัวเลือกเกี่ยวกับการใช้งานการพึ่งพารุ่นใดที่จะใช้ (เช่นตัวบันทึกใดที่ตัวอย่างซึ่งเป็น ฯลฯ ) มันเริ่มต้นขึ้นทุกอย่างแล้วเปิด App
app/app.go เป็นจุดควบคุมหลัก เมื่อฟังก์ชั่น Start จบโปรแกรมจะปิดตัวลง มันเปิดตัว Router สองตัวที่ฟังเหตุการณ์ที่เข้ามา
route/route.go ฟังบนเครือข่ายสำหรับการรับส่งข้อมูลที่เข้ามา มีเราเตอร์สองตัวที่ทำงานอยู่และพวกเขาจัดการกับการรับส่งข้อมูลที่เข้ามาหลายประเภท: เหตุการณ์ที่มาจากโลกภายนอก (เราเตอร์ incoming ) และเหตุการณ์ที่มาจากสมาชิกคนอื่นของคลัสเตอร์โรงกลั่น (การรับส่งข้อมูล peer ) เมื่อได้รับเหตุการณ์แล้วมันจะตัดสินใจว่าควรไปที่ไหนต่อไป: นี่เป็นคำขอที่เข้ามา (หรือชุดของเหตุการณ์) และถ้าเป็นเช่นนั้นมันมีรหัสติดตามหรือไม่? ทุกสิ่งที่ไม่ใช่เหตุการณ์หรือเหตุการณ์ที่ไม่มีรหัสติดตามจะถูกส่งไปยัง transmission ผ่านไปยังรังผึ้งทันที หากเป็นเหตุการณ์ที่มี ID ติดตามเราเตอร์จะแยก ID ติดตามแล้วใช้ sharder เพื่อตัดสินใจว่าสมาชิกของคลัสเตอร์โรงกลั่นใดควรจัดการกับร่องรอยนี้ ถ้าเป็นเพื่อนเหตุการณ์จะถูกส่งต่อไปยังเพียร์นั้น ถ้าเป็นเราเหตุการณ์จะถูกเปลี่ยนเป็นตัวแทนภายในและส่งมอบให้กับ collector เพื่อรวมกลุ่มกันเป็นร่องรอย
collect/collect.go The Collector มีหน้าที่รับผิดชอบในการรวมกลุ่มเข้าด้วยกันเป็นร่องรอยและตัดสินใจว่าจะส่งพวกเขาไปยังรังผึ้งเมื่อใดหรือควรจะทิ้ง ครั้งแรกที่มีการเห็นรหัสติดตามนักสะสมจะเริ่มจับเวลา หากช่วงของรูทซึ่งเป็นช่วงที่มีรหัสติดตามและไม่มีรหัสหลักมาถึงก่อนที่ตัวจับเวลาจะหมดอายุการติดตามจะถูกพิจารณาว่าสมบูรณ์ การติดตามจะถูกส่งและตัวจับเวลาจะถูกยกเลิก หากตัวจับเวลาหมดอายุก่อนที่รูทจะมาถึงการติดตามจะถูกส่งไม่ว่าจะเสร็จสมบูรณ์หรือไม่ ก่อนที่จะส่งนักสะสมจะขอ sampler อัตราตัวอย่างและไม่ว่าจะติดตามการติดตามหรือไม่ นักสะสมเชื่อฟังการตัดสินใจสุ่มตัวอย่างและบันทึกนี้ (บันทึกถูกนำไปใช้กับช่วงใด ๆ ที่อาจเข้ามาเป็นส่วนหนึ่งของการติดตามหลังจากการตัดสินใจได้รับการทำ) หลังจากทำการตัดสินใจสุ่มตัวอย่างหากการติดตามจะถูกเก็บไว้มันจะถูกส่งผ่านไปยัง transmission เพื่อส่งจริง
transmit/transmit.go เป็น wrapper รอบการโต้ตอบ HTTP กับ Honeycomb API มันจัดการกับเหตุการณ์แบทช์ด้วยกันและส่งพวกเขาต้นน้ำ
logger และ metrics มีไว้สำหรับการจัดการบันทึกและตัวชี้วัดที่โรงกลั่นเองผลิต
sampler มีอัลกอริทึมเพื่อคำนวณอัตราตัวอย่างตามร่องรอยที่ให้ไว้
sharder กำหนดว่าเพียร์ใดในการกำหนดค่าโรงกลั่นแบบคลัสเตอร์ควรจัดการกับการติดตามแต่ละครั้ง
types มีคำจำกัดความบางประเภทที่ใช้ในการส่งข้อมูลระหว่างแพ็คเกจ
