دوره آموزشی Splunk Fundamentals 2 – محصولات و خدمات امنیت سایبری

دسته بندی

splunk

بدون امتیاز 0 رای

دسترسی سریع

ارتباط با استاد

ضمانت بازگشت

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

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

سرفصل های آموزشی

ماژول یک - Beyond Search Fundamentals

زیرنویس عنوان

سلام. با Module اول Splunk Fundamental 2 در خدمت شما هستیم.در این Module، قرار است مروری کلی بر Basic Search Command هایی داشته باشیم که در دوره Splunk Fundamental 1 در خصوص آن‌ها صحبت کردیم و پس از آن، در خصوص فرایند Search در Splunk صحبت کنیم. در خصوص Basic Search در Splunk، برخی اصطلاحات و قوانین وجود داشت که در چند تصویر آن‌ها را بررسی خواهیم کرد.

مروری بر Basic Search

در Search Bar مربوط به Splunk، می‌توانستیم از یک کلمه یا چندین کلمه استفاده کنیم و در خصوص آن‌ها، در Log هایی که مد نظر داریم، Search انجام دهیم. اگر آن کلمه یا کلمات وجود داشته باشد، Log هایی که حاوی آن کلمات هستند، برای ما نمایش داده می‌شوند. برای مثال، در این Log هایی که مد نظر من است، کلمه error را Search کرده‌ام. پس از Search، اگر کلمه error در مجموعه Data و Log های مورد نظر وجود داشته باشد، آن Log ها نمایش داده می‌شوند و کلمه مربوطه برای من Highlight می‌شود.

همچنین می‌توانم از گروهی از کلمات استفاده کنم؛ برای مثال، error و post.

همان‌طور که مشاهده می‌کنید، Log هایی نمایش داده می‌شود که هم کلمه error و هم کلمه post در آن‌ها وجود دارد. اگر دقت کنید، کلمه POST که در Log وجود دارد، به صورت Capital حروف بزرگ نوشته شده است؛ اما من در اینجا و در Search، فقط از حروف کوچک استفاده کرده‌ام. به صورت کلی، Search Term Value هایی که استفاده می‌کنیم، Case-sensitive نیستند در تصاویر بعدی در خصوص این موضوع به تفصیل صحبت خواهیم کرد.

نکته بعدی در خصوص نحوه استفاده از Boolean های NOT، OR و AND است. ما اگر بخواهیم از این Boolean ها استفاده کنیم، باید حتماً آن‌ها را به صورت Uppercase با حروف بزرگ بنویسیم. همچنین، اگر بخواهیم قسمتی از Search ما در Search Bar اولویت بیشتری داشته باشد و ابتدا بررسی شود، می‌توانیم آن قسمت را داخل پرانتز قرار دهیم.

در این Search که در تصویر مشاهده می‌کنید، بین دو کلمه error و post، به صورت پیش‌فرض عملگر AND قرار دارد. زمانی که شما روی دکمه Search کلیک می‌کنید، در Background کلمه AND است که بین این دو Keyword قرار می‌گیرد. حتی اگر در Search Bar از Field های متفاوت نیز استفاده کنید، بین Field ها به صورت پیش‌فرض کلمه AND وجود دارد.

در مثال بعدی، ابتدا با استفاده از Field مربوط به index، مقدار Index مورد نظر class را مشخص کرده‌ایم. سپس با استفاده از Field مربوط به sourcetype، مقدار sourcetype=vendor_sales را تعیین کرده‌ایم. در ادامه، با استفاده از Boolean مربوط به OR و با استفاده از پرانتز برای تعیین اولویت، مشخص کرده‌ایم که یا sourcetype برابر vendor_sales باشد یا sourcetype برابر access_combined و action برابر purchase باشد. خروجی این Search، شامل Log هایی است که sourcetype آن‌ها vendor_sales یا access_combined است و برای Log هایی که sourcetype آن‌ها access_combined است، مقدار action برابر purchase می‌باشد.

نکته بعدی، استفاده از کلمات متفاوت و Field های متفاوت در Search Bar است که در خصوص این مورد توضیح داده شد. اگر بخواهیم در Search Bar یک جمله یا گروهی از کلمات که به هم مرتبط هستند را جستجو کنیم، باید آن‌ها را داخل Double Quote قرار دهیم. برای مثال، در جستجوی اول، عبارت "Failed password" را داخل Double Quote قرار داده‌ایم. همان‌طور که در خروجی مشاهده می‌کنید، کلمات Failed password برای من پیدا شد. اگر من Double Quote را بردارم، خروجی به چه صورت خواهد بود؟

همان‌طور که در خروجی می‌بینید، Failed به عنوان یک کلمه جدا و password به عنوان کلمه‌ای جدا شناسایی شد. البته در Log های نمونه ما، تقریباً خروجی مشابه است. اما اگر در یک سناریوی واقعی باشیم و بخواهیم یک جمله را Search کنیم، امکان دارد زمانی که از Double Quote استفاده نمی‌کنیم، خروجی بازگردانده‌شده ارتباطی با هدف و خروجی مورد انتظار ما نداشته باشد.

نکته بعدی در خصوص استفاده از Field ها داخل Search است. ما در Search Bar می‌توانیم از نام Field ها استفاده کنیم و مقادیر مورد انتظار را ذکر کرده و به دنبال آن مقادیر بگردیم. در دوره Splunk Fundamentals 1، در خصوص Field Discovery صحبت کردیم و به بخش‌های Verbose Mode، Smart Mode و Fast Mode اشاره‌ای کوتاه داشتیم. در این دوره، این قسمت را مفصل‌تر توضیح می‌دهیم و در خصوص Field Discovery و قسمت‌هایی مانند Pattern ها، Statistics و Visualization نیز بیشتر صحبت خواهیم کرد.

نکته بعدی که وجود دارد، در خصوص استفاده از Wildcard ها و عملگرهای مقایسه‌ای است. ما می‌توانیم در Search، از Wildcard استفاده کنیم، اما باید مراقب باشیم؛ چرا که نحوه استفاده از Wildcard، روی Performance تأثیر زیادی دارد و اگر شما در یک Search از Wildcard ها استفاده کنید، قطعاً زمانی که طول می‌کشد تا Search پاسخ دهد و خروجی مورد نظر را نمایش دهد، طولانی‌تر خواهد بود. پس تا حد امکان از Wildcard ها استفاده نکنید. با توجه به تجربه شخصی در سازمان های مختلف، افرادی که از splunk استفاده می کنند، خیلی از wildcard ها استفاده می کنند و از طرفی توقع دارند که splunk جستجوها را خیلی سریع پاسخ دهد. این دو موضوع با هم در تناقض اند. یعنی ابتدا باید درست جستجو کردن را یاد بگیریم و پس از آن توقع داشته باشیم که splunk با سرعت بالایی پاسخ دهد. پس یا از wildcar ها استفاده نکنید یا اگر قصد استفاده دارید، مانند مثالی که ارائه شده status=4*، در انتهای Value مورد نظرتان، آن Wildcard را به کار ببرید. یعنی ابتدا Field را مشخص کنید، نام Field را به کار ببرید، تا جایی که از Value اطلاع دارید آن را وارد کنید و در انتهای آن از Wildcard استفاده نمایید.

در مثال بعدی، در خصوص استفاده از عملگرهای مقایسه‌ای صحبت می‌کنیم. ما عملگرهای مختلفی مانند مساوی =، نامساوی !=، کوچکتر <، بزرگتر >، بزرگتر مساوی >= و کوچکتر مساوی <= داشتیم. می‌توانیم از تمام این‌ها در Search استفاده کنیم. بسته به سناریویی که داریم و هدفی که برای آن Search ایجاد می‌کنیم، می‌توانیم چند تا از این عملگرها را استفاده کنیم.

خلاصه دستورات دوره قبل

در این تصویر، خلاصه‌ای از دستوراتی را مشاهده می‌کنید که در دوره Splunk Fundamentals 1 با یکدیگر فرا گرفتیم.

دستور table را داشتیم؛ ما به وسیله این دستور می‌توانستیم خروجی Search خود را در قالب Table نمایش دهیم که خوانایی را افزایش می‌داد و خروجی خواناتر می‌شد.
با استفاده از دستور rename، می‌توانستیم نام Field ها را تغییر دهیم. برای مثال، فرض کنید در Table ای که رسم کرده‌اید، یک ستون به نام X وجود دارد؛ می‌توانستیم نام آن X را تغییر دهیم.
دستور fields وجود داشت؛ با استفاده از این دستور می‌توانستیم برخی Field ها را Include یا Exclude کنیم و گفتیم که این دستور بسیار مهمی است و اگر بتوانیم از آن در ابتدای Search استفاده کنیم و Field هایی که واقعاً نیاز داریم را Include کنیم، Performance مربوط به Search ما فوق‌العاده بهتر و بالاتر خواهد بود.
دستور dedup را داشتیم که به وسیله آن می‌توانستیم سطرها و ستون‌های تکراری را حذف کنیم.
دستور بعدی، دستور sort بود که با استفاده از آن می‌توانستیم نحوه نمایش و چینش جدول و مقادیر را تغییر دهیم.
دستور مهم بعدی، دستور lookup بود که ما به وسیله Lookup Table File ها می‌توانستیم Log های خود را Enrich کنیم و Field ها و اطلاعات دیگری را از External Source ها به Log خود اضافه نماییم.

بررسی Case Sensitivity در Splunk Search

در خصوص Search، یک نکته بسیار مهم و امتحانی وجود دارد و آن این است که بدانیم کجاها Case-sensitive بودن وجود دارد و چه چیزهایی Case-sensitive نیستند. در تصاویری که مشاهده می‌کنید، در دو جدول، موارد Case-sensitive و مواردی که Case-insensitive نیستند، ذکر شده و با هم آن‌ها را در جدول می‌بینیم. این نکته به قدری مهم است که در امتحانات Splunk، حداقل یک سؤال مرتبط با Case-sensitive بودن یا نبودن موارد مختلف وجود دارد.

موارد Case-sensitive حساس به حروف بزرگ و کوچک:

Boolean Operator ها: مورد اولی که با هم می‌بینیم، Boolean Operator ها هستند. همان‌طور که چندین بار گفته شد، باید حتماً با حروف بزرگ نوشته شوند
Field Name ها: نام Field ها در Splunk Search، Case-sensitive است. شما باید دقیقاً همان نام Field را بنویسید که وجود دارد. اگر نام Field ای ابتدا با حرف بزرگ شروع شده، شما باید عیناً همان را بنویسید و اگر از حروف کوچک استفاده کنید، خروجی برای شما نخواهد داشت.
Field Value های حاصل از Lookup پیش‌فرض، اما قابل تنظیم: مقادیری که از طریق Lookup ها به Event ها اضافه می‌شوند، به صورت پیش‌فرض Case-sensitive هستند البته این رفتار در تنظیمات Lookup قابل تغییر است.
Regular Expression ها: تمام موارد مرتبط با Regular Expression در Search Bar، Case-sensitive هستند.
Field Value های استفاده شده با دستورات eval و where : مقادیری که در شرط‌های دستورات eval و where استفاده می‌شوند، Case-sensitive هستند. مثال آن را هم می توانید اینجا ببینید.
Tag : مورد بعدی Tag ها هستند. Tag هایی که روی Log ها وجود دارند، تماماً Case-sensitive هستند و Admin ای که آن Tag ها را ایجاد می‌کند و Event Type ها را می‌سازد، باید دقت کند که Tag را با حروف بزرگ به کار می‌برد یا حروف کوچک. همچنین در آینده، مفاهیم Data Model را که فرا گرفتیم، Tag هایی نیاز است که باید در Log وجود داشته باشند؛ اگر در Log، Tag به صورت حروف بزرگ وجود داشته باشد، دیگر آن Data Model نمی‌تواند Data هایش را به دست آورد.

در جدول بعدی می توانیم مواردی که case sensitive نیستند را بررسی کنیم.

موارد Case-insensitive غیر حساس به حروف بزرگ و کوچک:

Command Name ها: نام دستورات مانند stats, table, rename و ... Case-insensitive نیستند و تفاوتی نمی‌کند که با حروف بزرگ یا کوچک نوشته شوند.
Command Clause ها: Clause هایی که جزیی از دستورات هستند مانند AS, BY, WITH نیز Case-insensitive نیستند.
Search Term ها Keyword ها: کلماتی که در Search Bar می‌نویسیم مانند failed password که در یکی از مثال ها داشتیم که می توانستیم آن را به صورت حروف بزرگ یا کوچک بنویسیم. Case-insensitive نیستند.
Statistical Function ها: توابع آماری مانند avg, sum, count نیز Case-insensitive نیستند.
Field Value ها: مقادیر Field ها به طور کلی Case-insensitive نیستند و می‌توان آن‌ها را با حروف بزرگ یا کوچک جستجو کرد مگر اینکه از Lookup آمده باشند یا در دستورات eval و where استفاده شوند.

فرایند جستجو و Buckets

تا اینجای ویدئو، ما در خصوص مطالب بسیار مهمی که در Splunk Fundamentals 1 وجود داشت، صحبت کردیم و نکات مهم آن را با هم بررسی نمودیم. از این لحظه به بعد، ما مطالب جدید Splunk Fundamentals 2 را با هم بررسی کرده و یاد می‌گیریم.

ابتدا می‌خواهیم در خصوص اینکه Bucket به صورت کلی چیست و زمانی که ما روی دکمه Search در Splunk کلیک می‌کنیم چه اتفاقی می‌افتد صحبت کنیم.

نکته بسیار مهمی که در خصوص آموزش‌های من وجود دارد و شما باید به آن دقت کنید، این است که Concept هایی که در هر دوره و در هر Module گفته می‌شود، در سطح همان Module و همان دوره است. برای مثال، الان که می‌خواهم در خصوص Bucket صحبت بکنم، به خاطر اینکه سطح تجربه و دانش افرادی که این دوره را مشاهده می‌کنند، در سطح مشخصی قرار دارد، من نمی‌توانم بیش از این موارد الان تدریس کنم و باید بقیه موارد را در دوره‌های بعد ببینید. دلیل اصلی‌اش هم این است که اگر یک سری موارد را بیش از حد الان بیان بکنم، قبل از اینکه شما دانش و تجربه یک سری موارد را نداشته باشید، یک سری سؤال و ابهام اساسی برایتان پیش می‌آید که شاید راه را گم کنید. برای همین، حتماً این را گوشه ذهنتان داشته باشید که اگر الان من مفاهیم Bucket را عرض می‌کنم، یک سری توضیحات اضافه هم دارد که بعداً در دوره‌های آینده درباره آن صحبت می‌کنیم و الان مجبوریم که مطالب را در سطح دوره و Module ای که داخل آن هستیم، ارائه دهیم.

در دوره قبلی Splunk Fundamentals 1، ما در خصوص Index و Indexer صحبت کردیم و گفتیم که Index و Indexer را با هم اشتباه نگیرید و مفاهیم مرتبط با Index و Indexer را توضیح دادیم. زمانی که یک Event یا یک Log وارد Splunk می‌شود و وارد آن Index می‌شود، داخل آن Index، Bucket های مختلفی وجود دارد.

انواع Bucket

Bucket چیست؟ تعریف‌های مختلفی برای Bucket وجود دارد، اما به صورت کلی، یک Index شامل چندین Bucket است که هر Bucket با طول عمرش، با سنش مدیریت می‌شود؛ یعنی Event ای که وارد Index می‌شود، ابتدا داخل یک Type خاص از Bucket که به آن Hot Bucket می‌گویند نوشته می‌شود و بعد از آن، با توجه به مدت زمان نگهداری‌اش و پارامترهای دیگر، به Bucket بعدی که Bucket مربوط به Warm است منتقل می‌شود و بعد از آن هم، باز با توجه به مدت زمان نگهداری اش، حجم آن و مجموعه ای از پارامترهای دیگر به Bucket مربوط به Cold منتقل می شود. در splunk پنج نوع Bucket داریم که در اینجا فقط سه نوع از آن را مشاهده می کنید. Bucketهای Hot، Warm و Cold. پس splunk enterprise دیتای ایندکس ها را داخل باکت های مختلف نگهداری می کند. در اصل Bucket ها در سیستم دایرکتوری هایی هستند که شامل Data و فایل های ایندکس هستند.

زمانی که یک منبع Log ای، Log خودش را برای Splunk ارسال می کند، ادمین Splunk تنظیمات مرتبط با Input را انجام می دهد و ایندکس مورد را می سازد و تنظیمات مرتبط با Bucket ها را نیز انجام می دهد. برای مثال تنظیمات مربوط به مدت زمان نگهداری داده داخل Bucket های Hot و Warm و Cold توسط ادمین انجام می شود و زمانی که داده وارد ایندکس ها می شود، ابتدا داخل Hot Bucket نوشته می شود و پس از آن با توجه به تنظیمات ادمین برای نگهداری این Bucket، این Bucket رول می شود به Warm Bucket و پس از آن نیز با توجه به تنظیمات انجام شده توسط ادمین، Warm Bucket رول می شود به سمت Cold Bucket و بعد از این Bucket های متفاوت دیگری نیز وجود دارد که در آینده با آن ها آشنا می شویم.

نکات مربوط به Bucket

یک سری نکات کلی و مهم هم هست که بد نیست با آن‌ها آشنا شوید. برای مثال، هر Bucket، فایل‌های Index، Metadata و Raw Data خودش را دارد. Metadata File ها، اطلاعات Source، Sourcetype و Host را Track می‌کنند. از آنجایی که هر Bucket عمر خودش را دارد، میزان مدت نگهداری خودش را دارد، زمانی که آن عمر یا آن مدت زمان نگهداری‌ای که Admin پیکربندی کرده برای هر Bucket به انتها برسد، Bucket، Roll می‌شود به Bucket بعدی مثلاً از Hot به Warm، از Warm به Cold. اصلاً امکان ندارد که یک‌دفعه از Hot به Cold برود؛ یک ترتیبی وجود دارد که این ترتیب باید رعایت شود.

مباحث مرتبط با Bucket خیلی گسترده‌تر از این صحبت‌هاست که بتوانیم در عرض چند دقیقه آن را تکمیل کنیم. ان‌شاءالله در ویدئوهای آینده در خصوص آن به تفصیل صحبت می‌کنیم. اما با توجه به مطلبی که گفتیم در خصوص Bucket، زمانی که شما روی دکمه Search کلیک می‌کنید چه اتفاقی می افتد؟ گفتیم که Bucket های متفاوتی وجود دارد و Splunk داده ها را در Bucket های مختلفی ذخیره می کند و هر Bucket نیز مدت زمان نگهداری مخصوص به خودش را دارد. برای مثال امکان دارد یک Data ای که ارسال شده به Splunk از سه ساعت پیش تا الان در یک Hot Bucket وجود داشته باشد و از سه ساعت قبل تا شش ساعت قبل در یک Hot Bucket دیگر و همین طور پایین تر می آید.

اسامی Event و Raw Data Event هم وجود دارد. این یک جدولی است که یک مفهوم ذهنی را به شما می رساند. زمانی که شما روی دکمه search کلیک می کنید و Time Range Picker تان را در تایم مشخص تنظیم کرده‌اید، Splunk ابتدا Bucket هایی که در آن Time Range هستند را مشخص کرده و انتخاب می‌کند. برای مثال، اگر شما ۲۴ ساعت گذشته را انتخاب کرده باشید، در این مثال، جستجوی شما شامل Bucket های سه Bucket مربوط به Hot و چندین Bucket مربوط به Warm هست. بعد از مشخص شدن Bucket باتوجه به نام ایندکس که ما مشخص کرده ایم، ایندکس و آن داده ها را نیز دقیق تر مشخص می کند.

بنابراین بعد از مشخص شدن Bucket به وسیله Time Range Picker، سپس Index، یعنی آن Data ای که می‌خواهیم داخلش Search بزنیم و بعد درون آن ایندکس مورد نظر به وسیله Field ها و search term هایی که شما در جستجو وارد کرده اید، Data را انتخاب می‌کند و به شما نمایش می‌دهد. به عنوان مثال اگر شما جستجو کرده باشید، index = web password faild در 24 ساعت گذشته، Splunk ابتدا Bucket های 24 ساعت گذشته را برای شما مشخص می کند و بعد نام ایندکس هم که مشخص شده و بر اساس واژه هایی که جستجو کرده اید، Log ها را به شما نمایش می دهد. حالا این مواردی که گفتیم، یک فرایند کلی از Search بود. خیلی مباحث پیچیده‌تر و مفصل‌تری دارد که در آینده حتماً در خصوصش صحبت می‌کنیم.

با توجه به مواردی که تا الان گفته شد، می‌خواهیم یک سری Search Practice های عمومی را با همدیگر بررسی کنیم.

بررسی Search Best Practices

مواردی که در این قسمت بیان می‌شود را احتمالاً چندین بار در طول این دوره شنیده‌اید.

بهترین فیلتر و تأثیرگذارترین فیلتر، این است که شما Time درستی را ابتدا انتخاب بکنید. زمانی که Data شما برای مثال در ۴ ساعت گذشته است و Time آن را می‌دانید، با استفاده از این Time Picker، سعی کنید Time دقیقی را برای آن Data.مشخص کنید
بعد از مشخص کردن Time، استفاده از Field هایی مانند Index، Host، Source و Sourcetype، بهترین Field هایی هستند که شما می‌توانید به عنوان فیلتر از آن‌ها استفاده کنید.
تا جایی که می‌توانید، اسم Index و اسم Sourcetype را در Search هایتان حتماً بیان کنید.
مورد بعدی، استفاده از دستور fields است. شما با استفاده از این دستور، دارید روی Field Discovery تأثیر می‌گذارید. Field Discovery یکی از زمان‌برترین پروسه‌های زمان Search در Splunk است. پیشنهاد من برای شما که دائماً می‌خواهید با Splunk کار بکنید و Search بزنید این است که، Sourcetype ها و Log هایی که دارید را یک بار برای همیشه شناسایی بکنید، مطالعه بکنید و Field هایی که بیشتر با آن‌ها کار می‌کنید را یک جا یادداشت کنید و از دستور fields استفاده بکنید و در Search هایتان، Field هایی که می‌خواهید را Include کنید یا Field هایی که نمی‌خواهید را Exclude کنید. تقریباً می‌توان گفت حدود ۷۰ درصد Search Performance شما بهتر می‌شود اگر از این روش استفاده کنید.
Wildcard هایی که می‌خواهید استفاده کنید را سعی کنید در انتهای Value هایتان قرار دهید. برای مثال، اگر من بخواهم Sourcetype مربوط به access_combined را با Wildcard جستجو کنم، در انتهای این Value، Wildcard ام را قرار می‌دهم و از آن استفاده می‌کنم.
Inclusion بهتر از Exclusion: زمانی که می‌خواهید Search بزنید، این‌طور فکر کنید که در Search تان همیشه Inclusion بهتر از Exclusion است. برای مثال، فکر کنید می‌خواهید Log هایی را ببینید که در آن Log ها، متوجه شوید چه کسانی دسترسی‌شان Denied شده است. می‌توانید Search ای بنویسید که مستقیماً access=denied را هدف قرار دهید، یا اینکه نه، بیایید Search ای بنویسید که access=granted را NOT بکنید. مورد اولی می‌شود Inclusion، مورد دومی می‌شود Exclusion. امیدوارم که مفهوم را درک کرده باشید، چون این یک مفهوم است. زمانی که می‌خواهید Search ایجاد بکنید، این تفکر Inclusion، فوق‌العاده سرعتش بالاتر از Exclusion است. هر زمانی که خواستید از NOT و یا نامساوی != استفاده کنید، بررسی کنید که آیا می‌توانید برعکس آن، Search ای بنویسید که Inclusion باشد و بعد Search را اجرا کنید.
فیلترهایی که داخل Search تان می‌نویسید، تا جایی که امکان دارد، فیلترهای مهم را ابتدای Search بیاورید.
از دستوراتی مانند dedup و sort استفاده کنید که سرعت Pipe های بعدی شما بالاتر برود. زمانی که این Pipe ها جمع می‌شود و شما روی دکمه Search کلیک می‌کنید، ابتدای Search تان اگر فیلترهای مناسبی نوشته باشید، Duplicate ها را حذف کرده باشید و خروجی را Sort کرده باشید، خیلی سرعت Process های بعدی بالاتر است.
مورد بعدی و مورد مهم این است که از Search Mode درستی استفاده کنید. Search Mode مربوط به Fast وجود دارد، Smart و Verbose. تفاوت Mode های مختلف چیست و در واقع این Mode ها چه کاری دارند برای ما انجام می‌دهند؟ من مثال‌ها را آماده می‌کنم و بعد با جزئیات کامل هر Mode را توضیح می‌دهم.

Transforming Search Command

قبل از اینکه با تفاوت Mode های مختلف آشنا بشویم، باید در خصوص Transforming Search Command ها یک توضیح مختصری بدهم. برخی از دستوراتی مانند top، rare، chart، timechart، stats و چندین دستور دیگر، جزو Transforming Search Command ها محسوب می‌شوند. یک Transforming Search Command، Raw Data را به یک جدولی از Data تبدیل می‌کند و Field های مورد انتظارمان که به آن Transforming Command ارسال کرده‌ایم را برای هر Event به Value های عددی تبدیل می‌کند، به مقادیر عددی تبدیل می‌کند که برای اهداف آماری مورد استفاده قرار می‌گیرد. اگر بخواهیم یک Visualization هم رسم بکنیم، به Transforming Command ها نیاز داریم. پس Transforming Command ها، Data ای که قبل از Pipe دریافت کرده‌اند را می‌گیرند، با توجه به Field هایی که در Transforming Command به کار برده‌ایم، آن‌ها را تبدیل به مقادیر عددی می‌کنند و برای اهداف آماری استفاده می‌شود. نکته‌ای که وجود دارد، Field هایی که استفاده می‌شود، باید با توجه به قوانین آن Command باشد.

با توجه به توضیحاتی که در این چند دقیقه اخیر دادم، می‌خواهم در خصوص Mode های مختلف Search و همین‌طور Job Inspector صحبت بکنم. بدانیم این‌ها چیست و چه کاری می‌توانند برای ما انجام دهند.

Mode های مختلف Search

زمانی که من Search خود را روی Fast Mode تنظیم می‌کنم، سرعت و Performance مربوط به Search برای من بسیار مهم است و به طور کلی، Fast Mode تاکید آن بر Performance بهتر است و Data ای را به شما بازمی‌گرداند که Essential است و نیازتان هست. اگر دقت بکنید، خروجی که وجود دارد، هیچ Field ای برای من Extract نشده و فقط Field های اصلی را من دارم اینجا می‌بینم. و از طرفی، چند Tab این قسمت وجود دارد: Tab مربوط به Event، Pattern، Statistics، Visualization. زمانی که Mode روی Fast باشد، فقط Tab های Event و Pattern کار می‌کند. Tab هایی مثل Statistics و Visualization کار نمی‌کنند. کاربرد این موارد در ادامه توضیح داده خواهد شد.

حالت Fast Mode

اما زمانی که من Mode را روی Fast Mode تنظیم می‌کنم و از دستورات Transforming استفاده می‌کنم، Tab های Statistics و Visualization کار می‌کنند و Tab های Pattern و Event کار نمی‌کنند. نکته دیگری که وجود دارد، این است که من از کجا بفهمم Performance این Search ام بهتر از آن Search بوده؟ و از کجا می‌توانم این‌ها را پایش کنم و ببینم؟ زمانی که یک Search برای ما اجرا می‌شود، ما می‌توانیم Job آن Search را ببینیم. بیاییم در قسمت Job، گزینه Inspect Job را بزنیم و اطلاعاتی در خصوص اجرا شدن آن Job داشته باشیم. برای مثال، این Search ای که اینجا من اجرا کرده‌ام، حدود ۳ ثانیه زمان برده است. کلاً Job Inspector به شما اجازه می‌دهد که State کلی Search تان را ببینید و بررسی کنید که چه قسمت‌هایی و کجاها Search، Time بیشتری استفاده کرده است.

معمولاً برای Troubleshoot کردن Search Performance و برای اینکه بفهمید Impact مربوط به Knowledge Object هایتان روی این Processing کجا بوده و چی شده، چه اتفاقی افتاده، این Job Inspector توسط Splunk Admin ها استفاده می‌شود. در این مثالی که داریم با هم می‌بینیم، در این کاری که داریم الان با هم انجام می‌دهیم، داریم Mode های مختلف را با همدیگر بررسی می‌کنیم، این Time برای ما مهم است. این Search حدود ۳ ثانیه طول کشیده است. Search ای که با Transforming Command و در Fast Mode اجرا شده را هم باهم ببینیم. این هم حدود ۳ ثانیه است. اگر بخواهیم مقایسه کنیم، این search تقریبا بیشتر طول کشیده است.

حالت Smart Mode

Mode بعدی‌ای که می‌خواهیم بررسی کنیم، Smart Mode است. Smart Mode برای این طراحی شده که به شما بهترین Result را ارائه بدهد. Search شما را بررسی می‌کند و تلفیقی از Fast و Verbose است. اگر از Transforming Command ها استفاده نکنم، Tab مربوط به Event، Pattern برای من کار می‌کند، ولی Statistics و Visualization همچنان کار نمی‌کنند. Time آن را هم با هم ببینیم؛ چقدر طول کشیده اجرا شود؟ حدود ۱۳ ثانیه. زمانی که از Transforming Command ها در Smart Mode استفاده می‌کنم، Tab مربوط به Visualization و Statistics کار می‌کند و Tab مربوط به Pattern و Event کار نمی‌کند. Time ای هم که استفاده کرده، حدود ۳ ثانیه است که از search قبلی که بدون Transforming Command بود خیلی کمتر است.

حالت Verbose Mode

Mode بعدی‌ای که می‌خواهیم بررسی کنیم، Verbose Mode است که با دو حالت بدون Transforming Command و با Transforming Command بررسی شده است Verbose Mode روی کامل بودن نتایج برگشتی، از نظر اینکه تمام Field ها و Data ها Extract بشوند، تمرکز دارد. و زمانی که شما از این Mode استفاده کنید، تا حد امکان Field Discovery تمام Field هایی که وجود دارد را برای شما Extract می‌کند و به شما نمایش می‌دهد. اما مدت زمانی که طول می‌کشد این Search اجرا بشود چقدر است؟ در حالتی که بدون Transforming Command است، حدود ۱۷ ثانیه و در حالتی که Transforming Command استفاده شده، حدود ۱۲ ثانیه زمان برده است. و در حالتی که Transforming Command وجود دارد، تمام Tab ها کار می‌کنند و همین‌طور زمانی که Transforming Command در این Mode وجود ندارد، Tab مربوط به Visualization و Statistics همچنان کار نمی‌کند و شما نمی توانید به قابلیت های آن دسترسی داشته باشید که این هم طبیعی است.

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

ماژول دو - Using Transforming Commands for Visualization

زیرنویس عنوان

سلام. با Module دوم دوره Splunk Fundamental 2 در خدمت شما هستیم. در این Module، قرار است نحوه استفاده از Transforming Command ها برای Visualization را فرا بگیریم. ابتدا، لازم است با Structure Data های مورد نیاز برای Visualization آشنا شویم. سپس، در خصوص Type های مختلف Visualization صحبت خواهیم کرد و در نهایت، با استفاده از دستوراتی مانند Chart و Timechart، نمودارهای مختلفی رسم می‌کنیم.

انواع Visualization ها در Splunk

زمانی که شما یک Search در Splunk ایجاد می‌کنید یا به عبارتی دیگر، یک Search اجرا می‌کنید، اگر خروجی آن Search به صورت مقادیر آماری باشد، می‌توانید از Type های مختلف Visualization های موجود استفاده کنید. انواع مختلفی از Visualization ها در Splunk وجود دارد. به عنوان مثال، Column Chart، Line Chart، Pie Chart و چندین نوع Visualization دیگر موجود است. توجه داشته باشید که Type های Visualization موجود در Splunk، زمانی که نرم‌افزار را به‌تازگی نصب می‌کنید، ممکن است محدود باشند. اما می‌توانید از Splunkbase، انواع Type های دیگری را نیز Download کنید. انواع مختلفی از Visualization در Splunkbase وجود دارد که توسط خود شرکت Splunk یا توسط سایر شرکت‌ها و افراد ایجاد شده‌اند و قابل استفاده هستند.

نکته بسیار مهمی که در اینجا مطرح است، این است که هر Search لزوماً قابلیت ایجاد Visualization را ندارد و نمی‌توان از خروجی هر Search، یک Visualization رسم کرد. زمانی که یک Search ایجاد می‌کنید و خروجی دریافت می‌کنید، اگر به Tab های Statistics و Visualization مراجعه کنید و نتایج Search شما قابلیت ایجاد Visualization بر اساس داده‌های آماری را نداشته باشد، پیامی مبنی بر این موضوع نمایش داده خواهد شد. مفهوم این پیام آن است که نتایج حاصل از Search شما، داده‌های آماری یا ساختار لازم برای Visualization را ندارند. در این حالت، معمولاً راهکارهایی پیشنهاد می‌شود که البته در این دوره به آن‌ها نمی‌پردازیم. در این دوره، هدف ما یادگیری نحوه ایجاد یک Data Series مجموعه داده مناسب و استفاده از آن برای رسم Visualization است.

سؤالی که مطرح می‌شود این است که Data Series چیست؟ چگونه می‌توان از Raw Data به یک Data Series رسید که برای Visualization قابل استفاده باشد؟ به خروجی این Search با دقت توجه کنید تا ببینید چه مواردی لیست شده و چه مقادیری نمایش داده می‌شود.

خروجی این Search شامل دو ستون است. ستون اول، نقاط یا دسته‌بندی‌هایی را در Data نمایش می‌دهد. ما یک Data خام داشتیم و با استفاده از Command مربوط به stats، نقاط یا دسته‌بندی‌های مشخصی را تعریف کرده‌ایم که هر کدام مقادیر عددی متناظری دارند. تمام این مقادیر و نقاط مشخص‌شده، با یکدیگر مرتبط هستند و یک جریان یا روندی را نمایش می‌دهند. Splunk می‌تواند با اتصال این نقاط و مقادیر مرتبط به هم، Visualization مورد نظر را برای شما رسم کند.

نکته بسیار حائز اهمیت این است که Data Structure های مختلفی وجود دارد و به همین ترتیب، Visualization های متفاوتی نیز موجود است. هر Visualization نیازمند Data Series با Structure خاص خود است.

به عنوان مثال، اگر داده‌ای دارید که می‌خواهید برای آن Visualization رسم کنید و هدف شما استفاده از Pie Chart یا Bar Chart است، باید بررسی کنید که کدام یک از دستورات Command ها در Splunk، Data Series ای با Structure مناسب برای این نوع نمودارها ایجاد می‌کند.

انواع Data Series

در این بخش، مهم است که بدانید Data Series های متفاوتی وجود دارد. خروجی دستورات Splunk، Data Series های متفاوتی تولید می‌کند و Type های Visualization مختلفی نیز در Splunk وجود دارد که هر کدام نیازمند Data Series با Structure خاصی هستند.

Single Series : بیشتر Visualization ها نیازمند یک جدول Single Series تک سری هستند. به این معنی که خروجی Transforming Command ها باید یک جدول با Data Structure از نوع Single Series باشد. در این ساختار، جدول باید حداقل دو ستون داشته باشد. در جدولی که در تصویر مشاهده می‌کنید خروجی دستور stats، یک جدول Single Series نمایش داده شده است. ستون سمت چپ اولین ستون، مقادیر محور X دسته‌بندی‌ها یا نقاط و ستون یا ستون‌های بعدی، مقادیر عددی محور Y را برای نمودار مشخص می‌کنند.
Multi Series : پس از Single Series، با Data Structure از نوع Multi Series مواجه هستیم. اگر بخواهیم جداولی رسم کنیم که Multi Series محسوب شوند، باید داده‌ها را به گونه‌ای در نظر بگیریم که نقاط یا دسته‌بندی‌های متعددی وجود داشته باشد. این نقاط بسیار بیشتر از حالت Single Series هستند. در عین حال، دسته‌هایی از این نقاط مختلف، کاملاً به هم مرتبط و از یک جنس هستند. معمولاً می‌توان از دستوراتی مانند Chart و Timechart برای تولید جداول Multi Series استفاده کرد. برای مثال، در جدولی که در تصویر مشاهده می‌کنید یک جدول Multi Series است. ستون سمت چپ ، مقادیر محور X نمودار را مشخص می‌کند و ستون‌های بعدی ، مقادیر عددی محور Y را در نمودار نشان می‌دهند. در Tab مربوط به Visualization، می‌توان نمودار حاصل از این داده‌ها را مشاهده کرد. همان‌طور که می‌بینید، نمودار Multi Series با نمودار Single Series متفاوت است. می‌توان از انواع Visualization های مختلف استفاده کرد و نوعی را انتخاب نمود که با خروجی Search مطابقت دارد. برای مثال، در حالت Single Series، می‌توان از Pie Chart نیز استفاده کرد، اما در حالت Multi Series، استفاده از Pie Chart ممکن است خروجی مفیدی ارائه ندهد، مگر اینکه از گزینه‌های اضافی مانند Trellis Layout برای تقسیم نمودار به بخش‌های مجزا بر اساس یک فیلد استفاده شود یا نوع Chart تغییر یابد.
Time Series : پس از Structure های Multi Series و Single Series، Data Structure از نوع Time Series را داریم. همان‌طور که در تصویر مشاهده می‌کنید خروجی دستور timechart count، خروجی، جدولی است که ستون سمت چپ اولین ستون نمایانگر زمان _time است می‌تواند تاریخ یا ساعت باشد. مهم است که این ستون، زمان را نشان می‌دهد. همانند Data Structure های قبلی، اولین ستون سمت چپ مقادیر محور X و ستون‌های بعدی مقادیر عددی محور Y را مشخص می‌کنند. نکته قابل توجه این است که Time Series ها نیز می‌توانند Single Series یا Multi Series باشند. اگر پس از ستون زمان، تنها یک ستون مقادیر عددی وجود داشته باشد، Single Series و اگر چندین ستون وجود داشته باشد، Multi Series خواهد بود. در نتیجه، Time Series ها، Trend آماری داده‌ها را بر اساس زمان نمایش می‌دهند. اگر Visualization آن را مشاهده کنیم نمودار حاصل، محور X نمایانگر تاریخ و زمان و محور Y شامل نقاط مختلف مقادیر عددی برای هر Host است که با حرکت دادن ماوس روی نمودار، مقادیر دقیق هر نقطه قابل مشاهده است.

برای جمع‌بندی مباحث این چند دقیقه: Data Structure های متفاوتی وجود دارد. Search ای که ایجاد می‌کنیم باید متناسب با Data Structure مورد نیاز Visualization انتخابی ما باشد. همچنین، Visualization های متفاوتی مانند Line Chart، Area Chart، Column Chart، Bar Chart، Bubble Chart، Scatter Chart، Pie Chart و غیره وجود دارد. در این Module، می خواهیم نگاهی کلی به انواع Chart ها و Data Structure های مورد نیاز آن‌ها داشته باشیم. در بخش‌های بعدی، به دستوراتی مانند Chart و Timechart که برای ما Visualization رسم می‌کنند، خواهیم پرداخت.

انواع چارت ها

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

LineChart

در این خروجی یک search ای نوشته شده که خروجی آن شامل یک جدول دو ستونه است و از LineChart استفاده شده و همین طور که می بینید خروجی آن شامل نموداری است که محور X و Y دارد که محور X زمان و محور Y تعداد Logهای مدنظر ما را نمایش می دهند. در Search بعدی که خروجی آن یک جدول Multi Series است و از LineChart استفاده شده می بینیم که محور X زمان و محور Y مقادیر فیلد Action را نمایش می دهد. در Search بعدی از AreaChart استفاده شده که ظاهر خروجی آن متفاوت است. خروجی این search یک جدول single series است و مانند مثال های قبل محور X زمان و محور Y تعداد Log ها را نمایش می دهند. مثال بعدی هم AreaChart است و خروجی Search یک جدول MultiSeries است. محور X زمان و محور Y مقادیر فیلد action داخل Log را نمایش می دهند.

Column Chart

در مثال بعدی، از Column Chart استفاده شده است. این نمودار ابتدا بر روی یک Single Series Table اعمال شده که خروجی آن به صورت تصویری است که مشاهده می‌فرمایید و در مثال بعدی، یک Multi-series Table وجود دارد و مجدداً از Column Chart استفاده شده است. خروجی آن به صورتی است که مشاهده می‌کنید. خروجی این Search یک Multi-series Table است که محور X شامل مقادیری است که داخل Field مربوط به Action وجود دارد و ستون‌های دیگری نیز وجود دارند که مقدار محور Y را مشخص می‌کنند. در Column Chart می‌توان از Stack Mode نیز استفاده کرد. گزینه‌ای با نام Stack Mode وجود دارد که نحوه نمایش را به صورت Stack تغییر می‌دهد. همچنین می‌توان از Option هایی مانند Show Data Value استفاده کرد تا مقادیر دقیق محور Y برای هر Point مشخص شود.

Bar Chart

در مثال بعدی، از Bar Chart استفاده شده است. در Bar Chart، تقریباً می‌توان گفت محور X و Y نسبت به Column Chart برعکس هستند. در این مثال، چپ‌ترین Column، محور Y و محور X مقادیری است که در Table نمایش داده می‌شود. در مثال بعدی نیز مجدداً از Bar Chart استفاده شده، اما این بار Table خروجی، Multi-series است. همان‌طور که مشاهده می‌شود، برعکس Column Chart، محور X و Y در اینجا جابجا شده‌اند، اما کارکرد اصلی تغییری نکرده است.

Pie Chart

در مثال بعدی، از Pie Chart استفاده شده است. یک Single Series Table وجود دارد و از Pie Chart برای رسم Visualization آن استفاده شده است.

Scatter Chart

Chart بعدی که در مثال‌های ما وجود دارد، Scatter Chart است. ممکن است در خروجی دستورات Commands و Search شما، مقادیر پراکنده وجود داشته باشد؛ Data ای که مقادیر آن از هم گسسته هستند. با استفاده از این Chart، می‌توان نمودار پراکندگی و Trend روابط بین این Value ها را نمایش داد. در نتیجه، Scatter Chart می‌تواند Trend و روابط بین مقادیری که گسسته هستند را به خوبی نمایش دهد. خود کلمه Scatter به معنی پراکندگی است و به وسیله آن می‌توان Chart های جدیدی رسم کرده و به راحتی از آن‌ها استفاده نمود.

Bubble Chart

Chart بعدی Bubble Chart است. این Chart نیز مانند Scatter Chart برای نمایش مقادیر Data های گسسته مناسب است و می‌تواند Trendحجم و ارتباط این مقادیر را نمایش دهد. تفاوت Bubble Chart با Scatter در این است که در Chart های Scatter، زمانی که Mouse بر روی یک مقدار قرار می‌گیرد، اطلاعاتی نمایش داده می‌شود که دو بُعد دارد یعنی Scatter Chart دو بعدی است اما در Bubble Chart، نه تنها آن اطلاعات نمایش داده می‌شود، بلکه حجم Bubble ها نیز مقداری را نشان می‌دهد بسته به Search، حجم Bubble یک مقدار مشخص را نمایش می‌دهد که این ویژگی در Scatter وجود ندارد.

برای درک بهتر، به دستور Stats دقت کنید. همین دستور در Scatter Chart نیز به کار رفته است. در Scatter Chart، ابتدا Sum مربوط به Price محاسبه شده و این Sum Price با نام Field جدید، به عنوان محور X قرار گرفته است. سپس با استفاده از Function مربوط به Value، مقادیر منحصر به فرد Price به عنوان محور Y در نظر گرفته شده‌اند. در ادامه، Count بر اساس Country و Product Name انجام شده است count by Country, "Product Name". این دسته‌بندی که تعدادی را نیز مشخص می‌کند، در خود Chart نمایش داده نمی‌شود. اما در Bubble Chart، محور X، محور Y و همچنین تعدادی که بر اساس Country و Product Name دسته‌بندی شده، به عنوان حجم Bubble نمایش داده می‌شود. برای رسم یک Bubble Chart، نیازمند حداقل سه پارامتر آماری هستیم: مقدار محور X، مقدار محور Y و مقدار مربوط به حجم . Bubble یعنی حجم این حباب هایی که وجود دارد باید مشخص شود.

تا اینجا سعی شد مهم‌ترین Chart ها توضیح داده شوند تا درک نسبی از آن‌ها حاصل گردد. حتماً موارد را با Searchهای مختلف تمرین کنید. سعی کنید Search هایی بنویسید که خروجی آن‌ها جداول Multi-series، Single Series یا Time Series باشد و آن‌ها را به Chart های مختلف تبدیل نمایید.

دستورات مربوط به چارت ها

همان‌طور که پیش‌تر گفته شد، در قسمت بعدی درباره دستورات جدید صحبت خواهیم کرد. در ادامه، قصد داریم درباره Command مربوط به Chart صحبت کنیم.

دستور Chart

دستور Chart می‌تواند هر نوع Data Series را نمایش دهد و Chartی که از آن Data Series رسم می‌کند، در یک یا دو بُعد قرار می‌گیرد. زمانی که تصمیم به استفاده از این Command می‌گیرید، ابتدا باید مشخص کنید که کدام Field بر روی محور X قرار گیرد و از چه Function هایی می‌خواهید برای نمایش مقادیر محور Y استفاده نمایید.

اولین Field که پس از Over به کار می‌برید، بر روی محور X قرار می‌گیرد. زمانی که از OVER یا BY Clause استفاده می‌کنید، باعث می‌شود Data شما به Subgroup های مختلف تقسیم شود. در تصویری که مشاهده می‌کنید، چندین مثال را بررسی می‌کنیم.

در مثال اول، از Command مربوط به Chart استفاده شده، سپس از Function مربوط به Average و Field عددی Bytes استفاده شده است. پس از Function، از OVER و Field مربوط به Host استفاده شده است که باعث شده محور X، مقادیر Host ها باشد و خروجی Function مربوط به Average به عنوان مقادیر محور Y نمایش داده شود.

در مثال بعدی، مجدداً از Function مربوط به Average و OVER host استفاده شده و در نهایت، یک By Clause اضافه شده است که باعث ایجاد گروه‌های مختلف در Chart شده و امکان دسته‌بندی بر اساس Product Name Field را نیز در نمودار فراهم کرده است.

در مثال بعدی نیز از Linux Logs استفاده شده و از Command مربوط به Chart، Function مربوط به Count و Field مربوط به Vendor Action برای رسم محور X استفاده شده است. همان‌طور که مشاهده می‌شود، در خروجی رسم شده، محور X شامل Action هایی است که در آن Field وجود دارد و محور Y تعداد Log ها است که با استفاده از Function مربوط به Count شمارش شده و مقدار آن به عنوان محور Y نمایش داده می‌شود.

در این مثال نیز از By Clause استفاده شده که باعث شده Chart یک بُعد دیگر پیدا کند و همچنین بر اساس User Field که در By Clause استفاده شده، گروه‌بندی ایجاد شود.

می‌توان Syntax را نیز در این مورد تغییر داد. به عنوان مثال، اگر دقت کنید، Vendor Action Field به جای اینکه بعد از OVER به کار رود، OVER حذف شده و بعد از BY به کار رفته و سپس User Field استفاده شده است. اگر دقت کنید، Chart هیچ تغییری نکرده و همان Chart قبلی است، اما Syntax تغییر کرده است. این Option ای است که خود Command مربوط به Chart دارد و می‌توان برای ساده‌تر شدن استفاده از Command مربوط به Chart، به این نحو از Command استفاده کرد.

در دستور Chart، حداکثر می‌توان از دو By Clause یا دو Field برای تقسیم‌بندی استفاده کرد. دلیل اصلی آن این است که Command مربوط به Chart حداکثر می‌تواند دو بُعد را نمایش دهد.

در نمودارهایی مانند Bar Charts، زمانی که برخی مقادیر بسیار بزرگ‌تر از سایر مقادیر و آیتم‌ها هستند، ممکن است نمودار تا حدی خوانا نباشد. در این مواقع می‌توان از گزینه‌هایی مانند Stack Mode استفاده کرد و همچنین گزینه‌ای مانند Show Data Value را فعال نمود تا Value های موجود شفاف‌تر و بهتر دیده شوند.

در مثال بعدی، اگر به جدول خروجی دقت کنید، دو ستون آخر Other و Null هستند. در خصوص Other، نکته‌ای که وجود دارد این است که زمانی که از Command های Chart و Timechart استفاده می‌کنید، به صورت پیش‌فرض این دستورات ۱۰ نتیجه برتر Top را نمایش می‌دهند. این خروجی‌ها از نظر مقدار در بالای جدول قرار گرفته و نمایش داده می‌شوند و بقیه موارد در ستون Other نشان داده می شوند. در نمودار نیز یک Line برای Other و یک Line برای Null وجود دارد.

اما در خصوص Null؛ زمانی که Search ای ایجاد کرده و از Commandی استفاده می‌کنید، ممکن است Field هایی که مد نظر شما هستند، در تمام Log ها وجود نداشته باشند. برای مثال، من از Field مربوط به Item ID استفاده کردم. زمانی که به Statistics این Field مراجعه می‌کنم، مشاهده می‌شود که مثلاً ۷۲ درصد از Log های من این Field را دارند. طبیعی است که برخی Log ها این Field را نداشته باشند و باید جزو Null محسوب شوند. در Chart و Table، این موارد با ستون Null شناسایی می‌شوند. این مقادیر Other و Null به صورت پیش‌فرض نمایش داده می‌شوند. تنظیماتی وجود دارد که می‌توان از نمایش آن‌ها جلوگیری کرد. این تنظیمات در مثال بعدی قابل مشاهده است. از Option های useother و usenull استفاده شده و مقدار آن‌ها برابر با false قرار داده شده است. می‌توان f یا false را نوشت. با انجام این کار، دیگر ستون‌های Other و Null در Table نمایش داده نمی‌شوند. دقت کنید useother و usenull هم برای دستور Chart و هم برای دستور Timechart کاربرد دارند که پس از این بخش، مثال‌هایی از Timechart را نیز خواهیم دید.

نکته بعدی، Option دیگری با نام Limit است. پیش‌تر گفته شد که به صورت پیش‌فرض، دستورات Chart و Timechart ده نتیجه اول را نشان می‌دهند. با دستور Limit می‌توان این مقدار را کم یا زیاد کرد. به عنوان مثال، اکنون من آن را به ۵ تغییر داده‌ام، یعنی ۵ نتیجه نمایش داده شود. همان‌طور که در تصویر مشاهده می‌شود، ۵ ستون وجود دارد و فقط این پنج نتیجه در Chart من نمایش داده می‌شوند. زمانی که از Limit Option استفاده می‌شود، این Limit بر روی دومین جداکننده و روی دومین Field اعمال می‌گردد. برای مثال، در اینجا بر روی Product Name اعمال شده است.

دستور Timechart

دستور بعدی که با آن کار خواهیم کرد، دستور Timechart است. با استفاده از دستور Timechart می‌توان عملیات ریاضی و آماری بر روی Data انجام داد. در این دستور، همیشه محور X، محور زمان _time است و نمی‌توان آن را تغییر داد. ماهیت این دستور، ارائه نمودار بر اساس Time است. به وسیله این دستور می‌توان Trend مربوط به Data را بر اساس Time رسم کرد.

برای مثال، تصویری که مشاهده می‌کنید، Trend تعداد Log های موجود در این Source Type را نمایش می‌دهد. می‌توان با استفاده از By Clause که در Timechart حداکثر یک Field می‌توان در آن استفاده کرد گروه‌بندی انجام داد.

برای استفاده از Visualization هایی مانند Line Chart و Area Chart، بهترین دستور قابل استفاده، همین دستور Timechart است. حتی می‌توان از گزینه Format استفاده کرده و گزینه Multi-series Mode را فعال نمود. با این کار، نمودار ما همان‌طور که مشاهده می‌شود به چندین بخش تقسیم شده و بر اساس By Clause که دسته‌بندی را ایجاد کرده، موارد را در Chart جدا می‌کند و هر گروه را در قالب یک نمودار جدا نمایش می‌دهد.

در مثال بعدی، از Option مربوط به Span استفاده شده است. این Option در این دستور چیست و چه کاری انجام می‌دهد؟ به محور X دقت کنید. این محور، همان‌طور که گفتیم، در Timechart بر اساس Time است. اگر بخواهیم Interval های زمانی موجود را تغییر دهیم، باید از دستور Span استفاده کنیم. زمانی که این دستور استفاده نمی‌شود، به صورت پیش‌فرض، مقادیر به صورت روزانه Daily نمایش داده می‌شوند. اما اگر از Option مربوط به Span استفاده کنیم، می‌توانیم آن را بر روی مقادیری مانند ۱۲ ساعت ، ۵ دقیقه یا ۱۰ ساعت تنظیم نماییم. بر اساس اختصاراتی که در Fund 1 گفته شد، می‌توان زمان را در اینجا وارد کرد 12h ، , 5m, 10s و.... مهم این است که در این مرحله، کاربرد Span که برای تغییر Interval های محور X مشخص شده باشد را درک کنید.

سؤالی که وجود دارد این است که آیا می‌توان از Span در دستور Chart نیز استفاده کرد؟ بله، در دستور Chart هم می‌توان از Span استفاده نمود. اما Span در اینجا دیگر بر مبنای Time نیست. اگر به یاد داشته باشید، نمودار X ما در دستور Chart، فیلدی بود که بعد از OVER قرار می‌گرفت. اگر فیلدی که بعد از OVER قرار می‌گیرد، Numeric باشد و دارای یک دنباله باشد، می‌توان با استفاده از Option مربوط به Span، یک دسته‌بندی نیز در اینجا ایجاد کرد.

برای مثال، من اکنون Span را بر روی ۱۰۰ تنظیم کرده و از Field مربوط به Status استفاده کرده‌ام. Status فیلدی است که مقادیر آن معمولاً بین ۲۰۰ تا ۶۰۰ است. در اینجا دسته‌بندی‌ای ایجاد شده که مقادیر را ۱۰۰ تا ۱۰۰ تا جدا کرده و بر اساس این گروه‌بندی، محورX را می‌سازد. در این Example از Span 100 استفاده شده و از مقدار ۲۰۰ که مقادیر شروع می‌شوند، ۱۰۰ تا ۱۰۰ تا جدا کرده و مقادیر حاصل را درمحور X نمایش می‌دهد.

در دستور Timechart می‌توان از Function های ریاضی که در دستور Stats با هم یاد گرفتیم نیز استفاده کرد، مانند Sum، Avg، Maximum، Minimum. همچنین Option های usenull و useother نیز در Timechart کاربرد دارند.

در یک مثال دیگر، من از گزینه Trellis استفاده کرده‌ام. با فعال کردن این گزینه، تک Chart ای که داشتیم به چندین Chart مختلف تبدیل می‌شود که شاید باعث شود نمودارهای ما قابل فهم‌تر و خواناتر گردند.

همچنین Option مربوط به Overlay وجود دارد. زمانی که چندین نمودار در Timechart وجود دارد و این نمودارها روی هم قرار گرفته و خوانایی Chart را کم می‌کنند، می‌توان از Option مربوط به Overlay استفاده کرد. بر روی گزینه Format کلیک کرده و در قسمت Chart Overlay، مقدار یا Fieldی را که می‌خواهیم روی تمام نمودارها قرار بگیرد، انتخاب می‌کنیم. اکنون اگر این گزینه را بردارم، مشاهده می‌شود که خوانایی Chart تا حدی پایین است. اگر دوباره Field مورد نظرم را انتخاب کنم، مشاهده می‌شود که خوانایی تا حدی بهتر شد.

این ماژول نیز به پایان رسید. در این ماژول، دستورات و مفاهیم بسیار خوبی را یاد گرفتیم. سعی کردم تمام موارد و نکات ریز موجود را منتقل کرده و به صورت واضح و شفاف بیان کنم. همچنین برای من مهم است که شما زمانی که این ویدئو و این دوره‌های آموزشی را مشاهده می‌کنید، نحوه تفکر و کارکردن شما با Splunk و نگاهتان به این ابزار تغییر کرده و بهبود یابد. چرا که Splunk و ماژول‌هایی که در ادامه با آن‌ها کار خواهیم کرد کاملاً متفاوت از تمام تجهیزات و Security Solutions موجود است و اگر بخواهیم در این مسیر موفق شویم، لازم است تفکر و نگاهمان را نسبت به این Solution تغییر دهیم.

امیدوارم مواردی که در این ماژول بیان شد، به پیشرفت شما کمک کند. اگر مورد، سؤال یا مشکلی وجود داشت، حتماً با من در ارتباط باشید. خدانگهدار.

ماژول سه - Using Trendlines, Mapping, and Single Value Commands

زیرنویس عنوان

سلام. با Module سوم از دوره Splunk Fundamental 2 در خدمت شما هستم.در این Module، قرار است درباره نحوه استفاده از Command مربوط به Trendline و همچنین ایجاد یک Trendline، مطالبی را فرا بگیریم. پس از آن، درباره ایجاد Map در Visualization های Splunk صحبت خواهیم کرد و در نهایت، به دستورات Single Value دستوراتی که خروجی آن‌ها یک مقدار واحد است می‌پردازیم و بررسی می‌کنیم که از چه Visualization هایی می‌توانیم برای نمایش آن‌ها استفاده کنیم.

میانگین متحرک (Moving Average)

قبل از پرداختن به دستور Trendline در Splunk، بهتر است درباره مفهوم میانگین متحرک یا Moving Average صحبت کنیم.

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

میانگین متحرک ساده
میانگین متحرک وزنی
میانگین متحرک نمایی

در نتیجه، یکی از روش‌های مرسوم برای مشاهده روند تغییرات، استفاده از میانگین‌های متحرک است. در بازارهای مالی با استفاده از میانگین‌های متحرک، روند تغییرات قیمت محاسبه می‌شود و می‌توان برای این محاسبه از Moving Average های متنوعی استفاده کرد. به عنوان مثال، از میانگین متحرک ساده استفاده می‌شود. در این نوع از Moving Average که Simple Moving Average نامیده می‌شود، قیمت‌های چند دوره قبل با هم جمع شده و بر تعداد دوره‌ها تقسیم می‌شوند. حاصل این محاسبات، Simple Moving Average آن روز، برای روزهایی است که شما تعیین کرده‌اید برای آن Timeline که مشخص نموده‌اید: ۵ روز، ۱۰ روز یا هر تعداد روز مورد نیاز.

میانگین متحرک نمایی یا Exponential Moving Average نیز وجود دارد. در بازارهای مالی، زمانی که از این Moving Average استفاده می‌شود، قیمت‌های مربوط به تاریخ‌های اخیر، تأثیر بالاتری در محاسبه میانگین دارند.

با توجه به این توضیحات در خصوص Moving Average ها، توصیه می‌شود که مطالعه‌ای نیز بر روی مطالب این قسمت داشته باشید. گرچه این مطالب خارج از بحث Splunk است، تسلط بر این مفاهیم و مطالب آماری Statistical بسیار مفید خواهد بود تا بتوانید درک بهتری از Command های پیشرفته Splunk داشته باشید.

دستور Trendline در Splunk

با توجه به توضیحات مربوط به Moving Average، در Splunk دستوری با نام trendline وجود دارد که با استفاده از آن، می‌توان Moving Average را محاسبه کرده و همزمان بر روی Chart مشاهده نمود و امکان مقایسه فراهم شود. به عنوان مثال، در تصویری که مشاهده می‌کنید، من با استفاده از Command مربوط به timechart بر روی Log های مورد نظرم، Chartی ایجاد کرده‌ام که در آن، مجموع Price Field با عنوان Sell نمایش داده می‌شود. سپس، با استفاده از دستور trendline و به‌کارگیری Simple Moving Average ، میانگین متحرک مربوط به Sell را محاسبه کرده‌ام و بر روی Chart نمایش داده‌ام. نکات مهم در خصوص این Command عبارتند از Syntax این Command و مفهوم دوره زمانی که می‌خواهیم Moving Average بر روی آن محاسبه شود.

در مثال مربوط به تحلیل تکنیکال اشاره شد که میانگین متحرک برای Price محاسبه می‌شود و بر اساس روزهای گذشته هر تعداد روزی که نیاز باشد صورت می‌گیرد؛ برای مثال، Simple Moving Average قیمت در ۵ روز گذشته یا ۲۰ روز گذشته. به طور قطع، در Splunk نیز هنگام استفاده از این دستور، باید مشخص شود که این میانگین متحرک در چه Period ای محاسبه گردد.

در بازارهای مالی Financial Markets، دوره زمانی بر اساس روز مشخص می‌شد مثلاً ۵ روز، ۲۰ روز، ۳۰ روز. در Splunk باید تعداد Event مشخص شود. Period در اینجا بر اساس تعداد Event های یا نقاط داده قبلی تعریف می‌شود.

به عنوان مثال، در Chartی که در Image مشاهده می‌شود، ابتدا فرض کنید خط سبز که نمایانگر Trend است و با دستور trendline رسم شده، وجود ندارد. در نمودار مشاهده شده، از نمودار میله‌ای Bar Chart استفاده شده که با استفاده از دستور timechart رسم گردیده است و Span مساوی دو ساعت span=2h تنظیم شده است. این تنظیم باعث می‌شود هر میله موجود در نمودار، نمایانگر یک بازه دو ساعته باشد. یعنی اکنون دستور timechart ستون‌هایی را رسم می‌کند که هر کدام مربوط به یک بازه دو ساعته هستند یعنی یک گروه‌بندی دو ساعته ایجاد شده و Event هایی که در هر بازه دو ساعته قرار می‌گیرند، مقادیر Price Field آن‌ها با هم جمع شده و در قالب یک ستون نمایش داده می‌شود.

اکنون در ستون آخر، اگر نشانگر موس بر روی آن قرار گیرد، مشاهده می‌شود که مربوط به ۹ مارس، ساعت ۵:۳۰ است و ستون قبلی مربوط به ساعت ۳:۳۰ است. یعنی از ساعت ۳:۳۰ به بعد تا ۵:۳۰، مقادیر Price Field مربوط به Event ها با هم جمع شده و در یک ستون نمایش داده می‌شود.

حال، اگر در این State در ستون آخر بخواهیم Simple Moving Average آن را محاسبه کنیم، ابتدا باید یک Period برای آن مشخص شود تا تعیین گردد Simple Moving Average در چه دوره‌ای محاسبه شود. اشاره شد که Period در اینجا بر اساس تعداد Event یا ستون‌های قبلی است، در حالی که بازارهای مالی نیازمند یک Period زمانی هستند. یعنی آنجا باید بگوییم چند روز، چند ساعت، چند دقیقه اما اینجا باید بر اساس تعداد Event یا تعداد ستون هایی که قبل از آن وجود دارد و باید محاسبه شود، از دستور Trendline استفاده کنیم.

برای استفاده از دستور trendline، در ادامه و پس از ذکر نوع میانگین متحرک به عنوان مثال، SMA، باید Period مشخص شود که در اینجا مقدار ۲ تعیین شده است. می‌توانستیم مقدار ۲۰ یا ۱۰ نیز تعیین کنیم. عدد Period باید بین ۲ تا ۱۰۰۰۰ باشد مقدار بیشتر مجاز نیست و کمتر از ۲ نیز مفهومی ندارد.

اکنون که Period برابر ۲ تعیین شده، در Chart موجود، اگر بخواهیم برای این ستون Simple Moving Average را محاسبه کنیم، مقدار Sell موجود در این ستون با مقدار ستون قبلی جمع شده، بر ۲ تقسیم می‌شود و حاصل، خط Trendline ما را تشکیل می‌دهد.

اگر Period بر روی ۱۰ تنظیم می‌شد، زمانی که می‌خواستیم در اینجا Simple Moving Average را محاسبه کنیم، لازم بود مقادیر ستون فعلی و ۹ ستون قبلی با هم جمع شده و عدد حاصل بر ۱۰ تقسیم می‌شد. در آن صورت، خط Trend ما تغییر می‌کرد. اکنون آن را بر روی ۱۰ تنظیم می‌کنم و Enter می‌زنم. همان‌طور که مشاهده می‌شود، Trend ما تغییر کرد و بر اساس Period برابر با ۱۰ محاسبه می‌شود. امیدوارم که توضیحات واضح بوده باشد.

اشاره شد که به جای SMA می‌توان EMA یا WMA نیز قرار داد. همان‌طور که مشاهده می‌شود، Trendline ما تغییر کرده است. من در قسمت Format از Chart Overlay استفاده کرده بودم و Trend را در حالت Overlay قرار دادم تا بتوانم آن را واضح‌تر در Chart مشاهده کنم. اگر این گزینه غیرفعال شود، ظاهر ممکن است تا حدی متفاوت گردد.

در مثال دیگر، از Field مربوط به Byte استفاده شده است و به عنوان Traffic Volume محاسبه می‌شود. در این دستور، ابتدا timechart بر اساس مجموع مقادیر Byte در هر بازه دو ساعته، Traffic Volume را رسم می‌کند و سپس بر اساس sma2، میانگین متحرک هر ستون را محاسبه کرده و بر روی خط Trend نمایش می‌دهد.

نکته‌ای که چندین بار به آن اشاره شد، Period ای است که اینجا بعد از نام Function مانند SMA قرار می‌گیرد. اگر این Period مشخص نشود، Function به رنگ مشکی درآمده و دستور اجرا نشده و Error دریافت می‌شود. بنابراین، توجه داشته باشید که باید عددی در اینجا قرار دهید که این عدد بر اساس Scenario شما مشخص می‌شود. این توضیحات مربوط به دستور trendline بود. جزئیات بیشتری وجود ندارد و شما می‌توانید با استفاده از مباحث مطرح شده، نیازهای خود را برآورده سازید و از Trendline ها نیز در Dashboard خود استفاده کنید.

استفاده از Map در Visualization

در بخش بعدی، درباره نمایش Data بر روی Map های مختلف صحبت خواهیم کرد و نحوه استفاده از Geographical Maps برای Visualization را بررسی خواهیم کرد. در این قسمت، درباره Map ها صحبت می‌کنیم. گاهی اوقات نیاز است که Data خود را بر روی Map های جغرافیایی نمایش دهید. به عنوان مثال، تصور کنید Log هایی دارید که حاوی Source IP های Public هستند و قصد دارید با استفاده از این IP های Public، یک Visualization شبیه به Map ایجاد کنید تا مشخص شود هر IP مربوط به کدام موقعیت جغرافیایی است و این موضوع در Map کاملاً مشخص باشد. این کار به راحتی با استفاده از Splunk امکان‌پذیر است.

در Splunk دو نوع Map اصلی وجود دارد Cluster Map و Choropleth Map نکته بسیار مهم این است که Log ی که قصد دارید برای ایجاد Map از آن استفاده کنید، باید شامل چندین Field مشخص باشد. فیلدهایی مانند City, Country, Region, Longitude, Latitude. معمولاً باید این Field ها را داشته باشد. اما اگر دقت کرده باشید، تعداد کمی از Log ها به صورت پیش‌فرض شامل این Field ها هستند. Log هایی مانند Log مربوط به Firewall FortiGate, FMC یا حتی Log های Windows و Linux این Field ها را ندارند و فاقد این Field ها هستند تا بتوان با استفاده از آن‌ها Map رسم کرد. راه حل چیست و چه کاری می‌توان انجام داد تا این Field ها به Log ما اضافه شوند؟

دستور iplocation

دستوری با نام iplocation وجود دارد که با استفاده از آن و Field حاوی IP های Public، می‌توان Field های مورد نیاز برای Visualization مربوط به Map را ایجاد کرد. در این Log های موجود، Fieldی با نام Client IP وجود دارد که تمام IP های Public موجود در این Field قرار دارند. می‌توان با استفاده از این دستور به همراه این Field، Field هایی مانند City, Country, Region را به Log اضافه کرد. همان‌طور که مشاهده می‌شود، اکنون Field مربوط به City اضافه شده است، همچنین Country, Lat, Long و سایر Field های مورد نیاز برای بصری‌سازی در اینجا موجود هستند.

دستور geostats برای Cluster Map

پس از استفاده از دستور iplocation و ایجاد Field های مورد نیاز برای Visualization مربوط به Map، می‌توان از دستور geostats برای محاسبه Function های آماری و برای Rendering و ایجاد Cluster Map استفاده کرد.

این دستور نیز دارای Syntax مشخصی است که در این تصویر قابل مشاهده است. ابتدا دستور geostats استفاده می‌شود، سپس باید latfield و longfield مشخص شوند در صورت نیاز، پس از آن، Function مورد نظر برای محاسبه مانند count و در انتها، By Clause برای گروه‌بندی قرار می‌گیرد.

برای مشاهده یک مثال کامل، به این تصویر توجه کنید. ابتدا از دستور iplocation استفاده شده که به وسیله آن، دو Field مهم long و lat به دست می‌آیند. اگر این Field ها از پیش در Log شما وجود داشته باشند، نیازی به استفاده از iplocation نیست. بسیار مهم است که نام این Field ها دقیقاً lat و long باشد. اگر نام‌ها دقیقاً همین باشند، دیگر نیازی به استفاده از Option های latfield و longfield در دستور geostats نیست. اگر نام این Field ها متفاوت بود یا حتی با حروف بزرگ نوشته شده بود، باید با استفاده از این دو Option موجود در دستور geostats، نام Field های صحیح را معرفی کنید.

پس از دستور iplocation، دستور geostats به کار رفته است با Option مربوط به globallimit=4. یعنی در خروجی 4 ستون خواهیم داشت. همچنین با استفاده از By Clause، گروه‌بندی بر اساس User ها ایجاد شده است. سپس Function مربوط به count و در انتها By Clause by user قرار دارد.

اگر نشانگر Mouse بر روی هر قسمت Map قرار گیرد، اطلاعاتی نمایش داده می‌شود، مانند موقعیت جغرافیایی و User هایی که از آن موقعیت جغرافیایی Login کرده‌اند. نوع Visualization نیز بر روی Cluster Map تنظیم شده است. دستور geostats فقط با Visualization از نوع Cluster Map کار می‌کند و با سایر انواع Map سازگار نیست. درباره نوع دیگر Map در ادامه صحبت خواهیم کرد.

بنابراین، تا اینجا نحوه استفاده از geostats را آموختیم و به راحتی می‌توان از آن استفاده کرد. نکات مهم آن را فراموش نکنید، مانند نام دقیق Field های lat و long و استفاده از دستور iplocation در صورت نیاز.

دستور geom برای Choropleth Map

نوع Map بعدی که درباره آن صحبت خواهیم کرد، Choropleth Map است. در این نوع Map، با استفاده از سایه‌ها و رنگ‌هایی که از کمرنگ به پررنگ متغیر هستند، می‌توان معیارهای نسبی و آمارها را نمایش داد. مناطق جغرافیایی نمایش داده شده در این نقشه، از پیش در Database های داخلی Splunk ثبت شده‌اند و می‌توان تنها با استفاده از یک Field که نام Country را مشخص می‌کند، Map مورد نظر را رسم نمود.

این دستور نیز Syntax مشخصی دارد که در تصویر قابل مشاهده است. ابتدا دستور geom استفاده می‌شود، پس از آن، باید featureCollection ذکر شود و در انتها، با استفاده از Option مربوط به featureIdField، نام Fieldی ذکر می‌شود که حاوی نام Country ها است.

به عنوان مثال، در این دستوری که نوشته شده، پس از دستور geom، کلمه ای به کار رفته که به فایلی در Splunk اشاره دارد که در آن فایل، تمام کشورهای جهان به همراه مرزها و مشخصات جغرافیایی آن‌ها ثبت شده و ما از آن استفاده می‌کنیم. می‌توان به جای این String، از geom_us_states استفاده کرد که این مختص کشور آمریکا بوده و تمام ایالت‌ها و نقاط جغرافیایی آن‌ها را شامل می‌شود. سپس، با استفاده از Option مربوط به featureIdField، نام Fieldی مثلاً Country مشخص می‌شود که حاوی نام Country های ثبت شده در Log ما است. بنابراین، برای استفاده از geom_world_countries، باید در Log های ما Fieldی وجود داشته باشد که نام کشورها در آن مشخص شده باشد.

اکنون بر روی دکمه Search کلیک کرده تا Map را مشاهده کنیم. اگر دقت کنید، در Mapی که نمایش داده می‌شود، برخی کشورها با رنگ پررنگ‌تر و برخی با رنگ‌های کمرنگ‌تر نمایش داده می‌شوند. مشخص است که رنگ پررنگ‌تر به معنی وجود تعداد Log های بیشتر مربوط به آن کشور با توجه به فیلد Country است.

در مثال قبلی که از Cluster Map استفاده شد، قصد دارم Search آن را به نحوی تغییر دهم که برای Choropleth Map مناسب باشد. همان‌طور که در این تصویر مشاهده می‌شود، Search را به نحوی تغییر دادم که ابتدا از دستور iplocation استفاده شده، موقعیت‌های جغرافیایی استخراج گردیده و Field مربوط به Country ایجاد شده است. سپس، با استفاده از دستور stats ، بر اساس Country گروه‌بندی انجام دادم و پس از آن، با دستور geom و با استفاده از فیلد Country آن Map مورد نظرم را رسم کنم. تا اینجا درباره ایجاد Map ها نیز صحبت شد و نحوه رسم Map فرا گرفته شد. در قسمت بعدی، درباره بصری‌سازی Single Value ها صحبت خواهیم کرد.

بصری‌سازی Single Value ها

اگر خروجی Search شما یک Single Value باشد، می‌توانید با استفاده از Visualization های مربوط به Single Value، Option های مختلفی برای بصری‌سازی در اختیار داشته باشید که تمام این Option ها باعث نمایش بهتر Data شما می‌شوند. اما اگر از این Visualization ها استفاده کنیم در حالی که خروجی Search ما یک Single Value نباشد، Visualization انتخاب شده که مخصوص Single Value است تنها مقدار اولین Cell در آن Table را نمایش می‌دهد.

در تصویری که مشاهده می‌کنید، Search Output من شامل یک Single Value است که تعداد Log ها را نمایش می‌دهد و از Visualization Radial Gauge استفاده شده که مخصوص Single Value ها است. همان‌طور که مشاهده می‌شود، Visualization بسیار ساده، شیک و کاربردی است که در قسمت Format می‌توان Style آن را نیز تغییر داد. حتی در قسمت Color Range، می‌توان محدوده رنگ‌هایی را که در این Visualization نمایش داده می‌شود، تغییر داد. به عنوان مثال، الان محدوده خروجی بین ۱۰۰۰ تا ۱۰۰۰۰ است و می‌توانیم این Range را تغییر دهیم. برای تغییر رنگ، علاوه بر استفاده از Option مربوط به Format، می‌توان با استفاده از Command مربوط به rangemap یا مشابه آن رنگ‌ها را مشخص کرد تا Visualization من در آن رنگ‌های تعیین شده قرار گیرد.

زمانی که در Search از By Clause استفاده می‌کنیم، می‌توان در Visualization نوع Gauge از گزینه Trellis استفاده کرد. با فعال شدن این گزینه، چندین Visualization از نوع Gauge نمایش داده می‌شود که هر کدام مقادیر مربوط به یکی از گروه‌های ستون اول را نشان می‌دهد.

می‌توان از Visualization های دیگری نیز استفاده کرد، به عنوان مثال، Visualizationی با نام Single Value . Search موجود، خروجی‌ای معادل یک Single Value دارد که مقدار آن قابل مشاهده است. با استفاده از Option مربوط به Format، یک Caption برای آن در نظر گرفته شده است و با استفاده از گزینه Number Format، یک Unit برای آن در نظر گرفته شده است که این Unit قبل یا بعد از مقدار Value نمایش داده می‌شود. می‌توان با استفاده از گزینه‌های مربوطه، تعداد ارقام اعشار را مشخص کرد. همچنین، می‌توان با استفاده از Option مربوط به Color، رنگ را تغییر داده و از رنگ‌بندی استفاده کرد و برای رنگ‌بندی، Range هایی مشخص کنیم که اگر مقدار آن Single Value خروجی Search، در هر یک از این محدوده‌ها قرار گیرد، رنگ مورد نظر نمایش داده شود. می‌توان از قسمت Color Mode، نوع رنگ‌بندی را نیز مشخص کنیم. رنگ Background یا رنگ خود Number در این نوع Visualization، Option های فوق‌العاده‌ای در دسترس است.

استفاده از Trend و Sparkline

مثال بعد را مشاهده کنیم. در این مثال از دستور timechart استفاده شده است و با استفاده از Format ، گزینه‌های Trend و Sparkline فعال شده‌اند. با فعال کردن Trend ، کنار عدد اصلی، یک فلش رو به بالا یا پایین به همراه یک عدد نشان‌دهنده تغییر نمایش داده می‌شود. هنگام فعال‌سازی این گزینه، Option های دیگری مانند Show Trend In نمایش به صورت Percentage یا عدد وجود دارد. سپس، در قسمت Compare To ، باید مشخص شود که عدد خروجی Search با مقدار مربوط به چه بازه Time پیشین مقایسه شود تا Trend افزایشی یا کاهشی مشخص گردد. پس از این، گزینه Caption وجود دارد که می‌توان متنی را در آن وارد کرد. سپس، گزینه Show Sparkline را داریم که اگر فعال باشد، در قسمت پایین Visualization، یک نمودار کوچک Chart نمایش داده می‌شود که با توجه به آن می‌توان Trend را واضح‌تر تشخیص داد.

با توجه به مطالب بیان شده در این قسمت، می‌توان با استفاده از این موارد، Visualization بهتری برای Single Value ها داشته باشیم و خروجی و Data ما خواناتر و قابل فهم‌تر باشد.

نمایش مجموع Total در نتایج

در این ماژول، هنوز یک مطلب باقی مانده که باید درباره آن صحبت کنیم. زمانی که Search Output شامل ستون‌های Numeric است و نیاز به نمایش مجموع آن ستون‌ها وجود دارد، می‌توان از چندین Option مختلف استفاده کرد که یکی از Option های دم دستی ، استفاده از گزینه Format است.

زمانی که در تب Statistics هستیم، می‌توان با انتخاب گزینه Format و رفتن به Summary Section، گزینه Total را فعال کرد. پس از فعال‌سازی، مشاهده می‌شود که سطری اضافه می‌گردد که مجموع هر ستون را نمایش می‌دهد. همچنین، می‌توان از گزینه درصد استفاده کرد که سطری حاوی درصدها را مطابق با خروجی نمایش می‌دهد. اما همان‌طور که اشاره شد، این یک Option دم دستی است و فاقد برخی ویژگی‌ها Features پیشرفته‌تر می‌باشد.

دستور addtotals

اگر بخواهیم محاسبه Total را به صورت حرفه‌ای‌تر انجام دهیم و بتوانیم مجموع سطرها و ستون‌های مورد نیاز را محاسبه کنیم، می‌توان از Command مربوط به addtotals یا مشابه آن استفاده کرد. این دستور نیز Syntax مشخصی دارد. تصویری که مشاهده می‌کنید، Syntax دستور addtotals است.

پس از نوشتن این دستور، Option مربوط به row وجود دارد که به صورت Default، مقدار آن True است. زمانی که این Option برابر با True باشد، ستونی جدید ایجاد می‌شود که مقادیر آن حاصل جمع مقادیر هر سطر هستند.

با Option مربوط به fieldname می‌توان نام آن ستون مجموع سطرها را مشخص کرد. بعد از آن، Option مربوط به col وجود دارد که به صورت Default، مقدار آن False و غیرفعال است. زمانی که این Option برابر با True فعال باشد، سطری جدید ایجاد می‌شود که حاصل جمع مقادیر هر ستون در آن سطر نوشته می‌شود و می‌توانید Total هر ستون را مشاهده کنید.

پس از این موارد، Option های labelfield و label وجود دارند. با استفاده از Option مربوط به label، می‌توانیم نام برچسب سطری را که با Option مربوط به col ایجاد شده را مشخص کنیم و با استفاده از Option مربوط به labelfield، می‌توانیم مشخص کنیم که آن نام Label در کدام ستون از جدول قرار گیرد. اکنون با بررسی مثال، موضوع دقیق‌تر روشن می‌شود. در انتهای این ویدئو ، دو مثال از دستور addtotals وجود دارد که آن‌ها را بررسی می‌کنیم.

مثال 1: ابتدا از Command مربوط به Chart استفاده شده و سپس از addtotals. پس از دستور addtotals، با استفاده از fieldname ، نام ستون مربوط به مجموع سطرها مشخص شده است. همان طور که در سینتکس توضیح دادم row به صورت پیش‌فرض True است و اینجا آن را تایپ نکردم. سپس، با استفاده از Option مربوط به col، سطری ایجاد می‌شود که برچسب آن برابر با Total per Category است و این برچسب در ستون Product Name قرار می‌گیرد.

خروجی را بررسی کنیم. ستونی با نام Total per Product . در انتهای جدول ایجاد شده که حاصل جمع مقادیر هر سطر را نمایش می‌دهد و در انتها، سطری با برچسب Total per Category ایجاد گردیده و این برچسب در ستون Product Name قرار گرفته است.

مثال 2: در مثال بعدی، ابتدا با استفاده از دستور stats، عملیات آماری انجام شده است. سپس، با استفاده از دستور addtotals، ابتدا row=f تنظیم شده یعنی ستونی برای مجموع سطرها ایجاد نمی‌شود و سپس col=t تنظیم شده که باعث ایجاد یک سطر برای مجموع ستون‌ها می‌شود. و در انتها، با استفاده از Option مربوط به labelfield، محل قرارگیری Labelو Host و مقادیر مجموع ستون‌ها Byte مشخص شده است.

بنابراین، با توجه به این مثال‌ها، می‌توان سناریوهای دیگری را نیز پیاده‌سازی کرد. این آخرین نکته مربوط به فصل ۳ بود. امیدوارم این مطالب به وضوح بیان شده باشد و شما نیز موارد را تمرین نمایید، زیرا در فصل بعدی، مطالب جدیدتر و پیچیده‌تری ارائه خواهد شد. با پیشروی در دوره، حجم و پیچیدگی مطالب افزایش می‌یابد. مزیت دوره‌های استاندارد Splunk این است که مطالب مهم در بخش‌های مختلف تکرار می‌شوند و به صورت ناخودآگاه، برخی از مطالب مهم در ذهن تثبیت می‌گردند و می‌توان آن‌ها را به خاطر سپرد. از همراهی شما تا این مرحله سپاسگزارم. تا ویدیوهای آینده، خدانگهدار.

ماژول چهار - Filtering Results and Manipulating Data

زیرنویس عنوان

سلام. با Module چهارم از دوره Splunk Fundamentals 2 در خدمت شما هستم. در این Module، قرار است نحوه استفاده از دستور eval را بررسی کنیم. همچنین، درباره Filtering و ویرایش Data و Result هایی که در خروجی Search وجود دارد، صحبت خواهیم کرد. در انتهای ویدئو، نحوه استفاده از Command های search، where و fillnull را فرا خواهیم گرفت.

دستور eval

مبحث اصلی این ماژول دستور eval است. اهمیت این دستور به حدی است که حتی در فصل‌های آینده، دوره‌های آتی و به‌خصوص اگر قصد شرکت در دوره SIEM را داشته باشید، تسلط بر آن ضروری است. افرادی که SIEM یا به‌طور کلی Splunk را Tune می‌کنند و در حوزه Data فعالیت دارند، یکی از اصلی‌ترین دستوراتی که با آن کار می‌کنند، Command مربوط به eval است.

بنابراین، به‌خاطر داشته باشید که این Module یکی از مهم‌ترین Module های دوره Fundamentals 2 محسوب می‌شود. ما به‌وسیله دستور eval می‌توانیم روی Field-Value ها و Value هایی که در Table خروجی Search نمایش داده می‌شود، محاسباتی انجام دهیم و حتی آن‌ها را متناسب با نیاز خود ویرایش کنیم.

همان‌طور که در تصویر مشاهده می‌کنید، این Command نیز دارای Syntax مشخصی است. همچنین، Function های بسیار متفاوت و کاربردی دارد که با برخی از آن‌ها در این Module آشنا خواهیم شد. زمانی که از این Command استفاده کرده و روی یک Field، Function خاصی را اعمال می‌کنیم، خروجی آن می‌تواند در یک Field جدید ثبت شود یا در Field ی که از قبل موجود است، بازنویسی گردد.

عدم تاثیرگذاری eval روی لاگ اصلی

نکته‌ای که وجود دارد و در مثال‌ها نیز تکرار خواهد شد، این است که ویرایش‌هایی که با استفاده از دستور eval در زمان جستجو انجام می‌دهید، فقط در سطح View اعمال می‌شود و هیچ تغییری در Log اصلی ایجاد نمی‌کند و چون در زمان search time دارد انجام می شود تنها بر نحوه نمایش Data در UI تأثیر می‌گذارد. حتی اگر از دستور eval در Calculated Field هایی که در پس‌زمینه اجرا می‌شوند استفاده کنید، این Calculated Field ها تنها در زمان اجرای Search محاسبه شده و خروجی آن‌ها نمایش داده می‌شود، بدون آنکه Log اصلی تغییر کند.

syntax دستور eval

Syntax این Command به این صورت است که پس از eval، نام fieldname مورد نظر ذکر می‌شود. این Field می‌تواند یک Field جدید باشد یا یک Field موجود در Log ها. اگر Field از قبل وجود داشته باشد، Result این Expression در آن Field بازنویسی می‌شود. اگر وجود نداشته باشد، Field جدید ایجاد شده و مقادیر مرتبط در آن ثبت می‌گردد. پس از نام Field، علامت مساوی = و سپس Expression و Function های مورد نظر قرار می‌گیرد. در مثال ها این را با هم خواهیم دید.

Case-sensitive بودن Field-Value های دستور eval

نکته بسیار مهم دیگر این است که Field-Value هایی که در این دستور به‌کار می‌روند، Case-sensitive هستند همان‌طور که در ابتدای دوره Fund 2 نیز اشاره شد. زمانی که در این دستور از Field-Value ها استفاده می‌کنید، باید آن‌ها را داخل Double Quote قرار دهید تا به‌عنوان Value مقدار شناخته شوند. اما اگر از Double Quote استفاده نکنید یا حتی از Single Quote علامت نقل قول تکی ' استفاده کنید، عبارت به‌عنوان Field Name در نظر گرفته می‌شود.

در Syntax ای که مشاهده می‌کنید می‌توان چندین Expression را با استفاده از کاما , از هم جدا کرد و به‌صورت همزمان تعریف نمود مانند fieldname1 = expression1, fieldname2 = expression2, .... در مثال‌ها با این قابلیت بیشتر آشنا خواهیم شد. هدف فعلی، درک Concept کلی و به‌خاطر سپردن نکات کلیدی مانند Case-sensitive بودن است.

با استفاده از دستور eval، می‌توان Calculated Expression ها را تعریف کرد و از اپراتورهای ریاضی مانند جمع ، تفریق ، ضرب ، تقسیم ، درصد ، اپراتورهای منطقی NOT, AND, OR و اپراتورهای مقایسه‌ای مانند بزرگتر, کوچکتر, مساوی, نامساوی , LIKE استفاده نمود. در ادامه مثال‌هایی از کاربرد این اپراتورها را بررسی خواهیم کرد.

مثال اول: در مثالی که در تصویر مشاهده می‌کنید، ابتدا بر روی Log های Web Server لینوکسی، با استفاده از دستور stats و Function مربوط به sum، مجموع مقادیر Field مربوط به Bytes برای هر Client IP محاسبه و گروه‌بندی شده است. خروجی این بخش شامل دو ستون clientIp و Bytes است که مجموع Byte های ثبت‌شده برای هر Client IP را نشان می‌دهد.
سپس، با استفاده از دستور eval، Field جدیدی به نام bandwidth ایجاد شده است این Field از قبل وجود نداشته. مقادیر داخل این Field، حاصل تقسیم مقدار Field مربوط به Bytes که در مرحله قبل با دستور stats ایجاد شد بر حاصل‌ضرب 1024 * 1024 است. خروجی نهایی در ستون bandwidth نمایش داده می‌شود که در ستون آخر آورده شده است. این مثال، کاربرد ساده‌ای از eval برای انجام محاسبات ریاضی و ایجاد Field جدید را نشان می‌دهد و پیچیدگی خاصی ندارد. در ادامه، مثال‌های پیچیده‌تر و کاربرد Function های مختلف که در این CheetSheet آمده را بررسی خواهیم کرد. Function هایی مانند if و random و... .

مثال دوم: در این مثال که بر روی Log های FMC یک Firewall سیسکویی اجرا شده، ابتدا با استفاده از دستور eval، حاصل جمع دو Field به نام‌های bytes_in و bytes_out محاسبه و در Field جدیدی به نام Bytes ذخیره شده است. سپس، با استفاده از دستور stats و Function مربوط به sum، مجموع مقادیر Field جدید Bytes برای هر مقدار از Field مربوط به app محاسبه و در ستون SumBytes نمایش داده شده است. خروجی تا این مرحله شامل دو ستون app و SumBytes است.
در نهایت، مجدداً با دستور eval، مقدار bandwidth محاسبه شده است. صحت فرمول محاسبه bandwidth در این مثال مد نظر نیست، بلکه هدف آشنایی با انجام عملیات ریاضی با دستور eval است. در این محاسبه، مقدار ستون SumBytes بر حاصل‌ضرب 1024 * 1024 تقسیم شده است.

مثال سوم: در مثال بعدی که اکنون در تصویر مشاهده می‌کنید، تنها تفاوتی که با مثال قبل دارد این است که زمانی که با استفاده از دستور eval، مقدار bandwidth محاسبه می‌شود، از تابع round استفاده شده است. حاصل عملیات که بر روی sumbyte انجام می‌شود، به round function ارسال شده است و این تابع، مقداری را که به آن ارسال می‌شود، بر اساس تعداد اعشاری که مشخص می‌کنیم، محاسبه کرده و در فیلد bandwidth ثبت می‌کند. پس از آن، با استفاده از دستور sort، خروجی مورد نظر مرتب شده است و با استفاده از دستور rename، نام ستون تغییر داده شده و در آخر، sumbyte با استفاده از دستور field حذف شده است تا در جدول نمایش داده نشود. در این مثال با تابع round آشنا شدیم که نحوه استفاده از آن نیز در این مثال قابل مشاهده است. زمانی که می‌خواهیم از این تابع استفاده کنیم، باید تعداد رقم اعشار مورد نظر را مشخص کنیم دو، چهار، پنج یا هر تعدادی که نیاز باشد. اکنون در اینجا مقدار ۲ تعیین شده است. اگر مثال قبلی را ببینیم، تعداد اعشار بسیار زیاد بود و خوانایی جدول را کاهش داده بود. ما با استفاده از دستور round و تعیین رقم اعشار برابر با ۲، خروجی را به نحوی ویرایش کردیم که علاوه بر round شدن، تنها دو رقم پس از ممیز نمایش داده شود.

مثال چهارم: در مثال بعدی که در تصویر مشاهده می‌کنید، ابتدا Log هایی انتخاب شده‌اند که حتماً فیلد Product Name را داشته باشند و مقدار فیلد Action آن‌ها برابر با purchase باشد. سپس، با استفاده از دستور stats، مجموع فیلد Price در ستون TP و مجموع فیلد sale_Price در ستون TSP نمایش دادیم و با استفاده از By Clause، خروجی گروه‌بندی شده است. پس از آن، با استفاده از دستور eval، Field جدیدی به اسم discount ساخته شده است که در بخش Expression آن، از تابع round استفاده شده و یک عملیات ریاضی انجام شده است. این عملیات ریاضی بر اساس ستون‌هایی که توسط دستور stats ایجاد شده‌اند، صورت می‌گیرد و خروجی این Expression در فیلد discount قرار می‌گیرد. پس از آن، با استفاده از دستور sort ، خروجی بر اساس ستون discount مرتب می‌شود. و دوباره پس از آن، از دستور eval استفاده شده که بر روی فیلد discount تغییراتی اساسی اعمال می‌شود؛ به طوری که در Expression نوشته شده، یک علامت درصد % در انتهای آن قرار می‌گیرد تا در جدول، عدد به همراه علامت درصد نمایش داده شود. و در نهایت، با استفاده از دستور rename، نام ستون‌ها تغییر داده می‌شود.

اکنون جدول نهایی را بررسی می‌کنیم. مهم‌ترین ستون، discount است که همان‌طور که مشاهده می‌شود، علامت % بعد از عدد وجود دارد. در این مثال نیز آموختیم که اگر بخواهیم یک String را به انتهای یک Field Value اضافه کنیم، چگونه باید این کار را انجام دهیم. در مثال‌های آینده نیز مجدداً به این موضوع پرداخته خواهد شد. اما در این مثال، دوباره تابع round function بررسی شد و نحوه افزودن علامت % یا هر کاراکتر مورد نیاز دیگر به انتهای یک Field فرا گرفته شد.

استفاده همزمان از دستور sort و eval

زمانی که قصد دارید از eval به عنوان اضافه کردن یک کاراکتر به یک فیلد استفاده کنید یک نکته و همزمان از دستور sort استفاده کنید، یک نکته بسیار مهم وجود دارد. اگر ابتدا از دستور eval استفاده کرده و کاراکتر مربوطه را اضافه کنید و سپس دستور sort را به کار ببرید، خروجی چندان جالبی نخواهید داشت و Sort به معنی واقعی اتفاق نخواهد افتاد. چرا؟ زیرا در لحظه اعمال دستور sort، کاراکتری که اضافه کرده‌اید، وجود دارد. شما ابتدا باید Sort را انجام دهید و پس از انجام شدن Sort، کاراکتر مورد نظر را اضافه کنید. در مثال قبلی که داشتیم نیز، ابتدا Sort انجام شد و سپس کاراکتر اضافه گردید. این باعث می‌شود آن کاراکتر در فرآیند Sort نقشی نداشته باشد و مرتب‌سازی به بهترین نحو انجام شود.

تابع tostring

در مثال بعدی که مشاهده می‌کنید، هدف آشنایی با Function مربوط به tostring است. ابتدا با استفاده از دستور stats بر روی Log های مورد نظر، یک سری عملیات ریاضی انجام شده و چندین ستون در خروجی مشاهده می‌شود که حاصل دستور stats هستند. سپس، با استفاده از دستور eval، Fieldی با نام Average Last Sales ایجاد شده است. برای مقداردهی به این Field، ابتدا یک علامت Dollar Sign $ و پس از آن علامت Plus Sign + و سپس از دستور tostring استفاده شده است.

ما به وسیله استفاده از دستور eval و تابع tostring ، می‌توانیم Field هایی را که عددی هستند، به String تبدیل کنیم. زمانی که می‌خواهیم از این Function استفاده کنیم، دو آرگومان دارد X و Y. اگر به مستندات Splunk مراجعه کنیم، در بخش X باید مقدار یا فیلدی را مشخص کنیم که می‌خواهیم به String تبدیل شود. در بخش Y که Optional است، اگر X عددی باشد، می‌توانیم Option های خاصی را به آن اعمال کنیم تا با یک فرمت مشخص به String تبدیل شود. اگر X از نوع Boolean باشد، خروجی به صورت رشته "true" یا "false" خواهد بود. زمانی که X عددی است، می‌توان Option های مختلفی را در Y به کار برد:

"commas" فیلد عددی را به String تبدیل کرده و با جداکننده هزارگان و دو رقم اعشار نمایش می‌دهد.
"duration" فیلد عددی که معمولاً ثانیه است را با فرمت ساعت Hour Format: HH:MM:SS نمایش می‌دهد.
"hex" فیلد عددی را به مقدار Hexadecimal تبدیل می‌کند.

اکنون مثال را بررسی کنیم. ابتدا در دستور tostring، فیلد عددی به کار رفته و سپس "commas" استفاده شده است. فیلد عددی ما را به یک عدد اعشاری با دو رقم اعشار تبدیل می‌کند. همان‌طور که در خروجی مشاهده می‌شود، ابتدا Dollar Sign $ قرار گرفته و سپس Value به صورت اعشاری نمایش داده شده است. پس از آن، فیلد Total Last Revenue وجود دارد که باز هم ابتدا Dollar Sign و سپس تبدیل فیلد به String به صورت اعشاری نمایش داده شده است.

تابع Range

در مثال بعدی که در تصویر مشاهده می‌کنید، ابتدا از دستور stats استفاده شده و همچنین از تابع range بهره گرفته شده است. تابع range زمانی که یک Field به آن ارسال می‌شود، تفاضل Maximum و Minimum مقدار آن Field را برای ما محاسبه کرده و نمایش می‌دهد. سپس، از دستور eval استفاده شده و همچنین تابع tostring که فیلد Session Time را با فرمت ساعت به String تبدیل می‌کند. خروجی که مشاهده می‌کنید، دقیقاً فرمت ساعت است و ستون Session Time که مقدار عددی range را نشان می‌دهد توسط دستور stats و تابع range ایجاد شده است.

دستور Eval با چندین Expression

در مثال بعدی، از دستور eval استفاده شده و چندین Expression به کار رفته است. ابتدا از round function استفاده شده، سپس فیلد جدیدی ایجاد شده که یک عملیات ریاضی بر روی آن انجام می‌شود و باز هم فیلد جدید دیگری که یک سری عملیات ریاضی بر روی آن اجرا می‌شود و خروجی آن‌ها داخل آن فیلد قرار می‌گیرد. این نیز نمونه و مثالی است از دستور eval با چندین Expression و بخش مجزا که می‌توان به این نحو از آن استفاده کرد.

تا اینجا، چندین Function و کلیت ماجرای این Command را یاد گرفتیم و توانستیم مثال‌های بسیار خوبی در خصوص آن یاد بگیریم.

توابع شرطی If و Case

در قسمت بعدی، قصد داریم Function های شرطی مانند if و case را بررسی کرده و ببینیم چگونه می‌توان از این توابع شرطی استفاده کرد.برای استفاده از Conditional Functions در دستور eval، می‌توان از دو تابع if و case استفاده کرد. در مثالی که در تصویر مشاهده می‌کنید، از تابع if استفاده شده است. اگر بخواهیم Syntax این تابع را توضیح دهیم، تابع if سه Argument دارد: X, Y, Z.

آرگومان اول، X، یک Boolean Expression است که خروجی آن یا False یا True می‌باشد.

اگر خروجی X برابر True باشد، مقدار Y به عنوان نتیجه تابع بازگردانده می‌شود.
اگر خروجی X برابر False باشد، مقدار Z به عنوان نتیجه تابع بازگردانده می‌شود.

به مثالی که در Document آمده توجه کنید: iferror == 200, "OK", "Error". اگر مقدار Error Field برابر ۲۰۰ باشد، رشته "OK" برگردانده می‌شود، در غیر این صورت هر مقدار دیگری غیر از ۲۰۰، رشته "Error" برگردانده می‌شود. این تابع ساده و البته محدود است.

مثال را بررسی کنیم. ابتدا از دستور eval استفاده شده و سپس نام فیلدی که می‌خواهیم خروجی if در آن قرار گیرد. در آرگومان اول، شرطی قرار داده‌ایم که اگر Vendor ID Field بزرگ‌تر یا مساوی ۷۰۰۰ و کوچک‌تر از ۸۰۰۰ بود، رشته‌ای خاص برگردانده شده و در فیلد مورد نظر ثبت شود. اگر این‌طور نبود و خروجی شرط False بود، مقدار آخر یعنی Z ، برگردانده شده و در فیلد ثبت می‌شود. پس از آن، با استفاده از دستور stats ، مجموع Price محاسبه شده و در انتها، باز هم با استفاده از دستور eval، ابتدا فیلد به String با فرمت Comma تبدیل شده و سپس Dollar Sign $ در ابتدای آن قرار داده شده است.

خروجی را مشاهده کنیم. فیلدی که ساخته شده شامل دو مقدار ممکن است که بر اساس شرط گذاشته شده، یکی از این دو مقدار نمایش داده می‌شود. ستون بعدی نیز بر اساس دستور eval نوشته شده، خروجی و فرمت آن تغییر کرده و نمایش داده می‌شود.

نکاتی در خصوص تابع if: اگر می‌خواهید مقادیر غیر عددی و String به کار ببرید، حتماً باید آن‌ها را داخل Double Quotes قرار دهید. به صورت پیش‌فرض، Field Value هایی که داخل شرط به کار می‌برید نیز Case-Sensitive هستند و باید به این نکته توجه کنید. این تابع پیچیدگی زیادی ندارد و کاربرد آن کاملاً مشخص است. محدودیت آن نیز مشخص است که نمی‌توان بیش از یک شرط اصلی قرار داد و اگر بیش از یک شرط را بخواهیم بررسی کنیم باید از case استفاده نماییم.

تابع case

ابتدا سینتکس Case را بررسی کنیم. همان‌طور که در تصویر مشاهده می‌شود، این تابع می‌تواند چندین Argument ورودی دریافت کند. ساختار به این صورت است که ابتدا شرط Expression اول بررسی می‌شود؛ در صورتی که خروجی آن True باشد، آرگومان بعدی مقدار مربوط به آن شرط به عنوان خروجی تابع در نظر گرفته می‌شود. اگر شرط اول False بود، شرط دوم بررسی می‌شود و در صورت True بودن، مقدار مربوط به آن بازگردانده می‌شود و همین‌طور تا انتها ادامه می‌یابد. می‌توان شرایط و شرط‌های متفاوتی قرار داد.

مثال را ببینیم.

اگر فیلد error = 404 باشد، خروجی برابر "Not found" خواهد بود.
اگر فیلد error = 500 باشد، آرگومان بعدی به عنوان خروجی برگردانده می شود.

و همین طور شرط بعدی و خروجی بعدی.

مثال را بررسی کنیم. در مثالی که روی Apache Logs نوشته شده، بر اساس Status Code ای است که Web Server پاسخ می‌دهد. همان‌طور که می‌دانید، Status Code های متفاوتی وجود دارد ۲۰۰, ۵۰۳, ۴۰۳ و.... در اینجا چندین Status Code مختلف در Log ها وجود داشت و می‌خواستیم ببینیم هر Status Code دقیقاً چه مفهومی دارد. برای اینکه بتوانیم Field دیگری به اسم Status Description داشته باشیم، از دستور eval و تابع case استفاده کرده‌ایم. شرط‌هایی که نوشته شده به این صورت است: اگر Status Field برابر ۲۰۰ بود، مقدار "OK" در فیلد Status Description نوشته می‌شود. برای هر Log، این شروط بررسی می‌شود. اگر با اولین شرط مطابقت نداشت، دومین شرط بررسی می‌شود. باز هم اگر دومی Match نشد، سومی و به همین ترتیب تا آخرین شرط. می‌توان برای آخرین آرگومان یک مقدار همیشه True در نظر گرفت تا اگر هیچ شرطی Match نشد، شرط آخر برقرار شده و یک Value پیش‌فرض در Field ذخیره شود. یا می‌توان این بخش آخر را حذف کرد و اگر هیچ شرطی Match نشد، مقداری بازگردانده نمی‌شود و آن Field خالی در نظر گرفته می‌شود.

در ادامه، از دستور timechart استفاده شده تا بتوان بر اساس فیلدی که ایجاد شده، یک Chart رسم کرد. خروجی را بررسی کنیم. بر اساس مقادیر فیلد Status Description، یک Timechart رسم کرده ایم. اگر به Events نیز بازگردیم، یک فیلد Status Description برای ما ایجاد شده که مقادیر مورد نظر در آن قرار دارد و اگر تعداد مقادیر را بررسی کنیم، دقیقاً با مقادیر فیلد Status مطابقت دارد. مثلاً اگر Value 200 در Status، ۳۴ هزار بار تکرار شده، فیلد OK در Status Description نیز ۳۴ هزار بار تکرار شده است.

همان‌طور که مشاهده می‌شود، این Function نیز پیچیدگی زیادی ندارد و به راحتی قابل استفاده است. خواهشمندم این موارد را تمرین کنید، چرا که در Calculated Fields، از دستور eval و توابع case و if بسیار استفاده می‌شود.

تابع eval به عنوان Function در دستورات دیگر

به غیر از دستور eval، یک eval function نیز وجود دارد. زمانی که بخواهیم تعداد Event هایی را که حاوی یک Value خاص هستند، بشماریم، می‌توانیم از ترکیب توابع Count و eval استفاده کنیم. این ترکیب با استفاده از Transformer Command ها مانند stats قابل استفاده است. زمانی که از این ترکیب استفاده می‌کنید، حتماً باید از As Clause استفاده کنید و همچنین Strings و مقادیر Non-numeric را داخل Double Quotes قرار دهید. تمام Field Value ها در این حالت Case Sensitive هستند.

تا اینجا دستور eval و همچنین تابع eval را یاد گرفتیم. در قسمت بعد، درباره command های search و where صحبت خواهیم کرد. برای اینکه بتوانیم خروجی‌های Search خود را Filter کنیم، می‌توانیم از دو command یعنی search و where استفاده نماییم. به وسیله این دو command، می‌توانیم در خروجی‌ای که Search ایجاد کرده در هر مرحله‌ای که هستیم، شرط گذاشته و یا مجدداً جستجو کنیم تا خروجی موجود باز هم فیلتر شود.

به عنوان مثال، در تصویری که مشاهده می‌کنید، ابتدا از stats command استفاده شده و سپس از دستور search. خروجی‌ای که stats command دارد، توسط دستور search فیلتر می‌شود. در این مثال، هر مقداری که بزرگ‌تر از ۵۰۰ باشد، نمایش داده می‌شود و پس از آن نیز دستورات دیگری اعمال می‌شوند. اگر خروجی را با هم ببینیم، خروجی فیلتر شده و مقادیری که در جدول مشاهده می‌شود، بزرگ‌تر از ۵۰۰ هستند.

ما می‌توانیم این command را در هر جای Search به غیر از ابتدای آن استفاده کنیم. ابتدا باید یک خروجی از دستورات قبلی داشته باشیم تا بتوانیم بر روی آن خروجی، با استفاده از دستور search، فیلتر را انجام دهیم. می‌توان از Wildcard نیز در این command استفاده کرد. نکته بسیار مهم این است که Field Value ای که اینجا استفاده می‌شود، Case Sensitive نیست.

برای کسانی که با Splunk Search آشنایی دارند، استفاده از این command بسیار آسان است، زیرا وقتی از آن استفاده می‌کنیم، انگار در حال ایجاد یک Search جدید هستیم. Command هایی که پس از آن به کار می‌روند، می‌توانند مانند یک Search معمولی باشند. برای مثال، می‌توانیم اینجا یک Keyword را مشخص کنیم یا از دستورات دیگر Search استفاده کنیم، از Field Value ها استفاده نماییم. پس استفاده از دستور search بسیار آسان است.

دستور where

دستور بعدی دستور where است. در مثالی که مشاهده می‌کنید، از دستور timechart استفاده شده و از ترکیب count و eval بهره گرفته شده که توضیحات آن پیش‌تر داده شد. خروجی این بخش شامل دو فیلد Change و Removal است. با استفاده از where command، این دو فیلد با هم مقایسه می‌شوند و Condition ای قرار داده شده که اگر Values داخل فیلد Removal از Change بزرگ‌تر باشند، در Table نمایش داده شوند.

پس از نوشتن این command، می‌توان دقیقاً مانند دستور eval، از Expression هایی که آنجا یاد گرفتیم، در اینجا نیز استفاده کرد. برخی نکات که قبلاً گفته شد، در اینجا نیز وجود دارد: اگر یک String را داخل Single Quotes قرار دهید یا اصلاً داخل هیچ علامتی قرار ندهید، به عنوان نام Field تلقی می‌شود و اگر یک String را داخل Double Quotes قرار دهید، به عنوان Field Value شناخته می‌شود و Field Value در where نیز Case Sensitive است.

اگر یادتان باشد، در دوره Fund 1 درباره Case Sensitive نبودن مقدار Value در Search اصلی صحبت کردیم آن مقادیری که مستقیماً در بخش اولیه Search استفاده می‌شوند Case Sensitive نیستند، اما نام Field ها Case Sensitive هستند. یکی از کاربردهای دستور where، همین Case Sensitive بودن مقدار Value آن است. اگر می‌خواهید بر اساس یک Value با رعایت Case Sensitivity جستجو کنید، می‌توانید از دستور where استفاده نمایید. دقت کنید که دستور search Case Sensitive نبود و دستور where که Case Sensitive است برای Case Sensitive Search استفاده می شود.

دستور CASE

اگر بخواهیم داخل Search Bar اصلی، کلمه‌ای را جستجو کنیم و به Splunk بگوییم که به Case Sensitive بودن آن دقت کند و این برای ما مهم است، می‌توانیم از دستور CASE استفاده کنیم که با حروف بزرگ نوشته می‌شود. این CASE را با case function که در دستور eval وجود دارد، اشتباه نگیرید.

مثال: اکنون در Log های موجود، می‌خواهم کلمه purchase را با P بزرگ Capital P جستجو کنم. خروجی ندارد، زیرا purchase با P بزرگ وجود ندارد. اما اگر با p کوچک جستجو کنم. خروجی می‌دهد و کلمه purchase را پیدا می‌کند. پس این را هم به مجموعه دستوراتی که در این ویدیو یاد گرفتید، اضافه کنید.

کلمه کلیدی LIKE در دستور where

نکته بعدی در خصوص where command این است که می‌توان از کلمه کلیدی LIKE داخل دستور where استفاده کرد. به این مثال توجه کنید. ابتدا از stats command استفاده شده و سپس با استفاده از where command، خروجی به صورتی فیلتر شده که Source IP هایی که ابتدای آن‌ها با ۱۰ شروع می‌شود نمایش داده شوند. زمانی که از LIKE استفاده می‌کنیم، می‌توان از Wildcard های _ آندرلاین و % درصد استفاده کرد:

_ : به یک کاراکتر منفرد اشاره می‌کند (هر کاراکتری).
% : به صفر یا چند کاراکتر اشاره می‌کند (هر کاراکتری).

خروجی مثال IP هایی است که اوکتت اول آن‌ها ۱۰ است. اوکتت های بعدی هر چیزی می تواند باشد. می‌توان کلمه LIKE را در case function نیز به کار برد.

مثال‌های دیگری را ببینیم. همان‌طور که در مثال مشاهده می‌شود، باز هم از where استفاده شده و User هایی که ابتدای نام آن‌ها adm است نمایش داده می‌شوند مانند admin, administrator یا خود adm. و در مثال بعدی، User هایی که حرف دوم و سوم نامشان dm است نمایش داده می‌شوند مانند admin و Edmund.

در نتیجه، می‌توان با استفاده از LIKE، مقادیری را که شبیه به یک Pattern مد نظر هستند، پیدا کرد و خروجی را بر آن اساس فیلتر نمود. هنوز دو نکته دیگر برای این دستور باقی مانده است: نکته اول ISNULL و نکته دوم ISNOTNULL.

زمانی که Searchی می‌نویسید و خروجی آن شامل مقادیر زیادی است و در این میان، Field هایی وجود دارند که خالی هستند، می‌توان به وسیله دو Function یعنی isnull و isnotnull مقادیر را فیلتر کرد Field هایی که خالی هستند یا نیستند.

با isnull می‌توان رکوردهایی را فیلتر کرد که Field مشخص شده برای آن‌ها خالی Null است. با isnotnull می‌توان رکوردهایی را نمایش داد که Field مشخص شده برای آن‌ها خالی نیست مقدار دارد.

اگر دقت کنید، در این مثال، ابتدا با دستور timechart کار شده و پس از آن، با استفاده از دستور where و تابع isnull، یک فیلد به این Function ارسال شده است. اگر سطری وجود داشته باشد که این فیلد برای آن مقدار داشته باشد، به ما نمایش داده نمی‌شود. در واقع، این دستور به دنبال سطرها یا رکوردهایی می‌گردد که فیلد مشخص شده در آن‌ها فاقد مقدار باشد. برعکس آن، isnotnull مقادیری را نمایش می‌دهد که داخل آن فیلد وجود دارند و رکوردهای با فیلدهای خالی را نمایش نمی‌دهد.

دستور fillnull

در انتهای این ماژول، هنوز یک Command باقی مانده است. دستور fillnull . وظیفه اصلی این Command، جایگزین کردن مقادیر خالی و Null با مقداری است که شما تعیین می‌کنید یا مقدار پیش‌فرض آن.

به صورت پیش‌فرض، وقتی این Command استفاده می‌شود مطابق مثال، اگر فیلدی مقداری نداشته باشد Null باشد، به جای آن مقدار صفر قرار می‌گیرد. مانند مثالی که مشاهده می‌کنید؛ داخل این Table، فیلدی وجود دارد که مقداری نداشته و به جای آن صفر گذاشته شده است.

در نتیجه، زمانی که روی Log ها کار می‌کنید و با حجم عظیمی از Log ها سروکار دارید و با استفاده از دستوراتی مانند stats یا timechart کار خود را پیش می‌برید، احتمالاً همه Log ها، فیلدهای مورد نظر شما را ندارند و این باعث می‌شود خروجی شما ظاهر نامناسبی پیدا کند یا در جایی خروجی درستی نگیرید و متوجه نشوید مقادیر Null دقیقاً کجا وجود داشته‌اند. شما می‌توانید با استفاده از این دستور fillnull، فیلدهایی را که مقدار Null دارند، با مقدار دیگری جایگزین کنید. به صورت پیش‌فرض، صفر جایگزین می‌شود. می‌توانید با استفاده از Option مربوط به value، دقیقاً مشخص کنید که به جای مقدار صفر یا Null، چه چیزی قرار گیرد.

در مثالی که مشاهده می‌کنیم، اکنون به جای مقدار Null، رشته NO VALUE قرار داده شده است؛ NO VALUE ای که با Option مربوط به value در دستور fillnull در Search ما تعیین شده است.

نکته آخری که در خصوص این دستور وجود دارد این است که می‌توان به این دستور گفت که fillnull بر روی کدام Field یا Fields اعمال شود و تأثیرگذار باشد. پس از استفاده از دستور و Option مربوط به value، می‌توان نام ستون‌ها و Field ها را در انتهای این دستور ذکر کرد تا fillnull فقط بر روی آن Field ها و ستون‌ها اعمال شود. به عنوان مثال، می‌توان Product Name یا حتی چندین Field را ذکر کرد. به این صورت می‌توان عملکرد این دستور را محدود Limit کرد.

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

ماژول پنج - Correlating Events

زیرنویس عنوان

سلام. با Module پنجم از دوره Splunk Fundamental 2 در خدمت شما هستم. در این Module، قرار است در خصوص یکی از بهترین Command های Splunk صحبت کنیم و ببینیم چگونه می‌توانیم میان Event ها همبستگی ایجاد کنیم. ابتدا با دستور transaction آشنا می‌شویم و در ادامه، در خصوص قابلیت‌های این Command و Option هایی که وجود دارد صحبت می‌کنیم و فرا می‌گیریم که چگونه از این Command استفاده کنیم.

Transaction چیست؟

سؤال مهمی که در ابتدای این Module باید به آن پاسخ دهیم این است که Transaction چیست و چه کاربردی دارد؟

با توجه به مطالبی که تاکنون فرا گرفته‌ایم، تصور کنید ما در Splunk، Log های مختلف و Event های مختلف را از Source های متفاوت دریافت می‌کنیم. در این Log هایی که از Source های مختلف دریافت می‌شود، گروهی از Event ها وجود دارد که با داشتن Value های مشترک در چندین Field متفاوت، با یکدیگر مرتبط هستند. اگر این Value های مشترک را بیابیم و این Log ها را با توجه به Value های مشترکشان به یکدیگر مرتبط کرده و ادغام کنیم، یک Transaction برای ما ایجاد می‌کند.

به عنوان مثال، کاربری را تصور کنید که قصد اتصال به یک Web Server را دارد. این اتصال از تجهیزات مختلف امنیتی و سیستم‌عامل‌ها عبور می‌کند و تمام این تجهیزات، Log و Event مرتبط با Activity آن کاربر را ثبت کرده و برای Splunk ارسال می‌کنند. یقیناً میان این Log هایی که ثبت و برای Splunk ارسال می‌شود، چندین Value مشترک میان تمام Log ها وجود دارد؛ حتی Log هایی که اساساً ماهیت آن‌ها با یکدیگر متفاوت است مانند Log مربوط به Firewall، Log مربوط به Web Server یا Log مربوط به سیستم‌عامل. نکته حائز اهمیت، مشترک بودن آن Value است. ابتدایی‌ترین Value ای که می‌تواند مشترک باشد، Source IP است. به احتمال زیاد، یقیناً گروهی از Event ها وجود دارد که با داشتن یک یا چند Value مشترک، می‌توانند با یکدیگر مرتبط باشند.

بنابراین، به گروهی از Event ها که با داشتن یک یا چندین Value و Data مشترک به هم مرتبط هستند، Transaction می‌گوییم. این گروه از Event ها می‌توانند از یک Source یا از چندین Source، Sourcetype یا Host باشند و می‌توانند چندین Timestamp در محدوده‌های زمانی مختلف داشته باشند.

مثال‌های کاربردی از Transaction

فعالیت کاربر در وب‌سایت: Event های مرتبط با Activity کاربران وب‌سایت یا Web Application شما که بر روی یک یا چند Server و در زمان‌های مختلف رخ داده است. هنگامی که کاربری وارد وب‌سایت شما می‌شود و قصد خرید دارد، تصور کنید تمام Event های مرتبط با Activity او در حال ثبت است. زمانی که کاربر خرید انجام می‌دهد، به احتمال زیاد چندین Activity مختلف انجام می‌دهد؛ مانند افزودن کالا به سبد خرید، حذف کالا از سبد خرید، مشاهده محصولات و در نهایت اقدام به خرید. این Event های مرتبط با Activity کاربر، یک Transaction ایجاد می‌کنند. هنگامی که شما بخواهید از طریق Log ها در Splunk بررسی کنید که Activity کاربر چگونه بوده است، می‌توانید از دستور transaction استفاده کنید.
ارسال ایمیل: به عنوان نمونه‌ای دیگر، هنگامی که شما یک Email ارسال می‌کنید، آن Email از Queue های مختلف و تجهیزات مختلف عبور می‌کند و Log های متفاوتی ایجاد می‌شود. در آن Log ها، تعدادی Value مشترک وجود دارد که ما با دستور transaction می‌توانیم مشاهده کنیم که از زمانی که آن Email ایجاد و ارسال شد، چه رخدادهایی برای آن پیش آمده است.
ترافیک شبکه: Log های ترافیک شبکه را در نظر بگیرید. هنگامی که کاربری بخواهد اتصال Remote برقرار کند یا یک اتصال Network ایجاد کند، تجهیزات مختلف Log آن را ثبت می‌کنند. ما می‌توانیم یک Transaction ایجاد کنیم که دارای یک نقطه شروع و یک نقطه پایان باشد و بررسی کنیم که از ابتدا تا انتها چه اتفاقاتی افتاده و چه Log هایی ثبت شده است.
فعالیت کاربر در Splunk : همین Splunk را در نظر بگیرید. هنگامی که من Login می‌کنم، برخی Dashboard ها را مشاهده می‌کنم و اقداماتی را انجام می‌دهم؛ Log مربوط به Audit تمام این موارد ثبت می‌شود. من می‌توانم با استفاده از دستور transaction، یک Search ایجاد کنم تا مشخص شود هنگامی که کاربر در Splunk، Login می‌کند تا زمانی که Logout انجام می‌دهد و از سیستم خارج می‌شود، چه اقداماتی انجام می‌دهد.

نکته‌ای که تاکنون مطرح شد این است که شما مفهوم Transaction را درک کرده باشید. این موضوع بسیار مهم است. شما ابتدا مفهوم را درک کنید و سپس بدانید که با استفاده از Command های متفاوت نیز می‌توان این همبستگی را ایجاد کرد، ولی با استفاده از دستور transaction این کار تا حدودی ساده‌تر و قابل فهم‌تر انجام می‌شود و خروجی حاصل، خواناتر است.

تعیین ابتدا و انتهای Transaction

نکته دیگر آنکه، این شما هستید که ابتدا و انتهای یک Transaction را مشخص می‌کنید. شما مفهوم کلی Transaction را اکنون فراگرفتید، اما ابتدا و انتهای یک Transaction را شما بر اساس سناریو و هدفی که قصد دارید از دستور transaction استفاده کنید، مشخص می‌نمایید. الزاماً شروع یک Transaction، Log مربوط به Firewall یا Source های اولیه یک ترافیک نیست. شما می‌توانید ابتدا و انتهای یک Transaction را بر روی Web Server خود یا بر روی یک Source مشخص، تعیین کنید. شما باید هدفی را تعریف کنید، یک سناریو ایجاد کنید و سپس از این Command استفاده نمایید. آن هدف یا سناریو می‌تواند درون یک Web Server باشد یا از دو مبدأ مشخص با Value های مشترک نشأت گرفته باشد.

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

بررسی مثال‌ها:

مثال 1 ساده‌ترین حالت: همانطور که در این تصویر مشاهده می‌کنید، نمونه‌ای از نحوه استفاده از دستور transaction نمایش داده شده است. این مثال، ساده‌ترین نمونه‌ای است که می‌توانیم از دستور transaction استفاده کنیم. ابتدا Log های مورد نظر را انتخاب کرده‌ایم و بعد از آن، یک Pipe گذاشتیم و دستور transaction باید نام یک Field یا Field هایی را ذکر کنیم که حاوی Value مشترک میان Log های مرتبط باشند. پس از کلیک بر روی دکمه Search، Event هایی که مد نظر ما هستند، بر اساس Value های مشترک درون Field هایی که در اینجا وارد کرده‌ایم، به گروهی از Transaction ها تبدیل می‌شوند.

بنابراین، پیش از استفاده از command، logs را مشاهده، events خود را بررسی و fields مشترک را استخراج کنید. همچنین مشخص نمایید بر اساس کدام field و value قصد ایجاد transaction را دارید. ممکن است لازم باشد ابتدا و انتهای transaction را مشخص نمایید؛ این موضوع در ادامه توضیح داده خواهد شد.

چالش نرمال‌سازی فیلدها در Transaction

نکته مهم دیگر این است که افرادی که قصد دارند از این command استفاده کرده و از چندین source متفاوت transaction ایجاد کنند، معمولاً با چالشی مواجه می‌شوند. آن‌ها قصد استفاده از یک field را دارند که در source های متفاوتی که برای ایجاد آن transaction استفاده می‌شوند، آن field با نام‌های متفاوتی وجود دارد. این مشکل ناشی از عدم normalization صحیح log در Splunk است که در این دوره و دوره‌های آتی به آن پرداخته خواهد شد.

بنابراین، اگر قصد دارید field مربوط به value و data مشترک در log های حاصل از source های مختلف را استفاده نمایید، آن log ها باید پیشتر نرمال‌سازی شده باشند تا بتوانید به بهترین شکل از این command استفاده نمایید. به عنوان مثال، اگر قصد دارید بر اساس source IP یک transaction ایجاد کنید و نام field مربوط به source IP در log های مختلف یکسان نباشد و از نام‌های متفاوتی استفاده شده باشد، این مسئله به نرمال‌سازی نادرست log شما بازمی‌گردد و این مشکل باید پیشتر طبق استانداردها رفع شده باشد.

برای درک بهتر این مثال و پیش از بررسی خروجی، به بررسی log های مربوط به این source type می‌پردازیم تا محتوای آن‌ها را مشاهده کنیم. این log ها مربوط به یک web server هستند که یک website بر روی آن میزبانی می‌شود و تمام log ها شامل یک field به نام jsessionID دارند که به اختصار در اینجا sessionID می گوییم.

هنگامی که کاربری وارد website می‌شود و در آن فعالیت می‌کند، web server، log های مربوطه را ثبت می‌نماید. یک session ID اختصاصی به آن کاربر تخصیص داده می‌شود، به گونه‌ای که در هر log ثبت شده، value مربوط به session ID به آن کاربر و فعالیت‌هایش تعلق دارد. fields و values دیگری نیز مانند source IP یا username وجود دارند که می‌توانستند مورد استفاده قرار گیرند. با بررسی log ها، مشاهده می‌شود که field session ID وجود دارد، اما تشخیص نقطه شروع و پایان یک activity و همچنین تعیین اینکه کدام events با یکدیگر مرتبط هستند، به سادگی امکان‌پذیر نیست.

زمانی که یک کاربر در حال استفاده از website است، احتمالاً کاربران دیگری نیز همزمان فعال هستند و log های مربوط به آن‌ها نیز ثبت می‌شود. هنگام تحلیل log ها، مشاهده می‌شود که تعداد زیادی log وجود دارد که هر کدام به activity یک کاربر متفاوت اشاره دارد و انجام یک تحلیل دقیق، با توجه به log های ثبت شده که نمایش داده می‌شوند، دشوار است.

بنابراین، با توجه به چالش‌های موجود در خروجی این search معمولی و نیازمندی موجود در این مثال، مبنی بر شناسایی events مرتبط بر اساس value موجود در این field، باید از command transaction استفاده کرد. اگرچه می‌توان برای رفع این نیازمندی از command های دیگری نیز استفاده نمود، اما استفاده از این command راهکار مناسب‌تری است.

ایجاد یک Single Event با transaction

حال، با در نظر گرفتن چالش‌ها و نیازمندی‌های ذکر شده، قصد داریم با استفاده از command transaction یک single event ایجاد نماییم. این single event از تجمیع گروهی از events تشکیل می‌شود که دارای یک یا چند value مشترک هستند. در ادامه فرآیند ایجاد transaction، خروجی این command را بررسی خواهیم کرد. با مشاهده تصویر، می‌توان دید که events که value آن‌ها در field session ID برابر است، به یک single event تبدیل شده‌اند.

هنگامی که جزئیات را با هم بررسی می‌کنیم، مشاهده می‌کنیم که Field هایی که به صورت مشترک میان Event های اولیه وجود داشتند، مقادیر آنها همچنان وجود دارد و می‌توانیم از آن استفاده کنیم. همچنین یک Field به نام eventcount اضافه شده است که تعداد Event های اولیه که درون این Single Event Transaction قرار دارند را به ما نمایش می‌دهد
بنابراین، هنگامی که من از این Command استفاده کردم و نام Field مورد نظرم را ذکر کردم و Search را اجرا می‌کنم، تمام Event هایی که Value آن Field را به صورت مشترک دارند، به یک Single Event تبدیل شده‌اند. اکنون من می‌توانم پس از این، Pipe قرار دهم و اقدامی که می‌خواهم انجام دهم را بر روی این Single Event ها Transaction ها انجام دهم. در ادامه، با هم مثال‌های واضح‌تری را انجام خواهیم داد.

مثال 2 استفاده از دستورات دیگر پس از transactionدر این مثال نیز من از Field مربوط به JSESSIONID برای ایجاد Transaction استفاده کردم و پس از آنکه این دستور خروجی داد، از دستور search استفاده کردم که در Module های قبلی درباره دستور search صحبت کردیم و فرا گرفتیم و پس از آن از دستور highlight استفاده کردم تا Value های مربوط در نتایج Highlight شوند. همانطور که مشاهده می‌کنید، Single Event ها ایجاد شده‌اند و مواردی که خواسته بودیم Highlight شده و نتایج کاملاً واضح است.

مثال 3 Use Case امنیتی Fail Loginمثالی که در تصویر مشاهده می‌کنید، یکی از Use Case های مراکز عملیات امنیت SOC است که برخی از SOC های موجود در همین یک Use Case ساده اکنون با مشکل مواجه هستند. مشاهده کنید که این Use Case چقدر ساده نوشته و پیاده‌سازی شده است. معمولاً SOC ها یک Use Case دارند که بر اساس آن می‌خواهند Login های ناموفق که از یک IP اما با User های مختلف رخ داده است را مشاهده کنند. خب، این مثالی که مشاهده می‌کنید، دقیقاً همین مورد را به ما اطلاع‌رسانی می‌کند. ما با استفاده از Log های مرتبط با Authentication ناموفق در Linux با استفاده از دستور مربوط به transaction را بر روی این Log ها استفاده کردیم و Value ای که می‌خواهیم بر اساس آن، Transaction شکل بگیرد و گروهی از Event هایی که با یکدیگر مرتبط هستند، یک Transaction ایجاد کنند، درون Field مربوط به source قرار دارد که همان Source IP ها است و خروجی این Search را اکنون شما مشاهده می‌کنید.

نکته قابل توجهی که در مثال پیشین به آن اشاره شد، این است که هنگام استفاده از این command، دو field ایجاد می‌شود. یکی field event است که پیشتر مشاهده شد و field دیگری که ایجاد می‌شود، duration field نام دارد.

این field، تفاوت زمانی بین اولین و آخرین event در آن transaction را اندازه‌گیری کرده و نمایش می‌دهد. همچنین field event، همانطور که در مثال پیشین ذکر شد، تعداد events موجود در هر transaction را نمایش می‌دهد. مثال بعدی را بررسی ‌کنیم.

مثال 4 Option های Maxspan و Maxpause:

در این مثال، مجدداً از web server logs استفاده شده است. پس از اجرای search، از transaction command استفاده شده و سپس field client IP به کار گرفته شده است. بدین معنا که value مشترک گروهی از events که یک transaction را تشکیل می‌دهند، در field client IP قرار دارد. پس از field client IP، برای نخستین بار با دو option با نام‌های maxspan و maxpause آشنا می‌شویم که با استفاده از این دو option می‌توان محدودیت‌های زمانی مشخصی را بین events تعیین نمود.

- maxspan : ما از طریق این Option می‌توانیم حداکثر زمان Span میان Timestamp اولین و آخرین Event که در هر Transaction وجود دارد را مشخص کنیم. اگر از این Option استفاده نکنیم، به صورت پیش‌فرض مقدار آن 1- است، یعنی هیچ محدودیت زمانی وجود ندارد.
- Maxpause : با Option مربوط به maxpause می‌توانیم بگوییم که حداکثر زمان اختلاف میان Event های داخل یک Transaction چقدر باشد. یعنی حداکثر گپی که وجود دارد.
  بنابراین، زمانی که می‌خواهید گروهی از Transaction ها را بسازید، می‌توانید با استفاده از Option مربوط به maxspan، حداکثر زمانی که میان اولین و آخرین Event در هر Transaction هست را مشخص کنید و با Option maxpause حداکثر اختلاف زمان میان Event های داخل یک Transaction را مشخص نمایید. اگر این Option را تنظیم نکنیم، به صورت پیش‌فرض مقدار آن 1- است و هیچ محدودیتی اعمال نمی‌شود.
  خیلی این نکته مهم است که ما بتوانیم برای آن سناریو و برای هدفمان، این زمان را مشخص کنیم؛ چرا که بر اساس سناریوهای واقعی، به احتمال زیاد از یک زمانی به بعد، احتمالاً آن Event ها به هم مرتبط نیستند. اگر می‌خواهید از یک سری Value هایی مانند Source IP استفاده کنید، به احتمال زیاد به مشکلاتی برمی‌خورید که این Event ها به هم مرتبط نیستند و شما زمانی که دارید به سناریو و هدف خود فکر می‌کنید، این پارامترها را هم در نظر بگیرید که حداقل Option maxspan را مقداردهی کنید.

پس از استفاده از command transaction، از eval استفاده شده است که همانطور که در ماژول‌های پیشین مطرح گردید، duration field را به یک field با فرمت string و ساعت تبدیل می‌نماید. سپس با استفاده از sort command خروجی مرتب‌سازی شده، با استفاده از table command خروجی به شکل table نمایش داده می‌شود و در نهایت با استفاده از rename command، نام ستون‌ها تغییر می‌یابد.

می‌توان گفت command های پس از transaction عمدتاً به منظور بهبود خوانایی خروجی به کار می‌روند. بخشی از commands مورد استفاده، با هدف افزایش خوانایی خروجی اعمال می‌شوند، در حالی که برخی دیگر از commands، مانند مواردی که برای تغییرات یا detect به کار می‌روند، اهداف عملیاتی مشخصی دارند. هنگامی که یک search ایجاد شده و به نتیجه مطلوب می‌رسد، گام بعدی افزایش خوانایی خروجی است. این هدف با استفاده از command هایی نظیر موارد ذکر شده، قابل دستیابی است.

به طور خلاصه، در خصوص maxspan و maxpause با استفاده از option maxpause در command transaction، می‌توان حداکثر فاصله زمانی بین events درون یک transaction را تعیین نمود. و با option maxspan، حداکثر بازه زمانی (time) کلی، بین اولین تا آخرین event در آن transaction، قابل تعیین است. مثال بعدی را ببینیم.

مثال 5 Option های startswith و endswithدر این مثال نیز دو Option جدید را با یکدیگر فرا می‌گیریم startswith و endswith. . ما از طریق این دو Option می‌توانیم تعیین کنیم که Transaction ما با چه چیزی شروع شود و با چه چیزی پایان یابد.
همانطور که در مثال مشاهده می‌کنید، مجدداً بر روی Log های Web Server، از دستور transaction استفاده شده است، اما این بار از دو Field مربوط به clientip و SESSIONID به صورت همزمان استفاده شده است و از Option مربوط به startswith برای تعیین نقطه شروع Transaction. استفاده شده است. اگر Function مربوط به eval را که در Module قبلی درباره آن صحبت کردیم به یاد داشته باشید، در این مثال، ما با استفاده از این Function و Field مربوط به action، شرطی را تعیین می‌کنیم برای شروع Transaction؛ تعیین می‌کنیم که اگر Field مربوط به action برابر با 'addtocart' بود، اینجا نقطه‌ای است که Transaction ما شروع می‌شود. و سپس با استفاده از Option مربوط به endswith، شرطی را برای پایان Transaction قرار می‌دهیم که در این مثال به Field مربوط به action اشاره می‌کنیم و اگر Field مربوط به action برابر با 'purchase' بود، آنجا نقطه پایان Transaction ما خواهد بود.

نکته مهم در ترتیب نمایش فیلدها

یک نکته تجربی وجود دارد که ابتدا Search را تغییر می‌دهم تا Field مربوط به action را به خروجی جدول خود اضافه کنم. اگر دقت کنید، در دستور transaction تعیین کردم که Transaction من باید با action='addtocart' شروع شود و با action='purchase' پایان یابد. اگر خروجی را با دقت بررسی کنیم، در ستون action، سطرهایی وجود دارد که Action آنها با 'addtocart' شروع شده، اما با Action دیگری پایان یافته است و Action مربوط به 'purchase' احتمالاً در سطرهای بعدی قرار دارد یا در انتهای گروه Event ها نباشد. از این نوع خروجی‌ها در اینجا بسیار یافت می‌شود که در آن ترتیب رعایت نشده است. در اینجا مشکل چیست؟ چرا چنین مشکلی رخ می‌دهد؟ پاسخ این است که هنگامی که خروجی به جدول با استفاده از دستور table یا stats تبدیل می‌شود، در جدول، نحوه نمایش مقادیر Multi-value به این صورت است و ممکن است ترتیب ظاهری رعایت نشود. اگر به خود Event های خام در نمای Events مراجعه کنیم، اصلاً امکان ندارد که Transaction ای وجود داشته باشد که Action اولین Event آن 'addtocart' نباشد و آخرین آن نیز 'purchase' نباشد طبق شروطی که تعیین کردیم. این مشکل صرفاً در نمای جدول View هنگام نمایش فیلدهای Multi-value وجود دارد.

جمع‌بندی startswith و endswith : ما می‌توانیم در دستور transaction، ابتدا و انتهای یک Transaction را مشخص کنیم و شرایطی را برای نقاط شروع و پایان تعیین نماییم و از Field های دیگر مانند action یا status در این شرایط استفاده کنیم. به عنوان مثال، تعیین کنیم اگر action='successful' بود، Transaction شروع شود و اگر action='logout' بود، Transaction پایان یابد. می‌توانیم با توجه به Option های startswith و endswith این شرایط را تعیین کنیم.

مثال 6 Investigation با transactionمثال دیگری را می‌خواهیم با هم بررسی کنیم اما من Log مربوط به این مثال را نداشتم و تصویری تهیه کردم که آن را با هم مشاهده کنیم. این مثالی که قصد توضیح آن را دارم، در مثال‌های قبلی نیز مشابه آن را داشتیم، اما در اینجا تا حدودی واضح‌تر است. یکی از کاربردهایی که دستور transaction برای ما دارد، Investigation است. هنگامی که شما به صورت Full Text در Log ها جستجو می‌کنید و خروجی به شما نمایش داده می‌شود، به احتمال زیاد Context و اطلاعات زیادی به صورت همزمان به شما نمایش داده نمی‌شود که بتوانید تحلیل مناسبی داشته باشید. در تصویری که مشاهده می‌کنید، کلمه REJECT جستجو شده و خروجی آن را مشاهده می کنید اما در Log ها اطلاعات زیادی به ما نمایش داده نمی‌شود و نمی‌توانیم آن را تحلیل کرده و تصمیم بگیریم. می‌توانیم از قابلیت Investigation که در دستور transaction وجود دارد، استفاده کرده و ابتدا Value و Data مشترک در این Log ها را بیابیم و با استفاده از دستور transaction، گروهی از Event هایی که به یکدیگر مرتبط هستند را به یک Transaction تبدیل کنیم و سپس بر روی خروجی Transaction، کلمه REJECT را جستجو کنیم و بتوانیم اطلاعات جامع‌تری درباره آن هدفی که داریم به دست آوریم و تصمیم بگیریم. هنگامی که ابتدا Transaction را ایجاد می‌کنید، می‌توانید بر روی خروجی Transaction جستجو کنید و بسیاری از Event های دیگری که مرتبط با آن کلمه‌ای است که می‌خواهید جستجو کنید را مشاهده نمایید.
اگر بخواهیم تفاوت این دو مثال را ببینیم، در خروجی دستور transaction اکنون اطلاعات بیشتری مانند IP، DNS Lookup Result، Action و ... وجود دارد که در جستجوی Full Text اولیه نبود. فقط ابتدا باید آن Log ها را بررسی کنیم، Value ها و Data مشترک آنها را به دست آوریم و سپس از دستور transaction استفاده کنیم و آن موردی که به دنبالش هستیم را درون آن Transaction ها بیابیم.

مثال 7 Reporting با transactionیکی از کاربردهای دستور transaction در Reporting است. هنگامی که شما از دستور transaction استفاده می‌کنید، می‌توانید بلافاصله پس از این Command، از Command های آماری و Reporting مانند chart, stats, timechart استفاده کنید و به دلیل آنکه خروجی دستور transaction غنی‌تر از Log های معمولی است می‌توانید Report های قوی‌تری داشته باشید.
در مثالی که در تصویر مشاهده می‌کنید، یک Transaction ایجاد شده است که حداکثر زمان میان اولین و آخرین Event آن، ۱۰ دقیقه است و بر اساس Value های Field مربوط به clientip که میان Event ها مشترک است، این Transaction ساخته می‌شود. و پس از آن با دستور chart و تابع count، تعداد Transaction ها مشخص می‌شود و بر اساس Field مربوط به duration که توسط دستور transaction ایجاد شده است، این Chart رسم می‌شود. محور X نمودار ما را Field مربوط به duration تشکیل می‌دهد و در انتها span=log2 قرار داده شده است که از طریق این log2، مقادیر عددی که در Field مربوط به duration وجود دارد و محور X را تشکیل داده است، به صورت لگاریتمی در پایه ۲ دسته‌بندی می‌شود و Chart ای که رسم می‌شود به صورتی است که در تصویر می‌بینید.

مقایسه transaction و stats

آخرین نکته‌ای که در این Module وجود دارد، مقایسه میان transaction و stats است. در برخی سناریوها پیش می‌آید که شما می‌توانید از stats نیز به جای transaction استفاده کنید.

چه زمانی از transaction استفاده کنیم؟
- هنگامی که نیاز دارید بررسی کنید کدام Event ها می‌توانند با یکدیگر Correlate شوند و این همبستگی را ایجاد کنید.
- هنگامی که به گروه‌بندی Event ها بر اساس نقاط شروع و پایانی که خودتان با startswith و endswith می‌خواهید مشخص کنید، نیاز دارید.
- هنگامی که به Option های خاص transaction مانند maxspan, maxpause, startswith, endswith نیاز دارید.
چه زمانی از stats استفاده کنیم؟
- هنگامی که هدف اصلی، انجام محاسبات آماری مانند count, sum, avg, values, list و گروه‌بندی بر اساس فیلدهای مشخص است و نیازی به قابلیت‌های پیشرفته Correlation یا تعیین شروع و پایان دقیق Transaction ندارید.
- در محیط‌های بسیار بزرگ، اگر هدف با stats نیز قابل دستیابی است، معمولاً stats ترجیح داده می‌شود، زیرا سریع‌تر و Efficient تر از transaction عمل می‌کند.

محدودیت transaction : دستور transaction محدودیت دیگری نیز دارد: تعداد Event های اولیه‌ای که در هر Transaction گروه‌بندی می‌کند، به صورت پیش‌فرض حداکثر ۱۰۰۰ عدد است. اگر بخواهیم این عدد ۱۰۰۰ را افزایش دهیم، Admin باید پیکربندی‌هایی را انجام دهد تا دستور transaction بتواند خروجی بیشتری داشته باشد یعنی Event های بیشتری را در یک Transaction جای دهد.

نمایش مقایسه خروجی transaction و stats برای دو مثال مشابه
مثال‌ها را با هم بررسی کنیم.

مثال اول: در این مثال از transaction استفاده شده.
مثال دوم: در این مثال از stats استفاده شده است. خروجی‌ای که مشاهده می‌کنید، کاملاً یکسان است.
مثال سوم: باز هم از transaction استفاده شده.
مثال چهارم: و خروجی مشابه با stats.

این Command ها را اگر در محیط‌های بزرگ و در بازه‌های زمانی طولانی‌مدت امتحان کنید، خروجی‌ای که دستور stats به شما نمایش می‌دهد، بسیار سریع‌تر و بسیار Efficient تر است این Module نیز به پایان رسید. امیدوارم نهایت استفاده را برده باشید. این دستور transaction یکی از مهم‌ترین Command هاست و یکی از Command های مورد علاقه من است. در دوره‌های پیشرفته‌تر درباره Command ها بسیار صحبت خواهیم کرد. سپاسگزارم که تا انتهای این Module نیز همراه من بودید. اگر انتقاد، پیشنهاد یا مطلبی وجود داشت، می‌توانید به من Email بزنید و من نیز پاسخگوی شما خواهم بود. امیدوارم هر کجا که هستید سلامت باشید. خدانگهدار.

ماژول شش - Understanding Knowledge Objects

زیرنویس عنوان

مقدمه

سلام. با ماژول ششم از دوره Splunk Fundamental 2 در خدمت شما هستم. در این ماژول به بررسی knowledge objects خواهیم پرداخت. ابتدا types و categories مختلف knowledge object در Splunk مورد بحث قرار خواهد گرفت و انواع knowledge objects موجود در Splunk و نحوه کار با آن‌ها معرفی خواهد شد. پس از آن، به نقش knowledge manager در تیم‌هایی که وظیفه maintenance پلتفرم Splunk را بر عهده دارند، پرداخته می‌شود. در ادامه، مبحث permissions که در این دوره و دوره قبل توضیحاتی درباره آن ارائه شد، به تفصیل بررسی خواهد شد. در انتها، مدیریت knowledge object و به ویژه CIM یا Common Information Model شرح داده شده و مطالب جدیدی ارائه خواهد گردید.

اگر قصد دارید در آینده وارد دوره‌های system admin, data admin, es admin یا سایر دوره‌های advanced شوید، لازم به ذکر است که این ماژول، از نظر مفاهیم مطرح شده، یکی از مهم‌ترین ماژول‌ها محسوب می‌شود. درک عمیق این مفاهیم و توانایی کار با آن‌ها در آینده ضروری است. این ماژول نسبتاً کوتاه بوده و ممکن است شامل فعالیت‌های عملی و technical کمتری نسبت به سایر ماژول‌ها باشد. هدف اصلی پس از اتمام این ماژول، درک کامل مفاهیم و آشنایی با دسته‌بندی‌های ارائه شده است تا برای کار با data آمادگی لازم را کسب نمایید. لذا توصیه می‌شود در صورت وجود ابهام یا عدم درک کامل مطلبی، ویدیو را چندین مرتبه مشاهده کرده و در صورت امکان، در Google جستجو کرده و Splunk documents مرتبط را مطالعه نمایید تا fundamental و base قوی‌تری برای خود ایجاد کنید و بهترین عملکرد را در دوره‌های آتی و پروژه‌ها داشته باشید.

اکنون به مباحث تئوری می‌پردازیم و با بخش‌های جدیدی آشنا خواهیم شد. هنگام ورود به Splunk Enterprise، با کلیک بر منوی settings، بخش‌های مختلفی قابل مشاهده است، از جمله بخش‌هایی مانند data distributed environment, user authentication system و knowledge. تقریباً تمام منوهای موجود در بخش knowledge به knowledge objects مرتبط هستند

knowledge objects چیست؟

knowledge objects در اسپلانک، tools هایی هستند که به وسیله آن‌ها می‌توانید جنبه‌های مختلف data ورودی به Splunk را شناسایی و تجزیه و تحلیل نمایید. این تعریف ممکن است واضح به نظر برسد، اما سوالاتی مطرح می‌شود: data که در Fund 1 معرفی شد و در دوره‌های Fund 1 و Fund 2 با آن کار کرده و search را آموختیم، چه جنبه‌هایی می‌تواند داشته باشد که نیازمند شناسایی و تجزیه و تحلیل باشند؟ و اساساً چه نیازی به انجام این کار وجود دارد؟ هدف از شناسایی جنبه‌های مختلف data و سپس analyze آن چیست؟

چرا به Knowledge Objects نیاز داریم؟

پیشتر به واژه tools اشاره شد. در زبان انگلیسی، tools به ابزارهایی اطلاق می‌شود که به انجام یک activity خاص کمک می‌کنند. با این تعریف، به ابهام دوم می‌پردازیم: ضرورت استفاده از knowledge objects چیست؟ پاسخ به این سوال به هدف شما از پیاده‌سازی Splunk Enterprise و نیازهایی که قصد رفع آن‌ها را دارید، بستگی دارد. اگر تنها هدف شما ذخیره‌سازی log بدون نیاز به search یا تحلیل‌های دیگر باشد، احتمالاً به knowledge objects نیازی نخواهید داشت. اما اگر اهداف گسترده‌تری از پیاده‌سازی این solution مد نظر است، تمرکز بر knowledge objects و اجرای باکیفیت آن ضروری است. میزان تلاش و زمان صرف شده در این بخش، مستقیماً بر کیفیت خروجی Splunk تأثیرگذار خواهد بود.

به احتمال زیاد، هدف شما از پیاده‌سازی Splunk Enterprise، استفاده از commercial apps مانند SIEM، UBA، Phantom و همچنین قابلیت‌های cybersecurity و threat detection این ابزار است. در این صورت، قطعاً باید زمان قابل توجهی را به مبحث knowledge objects اختصاص داده و موارد را با دقت بررسی کنید و در صورت لزوم، با استفاده از tools موجود، knowledge objects را اصلاح یا از ابتدا ایجاد نمایید.

اهمیت کاربرد صحیح Knowledge Objects

علت تأکید بر این موضوع چیست؟ می‌توانستم مستقیماً به تعریف و دسته‌بندی knowledge object بپردازم. هدف، درک اهمیت این موضوع است؛ به عنوان مثال، اگر در آینده SIEM پیاده‌سازی شود و خروجی مطلوبی حاصل نگردد، احتمالاً عملکرد در بخش knowledge object صحیح نبوده است. این مسئله در appها و featureهای دیگر نیز صادق است. مبحث data و knowledge objects، زیربنای قابلیت‌های Splunk محسوب می‌شود. برای استفاده از این قابلیت‌ها، باید جنبه‌های مختلف data را شناسایی، تجزیه و تحلیل کرده و به Splunk معرفی نمایید. اگر انتظار دارید Splunk تهدیدات سایبری سازمان شما را به درستی شناسایی کند، ارسال data صحیح و سپس معرفی مناسب آن data صحیح به Splunk، از طریق knowledge objects، ضروری است. امیدوارم اکنون اهمیت این موضوع روشن شده باشد و بدانید که برای فعالیت حرفه‌ای در این حوزه، knowledge object یکی از کلیدی‌ترین مباحث است.

ممکن است پرسیده شود آیا راهکاری برای اجتناب از این حجم کار وجود دارد؟ آیا Splunk راهکار از پیش آماده‌ای برای data ما ارائه کرده است؟ پاسخ مثبت است و Splunk امکانات خاصی را برای این منظور فراهم نموده است. با این حال، در این module، شرح detail تمام موارد ضروری است. پس از آشنایی با تمام موارد، می‌توانید از امکانات از پیش آماده Splunk در محیط خود استفاده کرده و data مورد نظر را به بهترین شکل برای Splunk آماده نمایید.

در دقایق گذشته به شرح knowledge object پرداخته شد و بیان گردید که knowledge object، tools هایی هستند که به وسیله آن‌ها می‌توان جنبه‌های مختلف data ورودی (log) را شناسایی و analyze کرد. جنبه‌های مختلف log باید شناسایی و به Splunk معرفی شوند. حال، ابزارها و دسته‌بندی‌های موجود کدامند؟

انواع knowledge object

به طور کلی، پنج دسته knowledge object وجود دارد:

Fields و Field Extractions : این دسته وظیفه data interpretation یا تفسیر data را بر عهده دارد. زمانی که data دریافت و index شده است و شما قصد دارید از طریق search آن log را مشاهده و استفاده نمایید، نیاز است value های موجود در log به صورت field value در دسترس باشند. هنگامی که extraction انجام می‌شود و field های موجود استخراج یا parse می‌گردند، data شما به نوعی تفسیر می‌شود. فرض کنید log های موجود، شناسایی و مسدودسازی یک attack را گزارش می‌دهند. برای رسیدن به این تفسیر، باید field ها و value های موجود در log را با استفاده از روش‌های موجود extract نمایید. توجه داشته باشید که در اینجا، تفسیر با تحلیل متفاوت است و بیشتر به معنای پردازش و شرح است. log خامی که ارسال می‌شود، در این مرحله process شده و field ها و value های آن استخراج و قابل استفاده می‌گردند. در Splunk، از مسیر settings > fields می‌توان به منوی fields دسترسی یافت و field extraction و parsers موجود برای logs را مشاهده نمود.در فصول آتی، هر یک از این categories به تفصیل شرح داده شده و نحوه پیکربندی آن‌ها آموزش داده خواهد شد. یکی از مفاهیم مهم که باید به تدریج با آن آشنا شوید، تفاوت میان index time و search time است. هنگام index کردن data، مجموعه‌ای از process ها رخ می‌دهد و هنگام مشاهده data از طریق search نیز مجموعه‌ای دیگر از process ها بر روی log اعمال می‌شود تا log نمایش داده شود. field extraction یکی از process هایی است که هنگام مشاهده log، یعنی در زمان search، اتفاق می‌افتد . به عبارت دیگر parse log یا field discovery در زمان search نیز گفته می‌شود. تفاوت index time و search time بسیار گسترده است و در دوره data admin به تفصیل به آن پرداخته خواهد شد. هدف در اینجا صرفاً آشنایی اولیه با این اصطلاح است تا در صورت اشاره به search time در ادامه دوره، ذهنیت کلی از آن وجود داشته باشد.

Event Types : دسته بعدی در knowledge objects، event types هستند که وظیفه data classification را انجام می‌دهند. ممکن است این سوال پیش آید که تفاوت classification و categorization چیست؟ یکجا data دسته بندی می شود و یکجا طبقه بندی می شود. این دو چه فرقی با هم دارند؟ هر دو با metadata همراه هستند و برای مدیریت و حاکمیت data به کار می‌روند. اما categorization بر اساس features یا ویژگی‌های entities موجود در data صورت می‌گیرد، در حالی که classification بر اساس الزامات انجام می‌شود. این موضوع با یک مثال روشن‌تر می‌شود: افراد در زندگی شما father, mother, child و غیره هر کدام در یک category قرار می‌گیرند. اما از منظر classification، برخی جزو family شما هستند و برخی دیگر خیر. این همان classification است. در Splunk، با استفاده از event types می‌توان data را classify یا categorize نمود. ابزار event type برای رسیدن به اهداف خاصی طراحی شده است. ممکن است در رفع یک نیازمندی خاص با event types، لزوماً عمل classify کردن data انجام نشود، اما نیازمندی برطرف گردد. این ابزار برای اهداف مختلفی قابل استفاده است. در فصول آتی که به شرح event type و جنبه‌های technical آن در Splunk پرداخته می‌شود، مثال‌های بیشتری ارائه خواهد شد. از طریق منوی settings > knowledge می‌توان event type را انتخاب و به منوی مربوطه دسترسی یافت. تمام event types در اینجا تعریف و مشاهده می‌شوند. در فصل مربوط به events، توضیحات بیشتری ارائه خواهد شد.
Lookups و Workflow Actions : دسته بعدی شامل lookups و workflow actions است. با استفاده از این دو ابزار می‌توان data enrichment یا غنی‌سازی data را انجام داد. در دوره Splunk Fundamentals 1 به lookups پرداخته شد و در آینده workflow actions نیز مورد بحث قرار خواهد گرفت.
Tags و Field Aliases : دسته بعدی شامل tags و field aliases است که برای normalization داده‌ها به کار می‌روند .داده های دریافتی در Splunk باید به نحوی نرمال‌سازی شوند تا اهداف مشخصی قابل دستیابی باشند.
Data Models : دسته بعدی data models است که data sets را برای ما فراهم می‌کنند. در دوره قبل توضیح مختصری درباره data models ارائه شد و در این دوره توضیحات و کار عملی بیشتری بر روی data models انجام خواهد شد. knowledge objects از نوع tag و field alias ارتباط نزدیکی با data models و data sets دارند. ایجاد tags و field aliases که منجر به نرمال‌سازی log می‌شود، به تکمیل data models و data sets موجود کمک می‌کند.

پس به طور کلی، پنج دسته knowledge object وجود دارد. ممکن است در حال حاضر درک کاملی از تمام توضیحات ارائه شده در خصوص این knowledge objects وجود نداشته باشد. پس از بررسی جزییات در فصول آتی، قطعاً درک عمیق‌تری از این مفاهیم پیدا می کنید و می توانید با این موارد کار کنید و نمونه های بیشتری ببینید. لذا از شما می خواهم ابهامات فعلی را تا رسیدن به topic مربوطه صبوری کنید.

خصوصیات اصلی knowledge object

اکنون که با چیستی knowledge object آشنا شدیم، سه خصوصیت اصلی آن‌ها را نیز مرور می‌کنیم. هر knowledge object دارای سه ویژگی کلیدی است:

Shareable : می‌توان یک knowledge object را ایجاد و با دیگران به اشتراک گذاشت تا آن‌ها نیز قادر به استفاده از آن باشند. پس Reusable هم هستند.
Reusable : می‌توان از آن‌ها به دفعات استفاده کرد.
در Search قابل استفاده هستند: می‌توان هنگام نوشتن search از knowledge objects استفاده نمود.

اهمیت نقش knowledge manager

با توجه به نکات و مفاهیم مهمی که تاکنون در خصوص Splunk مطرح شد و تأکید مکرر بر اهمیت این فصل، اهمیت بالای موارد توضیح داده شده، اکنون احتمالاً واضح است. بنابراین، با توجه به اهمیت موضوع، وجود نقشknowledge manager ضروری به نظر می‌رسد؛ فردی که بر تمام ابعاد این موضوع تسلط داشته و قادر به مدیریت تمامی این موارد باشد. در Splunk با حجم عظیمی از data سروکار داریم و knowledge objects نیز بر روی همین data عمل می‌کنند. این حجم گسترده از فعالیت نیازمند مدیریت شدن توسط فردی است که نیازها را شناسایی و رفع نموده و فرایند normalization مربوط به data را راهبری کند. این نقش همچنین باید در خصوص ایجاد dashboard، به‌ویژه dashboard هایی که بر روی data model ها نیاز به اجرای search دارند، پاسخگو بوده و برنامه‌ریزی لازم را انجام دهد.

Splunk وجود چنین نقشی را در تیم‌هایی که وظیفه maintain و نگهداری Splunk را بر عهده دارند، پیشنهاد می‌کند. اما اگر از Splunk در یک SOC استفاده می‌شود، چنین نقشی ممکن است در چارت سازمانی SOC تعریف نشده باشد و این توضیحات در خصوص knowledge manager احتمالا با ساختار SOC در تضاد باشد. راهکار چیست؟ لزوماً نیازی به تعریف رسمی این نقش در چارت SOC نیست. اگرچه چارت‌های SOC قابلیت customization دارند، اما افزودن چنین نقشی ممکن است منطقی نباشد. با این حال، در ساختار SOC قطعاً بخشی مسئول پیاده‌سازی و نگهداری ابزارهایی مانند Splunk است بسته به scale سازمان و نوع SOC می‌توان مسئولیت‌های این نقش را به یکی از اعضای تیم Splunk محول کرد تا آن شخص موارد را مدیریت کند.

مستندسازی و تجربه شخصی

به عنوان یک مثال از تجربیات شخصی، من در پروژه های مختلف knowledge objectsهایی که وجود نداشته را ایجاد کردم و آن مواردی که وجود داشته را بهبود دادم. به غیر از مباحث technical مربوط به splunk که در دوره های آتی در Splunk پوشش داده خواهد شد، بحث documentation نیز اهمیت فوق‌العاده‌ای دارد. در اکثر پروژه هایی که انجام دادم، به دلیل اهمیت، اولویت با مستندسازی این بخش بوده است، به نحوی که اعضای تیم SOC قادر به مدیریت کردن آن باشند. بنابراین، هنگام ورود به فاز کار با data و اعمال موارد ذکر شده بر روی data، قطعاً به ابزارهایی برای documentation و نگهداری سوابق کار نیاز خواهید داشت. این مستندات بخشی از database مربوط به knowledge management در SOC را تشکیل می‌دهند که برای تمام افراد تیم قابل استفاده است . نحوه استفاده افراد به نقش آن ها در SOC بستگی دارد.

اصرار بر وجود نقش knowledge manager چه در projects که outsource می‌شوند و چه در پروژه‌هایی که به صورت local در سازمان ها انجام می‌گیرند به همین دلیل است. همچنین tools هایی برای documentation و اطلاع‌رسانی نیاز است تا knowledge manager بتواند امور مرتبط را کنترل نماید. در صورت وجود سوال یا ابهام در این زمینه، می‌توانید برای توضیحات بیشتر در خصوص موارد نیازمند ثبت و اطلاع‌رسانی، یا الزامات مورد نیاز از پیمانکاران شخص ثالث، تماس حاصل فرمایید. متأسفانه، پروژه هایی وجود دارند که توسط افراد یا شرکت‌هایی اجرا می‌شوند که نه تنها مستندات مرتبط با موارد ذکر شده را ایجاد یا ارائه نمی‌کنند، بلکه هیچ مستندی در خصوص پیاده‌سازی کلی Splunk نیز وجود ندارد. این امر، صراحتاً، یکی از آسیب‌زننده‌ترین اتفاقات برای یک سازمان است. اگر این ویدئو را مشاهده می‌کنید و به محتوای آن اعتماد دارید، حتماً باید برای این موارد برنامه‌ریزی و راهکار داشته باشید.

نامگذاری knowledge object

نکته پایانی در خصوص knowledge object، به نامگذاری آن‌ها مربوط می‌شود. همانطور که در Fund 1 درباره نامگذاری dashboards, alerts و reports صحبت شد، برای knowledge objects نیز باید یک قاعده نامگذاری وجود داشته باشد. هنگام ایجاد یک knowledge object، باید نامی مناسب انتخاب شود که بیانگر هدف و توضیحات تکمیلی آن knowledge object باشد، به گونه‌ای که با مشاهده نام، هدف از ایجاد آن knowledge object مشخص گردد. پیشنهاد می‌شود نامگذاری knowledge objects با نام گروه که از آن knowledge object استفاده می‌کند یا روی آن کار می‌کند شروع شود، سپس object type را به کار ببریم و در انتها description را بنویسیم. البته این فرمت پیشنهادی باید برای سازمان شما سفارشی‌سازی شود، اما وجود یک فرمت نامگذاری استاندارد ضروری است. زیرا هنگامی که محیط Splunk شما توسعه یافته و مملو از knowledge objects می‌شود، نامگذاری مناسب نه تنها فواید عملی دارد، بلکه به خوانایی و نظم لیست knowledge objects کمک کرده و می‌تواند به عنوان یکی از معیارهای ارزیابی کیفیت کار شما در نظر گرفته شود. علاوه بر جنبه‌های technical که باید به درستی اجرا شوند، مواردی مانند configuration و naming نیز اهمیت دارند. رویکرد نامنظم می‌تواند side effect منفی داشته باشد، در حالی که کار منظم و خوانا، قطعاً points مثبتی به همراه خواهد داشت.

مروری بر Permissionها

در این بخش، مروری بر permissions خواهیم داشت. توجه نمایید که این موارد در ویدئوهای قبلی و دوره گذشته نیز مطرح شده‌اند و در اینجا صرفاً یک جمع‌بندی ارائه می‌شود. تمام objects که در Splunk تعریف می‌شوند، اعم از alert, dashboard یا knowledge object، می‌توانید به آن permission مشخصی بدهید. هنگام ایجاد یک object مانند alert یا dashboard، گزینه‌ای به نام Display For وجود دارد که به طور پیش‌فرض رویowner تنظیم شده است، به طوری که فقط سازنده می تواند آن object را مشاهده کند. با تغییر این تنظیمات و permission هایی که پایین تر لیست شده اند، می‌توان دسترسی users و apps مختلف را کنترل نمود. همانطور که گفته شد، Splunk ماژولار است؛ apps مختلف با permissions خاص خود نصب می‌شوند و users مختلف در groups متفاوت سازماندهی می‌شوند. دسترسی users به apps از طریق permissions تخصیص داده شده به groups کنترل می‌شود. بنابراین، هنگام ایجاد یک object، می‌توانید با ترکیبی از این تنظیمات، سطوح دسترسی به آن object را مدیریت کنید. به طور مشابه، برای تغییر permission یک knowledge object نیز فرم مشابهی وجود دارد.

به عنوان مثال، در فرم تغییر permission برای یک event type، دو گزینه اصلی برای سطح اشتراک‌گذاری مانند All apps و This app وجود دارد. اگر دقت کنید گزینه owner اینجا وجود ندارد. در بخش پایین‌تر، لیست groups برای کنترل permission ها قابل مشاهده است. به طور پیش‌فرض، ممکن است فقط admin دسترسی write داشته باشد. برای اعطای مجوز write به دیگران، باید گروه‌های مورد نظر را انتخاب کرده و تغییرات را save نمود.

جدول سطوح دسترسی در Splunk

خلاصه‌ای از سطوح permission و عملکرد هر یک را در این جدول مشاهده می کنید که به شرح زیر است:

Private : هنگامی که یک object به صورت Private تنظیم می‌شود، به طور پیش‌فرض فقط سازنده دسترسی کامل (خواندن و ویرایش) به آن دارد. admin user نیز می تواند آن را ویرایش کند و در صورت اعطای دسترسی، آن را بخواند.
This app only : اگر اشتراک‌گذاری در سطح This app only تنظیم شود، object ساخته شده تنها در context همان app در دسترس خواهد بود. اگر توسط نقشی با سطح power یا admin ایجاد شده باشد، به طور پیش‌فرض فقط admin دسترسی read دارد. می‌توان به گروه‌های user, power و گروه‌های سفارشی، دسترسی read-only اعطا کرد. برای دسترسی write، به طور پیش‌فرض admin دسترسی write دارد و می‌توان این دسترسی را به گروه‌های user, power و گروه‌های سفارشی منتخب نیز اعطا نمود.
All apps : اگر گزینه All apps انتخاب شود، object موردنظر به صورت globally توسط تمام apps قابل دسترسی خواهد بود. اگر توسط admin user ایجاد شده باشد، به طور پیش‌فرض فقط admins دسترسی read و write دارند. برای سایر گروه‌ها، باید دسترسی به صورت دستی اعطا شود و تیک گزینه های مرتبط با گروه را بزنید.

این خلاصه‌ای از permission های موجود در Splunk بود. درک صحیح این مطلب اهمیت دارد، زیرا گاهی مشکلات پیش آمده ناشی از تنظیمات نادرست permission است که ممکن است تشخیص آن زمان‌بر باشد.

معرفی CIM (Common Information Model)

در بخش پایانی این ویدئو، به معرفی app CIM (Common Information Model) می‌پردازیم. این app برای استفاده از قابلیت‌های commercial پلتفرم Splunk ضروری است. این app چه عملکردی دارد؟ با استفاده از آن، در واقع از متدولوژی Splunk برای normalization داده‌ها بهره می‌بریم. یکی از کارکردهای اصلی آن، normalize کردن dataset هاست. به وسیله این app، می‌توان data های مختلف از sources گوناگون را به سادگی با یکدیگر correlate کرد. همچنین، برخی از objects که در این دوره و دوره قبل معرفی شدند، مانند pivots که نیازمند data models هستند، را می‌توان با استفاده از این app ایجاد یا مدیریت نمود، زیرا هنگام نصب این app، مجموعه‌ای از data models نیز نصب می‌شوند. در module 13 توضیحات بیشتری در این خصوص ارائه خواهد شد. در این بخش، هدف صرفاً آشنایی اولیه است. توصیه می‌شود تا module 13، مطالعات بیشتری در این زمینه انجام دهید تا آمادگی ذهنی لازم را داشته باشید.

از همراهی شما تا پایان این ویدئو سپاسگزاریم. امیدوارم مفاهیم به خوبی منتقل شده و این module رضایت‌بخش بوده باشد. تا ویدئو بعدی، خدانگهدار.

ماژول هفت - Creating and Managing Fields

زیرنویس عنوان

سلام. با Module هفتم از دوره Splunk Fundamental 2 در خدمت شما هستیم.در این Module، قرار است در خصوص ایجاد و مدیریت Field ها صحبت کنیم. ابتدا در خصوص متدهای Field Extraction در Splunk صحبت کرده و بررسی می‌کنیم که چه Option هایی وجود دارد و چگونه می‌توانیم از این متدها استفاده کنیم.

Field Extraction در Splunk

در ویدیوهای پیشین و همچنین دوره قبلی، یعنی Splunk Fundamental 1، تا حدی در خصوص Field Extraction صحبت کردیم و گفتیم Splunk به‌صورت خودکار، بر اساس Sourcetype، برخی از Field ها را Discover کرده و می‌شناسد و جفت Key Value ای را که در Log وجود دارد، پیدا کرده و استخراج می‌کند. پیش از آنکه Search Time اتفاق بیفتد و کاربر Logی را جستجو کند، چندین Field وجود داشت که به همراه Event ذخیره و Index می‌شد. این فیلدها شامل Metafield ها و Internal Field ها بودند. Metafield ها مانند Host، Source و Sourcetype، و Internal Field ها مانند _time یا _raw.

Field Discovery و Modeهای مختلف جستجو

هنگامی که Search اتفاق می‌افتد، Field Discovery، فیلدها را از Raw Data مربوط به Event شما استخراج کرده و بسته به Mode جستجوی شما، آن‌ها را نمایش می‌دهد. اگر به یاد داشته باشید، Mode های مختلفی وجود داشت: Fast، Smart و Verbose، که بر اساس آن، Field Discovery اتفاق می‌افتد. حال، شرایطی را فرض کنید که Log هایی وجود دارد که Field Extraction روی آن‌ها اتفاق نمی‌افتد. با وجود اینکه Mode جستجوی شما Verbose است، Log ها به‌اصطلاح Parse نمی‌شوند و Field Value ای که داخل Log وجود دارد، برای شما نمایش داده نمی‌شود؛ صرفاً Log خام نمایش داده می‌شود. بنابراین، شما در اینجا نیاز دارید فیلدهایی را که در Log وجود دارند، Extract کنید. یا تصور کنید Log هایی وجود دارد که برخی از Field های آن Extract می‌شود و هنگام جستجو می‌توانید از آن‌ها استفاده کنید، اما هنگامی که Log را به‌طور کامل بررسی می‌کنید، مشاهده می‌کنید که مثلاً چند Field و Value وجود دارد که Field مشخصی برای آن‌ها تعریف نشده یا استخراج نشده و به‌اصطلاح آن قسمت Extract یا Parse نمی‌شود و شما نیاز دارید که Field های خود را Extract کنید.

Field Extractor

Splunk ابزاری به نام Field Extractor دارد که به وسیله آن می‌توانید Field ها و Value هایی را که در Log مدنظرتان است، Extract کنید. پس از آن، هنگامی که آن Log را جستجو می‌کنید، Field های مورد نظر به شما نمایش داده می‌شود. شما می‌توانید از چند طریق به Field Extractor یا به‌اصطلاح FX در Splunk دسترسی داشته باشید:

می‌توانید از Menu مربوط به Setting، به قسمت Fields وارد شوید. همزمان، یک صفحه Search را نیز باز می‌کنم. سپس گزینه Field Extractions را انتخاب کنید و در صفحه‌ای که باز می‌شود، گزینه Open Field Extractor را انتخاب کنید. این صفحه اول Field Extractor در Splunk است.
اما از روش دیگری نیز می‌توان به این قسمت دسترسی پیدا کرد. در صفحه Search، باید جستجویی را بنویسیم که ما را به Log های مدنظر می‌رساند و آن را اجرا کنیم تا Log های Parse نشده یا Log هایی که ناقص Parse شده‌اند را مشاهده کنیم. همان‌طور که در تصویر مشاهده می‌کنید، Mode جستجوی من Verbose است و هنگامی که Log ها را بررسی می‌کنم، Fieldی را نمی‌توانم بیابم که به‌درستی Extract شده باشد تا بتوانم از آن استفاده کنم. گزینه‌ای در این قسمت ستون سمت چپ با نام Extract New Fields وجود دارد. هنگامی که روی این گزینه کلیک کنم، به همان محیط Field Extractor منتقل می‌شوم. اما تفاوت آن در این است که با این روش، Sourcetype از قبل بر اساس جستجو انتخاب شده است، در حالی که هنگام اقدام از طریق Menu، باید Sourcetype را به‌صورت دستی انتخاب کنم. هنگامی که از طریق صفحه Search به این بخش وارد می‌شوم، تقریباً یک گام جلوتر هستم.

اکنون در این محیط Field Extractor، باید Sample Event مورد نظر را انتخاب کرده، در گام بعدی متد Extraction را انتخاب کنیم و پس از آن، استخراج Field ها را آغاز نماییم.

آشنایی با مفهوم Regular Expression

پیش از آشنایی با بخش‌های مختلف، ابتدایی‌ترین و مهم‌ترین نکته‌ای که وجود دارد، این است که باید بدانید Field Extraction یا Parse کردن Log، توسط مفاهیم Regex یا Regular Expression اتفاق می‌افتد. اگر شما به این مباحث مسلط هستید، می‌توانید به‌راحتی خارج از Splunk، Log ها را Parse کرده، Regex مرتبط با آن را بنویسید و در Field Extractor مربوط به Splunk از آن استفاده کنید. اما اگر روی مباحث Regex مسلط نیستید و نمی توانید خودتان به راحتی Regular Expression بنویسید، می توانید از متدهای Splunk استفاده کنید اما بدانید که Regular Expression ها یا Regex ها برای Parse کردن Log استفاده می شوند و نیاز است که شما روی این مباحث مسلط شوید. در دوره های آینده ما این مباحث را نیز در سرفصل ها داریم. اینجا فقط می خواهیم با Field Extractor در Splunk آشنا شویم. اگر می خواهید از بعضی متدهای Field Extractor استفاده کنید باید تا حدی با Regex آشنا باشید که بتوانید Regex ای که توسط Field Extractor تولید می شود را بهبود دهید و از آن استفاده کنید اما اگر با Regex آشنایی نداشته باشید، نمی توانید به خوبی از برخی متدها استفاده کنید و بعد از اینکه با Regular Expression آشنایی پیدا کردید، این ویدئو را مجددا ببینید تا مباحث را بهتر درک کنید.

ورود دستی Regular Expression

اگر شما از پیش، Regex مربوط به Log هایی که می خواهید Parse کنید را دارید و نوشتید می توانید با استفاده از این گزینه، آن Regex را در کادر مربوطه وارد کرده، با استفاده از دکمه Preview خروجی آن را مشاهده کنید و در صورتی که صحیح و بدون مشکل بود، روی دکمه Save کلیک نمایید. دقت کنید که برای استفاده از این قسمت، باید از قبل Regex مرتبط با استخراج Field های Log های خود را نوشته باشید و صرفاً در اینجا آن را آزمایش کنید.

به عنوان مثال، من از قبل Log ها را بررسی کرده‌ام و نیازمندی من این بوده است که در Log ها، پس از کلمه "user"، هر کاراکتری که وجود دارد، به عنوان مقدار فیلد "user" برای من استخراج شود. Regex مورد نظر را در اینجا وارد کرده و روی دکمه Preview کلیک می‌کنم. همان‌طور که مشاهده می‌کنید، در اینجا فیلد "user" برای من استخراج شده و در Log ها به‌صورت Highlight نمایش داده می‌شود. البته Log هایی نیز وجود دارد که فرمت متفاوتی دارند و Regex نوشته‌شده با آن‌ها مطابقت ندارد، اما برای Log هایی که Highlight شده‌اند، مطابقت صورت گرفته و Value های استخراج‌شده نمایش داده می‌شود. بدیهی است که باید این Regex را بهبود دهم تا با تمام Log ها منطبق باشد، یا برای Log هایی که منطبق نیستند، Regex جداگانه‌ای تعریف کنم. بنابراین، این روش نوشتن دستی Regex نیز در صورتی مناسب است که به Regex و مباحث Regular Expression مسلط باشید، یا Regex را از منبع دیگری دریافت کرده و قصد دارید آن را در Splunk خود پیاده‌سازی و آزمایش کنید و در نهایت ذخیره نمایید.

انتخاب و بررسی Sample Event

به صفحه Sample Event بازگشتیم و اکنون می‌خواهیم Event نمونه را انتخاب کنیم. از جدول پایینی، Log مورد نظر خود را انتخاب کنید. هنگامی که روی آن کلیک کنید، Log در این قسمت نمایش داده می‌شود. گزینه‌هایی در اینجا وجود دارد، مانند تعیین تعداد Sample Event هایی که در جدول زیرین نمایش داده می‌شوند. هنگامی که شما روی Log نمونه کار می‌کنید، عملیات استخراج با سایر Log های موجود در جدول نیز مقایسه می‌شود تا از صحت عملکرد اطمینان حاصل شود. همچنین گزینه‌ای برای لحاظ کردن یا نکردن جستجوی اصلی Original search included وجود دارد. اگر به یاد داشته باشید، ما از صفحه Search به این صفحه وارد شدیم. اگر تیک این گزینه را برداریم، آن جستجویی که در صفحه قبل اجرا شده بود، در Background نادیده گرفته می‌شود و دیگر در نتایج اینجا تأثیری نخواهد داشت. بنابراین، بهتر است این گزینه فعال باشد.

انتخاب متد استخراج Fieldها

پس از انتخاب Log نمونه Sample، روی دکمه Next کلیک می‌کنیم. در صفحه بعد، باید متد مورد نظر را انتخاب کنیم. گفتیم Splunk برای استخراج Field ها، چندین متد متفاوت دارد. متد اول، استفاده از Regular Expression و متد دوم، استفاده از Delimiter ها یا جداکننده‌ها است.

هنگامی که Log های خود را بررسی می‌کنید، برخی Log ها وجود دارند که Structure خاصی دارند و شما می‌توانید با استفاده از Delimiter، به‌راحتی Field ها و Value های مختلف را از هم تشخیص داده، جدا کنید و در نهایت، به سادگی Field های مدنظرتان را Extract نمایید. به عنوان مثال، Log هایی وجود دارند که Value های داخل Log با کاما , از هم جدا شده‌اند. در این صورت، شما به‌راحتی می‌توانید از متد Delimiter استفاده کرده و Log های خود را Parse کنید.

تجزیه Log با Regular Expression

اما Log هایی نیز وجود دارند که Unstructured هستند؛ یعنی Structure خاصی ندارند که بتوانید به وسیله جداکننده‌ها Delimiter ها Log خود را Parse کنید Logی که به عنوان نمونه انتخاب شده است، یک Log از نوع Unstructured است و جداکننده ای ندارد که مثلا بتوانیم ip را از port جدا کنیم و باید از Regular Expression استفاده کنیم. به وسیله این گزینه Field Extractor مربوط به Splunk سعی می کند فیلدها را به وسیله Regular Expression ای که با Event مربوطه Match می شود Extract کند. اما با استفاده از گزینه Delimiter شما می توانید کاراکتری را انتخاب کنید، مثل Space، Comma، Pipe، Tab ریا هر کاراکتر دیگری که در Log شما نقش جداکننده Value ها را دارد. با استفاده از این گزینه و تشخیص آن کاراکتر، شما به راحتی می توانید Log را Parse کنید. Log ای که به عنوان نمونه استفاده شده، یک Log غیرساختاریافته است که باید از Regular Expression استفاده کنیم. روی گزینه Regular Expression و سپس روی دکمه Next کلیک می‌کنیم.

در صفحه بعد، هنگامی که Sample Log به شما نمایش داده می‌شود، قسمت‌هایی را که می‌خواهید Extract کنید، باید Highlight نمایید. به محض اینکه دکمه ماوس را کلیک کرده و در انتهای کاراکترهای مورد نظر دکمه را رها کنید، پنجره‌ای برای شما باز می‌شود که از شما می‌خواهد نام Field را وارد نمایید. به عنوان مثال، قسمتی که من انتخاب کردم به User اشاره دارد؛ نام این Field را "user" قرار داده و روی دکمه Add Extraction کلیک می‌کنم. همین‌طور، قسمت بعدی که می‌خواهم استخراج کنم، Port است. در پنجره‌ای که باز می‌شود، دو گزینه وجود دارد که باید یکی را انتخاب کنیم Extract و Require . گزینه Extract را که با هم آزمایش کردیم؛ اما فعال کردن گزینه Require باعث می‌شود که این استخراج فقط روی Event هایی اعمال شود که قسمتی را که شما Highlight کرده‌اید، دارا باشند. بنابراین، در نتیجه احتمالاً Event هایی وجود دارند که این قسمت را ندارند و Extraction ما با آن‌ها Match نخواهد شد که همان‌طور که اشاره شد، این عدم تطابق در جدول پایین مشخص می‌شود. نام این Field را نیز مثلاً "port" انتخاب کرده و روی دکمه Add Extraction کلیک می‌کنم.

پس از اینکه تمام قسمت‌های مورد نظر خود را انتخاب و نام‌گذاری کردید، در قسمت پایین‌تر می‌توانید یک Preview از کل Field های استخراج‌شده داشته باشید و اگر مشکلی وجود داشت، آن را برطرف کنید. پس از اتمام کار، روی دکمه Next کلیک کنید.

مرحله Validate و بهینه‌سازی Regular Expression

در صفحه بعد Validate، می‌توانید موارد را صحت‌سنجی کنید. حتی می‌توانید Regular Expressionی را که Splunk به‌صورت خودکار تولید کرده است، مشاهده نمایید. برای این کار، باید روی گزینه Show Regular Expression کلیک کنید. همان‌طور که در تصویر مشاهده می‌کنید، اکنون Regular Expression مورد نظر، نوشته شده و نیازمندی ما را مرتفع می‌سازد و Field هایی را که می‌خواهیم، استخراج می‌کند. اما مشکل اساسی که وجود دارد، این است که این Regex اصلاً بهینه نیست و اگر شما با مباحث Regular Expression حداقل آشنایی داشته باشید، می‌دانید که این نوع Regular Expression غیربهینه، می‌تواند بار زیادی روی سیستم شما ایجاد کند. پیشنهاد خود Splunk نیز همین است که پس از استخراج Field ها با استفاده از متد Regular Expression خودکار Splunk، در مرحله Validate، آن Regular Expression تولیدشده را بهینه و تصحیح نمایید. برای این کار، کافی است اطلاعات اولیه‌ای از Regular Expression داشته باشید تا بتوانید Regex ای را که در نهایت توسط Field Extractor مربوط به Splunk تولید می‌شود، بهبود بخشیده و از آن استفاده کنید.

به عنوان مثال، اگر بخواهیم همین Regex را بهبود دهیم، روی دکمه Edit کلیک کرده و سپس این بخش از Regex را اصلاح می‌کنیم. اگر دقت کنید، آن تعداد زیاد کاراکتر Regular Expression به چند کاراکتر ساده‌تر تبدیل شد. پس از کلیک روی Preview، مشاهده می‌کنیم که Field هایی که مدنظر ما بود، همچنان استخراج می‌شوند و می‌توانیم از آن‌ها استفاده کنیم. روی دکمه Save کلیک می‌کنم و در نهایت، بخش Save برای من باز می‌شود که باید نام Extraction و Permission های آن را مشخص کنم. همان‌طور که در ویدیوهای قبلی در خصوص Permission گفته شد، بهتر است آن را روی All apps تنظیم کنیم تا مشکلات کمتری پیش آید و سایر App ها نیز بتوانند از این Regular Expression استفاده کنند.

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

پس از اینکه Field Extractor خود را ذخیره کردیم، مجدداً به Log ها بازگشته و بررسی می‌کنیم که آیا Field های مدنظرمان استخراج شده‌اند یا خیر. همان‌طور که مشاهده می‌کنید، اکنون Field مربوط به "user" و همچنین Field مربوط به "port" را داریم. بنابراین، Field Extractionی که تعریف کردیم، به درستی کار می کند و با استفاده از Regular Expression نوشته شده است.

تجزیه Log با Delimiter

حال اگر بخواهیم از Delimiter استفاده کنیم، چگونه عمل می‌کنیم؟ برای اینکه بتوانیم مثالی با Delimiter داشته باشیم، از Log های Apache استفاده می‌کنم. اگرچه این Log در حال حاضر Parse می‌شود، اما صرفاً برای آزمایش، به آن بخش Field Extractor مراجعه می‌کنیم. روی گزینه Extract New Fields کلیک می‌کنیم. Sourcetype به صورت خودکار بر اساس جستجوی قبلی انتخاب شده است و ما صرفاً Sample Event را انتخاب می‌کنیم. روی دکمه Next کلیک کرده، گزینه Delimiters را انتخاب می‌کنم و مجدداً Next را می‌زنم. در این صفحه، باید جداکننده‌ای Delimiter را که داخل Log وجود دارد، انتخاب کنم. هنگامی که Log را بررسی می‌کنم، مشاهده می‌کنم که به احتمال زیاد، جداکننده Space در اینجا می‌تواند مفید باشد؛ بنابراین روی گزینه Space کلیک می‌کنم. بلافاصله پس از کلیک، Log ما به قسمت‌های مختلف، با نام Field های پیش‌فرض، تجزیه می‌شود. اگر دقت کنید، بر اساس فاصله‌های موجود در Log، مقادیر مختلف از هم مجزا شده و تحت عنوان یک Field با نام پیش‌فرض field1, field2, ... به شما نمایش داده می‌شود. شما می‌توانید نام هر Field را Edit کنید. بنابراین، باید نام تمام Field های مورد نیاز را به نام‌های مدنظر خود تغییر دهید. اگر Log خود را بررسی کردید و مشاهده نمودید که جداکننده، کاراکتری غیر از Space است و آن کاراکتر در گزینه‌های پیش‌فرض وجود ندارد، از فیلد Other استفاده کرده و کاراکتر جداکننده خود را در آنجا وارد می‌کنید.

به عنوان مثال، اگر کاراکتر جداکننده، تک کوتیشن ' یا دابل کوتیشن " بود، خروجی به شکل زیر مشاهده می‌شود یا اگر دو نقطه : بود، باز هم تغییراتی در تجزیه Log رخ می‌داد که به ظاهر صحیح نیست. در مثال ما، همان Space صحیح است و از آن استفاده می‌کنیم. پس Log خود را به دقت بررسی کنید. احتمال دارد جداکننده Comma، Space یا Tab باشد. مهم این است که Log شما باید Structured باشد و کاراکتر جداکننده را تشخیص دهید. و در نهایت، پس از تغییر نام Field های مورد نیاز، روی دکمه Next کلیک کرده و می‌توانید Extraction تعریف‌شده را ذخیره کنید و در آخر، اگر به Log مورد نظر خود بازگردید، آن را به صورت Parse شده مشاهده خواهید کرد.

بنابراین، تا اینجای ویدیو آموختیم که چگونه Log را به‌وسیله دو متد Regular Expression و Delimiter تجزیه کنیم و در نهایت، Field Value های موجود در Log را استخراج کرده تا بتوانیم از Field های استخراج‌شده در جستجوهای Search خود استفاده نماییم.

اهمیت بهینه‌سازی Regex و مشورت با متخصص

نکاتی را که مطرح شد، در این بخش حتماً جدی بگیرید، زیرا این یکی از مهم‌ترین قسمت‌ها بوده و بر کیفیت Data شما تأثیر مستقیم دارد. حتماً به بهترین نحو ممکن Log را Parse کنید و تا حد امکان از Regular Expression های بهینه استفاده نمایید و از به کار بردن Regular Expression هایی که مناسب Log شما نیستند، بپرهیزید. اگر اطلاعات شما در زمینه Regular Expression کم است، حتماً با فرد متخصصی مشورت کرده و سپس Regular Expression های مربوط به Parse کردن Log را روی Splunk اعمال کنید.

در فصل‌های پیشین نیز اشاره شد که قرار نیست تمام کارها را ما در Splunk انجام دهیم، اما باید روش‌ها را بیاموزیم تا پس از آن بتوانیم از راه‌های دیگر نیز نیازمندی‌های خود را برطرف سازیم. برای رفع این نیازمندی‌ها، راه‌حل‌های مختلفی وجود دارد که در ادامه با آن‌ها آشنا خواهیم شد؛ اما تسلط بر مباحث Regular Expression اهمیت ویژه‌ای دارد. در دوره‌های آینده نیز در خصوص Regular Expression صحبت خواهیم کرد، اما توصیه می‌شود زودتر به سراغ یادگیری و مطالعه آن بروید تا بتوانید در کارهای خود از آن استفاده کنید. این فصل نیز به پایان رسید. از اینکه تا اینجا همراه من بودید سپاسگزارم. تا ویدیوی آینده، خدانگهدار.

ماژول هشت - Creating Field Aliases and Calculated Fields

زیرنویس عنوان

با ماژول هشتم دوره Splunk Fundamental ۲ همراه شما هستیم. در این ماژول، ابتدا در خصوص ایجاد و استفاده از field alias و سپس در خصوص ایجاد و استفاده از calculate fields صحبت خواهیم کرد. پیش از پرداختن به مباحث technical، ابتدا بررسی می‌کنیم که field alias چیست.

field alias چیست؟

واژه alias به معنی نام مستعار است؛ یعنی برای یک field، نام مستعاری تعریف می‌شود. به عنوان مثال، اگر نام یک field برابر X باشد، می‌توان برای آن field نام مستعار Z را تعریف کرد، به گونه‌ای که هر مقداری که در field اصلی وجود دارد، در field alias آن نیز موجود باشد. پرسشی که در اینجا مطرح می‌شود این است که اساساً چرا باید چنین اقدامی انجام داد و field alias تعریف کرد؟

چرا باید از field alias استفاده کنیم؟

هنگامی که قصد دارید data را بر اساس standards که در فصل‌های آینده به آن پرداخته خواهد شد نرمال‌سازی کنید، یکی از روش‌هایی که می‌توان برای انجام normalization استفاده کرد، تعریف field alias است. به عبارت دیگر، بر اساس مستندات و استانداردهای normalization اسپلانک که مطالعه و بررسی شده‌اند، ممکن است در logs خود مشاهده کنید که چندین field وجود دارد که نام آن‌ها با استاندارد CIM مطابقت ندارد و یکی از روش‌های انجام این normalization، تعریف field alias است.

یکی از نکات مهمی که وجود دارد، این است که می‌توان چندین field alias چندین نام مستعار برای یک field ایجاد کرد. به این نکته باید دقت نمود که field alias پس از field extraction اتفاق می‌افتد؛ ابتدا field ها extract می‌شوند و سپس field alias ها اعمال می‌گردند و پس از آن، automatic lookups که تعریف شده‌اند در ادامه همین ویدیو به تفصیل در خصوص این مورد توضیح داده خواهد شد. اگر بخواهیم یک flashback به ماژول قبل داشته باشیم، در ماژول قبل در خصوص field extraction صحبت کردیم و پیش‌تر از آن، در خصوص knowledge objects صحبت شد و گفته شد که دسته‌بندی‌های مختلفی در خصوص knowledge objects وجود دارد که یکی از آن‌ها field extraction بود که در ماژول قبل به طور کامل یاد گرفتیم و دسته‌بندی دیگری از knowledge objects، field alias ها بودند که در این ماژول در خصوص آن صحبت می‌کنیم. زمانی که قصد استفاده از log ها وجود دارد، ابتدا field extraction اتفاق می‌افتد و سپس field alias هایی که تعریف شده‌اند، روی آن log ها اعمال می‌شوند. پس نتیجه‌گیری می‌شود که اگر extraction وجود نداشته باشد یا با مشکل مواجه باشد، field alias هایی هم که تعریف شده‌اند، احتمالاً دچار مشکل خواهند شد.

فایده تعریف field alias

زمانی که از field alias استفاده می‌شود و برای چندین field در data های مختلف، alias تعریف می‌گردد، یکی از مزایایی که به همراه دارد، این است که بین data های مختلف، correlate ایجاد می‌شود و پس از آن، فرایند search توسط کاربران در Splunk به احتمال زیاد بسیار آسان‌تر خواهد شد.

مثالی که در تصویر است را مشاهده کنید. در log هایی که در تصویر مشاهده می‌شود، سه Log مختلف از سه source type متفاوت وجود دارد. در log اول، حرف ابتدایی فیلد username بزرگ نوشته شده است و در log دوم، فیلد username تماماً با حروف کوچک نوشته شده است و اگر به یاد داشته باشید، در ویدیوهای قبلی ذکر شد که نام field، case sensitive است و بر اساس همین قاعده، این دو field اساساً همنام نیستند. در log آخر نیز فیلد User وجود دارد که حرف ابتدایی این field با حروف بزرگ نوشته شده است. پس برای جمع‌بندی، در این سه log که مشاهده می‌کنید، field هایی که username در آن‌ها به کار رفته و username ای هم که مشاهده می‌شود که یکی است، کاملاً با هم متفاوت هستند و نرمال نیستند. ما باید این‌گونه مشکلات را برطرف کنیم و log را normalize نماییم. اینکه اساساً این field ها را باید با چه نامی تعریف کرد، در مستند CIM نوشته شده است؛ مستندی که در module ۱۳ در خصوص آن بیشتر صحبت خواهد شد. پس این موضوع را در نظر داشته باشید که Splunk برای نام field ها نام field هایی که مورد نیاز است از قبل برنامه‌ریزی کرده و مستند و راهنمایی تدوین نموده است که در آن راهنما و مستند، برای مثال، گفته شده است که اگر field ای از جنس نام user وجود دارد، باید نام آن مطابق با استانداردی که Splunk تعیین می‌کند، قرار داده شود.

در این مثالی که مشاهده می‌شود، اگر به مستندات CIM مراجعه کنید و به data model مربوط به authentication بروید، مشاهده خواهید کرد که این data model به یک field به نام user نیاز دارد که تمام حروف این field به صورت کوچک نوشته شده است. شما باید برای تمام این field هایی که در اینجا مشاهده می‌کنید، alias ای به نام فیلد user تعریف کنید. دقت کنید که در CIM، در data model ها، field هایی که مورد نیاز هستند، هیچ‌کدام با حروف بزرگ شروع نمی‌شوند و با حروف کوچک هستند. پس در نتیجه این مثال ما که log های مختلف از sources متفاوت وجود دارد، تمام این field هایی که مشاهده می‌کنید و به user اشاره دارند، تبدیل به یک فیلد user می‌شوند. زمانی که قصد دارید search کنید، در تمام این log ها فقط کافی است بنویسید username مساوی با username مورد نظر و پس از آن، در تمام source type ها به صورت مشترک، search انجام می‌شود و شما می‌توانید یک user را در log های مختلف پیدا کنید.

اگر این normalization را انجام ندهید، search ای که می‌نویسید باید یک بار شامل Username با U بزرگ، یک بار username با u کوچک و یک بار User با U بزرگ باشد که این امر، پروسه search را تا حدی دشوار می‌کند. بنابراین، normalization ای که انجام می‌دهید، به غیر از مزایایی که در سیستم به همراه دارد، در search نیز مزایای زیادی خواهد داشت.

نحوه تعریف field alias در Splunk

در این قسمت، می‌خواهیم یک مثال عملی داشته باشیم و یک field alias تعریف کنیم. اگر به خاطر داشته باشید، در ویدیوی قبلی یک source type log وجود داشت که به وسیله field extractor اسپلانک، دو field user و port را extract کردیم. اکنون می‌خواهیم یک field alias برای field port تعریف کنیم. field port باید مشخص شود که source port است یا destination port. به همین دلیل، می‌خواهیم برای field port که extract کرده‌ایم، یک نام مستعار بسازیم تا از این پس بتوانیم با آن نام مستعار کار کنیم.

برای تعریف field alias، از منوی settings گزینه Fields را انتخاب می‌کنم و در صفحه‌ای که باز می‌شود، گزینه Field aliases را انتخاب می‌نمایم. در صفحه‌ای که باز می‌شود، می‌توان field alias هایی که قبلاً تعریف شده‌اند را مشاهده کرد. در ابتدای این صفحه بالای صفحه، چندین فیلد وجود دارد که می‌توان جدول پایین را با استفاده از آن‌ها filter کرد و خروجی بر اساس filter نمایش داده خواهد شد. برای مثال، در این filter، field alias هایی که در app مربوط به Search & Reporting و در این app ایجاد شده‌اند، قابل نمایش هستند. می‌توان این filter ها را تغییر داد؛ مثلاً روی app های دیگر یا روی app با مقدار All تنظیم کرد. این بستگی دارد که در اینجا به دنبال چه چیزی هستید تا بتوانید filter آن را دقیقاً مشخص کنید. اما اگر بخواهید alias جدیدی بسازید، روی دکمه New کلیک می‌کنید.

در فرمی که مشاهده می‌شود، ابتدا باید مشخص کرد که تنظیمات مرتبط با این configuration که در حال انجام آن هستید، کجا ذخیره شود و سپس باید یک نام به آن اختصاص داد. ما در ویدئوهای قبلی در خصوص نحوه نام‌گذاری objects صحبت کردیم. اکنون من یک نام اختصاص می‌دهم. پس از آن، باید apply to را مشخص کنیم. apply to یعنی این تنظیماتی که در حال ایجاد آن هستید، روی چه log ای اعمال شود؟ بر اساس سه پارامتر source type، source و host می‌توان انتخاب کرد و پس از اینکه این را انتخاب کردیم، باید مقدار آن را ارائه دهیم. برای مثال، اگر من آن را روی source type تنظیم کنم، باید به search خود بازگردم و source type مورد نظر را برای آن انتخاب کنم. می‌توانم host را انتخاب کنم یا source را. اگر host را انتخاب کنم، باید به search خود بازگردم و host ای که مد نظرم هست را انتخاب کنم.

در این مثال، چهار host را مشاهده می‌کنید. من اگر بخواهم بر اساس host انتخاب کنم، باید تک‌تک برای host ها، field alias تعریف کنم. اما اگر بر اساس source type انتخاب کنم و پیکربندی‌ام بر اساس source type باشد، روی همه host هایی که این source type را دارند، اعمال می‌شود. من از source type استفاده می‌کنم. قسمت بعدی، باید نام field ای که در layer ما وجود داشت را ذکر کنیم و سمت راست علامت مساوی =، باید نام field جدیدمان نام field مستعارمان را ذکر کنیم. یک دکمه add نیز وجود دارد؛ زمانی که بخواهید برای چندین field، alias تعریف کنید، می‌توانید از این گزینه استفاده کنید؛ نام field هایی که وجود دارند را ذکر کنید و سمت راست علامت مساوی، نام field های جدید alias هایتان را تعریف نمایید.

در انتهای این فرم، گزینه‌ای به اسم overwrite field value وجود دارد. زمانی که شما یک alias تعریف می‌کنید، چندین شرایط مختلف به وجود می‌آید. یک شرایط این است که احتمالاً log هایی وجود دارند که این field را ندارند و شرایط دیگر زمانی است که log هایی وجود دارند که نام field ای که به عنوان alias انتخاب شده، در log ها از قبل وجود دارد. Splunk به این موضوع فکر کرده و متوجه شده است که این شرایط امکان دارد پیش بیاید. زمانی که alias تعریف می‌کنید، به احتمال زیاد با چند مشکل مواجه خواهید شد: زمانی که فیلد original ای که در حال تعریف آن هستید، در log وجود نداشته باشد و زمانی که نام تکراری انتخاب می‌کنید. خب، اینجا Splunk باید چگونه تصمیم بگیرد؟ با این گزینه‌ای که وجود دارد، می‌توان این اوضاع را کنترل کرد. زمانی که شما این گزینه را انتخاب می‌کنید و alias name شما از قبل وجود داشته باشد، field ای که شما به عنوان alias تعریف کرده‌اید، جایگزین آن field می‌شود. اما زمانی که این گزینه را انتخاب کرده‌اید و این field وجود ندارد یا value ای ندارد، field alias شما remove می‌شود و هیچ چیزی اعمال نمی‌گردد.

در documentation مربوط به Splunk یک table وجود دارد که در تصویر با هم مشاهده می‌کنیم. در این تصویر، مفصل‌تر توضیح داده شده است. در همین تصویر، یک example وجود دارد که فیلد DST به عنوان alias برای فیلد source تعریف شده است و اگر گزینه overwrite تیک زده شده باشد یا نشده باشد، چه شرایطی به وجود می‌آید. در این table به صورت خلاصه مشاهده می‌کنید. توضیحاتی که خدمتتان عرض کردم، در documentation مربوط به Splunk هم وجود دارد. اما نکته‌ای که وجود دارد این است که من بیشتر مواقع این گزینه را فعال نمی کنم؛ چرا؟ چون می‌دانم field هایی که تعریف می‌کنم، بر اساس standard هستند و در log هایی که می‌خواهم این اعمال شود، از قبل وجود ندارند و field ای که به عنوان original field خود در نظر می‌گیرم، در log هایی که مد نظرم هست، قطعاً وجود دارد و طبق یک plan من field alias ایجاد می‌کنم. خب، در آخر روی گزینه save کلیک می‌کنم و بلافاصله بعد از اینکه field من ذخیره شد، permission آن را تغییر می‌دهم.

بعد از اینکه field alias تعریف شد و شما permission آن را تغییر دادید، به log های خود بازمی‌گردید و یک بار دیگر search خود را اجرا می‌کنید. log ها را بررسی می‌کنید که آیا field اضافه شده است یا نه. خب، همانطور که مشاهده می‌کنید، بعد از field port، field source port را داریم که field source port، alias مربوط به field port است.

calculate fields

تا اینجای ویدیو، ما یاد گرفتیم field alias چیست و چگونه می‌توانیم آن را تعریف کنیم. در قسمت آخر این ویدیو، می‌خواهیم در خصوص calculate fields صحبت کنیم. در ویدیوهای قبلی، در خصوص command مربوط به eval صحبت کردیم. اگر به یاد داشته باشید، گفتیم به وسیله eval command و functions موجود در آن، می‌توانیم یک سری mathematical operations، یک سری transformations انجام دهیم و یک سری functions وجود داشت که از آن‌ها استفاده کنیم. حال تصور کنید شما دائماً در حال استفاده از eval command هستید که باعث می‌شود یک سری repetitive operations و complex را مدام تکرار کنید. ما می‌توانیم با استفاده از calculated fields، آن eval command ای که در search می‌خواهیم استفاده کنیم را در background تعریف کنیم و زمانی که شما به آن log ها می‌خواهید دسترسی پیدا کنید، آن عملیاتی که با eval انجام می‌شود، در background انجام شده و خروجی آن در قالب یک field به شما نمایش داده شود. برای مثال، در تصویری که مشاهده می‌کنید، از command مربوط به eval استفاده کرده‌ام تا field byte را به kilobyte تبدیل کنم. یک field در log ها وجود دارد به اسم byte که نیازمندی من byte نیست، kilobyte است و با استفاده از eval command، یک field kilobyte تعریف کرده‌ام. اکنون می‌خواهم با استفاده از calculated fields، این eval را در background پیاده‌سازی کنم و زمانی که به این log ها می‌خواهم دسترسی داشته باشم، دیگر به صورت خودکار این field kilobyte برای من ساخته شود.

در منوی settings، گزینه Fields را انتخاب می‌کنم و در صفحه‌ای که باز می‌شود، Calculated Fields را انتخاب می‌نمایم. در صفحه‌ای که برای من دوباره باز می‌شود، تمام Calculated Field هایی که از قبل تعریف شده‌اند، لیست می‌شوند و می‌توانم با کلیک روی گزینه New، calculated field جدیدی تعریف کنم. در فرم calculated field، یک سری گزینه‌ها تکراری هستند. destination app را قبلاً داشتیم. apply to هم همین‌طور. من می‌خواهم از source type استفاده کنم که source type مد نظرم را از search کپی می‌کنم و به فرم منتقل می‌نمایم.

گزینه بعدی name و eval expression است. در قسمت name، باید نام field ای را ذکر کنیم که می‌خواهیم نتیجه اجرای eval command داخل آن field قرار بگیرد؛ در این مثال، kilobyte است. در قسمت بعدی eval expression، ما فقط نیاز داریم که expression مورد نظرمان را وارد کنیم؛ دیگر نیاز نیست بنویسیم eval، نام field مساوی... هر چیزی که بعد از علامت مساوی در search بود را نیاز داریم وارد کنیم. برای مثال، به search خود بازمی‌گردیم. در search نوشته بودیم eval kilobyte = ، یک عملیات ریاضی. اصلاً نیاز نیست سمت چپ علامت مساوی را در قسمت eval expression کپی کنیم؛ فقط نیاز است که این قسمت اصلی را در expression کپی کنیم و بعد روی دکمه save کلیک می‌کنم و بلافاصله بعد از ذخیره شدن، permission را تغییر می‌دهم.

بعد از اینکه field ما ذخیره شد، چند دقیقه‌ای صبر می‌کنیم و برمی‌گردیم به search و search را دوباره اجرا می‌کنیم. ابتدا دستور eval را پاک می‌کنم و بعد search را دوباره اجرا می‌نمایم تا ببینم آیا kilobyte اضافه می‌شود یا نه. خب، همانطور که می‌بینید، فیلد kilobyte اضافه شده است. این field یک calculated field است که پشت آن یک eval expression وجود دارد و آن عملیاتی که ما می‌خواهیم را به وسیله دستور eval در background اجرا می‌کند و خروجی آن را در field مورد نظر کپی می‌نماید.

این ماژول هم به پایان رسید. در این ماژول، استفاده از field alias و calculated fields را یاد گرفتیم. این ماژول هم یکی از مهم‌ترین ماژول‌هاست، چون روی data کار می‌شود و یکی از اهداف این ماژول‌ها، normalization مربوط به data است که بحث normalization مهم‌ترین بحث در SIEM هاست. پس خواهشمندم این فصل را تمرین کنید و جدی بگیرید و اگر توانستید، در خصوص CIM و data models مطالعه کنید تا در ماژول ۱۳ در خصوص آن بیشتر صحبت کنیم. ممنونم که همراه من بودید. تا ویدیوی بعدی، خدانگهدار.

ماژول نه - Creating Tags and Event Types

زیرنویس عنوان

سلام. با module ۹ از دوره Splunk Fundamentals دو همراه شما هستیم. در این module قرار است در خصوص tags و events type ها صحبت کنیم؛ ابتدا نحوه ایجاد و استفاده از tags را یاد بگیریم و بعد از آن با event types آشنا شویم و نحوه ایجاد و استفاده از event type را با هم فرا بگیریم. در انتهای این module، در خصوص priority مربوط به operations که در search time اتفاق می‌افتد، صحبت خواهیم کرد.

tag ها در splunk

پیش از آنکه به کار با tags بپردازیم، بهتر است درک مشترکی از tag داشته باشیم. قطعاً شما با اصطلاح tag آشنا هستید، این اصطلاح را شنیده‌اید و شاید در social networks از آن استفاده کرده باشید. در modules قبلی گفته شد که tag یک knowledge object است که به وسیله آن می‌توانید eventsی را که حاوی یک field value خاص یا ترکیبی از field value خاص هستند، به راحتی search کنید.

تعریف Tag

Tag شبیه یک label یا برچسب است که شما آن را به جفت key value یا field value موجود در log اختصاص می‌دهید و بعداً می‌توانید به راحتی به آن tag دسترسی داشته باشید؛ دسترسی به آن tag معادل دسترسی به log هایی است که آن tag یا آن label را دارند. یکی از مزیت‌های مهم tag گذاری روی log ها این است که آن log را قابل فهم‌تر و خواناتر می‌کند و ابهامات آن log را کاهش می‌دهد. اگر شما قبلاً log های authentication مربوط به، برای مثال، Sophos یا firewalls مختلف را دیده باشید، به راحتی آن log را می‌شناسید. اگر فردی در ابتدای راه باشد و log های مختلف را ندیده باشد و نداند که چگونه می‌تواند به log های، مثلاً، authentication مربوط به FortiGate firewall دسترسی پیدا کند، می‌تواند از این tags و labels استفاده کند. زمانی که آن tag را استفاده می‌کند، log های مورد نظر را مشاهده و درک می‌نماید.

ویژگی‌های Tag ها

در Splunk ما می‌توانیم tags را به field value اختصاص دهیم یا tags را به event types اختصاص دهیم در خصوص event types نیز صحبت خواهیم کرد. یکی از موارد مهمی که وجود دارد، این است که tag ها، case sensitive هستند. در ابتدای همین دوره، در خصوص case sensitivity بسیار صحبت کردیم؛ یکی از مواردی که case sensitive بود، tag ها بودند. در modules قبلی، در خصوص CIM و یک سری موارد مرتبط با data model گفته شد که مطالعه کنید. اگر مطالعه کرده باشید، اکنون متوجه می‌شوید که tag هایی در Splunk وجود دارند که استاندارد هستند و بر اساس استاندارد CIM، یک سری log ها باید tag های مرتبط را داشته باشند تا در data model های Splunk درج شوند و ما بتوانیم به وسیله data model به آن‌ها دسترسی داشته باشیم که در modules بعدی به طور کامل در این خصوص صحبت خواهیم کرد. در این module، قرار است فقط در خصوص tag و event type صحبت کنیم. پس برای جمع‌بندی، tag ها یک knowledge object هستند که شبیه یک label عمل می‌کنند؛ شما آن‌ها را به یک سری log اختصاص می‌دهید و بعداً می‌توانید به وسیله این tag ها به آن log ها دسترسی داشته باشید که این کار، search شما را راحت‌تر کرده و آن log ها را قابل فهم‌تر می‌سازد.

مشاهده Tag ها در Splunk

اگر بخواهیم tag هایی که در Splunk تعریف شده‌اند را ببینیم، از منوی settings وارد گزینه Tags می‌شویم. در صفحه‌ای که برای ما باز می‌شود، به وسیله دو گزینه اول می‌توانیم tag ها را مشاهده کنیم؛ یکی بر اساس value موجود و گزینه بعدی، tag ها را بر اساس نام برای ما نمایش می‌دهد. در هر دو قسمت، تمام tag ها وجود دارند و فقط نوع نمایش در اینجا متفاوت است. اگر ما tagی را در سیستم تعریف کنیم، آن tag برای ما در اینجا نمایش داده می‌شود.

ایجاد Tag در Splunk

به منوی search وارد می شویم. می‌خواهم یک search بنویسم و بعد از طریق روش اول tagging که بر اساس field value بود، یک tag را اختصاص دهم. در این search که در تصویر مشاهده می‌کنید، از log های Linux استفاده شده است و log هایی که حاوی user با مقدار root هستند را اکنون با هم مشاهده می‌کنیم. در حال حاضر، تعداد ۱۰ عدد tag روی این log ها وجود دارد که ما فعلاً با این tag ها کاری نداریم و می‌خواهیم tag خودمان را ایجاد کنیم. اگر log را باز کنیم و detail آن را ببینیم، مشاهده می‌کنیم که value مربوط به field با نام user در اینجا root است و ما می‌خواهیم به این، یک tag اختصاص دهیم. روی علامت مربوطه کلیک می‌کنیم و edit tag را انتخاب می‌نماییم. پنجره‌ای برای ما باز می‌شود که field value را خودش وارد کرده است و ما فقط باید tag را وارد کنیم. برای مثال، tagی که می‌خواهم به آن اختصاص دهم، tag با نام خودم است و بعد روی save کلیک می‌کنم. بعد از اینکه روی save کلیک کنیم، tag ذخیره می‌شود و اگر دوباره من روی دکمه search کلیک کنم، tag مربوط به mohammad باید به log ها اضافه شده باشد. همانطور که مشاهده می‌کنید، تعداد tags به ۱۱ عدد افزایش یافته و tag مربوط به mohammad اکنون وجود دارد.

استفاده از tag ها در search

حال اگر بخواهم از این tag استفاده کنم و در search من استفاده شود، یک new search باز می‌کنم، از ساختار tag= استفاده می‌کنم و desired tag خود را می‌نویسم. روی دکمه search کلیک می‌کنم. همانطور که می‌بینید، log هایی که در جستجوی قبلی برای ما وجود داشت، در این search هم وجود دارند، بدون اینکه ما از source type و فیلد user استفاده کرده باشیم و ما به log هایی که مدنظرمان بود، رسیدیم. زمانی که از tag= استفاده می‌کنیم، می‌توان از wildcards نیز استفاده کرد. ما به چند روش می‌توانیم این tag= را بنویسیم. یکی همین روشی بود که ابتدا نوشتم tag= وtag مورد نظر را به صورت کامل بنویسم. روش دیگر اینکه از wildcard ها استفاده کنیم. اما یک نوع دیگر هم وجود دارد tag::<field>=<value>. زمانی که بخواهیم در search از tag به همراه نام field استفاده کنیم تا بتوانیم specific تر و اختصاصی‌تر search خود را بنویسیم، از این نسخه search برای tag استفاده می‌کنیم . tag::user=Mohammadفرق آن با حالت قبلی چیست؟ اگر من بنویسم tag=mohammad، یعنی تمام log هایی را بیاور که tag محمد را دارند. اگر بنویسم tag::user=mohammad ، یعنی log هایی را برای من بیاور که فیلد user را دارند و tag محمد به آن field اختصاص داده شده باشد؛ که این log هایی را برای ما می‌آورد که حجم و تعدادشان نسبت به حالتی که بگوییم کل log هایی را برای ما بیاور که tag مشخصی را دارند کمتر است. وقتی specific تر و اختصاصی‌تر می‌گوییم و از نام field استفاده می‌کنیم، مقدار اختصاصی‌تری به search خود می‌دهیم.

اگر به منوی settings، قسمت Tags بازگردیم و اینجا را refresh کنیم، باید tagها را مشاهده کنیم. همانطور که در تصویر مشاهده می‌کنید، tag محمد به field value pair مربوط به user=root اختصاص داده شده است. و همینطور در اینجا هم جفت field value مربوط به user=root، tag محمد را دارد. permission آن private است؛ این را روی All apps قرار می‌دهم. پس اینجا هم داریم tagها را مشاهده می‌کنیم. می‌توانیم اینجا یک سری تغییراتی داشته باشیم. در قسمت قبلی که list by tag name بود، اگر روی tag خود کلیک کنیم، می‌توانیم field value را تغییر دهیم؛ می‌توانیم اینجا field value های دیگری را هم تعریف کنیم و روی دکمه save کلیک کنیم. و در قسمت list by field value pair، اگر روی field value کلیک کنیم، می‌توانیم tag را تغییر دهیم. اکنون اینجا یک tag محمد وجود دارد، می‌توانیم tagهای دیگری را هم اضافه کنیم.

تا اینجا اولین راه ایجاد tag را در Splunk یاد گرفتیم. در قسمت بعد، می‌خواهیم ابتدا event type را یاد بگیریم و ببینیم که چگونه می‌توانیم به event types، تگ بزنیم که این مهم‌ترین نحوه تگ زدن است.

Event Type چیست؟

event type چیست و چه کاری می‌تواند برای ما انجام دهد؟ اگر به یاد داشته باشید، زمانی که دسته‌بندی‌های knowledge object ها را بررسی می‌کردیم، یکی از knowledge object ها event type بود. event type یک متد برای دسته‌بندی events بر اساس search است. تصور کنید در حال بررسی انبوهی از log های یک firewall هستید؛ برای مثال log مربوط به Kerio firewall. بعد از بررسی متوجه می‌شوید که یک سری از log ها که یک سری field و value مشخص را دارند، به log مربوط به IPS یا IDS آن firewall اشاره می‌کنند و خروجی IPS و IDS آن تجهیز یا نرم‌افزار هستند. فرض کنید روی Kerio firewall یک ماژول IPS/IDS وجود دارد که در حال کار است و log خود را برای شما ارسال می‌کند. شما با log آن آشنایی ندارید؛ log را بررسی می‌کنید و پس از بررسی مشخص می‌شود که log هایی که به عنوان مثال فیلد X و Y آن‌ها برابر با مقدار، مثلاً، IPS/IDS است، مرتبط با log IPS/IDS آن firewall هستند.

مزایای استفاده از Event Type

شما دسته‌ای از log های firewall را مشخص کرده‌اید. search ای می‌توانید بنویسید که مستقیماً آن log ها را به شما نمایش دهد. شما می‌توانید به وسیله event type، آن دسته از log را مشخص کنید و بعداً که خواستید دوباره به آن log مراجعه کنید، از event type مرتبط با آن استفاده کنید و دیگر نیازی نباشد که آن search طولانی را بنویسید.

tag زدن روی Event Type ها

event type یکی از بهترین متدها برای ضبط و به اشتراک‌گذاری knowledge objects سازمانی است و یک مزیتی هم که دارد، این است که ما می‌توانیم روی event type ها، tag بزنیم. تصور کنید نه تنها log مربوط به Kerio firewall را شما بررسی کرده‌اید و به این نتیجه رسیده‌اید، بلکه log های مربوط به firewall های دیگری هم وجود دارد که بررسی کرده‌اید و این نوع log آن را پیدا کرده‌اید. برای آن‌ها هم event type های متفاوت تعریف می‌کنید، اما روی همه این‌ها یک tag می‌زنید؛ مثلاً tag ids-ips. زمانی که شما آن tag را فراخوانی کنید، تمام این log ها به شما نمایش داده می‌شود. اما اگر خواستید فقط log مربوط به Kerio را ببینید، می‌توانید event type مرتبط با IPS/IDS آن را استفاده کنید تا log های مورد نظر را به شما نمایش دهد. پس این یکی از مزیت ها و ویژگی های مربوط به event type بود و تا اینجا متوجه شدیم که event type تقریباً چیست.

مثال عملی از tag زدن

برای مثالی که می‌خواهیم انجام دهیم، روی log های Linux، می‌خواهم log هایی که نشان‌دهنده authentication و login های موفق هستند را برایشان event type تعریف کنم. ابتدا search ای که مورد نظرم هست را می‌نویسم و log هایی که مد نظرم هست را می‌بینم و بررسی می‌کنم و بعد از آن، اقدام به ایجاد event type می‌نمایم. اکنون log ها را پیدا کرده‌ام و بعد روی گزینه Save کلیک می‌کنم و سپس روی گزینه Event Type . یک پنجره جدید باز می‌شود. نام را می‌پرسد؛ من یک نام برای آن انتخاب می‌کنم. در قسمت بعد، باید tag را انتخاب کنم. گفتیم که ما می‌توانیم به event types، تگ بزنیم؛ اصلاً روش درست tagging روی log ها این است که شما event type ایجاد کنید و بر اساس event type، تگ بزنید. در این مثال که log های احراز هویت Linux است، من می‌خواهم tag مربوط به login را به آن اختصاص دهم.

نحوه انتخاب tag ها برای Event Type های مختلف

نکته‌ای که در مورد اختصاص tagها وجود دارد اینکه چه tag ی را بخواهیم به چه event type ی اختصاص دهیم، قبلاً هم در خصوص آن مواردی در ویدئوهای قبلی گفته شد. اگر بخواهید log را normalize کنید و آن را با CIM مطابقت دهید، باید به مستند CIM مراجعه کنید که آنجا دقیقاً نوشته شده به چه log هایی، باید چه tagهایی زده شود. مطابق آن مستندات، آن log را پیدا می‌کنید، event type آن را تعریف می‌کنید و tag مورد نظر را ثبت می‌نمایید. اما اگر هدفتان از ایجاد آن event type و ایجاد آن tag، هدفی غیر از compatible کردن log هایتان با CIM یا normalization باشد، یا اصلاً دارید tag می‌زنید برای کارها و dashboard های خودتان، دیگر نیازی به آن مستند ندارید. Tagها را بر اساس سلیقه خودتان، اما بر اساس مفهوم و داشتن ارتباط با آن log ها، انتخاب کنید. حتی نام event type ای که انتخاب می‌کنید باید مرتبط باشد و بر اساس نکاتی باشد که در ویدئوهای قبلی گفته شد.

برای مثال، اینجا نام را بدون رعایت شرایط و بدون ملاحظه وارد می‌کنم، اما شما در محیط‌های عملیاتی کاملاً باید همه چیز را مستند کنید و با یک سلیقه و با یک تفکر بهینه و مرتبط این کار را انجام دهید. دو گزینه بعدی color و priority وجود دارد. با انتخاب یک رنگ برای این tag، زمانی که log هایی باشند که این tag را داشته باشند، یک رنگ به آن ها در search اختصاص داده می‌شود. و اما در مورد priority؛ ما می‌توانیم با استفاده از این گزینه، یک اولویتی در نمایش tagها داشته باشیم. شما فکر کنید چندین tag وجود داشته باشد؛ شما می‌توانید اولویت تعیین کنید برای هر tag که در نمایش، کدام یک بالاتر قرار بگیرد. بعد از اینکه موارد را وارد کردید، روی save کلیک می‌کنید. یک پنجره بلافاصله به شما نمایش داده می‌شود که با کلیک روی گزینه Event Type ، می‌توانید به منوی Event types بروید و اولین کاری که می‌کنید، تغییر permission است. در قسمت Event types، اکنون داریم search خود را می‌بینیم، name مربوط به event type خود را می‌بینیم و مشاهده می‌کنیم که private permission دارد؛ آن را تغییر می‌دهیم.

برمی‌گردیم به search ای که داشتیم و search را یک بار دیگر اجرا می‌کنیم. باید tag و رنگ مورد نظر روی log ها وجود داشته باشد. اگر دقت کنید، رنگ مورد نظر اعمال شده و همینطور tag مورد نظرمان هم اولین tagی است که داریم مشاهده می‌کنیم. ما می‌توانیم در search خود هم از آن event type استفاده کنیم. برای مثال، می‌توانیم بنویسیم eventtype=forclass login همانطور که در تصویر مشاهده می‌کنید، log های مورد نظرمان که جزء آن search ای بود که پشت این event type قرار دارد را مشاهده می‌کنیم. همینطور tag را هم مشاهده می‌کنیم. ما می‌توانستیم حتی با tag این مورد را فراخوانی کنیم. همانطور که در تصویر می‌بینید، توانستیم با استفاده از tag، log هایی که برایشان event type تعریف کرده بودیم را در خروجی داشته باشیم.

اگر بخواهیم event typeی که تعریف کرده بودیم را تغییر دهیم، به منوی Event types برمی‌گردیم و بر روی event type مورد نظرمان کلیک می‌کنیم. در قسمتی که باز می‌شود، می‌توانیم search string را تغییر دهیم، همینطور tag، همینطور color و priority را هم می‌توانیم تغییر دهیم و روی دکمه save کلیک کنیم.

priority عملیات‌ها

تا اینجا ما نحوه اختصاص tag از طریق field و value و event type را یاد گرفتیم. در انتهای این ویدئو، قصد داریم در خصوص priority عملیات‌هایی که در search time انجام می‌شود، صحبت کنیم. اگر به یاد داشته باشید، در فصل knowledge objects در خصوص دسته‌بندی knowledge objects صحبت کردیم. همانطور که در تصویر می‌بینید، field و field extraction وجود داشت. زمانی که log دریافت می‌شد و شما می‌خواستید log را ببینید، یک سری parser و regex یا regular expression وجود داشت که log را برای شما تجزیه می‌کردند و field value هایی که داخل log بود را به شما نمایش می‌دادند. بعد از آن، data باید طبقه‌بندی می‌شد که به وسیله event types که در این جلسه یاد گرفتیم، این طبقه‌بندی انجام می‌شد. و همینطور lookups و workflow actions وجود دارند که lookups منجر به غنی‌سازی داده‌ها می‌شوند و در دوره Fund 1 در خصوص آن صحبت کردیم. بعد از آن، tag و field aliases بود که در ویدئوی قبلی و این ویدئو در خصوص آن صحبت کردیم. و در آخر، data models وجود دارند که بر اساس انواع مختلف log ها، از آن‌ها استفاده می‌شود و log ها داخل این data models قرار می‌گیرند و ما و اپ های مختلف می‌توانیم از آن استفاده کنیم.

ترتیب اجرای عملیات ها در search time

اما مهم‌ترین نکته‌ای که وجود دارد این است که این operations که اکنون در خصوص آن‌ها صحبت کردیم و در فصل‌های مختلف به آن‌ها پرداختیم، ترتیب اجرایشان به چه صورت است؟ همانطور که در تصویر می‌بینید، زمانی که شما در خصوص یک log، جستجویی را در search bar وارد می‌کنید و روی دکمه search کلیک می‌نمایید این مراحل طی می شود:

Field extraction / Field discovery : ابتدا این مرحله اتفاق می‌افتد. آن regex ها یا regular expressions که در Splunk وجود دارند، با log ها و sources شما منطبق می‌شوند و آن logی که شما نیاز دارید را تجزیه می‌کنند و field value های آن را به شما نمایش می‌دهند.
Field alias application : بعد از اینکه field value استخراج شد، نوبت به aliases می‌رسد که در سیستم شما تعریف کرده‌اید یا توسط TA یا app ها تعریف شده‌اند. field aliase ‌ها روی field value ای که استخراج شده و شما می‌توانید از آن‌ها در search استفاده کنید اعمال می‌شوند و خروجی آن‌ها را هم می‌توانید در search ببینید.
Calculated field execution : بعد از آن، calculated fields هستند که execute می‌شوند؛ calculated fields ی که بر اساس field alias یا field هایی که extract شده‌اند، ایجاد شده‌اند. بعد از اینکه extraction و field alias اتفاق افتاد، calculated fields، execute می‌شوند و خروجی آن‌ها را هم می‌توانید در search در میان fields ببینید.
Lookup execution : بعد از همه این موارد، lookup ها هستند که execute می‌شوند و شما می‌توانید خروجی آن‌ها را به عنوان یک field که log شما را enrich می‌کند، در log ببینید.
Event type processing : بعد از execution مربوط به lookups، نوبت به event types می‌رسد. event types که امروز با هم یاد گرفتیم، اجرا می‌شوند و اگر tagی به آن‌ها اختصاص داده شده باشد، تگ ها ایجاد می‌شوند.
Tagging field value tags: و بعد از event type ، نوبت به tag ها می‌رسد؛ کلاً چه tagsی که بر اساس field value پیکربندی شده‌اند یا tagsی که از طریق event types در مرحله قبل ایجاد شده‌اند.

پس در نتیجه، زمانی که شما search می‌زنید، از بالا به پایین به صورت کلی این شش عملیات روی آن اتفاق می‌افتد. در دوره‌های آینده، تمام این‌ها را با جزئیات بیشتر بررسی خواهیم کرد. اما شما این step ها این ۶ operations و اولویت آن‌ها را به خاطر بسپارید، چون مهم است و یک سری قوانین بین این operations حاکم است.

قوانین operation ها

قوانینی که وجود دارند، به نظر من بسیار منطقی هستند:

شما می‌توانید calculated field بسازید بر اساس field aliases و field هایی که extract شده‌اند. یعنی اگر خواستید یک calculated field بر اساس یک expression مانند eval بسازید، field هایی که از آن‌ها استفاده می‌کنید، field هایی هستند که یا توسط alias ایجاد شده‌اند یا توسط extraction . نمی‌توانید از field هایی استفاده کنید که از طریق lookup ایجاد شده‌اند، چرا؟ چون lookup، مرحله بعدی است.
همینطور field alias؛ زمانی که شما می‌خواهید field alias بسازید، از روی field هایی می‌توانید alias بسازید که extract شده‌اند، نه field هایی محاسبه شده یا از lookup به وجود آمده‌اند.
شما می‌توانید event types بسازید که از calculated fields، از lookups، از field aliases و فیلدهای اکسترکت‌شده استفاده کنند.
شما نمی‌توانید field aliasی بسازید که از روی calculated fields یا lookup fields باشد.
شما نمی‌توانید calculated fieldی بسازید که از روی lookups باشد.

خب، فکر می‌کنم توانستم منطق آن را به شما منتقل کنم. دلیل اصلی آن هم این است که این عملیات‌ها از بالا به پایین، زمانی که شما روی دکمه search کلیک می‌کنید، رخ می‌دهند و Splunk مجبور است که objects را قبل از اینکه استفاده شوند، ایجاد کند. امیدوارم که مطالب این درس برایتان مفید بوده باشد و بتوانید در کار روزمره‌تان با Splunk از آن استفاده کنید. از این که تا اینجای ویدیو همراه من بودید و بابت حمایتتان از ویدیوها ممنونم. الان که این ویدیو را ضبط می‌کنم، دوره رایگان Fund 1 منتشر شده، حدود یک هفته‌ای هست و مقدار زمان مشاهده آن واقعاً عالی است؛ یک دوره رایگان ۸ ساعته در یک هفته حدود ۱۲۰۰ ساعت توسط افراد مختلف در پلتفرم‌های مختلف دیده شده است. خیلی تشکر می‌کنم از حمایتتان. تا ویدیوی آینده، خدانگهدار.

ماژول ده - Creating and Using Macros

زیرنویس عنوان

سلام. با ماژول دهم از دوره Splunk Fundamental دو همراه شما هستیم تا با ماکروها آشنا شویم، نحوه ایجاد یک ماکرو ساده را فرا بگیریم و سپس، نحوه استفاده از این macros ساده‌ای که ایجاد کرده‌ایم را خواهیم آموخت. در انتها، با ماکروهای دارای argument یا variable آشنا خواهیم شد و نحوه ساخت و استفاده از این ماکروها را فرا خواهیم گرفت.

Macro ها در Splunk

زمانی که شما به صورت روزانه از یک سری search و report استفاده می‌کنید که syntax آن‌ها تقریباً مشابه یکدیگر است، می‌توانید آن searche ها را تبدیل به ماکرو کنید و از این پس، از ماکروی مربوط به آن search استفاده نمایید. هنگامی که search شما بسیار طولانی می‌شود و تعداد characters آن از حدی فراتر می‌رود، می‌توانید بخشی از search یا حتی کل آن search را تبدیل به ماکرو کنید و در همان search و حتی در searche های دیگر از آن استفاده نمایید. برخی اوقات، شاید نیازمندی شما بسیار ساده‌تر از این موارد باشد؛ برای مثال، در ویدیوهایی که در خصوص search best practice صحبت می‌کردیم، گفته شد که در ابتدای search حتماً باید از مواردی مانند نام index و source type استفاده کنید. شاید شما حوصله تایپ کردن این تعداد characters را نداشته باشید؛ در این صورت، می‌توانید این موارد را به یک ماکرو با نامی بسیار ساده‌تر تبدیل کنید و زمانی که قصد دارید search انجام دهید، ابتدا آن ماکرو را فراخوانی کرده و سپس ادامه search خود را بنویسید.

قبل از اینکه شروع به نوشتن مثال‌ها کنیم، ابتدا چند ماکرو و چند search که داخل آن‌ها ماکرو وجود دارد را با هم مشاهده می‌کنیم. ابتدا با یک ماکرو شروع شده و پس از آن، یک سری field value وجود دارد و سپس یک pipe و بعد از آن command مربوط به stats مشاهده می‌شود. اگر باز هم بیشتر دقت کنید، متوجه می‌شوید که ماکروهای بیشتری در این search به کار رفته است. اگر بخواهیم یک macro را فراخوانی کنیم، باید نام macro را داخل بک‌تیک (backtick ) قرار دهیم. دقت کنید این با تیک (') یا کوتیشن (") فرق می‌کند و نباید از آن‌ها استفاده شود؛ فقط برای فراخوانی ماکرو، نام آن باید داخل backtick قرار گیرد. دکمه backtick روی کیبورد، بالای کلید Tab و زیر کلید Escape قرار دارد.

مشاهده محتوای یک Macro

اگر بخواهیم ببینیم که داخل این macros چه چیزی ذخیره شده است، دو راه وجود دارد:

وارد منوی Settings > Advanced Search شویم و نام ماکرو را جستجو کنیم. در صفحه‌ای که باز می‌شود، گزینه اول (Search macros) را باید انتخاب کنید و سپس در صفحه دیگری که باز می‌شود، نام ماکرو را جستجو نمایید. دقت کنید اگر در اینجا خروجی نمایش داده نشد، مشکل از filters است که شما در آنجا قرار داده‌اید. اگر من این filter را تغییر دهم، ماکرو برای من نمایش داده می‌شود . ماکرویی که در search من بود، در اینجا وجود دارد و search stringی که داخل این ماکرو هست را با هم مشاهده می‌کنیم.
راه دوم این است که زمانی که search را می‌نویسید و اجرا می‌کنید، کلید ترکیبی Ctrl + Shift + E را فشار دهید. زمانی که این کلید ترکیبی را می‌زنید، پنجره‌ای برای شما باز می‌شود و ماکروهای موجود در آن search را برای شما گسترش داده و کل search را به شما نمایش می‌دهد. اکنون اگر دقت کنید، ماکروی اولی که وجود داشت، این search داخل آن بود و مقادیر بقیه ماکروها هم که وجود دارند، کاملاً در اینجا واضح است.

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

نوشتن و استفاده از یک Macro ساده

همانطور که در تصویر مشاهده می‌کنید، یک search string وجود دارد که برای ما خروجی‌ای تولید می‌کند. ما می‌خواهیم بخشی از این search string را تبدیل به macro کنیم. برای مثال، هر چیزی که بعد از pipe اول هست را می‌خواهم تبدیل به macro کنم و بعد از اینکه macro را نوشتم، این قسمت را پاک کنم و ماکرو را فراخوانی نمایم؛ باید همین خروجی به من نمایش داده شود. به منوی Settings > Advanced Search می‌روم و روی گزینه New macro کلیک می‌کنم. در فرمی که برای ما باز می‌شود، ابتدا باید به ماکرو یک نام اختصاص دهیم و بعد از آن، در قسمت definition، باید آن قسمتی که می‌خواهیم داخل ماکرو باشد را وارد کنیم.

بعد از اینکه موارد را نوشتیم، روی گزینه save کلیک می‌کنیم. برمی‌گردیم به search مورد نظر و بعد از pipe، باید macro را فراخوانی کنیم. گفتیم که برای فراخوانی ماکرو، باید نام ماکرو را داخل دو backtick قرار دهیم. بعد از اینکه روی دکمه search کلیک کردم، همان خروجی به من نمایش داده شد. با استفاده از کلید ترکیبی Ctrl + Shift + E می‌توانم ببینم که چه چیزی داخل آن ماکرو هست. این یک ماکروی basic بود که ما می‌توانیم در بسیاری از جاها از آن استفاده کنیم.

Macro های پیشرفته (دارای آرگومان)

حالا می‌خواهیم یک ماکروی advanced که argument یا variable دارد، تعریف کنیم. در مثالی که در تصویر مشاهده می‌کنید، ابتدا از command مربوط به stats استفاده شده و بعد از آن از command مربوط به eval . می‌خواهم ماکرویی طراحی کنم که سه پارامتر ورودی داشته باشد:

پارامتر اول: نوع currency (پول) را مشخص کند (کاربر مثلاً بنویسد یورو).
پارامتر دوم: symbol آن currency را می‌خواهم به صورت داینامیک وارد macro کنم.
پارامتر سوم: rate است که می‌خواهم به صورت داینامیک یکی از arguments macroی مد نظرم باشد.

پس در نتیجه، باید یک ماکرویی طراحی کنم که سه آرگیومنت داشته باشد. argument اول به جای currency باید قرار بگیرد، argument دوم به جای symbol باید قرار بگیرد و argument سوم به جای rate که اینجا هست، باید قرار بگیرد. من از قبل در منوی Advanced Search موارد را نوشته‌ام. همانطور که می‌بینید، ابتدا یک نام به macro اختصاص داده‌ام و داخل پرانتز، تعداد arguments را ذکر کرده‌ام (گفتم که سه پارامتر ورودی باید داشته باشد). داخل search، هر قسمتی که می‌خواهم به صورت داینامیک از ورودی خوانده شود، آن قسمت را داخل علامت دلار ($) قرار می‌دهم. زمانی که شما یک string را بین دو علامت دلار قرار می‌دهید، آن نقش variable پیدا می‌کند در Splunk . همینطور در ادامه، symbol را بین دو علامت دلار و داخل دابل کوت قرار دادم (به خاطر اینکه این string است و باید داخل دابل کوت قرار گیرد) و در ادامه، rate را بین دو علامت دلار قرار دادم.

پس در نتیجه، ما آن قسمت‌هایی که می‌خواهیم به صورت dynamic باشند را داخل ماکرو باید بین علامت dollar sign قرار دهیم و تعداد آن‌ها را در نام ماکرو (بعد از نام، داخل پرانتز) ذکر کنیم. بعد از اینکه این دو قسمت را تکمیل کردیم، در قسمت Arguments، هر stringی که در definition نقش argument و variable را دارد، به ترتیب در اینجا وارد می‌کنیم. ترتیب مهم است؛ اول، دوم و سوم بودن اهمیت دارد. اینکه شما باید به همین ترتیب نام‌ها را در قسمت Arguments وارد کنید، مهم است. زمانی که بخواهید ماکرو با argument را call کنید، نام ماکرو را داخل backtick قرار می‌دهید، parenthesis باز می‌کنید و arguments را با comma از هم جدا کرده و وارد می‌کنید.

افزودن Validation برای آرگومان‌های ماکرو

قسمت بعدی که وجود دارد، validation است. شما با این قسمت می‌توانید ورودی ها را validate کنید و اگر ورودی نامناسبی وارد شد، یک پیام نمایش داده شود. داخل این مثال، اگر در argument سوم یعنی rate، کاربر به جای اینکه number بزند، string بزند، تابع tonumber() نمی‌تواند اجرا شود. پس بهتر است که argument سوم را validate کنیم و اگر عددی نبود، به کاربر یک پیغامی نمایش داده شود. برای این کار، در قسمت Validation Expression باید ابتدا عددی بودن rate را چک کند که این کار با isnum function یا مشابه آن انجام می‌شود و بعد از آن، اگر این شرط برقرار نبود (یعنی ورودی عدد نبود)، چه error message ای را باید ارائه دهد. بعد از اینکه message مورد نظر را نوشتیم و بقیه موارد را چک کردیم که مشکلی نباشد، روی دکمه save کلیک می‌کنیم.

فراخوانی Macro ها

بعد از اینکه ماکرو مدنظر ما ذخیره شد، به search برمی‌گردیم و بعد از pipe اول، می‌خواهیم نام ماکرو را فراخوانی کنیم. من نام macro را ابتدا داخل backtick قرار دادم، پرانتزی باز شد و داخل پرانتز، سه arguments به ترتیب وارد شد. اکنون روی دکمه search کلیک می‌کنم. همانطور که خروجی را می‌بینید، argument اولی که وارد کردیم، ستون سوم را تشکیل داده، symbol که وارد کردیم روی کاراکترها هست و عددی که در argument آخر وارد کردیم، در ستون USD ضرب شده و مقدار آن را مشاهده می‌کنید. پس در نتیجه، macro ما به درستی کار می‌کند. اما قابلیت validation را هم برای آن پیکربندی کرده بودیم که آن را هم تست می کنیم. به جای عدد آخر، یک string ارسال می‌کنم تا ببینم آیا پیغام خطا می‌دهد یا خیر. همانطور که در تصویر می‌بینید، پیغامی که مدنظرمان بود، نمایش داده می‌شود. پس validation ما هم در اینجا به درستی کار می‌کند.

برای نتیجه‌گیری این بخش، ما در مثال آخر در خصوص ماکروهایی صحبت کردیم که پارامترهای ورودی می پذیرند یا به اصطلاح argument دارند. ابتدا searchی نوشتیم که می‌توانستیم آن search را تبدیل به ماکرویی کنیم که بعضی از قسمت‌های داخل search، از ورودی ماکرو مقدار دریافت کنند و بر اساس ورودی‌ها، خروجی ما تولید شود. در منوی Settings > Advanced Search > New Macro، ماکرویی تعریف کردیم که داخل آن arguments و variables قرار دادیم، با قرار دادن نام متغیر بین علامت dollar sign همانطور که در تصویر می‌بینید، سپس در بخش مربوط به Arguments، آرگومان‌هایمان را به ترتیب وارد کردیم و بعد از آن، در بخش مربوط به Validation Expression، برای اینکه ورودی را بسنجیم و اگر ورودی مطابق با format مدنظرمان نبود، یک پیغامی بدهیم، از این قسمت استفاده کردیم. در آخر، بعد از اینکه از ماکرو استفاده کردیم، توانستیم خروجی مد نظرمان را دریافت کنیم.

این فصل هم به پایان رسید. ممنون و متشکرم که تا اینجا همراه من بودید. اگر سوال، مطلب یا ابهامی وجود داشت، حتماً با من در تماس باشید. تا ویدیوی آینده، خدانگهدار.

ماژول یازده - Creating Data Models

زیرنویس عنوان

با ماژول یازدهم از دوره Splunk Fundamental دو همراه شما هستیم. در این ماژول، در خصوص Workflow Actions صحبت خواهیم کرد. ابتدا با نحوه ایجاد Workflow Actions با متد Get، سپس با متد Post و در انتها با متد Search آشنا خواهیم شد.

Workflow Actions در Splunk

برخلاف نام این ماژول، این ماژول یکی از آسان‌ترین و جذاب‌ترین ماژول‌هایی است که در دوره Splunk وجود دارد و به صورت کلی، Workflow Action یکی از پرکاربردترین ابزارهای Splunk است. شما از طریق Menu مربوط به Settings می‌توانید وارد قسمت Field شوید و در صفحه‌ای که برای شما باز می‌شود، Workflow Actions را انتخاب کنید. در این قسمت، تمام Workflow Actionsی که در System تعریف شده‌اند، قابل مشاهده هستند.

دلایل استفاده از Workflow Actions

اما قبل از بررسی مثال ها، بهتر است بدانیم زمانی که شما در حال کار با Splunk و مشغول جستجو در Logs هستید، ممکن است یک سری نیازمندی‌های جانبی داشته باشید.

کاربردهای روزمره در زمان بررسی لاگ‌ها

برای مثال، شاید بارها برای شما پیش آمده باشد که بخواهید در خصوص یک IP، یک سری اطلاعاتی به دست آورید و مجبور شده‌اید آن IP را در وب سایت ها کپی کرده و در خصوص آن IP داخل آن وب‌سایت‌ها Search انجام دهید تا اطلاعاتی در خصوص آن IP به دست آورید. شما می‌توانید برای انجام این کار از Workflow Actions استفاده کنید تا با زدن یک کلیک، آن اطلاعاتی که از آن وب سایت نیاز دارید، به شما نمایش داده شود و دیگر نیازی به طی کردن یک پروسه طولانی برای به دست آوردن آن اطلاعات نباشد.

افزایش سرعت و دقت در ثبت رخدادها

شاید زمانی که در حال کار با Splunk و Logs هستید و روی Logs، عملیات Search انجام می‌دهید، یک Event را تشخیص داده باشید و نیاز داشته باشید که آن اتفاق را در سیستم تیکتینگ سازمان ثبت کنید. اگر از Workflow Actions استفاده نکرده باشید، قطعاً باید به صورت دستی موارد را در Ticketing سازمان خود ثبت کنید. اما اگر از Workflow Actions استفاده کنید، شما تنها با یک Click می‌توانید Ticket مورد نظر را داخل Ticketing ثبت نمایید.

انجام خودکار جستجوهای مرتبط با IP و Port

شاید زمانی که در حال Search هستید، نیاز داشته باشید که در خصوص یک IP یا یک Port، یک Search جدید ایجاد کنید و در یک سری Log موجود، در مورد آن IP و Port، جستجوی جداگانه انجام داده و نتایج متفاوتی را مشاهده کنید. در این حالت نیز، اگر از Workflow Actions استفاده کنید، باز هم با یک Click می‌توانید یک New Browser Tab باز کرده و به صورت Automatically آن Searchی که مد نظرتان است را ایجاد کنید و در بازه زمانی مورد نظر، خروجی را مشاهده نمایید.

کاربردهای Workflow Actions در SIEM

پس با توجه به مثال های ذکر شده، قدرت Workflow Actions واقعاً زیاد است. زمانی که شما به دوره SIEM می‌رسید، در آنجا نقش Workflow Actions همراه با Workbench ها، موجب ایجاد مجموعه ای از ابزارهای قدرتمند سفارشی می‌شود تا بیشتر کارهایی که تحلیل گرها به صورت دستی انجام می‌دهند، به صورت خودکار انجام شده و خروجی مورد نظر به آن‌ها نمایش داده شود.

نحوه اجرای Workflow Actions روی داده‌ها

ما می‌توانیم Workflow Actions را روی یک Field یا روی Eventsی که در Results مربوط به Search ما وجود دارند، اجرا کنیم تا ارتباط با Resources خارجی یا اجرای یک Search دیگر برقرار شود ، مطابق با مثال‌هایی که در ابتدای این ویدئو عرض شد، موقعیت‌هایی پیش می‌آید که شما نیاز دارید یک سری اطلاعات را از یک سری وب سایت های خارجی به دست آورید و مشاهده کنید. شاید موقعیت‌هایی پیش بیاید که نیاز باشد شما یک سری اطلاعات را به یک Ticketing یا یک Resource خارجی، Post کنید. یا شاید نیاز داشته باشید که یک Search دیگری را اجرا نمایید.

انواع متدها در Workflow Actions

در Workflow Actions متدهای مختلفی وجود دارد: Get، Post و Search . به وسیله متد Get می‌توانیم اطلاعاتی را از یک External Resource دریافت کنیم. همچنین با استفاده از متد Post می‌توانیم Field Values و یک سری اطلاعاتی که مد نظرمان است را به یک External Resource ارسال کنیم. با استفاده از متد Search نیز می‌توانیم بر اساس Field Value مد نظرمان، یک جستجوی ثانویه در یک صفحه جدید ایجاد نماییم. برای اینکه مثال‌هایی را در سیستم با هم اجرا کنیم، من از قبل سه نمونه Workflow Action ایجاد کرده‌ام که اکنون می‌خواهیم آن‌ها را با هم بررسی و اجرا کنیم.

ساخت Workflow Action با متد Get

مثال: جستجوی IP در سایت Whois

مثال اولی که با همدیگر بررسی خواهیم کرد، این است که من در حال Search در Log ها هستم و یک IP مشکوک مشاهده کرده‌ام و می‌خواهم در خصوص این IP در سایت Whois، جستجو کنم. IPرا کپی کرده و در سایت Whois وارد می‌کنم و در خصوص آن، اطلاعاتی به من نمایش داده می‌شود. من می‌خواهم این کار به وسیله Workflow Actions انجام شود. زمانی که Workflow Action در سیستم شما تعریف شده باشد، می‌توانید با انتخاب این گزینه و سپس انتخاب Event Action مورد نظرتان، روی آن کلیک کرده، آن را اجرا کنید و نتیجه آن را ببینید. در حال حاضر، در سیستم من سه Workflow Action تعریف شده است که این سه Workflow Action را می‌خواهیم با هم بررسی کنیم. پس در نتیجه، زمانی که Workflow Action شما تعریف شد، در این قسمت قرار می‌گیرد و شما می‌توانید با انتخاب آن، خروجی‌اش را مشاهده کنید. بنابراین، برای این مثال، من می‌خواهم Source IP موجود در Log را به سایت Whois ارسال کنم و خروجی آن به من نمایش داده شود، بدون اینکه نیاز باشد به صورت دستی IP را کپی کنم.

مراحل ساخت Workflow Action با متد Get

وارد منوی Settings می‌شوم و گزینه Fields را انتخاب می‌کنم، وارد قسمت Workflow Actions می‌شوم و سپس روی گزینه New Workflow Action کلیک می‌نمایم. فرم Workflow Action باز می‌شود. مانند بقیه فرم‌هایی که تا الان یاد گرفتیم، ابتدا Destination App و سپس نام قرار دارد. یک نام به این Workflow Action خود اختصاص می‌دهیم. پس از آن، گزینه های دیگری که وجود دارند، مانند Label و Apply only را باید تکمیل کنیم.

این Workflow Actionی است که من برای سایت Whois تعریف کرده‌ام و می‌خواهم مواردی که در اینجا تکمیل شده است را توضیح دهم. ابتدا به قسمت Workflow Actions رفتیم، بر روی New Workflow Action کلیک کردیم و یک نام به آن اختصاص دادیم، همچنین Destination App را مشخص نمودیم و سپس نوبت به Label رسید. Label دقیقاً همان چیزی است که شما در Search، داخل منوی Event Action مشاهده می‌کنید. برای مثال، اکنون اینجا Get info for ip است که ip جلوی آن نوشته شده است. من در Lable مربوط به این workflow action ، Get info for ip را همراه با علامت دو نقطه نوشتم و همینطور یک Variable به نام src تعریف کردم. اگر به یاد داشته باشید، در ویدئوهای قبلی که Variable تعریف می‌کردیم مثلاً برای Macros، آن‌ها را داخل دو علامت دلار ($$) قرار می‌دادیم تا نقش Variable به خود بگیرند. زمانی که ما Logs را می‌بینیم، هر کدام از این Field هایی که وجود دارند، می‌توانند به یک Variable تبدیل شوند و ما بتوانیم در فرم‌های خود از آن‌ها استفاده کنیم. اکنون در این مثال، من می‌خواهم از Source استفاده کنم. نام فیلد (src) را بین دو علامت دلار قرار می‌دهم ($src$) و زمانی که Action در آنجا بارگذاری شود، Source IP را در انتهای این Label نمایش می‌دهد.

گزینه بعدی که وجود دارد، این است که ما باید Field های خود را در اینجا ذکر کنیم؛ دقیقاً Field هایی را باید بنویسیم که اگر Action ما اجرا شود، می‌خواهیم روی کدام Field ها Apply و اعمال شود. بعد از این قسمت، گزینه Show Action in را داریم؛ در اینجا می‌توانیم مشخص کنیم که آن Labelی که تنظیم کردیم، کجا نمایش داده شود: Event Menu، Field Menu یا هردو. Event Menu را که با هم دیدیم، Field Menu هم در کنار فیلدها وجود دارد، یا هر دو.

بعد از این مورد، باید Action Type را مشخص کنیم: Action Type برای دو متد Get و Postاز نوع link است. اگر خواستیم از Search Method استفاده کنیم، Action Type را روی Search قرار می‌دهیم. پس اگر خواستیم از دو متد Get و Post استفاده کنیم، باید Action Type را روی Link قرار دهیم. بعد از Action Type، در قسمت Link Configuration، باید تنظیمات مرتبط با وب سایت مقصد را انجام دهیم. اولین تنظیم، URI است. اگر دقت کنید، من آدرس سایت whois.com را قرار دادم و دقیقاً لینکی را به کار بردم که اگر در انتهای آن IP قرار دهم، مشخصات آن IP را به من نمایش می‌دهد . اگر به لینک نگاه کنید، دقیقاً با پیکربندی من مطابقت دارد. دقت کنید از هر وب‌سایتی که می‌خواهید استفاده کنید، مستندات داخل آن وب‌سایت به چه چیزی اشاره کرده است؛ شاید نیاز باشد از APIs استفاده کنید. بعد از اینکه لینک را مشخص کردید، نوع باز شدن لینک را مشخص می‌کنید و سپس متد مورد نیازتان را انتخاب می‌نمایید که در این مثال، می‌خواهیم Information را Get کنیم. پس از اینکه اطلاعات را وارد کردیم، روی Save Button کلیک می‌کنیم.

در نهایت به صفحه Search بازمی‌گردیم. صفحه Search را باید یک بار Refresh کنید تا این موارد برای شما نمایش داده شود. من اکنون با زدن گزینه Get info for [IP Address] می‌توانم یک صفحه جدید باز کنم که Information مورد نظرم به من نمایش داده شود. همانطور که در تصویر می‌بینید، با زدن یک Click از Search، وارد سایت Whois شدیم و آن Informationی که می‌خواهیم، در حال نمایش است.

ساخت Workflow Action با متد Post

مثال: ثبت رخداد در سیستم تیکتینگ

مثال بعدی که می‌خواهیم با هم بررسی کنیم، در خصوص Method Post است. شما فرض کنید یک Ticketing یا یک System ثبت اطلاعات دارید و زمانی که چیزی را Detect می‌کنید، می‌خواهید اطلاعات را در آن ثبت کنید. در این Laboratory، من Ticketing یا Registration System ندارم، اما برای Test از یک وب سایت استفاده می‌کنم URLی که وجود دارد را در Configuration مربوط به Workflow Action خود به کار می‌برم و Parameters مورد نظرم را Set می‌کنم.

تنظیم URI، متد و آرگومان‌ها در متد Post

Workflow Action مورد نظر را من از قبل نوشته‌ام. همانطور که در مثال قبلی توضیح داده شد، ابتدا نام را به Workflow Action می‌دهید و سپس Label . توضیحات مربوط به Label را در مثال قبلی عرض کردم. در این مثال، ما می‌خواهیم Destination Port را مبنا قرار دهیم و در خصوص Destination Port، یک Ticket در Ticketing ثبت کنیم. شما در نیازمندی خود، مواردی که مد نظرتان است را وارد کنید. این مثال ها، تقریباً جای کار زیادی دارند. فیلدهای Label، Apply only ، Show Action و Action Type را در مثال قبلی توضیح دادم. در این مثال، از URI که آن وب‌سایت در اختیار من گذاشته است، استفاده می‌کنم و بعد ، Link Method را روی Post قرار می‌دهم. در نهایت، باید Post Arguments را مشخص کنم.

Post Argument چیست؟ زمانی که شما می‌خواهید اطلاعات را به Ticketing ارسال کنید، قطعاً مستندات مرتبط با Method Post آن سیستم Ticketing ، آرگومان هایی را مشخص کرده است. شما باید آن Arguments را پیدا کنید و از آن استفاده نمایید. برای مثال، به احتمال زیاد آن Ticketing، آرگومان Title دارد یا آرگومان Description دارد. شما می‌توانید Arguments را در ستون سمت چپ قرار دهید و Values را در ستون راست، با فرمتی که مشاهده می‌کنید یعنی باید Variable به آن ارسال کنید. بعد از اجرای این Workflow Action، مقدار Destination Port به همراه Raw Data به این آدرس ارسال می‌شود.

ارسال اطلاعات به سیستم هدف با متد Post

پس برای نتیجه‌گیری، شما از قبل Ticketing را بررسی می‌کنید، مستندات مرتبط با API و Method Post آن را مطالعه می‌کنید، آرگومان‌های آن را Extract می‌کنید و آرگومان‌های مد نظر و مورد نیازتان را به همراه Value هایی که می‌خواهید هر آرگومان داشته باشد، وارد می‌نمایید. در این مثال، آرگومان‌های من A و B هستند و می‌خواهم Destination Port و کل Data را ارسال کنم. روی دکمه Save کلیک می‌کنم و به Search می‌روم. در Searchی که وجود دارد، از Event Menu، آن workflow action ای که مدنظرم است را انتخاب می‌کنم و روی آن کلیک می‌نمایم. اکنون Workflow Action من اجرا شد و Ticket من باید ثبت شده باشد. به سایت Webhook بازمی‌گردم و مشاهده می‌کنم که آرگومان A مقدار Port ارسال شد و آرگومان B تمام Log در اینجا برای من ارسال شده است و می‌توانیم از آن استفاده کنیم. اگر این یک Ticketing واقعی بود، قطعاً Ticket ما ثبت شده بود.

ساخت Workflow Action با متد Search

مثال: اجرای جستجوی جدید برای یک IP

مثال بعدی که با همدیگر بررسی خواهیم کرد، استفاده از متد Search است. زمانی که داریم یک Search را اجرا می‌کنیم، به احتمال زیاد برای شما پیش آمده است که نیاز دارید یک New Page باز کنید به همراه یک New Search . نیازمندی من در این مثال این است که این IP در تمام Logs به عنوان Source IP، جستجو شود و اگر خروجی داشت، به من نمایش داده شود. من از قبل Workflow Action آن را تعریف کرده‌ام.

تنظیم Search String و Time Range

Workflow Actionی که مشاهده می‌کنید برای Search است. ابتدا یک Label به آن اختصاص دادیم، مانند مثال‌های قبل و در فیلد Apply only ، فیلد آی پی Source که می‌خواهیم در تمام Index های ما Search شود قرار داده ایم. بعد از آن، Action Type را Search قرار دادم و سپس Search String را باید وارد کنم. Search Stringی که وارد کردم، index=* src =$src $ است. همان متغیر src ای که از Input می‌آید.

بعد از این مورد، می‌توانیم Search appی که می‌خواهیم اجرا کننده این Search باشد را مشخص کنیم و اینکه این Search در پنجره جدیدی باز شود. در نهایت، تنظیمات مختص به Time Range وجود دارد؛ می‌توانیم Time Range را مشخص کنیم یا با زدن این تیک ، آن را برابر باTime Range مربوط به جستجوی اصلی تنظیم کنیم.

برای Test این Workflow Actionبه search برمی گردیم. روی Event Action کلیک می‌کنم و روی Label مرتبط با Workflow Action کلیک می‌نمایم. همانطور که مشاهده می‌کنید، یک پنجره جدید باز شد، Search ما اجرا شد و در نهایت یا خروجی دارد یا ندارد.

در این ماژول در خصوص Workflow Actions صحبت کردیم. Workflow Actions بسیار مهم هستند. زمانی که شما وارد دوره SIEM می‌شوید، می‌توانید از Workflow Actions استفاده کنید و قابلیت‌های جدیدی به SIEM خود اضافه نمایید. پس روی این ماژول، زمان زیادی صرف کنید. ممنونم که در این ویدیو هم همراه من بودید. تا ویدیوی دیگر، خدانگهدار.

ماژول دوازده - پارت یک - Using the Common Information Model (CIM) Add-on

زیرنویس عنوان

سلام. با Module دوازدهم دوره Splunk Fundamental 2 در خدمت شما هستیم. در این Module قرار است درباره ایجاد Data Model ها صحبت کنیم. ابتدا فرا می‌گیریم که Data Model چیست و چگونه می‌توان آن را ایجاد کرد. همچنین Dataset هایی که در هر Data Model وجود دارد چگونه است و ما چگونه می‌توانیم از هر کدام استفاده کنیم. در پایان این Module شما قادر خواهید بود به راحتی Data Model های جدیدی ایجاد کنید و بر اساس Data های مختلفی که در Splunk شما وجود دارد، Dataset های مختلفی ایجاد کنید و در Data Model از آن‌ها استفاده کنید.

مروری بر مفهوم Pivot

در دوره Splunk Fundamental 1، در یک ویدئو درباره Pivot توضیحاتی ارائه شد و اشاره شد که زمانی که قصد استفاده از Pivot ها را داریم، باید یا از Data Model ها یا از Lookup ها استفاده کنیم تا بتوانیم بر اساس Pivot ها، Dashboard ایجاد کنیم. بنابراین، برای مرور مبحث Pivot ها، از Pivot ها برای ایجاد Report و Dashboard استفاده می‌کردیم و Report ها و Dashboard هایی که با Pivot ایجاد می‌شدند، بر اساس Dataset های مختلفی بودند که این Dataset ها شامل Lookup و Data Model بودند.

تعریف Dataset در Splunk

زمانی که شما در Splunk جستجویی مانند index=... انجام می‌دهید، در اصطلاحات Splunk، نتیجه آن جستجو جزء Dataset محسوب نمی‌شود. در Splunk، زمانی که از Dataset صحبت می‌شود، منظور Data Model ها و Lookup هایی است که شما در Splunk ایجاد کرده‌اید. همان‌طور که در تصویر مشاهده می‌کنید، در قسمت Datasets، تمام Data Model ها و Lookup ها وجود دارند و شما می‌توانید از آن‌ها استفاده کنید.

نقش Knowledge Manager در ساخت Data Model

اگر در تیم Splunk خود، نقش Knowledge Manager را دارید، برای ساخت Data Model هایی که Dataset ها را برای شما فراهم می‌کنند، شما مسئول این کار هستید و باید یک برنامه مشخص برای این کار داشته باشید تا Data های خامی که در Index ها ذخیره می‌شوند و بخش بزرگی از این Data ها که به صورت روزمره توسط تحلیلگران استفاده می‌شود، به Dataset هایی تبدیل شوند که برای تحلیلگران قابل استفاده بوده و بتوانند عملیات مختلفی روی آن‌ها انجام دهند.

Data Model چیست؟

در دوره قبلی، Data Model به این صورت توضیح داده شد که یک لایه انتزاعی بین Data خام و کاربر است که باعث می‌شود شما راحت‌تر و با سرعت بیشتری به Data دسترسی داشته باشید. در این دوره، این تعریف را کمی کامل‌تر می‌کنیم: Data Model ها، Dataset هایی هستند که ساختار سلسله مراتبی دارند و حاوی چندین Search و Field هستند.

نقش Search ها در Data Model

اگر به تعریف دقت کنید، متوجه می‌شوید که پشت تمام این Data Model ها، یک Search وجود دارد که دائماً در حال اجرا شدن است و اگر به مفاهیم Search-time مراجعه کنید، زمانی که این Search ها اتفاق می‌افتند، عملیات مربوط به Search-time نیز انجام شده و Dataset هایی که مد نظر ماست، در Data Model ها ایجاد می‌شود.

استفاده از Data Model های پیش‌فرض Splunk

در ویدئوهای قبلی اشاره شد که Splunk از قبل، تعدادی Data Model ایجاد کرده و بر اساس آن Data Model ها، App ها و Solution های Commercial خود را پیکربندی می‌کند. اگر ما بخواهیم از آن App ها استفاده کنیم، حتماً باید از این Data Model های استاندارد استفاده نماییم. در Module بعدی درباره این Data Model ها توضیح داده خواهد شد. زمانی که شما یک Data Model جدید را با استفاده از گزینه "New Data Model" ایجاد می‌کنید، هر Event، هر Search یا هر Transaction که تا کنون فرا گرفته‌ایم، می‌تواند به عنوان یک Dataset جداگانه در آن Data Model ذخیره شود.

قابلیت Accelerate در Data Model

یک مفهوم به نام Accelerate وجود دارد؛ Data Model ها می‌توانند Accelerate شوند تا Performance بهتری داشته باشند و زمانی که شما روی Data های آن Data Model جستجو می‌کنید، با سرعت بیشتری Data برای شما نمایش داده شود.

ایجاد یک Data Model جدید (مثال عملی)

برای اینکه بتوانیم یک Data Model جدید ایجاد کنیم، روی گزینه "New Data Model" کلیک می‌کنیم. در پنجره‌ای که باز می‌شود، ابتدا یک Title به آن اختصاص می‌دهیم. پس از وارد کردن Title، فیلد ID به صورت خودکار تکمیل می‌شود. در قسمت App، مانند پیکربندی‌های گذشته، باید Destination App را مشخص کنیم و روی گزینه Create کلیک می‌کنیم. محیط اصلی ایجاد Data Model ها را مشاهده می‌کنیم. من پیش از ضبط این ویدئو، یک Data Model ایجاد کرده‌ام که با هم آن را بررسی می‌کنیم تا یاد بگیریم چگونه می‌توان یک Data Model ایجاد کرد.

ابتدا باید با قسمت‌های مختلف و اصطلاحات آن آشنا شویم. Data Model ها می‌توانند شامل سه نوع Dataset باشند: Dataset های Event، Search و Transaction . با کلیک بر روی گزینه "Add Dataset"، Event، Transaction، Search قابل انتخاب هستند. در این Data Model که مشاهده می‌کنید، فقط Dataset از نوع Event وجود دارد. اگر Dataset از نوع Transaction نیز وجود داشت، در این قسمت (پایین ستون سمت چپ)، می نوشت Transaction و Dataset مورد نظر نمایش داده می‌شد. همین‌طور برای نوع Search؛ اگر Dataset از نوع Search در این Data Model وجود داشت، مانند اینجا که Event نوشته شده، Search نوشته می‌شد و پایین‌تر، مانند همین Dataset ها، نام Dataset نوشته می‌شد و ما می‌توانستیم آن را ببینیم. در مثال، همین Data Model را تغییر داده و Dataset های مختلف به آن اضافه خواهیم کرد. اگر بخواهیم نمایی از این Dataset ها ببینیم، در این تصویر که مشاهده می‌کنید، Dataset از نوع Search و نوع Transaction وجود دارد و ما می‌توانیم از آن استفاده کنیم.

ایجاد Dataset از نوع Event

اگر شما بخواهید یک Dataset از نوع Event ایجاد کنید، از قسمت "Add Dataset"، روی "Root Event" کلیک می‌کنید. منویی برای شما باز می‌شود که Name و Constraint را باید وارد کنید. هر Event Dataset حاوی Constraint و Field هاست. Constraint ها Search هایی هستند که به صورت سلسله مراتبی ایجاد می‌شوند؛ یعنی ابتدا شما یک Root Dataset می‌سازید و یک Search به آن اختصاص می‌دهید که خروجی آن Search شامل Data هایی است که شما مد نظرتان است و بعد از آن، می‌توانید از روی آن Dataset، Child هایی بسازید که بخشی از Data ی آن Dataset را شامل می‌شوند.

بررسی نمونه عملی Constraint و Child Dataset

در مثالی که در تصویر مشاهده می‌کنید، دقت کنید: ابتدا یک Dataset از نوع Event ایجاد شده که در قسمت Constraint آن (که به آن Base Search می‌گویند)، یک Search نوشته شده است. بعد از آن، یک Child ایجاد شده که داخل آن Child، یک Search و شرایط اضافه‌تری وجود دارد که به صورت سلسله مراتبی ایجاد شده است. زمانی که این Data Model ایجاد می‌شود، ابتدا Root Dataset، Search مورد نظر خود را اجرا کرده و Data ها را به دست می‌آورد. سپس Search ای که داخل Child مربوط به آن است، به صورت سلسله مراتبی روی آن Data ها اجرا شده و بخشی از آن Data را شامل می‌شود.

توضیح نحوه ارث‌بری Search و Constraint

اگر به Root Dataset بازگردیم و قسمت Base Search را بررسی کنیم، می‌بینیم که یک Constraint وجود دارد که شامل یک Search است که به یک Index و یک Sourcetype اشاره می‌کند. زمانی که این Search ایجاد می‌شود، کل Dataset مورد نظر ما را می‌سازد. بر اساس نیازمندی‌مان، یک Child ایجاد کردیم و داخل آن Dataset، Log هایی که Status شان کوچک‌تر از ۴۰۰ است را به عنوان یک Dataset فرزند از Dataset اصلی پیکربندی کردیم.

اگر به قسمت Base Search توجه کنید، search بالادست از Root Event به ارث برده شده و constraint ای که وجود دارد برای خود این dataset فرزند است. پس در نتیجه ساختار سلسله مراتبی که در خصوص آن صحبت کردیم را اینجا داریم مشاهده می کنیم که یک Root Dataset ای وجود دارد که از نوع Event است و همین طور از این Root Dataset یک child ای ساخته شده و از این child هم یک child دیگر ساخته شده است. اگر Base Search آن را بررسی می کنید می بینید که از ابتدا از Root Dataset یک search ای را به ارث برده و بعد از آن از dataset بعدی یک search به ارث برده و درنهایت خودش هم یک constraint ای دارد.

خلاصه و نتیجه‌گیری بخش ایجاد Dataset

اگر بخواهیم تا اینجا یک نتیجه گیری داشته باشیم، ابتدا نیازمندی ما روی Log های وب‌سرور بود که می‌خواستیم از روی این Log ها، Dataset و Data Model اختصاصی بسازیم و در این Data Model و Dataset، بر اساس وضعیت‌های مختلف، Dataset های مختلفی داشته باشیم: یک Dataset که کل Data های وب‌سرور ما را شامل شود و از کل Data، Dataset هایی وجود داشته باشد که به وضعیت‌های مختلف اشاره کند. برای مثال می توانیم داده های مرتبط با وب سرور را بر اساس status، action و موارد دیگر تقسیم بندی کنیم. اما اینجا نیاز ما این بود که بر اساس status، Request هایی که به سمت وب سرور می آید را به Dataset های مختلف تقسیم بندی کنیم که بتوانیم روی آن Dataset ها با Performance بهتری کار کنیم.

ابتدا Data Model مورد نظرمان را ساختیم و در آن Data Model، یک Dataset از نوع Root ساختیم که این Dataset Root شامل تمام Log های وب‌سرور است. بعد از آن، بر اساس نیازمان که می‌خواستیم بر اساس وضعیت Request های مختلف، Dataset های مختلفی داشته باشیم، یک Dataset به عنوان Child از روی Data Model Root ساخته شد که در آن Dataset فرزند، Data هایی که فیلد Status شان کوچک‌تر از ۴۰۰ است، قرار می‌گیرند. باز هم از روی Data های داخل این Dataset، فرزندهای متفاوتی ساختیم که بر اساس فیلد Action و Product Name، Action های مختلف، Dataset های مختلف را تشکیل می‌دهند. الان ما داریم این Data Model را بررسی می‌کنیم، اما جلوتر برخی از این موارد را دوباره پیکربندی می‌کنیم تا شما نحوه این پیکربندی را ببینید.

نحوه کار با فیلدها و ارث‌بری در Data Model

در Data Model ها، زمانی که شما یک Root Dataset از نوع Event تعریف می‌کنید و یک Constraint به آن اختصاص می‌دهید، بعد از آن می‌توانید یک سری Field انتخاب کنید که با انتخاب آن Field ها، آن موارد به Dataset شما اضافه می‌شوند. زمانی که یک Child یا فرزند برای آن Dataset ایجاد می‌کنید، آن Dataset فرزند هم Search String ای که در Constraint والد وجود دارد و همچنین Field هایی که در والد وجود دارد را به ارث می‌برد و خود این Dataset فرزند هم می‌تواند Constraint و Field های اختصاصی خودش را داشته باشد.

ایجاد Data Model با Constraint ها و Field ها

اکنون می‌خواهیم Data Model کلاس ۲ (class-2) را با هم بسازیم، (مانند Data Model قبلی)، و ببینیم که چگونه این Constraint ها و Field ها اضافه می‌شوند تا نحوه ایجاد Data Model ها را فرا بگیرید و در محیط خودتان از آن استفاده کنید.

برای شروع ساخت یک Data Model، همان‌طور که ابتدای این Module گفته شد، در منوی Settings وارد Data Models می‌شوید و روی گزینه "New Data Model" کلیک می‌کنید، Title و ID دیتا مدل، به همراه توضیحات و App ای که مد نظرتان هست را انتخاب کرده و بعد وارد صفحه Data Model می‌شوید.

نکته اول اینکه ID دیتا مدل بسیار مهم است. زمانی که شما می‌خواهید از Data Model در Search استفاده کنید، ID دیتا مدل را باید در Search وارد کنید تا بتوانید Data های مورد نظرتان را ببینید. پس ID دیتا مدل و Dataset هایی که زیرمجموعه یک Data Model ساخته می‌شوند، بسیار مهم هستند.

بعد از اینکه Data Model ساخته شد، روی گزینه "Add Dataset"، گزینه "Root Event" را کلیک می‌کنید. صفحه‌ای که برای ما باز می‌شود، شامل Dataset Name، Dataset ID و Constraints است که باید وارد کنیم. برای اینکه کارمان کمی راحت‌تر باشد، من از Data Model قبلی موارد را فقط کپی می‌کنم.

زمانی که Dataset Name را وارد می‌کنیم، Dataset ID برای ما به صورت خودکار تکمیل می‌شود و Constraint مورد نظرمان را وارد می‌کنیم و بعد روی گزینه Preview کلیک می‌کنیم. همان‌طور که می‌بینید، Data هایی که در این Search وجود دارد، برای ما نمایش داده می‌شود. روی گزینه Save کلیک می‌کنیم.

Dataset ما اکنون اینجا ساخته شده و سه Field را به صورت پیش‌فرض دارد: Host، Source، Sourcetype به علاوه ی Time .

اضافه کردن فیلد به Dataset

اگر بخواهیم Field ای به این Dataset اضافه کنیم، روی "Add Field" کلیک می‌کنیم. در منویی که باز می‌شود، پنج گزینه مختلف وجود دارد:

Auto-Extracted : با استفاده از این گزینه، شما می‌توانید Default Field ها و همین‌طور Manual Field هایی که در آن Search ، Extract شده‌اند را به Dataset خود اضافه کنید.
Eval Expression : شما می‌توانید یک Field جدید بر اساس یک Expression که می‌نویسید و تعریف می‌کنید، داشته باشید.
Lookup : با استفاده از این گزینه می توانید از Lookup Table هایی که وجود دارند استفاده کرده و ستون‌هایی که داخل Lookup مدنظرتان هست را به عنوان Field اضافه کنید.
Regular Expression : شما می‌توانید با استفاده از Regex، فیلد جدیدی را از آن Data های مدنظرتان استخراج کنید.
Geo IP : با استفاده از این نوع، شما می‌توانید فیلدهای جغرافیایی (Geographical) مانند Latitude، Longitude، Country و ... را اضافه کنید.

در این تمرین، ما می‌خواهیم از گزینه "Auto-Extracted" استفاده کنیم. روی این گزینه کلیک می‌کنیم. در صفحه جدیدی که باز می‌شود، بر اساس Search String ای که در Constraint وارد کرده بودید، Field ها به شما نمایش داده می‌شود. شما می‌توانید هر Field ای که مد نظرتان هست را انتخاب کنید تا به Dataset مورد نظرتان اضافه شود.

زمانی که Field ها را انتخاب می‌کنید، می‌توانید برای آن یک Display Name انتخاب کنید. این Display Name زمانی کاربرد دارد که شما می‌خواهید از این Dataset در Pivot ها استفاده کنید. نکته اصلی که وجود دارد، این Display Name، اگر با Field Name ای که وجود دارد تفاوت داشته باشد، در Search، زمانی که می‌خواهید از این Dataset استفاده کنید، هیچ تغییری ایجاد نمی‌شود و باید از Field Name استفاده کنید. این قابلیت بیشتر برای استفاده در Pivot ها است.

بعد از Display Name، نوع (Type) فیلد را داریم که باید مشخص کنیم: String، Number، Boolean یا IP. بر اساس محتوای (Content) موجود در این Field، Splunk خودش این را به صورت اتوماتیک حدس می‌زند و شما هم می‌توانید آن را تغییر دهید.

تنظیم گزینه های Flag

بعد از مشخص کردن Type، گزینه‌های Flags وجود دارد که شما می‌توانید روی این Field تنظیم کنید:

Optional : با انتخاب این گزینه، همان‌طور که از اسمش مشخص است، این فیلد اختیاری می‌شود و اجباری وجود ندارد که در همه Event ها باشد.
Required : اگر این گزینه را انتخاب کنید، فقط Event هایی که حاوی این Field هستند، در Pivot شما نمایش داده می‌شوند و قابل استفاده‌اند. یعنی زمانی که شما از این Dataset در Pivot ها می‌خواهید استفاده کنید، اگر برای این Field این گزینه را انتخاب کرده باشید، فقط Event هایی را به شما برمی‌گرداند که حاوی این Field هستند.
Hidden : با انتخاب این گزینه، این Field در Pivot برای شما نمایش داده نمی‌شود. زمانی که شما از این Dataset در Pivot استفاده می‌کنید، این Field دیگر نمایش داده نمی‌شود. کاربرد آن در سناریوهایی است که شما یک سری Field ها را فقط اضافه می‌کنید تا بتوانید یک سری Field های دیگر را از روی آن بسازید و نیاز ندارید به طور مستقیم از آن Field استفاده کنید.
Hidden & Required : با انتخاب این گزینه، زمانی که در Pivot ها می‌خواهید از این Dataset استفاده کنید، فقط Event هایی را به شما برمی‌گرداند که حاوی این Field هستند و همچنین باعث می‌شود که این Field در آن Pivot مخفی شود.

تفاوت دو گزینه اول Optional و Required

شما فرض کنید Dataset ای دارید می‌سازید که پشت آن یک Search هست و آن Search شامل یک سری Event هایی است که ۵۰ درصدشان این Field را دارند و ۵۰ درصد ندارند. زمانی که Flag این Field را Required قرار می‌دهیم و از این Dataset در یک Pivot استفاده می‌کنیم، فقط Event هایی را به ما نمایش می‌دهد که حاوی این Field هستند. اما اگر از گزینه Optional استفاده کنیم، حتی آن Event هایی که این Field را هم ندارند، به ما نمایش داده می‌شوند. یک سری شروط هم وجود دارد که آیا بقیه موارد را درست تنظیم کرده اید یا خیر. اما اگر بخواهیم درباره همین یک فیلد تصمیم بگیریم، تفاوت دو گزینه اول را به طور شفاف بیان کردیم.

فیلدهای مد نظرم را انتخاب می‌کنم و بعد روی گزینه Save کلیک می‌کنم. همان‌طور که در تصویر می‌بینید، فیلدهای مد نظر من اضافه شد. ابتدا با انتخاب گزینه add field گزینه auto extracted را انتخاب کردیم و فیلدهایی که وجود داشت را انتخاب کردیم.

اضافه کردن فیلد با Eval Expression

می‌خواهیم به وسیله Eval Expression یک فیلدی را اضافه کنیم. روی قسمت "Add Field"، گزینه "Eval Expression" کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، در قسمت "Eval Expression"، بر اساس Command مربوط به eval که با هم یاد گرفتیم، اینجا یک Expression وارد می‌کنیم و بعد از آن نام فیلدمان را وارد می‌کنیم.

در Eval Expression ای که وارد کردم، ابتدا از if استفاده کردم و بعد از آن یک شرطی گذاشتم: اگر مقادیری که داخل فیلد Status هست بزرگ‌تر از ۳۹۹ باشد، مقدار "Web error" را در فیلد جدیدمان قرار می‌دهد و اگر این شرط برقرار نباشد، مقدار "OK" را در فیلد مورد نظرمان قرار می‌دهد. اسم فیلد را هم errorReason می‌گذارم. همان‌طور که می‌بینید، می‌توانیم Display Name، Type و Flags را هم مشخص کنیم. روی دکمه Preview کلیک می‌کنیم.

همان‌طور که در خروجی می‌بینید، این فیلد برای ما ایجاد شد و حاوی مقادیری است که در Eval Expression مان نوشتیم. روی دکمه Save کلیک می‌کنم. بعد از اینکه فیلد اضافه شود در بخش Calculated، می توانیم آن را مشاهده کنیم.

اضافه کردن فیلد با Lookup

بعد از اینکه Eval Expression را اضافه کردیم، می‌خواهیم یک فیلدی بر اساس Lookup هم اضافه کنیم. روی "Add Field"، گزینه "Lookup" کلیک می‌کنم. در صفحه‌ای که باز می‌شود، دقیقاً مانند Automatic Lookup هایی که در دوره Fundamental 1 گفتم، اینجا هم همان مفاهیم برقرار است. ابتدا Lookup Table File مان را مشخص می‌کنیم.

بعد از اینکه Lookup را مشخص کردیم، Input را باید مشخص کنیم: فیلدی که داخل Lookup می‌خواهیم نقش Relation و کلید را داشته باشد و همین‌طور فیلدی که داخل Dataset مان می‌خواهد نقش Relation و کلید را داشته باشد را باید مشخص کنیم. هم در Lookup و هم در Dataset، فیلد productid هست. بعد از آن قسمت Output را داریم. مواردی که مد نظرمان هست را فعال می کنیم (تیک آن را می زنیم)

بعد از اینکه تیک‌های مورد نظرمان را زدیم، روی گزینه Preview کلیک می‌کنیم. همان‌طور که در خروجی می‌بینید، فیلدهای مورد نظر ما اضافه شد. روی دکمه Save کلیک می‌کنم. مشاهده می کنید که در قسمت Calculated Fields، فیلدهای ما اضافه شد و روبروی این فیلد کلمه Lookup را دارید می‌بینید که منظور این است که این فیلدها به وسیله Lookup اضافه شده‌اند. در ادامه می خواهیم از Regualar Expression ها هم استفاده کنیم.

اضافه کردن فیلد با Regular Expression

برای این منظور روی گزینه "Add Field" و بعد "Regular Expression" را انتخاب می‌کنیم. در صفحه‌ای که باز می‌شود، در قسمت "Extract From"، باید Source آن محتوایی (Content) که می‌خواهیم آن Extraction روش اتفاق بیفتد را مشخص کنیم که با انتخاب _raw، تمام Log ای که مد نظرتان هست را می‌توانید انتخاب کنید و آن Extraction ای که می‌خواهید اتفاق بیفتد، روی بخشی از آن Log اتفاق بیفتد، یا فیلدهایی که مد نظرتان هست و در این Dataset وجود دارد را می‌توانید انتخاب کنید. برای مثال، من فیلد useragent را انتخاب می‌کنم و Regular Expression ای که برایش نوشتم، از useragent نوع Browser را Extract می کند و من می‌توانم در Field ها یک فیلدی داشته باشم به نام browser که مقادیر این فیلد شامل مواردی می‌شود که از فیلد useragent استخراج شده اند. بعد از نوشتن Regular Expression ، اگر روی صفحه کلیک کنیم ، Field Name مربوط به فیلد مد نظرمان مشخص می‌شود. چون این Field Name را در Regular Expression مان وارد کردیم و می‌توانیم Display Name، Type و Flags را هم مشخص کنیم. روی گزینه Preview کلیک می‌کنیم.

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

اضافه کردن فیلد با Geo IP

در آخر، با استفاده از گزینه "Geo IP"، می‌خواهیم فیلدهایی مثل Country، Region، City، Lat و Long را ایجاد کنیم که برای ایجاد Visualization هایی از نوع Map استفاده می‌شود. روی این گزینه کلیک می‌کنیم. همان‌طور که قبلاً دیدیم، پیغامی مبنی بر نبود فیلد IP نمایش داده شد و مفهوم آن این است که هیچ فیلدی از نوع IP وجود ندارد که بر اساس آن بتوانیم فیلدهای مدنظرمان را ایجاد کنیم. پس روی Cancel کلیک می کنم و به دیتاست برمی گردم و ابتدا فیلد clientip را Edit کرده و Type آن را از نوع IP قرار می دهم و Save می‌کنم. سپس دوباره روی "Add Field" و "Geo IP" کلیک می‌کنیم. همان‌طور که می‌بینید، آن پیغام دیگر نمایش داده نمی‌شود و فقط نیاز است که تیک فیلدهای مورد نظرمان را بزنیم و روی دکمه Preview یا Save کلیک کنیم. روی دکمه Preview کلیک کردیم، همان‌طور که در تصویر می‌بینید، فیلدهای مورد نظر برای ما اضافه شد. روی دکمه Save کلیک می‌کنم و در انتهای Dataset، فیلدهای مورد نظر من اضافه شد.

ایجاد Dataset فرزند برای Data Model

تا اینجای این Module، توانستیم Dataset مورد نظرمان را ایجاد و فیلدهای مورد نظرمان را اضافه کنیم و تمام انواع Field ها را با هم کار کردیم. بعد از اینکه Dataset اصلی یا Root را ساختیم و فیلدهای مورد نظر را به آن اضافه کردیم، می‌خواهیم Dataset فرزند را ایجاد کنیم. روی دکمه "Add Dataset" کلیک می‌کنیم و گزینه Child را انتخاب می‌کنیم.

در صفحه‌ای که باز می‌شود، ابتدا اسم Dataset و بعد از آن Constraint یا آن Search String ای که مد نظرمان است را وارد می‌کنیم. در پایین صفحه، Dataset والدش را مشخص می‌کنیم که در این مثال، فقط یک دیتاست است که Dataset "Web Request" می باشد. بعد از اینکه تنظیمات را انجام دادیم، روی گزینه Preview کلیک می‌کنیم. همان‌طور که در خروجی می‌بینید، Event هایی که با Constraint مورد نظرمان Match می‌شوند، به ما نمایش داده می‌شود. در نهایت روی دکمه Save کلیک می‌کنیم.

مشاهده می کنید که Dataset ما ساخته شد و در قسمت Constraints، Search String ای که متعلق به Dataset والد هست را با هم می‌بینیم و مشاهده می‌کنیم که به ارث برده شده و بعد از آن، Constraint ای که متعلق به همین Child است را می‌بینیم و می‌توانیم با زدن گزینه Edit، Search را ویرایش کنیم. پایین صفحه هم Field ها را مشاهده می‌کنید؛ فیلدهایی که از Dataset والد به ارث برده شده‌اند. اگر بخواهیم یک Field ای به این Dataset فرزند اضافه کنیم، روی دکمه "Add Field" می‌توانیم کلیک کنیم و فیلد مورد نظرمان را اضافه کنیم.

اگر نیاز باشد، باز هم می‌توانیم برای این Dataset که خودش فرزند یک Dataset دیگر است، یک Dataset فرزند تعریف کنیم و خودش نقش والد را هم داشته باشد. برای مثال، روی "Add Dataset"، "Child" دوباره کلیک می‌کنیم. ابتدا اسم Dataset و بعد از آن Constraint مدنظرمان و در نهایت، Dataset والدش را مشخص می‌کنیم و روی دکمه Save کلیک می‌کنیم.

همان‌طور که می‌بینید، Dataset مد نظر ساخته شد و دارای Field هایی است که از Dataset والدش به ارث برده و همین‌طور Constraint و Search String هایی که از Dataset های والدش به ارث برده شده و در نهایت، خودش هم یک Constraint دارد.

در این قسمت هم آموختیم که چگونه می توانیم دیتاست فرزند بسازیم.

ماژول دوازده - پارت دو- Using the Common Information Model (CIM) Add-on

زیرنویس عنوان

در ادامه Module دوازدهم و مباحث Data Model، در این ویدیو قصد داریم ابتدا به‌وسیله Pivot ها این Data Model را تست کرده و در ادامه ویدیو، در خصوص Dataset های Transaction و Search صحبت کنیم.

تست Data Model با Pivot

اگر به خاطر داشته باشید، در دوره Splunk Fundamental 1، یک ویدئو مجزا در خصوص Pivot ها ضبط و ارائه گردید. در آن ویدئو، درباره Dataset هایی که در Pivot ها مورد استفاده قرار می‌گیرند، صحبت کردیم. اگرچه در آن ویدئو، مباحث Pivot به‌صورت کامل بیان نشد و چند مطلب دیگر همچنان در مورد Pivot ها وجود دارد که در ویدئو های آتی در خصوص آن‌ها صحبت خواهیم کرد.

نحوه استفاده از Pivot در Data Model

اگر بخواهیم از این Data Model در Pivot استفاده کنیم، می‌توانیم روی دکمه Pivot کلیک کرده یا به بخش Dataset ها مراجعه نموده، Dataset مورد نظر را پیدا کنیم و مطابق ویدئو مربوط به Pivot، روی گزینه مرتبط با آن کلیک نماییم. اما زمانی که در صفحه Data Model قرار دارید، ابتدا می‌توانید روی دکمه Pivot کلیک کرده و Dataset مورد نظر خود را انتخاب کنید. در این Data Model، چندین Dataset وجود داشت که قصد داریم از Failed Request استفاده کنیم.

صفحه Pivot ها برای ما باز می‌شود. پس از اجرای این Search، تعداد Event هایی که در این Dataset وجود دارد، قابل مشاهده است. در این مثالی که بررسی خواهیم کرد، بر روی Dataset مربوط به Failed Request ها، قصد داریم Action مربوط به Request هایی که Fail شده‌اند را بر اساس Status مشاهده کنیم. روی Split Column کلیک کرده، سپس روی Status کلیک می‌کنیم. در قسمتی که باز می‌شود، دکمه Add To Table را می‌زنیم. به همین ترتیب، در قسمت Split Row، گزینه Action را انتخاب می‌کنیم.

همان‌طور که مشاهده می‌شود، سطرها و ستون‌هایی ایجاد شد و به هدفی که مد نظر بود، دست یافتیم. حال، با استفاده از Filter، قصد داریم تنها Status هایی که برابر با 503 هستند را مشاهده کنیم. در قسمت Match، گزینه مساوی (=) را انتخاب کرده، سپس مقدار مد نظر (503) را وارد و در نهایت Add To Table را می‌زنیم.

همان‌طور که مشاهده می‌شود، تنها Status کد 503 نمایش داده می‌شود و می‌توان از ابزارهای Visualization نیز استفاده کرد. اما قصد داریم Search پشت این Pivot را بررسی کنیم تا ببینیم چه مواردی در آن وجود دارد.

بررسی Search پشت Pivot

برای مشاهده Search پشت این Pivot، باید روی دکمه‌ای که علامت ذره‌بین دارد کلیک کنیم تا Search برای ما باز شود.

Search ای که مشاهده می‌کنید، با استفاده از دستور pivot نوشته شده است. اگر بخواهیم اجزای آن را بررسی کنیم: ابتدا نام Data Model سپس نام Dataset مورد نظر و در ادامه، سایر قسمت‌ها که کاملاً به تنظیمات Pivot ای که ایجاد کردیم، بازمی‌گردد.

اگر یک بار دیگر به Pivot بازگردیم، یک بخش Split Column، یک بخش Column Values، یک بخش Split Row و یک بخش Filter وجود داشت. در Search مربوط به pivot، بعد از نام Dataset، ابتدا بخش Column Values قرار دارد که تعداد Event های این Dataset را شمارش کرده و نمایش می‌دهد. همان‌طور که می‌بینید، تابع count وجود دارد که نام دیتاست (Failed_Request) به آن ارسال شده و تعداد آن را با عنوان "Count of Failed Request" به ما نمایش می‌دهد. سپس پارامتر SPLITROW وجود دارد که (همان‌طور که به یاد دارید) Action را برای آن وارد کردیم و بعد از آن SPLITCOL قرار دارد که Field مربوط به Status را به آن معرفی کردیم. همچنین FILTER ای وجود دارد که بر اساس Field مربوط به Status نوشته‌ایم. در نهایت، SORT و پارامترهایی مانند SHOWOTHER یا NUMCOLS وجود دارند که در دوره‌های آینده به تفصیل با آن‌ها آشنا خواهیم شد.

بنابراین، تا این بخش از ویدیو، آموختیم که چگونه Dataset خود را به‌وسیله Pivot ها تست کنیم. اما به یاد داشته باشید، دستوراتی در Search وجود دارد که می‌توانیم به‌وسیله آن‌ها مستقیماً با Data Model خود ارتباط برقرار کرده و Data هایی که با Data Model ها و Dataset های ما مطابقت دارند را مشاهده کنیم که در فصل بعدی در خصوص آن صحبت خواهیم کرد. در قسمت بعدی این ویدیو، قصد داریم در خصوص Dataset هایی از نوع Search و Transaction صحبت کرده و ببینیم چگونه می‌توانیم این Dataset ها را ایجاد کنیم.

اگر به یاد داشته باشید، در ابتدای این Module، در خصوص انواع Dataset های موجود در Data Model صحبت کردیم. گفتیم که Dataset هایی که در Data Model ها ایجاد می‌شوند، سه نوع هستند: Dataset از نوع Event، از نوع Search یا از نوع Transaction . در خصوص Dataset های از نوع Event به تفصیل صحبت کردیم. اما Dataset های از نوع Search چه Dataset هایی هستند؟

دیتاست های نوع search

Dataset هایی که از نوع Search هستند، مبتنی بر Search هایی ایجاد می‌شوند که در آن‌ها از Transforming Command ها استفاده شده است. زمانی که شما یک Dataset از نوع Event ایجاد می‌کنید، یک Search را به عنوان Constraint داخل آن وارد می‌نمایید؛ اما این Search نمی‌تواند شامل Pipe و Command هایی مانند stats باشد. اگر بخواهید از این نوع Command ها در Search خود استفاده کرده و آن Search را برای یک Dataset در نظر بگیرید، باید Dataset از نوع Search ایجاد کنید.

نحوه ایجاد Dataset از نوع Search

روی گزینه Add Dataset، سپس Root Search کلیک می‌کنیم. نام Dataset را (برای مثال) User قرار می‌دهیم و یک Search را که اینجا نوشته‌ایم، به آن اختصاص می‌دهیم. روی گزینه Search کلیک می‌کنیم. همان‌طور که مشاهده می‌شود، Data مربوطه در حال بارگذاری است. روی دکمه Save کلیک می‌کنیم.

مشاهده می کنید که Dataset مربوط به User برای ما ایجاد شد و می‌توانیم Field های مورد نظر را به آن اضافه کنیم. برای مثال، چند Field را انتخاب می‌کنیم و سپس روی دکمه Save کلیک می‌نماییم. همان‌طور که مشاهده می‌شود، این نوع Dataset نیز ایجاد شد؛ پیچیدگی زیادی نداشت و بسیار آسان بود.

دیتاست های نوع Transaction

فقط ایجاد Dataset از نوع Transaction باقی مانده است. Dataset های Transaction، همان‌طور که از نامشان پیداست، بر اساس یک Transaction شکل می‌گیرند. در ویدیوها و Module های قبلی، در خصوص Command مربوط به transaction صحبت کردیم و مفهوم Transaction را در آن Module فرا گرفتیم. زمانی که می‌خواهید یک Transaction ایجاد کنید، باید بر اساس یک یا چندین Field این کار را انجام دهید. در Data Model ها، زمانی که می‌خواهید Dataset از نوع Transaction بسازید، می‌توانید بر اساس Field هایی که در Dataset های شما وجود دارد، این کار را انجام دهید. حال، آن Dataset می‌تواند از نوع Event یا از نوع Search باشد؛ تفاوتی ندارد. شما یک Dataset از نوع Transaction می‌خواهید ایجاد کنید که به یک سری Field نیاز دارد. این Field ها می‌توانند در Dataset از نوع Event یا Dataset از نوع Search وجود داشته باشند.

ایجاد Dataset از نوع Transaction

روی قسمت Add Dataset، سپس Root Transaction کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، مانند همیشه، باید Dataset Name را وارد کنیم و در قسمت Group Datasets، باید آن Datasetای که می‌خواهیم این Transaction بر اساس Data ها و Field های آن‌ شکل بگیرد، انتخاب کنیم و سپس در قسمت Group by، Field مورد نظر که می‌خواهیم بر اساس آن‌ها Transaction محاسبه شود، انتخاب می‌کنیم و در نهایت Max Pause و Max Span را انتخاب می کنیم. روی دکمه Preview کلیک می‌کنیم. همان‌طور که مشاهده می‌شود، خروجی Transaction برای ما نمایش داده می‌شود.

پس برای جمع‌بندی: این فیلد همان Fieldای است که برای Command مربوط به transaction استفاده می‌کردیم. در این قسمت می‌توانیم هم چندین Dataset و هم چندین Field را انتخاب کنیم. پس از اتمام پیکربندی، روی دکمه Save کلیک می‌کنیم.

بعد از ذخیره تنظیمات، مشاهده می‌شود که Dataset مورد نظر وجود دارد. داخل این Dataset، قسمت Constraint بر اساس Transaction نوشته‌شده تکمیل می‌شود. همچنین در قسمت Field ها، یک سری Field هایی وجود دارد که با استفاده از دستور transaction به وجود می‌آیند مانند duration و eventcount و یک سری Field ها نیز که در Dataset مبدأ این Transaction وجود داشتند. یک سری Field ها هم از Dataset مبدأ خوانده شده و به اینجا منتقل شده‌اند. می‌توانیم با استفاده از Add Field، Field های مورد نظر را اضافه کنیم. برای مثال، با استفاده از Eval Expression، می‌توانیم Field مربوط به duration را بر 60 تقسیم کرده و یک Field دیگر به نام visit ایجاد کنم. روی گزینه Preview کلیک می‌کنم. همان‌طور که مشاهده می‌شود، این Field ایجاد شده و Field مربوط به duration تقسیم بر 60 می‌شود که خروجی آن در اینجا نمایش داده شده است. روی دکمه Save کلیک می‌کنیم و این Field نیز به جمع Field ها اضافه می‌شود.

در این قسمت از ویدیو، آموختیم که Data Model های Search و Transaction چگونه ایجاد می‌شوند.

نکات تکمیلی درباره Data Model ها

چند نکته پایانی در خصوص Data Model ها نیز وجود دارد.

تنظیم Permission ها برای Data Model

اول در خصوص Permission هاست. می‌توانیم با استفاده از گزینه Edit و انتخابEdit Permissions، Permission های مورد نظر را تنظیم کنیم.

دانلود و آپلود Data Model ها

مورد بعدی در خصوص Download و Upload کردن Data Model است. زمانی که روی دکمه Download کلیک می‌کنیم، فایل JSON مرتبط با آن Data Model همان‌طور که در تصویر مشاهده می‌شود دانلود می‌شود. پس از آن می‌توانیم این Data Model را در یک Splunk دیگر یا هر جای دیگری که نیاز بود، استفاده کنیم. اگر وارد منوی Setting و سپس Data Models شویم، یک گزینه Upload Data Model وجود دارد. در پنجره‌ای که باز می‌شود، می‌توانیم فایل JSON، ID و App مورد نظر را اختصاص داده و روی گزینه Upload کلیک کنیم. زمانی که کلیک می‌کنیم، Data Model مورد نظر Upload شده و تمام آن Structure ای که ساخته بودیم، پیاده‌سازی می‌شود و می‌توانیم از آن استفاده کنیم. یکی از کاربردهای این قابلیت آن است که زمانی که شما یک محیط بزرگ Splunk با Scale بالا دارید، شاید نخواهید Data Model را ابتدا در محیط Production ایجاد کنید. می‌توانید یک محیط Testing داشته باشید، Data Model را در آن محیط ایجاد کرده، سپس آن را Download و به محیط Production منتقل (Upload) کنید. پس می توانید با دانلود و آپلود، آن دیتامدل را منتقل کنید.

فعال‌سازی Acceleration در Data Model

نکته بعدی که وجود دارد، در خصوص Acceleration است. اصطلاحی در Splunk و در Data Model ها به نام Acceleration وجود دارد. بهتر است همین ابتدا بدانید که مفاهیمAcceleration در دوره Fund 3 به تفصیل بیان می‌شود. اما اگر بخواهیم کلیت Acceleration را بررسی کنیم: زمانی که شما Acceleration را روی یک Data Model فعال می‌کنید، Splunkبا استفاده از الگوریتم‌هایی، یک سری Summary برای Data هایی که داخل Data Model ها هستند ایجاد می‌کند و از مفاهیمی مانند Inverted Time Series Index استفاده می‌نماید تا شما بتوانید با سرعت بیشتری به Data ای که مد نظرتان است، دسترسی داشته باشید. پس کلیت آن این است که سرعت دسترسی به Data افزایش می‌یابد.نحوه استفاده از آن در دوره Fund 3 بررسی می‌شود.فقط در ذهن داشته باشید که قابلیتی به نام Accelerate وجود دارد که می‌توانید با استفاده از گزینه Edit و سپس Edit Acceleration، گزینه Accelerate را فعال کرده و بازه زمانی (Time) مربوط به Summary Range را مشخص کنید. یک روز، هفت روز، یک ماه و ... بسته به حجم نگهداری Data.تایم را مشخص کنید و سپس روی دکمه Save کلیک کنید. پس از ذخیره، مدتی زمان می‌برد تا موارد ذخیره شده و Summary ها ایجاد شوند و بعد می‌توانید از آن استفاده کنید.

نکات پایانی در خصوص Data Model ها

اما چندین نکته کلی دیگر نیز وجود دارد:

شما اگر بخواهید Data Model ای را Accelerate کنید، Permissionآن نباید Private باشد؛ Data Model هایی که Permission آن‌ها Private است، Accelerate نمی‌شوند.
نکته بعدی این است که زمانی که Acceleration انجام شد، بعد از آن دیگر نمی‌توانید Data Model را Edit کنید. این نکته بسیار مهمی است؛ پس دقت کنید که چه زمانی Data Model را Accelerate می‌کنید. برای اینکه بتوانید Data Model ای را Accelerate کنید، نیاز به Permission مربوط به Accelerate Data Model دارید یا اینکه باید نقش Admin را در کل Splunk داشته باشید.
چندین نکته دیگر در خصوص Data Model ها وجود دارد که در این دوره چندین بار به آن‌ها اشاره کردم؛ مثل اینکه اگر بخواهید یک Transaction Dataset بسازید، باید حداقل یک Dataset از نوع Event یا Search وجود داشته باشد.
نکته دیگر آنکه، Datasetهای از نوع Search و Transaction هیچ‌گاه نمی‌توانند از مزایای Accelerate استفاده کنند، یعنی Accelerate نمی‌شوند.

خب، اکنون که شما با این مفاهیم آشنا شدید و آموختید که Data Model ها به چه کار می‌آیند و چه کارهایی می‌توان با آن‌ها انجام داد، قطعاً در محیط کاری شما، Report ها و یا کاربرانی وجود دارند که Report هایی ایجاد می‌کنند. باید به این فکر کنید که نیازمندی آن‌ها چیست و چگونه می‌توانید با ایجاد Data Model به نیازمندی آن‌ها کمک کنید تا Report ها با سرعت بهتر و بیشتری اجرا شوند. آیا نیازمندی آن کاربر و Report، دسترسی به Raw Data Event است و باید بتواند آن‌ها را ببیند، یا با Data های Transactional نیز کار او انجام می‌شود؟ باید در این حوزه مقداری تفکر کنید، کار کنید و تجربه کسب نمایید تا بتوانید به عنوان یک Knowledge Manager، تمام این موارد را کنترل کنید.

هر جا نکته، سؤال یا مطلبی هم وجود داشت، می‌توانید از طریق Email با من در تماس باشید تا بتوانم به شما کمک کنم.

ممنونم که همراه ما بودید. این ویدیو نیز به پایان رسید. تا ویدیوی بعدی، خدانگهدار.

ماژول سیزده

زیرنویس عنوان

سلام. با Module سیزدهم از دوره Splunk Fundamental 2 در خدمت شما هستیم. این Module آخرین Module است که در مجموعه دوره Splunk Fundamental 2 وجود دارد. در این Module قصد داریم در خصوص App مربوط به CIM (Common Information Model) صحبت کرده و بیاموزیم که چگونه می‌توان از این App استفاده کرد و در چه مواردی کاربرد دارد.

پیش از ورود به تعریف CIM، بهتر است مواردی را به‌صورت تجربی در اختیار شما قرار دهم تا ذهنیت مشترکی ایجاد شود که در ادامه دوره، به درک مفاهیم و کاربردهایی که قصد ارائه آن‌ها را دارم، کمک کند.

نقش Splunk به عنوان ابزار در یک SOC

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

اهداف استفاده از Splunk در SOC

هنگامی که در یک SOC تصمیم به استفاده از Splunk گرفته می‌شود، اهداف مشخصی در آن SOC وجود دارد که منجر به این تصمیم شده است. این اهداف می‌تواند شامل جمع‌آوری Log، تحلیل و بررسی عمیق Log، Forensic Log و سایر امکاناتی باشد که App های Commercial و App های رایگان (Free) ارائه می‌دهند. بنابراین، با توجه به این اهداف، در یک SOC و برای استفاده از Splunk، Log های متفاوت از تجهیزات گوناگون جمع‌آوری شده، به سمت Splunk ارسال می‌شوند، در Splunk، Index شده و سپس برای استفاده کاربران و App های Commercial یا رایگان (Free) قابل دسترس می‌شوند. بنابراین اگر دقت کنید، دستیابی به اهداف پیشرفته موجود، وابستگی زیادی به Data ورودی به Splunk دارد.

چالش‌های جمع‌آوری و استانداردسازی Log ها

از طرف دیگر، در یک سازمان یا SOC، تجهیزات متنوعی از Brand های مختلف با کارکردهای گوناگون و Log های متفاوت وجود دارند. اکثر این Log ها و Data ها دارای Format های متفاوتی هستند و Format آن‌ها با یکدیگر تفاوت دارد. به‌‌عنوان مثال، Log های تجهیزاتی مانند FortiGate با Log های تجهیزاتی نظیر FMC و Cisco کاملاً متفاوت هستند. این تفاوت، چالشی بزرگ برای Splunk و SOC ایجاد می‌کند مبنی بر اینکه چگونه این Log ها استانداردسازی شوند و چه Methodology ای باید ایجاد گردد تا تمام Log ها بر اساس آن استاندارد شده، همگی Format یکسانی داشته باشند و بتوان با آن ها به‌‌صورت استاندارد با یک Format واحد کار کرد و یک Language مشترک را آموخت.

نیاز به استانداردسازی در Splunk

برای مثال، اگر قصد ساخت یک App را داشته باشیم که وظیفه اصلی آن تحلیل و بررسی Log های مربوط به ترافیک شبکه باشد، باید توجه داشت که Log مرتبط با ترافیک شبکه توسط تجهیزات مختلفی تولید می‌شود که هر کدام Structure های متفاوتی دارند. حال پرسش این است که App مورد نظر باید با کدام یک از این Structure ها و Format ها سازگار (Compatible) باشد؟ آیا می‌توان App ای ساخت که با تمام Format ها کار کند و استانداردسازی اهمیتی نداشته باشد؟ یا بهتر است یک استاندارد واحد وجود داشته باشد که پس از دریافت Log ها، آن‌ها را Process کرده، استانداردسازی نماید و سپس در اختیار کاربر و سایر App ها قرار دهد؟

چالش‌های ساخت App و Dashboard در Splunk

ممکن است تصور شود ساخت App فرآیندی پیچیده است. این مثال را می‌توان به ساخت Dashboard نیز تعمیم داد. چگونه می‌توان یک Dashboard ساخت که بر روی Log های Network Traffic کار کند و بتوان آن را در محیط‌های مختلف به کار گرفت؟ اگر Dashboard بر اساس Log خام یک سیستم خاص ایجاد شود و آن Log در Splunk دیگری به نحو متفاوتی Parse شده باشد، احتمالاً Dashboard در محیط جدید به درستی کار نخواهد کرد و نیازمند تغییرات خواهد بود. اما اگر یک Format استاندارد وجود داشته باشد و Dashboard بر اساس آن Format ساخته شود، در تمام محیط‌های Splunk که از آن Format پیروی می‌کنند، به راحتی قابل انتقال و استفاده خواهد بود.

برای جمع‌بندی این مباحث، در Splunk به یک Methodology یا راهکار نیاز داریم تا بتوانیم فرآیندهای نرمال‌سازی Data را به‌صورت استاندارد پیاده‌سازی کنیم. App مربوط به CIM که در Splunkbase موجود است و قابل نصب و استفاده می‌باشد، این هدف را دنبال می‌کند. با نصب این App، مجموعه‌ای از Data Model های از پیش تعریف‌شده نیز نصب و پیاده‌سازی می‌شوند که می‌توان از آن‌ها استفاده کرد.

CIM ( Common Information Model )

وقتی در Splunk از CIM صحبت می‌شود، علاوه بر App موجود در تصویر، به مجموعه‌ای از Document ها و مفاهیم نیز اشاره دارد که با اصطلاح CIM شناخته می‌شوند. زمانی که قصد استفاده از CIM یا همان Methodology استاندارد برای Normalization Data را دارید، مراجعه به Document های CIM ضروری است. بنابراین، App مربوط به CIM که استفاده می‌کنیم، متکی بر یک Document بسیار مهم است و استفاده از این App باید همراه با مطالعه و پیروی از این Document باشد.

فرض کنید مجموعه‌ای از Data را جمع‌آوری کرده‌اید و در Splunk در حال Index شدن هستند. ابتدا باید با استفاده از Document مربوط به CIM، Knowledge Object های لازم (که در فصل‌های پیشین در مورد آن‌ها صحبت شد) را بر روی آن Data پیاده‌سازی کنید. یعنی با مراجعه به Document، مشخص کنید چه Field هایی باید Extract شوند، نام آن‌ها چه باید باشد، چه Tag هایی مورد نیاز است و سایر Knowledge Object ها را ایجاد نمایید. سپس App مربوط به CIM را نصب کنید تا Data Model های آن، Data شما را شناسایی کرده و فرآیند Normalization را آغاز کنند. پس از آن، می‌توانید از خروجی Data Model ها به Data نرمال‌شده دسترسی داشته باشید.

همان‌طور که در ویدئوهای قبلی اشاره شد، قرار نیست تمام این کارها لزوماً توسط شما انجام شود. در بسیاری موارد، Technology ها یا App های دیگری وجود دارند که این Knowledge Object ها را برای شما تعریف می‌کنند و می‌توانید از آن‌ها استفاده کنید.

تا اینجای ویدئو، انتظار می‌رود که Concept کلی را درک کرده باشید و آن این است که: یک App به نام CIM وجود دارد که پشت آن یک Document قوی قرار دارد و Methodology لازم برای Normalization Data در آن توضیح داده شده است که باید از آن استفاده کرد.

اگر به Module مربوط به Knowledge Object ها بازگردیم، مواردی مانند Field Extraction، Field Alias، Event Type و Tag مطرح شد. زمانی که قصد ایجاد Field Extraction، Field Alias، Event Type یا حتی Tag را دارید، باید از استاندارد CIM استفاده کنید. نکات مهمی در این زمینه وجود دارد. استفاده از CIM ضروری است تا App هایی که در آینده نصب می‌کنید، بتوانند روی محیط Splunk شما کار کرده و بهترین خروجی را ارائه دهند.

در مبحث Knowledge Object ها بر اهمیت تنظیم صحیح Permission ها تاکید شد. زیرا زمانی که Knowledge Object ها را ایجاد می‌کنید، باید Permission ها به درستی تنظیم شوند تا App های دیگر بتوانند از این Object ها استفاده کنند. در نهایت، با استفاده صحیح از App CIM و Data Model های آن، می‌توان Event های دریافتی از Source ها و Sourcetype های مختلف را راحت‌تر و با کارایی بهتر Correlate (مرتبط) کرد.

نحوه تعامل CIM با سایر App ها و Add-on ها

سوال مهمی که مطرح می‌شود این است که Add-on مربوط به CIM چگونه با سایر App ها و Add-on های موجود تعامل می‌کند؟

Add-on مربوط به CIM یک App از نوع Search Time است . با مفهوم Search Time در ویدئوهای گذشته آشنا شدیم. مانند سایر App ها، این App نیز در (Search Time) اجرا می‌شود.

سازگاری CIM با سایر App ها

اگر سایر App های موجود با مفاهیم CIM سازگار (Compatible) باشند و از Document آن پیروی کنند، Data ای که آن App ها با آن کار می‌کنند، Normalize شده و سپس در Data Model های تعریف‌شده توسط CIM قرار می‌گیرد. همان‌طور که در Module مربوط به Data Model بحث شد، Data موجود در Data Model ها قابل دسترس و استفاده است.

اگر App ها CIM Compatible نباشند ، سازگار با CIM نباشند، شما باید با استفاده از Knowledge Object هایی مانند Field Alias، Tag یا Event Type، Data مربوطه را Normalize کرده و با CIM سازگار کنید.

برای مثال، فرض کنید Log های دو تجهیز امنیتی مختلف را از شبکه جمع‌آوری کرده‌اید: یک Firewall مربوط به FortiGate و یک Firewall مربوط به Firepower Cisco . Log های آن‌ها در تصویر نمایش داده شده است: Log های FMC و Log های FortiGate .

راهکارهای Normalize کردن Log ها

زمانی که این Log ها Index شدند، برای Normalize کردن آن‌ها و اجرای فرآیند Normalization، چندین راهکار وجود دارد:

استفاده از TA یا App های موجود: به Splunkbase مراجعه کرده و برای Log مورد نظر جستجو کنید تا ببینید آیا TA، App یا Add-on ای وجود دارد که CIM Compatible باشد. در این صورت، با نصب و استفاده از آن، Log های شما Parse شده و Knowledge Object های لازم یعنی Field Alias، Tag، Event Type و ... مطابق با استاندارد CIM برای شما تعریف می‌شوند و Log ها Normalize می‌گردند. در واقع، برای برخی Log های رایج، اشخاص یا خود Splunk، App یا Add-on هایی را توسعه داده‌اند که وظیفه اصلی آن‌ها، Normalization آن Log خاص مطابق با استاندارد CIM است.

Normalization دستی: اگر TA یا App سازگار با CIM برای Log مورد نظر شما وجود نداشت، شما باید فرآیند را به‌صورت دستی انجام دهید. یعنی تمام Knowledge Object های لازم Field Extraction، Field Alias، Event Type، Tag ها و... را خودتان ایجاد کنید تا Data با Data Model مقصد در CIM سازگار شود. برای این کار، به Document مربوط به CIM و Data Model مورد نظر مراجعه کرده، Field ها و Tag های الزامی را شناسایی کرده و Knowledge Object های لازم را بر اساس آن ایجاد می‌کنید. برای مثال این مستندات مربوط به Change را ببینید. فیلدهای action، change_type و destination وجود دارد. این ها باید extract شوند یا Aliase برایشان تعریف شود و بعد event_type و tag برایشان تعریف شود. تگ های مورد نیازشان را هم اینجا نوشته است. هدف ما در اینجا، این است که آن Data Model کامل شود تا بتوان از دیتای آن ها در سایر app ها استفاده کرد. الان روی این دو لاگ از دو تجهیز مختلف که داریم مثال می زنیم، هدف یکی است.

اگر دقت کنید به طور مثال، برای فیلدی مانند ip ، اینجا یک src_ip داریم و در آن یکی لاگ هم srcip داریم که تفاوت دارد. قبلی underline دارد و این یکی ندارد. تمام این ها باید Normalize شود و آن فیلدی باید نام گذاری شود که Data Model و CIM ما نیاز دارد. برای این منظور باید وارد مستندات CIM شویم و با توجه به نوع لاگ که در اینجا Network_Traffic بود، بررسی می کنیم که برای source چه چیزی باید نوشته شود. می بینیم که src باید درنظر گرفته شود. البته یک فیلد دیگر هم به نام src_ip داریم که باید مطالعه کنید ببینید بر اساس کدام یک باید فیلدها را extract کنید. باید حداکثر تلاشتان را بکنید که این را کامل کنید. پس زمانی که یک Log را دریافت و ایندکس می کنید، باید در Splunkbase دنبال TA و Addon آن Log باشید که در توضیحات مربوط به آن TA و App نوشته شده باشد که این App CIM Compatible است. یعنی برای Log، Field Extraction، Field Alias، Event Type و knowledge Object هایی تعریف می کند که مطابق با CIM و Data Model مقصد آن باشد.

برای مثال Log مربوط به فایروال Check Point ، لاگ های مرتبط با Network Traffic و Intrusion Detection دارد که در Addon مربوط به CIM دو Data Model برای این کار وجود دارد. زمانی که شما از این TA CheckPoint استفاده می کنید Knowledge Object هایی را برای شما ایجاد می کند مرتبط با آن Data Model مقصد است. اگر این TA و App وجود نداشتند باید آن Knowledge Object ها را به صورت دستی ایجاد کنید. برای مثال پیش از این TA و App ای مرتبط با Kerio وجود نداشت و مجبور بودم که آن ها را دستی ایجاد کنم. یا همین الان برای لاگ های KSMG Kaspersky چیزی وجود ندارد و شما باید داده های این Mail Gateway را مطابق با Data Model ایمیل سازگار و Normalize کنید و Knowledge Object هایی که مورد نیاز است را تعریف کنید.

نکته‌ای در مورد Search Time و Index Time

نکته‌ای در مورد Search Time و Index Time به یاد داشته باشید که برخی تنظیمات در TA ها و App ها مربوط به Index Time و برخی دیگر مربوط به Search Time هستند . جزئیات بیشتر در دوره Admin ارائه خواهد شد. برای مثال فرض کنید، لاگ های مرتبط با KSMG Kaspersky که مرتبط با ایمیل است را دریافت کردید و هیچ گونه TA و App ای برای آن وجود ندارد. ابتدا باید به مستند CIM و Data Model مربوطه مراجعه کنید و ببینید که چه فیلدهای ضروری وجود دارد. باید ابتدا Field Extraction برای لاگ تان تعریف کنید و بعد بر اساس Extraction ای که انجام شده Field Alias هایی را تعریف کنید فیلدهای مدنظر این data model را داشته باشد و در نهایت با استفاده از Event Type تگ مورد نظر و موارد دیگر را روی آن Data اعمال می کنید تا با Data Model و CIM مدنظر سازگار شود. همین طور داده هایی مانند Network Traffic و یا داده های مرتبط با web server ها را به طور مثال با Data Model مربوط به Web باید سازگار کنید.

جدولی که می بینید برخی از فیلدهای این Data Model مربوط به Web است که زمانی که شما لاگ های IIS یا Apache را جمع آوری می کنید و از TA و app مرتبط به آن استفاده می کنید، حتما کنترل کنید که آیا فیلدهای مورد نیاز Data Model را ایجاد می کند یا مشکلی وجود دارد که باعث جلوگیری از نرمالیزه کردن داده ها می شود. زمانی که شما از TA و App ای استفاده می کنید، بررسی کنید که در مستندات چه نیازمندی هایی وجود دارد. همچنین بررسی کنید که بعد از نصب آن Addon آیا لاگ های شما نرمالیزه می شود یا خیر.

بررسی Data Model ها در CIM

در ویدئوهای قبلی یاد گرفتیم که چطور Data Model ایجاد کنیم و چطور از آن استفاده کنیم و مطالب مربوط به آن را به طور کامل بررسی کردیم. در ویدئوهای قبل تر نیز در مورد knowledge object ها و پروسه Normalization صحبت کردیم. همچنین درباره متدولوژی CIM صحبت کردیم و گفتیم که اگر می خواهیم Normalization انجام دهیم، باید بر اساس متد CIM باشد و هدف ما کامل کردن این Data Model ها باشد تا App ها و کاربران بتوانند به راحتی از آن‌ها استفاده کنند.

همان‌طور که اشاره شد، با نصب App CIM، حدود ۲۷ تا Data Model (در این نسخه) ایجاد می‌شود . این تعداد ممکن است در آینده تغییر کند و برخی Data Model ها منسوخ یا Deprecated شوند. شما یک سری داده هایی دارید باید آن را بر اساس CIM نرمالیزه کنید و Knowledge Object های آن را بسازید یا TA استفاده کنید که این کار را برای شما انجام دهد و در نهایت این Data Model ها پر می شوند. اگر Data Model مربوط به Network Traffic یا Intrusion Detection را بررسی کنیم، مشاهده می‌شود که Constraint تعریف‌شده برای آن‌ها معمولاً ترکیبی از یک Macro و Tag است. Macro معمولاً برای تعیین Index هایی است که Data مربوطه در آن‌ها ذخیره شده و Tag برای شناسایی Event های مرتبط با آن Data Model است.

اهمیت استفاده از Tag ها و Macro ها

به همین دلیل بر استفاده صحیح از Tag ها بر اساس استاندارد CIM تاکید می‌شود. شما باید با مراجعه به Document مربوط به CIM، Tag های مخصوص هر Data Model را شناسایی کرده و آن‌ها را به درستی بر روی Data خود اعمال کنید. همچنین، باید Macro مربوط به Index ها را در Setting > Advanced Search > Search Macros ویرایش کرده و نام Index هایی که Data مربوط به آن Data Model در آن‌ها قرار دارد را وارد نمایید. این کار به بهبود Performance کمک می‌کند. چون Data و تگ های مرتبط با آن سریع پیدا می شوند و داده ها اینجا قابل استفاده می شود. همان طور که می بینید فیلدهایی هم اینجا وجود دارد که باید از داده های شما استخراج کند. اگر داده های شما فیلد destination ip را نداشته باشد و برای مثال dest_ip باشد، آن دیتا اینجا قرار نمی گیرد و به جای آن unknown قرار می گیرد. پس در پروسه Normalization باید این موارد را بررسی کنید حتی اگر از App ها و TA ها استفاده کنید.

Constraint همه Data Model های CIM به این صورت است یعنی ترکیبی از tag و نام ایندکس. داخل یک Data Model چندین دیتاست متفاوت از نوع Event وجود دارد که شما می توانید آن ها را بررسی کنید. اما یک نکته مهم وجود دارد. ما در ویدئوهای قبلی که درباره Data Model صحبت کردیم، به وسیله Pivot ها ، Data Model را تست کردیم. اما یک Command ای وجود دارد به نام from و datamodel که به وسیله این دستورات نیز می توانیم دیتایی که درون دیتامدل است را ببینیم و تست کنیم.

روش‌های اعتبارسنجی Data Model ها

همان طور که در تصویر می بینیم، با استفاده از دستور from و کلمه data model و ذکر ID مربوط به Data Model، به همراه دیتاست مرتبط می توانیم دیتاهایی که با این دیتامدل Match می شوند را ببینیم و همین طور فیلدهایی که وجود دارد را بررسی کنید تا از صحت فرآیند Normalization و سازگاری Data با CIM اطمینان حاصل نمایید. برای مثال، می‌توانید فیلد app یا src را بررسی کرده و مقادیر موجود در آن‌ها را مشاهده کنید. اگر فیلد مورد انتظار در لیست Field ها وجود نداشت، مشکلی بین Raw Data و Data Model وجود دارد. یا نام آن متفاوت است یا مشکلی در Knowledge Object ها وجود دارد. در همین ویدئو وقتی گفتم بررسی کنید منظورم این بود که با استفاده از این دستور دیتایی که در دیتامدل است را ببینید و فیلدی وجود نداشت مشکل آن را پیدا کنید و مشکل را رفع کنید تا اینجا به شما نمایش داده شود. برخی App های کمکی برای این کار وجود دارند که در دوره ESIM به آن‌ها پرداخته خواهد شد؛ چون آنجا خیلی به ما کمک می کند.

پس با این دستور آشنا شوید: pipe from datamodel : و بعد ID مربوط به مدل تان درون دابل کوت و بعد از آن نقطه می گذاریم و ID مربوط به دیتاست را هم وارد می کنیم. می توانیم نام دیتاست را هم ننویسیم و خودش Root Dataset را به شما نمایش می دهد. این دستور را به شکل دیگری هم می توان استفاده کرد. باز هم می نویسیم pipe from datamodel و بعد ID مربوط به Data Model و بعد از آن دیتاست و بعد کلمه search را استفاده کنیم. همان طور که می بینیم دیتای موردنظر اینجا دارد نمایش داده می شود و می توانیم آن Validate کنیم که آیا درست است یا خیر. این دو دستور، به خصوص دستور from، برای اعتبارسنجی (Validate) و کار با Data Model ها بسیار مفید هستند. توصیه می‌شود این دستورات و مفاهیم CIM را تمرین و تکرار کنید و اگر سوالی داشتید حتما با من در ارتباط باشید.

جمع بندی ماژول و دوره

این Module که آخرین بخش دوره Splunk Fundamental 2 بود، یکی از مهم‌ترین ماژول‌ها محسوب می‌شود، زیرا مفاهیم CIM و Normalization، زیربنای اصلی برای کار با Splunk در سطوح پیشرفته‌تر و استفاده از App های قدرتمندی مانند ESIM و ITSI است. تسلط بر مفاهیم ارائه شده در دوره‌های Fundamental 1 و 2، پیش‌نیاز ورود به دوره‌های Admin، Data Admin، System Admin و دوره‌های مرتبط با توسعه Search، Dashboard و App است. این مفاهیم ممکن است در ابتدا کمی پیچیده به نظر برسند، اما با تمرین و تکرار، به بخشی عادی از کار با Splunk تبدیل خواهند شد.

حوزه Splunk، به ویژه در زمینه Security و Data Analysis، در حال حاضر با کمبود نیروی کار متخصص مواجه است. با مطالعه دقیق، آموزش با کیفیت و تمرین مستمر، می‌توانید در این حوزه به یکی از بهترین‌ها تبدیل شوید. از همراهی شما در این دوره سپاسگزارم. پس از اتمام این دوره، می‌توانید از طریق ایمیل با من در ارتباط باشید و در صورت وجود هرگونه مشکل یا سوال، پاسخگوی شما خواهم بود. با سپاس، تا دوره بعدی خدانگهدار.

موارد مرتبط

نظرات

متوسط امتیازات

بدون امتیاز 0 رای

تماس بگیرید

0 نقد و بررسی

جزئیات امتیازات

5 ستاره

4 ستاره

3 ستاره

2 ستاره

1 ستاره

دیدگاهها

هیچ دیدگاهی برای این محصول نوشته نشده است.

اولین نفری باشید که دیدگاهی را ارسال می کنید برای “دوره آموزشی Splunk Fundamentals 2”

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

امتیاز شما

خیلی ضعیف

نه خیلی بد

متوسط

خوب

عالی

دیدگاه شما *

نام *

ایمیل *

وب‌ سایت

لطفا برای ارسال یا مشاهده تیکت به حساب خود وارد شوید

قیمت

تماس بگیرید

تعداد دانشجویان

0 دانشجو

0 دیدگاه 112 بازدید

تاریخ انتشار: 8 آذر 1404

امتیاز کاربران:

بدون امتیاز 0 رای

دسته بندی

splunk/

لینک کوتاه:

https://soclib.ir/?p=12539

آخرین اطلاعیه ها

سرفصل های آموزشی

ماژول یک - Beyond Search Fundamentals

مروری بر Basic Search

خلاصه دستورات دوره قبل

بررسی Case Sensitivity در Splunk Search

فرایند جستجو و Buckets

انواع Bucket

نکات مربوط به Bucket

بررسی Search Best Practices

Transforming Search Command

Mode های مختلف Search

حالت Fast Mode

حالت Smart Mode

حالت Verbose Mode

ماژول دو - Using Transforming Commands for Visualization

انواع Visualization ها در Splunk

انواع Data Series

انواع چارت ها

LineChart

Column Chart

Bar Chart

Pie Chart

Scatter Chart

Bubble Chart

دستورات مربوط به چارت ها

دستور Chart

دستور Timechart

ماژول سه - Using Trendlines, Mapping, and Single Value Commands

میانگین متحرک (Moving Average)

دستور Trendline در Splunk

استفاده از Map در Visualization

دستور iplocation

دستور geostats برای Cluster Map

دستور geom برای Choropleth Map

بصری‌سازی Single Value ها

استفاده از Trend و Sparkline

نمایش مجموع Total در نتایج

دستور addtotals

ماژول چهار - Filtering Results and Manipulating Data

دستور eval

عدم تاثیرگذاری eval روی لاگ اصلی

syntax دستور eval

Case-sensitive بودن Field-Value های دستور eval

استفاده همزمان از دستور sort و eval

تابع tostring

تابع Range

دستور Eval با چندین Expression

توابع شرطی If و Case

تابع case

تابع eval به عنوان Function در دستورات دیگر

دستور where

دستور CASE

کلمه کلیدی LIKE در دستور where

دستور fillnull

ماژول پنج - Correlating Events

Transaction چیست؟

مثال‌های کاربردی از Transaction

تعیین ابتدا و انتهای Transaction

بررسی مثال‌ها:

چالش نرمال‌سازی فیلدها در Transaction

ایجاد یک Single Event با transaction

نکته مهم در ترتیب نمایش فیلدها

مقایسه transaction و stats

ماژول شش - Understanding Knowledge Objects

مقدمه

knowledge objects چیست؟

چرا به Knowledge Objects نیاز داریم؟

اهمیت کاربرد صحیح Knowledge Objects

انواع knowledge object

خصوصیات اصلی knowledge object

اهمیت نقش knowledge manager

مستندسازی و تجربه شخصی

نامگذاری knowledge object

مروری بر Permissionها

جدول سطوح دسترسی در Splunk

معرفی CIM (Common Information Model)

ماژول هفت - Creating and Managing Fields

Field Extraction در Splunk

Field Discovery و Modeهای مختلف جستجو