WIUNIX ACADEMY
پرشدن صف OpenTelemetry Collector؛ تشخیص علت، محدودکردن حافظه و بررسی بازیابی
نرخ ورود، پرشدن صف و خطای ارسال را کنار هم بسنجید؛ یک مسیر آزمایشی محدود بسازید و تحویل واقعی داده را پس از قطعی بررسی کنید.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من6 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
تفاوت پذیرش داده، ورود به صف، تلاش ارسال و دیده‌شدن در مقصد را تشخیص دهید و برای یک مسیر آزمایشی مستقل، حافظه و تلاش دوباره را با اندازه‌گیری محدود کنید.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست.
قبل از شروع
- باینری موجود و مورد تأیید otelcol-contrib؛ مستندات باید با نسخه و مؤلفه‌های همان باینری تطبیق داده شوند.
- دسترسی غیرریشه به میزبان Collector، متریک داخلی محافظت‌شده و مقصد مجاز OTLP/gRPC با TLS معتبر.
- یک مسیر آزمایشی مستقل و مولد موجود برای traceهای ساختگیِ دارای شناسهٔ معلوم؛ اختلال در صادرکنندهٔ مشترک مجاز نیست.
قدم بعدی
ابزار میزبان انتخاب‌شده را آماده کنید
ابزارهای لازم را روی کامپیوتر یا سروری آماده کنید که فرمان‌های مدیریتی را از آن اجرا می‌کنید. پیش از تأیید، فهرست تغییر بسته‌ها را بخوانید؛ داخل کانتینر برنامه ابزار نصب نکنید. کلاستر، سرویس و باینری‌های اصلی باید از قبل با نسخهٔ مورد تأیید موجود باشند. پنل‌های بعد را در Bash اجرا کنید. نصب بسته روی همین میزبان تغییر ایجاد می‌کند، اما سرور برنامهٔ تازه‌ای راه نمی‌اندازد.
مؤلفه‌ها و فیلد sizer صف در نسخه‌ها و توزیع‌های Collector متفاوت‌اند. باینری موجود باید مؤلفه‌های نمونه را داشته باشد و فایل را با validate خود بپذیرد. انتخاب سیستم‌عامل نسخهٔ Collector را انتخاب یا ارتقا نمی‌دهد.
میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان
sudo apt-get update
sudo apt-get install --no-install-recommends ca-certificates curl bash coreutils openssl iproute2
cat /etc/os-release
command -v bash curl timeout
'/usr/local/bin/otelcol-contrib' --version
'/usr/local/bin/otelcol-contrib' components
openssl version
ss --versionنسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.
حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید
در Ubuntu و Debian ممکن است AppArmor و قواعد دیوارهٔ آتش میزبان فعال باشند. این روند پورت ورودی باز نمی‌کند و پروفایل امنیتی را تغییر نمی‌دهد. اگر دسترسی فایل یا شبکه رد شد، لاگ و سیاست سرویس را با مسئول آن بررسی کنید. مسیر نصب واقعی را حفظ کنید؛ مسیرهای نمونهٔ فرم، کشف خودکار محل نصب نیستند.
پذیرش داده را با تحویل نهایی یکی نگیرید
Collector داده را از receiver می‌گیرد، پردازش می‌کند و به exporter می‌سپارد. ورود به صف، موفقیت یک تلاش ارسال و قابل جست‌وجوشدن در مقصد سه رویداد متفاوت‌اند. retry داده‌ای را که پیش از ورود به صف رد شده بازیابی نمی‌کند؛ صف حافظه‌ای هم از راه‌اندازی دوباره جان سالم به در نمی‌برد. در بعضی خطاهای دائمی، ارسال دوباره انجام نمی‌شود.
نمونهٔ این راهنما فقط یک پیکربندی پیشنهادی برای trace و باینری موجود otelcol-contrib است؛ آن را جایگزین مستقیم تنظیمات محیط عملیاتی نکنید. ورودی gRPC فقط محلی است و خروجی به مقصد TLS تأییدشده می‌رود. هنگام ادغام، احراز هویت، پالایش اطلاعات خصوصی و مسیرهای دیگر داده را با مسئول سرویس حفظ کنید.
قدم بعدی
نسخه و مؤلفه‌های باینری موجود را ثبت کنید
با حساب غیرریشه روی میزبان Collector کار کنید. نسخه و مؤلفه‌های نصب‌شده را بخوانید؛ توزیع core، contrib، نسخهٔ فروشنده و ساخت سفارشی یکسان نیستند. مستندات را با همین نسخه تطبیق دهید و مسیر سرویس و تنظیمات فعلی را خصوصی بررسی کنید. برای سازگارکردن یک مثال، Collector در حال کار را ارتقا ندهید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
'/usr/local/bin/otelcol-contrib' --version
'/usr/local/bin/otelcol-contrib' components
'/usr/local/bin/otelcol-contrib' validate --helpنسخه، توزیع و مؤلفه‌های مورد نیاز روشن باشند و مسیر باینری به نصب واقعی اشاره کند.
قدم بعدی
نرخ خطا و اندازهٔ صف را در یک بازه بخوانید
از نشانی محافظت‌شدهٔ متریک داخلی استفاده کنید. نمونه فرض می‌کند یک reader از نوع Prometheus از قبل روی loopback و پورت انتخاب‌شده وجود دارد؛ آن را فعال نمی‌کند. نام متریک، واحد و پسوند _total به نسخه و reader بستگی دارد. خروجی واقعی را بخوانید، نه برچسب یک داشبورد کپی‌شده را. درخواست محدود است؛ ویژگی‌های منابع و نام مقصدها را محرمانه نگه دارید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
set -o pipefail
curl --noproxy '*' --fail --silent --show-error --max-time 5 'http://127.0.0.1:8888/metrics' | grep -E '^otelcol_(receiver_(accepted|refused)|exporter_(queue|enqueue_failed|send_failed|sent)|processor_refused|process_memory)'پذیرش و رد ورودی، اندازه و ظرفیت صف، شکست ورود به صف، خطای ارسال و حافظه در بازهٔ زمانی یکسان ثبت شده باشند.
پیش از بزرگ‌کردن صف، زمان قابل تحمل قطعی را حساب کنید
واحد queue_size را از sizer بخوانید. در حالت requests عدد ۱۰۰۰ به درخواست یا دسته اشاره دارد، نه تعداد span یا بایت. اندازهٔ batch نیز سقف کل حافظه نیست. رشد صف را از اختلاف نرخ ورودی و نرخ پایدار خروجی تخمین بزنید؛ ظرفیت لازم برای قطعی، این اختلاف مثبت ضرب‌در مدت قطعی است، به‌علاوهٔ حاشیهٔ جهش‌های اندازه‌گیری‌شده.
حافظهٔ واقعی هر درخواست را روی داده‌هایی شبیه دادهٔ واقعی سامانه بسنجید و بافر receiver، پردازشگر batch و سربار اجرا را هم حساب کنید. صف ۲۰۰۰درخواستی با ورود ۲۰درخواست در ثانیه و خروج صفر، از نظر حساب ساده حدود۱۰۰ثانیه ظرفیت دارد؛ این عدد فقط حاصل محاسبه است؛ ظرفیت واقعی را باید اندازه بگیرید. تلاش نامحدود می‌تواند مشکل شبکه را به پرشدن حافظه یا دیسک تبدیل کند.
max_elapsed_time مدت تلاش دوباره برای درخواستِ در حال ارسال را محدود می‌کند؛ مهلت نگهداری هر داده از لحظهٔ ورود به صف نیست. مدت انتظار در صف را از مدت retry فعال جدا ببینید.