مسیر فایل: scripts/network/analyze_pcaps.sh
۱. کاراییش به زبان ساده
هر فایل capture داخل inbox را یکی‌یکی از طریق زیرسیستم Network Analyzer (python -m network_analyzer.main) رد می‌کند، سپس بر اساس کد خروج Analyzer فایل را جابه‌جا می‌کند: موفق → processed/؛ ورودی ردشده → failed/ (+ فایل .log)؛ خطای قابل‌تلاش مجدد (مثل قطع بودن Kafka) → همان‌جا در inbox می‌ماند تا اجرای بعدی دوباره برداردش. همین مسیریابی، قلب ارزش اسکریپت است.
۲. کجا در پروژه کلی استفاده می‌شود؟
- مسیر host-side برای batch روی
data/pcap/inboxوقتی اپراتور captureهای PCAPdroid را می‌ریزد داخل فولدر. - معادل مفهومی سرویس Compose
network-analyzer(پروفایلtools) که همان کار را داخل کانتینر انجام می‌دهد؛docker-compose.ymlصریحاً به این اسکریپت ارجاع می‌دهد. - پس از اجرا، معمولاً با
verify_network_metrics.shتأیید می‌شود که پیام‌ها روی تاپیک نشسته‌اند، و در نهایت Storage Consumer آن‌ها را به DB می‌برد. - به App Registry وابسته است مگر
--skip-registry-check/--dry-run: نام بسته باید در فهرست اپ‌های تحت پایش باشد.
۳. چیکارا می‌کند؟
قرارداد نام فایل (اجباری برای تشخیص خودکار app و سناریو):
<package>__<upload|download>__<YYYYMMDDTHHMMSS>.pcap
مثال: com.whatsapp__upload__20260907T141500.pcap
مسیریابی بر اساس exit code Analyzer:
| نتیجه | رفتار فایل | معنا |
|---|---|---|
موفق (0) | انتقال به processed/ | متریک‌ها محاسبه و (معمولاً) به Kafka منتشر شدند. |
خطای transport / قابل retry (مثلاً 5) | ماندن در inbox | بروکر یا وابستگی موقتاً در دسترس نیست؛ capture خوب است، quarantine نشود. |
| ورودی ردشده | انتقال به failed/ + .log | فایل خراب/نامعتبر؛ نباید forever retry شود. |
در پایان یک خلاصهٔ شمارش (analyzed / failed / retryable) چاپ می‌شود. Exit 0 فقط وقتی همه OK یا inbox خالی باشد؛ در غیر این صورت 1.
۴. تصمیمات معماری
- عمداً بدون
set -e: شکست یک فایل نباید کل batch را بکشد؛ مثلcheck_infraباید گزارش کامل بدهد. - تفکیک «خطای زیرساخت» از «خطای ورودی»: بروکر قطع ≠ capture بد. بدون این تفکیک، یا فایل خوب quarantine می‌شود یا فایل بد تا ابد inbox را اشغال می‌کند.
- متاداده در نام فایل: بدون آرگومان per-file، Analyzer می‌فهمد package و upload/download چیست — قرارداد عملیاتی با PCAPdroid.
--dry-run+--skip-registry-check+--keep: مسیر دیباگ بدون دست زدن به Kafka، Registry و جابه‌جایی فایل.- دو مسیر اجرا (host script vs Compose service): همان منطق؛ یکی برای توسعهٔ محلی با venv، یکی برای محیط Docker یکپارچه.
۵. دستورات
# اجرای عادی روی data/pcap/inbox
./scripts/network/analyze_pcaps.sh
# فقط محاسبه، بدون Kafka / بدون جابه‌جایی فایل
./scripts/network/analyze_pcaps.sh --dry-run --skip-registry-check --keep
# inbox سفارشی
./scripts/network/analyze_pcaps.sh --inbox ~/Downloads/PCAPdroid
./scripts/network/analyze_pcaps.sh --help
# معادل داخل Compose
docker compose --profile tools run --rm network-analyzer
پیش‌نیاز: وابستگی‌های پایتون Analyzer نصب باشد (network_analyzer/requirements.txt). برای publish واقعی: Kafka و App API در دسترس، مگر فلگ‌های dry-run / skip-registry.
← verify_network_metrics.sh · فهرست اسکریپت‌ها · finalize_cycle_reports.py →