WIUNIX ACADEMY
پرشدن صف OpenTelemetry Collector؛ تشخیص علت، محدودکردن حافظه و بررسی بازیابی
صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من6 مقدار قابل‌تغییر
قدم بعدی
پیکربندی پیشنهادی را در فایل جداگانه بنویسید
از پوشه و فایل تازه استفاده کنید. پنل بعد محتوای YAML است. سقف حافظه، batch و صف عمداً محدود و آموزشی‌اند؛ آن‌ها را با اندازه‌گیری و پایین‌تر از محدودیت واقعی فرایند یا کانتینر تعیین کنید. نوشتن این فایل هیچ سرویس موجودی را دوباره راه‌اندازی نمی‌کند.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
umask 077
mkdir '/tmp/academy-otel' && cd '/tmp/academy-otel' || exit 1
(set -C; : > candidate.yaml) || exit 1
${EDITOR:-vi} candidate.yamlفایل تازه برای بازبینی آماده باشد و پیکربندی فعال سرویس تغییری نکرده باشد.
قدم بعدی
ترتیب پردازش و مرزهای حافظه و ارسال را بازبینی کنید
memory_limiter ابتدا قرار دارد تا پیش از تخصیص بیشتر در پردازشگرهای بعدی، بتواند نیاز به کاهش ورودی را به فرستنده اعلام کند. batch دسته‌های محدود می‌سازد و صف exporter تعداد مصرف‌کننده و حداکثر زمان مجاز تلاش مجدد مشخص دارد. receiver فقط روی loopback گوش می‌دهد. گواهی مقصد باید برای دامنهٔ انتخاب‌شده معتبر باشد؛ گزینهٔ TLS ناامن یا اطلاعات احراز هویت در نمونه وجود ندارد.
محتوای فایل؛ در مسیر درج‌شده ذخیره کنید
receivers:
otlp:
protocols:
grpc:
endpoint: 127.0.0.1:14317
processors:
memory_limiter:
check_interval: 1s
limit_mib: 384
spike_limit_mib: 96
batch:
timeout: 1s
send_batch_size: 256
send_batch_max_size: 512
exporters:
otlp/backend:
endpoint: otel.example.com:4317
tls:
insecure: false
timeout: 5s
sending_queue:
enabled: true
sizer: requests
queue_size: 1000
num_consumers: 4
retry_on_failure:
enabled: true
initial_interval: 1s
max_interval: 10s
max_elapsed_time: 2m
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/backend]
یک ورودی محلی trace و یک خروجی TLS با صف و retry محدود تعریف شده باشند؛ دوام داده پس از توقف تضمین نشده است.
قدم بعدی
فایل را با همان باینری موجود اعتبارسنجی کنید
موفقیت validate فقط سازگاری مؤلفه‌ها و پیکربندی را بررسی می‌کند؛ سلامت مقصد، تحویل داده یا ظرفیت را ثابت نمی‌کند. اگر فیلدی پشتیبانی نشد، مستندات exporterhelper همان نسخه را بخوانید و فایل پیشنهادی را اصلاح کنید؛ محدودیت‌ها را کورکورانه حذف نکنید. پیش از تمرین مجاز، اشغال‌نبودن پورت آزمایش را بررسی کنید. نمونه را کنار فرایندی که همان پورت را گرفته اجرا نکنید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
'/usr/local/bin/otelcol-contrib' validate --config='/tmp/academy-otel/candidate.yaml'
ss -lntp '( sport = :14317 or sport = :8888 )'
timeout 15s openssl s_client -connect 'otel.example.com:4317' -servername 'otel.example.com' -verify_hostname 'otel.example.com' -verify_return_error </dev/nullاعتبارسنجی پیکربندی موفق باشد؛ مالکیت پورت‌ها و اعتماد TLS پیش از هر تغییر اجرایی روشن شده باشند.
شکستِ قابل تکرار را از دادهٔ ردشده جدا کنید
افزایش send_failed ممکن است خطای چند تلاش ارسال برای همان داده‌ها را هم شامل شود؛ این عدد شمار مستقیم spanهای ازدست‌رفته نیست. enqueue_failed به رد داده پیش از ورود به صف exporter اشاره دارد. رد ورودی در receiver یا memory_limiter باید به فرستنده‌ای برسد که بتواند بین ارسال‌ها فاصله بیندازد و فشار ورودی را کم کند؛ رفتار retry و صف محدود خود SDK نیز مهم است.
خطای احراز هویت یا دادهٔ نامعتبر ممکن است دائمی باشد. دیسک پر مقصد با بزرگ‌کردن بی‌پایان صف بالادست درمان نمی‌شود. هم‌زمانی را فقط وقتی افزایش دهید که مقصد توان پذیرش دارد؛ وگرنه تکرار درخواست حادثه را تشدید می‌کند. کد وضعیت، مدت تلاش و تغییر نرخ‌ها را با مسئول مقصد بررسی کنید.
بازیابی را با شناسه‌های ساختگیِ معلوم بسنجید
در مسیر آزمایشی مستقل و مجاز، تعداد کمی trace با شناسهٔ مشخص از مولد موجود بفرستید. فقط مقصد همین آزمایش را از کنترل مدیریتی خودش قطع و دوباره وصل کنید. تغییر شمارنده‌های پذیرش، رد، ورود به صف و ارسال را ثبت و همان شناسه‌ها را در مقصد جست‌وجو کنید. قطعی کوتاه و بلندتر از حداکثر زمان مجاز تلاش مجددِ درخواست فعال را مقایسه کنید، اما اتلاف واقعی را مشاهده کنید؛ همهٔ داده‌های منتظر الزاماً در یک لحظه منقضی نمی‌شوند. برای تولید شواهد، exporter مشترک محیط عملیاتی را مختل نکنید.
صف ماندگار را طرحی جدا با پذیرش مستقل بدانید
file_storage می‌تواند دادهٔ صف را در بعضی توقف‌ها حفظ کند، اما به افزونهٔ contrib سازگار با نسخه، فضای ذخیره‌سازی پایدار و قابل نوشتن، ظرفیت، مجوز و برنامهٔ بازیابی نیاز دارد. رفتار توقف، شروع دوباره و قطعی را روی همان ساخت بررسی کنید. این صف کارگزار پیام با تضمین exactly-once نیست. گزارش بالادستی شمارهٔ۱۵۶۷۷ دربارهٔ اتلاف در خاموش‌شدن نسخه‌های۰٫۱۵۷ است؛ دلیل بررسی نسخهٔ شماست، نه اثبات وجود خطا در همهٔ نسخه‌ها. برای سالم نشان‌دادن صف، WAL یا PVC را حذف نکنید.