ردیابی توزیع شده

ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

فعل و انفعالات از فرانت اند به باطن. با ردیابی، Sentry عملکرد نرم‌افزار شما را ردیابی می‌کند، معیارهایی مانند توان عملیاتی و تأخیر را اندازه‌گیری می‌کند و تأثیر خطاها را در چندین سیستم نشان می‌دهد. ردیابی، Sentry را به یک راه‌حل نظارت کامل‌تر تبدیل می‌کند و به شما کمک می‌کند مشکلات را تشخیص دهید و سلامت کلی برنامه‌تان را سریع‌تر اندازه‌گیری کنید. Tracing در Sentry بینش هایی از قبیل:

• آنچه برای یک رویداد یا مشکل خطای خاص رخ داده است
• شرایطی که باعث ایجاد گلوگاه یا مشکلات تاخیر در برنامه شما می شود
• نقاط پایانی یا عملیاتی که بیشترین زمان را مصرف می کنند

ردیابی چیست؟

برای شروع، یک یادداشت در مورد چیست

ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

نیست: ردیابی پروفایل نیست. اگرچه اهداف نمایه سازی و ردیابی تا حدودی با هم همپوشانی دارند، و اگرچه می توان از هر دوی آنها برای تشخیص مشکلات در برنامه شما استفاده کرد، اما از نظر اندازه گیری و نحوه ثبت داده ها متفاوت هستند.

ممکن است هر تعدادی از جنبه‌های عملکرد یک برنامه کاربردی را اندازه‌گیری کند: تعداد دستورالعمل‌های اجرا شده، مقدار حافظه‌ای که توسط فرآیندهای مختلف استفاده می‌شود، مدت زمانی که یک فراخوانی تابع معین طول می‌کشد، و بسیاری موارد دیگر. نمایه به دست آمده یک خلاصه آماری از این اندازه گیری ها است.

از سوی دیگر، به جای اینکه چند بار اتفاق افتاده یا چقدر طول کشیده است، بر آنچه اتفاق افتاده (و چه زمانی) تمرکز می کند. ردیابی به دست آمده گزارشی از رویدادهایی است که در طول اجرای یک برنامه، اغلب در چندین سیستم رخ داده است. اگرچه ردیابی اغلب - یا در مورد ردیابی های Sentry، همیشه - شامل مهرهای زمانی است که امکان محاسبه مدت زمان را فراهم می کند، اندازه گیری عملکرد تنها هدف آنها نیست. آنها همچنین می توانند راه هایی را نشان دهند که در آن سیستم های به هم پیوسته با هم تعامل دارند، و راه هایی که در آن مشکلات در یکی می تواند باعث ایجاد مشکل در دیگری شود.

برنامه ها معمولاً از اجزای به هم پیوسته تشکیل شده اند که به آنها خدمات نیز می گویند. به عنوان مثال، اجازه دهید به یک برنامه وب مدرن، متشکل از اجزای زیر، که با مرزهای شبکه از هم جدا شده اند، نگاه کنیم:

• Frontend (برنامه تک صفحه ای)
• Backend (REST API)
• صف وظایف
• سرور پایگاه داده
• Cron Job Scheduler

هر یک از این مؤلفه ها ممکن است به زبانی متفاوت در پلتفرم متفاوتی نوشته شوند. هر کدام را می توان به صورت جداگانه با استفاده از Sentry SDK برای گرفتن داده های خطا یا گزارش های خرابی ابزارسازی کرد، اما این ابزار دقیق تصویر کاملی را ارائه نمی دهد، زیرا هر قطعه به طور جداگانه در نظر گرفته می شود. ردیابی به شما این امکان را می دهد که همه داده ها را با هم گره بزنید.

در برنامه وب مثال ما،

ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

به این معنی است که می‌توانید درخواستی را از فرانت‌اند به بخش پشتیبان و پشتیبان دنبال کنید، داده‌ها را از هر کار پس‌زمینه یا کار اعلان‌هایی که درخواست ایجاد می‌کند، وارد کنید. این نه تنها به شما این امکان را می‌دهد که گزارش‌های خطای Sentry را به هم مرتبط کنید، تا ببینید چگونه یک خطا در یک سرویس ممکن است به سرویس دیگر منتشر شده باشد، بلکه به شما این امکان را می‌دهد که بینش قوی‌تری در مورد اینکه کدام سرویس‌ها ممکن است بر عملکرد کلی برنامه شما تأثیر منفی داشته باشند، به دست آورید.

قبل از یادگیری نحوه فعال کردن ردیابی در برنامه خود، به درک چند اصطلاح کلیدی و نحوه ارتباط آنها با یکدیگر کمک می کند.

ردیابی ها، تراکنش ها و دهانه ها

اثری نشان دهنده رکورد کل عملیاتی است که می خواهید اندازه گیری یا ردیابی کنید - مانند بار صفحه ، نمونه ای از کاربر که برخی از اقدامات را در برنامه شما انجام می دهد یا یک کار Cron در باطن شما است. هنگامی که اثری شامل کار در چندین سرویس ، مانند موارد ذکر شده در بالا است ، آن را ردیابی توزیع شده می نامند ، زیرا ردیابی در آن سرویس ها توزیع می شود.

هر اثری از یک یا چند ساختار شبیه درخت به نام معاملات تشکیل شده است که گره هایی از آنها به آن دهانه گفته می شود. در بیشتر موارد ، هر معامله نشان دهنده یک نمونه واحد از یک سرویس است که در آن خوانده می شود ، و هر دهانه در آن معامله نشان دهنده این سرویس است که یک واحد کار را انجام می دهد ، خواه یک عملکرد را در آن سرویس فراخوانی کند یا با یک سرویس متفاوت تماس بگیرد. در اینجا یک اثری از مثال ، تقسیم شده به معاملات و دهانه ها وجود دارد:

از آنجا که یک معامله دارای ساختار درختی است ، دهانه های سطح بالا می توانند خود را به دهانه های کوچکتر تقسیم کنند ، و این روش را نشان می دهد که یک عملکرد ممکن است تعدادی از کارکردهای کوچکتر را فراخوانی کند. این با استفاده از استعاره والدین و فرزند بیان می شود ، به طوری که هر طول ممکن است دهانه والدین به چندین دهانه کودک دیگر باشد. علاوه بر این ، از آنجا که همه درختان باید یک ریشه واحد داشته باشند ، یک دوره در هر معامله همیشه خود معامله را نشان می دهد ، با تمام دهانه های دیگر در معامله که از آن دوره ریشه پایین می آید. در اینجا نمای بزرگنمایی یکی از معاملات از نمودار بالا آورده شده است:

برای اینکه همه این موارد بتونی تر شود ، اجازه دهید دوباره برنامه وب مثال ما را در نظر بگیریم.

مثال: بررسی بار صفحه آهسته

فرض کنید برنامه وب شما برای بارگیری کند است ، و می خواهید بدانید که چرا. برای رسیدن به یک وضعیت قابل استفاده ، برنامه شما اتفاق زیادی می افتد: درخواست های متعدد به پس زمینه شما ، به احتمال زیاد برخی از کارها - از جمله تماس به پایگاه داده شما یا API های خارج - قبل از بازگشت پاسخ ها ، و پردازش توسط مرورگر برای ارائه همهاز داده های برگشتی به چیزی معنی دار برای کاربر. بنابراین کدام قسمت از این روند در حال کند شدن کارها است؟

بیایید بگوییم ، در این مثال ساده ، وقتی کاربر برنامه را در مرورگر خود بارگیری می کند ، موارد زیر در هر سرویس اتفاق می افتد:

• مرورگر
  • 1 هر یک را برای HTML ، CSS و JavaScript درخواست کنید
  • 1 کار ارائه ، که 2 درخواست برای داده های JSON را تنظیم می کند ^
  • 3 درخواست برای ارائه پرونده های استاتیک (HTML ، CSS و JS)
  • 2 درخواست برای داده های JSON - 1 نیاز به تماس با پایگاه داده - 1 که نیاز به تماس با API خارجی دارد و برای پردازش نتایج قبل از بازگشت آنها به جبهه ^ کار می کند.
  • 1 درخواست که به 2 نمایش داده می شود
    • 1 پرس و جو برای بررسی احراز هویت
    • 1 پرس و جو برای دریافت داده

    توجه: API خارجی دقیقاً به دلیل خارجی ذکر نشده است ، و بنابراین شما نمی توانید در داخل آن ببینید.

    در این مثال ، کل فرآیند بارگیری صفحه ، از جمله تمام موارد فوق ، توسط یک ردیابی واحد نشان داده شده است. این ردیابی شامل معاملات زیر است:

    • 1 معامله مرورگر (برای بار صفحه)
    • 5 معاملات باطن (یکی برای هر درخواست)
    • 1 معامله سرور پایگاه داده (برای درخواست DB تنها)

    هر معامله به شرح زیر تقسیم می شود:

    • معامله بارگذاری صفحه مرورگر: 7 دهانه
      • 1 دهانه ریشه که کل بار صفحه را نشان می دهد
      • 1 دهانه هر (3 کل) برای درخواست های HTML ، CSS و JS
      • 1 دهانه برای کار رندر ، که خود شامل آن است
        • 2 دهانه کودک ، یکی برای هر درخواست JSON

        بیایید در اینجا مکث کنیم تا به یک نکته مهم اشاره کنیم: برخی، هرچند نه همه، از گستره های فهرست شده در اینجا در تراکنش مرورگر، مطابقت مستقیمی با تراکنش های پشتیبان ذکر شده در قبل دارند. به طور خاص، هر دامنه درخواست در تراکنش مرورگر با یک تراکنش درخواست جداگانه در باطن مطابقت دارد. در این شرایط، زمانی که یک span در یک سرویس منجر به تراکنش در یک سرویس بعدی می شود، ما span اصلی را یک span والد هم برای تراکنش و هم برای root span می نامیم. در نمودار زیر، خطوط خمیده این رابطه والد-فرزند را نشان می دهد.

        

        در مثال ما، هر تراکنش غیر از تراکنش بارگذاری صفحه اولیه مرورگر، فرزند یک span در سرویس دیگری است، به این معنی که هر دهانه ریشه به غیر از ریشه تراکنش مرورگر، یک اسپان والد دارد (البته در یک سرویس متفاوت).

        در یک سیستم کاملاً ابزار دقیق (سیستمی که هر سرویس در آن وجود دارد

        ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

        فعال) این الگو همیشه درست است. تنها بازه بدون والدین، ریشه تراکنش اولیه خواهد بود. هر بازه دیگر یک والد خواهد داشت. علاوه بر این، والدین و فرزندان همیشه در یک سرویس زندگی خواهند کرد، به جز در مواردی که span فرزند ریشه تراکنش فرزند باشد، در این صورت، دامنه والد در سرویس تماس برقرار خواهد شد و تراکنش فرزند/طول ریشه فرزند خواهد بود. در سرویس نامیده شده زندگی کنید.

        به عبارت دیگر، یک سیستم کاملاً ابزاری یک ردیابی ایجاد می کند که خود یک درخت متصل است - با هر تراکنش یک زیردرخت - و در آن درخت، مرزهای بین زیردرختان/تراکنش ها دقیقاً مرزهای بین خدمات هستند. نمودار بالا یک شاخه از درخت ردیابی کامل مثال ما را نشان می دهد.

        اکنون، برای کامل بودن، به گستره های خود بازگردیم:

        • درخواست تراکنش‌های HTML/CSS/JS: هر کدام 1 بازه
          • 1 ریشه ریشه که کل درخواست را نشان می دهد (فرزند یک گستره مرورگر) ^
          • 1 دهانه ریشه که کل درخواست را نشان می دهد (فرزند یک گستره مرورگر)
          • 1 بازه برای پرس و جو از پایگاه داده (والد تراکنش سرور پایگاه داده) ^
          • 1 دهانه ریشه که کل درخواست را نشان می دهد (فرزند یک گستره مرورگر)
          • 1 بازه برای درخواست API (برخلاف تماس DB، نه یک دامنه والد، زیرا API خارجی است)
          • 1 بازه برای پردازش داده های API ^
          • 1 دهانه ریشه که کل درخواست را نشان می دهد (فرزند دامنه باطن بالا)
          • 1 فاصله برای پرس و جو احراز هویت
          • 1 فاصله برای بازیابی داده های پرس و جو

          برای جمع‌بندی مثال: پس از ابزار دقیق همه سرویس‌های خود، ممکن است متوجه شوید که - به دلایلی - این پرس و جوی تأیید اعتبار در سرور پایگاه داده شما است که کار را کند می‌کند و بیش از نیمی از زمانی را که کل صفحه شما طول می‌کشد، تشکیل می‌دهد. فرآیند بارگیری برای تکمیلردیابی نمی تواند به شما بگوید که چرا این اتفاق می افتد، اما حداقل اکنون می دانید کجا باید نگاه کنید!

          این بخش شامل چند نمونه دیگر از

          ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

          اندازه گیری یک اقدام کاربر خاص

          اگر درخواست شما شامل تجارت الکترونیکی است، احتمالاً می خواهید زمان بین کلیک کاربر روی «ارسال سفارش» و نمایش تأیید سفارش، از جمله پیگیری ارسال هزینه به پردازشگر پرداخت و ارسال ایمیل تأیید سفارش را اندازه گیری کنید. کل این فرآیند یک ردیابی است و معمولاً تراکنش (T) و دهانه (S) برای:

          • فرآیند کامل مرورگر (T و ریشه S)
            • درخواست XHR برای باطن * ( S )
            • در حال نمایش صفحه تایید ( S ) ^
            • فراخوانی تابع برای محاسبه کل (ها)
            • تماس DB برای ذخیره سفارش * (ها)
            • تماس API به پردازنده پرداخت (ها)
            • صف تأیید ایمیل * (ها) ^
            • پرس و جوهای SQL انفرادی (ها) ^
            • تماس عملکرد برای جمع آوری الگوی ایمیل (ها)
            • تماس API به سرویس (های) ارسال کننده ایمیل

            توجه: دهانه های ستاره دار نمایانگر دهانه هایی هستند که والدین یک معامله بعدی (و طول ریشه آن) هستند.

            نظارت بر یک فرایند پس زمینه

            اگر پس زمینه شما به طور دوره ای برای داده های یک سرویس خارجی نظرسنجی می کند ، آن را پردازش می کند ، آن را ذخیره می کند ، و سپس آن را به یک سرویس داخلی منتقل می کند ، هر نمونه از این اتفاق یک اثری است ، و شما به طور معمول معاملات (t) و دهانه ها را دارید (s)) برای:

            • کار Cron که کل فرآیند را تکمیل می کند (T و Root Span)
              • تماس API به سرویس (های) خارجی
              • تابع پردازش (ها)
              • تماس با سرویس ذخیره * (ها)
              • تماس API به سرویس داخلی * (ها) ^
              • بررسی حافظه پنهان برای داده های موجود (های)
              • ذخیره داده های جدید در حافظه نهان (ها) ^
              • هر کاری که ممکن است برای رسیدگی به درخواست (ها) انجام دهد

              توجه: دهانه های ستاره دار نمایانگر دهانه هایی هستند که والدین یک معامله بعدی (و طول ریشه آن) هستند.

              ردیابی مدل داده

              "نمودار خود را به من نشان دهید و جداول خود را پنهان کنید ، و من همچنان عرفانی خواهم شد. جداول خود را به من نشان دهید ، و من معمولاً به نمودار شما احتیاج نخواهم داد ؛ آشکار خواهد بود."

              - فرد بروکس ، ماه اسطوره ای (1975)

              در حالی که این تئوری جالب است ، در نهایت هر ساختار داده با نوع داده های موجود در آن تعریف می شود و روابط بین ساختار داده ها با نحوه ثبت پیوندها بین آنها تعریف می شود. ردیابی ، معاملات و دهانه ها فرقی نمی کنند.

              اثری از خود موجودی نیست. در عوض ، اثری به عنوان مجموعه کلیه معاملات که دارای یک مقدار trace_id هستند تعریف می شود.

              معاملات بیشتر خصوصیات خود را (زمان شروع و پایان ، برچسب ها و موارد دیگر) با دهانه ریشه خود به اشتراک می گذارند ، بنابراین همان گزینه های شرح داده شده در زیر برای دهانه ها در معاملات موجود است و تنظیم آنها در هر مکان معادل است.

              معاملات همچنین دارای یک ویژگی اضافی در دهانه ها به نام Transaction_Name است که در UI برای شناسایی معامله استفاده می شود. نمونه های متداول از مقادیر Transaction_Name شامل مسیرهای نقطه پایانی (مانند/فروشگاه/پرداخت/یا API/V2/کاربران //) برای معاملات درخواست باطن ، نام کار (مانند Data. leanup. delete_inactive_users) برای معاملات کار Cron و URL ها (مانند https://docs. sentry. io/performance-monitoring/distributed-tracing/) برای معاملات بارگذاری صفحه.

              نام معاملات به طور بالقوه می تواند حاوی داده های حساس باشد. برای اطلاعات بیشتر به Scrubbing Data حساس مراجعه کنید.

              توجه: قبل از ارسال معامله ، برچسب ها و خصوصیات داده با داده های دامنه جهانی ادغام می شوند..

              اکثر داده های موجود در یک معامله در فردی است که شامل معامله است. داده های دهانه شامل:

              • parent_span_id: دهانه را به طول والدین خود پیوند می دهد
              • OP: رشته کوتاه شناسایی نوع یا دسته عملیاتی که دهانه اندازه گیری می شود. جزئیات مربوط به ساختار عملیات دهانه را می توان در مستندات توسعه دهنده Sentry یافت

              چند نکته مهم دیگر در مورد آثار ، معاملات و دهانه ها و نحوه ارتباط آنها با یکدیگر:

              از آنجایی که trace just مجموعه ای از تراکنش ها است، ردیابی ها زمان شروع و پایان خاص خود را ندارند. در عوض، یک ردیابی با شروع اولین تراکنش شروع می شود و زمانی که آخرین تراکنش به پایان می رسد پایان می یابد. در نتیجه، نمی‌توانید مستقیماً یک ردیابی را شروع یا پایان دهید. در عوض، با ایجاد اولین تراکنش در آن ردیابی، یک ردیابی ایجاد می‌کنید و با تکمیل تمام تراکنش‌های موجود در آن، یک ردیابی را تکمیل می‌کنید.

              به دلیل امکان فرآیندهای ناهمزمان، تراکنش‌های فرزند ممکن است بیشتر از تراکنش‌هایی که شامل گستره‌های والد خود هستند، گاهاً به مراتب بزرگتر باشند. به عنوان مثال، اگر یک فراخوانی API باطن، یک کار پردازشی طولانی‌مدت را تنظیم کند و سپس بلافاصله پاسخی را برگرداند، تراکنش باطن پایان می‌یابد (و داده‌های آن به Sentry ارسال می‌شود) خیلی قبل از انجام تراکنش وظیفه async. ناهمزمانی همچنین به این معنی است که ترتیب ارسال (و دریافت توسط) تراکنش ها به هیچ وجه به ترتیب ایجاد آنها بستگی ندارد.(در مقابل، ترتیب دریافت تراکنش‌ها در همان ردیابی با ترتیب تکمیل همبستگی دارد، اگرچه به دلیل عواملی مانند تغییرپذیری زمان‌های ارسال، این همبستگی بسیار کامل نیست.)

              در تئوری، در یک سیستم کاملاً ابزار، هر ردیابی باید فقط شامل یک تراکنش و یک دهانه (ریشه تراکنش) بدون والد، یعنی تراکنش در سرویس مبدأ باشد. با این حال، در عمل، ممکن است نداشته باشید

              ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

              در هر یک از سرویس های شما فعال باشد، یا یک سرویس ابزاردار ممکن است به دلیل اختلال در شبکه یا سایر شرایط پیش بینی نشده تراکنش را گزارش ندهد. هنگامی که این اتفاق می افتد، ممکن است شکاف هایی در سلسله مراتب ردیابی خود مشاهده کنید. به طور خاص، ممکن است تراکنش‌هایی را در طول ردیابی مشاهده کنید که گستره‌های اصلی آن‌ها به عنوان بخشی از هیچ تراکنش شناخته‌شده‌ای ثبت نشده است. این گونه معاملات بدون مبدأ و بدون والدین را معاملات یتیم می نامند.

              اگرچه مثال‌های ما در بالا چهار سطح در سلسله‌مراتب خود داشتند (ردیابی، تراکنش، بازه، گستره فرزند)، هیچ محدودیت مشخصی برای عمق تودرتوی دهانه‌ها وجود ندارد. با این حال، محدودیت‌های عملی وجود دارد: محموله‌های تراکنش ارسال شده به Sentry دارای حداکثر اندازه مجاز هستند، و مانند هر نوع گزارش، تعادلی بین جزئیات داده‌های شما و قابلیت استفاده آن وجود دارد.

              ممکن است یک بازه زمان شروع و پایان یکسانی داشته باشد، و بنابراین به‌عنوان بدون زمان ثبت شود. این ممکن است به این دلیل رخ دهد که از دامنه به عنوان نشانگر استفاده می شود (مانند کاری که در API عملکرد مرورگر انجام می شود

              ) یا به این دلیل که مدت زمان انجام عملیات کمتر از وضوح اندازه گیری است (که بسته به سرویس متفاوت خواهد بود).

              اگر تراکنش‌ها را از چندین ماشین جمع‌آوری می‌کنید، احتمالاً با انحراف ساعت مواجه می‌شوید، که در آن مهر زمانی در یک تراکنش با مهر زمانی در تراکنش دیگر مطابقت ندارد. برای مثال، اگر باطن شما یک تماس با پایگاه داده برقرار کند، تراکنش باطن به طور منطقی باید قبل از تراکنش پایگاه داده شروع شود. اما اگر زمان سیستم در هر دستگاه (آنهایی که به ترتیب میزبان باطن و پایگاه داده شما هستند) با یک استاندارد مشترک همگام‌سازی نشود، ممکن است اینطور نباشد. همچنین ممکن است که ترتیب درست باشد، اما دو بازه زمانی ثبت‌شده به‌گونه‌ای مطابقت نداشته باشند که دقیقاً اتفاقات واقعی را منعکس کند. برای کاهش این احتمال، توصیه می کنیم از پروتکل زمان شبکه (NTP) یا خدمات همگام سازی ساعت ارائه دهنده ابر خود استفاده کنید.

              نحوه ارسال داده ها

              دهانه های انفرادی به Sentry ارسال نمی شوند. در عوض ، کل معامله به عنوان یک واحد ارسال می شود. این بدان معناست که تا زمانی که معامله ای که متعلق به آنها تعلق دارد بسته و اعزام می شود ، هیچ داده دهانه ای توسط سرورهای Sentry ثبت نمی شود. Converse درست نیست ، با این حال - اگرچه دهانه ها بدون معامله ارسال نمی شوند ، اما معاملات هنوز معتبر هستند و حتی اگر تنها دهانه ای که در آن وجود داشته باشد ، ارسال می شود.

              وقتی نمونه گیری را در خود فعال می کنید

              ردیابی فرآیند ثبت وقایع رخ داده در طول یک درخواست، اغلب در چندین سرویس.

              تنظیم ، شما یک درصد از معاملات جمع آوری شده را برای ارسال به Sentry انتخاب می کنید. به عنوان مثال ، اگر یک نقطه پایانی داشتید که در هر دقیقه 1000 درخواست دریافت می کرد ، نرخ نمونه برداری 0. 25 منجر به تقریباً 250 معاملات (25 ٪) در هر دقیقه به Sentry ارسال می شود.(این تعداد تقریبی است زیرا هر درخواست یا به طور مستقل و شبه ، با احتمال 25 ٪ ردیابی می شود یا خیردر حدود 250 مورد اثری را جمع آوری کنید.) از آنجا که درصد نمونه برداری را می دانید ، می توانید حجم کل ترافیک خود را برون مرزی کنید.

              هنگام جمع آوری اثری ، توصیه می کنیم از داده های خود به دو دلیل نمونه برداری کنید. اول ، اگرچه گرفتن یک ردیابی واحد شامل حداقل سربار است ، گرفتن اثری برای هر بار بار صفحه یا هر درخواست API ، این امکان را دارد که مقدار نامطلوبی از سیستم شما را اضافه کند. دوم ، فعال کردن نمونه گیری به شما امکان می دهد تعداد رویدادهای ارسال شده به Sentry را بهتر مدیریت کنید ، بنابراین می توانید آن را متناسب با نیازهای سازمان خود تنظیم کنید.

              هنگام انتخاب نرخ نمونه برداری ، هدف این است که داده های زیادی را جمع آوری نکنید (با توجه به دلایل فوق) بلکه جمع آوری داده های کافی که شما قادر به نتیجه گیری معنی دار هستید. اگر مطمئن نیستید که چه نرخ انتخابی را انتخاب کنید ، توصیه می کنیم با ارزش کم شروع کنید و به تدریج آن را افزایش دهید زیرا در مورد الگوهای ترافیک و حجم خود اطلاعات بیشتری کسب می کنید ، تا زمانی که نرخی پیدا کرده اید که به شما امکان می دهد عملکرد و نگرانی های حجم را با داده ها متعادل کنیددقت.

              قوام در یک ردیابی

              برای اثری که شامل معاملات متعدد است ، Sentry از یک رویکرد "مبتنی بر سر" استفاده می کند: یک تصمیم نمونه برداری در سرویس مبدا اتخاذ می شود ، و سپس این تصمیم به کلیه خدمات بعدی منتقل می شود. برای دیدن این که چگونه این کار می کند ، بیایید به مثال WebApp در بالا برگردیم. دو کاربر ، A و B را در نظر بگیرید که هر دو برنامه شما را در مرورگرهای مربوطه بارگیری می کنند. هنگامی که یک برنامه را بارگیری می کند ، SDK Pseudorandomly "تصمیم می گیرد" برای جمع آوری اثری ، در حالی که وقتی B برنامه را بارگیری می کند ، SDK "تصمیم می گیرد". هنگامی که هر مرورگر درخواست های خود را در پس زمینه شما انجام می دهد ، در آن درخواست ها "بله ، لطفاً معاملات را جمع کنید" یا تصمیم "نه ، معاملات را این بار جمع نکنید" در هدرها را شامل می شود.

              هنگامی که پس زمینه شما درخواست های مرورگر A را پردازش می کند ، تصمیم "بله" را می بیند ، داده های معامله و دهانه را جمع می کند و آن را به Sentry می فرستد. علاوه بر این ، این شامل تصمیم "بله" در هر درخواستی است که به خدمات بعدی (مانند سرور پایگاه داده شما) می دهد ، که به طور مشابه داده ها را جمع می کنند ، آن را به Sentry ارسال می کنند و تصمیم را به هر خدمتی که با آنها تماس می گیرند منتقل می کنند. از طریق این فرآیند ، تمام معاملات مربوطه به اثری از A جمع آوری و به Sentry ارسال می شود.

              از طرف دیگر، هنگامی که باطن شما درخواست های مرورگر B را پردازش می کند، تصمیم "نه" را می بیند و در نتیجه تراکنش ها و داده ها را به Sentry جمع آوری و ارسال نمی کند. با این حال، همان کاری را که در مورد A انجام می‌دهد از نظر انتشار تصمیم برای سرویس‌های بعدی انجام می‌دهد و به آنها می‌گوید که داده‌ها را نیز جمع‌آوری یا ارسال نکنند. سپس آنها به نوبه خود به هر سرویسی که تماس می گیرند می گویند که داده ارسال نکند و به این ترتیب هیچ تراکنشی از ردیابی B جمع آوری نمی شود.

              به بیان ساده: در نتیجه این رویکرد مبتنی بر سر، که در آن تصمیم یک بار در سرویس مبدأ گرفته می‌شود و به همه سرویس‌های بعدی منتقل می‌شود، یا تمام تراکنش‌ها برای یک ردیابی معین جمع‌آوری می‌شوند یا هیچ کدام جمع‌آوری نمی‌شوند، بنابراین نباید وجود داشته باشد. هیچ اثری ناقص نباشد.

              مشاهده داده های ردیابی

              از طریق Performance و Discover، می‌توانید داده‌های ردیابی را در جزئیات رویداد مشاهده کنید.

              به بهبود این محتوا کمک کنید اسناد ما منبع باز است و در GitHub موجود است. از مشارکت‌های شما استقبال می‌شود، چه تصحیح یک اشتباه تایپی (درات!) تا پیشنهاد به‌روزرسانی ("بله، این بهتر است").