Log routing — log yozuvlarini ularning source, tenant, severity, event turi yoki boshqa metadata siga qarab tegishli pipeline va storage destinationlarga yo‘naltirish jarayonidir. Masalan, audit log uzoq saqlanadigan himoyalangan arxivga, debug log qisqa retentionli qidiruv tizimiga yuborilishi mumkin.
Routing kaliti
Collector recordga tag yoki label qo‘shadi. Route sharti service=api, level=error yoki event.category=audit kabi fieldlarga tayanadi. Routing uchun ishlatiladigan field ishonchli metadata manbasidan olinadi; application yuborgan tenant satri authorization dalili emas.
Bir record bir nechta destinationga fan-out qilinishi yoki faqat bir routega tushishi mumkin. First-match va all-match semantikasi konfiguratsiyada aniq bo‘ladi. Qoidalar tartibi o‘zgarsa natija ham o‘zgarishi mumkin.
Pipeline bosqichlari
Parsing routingdan oldin bo‘lsa structured fieldlar ishlatiladi. Parse xatosi default route yoki quarantinega ketadi. Raw matn regexiga tayanish format o‘zgarganda yozuvni noto‘g‘ri destinationga yuborishi mumkin.
Redaction har qanday tashqi outputdan oldin bajariladi. Agar bitta route redactiondan chetlab o‘tsa secret arxiv yoki third-party tizimga chiqishi mumkin. Common processor va destinationga xos filterlar iyerarxiyasi test qilinadi.
Multi-tenant isolation
Har tenant alohida index, stream namespace yoki accountga yo‘naltirilishi mumkin. Tenant identity mTLS, authenticated endpoint yoki platform metadata bilan bog‘lanadi. User-controlled log fieldni to‘g‘ridan-to‘g‘ri destination nomiga qo‘shish path injection va data leakage xavfi yaratadi.
Quota ingest rate, storage va query xarajatini cheklaydi. Bir tenant burst qilganda umumiy buffer boshqa tenant logini drop qilmasligi uchun queue va rate siyosati adolatni hisobga oladi.
Failure va fallback
Asosiy destination ishlamasa log persistent queuega tushadi. Fallback arxivga yuborish data ni saqlashi mumkin, lekin keyin qidiruv tizimiga qayta yuklash jarayoni kerak. Fallbackning o‘zi ruxsat va retention talabiga mos bo‘ladi.
Noma’lum route ni default debug storagega yuborish sensitiveni ochishi mumkin; uni quarantine va alertga yo‘naltirish xavfsizroq bo‘lishi mumkin. Drop qilingan recordlar soni va sababi metricda ko‘rinadi.
Konfiguratsiya boshqaruvi
Routing qoidalari code sifatida versionlanadi. Sample log fixturelar har event turining aniq destinationini tekshiradi. Dry-run yangi config eski trafikni qayerga yuborishini bloklamasdan ko‘rsatishi mumkin.
O‘zgarish canary collectorlar orqali chiqariladi. Destination permission, mapping va quota oldindan tekshiriladi. Rollback yangi route davomida yozilgan data ni avtomatik eski joyga ko‘chirmaydi; migratsiya va dual-write davri alohida boshqariladi.
Qoidalar evolyutsiyasi
Routing qoidasi o‘zgarganda eski va yangi yozuvlar turli destinationga tushishi mumkin. Qoida versiyasi event metadata yoki deployment auditida qayd etilsa keyingi qidiruvda bu chegara tushuntiriladi. Yangi route avval shadow rejimda baholanib, qancha event mos kelishi o‘lchanadi; ma’lumot ikkinchi marta yuborilmasdan faqat qaror loglanadi. Catch-all yo‘nalish noma’lum formatni yo‘qotmaslikka yordam beradi, lekin u cheksiz saqlanmasligi kerak. Unmatched, duplicated va dropped event counterlari har qoida bo‘yicha kuzatiladi.
Xavfsizlik chegaralari
Route fieldini ishonchsiz log matnidan bevosita destination nomiga aylantirish ruxsatsiz oqim yaratishi mumkin. Destinationlar allowlistdan tanlanadi, tenant identifikatori autentifikatsiya qilingan metadata bilan tekshiriladi. Maxfiy loglar umumiy storagega tushmasligi uchun deny qoidasi catch-all qoidan oldin bajariladi. Konfiguratsiya o‘zgarishi auditga yoziladi va rollback uchun avvalgi versiya saqlanadi.
Bog‘liq tushunchalar
Log collector, Filter plugin, Output plugin, Multi-tenancy, Data routing, Persistent queue, Log aggregation