با ماژول اول دوره Splunk Enterprise Data Admin در خدمت شما هستیم. در این ماژول، ابتدا یک overview بر روی Splunk Enterprise ارائه خواهد شد. سپس، چهار فاز اصلی مرتبط با مدل‌های توزیع‌شده Splunk بررسی می‌شوند. در نهایت، در خصوص فایل‌ها و directory های پیکربندی Splunk و همچنین اولویت و تقدم در زمان search time و index time صحبت خواهیم کرد. در پایان نیز نگاهی به ابزار btool خواهیم داشت.

تفاوت دوره های Data Administrator و System Administrator

قبل از ورود به دوره Data Administrator، بهتر است با تفاوت‌های آن با دوره System Administrator آشنا شویم. تمرکز اصلی دوره Data Admin بر مدیریت و onboarding data است. همچنین، لازم به ذکر است که در تیم‌های Splunk، معمولاً نقشی مرتبط با data onboarding وجود دارد و فردی که این نقش را بر عهده دارد، مسئول مستقیم شناسایی و جمع‌آوری data های مورد نیاز تحلیل‌گران است.

همچنین باید توجه داشت که تمام data های جمع‌آوری شده، باید مطابق با یک فرآیند مشخص انجام پذیرد و تمام جزئیات مرتبط با جمع‌آوری آن data باید document شود. فرد مسئول onboarding data، باید وظایف technical مربوط به جمع‌آوری آن log در سمت Splunk Universal Forwarder و Heavy Forwarder را انجام دهد. پس از آن، باید کارهای مرتبط با parsing آن data را نیز به انجام رساند تا آن log بتواند توسط dashboard ها و ماژول‌هایی مانند ES مورد استفاده قرار گیرد و زمانی که این وظایف را انجام می‌دهد، باید تمام configuration file های مرتبط با input را نیز مدیریت کند. در صورتی که نیاز به اعمال تغییری در فرآیند جمع‌آوری data باشد، می‌تواند از ابزارهایی مانند Deployment Management استفاده کرده و آن تغییر را در دامنه Universal Forwarder های مورد نظر deploy کند. در نهایت، باید به این نکته توجه داشت که لازم است از یک محیط آزمایشگاهی برای جمع‌آوری و parsing data ی مشابه استفاده شود.

اما در دوره System Admin، شما با نصب، پیکربندی و مدیریت component های مختلف Splunk آشنا می‌شوید. همچنین، می‌آموزید که Splunk app ها چه هستند و چگونه می‌توان آن‌ها را نصب و مدیریت کرد. پس از آن، با مفاهیم licensing و index های Splunk آشنا شده و نحوه مدیریت آن‌ها را فرا می‌گیرید. علاوه بر این، در دوره System Administrator به مباحث مدیریت کاربران، configuration file ها و monitoring console نیز پرداخته می‌شود.

معماری Splunk

همانطور که می‌دانید، Splunk را می‌توان با معماری‌های مختلف نصب کرد؛ از یک single instance گرفته تا داشتن cluster های مختلف در لایه‌های گوناگون. همانطور که در دوره System Admin توضیح داده شد، زمانی که از یک single instance استفاده می‌شود، تمام جنبه‌های مختلف پردازش data در همان single instance اتفاق می‌افتد؛ از ورود و دریافت data گرفته تا indexing و searching که توسط کاربر انجام می‌شود، همگی توسط همان یک single instance صورت می‌پذیرد. ذکر شد که این مدل deployment، عمدتاً برای موارد تستی مناسب است.

زمانی که قصد طراحی یک طرح یا معماری Splunk Enterprise برای پوشش محیط‌های بزرگ سازمانی وجود دارد (محیط‌هایی که دارای چندین source و ماشین‌های تولیدکننده log هستند و log آن‌ها باید جمع‌آوری شود و در نهایت user های زیادی قصد search بر روی Splunk و استفاده از آن را دارند)، در چنین محیط‌هایی باید از معماری توزیع‌شده Splunk استفاده نمود و چندین Splunk Enterprise داشت تا بتوان حجم ورودی و تعداد user ها را support کرد.

هنگام استفاده از معماری توزیع‌شده Splunk، بسته به نوع طراحی، هر یک از component ها وظیفه خاصی را انجام می‌دهند. به عنوان مثال، یک یا چندین instance وجود دارند که صرفاً وظیفه ذخیره و indexing data را بر عهده دارند. در نهایت، در تمام این معماری‌ها، آشنایی با component ها و فازهای Splunk ضروری است تا بتوان فرآیند پردازش log ها و data ها را درک کرد و کاربر نهایی بتواند از طریق search head ها، log مورد نظر خود را جستجو کرده و از آن استفاده نماید.

چهار مرحله پردازش در Splunk

چهار stage اصلی برای Splunk وجود دارد که در این تصویر قابل مشاهده هستند:

• Input: منظور از input، ورود تمام data هایی است که مورد نیاز هستند.
• Parse: در این مرحله، data به event تبدیل می‌شود.
• Index: تمام dataیی که به event تبدیل شده است، در این مرحله ذخیره می‌شود.
• Search: در نهایت، در stage search، کاربر تمام data ی مورد نیاز خود را مشاهده کرده و می‌تواند به راحتی با آن کار کند.

این چهار stage ذکر شده (Input, Parse, Index, Search)، از جمله مهم‌ترین مطالبی هستند که باید به خاطر سپرده شوند. تا دوره Architect نیز با این چهار stage سروکار خواهید داشت. اگر در این مرحله درک درستی از این stage ها حاصل نشود، احتمالاً در دوره‌های بالاتر با مشکل مواجه خواهید شد. توضیحات بیشتری در خصوص این چهار stage ارائه خواهد شد، اما قبل از بررسی دقیق آن‌ها، لازم است مطالبی بیان شود و سپس در خلال همین توضیحات، به این چهار stage بازگشته و به تفصیل در مورد آن‌ها صحبت خواهیم کرد.

مولفه های Splunk

من بارها در خصوص component های مختلف Splunk صحبت کرده‌ام. Component هایی با عناوین Indexer, Search Head, License Master, Deployment Server, Heavy Forwarder و Master Node وجود دارند. همچنین، component دیگری به نام Deployer نیز وجود دارد (که در این تصویر نمایش داده نشده است). زمانی که Splunk Enterprise به صورت معماری توزیع‌شده طراحی می‌شود، باید از این component ها استفاده نمود.

همچنین، component Universal Forwarder نیز وجود دارد. پکیج Splunk UF (Universal Forwarder) از پکیج Splunk Enterprise مجزا است. می‌توان با استفاده از component Deployment Server، نقش Deployment Client را به این component اختصاص داد و به وسیله آن server، تمام Universal Forwarder هایی را که نقش Deployment Client دارند، مدیریت کرد.

یکی از نکات مهم در این قسمت، تعریف component است. در طراحی‌ها معمولاً از این اصطلاح استفاده می‌شود، اما تعریف دقیق آن ممکن است مشخص نباشد. زمانی که یک معماری توزیع‌شده Splunk طراحی می‌شود، به هر Splunk Enterprise که یک instance اختصاصی و تخصصی است، به صورت معمول component گفته می‌شود. با در نظر گرفتن یک استثناء، component ها full Splunk Enterprise instance هایی هستند که برای تمرکز بر روی یک یا چندین function Splunk پیکربندی شده‌اند (در خصوص function ها نیز صحبت خواهد شد).

استثناء مورد بحث، Universal Forwarder ها هستند. Universal Forwarder ها نسخه‌ای light از Splunk Enterprise بوده و پکیج آن‌ها نیز مجزا است. معمولاً در تیم‌های Splunk، هنگامی که admin ها در خصوص component ها صحبت می‌کنند، 100% به Universal Forwarder اشاره نمی‌نمایند. در فیلم‌های آموزشی انگلیسی‌زبان نیز، زمانی که از component صحبت می‌شود، قطعاً Universal Forwarder جزئی از هدف گوینده نیست.

حال، Component ها به دو دسته تقسیم می‌شوند:

• Component هایی که processing انجام می‌دهند.
• Component هایی که وظایف management را بر عهده دارند.

این تقسیم‌بندی بر اساس function هایی است که در ادامه مورد بحث قرار خواهند گرفت.

Component هایی که processing انجام می‌دهند، خود به سه دسته تقسیم می‌شوند:

• Forwarder ها
• Indexer ها
• Search Head ها

این‌ها component هایی هستند که وظیفه processing را بر عهده داشته و جزء دسته Processing Component های Splunk محسوب می‌شوند. اما component هایی که جزء Management Component ها هستند، شامل مواردی نظیر:

License ManagerMonitoring ConsoleDeployment ServerCluster Master (یا Master Node که مدیریت cluster index ها را انجام می‌دهد) و در نهایت، Search Head Cluster Deployer نیز جزو component های مدیریتی و management Splunk به شمار می‌روند.

تا این بخش از ویدئو، با چهار stage اصلی Splunk آشنا شدیم. این نکته مهم را نیز باید در نظر داشت که Splunk Enterprise سه function کلیدی برای پردازش data دارد:

• Function اول، خواندن data از file ها، network یا source های دیگر و ارسال آن به سمت Splunk
• Function دوم: پس از دریافت data توسط Splunk Enterprise، فرآیند parse و index آن data انجام می‌شود.
• Function سوم: در نهایت، زمانی که کاربر قصد استفاده از آن data را دارد، function اجرای search بر روی data های index شده باید اتفاق بیفتد که این کار توسط کاربر و از طریق component search head به راحتی قابل انجام است.

طراحی یک معماری توزیع شده Splunk

در صورتی که قصد انجام یک طراحی توزیع‌شده را دارید، باید به این سه function توجه کرده و آن‌ها را در اجزای طراحی خود لحاظ کنید. می‌توان یک یا چند component را به این function ها اختصاص داد.

در زمان طراحی، معمولاً با سه سطح (tier) مواجه می‌شویم که با این function ها مرتبط هستند:

• سطح Data Input
• سطح Indexing
• سطح Search Management

هر یک از این سطوح می‌توانند clustering و HA (High Availability) مختص به خود را داشته باشند که در دوره Clustering و Architect به تفصیل در مورد آن‌ها صحبت خواهد شد. در اینجا، صرفاً آگاهی از وجود این سه سطح در طراحی‌ها از منظر منطقی کافی است. به طور کلی، System Admin ها و Data Admin ها بر این function ها تسلط داشته و اطلاعات کافی در مورد آن‌ها دارند تا در زمان بروز مشکل، بتوانند به راحتی موارد را troubleshoot کنند.

همانطور که در تصویر مشاهده می‌شود، این سه سطح به صورت شفاف توضیح داده شده‌اند. سطح پایین، Data Input است که توسط forwarder ها handle می‌شود. انتخاب نوع forwarder در این سطح، به scale طراحی شما و data sourceی که قصد جمع‌آوری آن را دارید، بستگی دارد. اما معمولاً چندین Heavy Forwarder قبل از indexer ها وجود دارند که data را دریافت کرده و برای indexer ها ارسال می‌کنند.

سطح میانی و بعدی، Indexer ها هستند. در این سطح، امکان وجود cluster وجود دارد که مزایای خاص خود را دارد (در دوره Clustering به آن پرداخته می‌شود). سطح بعدی و بالاترین سطح، Search Management است. سطحی که کاربران مستقیماً با آن کار می‌کنند، Search Head است. در این سطح نیز می‌توان cluster مخصوص search head ها را داشت. وظیفه اصلی این سطح، اجرای search بر روی تمام indexer ها و نمایش یکپارچه خروجی آن‌ها به کاربر است.

نکته بسیار مهمی که باید در نظر گرفته شود، این است که به دلیل حجم بالای مطالب آموزشی در مباحث Clustering و Architect Splunk، لازم است ابتدا حداقل شش ماه الی یک سال سابقه کار در نقش‌های Sys Admin و Data Admin و کار با این solution وجود داشته باشد و پس از آن، اقدام به شرکت در دوره‌های Cluster و Architect نمود. تمام موارد مرتبط با Clustering و معماری Splunk در آن دوره‌ها بیان شده و جزئیات دقیق در آن دوره‌ها قابل بررسی است.

به عنوان جمع‌بندی تا این بخش از ویدئو، در خصوص چهار stage اصلی Splunk صحبت شد، process tier ها (سطوح و طبقات موجود در معماری Splunk) بررسی گردید. اکنون قصد داریم مجدداً به آن چهار stage اصلی Splunk بازگشته و در خصوص data pipeline ها صحبت کنیم. پیش‌تر در مورد سه سطح یا tier process data صحبت شد و گفته شد که این‌ها سه function کلیدی Splunk هستند.

هنگامی که این سه سطح را با جزئیات بیشتری بررسی می‌کنیم، به مفهوم data pipeline ها می‌رسیم. آن چهار stageی که ابتدا در خصوص آن‌ها صحبت شد (Input, Parse, Index, Search)، چهار stageی هستند که در data pipeline های Splunk وجود دارند. زمانی که یک data به Splunk Enterprise می‌رسد، تا زمانی که کاربر توسط search head، search را اجرا کرده و data را مشاهده می‌کند، data از این pipeline ها استفاده می‌کند تا به دست کاربر نهایی برسد.

سه سطح processing data شامل Data Input, Index و Search Management بودند. همچنین چهار stage اصلی شامل Input, Parsing, Index و Search بودند. اگر بخواهیم این موارد را به یکدیگر مرتبط کنیم، می‌توان گفت:

• سطح Data Input، stage Input data pipeline را support می‌کند.
• سطح Indexing، stage های Parsing و Indexing Splunk را support می‌کند.
• سطح Search Management، stage Search را support می‌کند.

تصویری که در صفحه مشاهده می‌شود، دیاگرام data pipeline Splunk است. قبل از توضیح این تصویر، نکته مهمی وجود دارد: در زمان مشاهده این ویدئو، ضروری است توضیحات ارائه شده را یادداشت کرده یا حداقل خلاصه‌ای از نکات مهم را ثبت نمایید. این ویدئوها به گونه‌ای طراحی شده‌اند که نیاز به توجه کامل در زمان ارائه توضیحات و همچنین یادداشت‌برداری و مرور موارد مهم دارند. زیرا مباحث تئوری مطرح شده، base و اساس دانش Splunkی شما را تشکیل می‌دهند و صرفاً انجام پیکربندی کافی نیست. پیکربندی را می‌توان به راحتی از manual های موجود دریافت و استفاده کرد، اما درک concept های اساسی اهمیت بالایی دارد و باید نسبت به آن‌ها آگاهی داشت.

خب، همانطور که در تصویر مشاهده می‌شود، از بالا، قسمت اول Input قرار دارد. این بخش دقیقاً به stage Input اشاره می‌کند. در این مرحله، streamی از raw data وجود دارد که Heavy Forwarder آن را از یک source دریافت می‌کند. زمانی که این stream از raw data دریافت می‌شود، به block های 64 کیلوبایتی تقسیم (break) شده و سپس metadata ی مرتبط به آن block اضافه می‌گردد. Field هایی مانند host، sourcetype و source جزو metadata هایی هستند که به block ها اضافه می‌شوند. در این مرحله، Splunk Enterprise به content داخل آن data توجهی نمی‌کند و این موضوع در این مرحله اهمیتی ندارد.

نکته مهم دیگری که در این مرحله وجود دارد، این است که هنگام اضافه کردن آن metadata ها، برخی از پیکربندی‌هایی که در سطح input انجام می‌شود، در همین مرحله به block ها اضافه می‌گردند. به عنوان مثال، تنظیمات index که در فایل input برای input های مختلف ایجاد می‌کنیم. فرض کنید streamی از raw data های مرتبط با تجهیزی مانند Cisco در حال ارسال است و inputی که پیکربندی شده، یکی از پارامترهای آن تنظیمات index است. در این مرحله، metadata ی index نیز برای آن block ها اضافه می‌شود. در این مرحله باید به این نکته توجه داشت که فقط برخی از key metadata ها به کل آن source data stream اضافه می‌شوند و در مراحل بعدی، metadata های دیگر اضافه خواهند شد. هنگام طراحی یک معماری Splunk، برای stage Input، می‌توان component هایی مانند Heavy Forwarder و حتی Indexer را در نظر گرفت. با قائل شدن یک استثناء برای Universal Forwarder، می‌توان در این stage از Universal Forwarder نیز استفاده کرد. همانطور که در تصویر مشاهده می‌شود، قبل از هر pipeline، یک صف یا queue نیز وجود دارد که در خصوص صف‌ها و queue ها در ویدئوهای آینده صحبت می‌کنیم.

پس از stage Input، stage Parsing قرار دارد. این stage معمولاً توسط component هایی مانند Indexer و Heavy Forwarder انجام می‌شود و یکی از stage های مهمی است که تسلط بر آن ضروری است. در این stage، Splunk Enterprise، data ی شما را بررسی، تحلیل و transform می‌کند. مباحثی مرتبط با event processing در Splunk وجود دارد که دقیقاً در این stage، data process شده و به event تبدیل می‌گردد. زمانی که data از stage Input وارد stage Parsing می‌شود، Splunk Enterprise آن stream از data ها را که به block های 64 کیلوبایتی تبدیل شده بودند، به event های مجزایی تبدیل می‌کند (به اصطلاح آن‌ها را break می‌کند). این stage دارای sub-stage هایی است که event ها را process می‌کنند. برخی از وظایفی که در این stage و sub-stage های Parsing انجام می‌شود، شامل موارد زیر است:

• شناسایی line termination با استفاده از line breaking rule های موجود؛
• مشخص شدن ابتدا و انتهای event ها و سپس تشخیص event های مجزا؛
• Extract شدن field های پیش‌فرض مانند host, source و sourcetype؛
• شناسایی timestamp مرتبط با آن event و درج field های مرتبط با آن؛
• و اعمال پیکربندی‌هایی مانند character encode در همین stage.

گفته شد که در این stage، مجموعه‌ای از field های پیش‌فرض به log یا event ما اضافه می‌شود. اما این field های پیش‌فرض کدامند؟ همانطور که در تصویر مشاهده می‌شود، مجموعه‌ای از field ها در این stage اضافه می‌گردند: Internal Fields, Basic Fields و Default Datetime Fields که هر کدام با هدف خاصی به event ما افزوده می‌شوند. همانطور که در تصویر مشاهده می‌شود و احتمالاً در کار با Splunk نیز به کرات با آن مواجه شده‌اید، فیلد _time وجود دارد. این field جزو metadata هایی است که Splunk به event شما اضافه می‌کند. همچنین، صحبت شد که Splunk Enterprise، line termination را تشخیص داده و می‌تواند بر اساس آن، ابتدا و انتهای log را مشخص کرده و آن را به عنوان یک event در نظر بگیرد. برای این منظور، مجموعه‌ای از تنظیمات نیز وجود دارد. همانطور که در تصویر قابل مشاهده است، تنظیماتی وجود دارند که می‌توان از آن‌ها استفاده نمود (با برخی از این تنظیمات در این دوره حتماً آشنا خواهیم شد). اما برای بررسی بیشتر توسط خودتان، حتماً این کار را انجام دهید: TA هایی را که برای Windows و Linux وجود دارد، بررسی کرده و فایل‌های props آن‌ها را مشاهده کنید تا ببینید چه تنظیماتی مرتبط با line breaker ها، timestamp یا مواردی که در این ویدئو مشاهده می‌کنید، وجود دارد.

خب، اگر به تصویر قبلی بازگردیم، پس از Parsing Stage، Stage Indexing قرار دارد. مهم‌ترین وظیفه این stage، نوشتن event هایی است که parse شده‌اند، بر روی disk تحت عنوان index. این نوشتن data بر روی disk به صورت فشرده (compressed) انجام می‌شود. یعنی آن raw data ی شما، زمانی که قرار است بر روی disk نوشته شود، compress می‌گردد. همچنین، این فرآیند به همراه مجموعه‌ای از فایل‌های مرتبط با index صورت می‌گیرد که در کنار raw data های شما ذخیره می‌شوند. Stage بعدی در خصوص Search است. همانطور که در همین ویدئو اشاره شد، در این stage، user به search head ها دسترسی دارد و در خصوص data ی مورد نظر خود، search ایجاد می‌کند. یا ممکن است dashboard هایی وجود داشته باشد که در پس‌زمینه آن‌ها search اجرا می‌شود. همچنین، report هایی نیز ممکن است وجود داشته باشند که base تمام آن‌ها search هایی باشند. این search ها اجرا شده و خروجی مورد نظر کاربر نمایش داده می‌شود. در این stage، مواردی با عنوان Knowledge Object وجود دارد که در دوره‌های Fund 1 و Fund 2 در خصوص آن‌ها صحبت شده است.

در این تصویر و اسلایدی که در صفحه مشاهده می‌شود، جمع‌بندی‌ای از موارد مطرح شده در این ویدئو ارائه گردیده است. در خصوص stage ها و function ها صحبت شد؛ چهار مرحله  Input, Parsing, Indexing و Searching وجود داشتند و function هایی نیز وجود داشتند که با این stage ها مرتبط بودند. در مرحله اول، به وسیله forwarder می‌توان stage Input را پوشش داده و log های مورد نظر را دریافت کرد. پس از آن، forwarder، streamی از data را به سمت indexer ارسال می‌کند و در این نقطه است که stage Parsing و سپس Indexing اتفاق می‌افتد. گفته شد که دو component Indexer و Heavy Forwarder می‌توانند stage Parsing را پوشش دهند و Indexer می‌تواند stage Indexing را پوشش دهد.

همانطور که در تصویر مشاهده می‌شود، بخشی با عنوان License Meter در اینجا وجود دارد. زمانی که عملیات parsing بر روی data اتفاق می‌افتد، پس از آن، License Meter حجم log را اندازه‌گیری می‌کند. البته باید ذکر شود که metadata و data ی replication جزو محاسبات لایسنس محسوب نشده و در نظر گرفته نمی‌شوند و فقط حجم data ی شما محاسبه شده و از لایسنس کسر می‌گردد. و پس از آن، stage Indexing اتفاق می‌افته که در آن، log و event مورد نظر بر روی disk نوشته می‌شود (بر اساس تنظیمات انجام شده توسط admin). سپس، search head، stage Searching را پوشش می‌دهد که کاربر به وسیله این component می‌تواند به event ها دسترسی داشته باشد. البته نکته بسیار مهمی در خصوص stage Search وجود دارد: این stage می‌تواند توسط component Indexer نیز پوشش داده شود و امکان search بر روی Indexer نیز وجود داشته باشد، اما این کار معمول نیست.

تا این بخش از ویدئو در خصوص stage ها صحبت شد. در ادامه این ویدئو، قصد داریم در خصوص configuration file ها صحبت کنیم. پیش‌تر ویدئویی در این خصوص ضبط شده و در دوره Sys Admin نیز در مورد configuration file ها صحبت شده است. مطالب دقیقاً همان موارد هستند و از ضبط مجدد مطالب خودداری شده و همان ویدئو در اینجا قرار داده می‌شود تا مشاهده فرمایید.

configuration file چیست؟

در درس های گذشته ما چند configuration file را مشاهده کردیم اما در مورد اینکه configuration file چیست صحبت نشد. configuration file جنبه های مختلف functionality اسپلانک را کنترل و مدیریت می کنند. زمانی که شما پیکربندی برای هر ابزار و نرم افزاری تنظیم می کنید، آن پیکربندی را در یک قالبی ذخیره و استفاده می کند. اسپلانک هم به همین شکل کار می کند. یعنی آن پیکربندی که شما در سطح UI اعمال می کنید، به صورت clear text ذخیره می شود  اسپلانک از آن استفاده می کند. در اسپلانک الزامی به پیکربندی از طریق web UI نیست و در قالب command نیز می توان این کار را انجام داد یا به صورت مستقیم configuration file را ایجاد کنید و شروع به پیکربندی کنید یا اینکه همان configuration file ای که وجود دارد یا ویرایش کنید.

در تصویری که مشاهده می کنید یکی از configuration file  های مهم اسپلانک به نام input.conf نمایش داده شده است. به نام های فایل های پیکربندی دقت کنید. همانطور که می‌دانید، مجموعه‌ای از فایل‌های پیکربندی مهم Splunk با نام‌های inputs.conf, outputs.conf, props.conf, transforms.conf وجود دارند. هر یک از این فایل‌ها، کارکرد و functionality خاص خود را داشته و در اصل، functionality Splunk را کنترل می‌کنند. تمام این فایل‌های پیکربندی به صورت clear text و case-sensitive هستند و همگی از یک ساختار مشترک استفاده می‌کنند. این ساختار مشترک چیست؟ زمانی که فایل پیکربندی ایجاد یا باز می‌شود، بخشی با نام stanza وجود دارد (علامت آن در تصویر قابل مشاهده است). اگر دقت کنید، در داخل این stanza کلمه default نوشته شده است. این کلمه default، یک کلمه کلیدی است که از پیش برای پیکربندی inputs.conf تعریف شده و مورد استفاده قرار می‌گیرد. بنابراین، در داخل stanza ها، قالبی وجود دارد که باید رعایت شود؛ این قالب یا از پیش تعریف شده است یا base آن از پیش تعیین گردیده است. به عنوان مثال، در مورد بعدی، در stanza ی بعدی، از کلمه monitor استفاده شده و آدرسی در مقابل آن قرار گرفته است. کلمه monitor یک کلمه کلیدی است و در document های Splunk ثبت شده که هنگامی که کاربر در configuration inputs.conf از کلمه کلیدی monitor استفاده می‌کند، باید پس از آن، آدرسی را ارائه دهد. بنابراین، برخی از stanza ها static هستند (مانند default) و برخی دیگر dynamic می‌باشند (بخشی از پیش تعریف شده و بخش دیگر باید توسط کاربر و متناسب با نیاز وارد شود).

این stanza به بخشی از functionality Splunk اشاره دارد. نکته قابل توجه این است که امکان حفظ کردن تمام این stanza ها وجود ندارد. صرفاً برخی از موارد مهم‌تر به مرور زمان آموخته شده و در ذهن تثبیت می‌شوند و برای موارد جدید مورد نیاز، باید به document مراجعه کرده و از آن‌ها استفاده نمود. در document های Splunk، بخشی وجود دارد که تمام configuration file ها را توضیح داده و همینطور stanza هایی که نیاز دارید را نیز در اینجا توضیح داده است.

قسمت بعدی configuration file ها، attribute ها به علاوه value ها هستند. attribute ها قبل از مساوی قرار می‌گیرند، value مرتبط با attribute ها بعد از مساوی قرار می‌گیرند. برای مثال، در تصویری که مشاهده می‌شود، از attribute host استفاده شده که آن را برابر با www قرار داده‌اند. یا در مثال بعدی، attribute sourcetype را داریم که برابر با access_common قرار داده شده و همینطور attribute index را داریم که مقدار آن را برابر با web قرار داده‌اند. پس یک فایل پیکربندی تشکیل شده از stanza ها و attribute ها و value ها. ما با attribute ها مشخص می‌کنیم دقیقاً چه چیزی را می‌خواهیم پیکربندی کنیم و چه valueی را می‌خواهیم برای آن پیکربندی قرار دهیم. این attribute ها هم در تمام این فایل‌های پیکربندی از قبل list شده و شما می‌توانید در document های Splunk آن‌ها را ببینید. اما یک سری از attribute هایی که خیلی استفاده می‌شود، در app ها، در TA ها، در کار، کم‌کم با اینها آشنا می‌شوید و از آن استفاده می‌کنید. برای همین در درس قبلی گفته شد که TA ها را ببینید، پیکربندی‌هایشان را ببینید، ببینید از چه پیکربندی‌هایی استفاده شده است که کم‌کم با آن ها آشنا شوید.

تمام این فایل‌های پیکربندی در مسیر نصب Splunk در شاخه etc قرار می‌گیرند. یک نکته خیلی جالب هم که وجود دارد، در مسیر نصب Splunk در directory etc/system، یک directory readme وجود دارد که در این directory تمام documentation ها و sample های پیکربندی وجود دارد که می‌توان از آن‌ها استفاده کرد. یعنی اگر در جایی نیاز به documentation Splunk داشتید و اینترنت در دسترس نبود، می‌توانید از این example ها و configuration ها و document ها استفاده کنید.

اگر بخواهیم سه تا از مهم‌ترین configuration file ها را در سه تا از مهم‌ترین component ها بررسی کنیم، در تصویری که مشاهده می‌کنید این بررسی انجام شده است. component اول Universal Forwarder است. همانطور که می‌دانید، Universal Forwarder برای جمع‌آوری data استفاده می‌شود و معمولاً برای جمع‌آوری data از سطح سیستم‌عامل‌ها نصب می‌شود. به این نکته هم توجه کنید که Universal Forwarder قابلیت دریافت log از طریق network هم دارد. یعنی شما می‌توانید Universal Forwarder را روی یک سیستم‌عامل نصب کنید و data ی سیستم‌عامل را جمع‌آوری نکنید و به جایش یک portی را باز کنید که data از طریق تجهیزات networkی وارد آن سیستم‌عامل و وارد Universal Forwarder بشود و Universal Forwarder برای indexer یا heavy forwarder ارسال کند. اما Universal Forwarder بیشتر برای جمع‌آوری data از سطح سیستم‌عامل نصب می‌شود.

اگر در Universal Forwarder بخواهیم بگوییم که چه dataیی جمع‌آوری شود، باید از configuration file inputs.conf استفاده کنیم. در این configuration file ما باید بگوییم که دقیقاً چه dataیی باید جمع‌آوری شود و همینطور attribute هایی که مد نظرمان هست مثل host، sourcetype، اسم index را هم مشخص کنیم. البته که attribute های دیگری هم هست که بر اساس نوع log می‌توانیم ازشان استفاده کنیم. در درس قبل که در خصوص TA و app ها صحبت کردم، لطفاً TA مرتبط با Windows و Linux را بررسی کنید و فایل inputs.conf را به دقت بررسی کنید. چرا که همین بررسی ساده این فایل‌ها باعث می‌شود شما یک قدم جلو باشید از نظر اینکه چه پیکربندی‌های متداولی در این configuration file ها استفاده می‌شود. configuration props.conf در Universal Forwarder یک functionality parsing محدود به همراه دارد. در درس‌های آینده در خصوص این parsing بیشتر صحبت می‌کنیم اما همین قدر بدانید که parsing در props.conf، functionality هایی مثل set کردن character encoding، set کردن metadata، مشخص کردن event break هاست و دقیقاً زمانی که شما Universal Forwarder را روی Windows یا Linux نصب می‌کنید، این limited parsing فقط برای data های Windows و Linux در Universal Forwarder وجود دارد و اگر log های دیگر مثل log های تجهیزات شبکه‌تان را با Universal Forwarder جمع‌آوری کنید، این limited parsing وجود ندارد. فقط برای log های مرتبط با سیستم‌عامل‌ها این limited parsing ها وجود دارد. پس زمانی که شما دارید data را جمع‌آوری می‌کنید و ارسال می‌کنید، props.conf، feature های محدود شده parsing را برای شما در Universal Forwarder به همراه دارد. در خصوص این character encode و event break هم در این دوره صحبت خواهیم کرد.

پیکربندی بعدی outputs.conf است که در این فایل پیکربندی شما باید مقصدی را مشخص کنید که data می‌خواهد برای آن مقصد ارسال شود و آن مقصد data را به نحوی دریافت کند. برای مثال، در برخی از معماری‌ها، Universal Forwarder ها log هایشان را به heavy forwarder یا به صورت مستقیم به سمت indexer ها ارسال می‌کنند. بسته به نوع معماری، configuration outputs.conf پیکربندی می‌شود. در ادامه توضیح چگونگی پیکربندی آن را توضیح خواهیم داد. ما تا الان در خصوص Universal Forwarder صحبت کردیم. درخواست من از شما این است که به اسم‌ها دقت کنید. یک موقع Universal Forwarder را با heavy forwarder اشتباه نگیرید. در ادامه در خصوص چیستی heavy forwarder خیلی بیشتر صحبت می‌کنیم.

در همین جدول، اگر heavy forwarder وجود داشت، در heavy forwarder، inputs.conf باز هم دارد مشخص می‌کند که چه dataیی را دریافت کند و قطعاً نوع پیکربندی دریافت data از تجهیزات شبکه متفاوت از دریافت و جمع‌آوری log هایی است که در یک سیستم‌عامل وجود دارد. همچنین در heavy forwarder، فایل props.conf دیگر parsing محدود ندارد و full functionality parsing آنجا می‌تواند انجام شود و شما حتی می‌توانید feature های بیشتری مثل event routing را داشته باشید. و در انتها باز هم outputs.conf در heavy forwarder مشخص‌کننده مقصد یا دریافت‌کننده log است که در معماری‌ها معمولاً indexer ها هستند یا اگر معماری خاصی باشد که باز هم آن log را به سمت یک heavy forwarder دیگر ارسال کنند.

نکته بسیار مهمی که وجود دارد و شما باید ذهنیت خودتان را بر این اساس منطبق کنید این است که این سه configuration file دارد به سه مرحله مهم در Splunk اشاره می‌کند، در component های Splunk اشاره می‌کند. مرحله input یا مرحله جمع‌آوری log را داریم، حالا چه log هایی که از سمت تجهیزات networkی می‌آید یا log هایی که در سطح خود سیستم‌عامل‌ها وجود دارند (log های local). سطح بعدی، process log است، حالا این process هرچه که می‌خواهد باشد، که با فایل props.conf اتفاق می‌افتد و مرحله ارسال آن data به component بعدی، به سطح بعدی است که با پیکربندی outputs.conf اتفاق می‌افتد. در مواردی شما روی componentی هستید که دیگر نیاز به ارسال وجود ندارد و آن component دارد log را ذخیره می‌کند مثل (indexer). مواردی هم هست در componentی هستید که نیاز به ارسال آن data دارید مثل Universal Forwarder، مثل heavy forwarder، باید قطعاً output را پیکربندی کنید. پس ذهنیت خودتان را بر این اساس منطبق کنید که هر componentی به احتمال زیاد به این سه تا نیاز دارد که البته بر اساس نقشش، امکان دارد یکی از این configuration ها را نیاز نداشته باشد.

Component بعدی indexer است که inputs.conf در indexer دارد مشخص می‌کند که چه dataیی را روی چه portی می‌خواهید دریافت کنید. در معماری‌هایی که heavy forwarder یا universal forwarder، log را دارد ارسال می‌کند به indexer ها، قطعاً روی یک portی دارد آن را ارسال می‌کند که به صورت پیش‌فرض این port، 9997 است. زمانی که یک indexer را پیکربندی می‌کنید، باید آن port را مشخص کرده و آن را در inputs.conf باز کنید که این کار هم از طریق UI و هم از طریق CLI یا پیکربندی مستقیم فایل inputs.conf قابل انجام است. پس در indexer هایی که دریافت‌کننده log هستند، شما باید port ورودی را باز کنید. حالا این port ورودی می‌تواند محدودیت‌های IP داشته باشد، محدودیت‌های خیلی دیگری داشته باشد که من به صورت general و بدون محدودیت دارم صحبت می‌کنم. ما می‌خواهیم log را دریافت کنیم، روی چه portی دریافت کنیم؟ یک موقعی هم هست شما می‌خواهید log را به صورت localی از سیستم‌عامل indexer جمع‌آوری کنید که آن هم به وسیله inputs.conf امکان پذیر است ولی این مسئله را من فعلاً مطرح نمی‌کنم چون ممکن است که شما بعضی مباحث را با هم اشتباه بگیرید و یک مقدار مفاهیم برایتان بد جا بیفتد.

پس در indexer ها ما inputs.conf را پیکربندی کردیم که port 9997 باز باشد، بتواند از universal forwarder یا heavy forwarder  لاگ بگیرد.

مرحله بعدی props.conf است که آن logی که دارد دریافت می‌شود باید process شود، باید parsing رویش اتفاق بیفتد. برای مثال metadata ی مورد نظر Splunk به آن data اضافه شود، time extraction اتفاق بیفتد، timezoneش مشخص شود و و کلی process دیگری که امکان دارد وجود داشته باشد. حالا بعد از اینکه این process انجام شد، در indexer ها دیگر نیازی نیست آن log ارسال شود به جای دیگر چون قرار است به صورت localی روی خود indexer ذخیره شود. پس دیگر نیازی نیست outputs.conf پیکربندی شود.

Component بعدی search head است. در معماری‌هایی که وجود دارد ما log را به سمت search head نمی‌خواهیم ارسال کنیم. هیچ componentی logش را به سمت search head ارسال نمی‌کند چون اصلاً search head وظیفه‌اش فرق می‌کند. Search head قرار است آن logی که در indexer ها هست را بخواند و به شما نمایش دهد. پس اینجا inputs.conf نقش ورودی networkی ندارد مگر اینکه باز هم بخواهید log های internalی را جمع‌آوری کنید که اینجا نیاز به پیکربندی inputs.conf با پیکربندی‌ای است که شما دارید log را به صورت localی جمع‌آوری کنید که من این را هم باز مطرح نمی‌کنم چون ممکن است که شما بعضی مباحث را با هم قاطی کنید و یک مقدار مفاهیم برایتان بد جا بیفتد. پس در search head ها ما inputs.conf نداریم مگر اینکه نیاز داشته باشیم internal log Splunk را جمع‌آوری کنیم.

مرحله یا پیکربندی بعدی در search head ها props.conf است. ما در props.conf در search head، قرار است logی که از indexer ها خوانده می‌شود و قرار است به کاربر نمایش داده شود را یک process کوچکی رویش انجام دهیم مثل field extraction، مثل functionality های دیگری که زمان search time اتفاق می‌افته که در ادامه در خصوص اینکه search time چیست، index time چیست صحبت می‌کنیم. یا یک سری lookup ها وجود دارد که data ی شما را غنی می‌کند، یک سری field ها به آن اضافه می‌کند، این کار هم در فایل props.conf اتفاق می‌افتد و شما خیلی راحت از طریق UI می‌توانید این را پیکربندی کنید. پس تا اینجا، در search head ها ما مگر در مواقع خاص نیازی به inputs.conf نداریم. نیاز به props.conf داریم برای اینکه آن logی که می‌خواهد به کاربر نمایش داده شود، یک process کوچکی رویش انجام شود، یک سری field extraction و یک سری عملیات رویش انجام شود. و در نهایت، پیکربندی outputs.conf هم نیاز نیست مگر در مواقع خاص. برای مثال اگر بخواهید internal log Splunk را که در inputs.conf جمع‌آوری کردید را ارسال کنید به یک component دیگر. باز هم ترجیح می‌دهم این مسئله را قاطی این موضوع نکنم که مفاهیم برایتان ساده‌تر جا بیفتد.

پس برای نتیجه‌گیری، در search head ها هم ما outputs.conf نیاز نداریم مگر در مواقع خاص. خب چهار تا از component های اصلی Splunk را در خصوص inputs.conf، props.conf، outputs.conf صحبت کردیم. البته که در ادامه نحوه پیکربندی این موارد را هم بررسی می‌کنیم و با جزئیات بیشتر به این موضوع می‌پردازیم. دوره‌های Splunk به گونه‌ای است که شما کم‌کم یک سری موارد را پیش می‌روید، می‌بینید، می‌فهمید و یاد می‌گیرید. و الان اگر بخواهیم یک نمونه inputs، props.conf و output را با هم ببینیم، به TA Windows یا Linux مراجعه کرده و بررسی‌اش می‌کنیم.

اکنون من در directory Splunk TA Windows هستم. این TA را از Splunkbase دانلود کرده، extract نموده‌ام و وارد اولین directory آن شده‌ام و در حال مشاهده ساختار directory ها هستم. bin, default, lib, lookup و چند directory دیگر وجود دارد. گفته شد که مهم‌ترین آن‌ها default, bin, lookup هستند. در directory bin، مانند directory bin Splunk، فایل‌های اجرایی و script ها قرار دارند. در directory default، تمام پیکربندی‌هایی که به صورت پیش‌فرض هستند قرار دارند و اگر بخواهیم از این پیکربندی‌ها استفاده کرده و آن‌ها را تغییر دهیم، باید یک directory local ایجاد کرده و در local، آن پیکربندی را وارد و تغییر دهیم (در ادامه باز هم در این مورد صحبت خواهیم کرد). وارد default می‌شوم. در این directory، configuration های مختلفی وجود دارد.

configuration eventtypes؛ ما در خصوص eventtype ها در دوره‌های fund صحبت کردیم. زمانی که eventtype را در Web UI Splunk ایجاد می‌کنیم، فایل configuration آن تحت عنوان eventtypes.conf ساخته می‌شود. در TA Windows که توسط خود Splunk در Splunkbase ارائه می‌شود، از پیش eventtype هایی ایجاد شده‌اند و زمانی که ما از این TA در search head استفاده می‌کنیم، این eventtype ها برای ما نصب شده و ما و app های دیگر می‌توانند از آن‌ها استفاده کنند. به عنوان مثال، app هایی وجود دارند که صرفاً visualization ارائه می‌دهند، یعنی برای log Windows بصری‌سازی انجام می‌دهند و dashboard ساخته‌اند. آن app ها از این eventtype ها استفاده می‌کنند تا یک ساختار استانداردی برای visualization خود داشته باشند. شما نیز می‌توانید از این eventtype ها استفاده کنید.

Configuration بعدی inputs.conf است که در خصوص آن صحبت کردیم. همانطور که در تصویر مشخص است و با توجه به توضیحات ویدیوی TA و همین ویدئو، این inputs.conf که متعلق به TA Windows است، برای collection log های سطح Windows می‌باشد. یعنی می‌توان از این در Universal Forwarder نیز استفاده کرد و زمانی که این TA به Universal Forwarder منتقل می‌شود، فقط از configuration های مرتبط با Universal Forwarder آن به صورت خودکار استفاده می‌شود. پس این inputs.conf را که برای collection Windows است، می‌خواهیم بررسی کنیم که چه محتوایی دارد.

در ابتدای کار، مجموعه‌ای از comment وجود دارد و سپس یک stanza باز شده که با WinEventLog شروع شده و پس از آن به یکی از channel های Windows اشاره می‌کند (channel Application) که یکی از channel های مرتبط با log Windows است. اگر به Event Viewer Windows مراجعه کنید، مشاهده خواهید کرد که یک channel Application وجود دارد. اگر بخواهید در سطح Windows و به وسیله Universal Forwarder، log channel های مختلف Windows را جمع‌آوری کنید و این کار را به صورت دستی پیکربندی نمایید، باید از چنین formatی استفاده کنید: در stanza، WinEventLog: و پس از آن باید به channel مورد نظر اشاره کنید. و پس از بستن stanza، attribute های مورد نظر خود را وارد نمایید. به عنوان مثال، در این stanza، ابتدا از attribute disabled, start_from, current_only, checkpoint_interval و render_xml استفاده شده که هر یک از این‌ها توضیحات خاص خود را دارند و این TA که در حال استفاده است، کاملاً بهینه می‌باشد. برای مثال، disabled می‌تواند این stanza را فعال یا غیرفعال کند. اگر از attribute disabled استفاده شده و مقدار آن برابر 1 قرار داده شود، آن stanza غیرفعال است. start_from وجود دارد که مقدار آن برابر با oldest set شده، یعنی خواندن را از اولین log شروع کند. render_xml وجود دارد؛ با توجه به اینکه base log های Windows به صورت XML است، این attribute به این اشاره دارد که در Universal Forwarder، log های Windows که base آن‌ها XML است، render شده و بهتر نمایش داده شوند. برای تسلط بهتر بر attribute ها، حتماً به مستندات  inputs.conf اسپلانک مراجعه کنید تا ببینید چه attribute ها و stanza هایی وجود دارد. به عنوان مثال، اگر بخواهید log هایی را که مرتبط با DHCP هستند و base آن‌ها فایل است، جمع‌آوری کنید، باید از stanza ی monitor استفاده نمایید. همینطور log های مرتبط با transaction DNS.

این TA ویژگی‌های دیگری نیز دارد؛ مثلاً مجموعه‌ای از script ها را با خود دارد و زمانی که از این TA بر روی Universal Forwarder استفاده می‌کنید، می‌توانید stanza ی مرتبط با آن script را ابتدا فعال کنید تا log آن را نیز جمع‌آوری نمایید.

نکته‌ای که در زمان نصب Universal Forwarder وجود دارد: زمانی که قصد نصب Universal Forwarder را دارید، باید آن را با configuration پیش‌فرض و حداقلی نصب کنید و این TA را (directory اصلی آن را) در پوشه etc/apps Universal Forwarder قرار داده، آن را restart کرده و configuration هایی مانند output را انجام دهید. در یکی از ویدئوهای همین دوره، این فرآیند انجام می‌شود. می‌توانید به آن ویدئو مراجعه کنید تا دقیقاً متوجه شوید که این TA در کجا باید کپی شود و Universal Forwarder چگونه نصب می‌گردد.

فایل‌های پیکربندی دیگری که در این TA وجود دارد، شامل props.conf است که همانطور که عرض شد، یک parsing محدود شده را اعمال می‌کند. البته پیکربندی‌ای که در اینجا مشاهده می‌شود، بسیار مفصل است، زیرا بخشی از پیکربندی‌های آن برای heavy forwarder، بخشی مناسب search head و بخشی دیگر برای Universal Forwarder است. پس در نتیجه، با توجه به componentی که این TA بر روی آن نصب می‌شود، function های مختلف اجرا شده و نتیجه مثبتی برای شما خواهد داشت.

پیکربندی‌های دیگری که وجود دارد شامل tags, transforms, WMI است، اما outputs.conf وجود ندارد. دقت کنید که outputs.conf معمولاً در TA ها قرار داده نمی‌شود و خود شما باید آن پیکربندی را اضافه کنید. به عنوان مثال، در heavy forwarderی که در لابراتوار من وجود دارد، یک فایل outputs.conf از پیش ایجاد شده است که این فایل output باعث می‌شود log ها به سمت مجموعه‌ای از server هایی که indexer هستند، ارسال شوند. حال، این configuration به چه نحوی است و چگونه انجام می‌شود، در ادامه در خصوص آن صحبت خواهیم کرد.

پس configuration input Windows، props Windows و همچنین configuration مرتبط با output یک heavy forwarder را مشاهده کردیم. البته نحوه پیکربندی configuration output در تمام component ها یکسان است و تفاوتی ندارد.

یکی از مطالبی که تسلط بر آن بسیار مهم است، configuration directory ها هستند. همانطور که قبلاً توضیح داده شد، Splunk به نحوی طراحی شده که قابلیت نصب app های مختلف بر روی آن وجود دارد و configuration های مختلف به وسیله این app ها و add-on ها به مجموعه Splunk شما اضافه می‌شوند. زمانی که Splunk نصب می‌شود، تمام پیکربندی‌ها در directory etc قرار می‌گیرند و اگر نیاز به backup گرفتن از پیکربندی باشد، کافی است از همین directory یک نسخه کپی تهیه نمود.

Configuration هایی که مد نظر شماست و می‌خواهید بر روی سیستم اعمال شوند، هم از طریق app ها و هم از طریق system قابل اعمال هستند. اما تفاوت آن‌ها چیست؟ در ادامه در خصوص آن صحبت خواهیم کرد؛ اولویت‌های مختلفی بین app های گوناگون و همچنین configurationی که در system اعمال می‌شود، وجود دارد. اما در این بخش، مهم شناخت configuration directory ها است.

system یکی از مهم‌ترین configuration directory هایی است که با آن سروکار خواهید داشت. همانطور که گفته شد، اصلاً نیازی نیست که در default، پیکربندی اضافه یا custom شود. اگر نیاز به اضافه کردن پیکربندی در system باشد، کافی است directory local ایجاد گردد. یا می‌توان یک app برای خود ایجاد کرده (با نام دلخواه) و در directory local آن app، configuration های مختص خود را اعمال نمود.

به این نکته نیز توجه داشته باشید که user هایی که با سیستم کار می‌کنند، حتی user هایی با سطح دسترسی پایین، هر پیکربندی یا تنظیماتی را که تغییر دهند، در profile آن‌ها و در directory users، آن پیکربندی قرار می‌گیرد.

یکی از نکاتی که در document های Splunk بارها و بارها بیان شده، این است که اصلاً نباید در default هیچ‌گونه پیکربندی را تغییر داده یا اضافه نمود. به این علت که زمانی که Splunk update می‌شود، directory default در زمان update کاملاً override می‌گردد و اگر پیکربندی در آنجا تغییر داده شده باشد، تمام آن پیکربندی حذف خواهد شد.

اگر در configuration directory ها، directory local وجود نداشت، می‌توان آن را ایجاد کرد. این نکات به قدری مهم هستند که چندین بار از ابتدای دوره بیان شده‌اند. تمام پیکربندی‌ها باید در directory های local اضافه یا تغییر داده شوند. زیرا زمانی که Splunk یا آن app update می‌شود، directory local حفظ شده و تمام پیکربندی‌های شما را نگه می‌دارد.

یکی دیگر از مطالب و نکات مهمی که شاید تا کنون برای شما سوال ایجاد کرده باشد، این است که اگر یک configuration file مشابه (مثلاً یکی از configuration file های Splunk مانند inputs.conf) در directory های system/local, apps/search/local, system/default و app های دیگر وجود داشته باشد، چه اتفاقی رخ می‌دهد؟ اگر در داخل این فایل inputs.conf، stanza ی مشابه با attribute های مشابه و value های متفاوت وجود داشته باشد، چه اتفاقی می‌افتد؟

به صورت کلی، زمانی که Splunk start می‌شود یا یک search run می‌گردد، فقط یک نسخه از configuration file های آن mode در RAM قرار گرفته و یا Splunk از آن استفاده می‌کند. تمام فایل‌های پیکربندی مشابه با یکدیگر merge می‌شوند، duplicate ها و conflict های آن‌ها به نحوی رفع شده و کاربر یا خود Splunk از آن استفاده می‌کند.

برای توضیح بهتر، فرض کنید فایل inputs.conf در system/default, system/local و apps/search/local وجود دارد و در داخل این فایل inputs.conf هم stanza های مشابه و هم stanza هایی که با هم مشابه نیستند (و در هر کدام به صورت یکتا هستند) وجود دارد. آن‌هایی که به صورت یکتا هستند و مشابه ندارند، همگی با هم merge شده و Splunk از آن‌ها استفاده می‌کند یا کاربر از آن‌ها استفاده می‌نماید. اما آن‌هایی که مشابه هستند، بر اساس یک متدی که در ادامه در خصوص آن صحبت خواهد شد، با یکدیگر merge می‌شوند و مواردی که اولویت بالاتری دارند، در فایل پیکربندی نهایی قرار گرفته و Splunk در index time یا search time از آن استفاده می‌کند.

یکی از مهم‌ترین نکاتی که Splunk admin باید بر آن مسلط باشد، مطالب مرتبط با Index Time (یا Global Context) و Search Time (یا User Context) است. زمانی که log ها وارد Splunk شده، از pipeline های مختلف عبور کرده و index می‌شوند، به آن Index Time یا Global Context گفته می‌شود. زمانی که در این time و در این context قرار داریم، از فایل‌های پیکربندی مانند input, output و props استفاده می‌شود.

همچنین، زمانی که کاربر با Splunk به صورت مستقیم کار می‌کند (به عنوان مثال search می‌زند)، به آن Search Time یا User Context گفته می‌شود. و فایل‌های پیکربندی از قبیل ماکروها، save search ها و props نیز در این time استفاده می‌شوند. پس این دو time، این دو context را در ذهن داشته باشید و تفاوت کلی آن‌ها را درک کنید تا در ادامه به بررسی اولویت‌بندی merge کردن فایل‌های configuration در زمان Index Time بپردازیم.

همانطور که ذکر شد، امکان دارد فایل‌های پیکربندی مشابهی در قسمت‌های مختلف وجود داشته باشد. می‌خواهیم ببینیم که در Global Context چه اتفاقی برای این فایل‌های پیکربندی رخ می‌دهد. دقت کنید که فایل‌های پیکربندی مانند props برای هر دو context کاربرد دارند، اما برخی از attribute ها و value هایی که در این فایل پیکربندی وجود دارد، برای Global Context و برخی دیگر برای Search Time هستند (که در آینده بیشتر در این خصوص صحبت خواهیم کرد).

همانطور که در تصویر مشاهده می‌شود، این تصویر بیانگر Index Time Precedence است. یعنی زمانی که Splunk اجرا می‌شود، configuration file های کدام directory ها اولویت بالاتری دارند. همانطور که در گوشه سمت راست تصویر مشاهده می‌شود، اولویت‌های این تقدم به صورت اعداد 1 تا 4 نمایش داده شده‌اند.

در Global Context، با اولویت‌ترین دایرکتوری، directory system/local است و پایین ترین اولویت هم متعلق به system/default است و بین این دو اولویت، App هایی وجود دارند که بر اساس نامشان اولویت گذاری می شوند. به عنوان مثال، اگر نام یک app، A باشد، اولویت بالاتری نسبت به appی دارد که نام directory آن B است. همچنین دایرکتوری های لوکال App ها از دایرکتوری های default app ها اولویت بالاتری دارند.  برای مثال همان طور که در تصویر می بینید، دو App وجود دارد به نام search و unix که App search اولویت بالاتری دارد نسبت به unix app. پس در گام بعدی دایرکتوری های لوکال مقایسه می شوند و اولویت بندی می شوند.  در همین مثال، دایرکتوری لوکال search app اولویت بیشتری دارد نسبت به دایرکتوری لوکال unix app و دایرکتوری لوکال unix app، اولویت بالاتری نسبت به دایرکتوری default مربوط به search app دارد و دایرکتوری default مربوط به search app اولویت بالاتری نسبت به دایرکتوری default مربوط به unix app دارد.

بنابراین اگر بخواهیم واضح تر بگوییم، Configuration هایی که در مسیر etc/system/local قرار دارند، از اولویت بیشتری در Global Context برخوردارند (زمانی که Index Time است و log ها در حال ورود، پردازش و ذخیره شدن هستند).

پس از آن، directory local مربوط به app هایی که در etc/apps قرار دارند، اولویت دارند. حال، بین app ها اولویت‌بندی چگونه انجام می‌شود؟ بر اساس نام آن‌ها. و پس از آن، directory default مربوط به app ها اولویت دارند. باز هم در این قسمت، بین app ها بر اساس نامشان تصمیم‌گیری می‌شود.

و در نهایت، configuration هایی که در مسیر default etc/system هستند (همان directoryی که configuration های پیش‌فرض و اصلی Splunk در آن قرار دارد)، اولویت دارند.

اگر بخواهیم مثالی در این زمینه در Global Context یا Index Time داشته باشیم، فرض کنید که در directory های local/app/search, local/app/unix, local/app/indexes و همچنین local/system، یک فایل inputs.conf وجود دارد که پیکربندی‌های داخل این فایل‌ها در کادرهای تصویر نمایش داده شده‌اند. حال می‌خواهیم بدانیم که در نهایت، فایلی که merge می‌شود و در RAM قرار می‌گیرد، چه محتوایی دارد؟ بهتر است ویدئو را متوقف کرده، بر اساس مطالب گفته شده این تمرین را حل کنید و سپس ادامه ویدئو را مشاهده نمایید.

برای حل این تمرین، ابتدا بهتر است configuration هایی را که همپوشانی ندارند، جدا کرده و در فایل inputs.conf نهایی وارد کنیم و از آن‌ها استفاده نماییم و سایر مواردی را که همپوشانی دارند، بر اساس اولویت ذکر شده جایگذاری کنیم. اگر دقت کنید، یک stanza ی default وجود دارد. این stanza ی default در پیکربندی نهایی قرار می‌گیرد و همچنین attribute و valueی که برای آن set شده، در فایل پیکربندی نهایی قرار می‌گیرد. stanza ی بعدی که باید در خصوص آن تصمیم‌گیری کنیم، monitor مرتبط با فایل access.log است که اگر دقت کنید این stanza جای دیگری هم تکرار شده است. این stanza نیز در inputs.conf نهایی ما وارد می‌شود و فقط Attribute هایی که با هم همپوشانی دارند باقی می مانند. اولین attribute ای که همپوشانی دارد، host attribute است. اگر دقت کنید در دایرکتوری apps/search/local مقدار www1 قرار گرفته اما در system/local مقدار websvr1 قرار گرفته است. با توجه به اولویت هایی که بود، کدام یک از این value ها قرار می گیرد. قطعا value ای که در فایل inputs.conf دایرکتوری system/local قرار دارد. پس از آن attribute دیگری داریم که همپوشانی ندارد که sourcetype است. پس در نتیجه این attribute هم در inputs.conf نهایی قرار می‌گیرد.

stanza ی بعدی که باید در خصوص آن تصمیم‌گیری کنیم، monitor مرتبط با secure.log است. این stanza نیز در inputs.conf نهایی ما وارد می‌شود و همانطور که مشاهده می‌کنید، تنها موردی که همپوشانی دارد، sourcetype است. sourcetype مرتبط با linux-secure قرار می گیرد و بقیه attribute هایی که همپوشانی برای آن ها وجود ندارد، در فایل پیکربندی نهایی قرار داده می شود. نتیجه به این صورت می‌شود که می‌توانید فایل inputs.conf را (خروجی نهایی آن را) مشاهده کرده و استفاده کنید. پس زمانی هم که Splunk اجرا می‌شود، برای فایل‌های پیکربندی دیگر از همین روش استفاده می‌کند تا بتواند فایل پیکربندی نهایی را ایجاد کند. حالا یک سری نکات جزئی دیگر وجود دارد که در ادامه در خصوص آن‌ها صحبت خواهیم کرد.

اما در خصوص Search Time یا User Context چه اتفاقی رخ می‌دهد زمانی که کاربر search می‌زند؟ همانطور که در تصویر مشاهده می‌کنید، در اینجا پیچیدگی اندکی بیشتر است. در User Context یا Search Time، بالاترین اولویت با directory یا app هایی است که در مسیر user قرار دارند. یعنی در واقع، پیکربندی‌هایی که خود user ایجاد کرده و در حال استفاده از آن‌هاست (در app های مختلف). به عنوان مثال، اگر چندین macro یا چندین field alias در app های مختلف با دسترسی‌های گوناگون تعریف شده باشد که با یکدیگر همپوشانی داشته باشند، آخرین موردی که کاربر در زمان search مشاهده می‌کند، آن چیزی است که خودش تعریف کرده و در مسیر کاربری خودش قرار دارد.

و پس از آن، app هایی اولویت دارند که در مسیر etc/apps قرار دارند. اما در اینجا اولویت app ها برعکس است. یعنی اگر app B وجود داشته باشد، app B اولویت بالاتری نسبت به app A دارد. این نکته را دقت کنید.

تفاوت دیگر این است که در اینجا directory های default و local در یک app، در یک اولویت قرار می‌گیرند و دیگر مانند Global Context، ابتدا local ها اولویت بالاتری ندارند. کل آن app است که اولویت دارد و در داخل آن app، ابتدا directory local و سپس default بررسی می‌شود. و پس از این app، اگر app دیگری نیز وجود داشته باشد که اولویت کمتری داشته باشد، ابتدا directory local آن و سپس default آن بررسی می‌شود. و در نهایت، directory local/system و همینطور default/system اولویت دارند.

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

خب، تا اینجا در خصوص مجموعه‌ای از مباحث تئوری صحبت کردیم. در قسمت بعد، در خصوص موارد عملی صحبت خواهیم کرد. به Splunk مراجعه کرده و با دستورات جدیدی آشنا می‌شویم که با استفاده از آن‌ها می‌توان configuration های مورد نظر را validate نمود.

می‌توان configuration های Splunk را validate کرد؛ هم configuration هایی که در memory قرار دارند و هم configuration هایی که بر روی disk وجود دارند. اگر بخواهیم configuration هایی را که در memory قرار دارند، validate کنیم، می‌توان با استفاده از دستور زیر این کار را انجام داد:

splunk show config inputs

همانطور که مشاهده می‌کنید، با استفاده از دستور splunk show config inputs (inputs نام config fileی است که می‌خواهیم check کنیم؛ می‌توانستیم outputs قرار دهیم)، می‌توان configuration هایی را که در memory قرار دارند، validate نمود.

همچنین، می‌توان configuration هایی را که بر روی disk وجود دارند، check کرد با استفاده از دستوری که در ادامه می‌نویسم:

splunk btool inputs list

با استفاده از دستور splunk btool <config_file_name> list، می‌توان تمام configuration های مرتبط با configuration file input (یا هر فایل دیگری) را در کل مجموعه Splunk، list کرده و مشاهده نمود که چه input هایی وجود دارد و قابل استفاده است.

این دستور جزئیات بیشتری نیز دارد. به عنوان مثال، برای مشاهده جزئیات مرتبط با یک stanza خاص (حتی اگر آن stanza از این خروجی اولیه نباشد و مثلاً از یک config file دیگر برداشته شده باشد)، می‌توان در انتهای همین دستور، آن stanza را type کرد تا فقط اطلاعات مربوط به آن stanza نمایش داده شود و حتی می‌توان در انتهای دستور از switch –debug استفاده کرد تا اطلاعات بیشتری نمایش داده شود، مبنی بر اینکه در کدام مسیرها این stanza مشاهده شده است. همانطور که در خروجی مشاهده می‌شود، اکنون در app search، directory local، فایل inputs.conf، پیکربندی‌های مرتبط با این stanza وجود دارد.

با ماژول دوم از دوره Splunk Enterprise Data Admin در خدمت شما هستیم. در این ماژول به بررسی مواردی نظیر انواع data input ها و همچنین تنظیمات مرتبط با default metadata ها خواهیم پرداخت. همچنین، تفاوت بین فازهای input و parsing مشخص خواهد شد و در انتهای همین ویدئو، با استفاده از Splunk Web، مجموعه‌ای از input ها ایجاد شده و نتیجه آن به صورت عملی نمایش داده می‌شود.

مفهوم Data

پیش‌تر در ویدئوهای ابتدایی دوره Fund 1 و Fund 2 در خصوص data صحبت شد و ضروری است با مفهوم data آشنا شویم. در صورت رجوع به واژه‌نامه‌هایی مانند Oxford، مشاهده می‌شود که معمولاً لغت‌نامه‌ها، data را بدین صورت تعریف نموده‌اند که تمام حقایق یا factها و آمارهایی که برای تجزیه‌وتحلیل و reference جمع‌آوری می‌شوند، data نامیده می‌شوند. به نظر می‌رسد این تعریف، مناسبی باشد و با اندکی تامل بر روی آن، کاملاً قابل‌درک و استفاده است.

اما در حوزه Splunk چه انواعی از data وجود دارد؟ معمولاً data هایی که جمع‌آوری می‌شوند از نوع text خواهند بود و مواردی مانند log ها، configuration ها، message ها و alert هایی که تجهیزات امنیتی fire می‌کنند و همچنین metric هایی که در برخی از system ها وجود دارد را می‌توان data نامید. این نوع data از نوع text بوده و به نحوی قابل ارسال به Splunk Enterprise است. باید به این نکته توجه نمود که مواردی همچون script ها نیز وجود دارند که پس از اجرای این نوع script ها، معمولاً مجموعه‌ای از data های text به صورت file ذخیره می‌شوند و این موارد نیز به نحوی قابل ارسال هستند. نوع دیگری از data های بسیار مهم که در مراکز SOC وجود دارد، ticket ها هستند. هنگامی که یک SOC از یک سیستم ticketing استفاده می‌کند، می‌تواند پیکربندی‌هایی را انجام دهد که به محض ثبت یک ticket، مجموعه‌ای از data به سمت Splunk Enterprise ارسال شود و ماژول‌های مرتبط با آن، مانند Splunk Enterprise Security، بتوانند از آن data ی ticketing استفاده کنند.

تمام data ها دارای یک source هستند. در حوزه IT، تمام سیستم‌عامل‌ها، computer ها، تجهیزات network، virtual machine ها، تجهیزات ارتباطی، sensor ها، database ها و حتی تجهیزات IoT، یک source data محسوب می‌شوند و تمام این موارد، data های مختلف با format های گوناگون تولید می‌کنند. شما باید بر اساس strategy های مختلف، این data ها را با روش‌های گوناگونی که وجود دارد و compatible هستند، جمع‌آوری کنید. در زمان مشاهده این ویدئو، اگر سابقه کاری زیادی در این حوزه ندارید، خواهشمند است به توضیحات ارائه شده دقت فرمایید، موارد ذکر شده را یادداشت نموده و بر روی آن‌ها تامل کنید تا مطالب به خوبی در ذهن شما تثبیت شوند.

بنابراین، برای نتیجه‌گیری از این slide، ما با مجموعه‌ای از data های text مواجه هستیم که این data ها هر کدام از یک source نشات می‌گیرند. وظیفه ما این است که به نحوی این data ها را جمع‌آوری کرده و به سمت Splunk Enterprise ارسال کنیم. قطعاً باید در سمت Splunk Enterprise، input های مناسبی ایجاد کنیم تا بتوانیم این data ها را دریافت نماییم.

انواع Data Input در Splunk

اگر بخواهیم انواع type های data input موجود در Splunk Enterprise را بررسی کنیم، می‌توان از منوی Settings وارد قسمت Data Inputs شد. پس از کلیک بر روی این گزینه، وارد صفحه Data Inputs خواهید شد. در این صفحه، تمام type input هایی که Splunk Enterprise به صورت پیش‌فرض پشتیبانی می‌کند، به راحتی قابل مشاهده است.

نکته اول: زمانی که از برخی app های Splunk استفاده می‌کنید، ممکن است یک type جدید data input به input های Splunk Enterprise شما افزوده شود.

همچنین، این امکان وجود دارد که برخی از app ها و TA ها، input هایی را به Splunk Enterprise شما اضافه کنند. اگر به توضیحات پیشین توجه کرده باشید، مورد اولی که ذکر شد، type جدیدی از data input ها بود که توسط برخی app ها ایجاد می‌شود و جمله دوم، به اضافه شدن input به Splunk Enterprise شما اشاره داشت. به عبارت دیگر، امکان دارد برخی TA ها، به عنوان مثال، input های TCP، UDP یا File & Directory را اضافه کنند، در حالی که برخی app های دیگر، مستقیماً یک type input جدید را در اینجا اضافه می‌کنند.

File & Directory Data Input

به صورت پیش‌فرض، چندین type data input در Splunk وجود دارد. مورد اول File & Directory است. قطعاً log هایی را مشاهده کرده‌اید که در سیستم‌عامل‌ها به صورت file ذخیره می‌شوند. به عنوان مثال، سیستم‌عامل Linux، log های خود را به صورت فایل text ذخیره می‌کند. بنابراین، قطعاً تجهیزات و سیستم‌عامل‌های دیگری نیز وجود دارند که log های خود را به این شکل ذخیره می‌کنند. با استفاده از Splunk Enterprise می‌توان آن file را monitor کرد و به محض اضافه شدن data ی جدید به آن file، Splunk Enterprise آن را خوانده و ارسال می‌کند.

نکته‌ای که در اینجا مطرح می‌شود و احتمالاً به آن فکر کرده‌اید، این است که چرا این موضوع بر روی خود Splunk Enterprise توضیح داده می‌شود و به Universal Forwarder پرداخته نمی‌شود. این نکته را در نظر داشته باشید که Splunk Universal Forwarder نسخه‌ای از Splunk Enterprise با feature های محدود است و کاملاً از قوانینی که در این ویدئوها ذکر می‌شود، پیروی می‌کند. همچنین، با خود Splunk Enterprise نیز می‌توان کارهایی را که Universal Forwarder انجام می‌دهد، اجرا نمود. به عنوان مثال، اگر Splunk Enterprise را بر روی یک server لینوکسی نصب کرده باشید و بخواهید از آن به عنوان Indexer یا Search Head استفاده کنید، می‌توانید data inputی را پیکربندی کنید که log های داخلی همان سیستم‌عاملی که Splunk Enterprise بر روی آن نصب شده است را monitor کرده و بر روی همین Splunk ذخیره نماید. پس خواهشمند است به این نکته توجه کنید و این مسائل را با یکدیگر اشتباه نگیرید.

HTTP Event Collector Data Input

نوع بعدی data input، HTTP Event Collector است. تجهیزات و ابزارهایی وجود دارند که هم log خود را به صورت file ذخیره می‌کنند و هم قابلیتی در آن‌ها توسعه داده شده است که می‌توانند log ها را بر روی پروتکل HTTP یا HTTPS ارسال کنند. در Splunk برای دریافت چنین logی، باید از data input از نوع HTTP Event Collector استفاده کرد. پیکربندی این نوع input بسیار ساده است که در ویدئوهای آینده به آن پرداخته خواهد شد. بنابراین، اگر قصد استفاده از این نوع input را دارید، ابتدا باید بررسی کنید که آیا source ارسال‌کننده log، قابلیت ارسال log بر روی HTTP را دارد یا خیر. پس از اطمینان از وجود این قابلیت، از این ویژگی Splunk استفاده کرده و این data input را پیکربندی می‌کنید. در نهایت، یک token به شما داده می‌شود. آن token را در اختیار نرم‌افزار مربوطه قرار داده، آدرس‌ها را set می‌کنید و زمانی که آن ابزار log خود را ارسال کند، شما به راحتی می‌توانید آن log را دریافت کنید. نکته بسیار مهمی که در خصوص data input HTTP وجود دارد، این است که اکثر ابزارهایی که از این نوع ارسال log استفاده می‌کنند، log ها را با فرمت JSON ارسال می‌نمایند. فرمت JSON یک فرمت ساختاریافته و منظم است که Splunk به راحتی می‌تواند log های با فرمت JSON را parse کرده و field ها را extract نماید. کیفیت ظاهری این نوع log ها بسیار بالا است.

TCP / UDP Data Input

نوع بعدی data input موجود در Splunk، TCP و UDP است. این نوع data input معمولاً network data نامیده می‌شود. برخی تجهیزات می‌توانند با استفاده از پروتکل Syslog، data ی خود را به سمت یک IP:Port مشخص بر روی پروتکل TCP یا UDP ارسال کنند. به احتمال زیاد، در این ابزارها و تجهیزات، قابلیت انتخاب port نیز وجود دارد. از آنجایی که Syslog به صورت پیش‌فرض بر روی پورت UDP 514 کار می‌کند، در برخی تجهیزات این امکان نیز وجود دارد که پروتکل را به TCP تغییر داده و همچنین port numberی که می‌خواهید log بر روی آن ارسال شود را نیز تغییر دهید. بنابراین، زمانی که قصد پیکربندی TCP و UDP را دارید، می‌توانید در اینجا port و IP را نیز مشخص کنید. این data input از نوع TCP یا UDP که در Splunk پیکربندی می‌شود، منتظر دریافت log از آن IP address source بر روی portی است که در source پیکربندی شده است. در ویدئوهای آینده، توضیحات بیشتری در این خصوص ارائه خواهد شد.

Script Data Input

Data input بعدی از نوع Script است. به وسیله این گزینه می‌توانید script های مد نظر خود را به صورت زمان‌بندی شده اجرا کرده و خروجی آن را به Splunk Enterprise ارسال کنید. اگر TA مرتبط با Windows را از Splunkbase دانلود کرده و به directory پیش‌فرض آن مراجعه کنید و در آن directory وارد فایل input شوید، می‌توانید stanza های مرتبط با اجرای برخی script ها را مشاهده نمایید. این یک نمونه بسیار خوب برای کسب اطلاعات بیشتر در این زمینه است. حتماً این مورد را به عنوان تمرین کلاسی انجام دهید. Script هایی که داخل آن TA قرار دارند، باعث اجرای یک task خاص می‌شوند و سپس خروجی آن task به صورت یک log file ذخیره شده و محتوای آن log file به Splunk Enterprise ارسال می‌گردد.

تا این بخش از ویدئو، در خصوص برخی از data input ها صحبت کردیم. همانطور که در تصویر نیز مشاهده می‌شود، data input های متفاوت دیگری نیز در اینجا وجود دارند.

بخشی با عنوان Forwarder Inputs وجود دارد. زمانی که از Splunk Enterprise در نقش Deployment Server استفاده می‌شود، می‌توان از این بخش به منظور ایجاد مجموعه‌ای از پیکربندی‌ها به وسیله Web UI و push کردن آن‌ها بر روی Universal Forwarder ها استفاده نمود تا پیکربندی ایجاد شده بر روی Universal Forwarder ها اعمال گردد و data ی مورد نظری که برای آن پیکربندی صورت گرفته، به Splunk Enterprise ارسال شود.

به طور کلی، از چند طریق می‌توان data input ها را ایجاد کرد:

• استفاده از Web UI: همانطور که پیش‌تر بررسی شد.
• استفاده از CLI و command های مرتبط: این روش نیز امکان‌پذیر است.
• ایجاد یا ویرایش مستقیم فایل conf: می‌توان مستقیماً فایل inputs.conf را ایجاد یا فایل‌های موجود را ویرایش نمود.
• نصب app ها و add-on ها: همانطور که در همین ویدئو اشاره شد، می‌توان app ها و add-on هایی را از Splunkbase دانلود و بر روی Splunk نصب کرد. این app یا add-on ها معمولاً حاوی یک فایل conf هستند که پیکربندی‌های داخل آن بر روی Splunk Enterprise اجرا شده و باعث دریافت data ی مرتبط در صورت ارسال می‌شوند. می‌توان فایل‌های inputs.conf موجود در این app ها و add-on ها را نیز با روش استاندارد (ویرایش در directory local) ویرایش کرده و پس از restart کردن Splunk، تغییرات مورد نظر را در inputs.conf اعمال نمود.

در همین ویدئو و ویدئوهای آینده، بیشتر به موضوع input پرداخته و input های متفاوت را پیکربندی خواهیم کرد.

همانطور که در ویدئوی قبلی در خصوص default field ها صحبت شد، در اینجا نیز باید به این موضوع اشاره شود. زمانی که Splunk، data source ها را index می‌کند، metadata value ها نیز به آن‌ها اختصاص داده می‌شوند. چند نکته در این زمینه وجود دارد:

metadata ها به کل آن source اعمال و اختصاص داده می‌شوند. اگر در پیکربندی خود (در فایل inputs.conf)، به metadata هایی که در تصویر مشاهده می‌کنید، value اختصاص داده باشید، همان value به data source شما اختصاص می‌یابد. اگر هیچ valueی به این metadata ها یا attribute ها set نکرده باشید، مقادیر پیش‌فرضی وجود دارند که assign خواهند شد. در نتیجه، می‌توان value های مرتبط با این metadata ها را در زمان input، override کرد و حتی در فازهای دیگر نیز این metadata ها را override نمود.

انواع metadata ها

در تصویر، چهار مورد از مهم‌ترین metadata ها نمایش داده شده است:

• source: مقداری که به صورت پیش‌فرض برای این metadata set می‌شود، به نوع data inputی که برای آن source data ایجاد شده، بستگی دارد. به عنوان مثال، اگر در حال خواندن یک log file باشید، مسیر آن log file در source نمایش داده می‌شود.
• host: معمولاً value پیش‌فرضی که برای این metadata set می‌شود، مرتبط با hostname یا IP data source اصلی شماست.
• sourcetype: در ادامه همین ویدئو، به تفصیل در مورد آن صحبت خواهیم کرد. اما نکته‌ای که در اینجا وجود دارد این است که اگر شما این پارامتر را set نکرده باشید و Splunk نیز نتواند به صورت خودکار مقدار آن را مشخص کند، filename مرتبط با آن source log را در این field قرار می‌دهد.
• index: به صورت پیش‌فرض، اگر مقداری set نشود، index main برای آن در نظر گرفته می‌شود.

بنابراین، در این بخش چهار مورد از مهم‌ترین metadata ها بررسی شدند و مقادیر پیش‌فرض آن‌ها نیز ذکر گردید. در ادامه، توضیحات بیشتری در خصوص sourcetype ارائه شده و این موارد در پیکربندی inputs.conf بررسی خواهند شد.

نکته دیگری که در خصوص این اسلاید می‌توان مطرح کرد، بر اساس توضیحات ویدئوی قبلی، این است که در stage های parsing و indexing، مجموعه‌ای از metadata به data ی اصلی ما اضافه می‌شد. منظور از metadata، data ها و field هایی است که توسط خود Splunk به data ی شما افزوده می‌شوند. اگر به خاطر داشته باشید، در ویدئوی قبلی، تصویری نمایش داده شد که انواع field هایی که به عنوان metadata به data ی اصلی اضافه می‌شوند را نشان می‌داد و در مورد آن صحبت شد. پس خواهشمند است این موارد را که به صورت زنجیروار به یکدیگر متصل هستند، به طور کامل درک کنید. اگر قسمتی از یک ویدئو را متوجه نشوید یا دقت کافی نداشته باشید، احتمالاً در ویدئوهای بعدی سوالات زیادی برای شما پیش خواهد آمد که دلیل اصلی عدم درک مطلب، به بخش‌هایی باز می‌گردد که به آن‌ها توجه نکرده‌اید یا در آن مباحث ضعف دارید.

فازهای input و parsing

در این قسمت از ویدئو، قصد داریم توضیحات بیشتری در خصوص فازهای input و parsing ارائه دهیم. اما قبل از ورود به توضیحات، لازم است تا این بخش از ویدئو، بر روی stage input تسلط کامل پیدا کرده و مفاهیم آن را درک کرده باشید. همچنین، باید با مباحث مرتبط با اولویت‌بندی configuration file ها و خود configuration file ها (مانند inputs.conf, props.conf, transforms.conf, indexes.conf) و کاربرد هر یک، آشنایی کامل داشته باشید.

همانطور که در تصویر نمایش داده شده، در stage input، چندین configuration file دخیل هستند. configuration file اصلی، inputs.conf است که پیکربندی‌های مرتبط با باز کردن port و ایجاد data input را انجام می‌دهد. به صورت مستقیم در این configuration file می‌توان metadata ها را برای هر data sourceی که اضافه می‌شود، set کرد.

پس از آن، configuration file props.conf وجود دارد که در این فاز، برخی از configuration های موجود در این file برای stage input و برخی دیگر برای stage های بعدی کاربرد دارند. Configuration file هایی مانند character set و prefix sourcetype، مواردی هستند که در stage input پردازش شده و مورد استفاده قرار می‌گیرند.

در stage parsing نیز configuration file props.conf کاربرد بسیار مهمی دارد. می‌توان گفت اصلی‌ترین configuration file مرتبط با stage parsing، props.conf است. پس از آن، configuration file transforms.conf قرار دارد که نقش مهمی در این stage ایفا می‌کند.

به عنوان مثال، فرض کنید می‌خواهید timezone مرتبط با log های یک data source خاص را تغییر دهید. باید پیکربندی مرتبط با این مورد را در فایل props.conf set کنید. به عنوان مثال دیگر ممکن است نیاز داشته باشید پس از دریافت یک log، آن را تغییر داده و به یک معماری یا تجهیز دیگر ارسال کنید. در این مورد نیز باید از فایل‌های props.conf و transforms.conf استفاده نمایید.

به صورت کلی، زمانی که در stage input هستید و با configuration های مرتبط با آن کار می‌کنید، انعطاف‌پذیری بسیار پایین است، اما config هایی که در این فاز اعمال می‌شوند، کارآمدتر هستند یا کارایی بالاتری دارند. به عنوان مثال، اگر بخواهیم sourcetype یک log را تغییر دهیم، هم می‌توانیم این کار را در فاز input انجام دهیم و هم به نحوی در فاز parsing. اما زمانی که این کار در فاز input انجام می‌شود، کارایی آن بیشتر بوده و performance بهتری دارد.

در فاز یا stage input، data source دریافت می‌شود، اما در stage یا فاز parsing، آن data به event تبدیل شده و timestamp مورد نظر نیز به آن assign می‌گردد.

مورد بعدی که بسیار حائز اهمیت است، این است که در فاز input می‌توان مقدار اولیه field های metadata را set کرد. می‌توان source, sourcetype, host, index را set نمود. کافی است در stanza ی مرتبط با آن source، از attribute های source, sourcetype, host و index استفاده کرده و value مورد نظر را برای آن قرار داد. در همین ویدئو، این مورد به صورت عملی نمایش داده خواهد شد.

در stage parsing، می‌توان event-level transformation داشت. می‌توان مجموعه‌ای از field ها را اضافه یا کم کرد، log را route نمود و یا حتی بخشی از log را filter کرد. همانطور که پیش‌تر گفته شد، در فاز یا stage parsing می‌توان تنظیمات مرتبط با metadata را که از فاز input آمده‌اند، fine-tune کرد. البته کارایی این روش کمتر است، اما در اینجا control بیشتری وجود دارد.

زمانی که در فاز input، attributeی برای یک source تغییر داده می‌شود، در واقع آن تغییر برای کل آن source اعمال می‌گردد. نمی‌توان یک log مشخص از آن source را انتخاب کرده و تغییرات را فقط برای آن اعمال نمود. اما در فاز parsing چنین قابلیتی وجود دارد و می‌توان بخشی از data ی یک data source دریافتی را انتخاب کرده و عملیات خاصی بر روی آن انجام داد (مثلاً بخشی از log را filter کرد).

همانطور که در ابتدا ذکر شد، اصلی‌ترین فایل پیکربندی فاز input، inputs.conf و اصلی‌ترین فایل پیکربندی فاز parsing، props.conf است. البته در props.conf، مجموعه‌ای از attribute ها وجود دارند که به فاز input مرتبط هستند، اما بیشتر attribute های configuration file props.conf به فاز parsing مربوط می‌شوند.

فیلد sourcetype

در این ویدئو در خصوص sourcetype گفته شد که یکی از مهم‌ترین metadata های Splunk، فیلد sourcetype است. اما این فیلد دقیقاً چیست؟

فیلد sourcetype یک فیلد پیش‌فرض است که data structure event شما را مشخص می‌کند (تعریف event و زمان تبدیل data به event را به خاطر داشته باشید). تقریباً می‌توان گفت این فیلد به Splunk می‌گوید که چگونه این data را قالب‌بندی کند، به‌خصوص در زمان فرآیند indexing. از طرف دیگر، می‌توان آن را روشی برای دسته‌بندی و categorize کردن data type های مختلف در نظر گرفت.

فیلد sourcetype فیلدی است که بیشتر در فاز indexing مورد استفاده قرار می‌گیرد و استفاده از آن در ابتدای search های کاربر، باعث بهبود performance search می‌شود.

اما نکته بسیار مهم این است که چگونه sourcetype را اختصاص دهیم و از چه sourcetypeی استفاده کنیم؟

لیستی از sourcetype ها وجود دارد که Splunk به صورت پیش‌فرض آن‌ها را شناسایی کرده، sourcetype مربوطه را set نموده و مورد استفاده قرار می‌دهد. همچنین، زمانی که app هایی نصب می‌شوند که حاوی input و props هستند، به احتمال زیاد در آن input، فیلد sourcetype به صورت استاندارد تعریف شده است.

اما اگر inputی را خودتان ایجاد کرده‌اید و نمی‌دانید از چه sourcetypeی استفاده کنید، ابتدا باید بررسی کنید که آیا TA و appی برای آن data وجود دارد که data را بر اساس CIM، extract و normalize کند یا خیر. اگر چنین app و TAی وجود داشت، باید دستورالعمل آن را مطالعه کرده و ببینید دقیقاً چه sourcetypeی را پیشنهاد می‌دهد. برای اطمینان از matching صحیح بین data ی ورودی شما و stanza های موجود در props و transform آن TA، حتماً باید از همان sourcetypeی استفاده کنید که خود آن app و TA پیشنهاد داده و در configuration file های خود استفاده کرده است.

به عنوان مثال، اگر data ی FortiGate را دریافت می‌کنید و inputی برای آن باز کرده‌اید، از آنجایی که این data دارای TA و app مخصوص به خود است، TA آن را دانلود کرده و دستورالعملش را مطالعه کنید. اگر در خصوص sourcetype چیزی ذکر نشده بود، باید configuration file هایی مانند props.conf موجود در آن TA را با دقت بررسی کنید، ببینید از چه stanza هایی استفاده کرده و چه sourcetypeی نیاز است تا data ی شما با آن stanza match شود. سپس همان sourcetype را در input مرتبط با FortiGate استفاده نمایید. حتماً این تمرین را انجام دهید تا با روند کار آشنا شوید.

این توضیحات مربوط به تعریف sourcetype بود. همانطور که مشاهده شد، تعریف آن پیچیده نیست و با مسئله دشواری روبرو نیستیم. در قسمت بعدی این ویدئو، به موارد عملی پرداخته و نحوه پیکربندی یک input را با هم بررسی خواهیم کرد.

نحوه پیکربندی یک input

در قسمت عملی، قصد داریم دو نوع input ایجاد کنیم. همانطور که توضیح داده شد، می‌توان از قسمت Setting، گزینه Data Input را انتخاب کرده و سپس با توجه به نوع input مورد نظر، پیکربندی را انجام داد.

اما در صفحه home Splunk، قسمتی با عنوان Add Data وجود دارد. با کلیک بر روی این گزینه، صفحه‌ای باز می‌شود که سه گزینه اصلی در آن وجود دارد:

• Upload: می‌توان فایل‌هایی که دارای structure هستند را در اینجا upload کرد تا data ی داخل آن‌ها به راحتی در یک index ذخیره شود. توجه داشته باشید که در زمان استفاده از قسمت upload، هیچ inputی پیکربندی نمی‌شود و صرفاً محتوای فایل شما index می‌گردد. این گزینه بیشتر برای موارد تستی یا use case های خاص کاربرد دارد (مثلاً دریافت log از سیستمی که پیش‌تر log آن جمع‌آوری نمی‌شده است).
• Monitor: با کلیک بر روی این گزینه، می‌توان پیکربندی‌های مرتبط با مانیتورینگ file ها، directory ها و همچنین network port ها را انجام داد. تقریباً می‌توان گفت آیتم‌ها و data input هایی که در بخش Data Inputs وجود دارند، در این قسمت نیز با ظاهری شکیل‌تر و مرحله‌بندی شده، در دسترس هستند.
• Forward: این گزینه زمانی کاربرد دارد که Splunk Enterprise شما در نقش Deployment Server عمل کند و بخواهید پیکربندی‌هایی را به سمت Universal Forwarder ها ارسال نمایید.

اولین inputی که ایجاد خواهیم کرد، مرتبط با مانیتور کردن یکی از log file های Linux server است. این Splunk Enterprise بر روی یک Linux نصب شده است. زمانی که Splunk بر روی Linux نصب می‌شود، به صورت پیش‌فرض log های سیستم‌عامل خوانده نمی‌شوند. اگر بخواهید log های داخلی آن سیستم‌عامل را به وسیله Splunk Enterprise monitor کنید، باید پیکربندی‌های لازم را انجام دهید. توجه داشته باشید که این روش پیکربندی در سطح Web UI است و می‌توان از روش‌های دیگری نیز استفاده نمود.

برای ایجاد اولین input، از قسمت Setting وارد Data Input شده و بر روی گزینه File & Directory کلیک می‌کنیم. در این قسمت، تمام input های مرتبط با File & Directory نمایش داده می‌شوند. همانطور که در تصویر مشاهده می‌شود، برخی موارد به صورت پیش‌فرض وجود دارند. اگر TA، add-on یا app های Splunk را نصب کنید، به احتمال زیاد input های بیشتری نیز در اینجا نمایش داده خواهند شد که مرتبط با آن TA هستند. به عنوان مثال، همانطور که در پایین صفحه قابل مشاهده است، TA Linux نصب شده است (ابتدا از Splunkbase دانلود و سپس بر روی Splunk نصب گردیده) که باعث اضافه شدن این input ها شده است. اما به صورت پیش‌فرض، این input ها disable هستند. برای استفاده از آن‌ها، باید آن‌ها را enable کرده و پیکربندی‌های لازم را انجام داد (در آینده به این موارد خواهیم پرداخت).

اکنون قصد داریم یک مانیتور جدید تعریف کنیم. بر روی دکمه New Local File کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، ابتدا باید file یا directory مورد نظر را انتخاب کنیم. Log file مورد نظر در دایرکتوری /var/log لینوکس قرار دارد. فایل را انتخاب کرده و بر روی گزینه Next کلیک می‌کنیم.

سپس باید sourcetype مرتبط با log را انتخاب نماییم. در قسمت sourcetype، انواع مختلفی وجود دارد و مجدداً، اگر TAی نصب شده باشد که sourcetypeی در آن تعریف شده باشد، می‌توان آن را در اینجا انتخاب کرد. از قسمت Operation System، linux_secure را انتخاب می‌کنیم که sourcetype مورد نظر برای parsing این log است.

سپس بر روی گزینه Next کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، در قسمت App Context باید appی را که می‌خواهیم این پیکربندی input در آن ذخیره شود، معرفی کنیم. در اینجا به دلیل انتخاب sourcetype مرتبط با TA Linux، به صورت پیش‌فرض App Context همان app و add-on Linux قرار داده شده است. می‌توان آن را به راحتی تغییر داده و بر روی Search & Reporting تنظیم کرد.

پس از آن، باید host را پیکربندی کنیم که به صورت پیش‌فرض hostname Linux در نظر گرفته شده است. مهم‌تر از همه، باید index مرتبط را انتخاب کنیم. پیش‌تر یک index با نام linux ایجاد شده است که آن را انتخاب می‌کنیم.

در آخر بر روی گزینه Review کلیک کرده، review نمایش داده شده را بررسی و بر روی گزینه Submit کلیک می‌کنیم.

در این مرحله، input ایجاد شده است. می‌توان از گزینه Start Searching استفاده کرد تا به app search منتقل شده و log نمایش داده شود.

اما قصد داریم یک log file دیگر را نیز بخوانیم. بر روی Add More Data کلیک کرده، سپس Monitor را انتخاب می‌کنیم. در صفحه‌ای که نمایش داده می‌شود، بر روی قسمت File & Directory کلیک کرده و مجدداً فایل مورد نظر را انتخاب می‌کنیم.

بر روی گزینه Next کلیک می‌کنیم. Sourcetype به صورت پیش‌فرض توسط Splunk تشخیص داده می‌شود، اما می‌توان آن را تغییر داده و sourcetype مورد نظر را قرار داد.

سپس بر روی گزینه Next کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، App Context و Index را تغییر می‌دهیم.

بر روی گزینه Review و در نهایت Submit کلیک می‌کنیم. می‌توان با استفاده از Start Searching به app search رفته و نتیجه را مشاهده نمود.

در اینجا search را اندکی تغییر می‌دهیم تا تمام sourcetype های موجود در این index قابل مشاهده باشند و سپس بر روی دکمه search کلیک می‌کنیم.

همانطور که در تصویر مشاهده می‌شود، اکنون دو sourcetype syslog و linux_secure وجود دارند و Splunk، log های مرتبط با دو فایل syslog و authentication را می‌خواند. اگر log جدیدی ثبت شود، آن را index خواهد کرد. همانطور که در تصویر قابل مشاهده است، log ها تقریباً parse شده، tag می‌خورند و مشکلی وجود ندارد. این به دلیل نصب قبلی TA Linux و استفاده از sourcetype های از پیش تعریف شده است. در داخل TA Linux، regex هایی وجود دارند که log ها را parse کرده و نمایش می‌دهند.

نکاتی در زمان ایجاد input وجود داشت:

• نکته اول: زمانی که در اینجا directory معرفی می‌شود، می‌توان include list یا exclude list داشت. در این دو قسمت، regex مورد نظر وارد می‌شود تا موارد دلخواه include یا exclude شوند (در آینده مثال‌هایی ارائه خواهد شد).
• نکته دیگر: اگر از Browse استفاده نشود و مسیر به صورت دستی وارد گردد، باید دقت شود که فایل مورد نظر بر روی سیستم‌عامل Windows است یا Linux. چون آدرس‌دهی در این دو سیستم‌عامل متفاوت است، باید نحوه آدرس‌دهی را متناسب با آن تغییر داد (مثالی در خود رابط کاربری نمایش داده شده است).

در صفحه بعد، در قسمت host سه گزینه وجود داشت:

• گزینه اول: می‌توان host value را به صورت مستقیم (یک کلمه) وارد کرد.
• گزینه دوم: می‌توان از regular expression استفاده کرد تا host از فیلد source استخراج شود (نیازمند آشنایی با محتوای فیلد source و نوشتن regex مناسب است) یعنی باید به Value ای که داخل Source قرار می گیرد دقت کنید. قبلا گفته بودیم که چه چیزی در متادیتای source به صورت پیش فرض قرار می گیرد. باتوجه به آن باید regex ای بنویسید تا host مدنظرتان را از source استخراج کنید. این در صورتی است که بخواهید host name را از فیلد Source استخراج کنید و اگر hostname را می دانید که از گزینه اول استفاده می کنید.
• گزینه سوم: این گزینه نیز امکان استخراج host value از فیلد source را فراهم می‌کند، اما با روش segment بندی بر اساس اسلش (/). یعنی هر slash که در فیلد source وجود دارد یک segment درنظر گرفته می شود و با شمارش segment ها و وارد کردن عدد آن می توان host value را استخراج کرد. به عنوان مثال در این مسیری که مشاهده می کنید، سگمنت اول، دوم و سوم را می بینید و می‌توان شماره segment مورد نظر برای قرار گرفتن در فایل host را وارد کرد.

نکته‌ای که وجود دارد این است که کمتر پیش می‌آید پیکربندی input ها از طریق Web UI انجام شود، به‌خصوص روی Splunk Enterprise. معمولاً admin ها بیشتر با پیکربندی input روی Universal Forwarder ها سروکار دارند.

به خاطر داشته باشید که پیکربندی انجام شده در Web UI، به صورت text در فایل پیکربندی مرتبط (در app مشخص شده توسط App Context) ذخیره می‌شود. اکنون اگر به app Search & Reporting مراجعه کرده و فایل inputs.conf آن را در directory local بررسی کنیم، پیکربندی‌های انجام شده قابل مشاهده خواهند بود.

همانطور که مشاهده می‌شود، ابتدا یک stanza برای input network تعریف شده (که بعداً بررسی می‌شود) و پس از آن، دو stanzaی monitor وجود دارد که دقیقاً همان مواردی هستند که پیش‌تر تعریف کردیم.

بنابراین، برای مانیتور کردن یک فایل یا directory، باید از کلمه کلیدی monitor استفاده کرده، سپس دو نقطه (:) قرار داده و مسیر مورد نظر را (با توجه به سیستم‌عامل) وارد نماییم.

پس از آن، attribute هایی مانند disabled (که اگر true باشد، stanza غیرفعال می‌شود)، host (یا metadataی host) و index وجود دارند. می‌توان این موارد را به صورت مستقیم در اینجا تغییر داده و پس از restart، تغییرات را اعمال نمود. همچنین attribute sourcetype نیز قابل تغییر است.

Stanza ی بعدی نیز به همین صورت است.

اگر بخواهیم whitelist یا blacklist اضافه کنیم، می‌توانیم از attribute های whitelist و blacklist استفاده نماییم. همانطور که در تصویر مشاهده می‌شود، مثالی از TA Linux آورده شده که در آن whitelist و blacklist به صورت regex تعریف شده‌اند. نکته مهم این است که این whitelist/blacklist بر روی فایل اعمال نمی‌شود، بلکه بر روی directory کاربرد دارد. اگر مسیر فایل حذف شده و directory مانیتور شود، آنگاه این whitelist و blacklist منطقی شده و بر روی آن directory اعمال می‌گردند. در این حالت، هر log file یا directory دیگری داخل آن directory که با whitelist مطابقت داشته باشد، مانیتور شده و log آن ارسال می‌شود.

نکته بسیار مهم: می‌توان از همین نوع پیکربندی در Universal Forwarder نیز استفاده کرده و این موارد را اعمال نمود تا log های مورد نظر به وسیله Universal Forwarder به Splunk Enterprise ارسال شوند.

نکته تکراری دیگر: در حال حاضر، این input ها بر روی Splunk Enterprise پیکربندی می‌شوند و log ها نیز بر روی همین Splunk Enterprise index می‌گردند. اگر قرار بود این Splunk Enterprise، log را به جای دیگری ارسال کند، حتماً باید فایل outputs.conf پیکربندی شود (که در ویدئوهای آینده بررسی خواهد شد) تا امکان ارسال log به Splunk دیگر فراهم گردد.

سناریوی بعدی، دریافت log به وسیله یکی از network port ها است. فرض کنید تجهیزی وجود دارد که log های خود را به سمت Splunk Enterprise بر روی پورت 514 UDP ارسال می‌کند.

ابتدا برای اطمینان از رسیدن log های مورد نظر از source مشخص به Splunk Enterprise، حتماً از ابزار tcpdump استفاده کنید. می‌توان دستور tcpdump را بر روی Linux مورد نظر اجرا کرده و حتی شماره port و نام host مبدا را نیز در دستور وارد نمود تا در صورت دریافت log از آن source، log در خروجی نمایش داده شود و از رسیدن log به Splunk Enterprise اطمینان حاصل گردد. در محیط‌های واقعی، کار با tcpdump بسیار رایج است، پس حتماً در خصوص این دستور مطالعه کرده و بر آن مسلط شوید. زیرا معمولاً قبل از انجام پیکربندی توسط Splunk admin، نیاز به verify دریافت log از سمت admin های دیگر وجود دارد.

پس از اطمینان از دریافت log با این دستور، برای انجام پیکربندی، از قسمت Data Inputs بر روی گزینه UDP کلیک می‌کنیم. همانطور که مشاهده می‌شود، هیچ portی برای UDP از پیش باز نشده است.

بر روی New Local UDP کلیک می‌کنیم. در فرمی که باز می‌شود، ابتدا می‌توان نوع پروتکل (TCP یا UDP) را انتخاب کرد و سپس port مورد نظر را وارد نمود. در قسمت بعدی، می‌توان source را override کرد.

قسمت بعدی که بسیار مهم است، امکان ایجاد محدودیت بر اساس source ارسال‌کننده است. این محدودیت باعث می شود شما فقط از همان یک source روی این پورت log دریافت کنید. می‌توان در این فیلد، آدرس IP یا DNS name ارسال‌کننده log را وارد کرد تا این port باز شده بر روی Splunk Enterprise، فقط از همان source خاص log دریافت کند و log های ارسالی از source های دیگر را نادیده بگیرد.

پس از انجام تنظیمات، بر روی گزینه Next کلیک می‌کنیم. در اینجا می‌توان ابتدا sourcetype را مشخص کرد (می‌توان از لیست جستجو و انتخاب نمود) و سپس App Context، host (بر اساس IP, DNS یا custom) و در نهایت index را تنظیم نمود.

سپس بر روی Review و در نهایت Submit کلیک می‌کنیم. پس از ایجاد موفقیت‌آمیز پیکربندی، می‌توان از گزینه Start Searching استفاده کرده و به منوی search رفت تا log های دریافتی را مشاهده نمود.

همانطور که در تصویر مشاهده می‌شود، log های مورد نظر که ارسال شده بودند، در اینجا دریافت شده‌اند (محتوای log در این سناریوی تستی اهمیتی ندارد).

پس از اطمینان از index شدن log، به فایل inputs مراجعه می‌کنیم تا ببینیم چه نوع stanzaی در آنجا اضافه شده است.

همانطور که در تصویر مشاهده می‌شود، stanza ی UDP اضافه شده است (اگر TCP انتخاب می‌شد، stanza ی TCP ایجاد می‌گردید). پس از آن، آدرس IP ارسال‌کننده و portی که log بر روی آن ارسال می‌شود، مشخص شده‌اند و در نهایت، attribute های مرتبط با ذخیره‌سازی آن log (مانند index, sourcetype, host, connection_host) قرار دارند.

به عنوان جمع‌بندی، اگر نخواهید از طریق Web UI این پیکربندی‌ها را انجام دهید، می‌توانید به صورت دستی همین پیکربندی‌ها را در فایل inputs.conf وارد کرده و از آن‌ها استفاده کنید و در صورت نیاز، مقادیر sourcetype، نام index و سایر موارد را تغییر دهید.

با ماژول دوم از دوره Splunk Enterprise Data Admin در خدمت شما هستیم. در این ماژول به بررسی مواردی نظیر انواع data input ها و همچنین تنظیمات مرتبط با default metadata ها خواهیم پرداخت. همچنین، تفاوت بین فازهای input و parsing مشخص خواهد شد و در انتهای همین ویدئو، با استفاده از Splunk Web، مجموعه‌ای از input ها ایجاد شده و نتیجه آن به صورت عملی نمایش داده می‌شود.

مفهوم Data

پیش‌تر در ویدئوهای ابتدایی دوره Fund 1 و Fund 2 در خصوص data صحبت شد و ضروری است با مفهوم data آشنا شویم. در صورت رجوع به واژه‌نامه‌هایی مانند Oxford، مشاهده می‌شود که معمولاً لغت‌نامه‌ها، data را بدین صورت تعریف نموده‌اند که تمام حقایق یا factها و آمارهایی که برای تجزیه‌وتحلیل و reference جمع‌آوری می‌شوند، data نامیده می‌شوند. به نظر می‌رسد این تعریف، مناسبی باشد و با اندکی تامل بر روی آن، کاملاً قابل‌درک و استفاده است.

اما در حوزه Splunk چه انواعی از data وجود دارد؟ معمولاً data هایی که جمع‌آوری می‌شوند از نوع text خواهند بود و مواردی مانند log ها، configuration ها، message ها و alert هایی که تجهیزات امنیتی fire می‌کنند و همچنین metric هایی که در برخی از system ها وجود دارد را می‌توان data نامید. این نوع data از نوع text بوده و به نحوی قابل ارسال به Splunk Enterprise است. باید به این نکته توجه نمود که مواردی همچون script ها نیز وجود دارند که پس از اجرای این نوع script ها، معمولاً مجموعه‌ای از data های text به صورت file ذخیره می‌شوند و این موارد نیز به نحوی قابل ارسال هستند. نوع دیگری از data های بسیار مهم که در مراکز SOC وجود دارد، ticket ها هستند. هنگامی که یک SOC از یک سیستم ticketing استفاده می‌کند، می‌تواند پیکربندی‌هایی را انجام دهد که به محض ثبت یک ticket، مجموعه‌ای از data به سمت Splunk Enterprise ارسال شود و ماژول‌های مرتبط با آن، مانند Splunk Enterprise Security، بتوانند از آن data ی ticketing استفاده کنند.

تمام data ها دارای یک source هستند. در حوزه IT، تمام سیستم‌عامل‌ها، computer ها، تجهیزات network، virtual machine ها، تجهیزات ارتباطی، sensor ها، database ها و حتی تجهیزات IoT، یک source data محسوب می‌شوند و تمام این موارد، data های مختلف با format های گوناگون تولید می‌کنند. شما باید بر اساس strategy های مختلف، این data ها را با روش‌های گوناگونی که وجود دارد و compatible هستند، جمع‌آوری کنید. در زمان مشاهده این ویدئو، اگر سابقه کاری زیادی در این حوزه ندارید، خواهشمند است به توضیحات ارائه شده دقت فرمایید، موارد ذکر شده را یادداشت نموده و بر روی آن‌ها تامل کنید تا مطالب به خوبی در ذهن شما تثبیت شوند.

بنابراین، برای نتیجه‌گیری از این slide، ما با مجموعه‌ای از data های text مواجه هستیم که این data ها هر کدام از یک source نشات می‌گیرند. وظیفه ما این است که به نحوی این data ها را جمع‌آوری کرده و به سمت Splunk Enterprise ارسال کنیم. قطعاً باید در سمت Splunk Enterprise، input های مناسبی ایجاد کنیم تا بتوانیم این data ها را دریافت نماییم.

انواع Data Input در Splunk

اگر بخواهیم انواع type های data input موجود در Splunk Enterprise را بررسی کنیم، می‌توان از منوی Settings وارد قسمت Data Inputs شد. پس از کلیک بر روی این گزینه، وارد صفحه Data Inputs خواهید شد. در این صفحه، تمام type input هایی که Splunk Enterprise به صورت پیش‌فرض پشتیبانی می‌کند، به راحتی قابل مشاهده است.

نکته اول: زمانی که از برخی app های Splunk استفاده می‌کنید، ممکن است یک type جدید data input به input های Splunk Enterprise شما افزوده شود.

همچنین، این امکان وجود دارد که برخی از app ها و TA ها، input هایی را به Splunk Enterprise شما اضافه کنند. اگر به توضیحات پیشین توجه کرده باشید، مورد اولی که ذکر شد، type جدیدی از data input ها بود که توسط برخی app ها ایجاد می‌شود و جمله دوم، به اضافه شدن input به Splunk Enterprise شما اشاره داشت. به عبارت دیگر، امکان دارد برخی TA ها، به عنوان مثال، input های TCP، UDP یا File & Directory را اضافه کنند، در حالی که برخی app های دیگر، مستقیماً یک type input جدید را در اینجا اضافه می‌کنند.

File & Directory Data Input

به صورت پیش‌فرض، چندین type data input در Splunk وجود دارد. مورد اول File & Directory است. قطعاً log هایی را مشاهده کرده‌اید که در سیستم‌عامل‌ها به صورت file ذخیره می‌شوند. به عنوان مثال، سیستم‌عامل Linux، log های خود را به صورت فایل text ذخیره می‌کند. بنابراین، قطعاً تجهیزات و سیستم‌عامل‌های دیگری نیز وجود دارند که log های خود را به این شکل ذخیره می‌کنند. با استفاده از Splunk Enterprise می‌توان آن file را monitor کرد و به محض اضافه شدن data ی جدید به آن file، Splunk Enterprise آن را خوانده و ارسال می‌کند.

نکته‌ای که در اینجا مطرح می‌شود و احتمالاً به آن فکر کرده‌اید، این است که چرا این موضوع بر روی خود Splunk Enterprise توضیح داده می‌شود و به Universal Forwarder پرداخته نمی‌شود. این نکته را در نظر داشته باشید که Splunk Universal Forwarder نسخه‌ای از Splunk Enterprise با feature های محدود است و کاملاً از قوانینی که در این ویدئوها ذکر می‌شود، پیروی می‌کند. همچنین، با خود Splunk Enterprise نیز می‌توان کارهایی را که Universal Forwarder انجام می‌دهد، اجرا نمود. به عنوان مثال، اگر Splunk Enterprise را بر روی یک server لینوکسی نصب کرده باشید و بخواهید از آن به عنوان Indexer یا Search Head استفاده کنید، می‌توانید data inputی را پیکربندی کنید که log های داخلی همان سیستم‌عاملی که Splunk Enterprise بر روی آن نصب شده است را monitor کرده و بر روی همین Splunk ذخیره نماید. پس خواهشمند است به این نکته توجه کنید و این مسائل را با یکدیگر اشتباه نگیرید.

HTTP Event Collector Data Input

نوع بعدی data input، HTTP Event Collector است. تجهیزات و ابزارهایی وجود دارند که هم log خود را به صورت file ذخیره می‌کنند و هم قابلیتی در آن‌ها توسعه داده شده است که می‌توانند log ها را بر روی پروتکل HTTP یا HTTPS ارسال کنند. در Splunk برای دریافت چنین logی، باید از data input از نوع HTTP Event Collector استفاده کرد. پیکربندی این نوع input بسیار ساده است که در ویدئوهای آینده به آن پرداخته خواهد شد. بنابراین، اگر قصد استفاده از این نوع input را دارید، ابتدا باید بررسی کنید که آیا source ارسال‌کننده log، قابلیت ارسال log بر روی HTTP را دارد یا خیر. پس از اطمینان از وجود این قابلیت، از این ویژگی Splunk استفاده کرده و این data input را پیکربندی می‌کنید. در نهایت، یک token به شما داده می‌شود. آن token را در اختیار نرم‌افزار مربوطه قرار داده، آدرس‌ها را set می‌کنید و زمانی که آن ابزار log خود را ارسال کند، شما به راحتی می‌توانید آن log را دریافت کنید. نکته بسیار مهمی که در خصوص data input HTTP وجود دارد، این است که اکثر ابزارهایی که از این نوع ارسال log استفاده می‌کنند، log ها را با فرمت JSON ارسال می‌نمایند. فرمت JSON یک فرمت ساختاریافته و منظم است که Splunk به راحتی می‌تواند log های با فرمت JSON را parse کرده و field ها را extract نماید. کیفیت ظاهری این نوع log ها بسیار بالا است.

TCP / UDP Data Input

نوع بعدی data input موجود در Splunk، TCP و UDP است. این نوع data input معمولاً network data نامیده می‌شود. برخی تجهیزات می‌توانند با استفاده از پروتکل Syslog، data ی خود را به سمت یک IP:Port مشخص بر روی پروتکل TCP یا UDP ارسال کنند. به احتمال زیاد، در این ابزارها و تجهیزات، قابلیت انتخاب port نیز وجود دارد. از آنجایی که Syslog به صورت پیش‌فرض بر روی پورت UDP 514 کار می‌کند، در برخی تجهیزات این امکان نیز وجود دارد که پروتکل را به TCP تغییر داده و همچنین port numberی که می‌خواهید log بر روی آن ارسال شود را نیز تغییر دهید. بنابراین، زمانی که قصد پیکربندی TCP و UDP را دارید، می‌توانید در اینجا port و IP را نیز مشخص کنید. این data input از نوع TCP یا UDP که در Splunk پیکربندی می‌شود، منتظر دریافت log از آن IP address source بر روی portی است که در source پیکربندی شده است. در ویدئوهای آینده، توضیحات بیشتری در این خصوص ارائه خواهد شد.

Script Data Input

Data input بعدی از نوع Script است. به وسیله این گزینه می‌توانید script های مد نظر خود را به صورت زمان‌بندی شده اجرا کرده و خروجی آن را به Splunk Enterprise ارسال کنید. اگر TA مرتبط با Windows را از Splunkbase دانلود کرده و به directory پیش‌فرض آن مراجعه کنید و در آن directory وارد فایل input شوید، می‌توانید stanza های مرتبط با اجرای برخی script ها را مشاهده نمایید. این یک نمونه بسیار خوب برای کسب اطلاعات بیشتر در این زمینه است. حتماً این مورد را به عنوان تمرین کلاسی انجام دهید. Script هایی که داخل آن TA قرار دارند، باعث اجرای یک task خاص می‌شوند و سپس خروجی آن task به صورت یک log file ذخیره شده و محتوای آن log file به Splunk Enterprise ارسال می‌گردد.

تا این بخش از ویدئو، در خصوص برخی از data input ها صحبت کردیم. همانطور که در تصویر نیز مشاهده می‌شود، data input های متفاوت دیگری نیز در اینجا وجود دارند.

بخشی با عنوان Forwarder Inputs وجود دارد. زمانی که از Splunk Enterprise در نقش Deployment Server استفاده می‌شود، می‌توان از این بخش به منظور ایجاد مجموعه‌ای از پیکربندی‌ها به وسیله Web UI و push کردن آن‌ها بر روی Universal Forwarder ها استفاده نمود تا پیکربندی ایجاد شده بر روی Universal Forwarder ها اعمال گردد و data ی مورد نظری که برای آن پیکربندی صورت گرفته، به Splunk Enterprise ارسال شود.

به طور کلی، از چند طریق می‌توان data input ها را ایجاد کرد:

• استفاده از Web UI: همانطور که پیش‌تر بررسی شد.
• استفاده از CLI و command های مرتبط: این روش نیز امکان‌پذیر است.
• ایجاد یا ویرایش مستقیم فایل conf: می‌توان مستقیماً فایل inputs.conf را ایجاد یا فایل‌های موجود را ویرایش نمود.
• نصب app ها و add-on ها: همانطور که در همین ویدئو اشاره شد، می‌توان app ها و add-on هایی را از Splunkbase دانلود و بر روی Splunk نصب کرد. این app یا add-on ها معمولاً حاوی یک فایل conf هستند که پیکربندی‌های داخل آن بر روی Splunk Enterprise اجرا شده و باعث دریافت data ی مرتبط در صورت ارسال می‌شوند. می‌توان فایل‌های inputs.conf موجود در این app ها و add-on ها را نیز با روش استاندارد (ویرایش در directory local) ویرایش کرده و پس از restart کردن Splunk، تغییرات مورد نظر را در inputs.conf اعمال نمود.

در همین ویدئو و ویدئوهای آینده، بیشتر به موضوع input پرداخته و input های متفاوت را پیکربندی خواهیم کرد.

همانطور که در ویدئوی قبلی در خصوص default field ها صحبت شد، در اینجا نیز باید به این موضوع اشاره شود. زمانی که Splunk، data source ها را index می‌کند، metadata value ها نیز به آن‌ها اختصاص داده می‌شوند. چند نکته در این زمینه وجود دارد:

metadata ها به کل آن source اعمال و اختصاص داده می‌شوند. اگر در پیکربندی خود (در فایل inputs.conf)، به metadata هایی که در تصویر مشاهده می‌کنید، value اختصاص داده باشید، همان value به data source شما اختصاص می‌یابد. اگر هیچ valueی به این metadata ها یا attribute ها set نکرده باشید، مقادیر پیش‌فرضی وجود دارند که assign خواهند شد. در نتیجه، می‌توان value های مرتبط با این metadata ها را در زمان input، override کرد و حتی در فازهای دیگر نیز این metadata ها را override نمود.

انواع metadata ها

در تصویر، چهار مورد از مهم‌ترین metadata ها نمایش داده شده است:

• source: مقداری که به صورت پیش‌فرض برای این metadata set می‌شود، به نوع data inputی که برای آن source data ایجاد شده، بستگی دارد. به عنوان مثال، اگر در حال خواندن یک log file باشید، مسیر آن log file در source نمایش داده می‌شود.
• host: معمولاً value پیش‌فرضی که برای این metadata set می‌شود، مرتبط با hostname یا IP data source اصلی شماست.
• sourcetype: در ادامه همین ویدئو، به تفصیل در مورد آن صحبت خواهیم کرد. اما نکته‌ای که در اینجا وجود دارد این است که اگر شما این پارامتر را set نکرده باشید و Splunk نیز نتواند به صورت خودکار مقدار آن را مشخص کند، filename مرتبط با آن source log را در این field قرار می‌دهد.
• index: به صورت پیش‌فرض، اگر مقداری set نشود، index main برای آن در نظر گرفته می‌شود.

بنابراین، در این بخش چهار مورد از مهم‌ترین metadata ها بررسی شدند و مقادیر پیش‌فرض آن‌ها نیز ذکر گردید. در ادامه، توضیحات بیشتری در خصوص sourcetype ارائه شده و این موارد در پیکربندی inputs.conf بررسی خواهند شد.

نکته دیگری که در خصوص این اسلاید می‌توان مطرح کرد، بر اساس توضیحات ویدئوی قبلی، این است که در stage های parsing و indexing، مجموعه‌ای از metadata به data ی اصلی ما اضافه می‌شد. منظور از metadata، data ها و field هایی است که توسط خود Splunk به data ی شما افزوده می‌شوند. اگر به خاطر داشته باشید، در ویدئوی قبلی، تصویری نمایش داده شد که انواع field هایی که به عنوان metadata به data ی اصلی اضافه می‌شوند را نشان می‌داد و در مورد آن صحبت شد. پس خواهشمند است این موارد را که به صورت زنجیروار به یکدیگر متصل هستند، به طور کامل درک کنید. اگر قسمتی از یک ویدئو را متوجه نشوید یا دقت کافی نداشته باشید، احتمالاً در ویدئوهای بعدی سوالات زیادی برای شما پیش خواهد آمد که دلیل اصلی عدم درک مطلب، به بخش‌هایی باز می‌گردد که به آن‌ها توجه نکرده‌اید یا در آن مباحث ضعف دارید.

فازهای input و parsing

در این قسمت از ویدئو، قصد داریم توضیحات بیشتری در خصوص فازهای input و parsing ارائه دهیم. اما قبل از ورود به توضیحات، لازم است تا این بخش از ویدئو، بر روی stage input تسلط کامل پیدا کرده و مفاهیم آن را درک کرده باشید. همچنین، باید با مباحث مرتبط با اولویت‌بندی configuration file ها و خود configuration file ها (مانند inputs.conf, props.conf, transforms.conf, indexes.conf) و کاربرد هر یک، آشنایی کامل داشته باشید.

همانطور که در تصویر نمایش داده شده، در stage input، چندین configuration file دخیل هستند. configuration file اصلی، inputs.conf است که پیکربندی‌های مرتبط با باز کردن port و ایجاد data input را انجام می‌دهد. به صورت مستقیم در این configuration file می‌توان metadata ها را برای هر data sourceی که اضافه می‌شود، set کرد.

پس از آن، configuration file props.conf وجود دارد که در این فاز، برخی از configuration های موجود در این file برای stage input و برخی دیگر برای stage های بعدی کاربرد دارند. Configuration file هایی مانند character set و prefix sourcetype، مواردی هستند که در stage input پردازش شده و مورد استفاده قرار می‌گیرند.

در stage parsing نیز configuration file props.conf کاربرد بسیار مهمی دارد. می‌توان گفت اصلی‌ترین configuration file مرتبط با stage parsing، props.conf است. پس از آن، configuration file transforms.conf قرار دارد که نقش مهمی در این stage ایفا می‌کند.

به عنوان مثال، فرض کنید می‌خواهید timezone مرتبط با log های یک data source خاص را تغییر دهید. باید پیکربندی مرتبط با این مورد را در فایل props.conf set کنید. به عنوان مثال دیگر ممکن است نیاز داشته باشید پس از دریافت یک log، آن را تغییر داده و به یک معماری یا تجهیز دیگر ارسال کنید. در این مورد نیز باید از فایل‌های props.conf و transforms.conf استفاده نمایید.

به صورت کلی، زمانی که در stage input هستید و با configuration های مرتبط با آن کار می‌کنید، انعطاف‌پذیری بسیار پایین است، اما config هایی که در این فاز اعمال می‌شوند، کارآمدتر هستند یا کارایی بالاتری دارند. به عنوان مثال، اگر بخواهیم sourcetype یک log را تغییر دهیم، هم می‌توانیم این کار را در فاز input انجام دهیم و هم به نحوی در فاز parsing. اما زمانی که این کار در فاز input انجام می‌شود، کارایی آن بیشتر بوده و performance بهتری دارد.

در فاز یا stage input، data source دریافت می‌شود، اما در stage یا فاز parsing، آن data به event تبدیل شده و timestamp مورد نظر نیز به آن assign می‌گردد.

مورد بعدی که بسیار حائز اهمیت است، این است که در فاز input می‌توان مقدار اولیه field های metadata را set کرد. می‌توان source, sourcetype, host, index را set نمود. کافی است در stanza ی مرتبط با آن source، از attribute های source, sourcetype, host و index استفاده کرده و value مورد نظر را برای آن قرار داد. در همین ویدئو، این مورد به صورت عملی نمایش داده خواهد شد.

در stage parsing، می‌توان event-level transformation داشت. می‌توان مجموعه‌ای از field ها را اضافه یا کم کرد، log را route نمود و یا حتی بخشی از log را filter کرد. همانطور که پیش‌تر گفته شد، در فاز یا stage parsing می‌توان تنظیمات مرتبط با metadata را که از فاز input آمده‌اند، fine-tune کرد. البته کارایی این روش کمتر است، اما در اینجا control بیشتری وجود دارد.

زمانی که در فاز input، attributeی برای یک source تغییر داده می‌شود، در واقع آن تغییر برای کل آن source اعمال می‌گردد. نمی‌توان یک log مشخص از آن source را انتخاب کرده و تغییرات را فقط برای آن اعمال نمود. اما در فاز parsing چنین قابلیتی وجود دارد و می‌توان بخشی از data ی یک data source دریافتی را انتخاب کرده و عملیات خاصی بر روی آن انجام داد (مثلاً بخشی از log را filter کرد).

همانطور که در ابتدا ذکر شد، اصلی‌ترین فایل پیکربندی فاز input، inputs.conf و اصلی‌ترین فایل پیکربندی فاز parsing، props.conf است. البته در props.conf، مجموعه‌ای از attribute ها وجود دارند که به فاز input مرتبط هستند، اما بیشتر attribute های configuration file props.conf به فاز parsing مربوط می‌شوند.

فیلد sourcetype

در این ویدئو در خصوص sourcetype گفته شد که یکی از مهم‌ترین metadata های Splunk، فیلد sourcetype است. اما این فیلد دقیقاً چیست؟

فیلد sourcetype یک فیلد پیش‌فرض است که data structure event شما را مشخص می‌کند (تعریف event و زمان تبدیل data به event را به خاطر داشته باشید). تقریباً می‌توان گفت این فیلد به Splunk می‌گوید که چگونه این data را قالب‌بندی کند، به‌خصوص در زمان فرآیند indexing. از طرف دیگر، می‌توان آن را روشی برای دسته‌بندی و categorize کردن data type های مختلف در نظر گرفت.

فیلد sourcetype فیلدی است که بیشتر در فاز indexing مورد استفاده قرار می‌گیرد و استفاده از آن در ابتدای search های کاربر، باعث بهبود performance search می‌شود.

اما نکته بسیار مهم این است که چگونه sourcetype را اختصاص دهیم و از چه sourcetypeی استفاده کنیم؟

لیستی از sourcetype ها وجود دارد که Splunk به صورت پیش‌فرض آن‌ها را شناسایی کرده، sourcetype مربوطه را set نموده و مورد استفاده قرار می‌دهد. همچنین، زمانی که app هایی نصب می‌شوند که حاوی input و props هستند، به احتمال زیاد در آن input، فیلد sourcetype به صورت استاندارد تعریف شده است.

اما اگر inputی را خودتان ایجاد کرده‌اید و نمی‌دانید از چه sourcetypeی استفاده کنید، ابتدا باید بررسی کنید که آیا TA و appی برای آن data وجود دارد که data را بر اساس CIM، extract و normalize کند یا خیر. اگر چنین app و TAی وجود داشت، باید دستورالعمل آن را مطالعه کرده و ببینید دقیقاً چه sourcetypeی را پیشنهاد می‌دهد. برای اطمینان از matching صحیح بین data ی ورودی شما و stanza های موجود در props و transform آن TA، حتماً باید از همان sourcetypeی استفاده کنید که خود آن app و TA پیشنهاد داده و در configuration file های خود استفاده کرده است.

به عنوان مثال، اگر data ی FortiGate را دریافت می‌کنید و inputی برای آن باز کرده‌اید، از آنجایی که این data دارای TA و app مخصوص به خود است، TA آن را دانلود کرده و دستورالعملش را مطالعه کنید. اگر در خصوص sourcetype چیزی ذکر نشده بود، باید configuration file هایی مانند props.conf موجود در آن TA را با دقت بررسی کنید، ببینید از چه stanza هایی استفاده کرده و چه sourcetypeی نیاز است تا data ی شما با آن stanza match شود. سپس همان sourcetype را در input مرتبط با FortiGate استفاده نمایید. حتماً این تمرین را انجام دهید تا با روند کار آشنا شوید.

این توضیحات مربوط به تعریف sourcetype بود. همانطور که مشاهده شد، تعریف آن پیچیده نیست و با مسئله دشواری روبرو نیستیم. در قسمت بعدی این ویدئو، به موارد عملی پرداخته و نحوه پیکربندی یک input را با هم بررسی خواهیم کرد.

نحوه پیکربندی یک input

در قسمت عملی، قصد داریم دو نوع input ایجاد کنیم. همانطور که توضیح داده شد، می‌توان از قسمت Setting، گزینه Data Input را انتخاب کرده و سپس با توجه به نوع input مورد نظر، پیکربندی را انجام داد.

اما در صفحه home Splunk، قسمتی با عنوان Add Data وجود دارد. با کلیک بر روی این گزینه، صفحه‌ای باز می‌شود که سه گزینه اصلی در آن وجود دارد:

• Upload: می‌توان فایل‌هایی که دارای structure هستند را در اینجا upload کرد تا data ی داخل آن‌ها به راحتی در یک index ذخیره شود. توجه داشته باشید که در زمان استفاده از قسمت upload، هیچ inputی پیکربندی نمی‌شود و صرفاً محتوای فایل شما index می‌گردد. این گزینه بیشتر برای موارد تستی یا use case های خاص کاربرد دارد (مثلاً دریافت log از سیستمی که پیش‌تر log آن جمع‌آوری نمی‌شده است).
• Monitor: با کلیک بر روی این گزینه، می‌توان پیکربندی‌های مرتبط با مانیتورینگ file ها، directory ها و همچنین network port ها را انجام داد. تقریباً می‌توان گفت آیتم‌ها و data input هایی که در بخش Data Inputs وجود دارند، در این قسمت نیز با ظاهری شکیل‌تر و مرحله‌بندی شده، در دسترس هستند.
• Forward: این گزینه زمانی کاربرد دارد که Splunk Enterprise شما در نقش Deployment Server عمل کند و بخواهید پیکربندی‌هایی را به سمت Universal Forwarder ها ارسال نمایید.

اولین inputی که ایجاد خواهیم کرد، مرتبط با مانیتور کردن یکی از log file های Linux server است. این Splunk Enterprise بر روی یک Linux نصب شده است. زمانی که Splunk بر روی Linux نصب می‌شود، به صورت پیش‌فرض log های سیستم‌عامل خوانده نمی‌شوند. اگر بخواهید log های داخلی آن سیستم‌عامل را به وسیله Splunk Enterprise monitor کنید، باید پیکربندی‌های لازم را انجام دهید. توجه داشته باشید که این روش پیکربندی در سطح Web UI است و می‌توان از روش‌های دیگری نیز استفاده نمود.

برای ایجاد اولین input، از قسمت Setting وارد Data Input شده و بر روی گزینه File & Directory کلیک می‌کنیم. در این قسمت، تمام input های مرتبط با File & Directory نمایش داده می‌شوند. همانطور که در تصویر مشاهده می‌شود، برخی موارد به صورت پیش‌فرض وجود دارند. اگر TA، add-on یا app های Splunk را نصب کنید، به احتمال زیاد input های بیشتری نیز در اینجا نمایش داده خواهند شد که مرتبط با آن TA هستند. به عنوان مثال، همانطور که در پایین صفحه قابل مشاهده است، TA Linux نصب شده است (ابتدا از Splunkbase دانلود و سپس بر روی Splunk نصب گردیده) که باعث اضافه شدن این input ها شده است. اما به صورت پیش‌فرض، این input ها disable هستند. برای استفاده از آن‌ها، باید آن‌ها را enable کرده و پیکربندی‌های لازم را انجام داد (در آینده به این موارد خواهیم پرداخت).

اکنون قصد داریم یک مانیتور جدید تعریف کنیم. بر روی دکمه New Local File کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، ابتدا باید file یا directory مورد نظر را انتخاب کنیم. Log file مورد نظر در دایرکتوری /var/log لینوکس قرار دارد. فایل را انتخاب کرده و بر روی گزینه Next کلیک می‌کنیم.

سپس باید sourcetype مرتبط با log را انتخاب نماییم. در قسمت sourcetype، انواع مختلفی وجود دارد و مجدداً، اگر TAی نصب شده باشد که sourcetypeی در آن تعریف شده باشد، می‌توان آن را در اینجا انتخاب کرد. از قسمت Operation System، linux_secure را انتخاب می‌کنیم که sourcetype مورد نظر برای parsing این log است.

سپس بر روی گزینه Next کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، در قسمت App Context باید appی را که می‌خواهیم این پیکربندی input در آن ذخیره شود، معرفی کنیم. در اینجا به دلیل انتخاب sourcetype مرتبط با TA Linux، به صورت پیش‌فرض App Context همان app و add-on Linux قرار داده شده است. می‌توان آن را به راحتی تغییر داده و بر روی Search & Reporting تنظیم کرد.

پس از آن، باید host را پیکربندی کنیم که به صورت پیش‌فرض hostname Linux در نظر گرفته شده است. مهم‌تر از همه، باید index مرتبط را انتخاب کنیم. پیش‌تر یک index با نام linux ایجاد شده است که آن را انتخاب می‌کنیم.

در آخر بر روی گزینه Review کلیک کرده، review نمایش داده شده را بررسی و بر روی گزینه Submit کلیک می‌کنیم.

در این مرحله، input ایجاد شده است. می‌توان از گزینه Start Searching استفاده کرد تا به app search منتقل شده و log نمایش داده شود.

اما قصد داریم یک log file دیگر را نیز بخوانیم. بر روی Add More Data کلیک کرده، سپس Monitor را انتخاب می‌کنیم. در صفحه‌ای که نمایش داده می‌شود، بر روی قسمت File & Directory کلیک کرده و مجدداً فایل مورد نظر را انتخاب می‌کنیم.

بر روی گزینه Next کلیک می‌کنیم. Sourcetype به صورت پیش‌فرض توسط Splunk تشخیص داده می‌شود، اما می‌توان آن را تغییر داده و sourcetype مورد نظر را قرار داد.

سپس بر روی گزینه Next کلیک می‌کنیم. در صفحه‌ای که باز می‌شود، App Context و Index را تغییر می‌دهیم.

بر روی گزینه Review و در نهایت Submit کلیک می‌کنیم. می‌توان با استفاده از Start Searching به app search رفته و نتیجه را مشاهده نمود.

در اینجا search را اندکی تغییر می‌دهیم تا تمام sourcetype های موجود در این index قابل مشاهده باشند و سپس بر روی دکمه search کلیک می‌کنیم.

همانطور که در تصویر مشاهده می‌شود، اکنون دو sourcetype syslog و linux_secure وجود دارند و Splunk، log های مرتبط با دو فایل syslog و authentication را می‌خواند. اگر log جدیدی ثبت شود، آن را index خواهد کرد. همانطور که در تصویر قابل مشاهده است، log ها تقریباً parse شده، tag می‌خورند و مشکلی وجود ندارد. این به دلیل نصب قبلی TA Linux و استفاده از sourcetype های از پیش تعریف شده است. در داخل TA Linux، regex هایی وجود دارند که log ها را parse کرده و نمایش می‌دهند.

نکاتی در زمان ایجاد input وجود داشت:

• نکته اول: زمانی که در اینجا directory معرفی می‌شود، می‌توان include list یا exclude list داشت. در این دو قسمت، regex مورد نظر وارد می‌شود تا موارد دلخواه include یا exclude شوند (در آینده مثال‌هایی ارائه خواهد شد).
• نکته دیگر: اگر از Browse استفاده نشود و مسیر به صورت دستی وارد گردد، باید دقت شود که فایل مورد نظر بر روی سیستم‌عامل Windows است یا Linux. چون آدرس‌دهی در این دو سیستم‌عامل متفاوت است، باید نحوه آدرس‌دهی را متناسب با آن تغییر داد (مثالی در خود رابط کاربری نمایش داده شده است).

در صفحه بعد، در قسمت host سه گزینه وجود داشت:

• گزینه اول: می‌توان host value را به صورت مستقیم (یک کلمه) وارد کرد.
• گزینه دوم: می‌توان از regular expression استفاده کرد تا host از فیلد source استخراج شود (نیازمند آشنایی با محتوای فیلد source و نوشتن regex مناسب است) یعنی باید به Value ای که داخل Source قرار می گیرد دقت کنید. قبلا گفته بودیم که چه چیزی در متادیتای source به صورت پیش فرض قرار می گیرد. باتوجه به آن باید regex ای بنویسید تا host مدنظرتان را از source استخراج کنید. این در صورتی است که بخواهید host name را از فیلد Source استخراج کنید و اگر hostname را می دانید که از گزینه اول استفاده می کنید.
• گزینه سوم: این گزینه نیز امکان استخراج host value از فیلد source را فراهم می‌کند، اما با روش segment بندی بر اساس اسلش (/). یعنی هر slash که در فیلد source وجود دارد یک segment درنظر گرفته می شود و با شمارش segment ها و وارد کردن عدد آن می توان host value را استخراج کرد. به عنوان مثال در این مسیری که مشاهده می کنید، سگمنت اول، دوم و سوم را می بینید و می‌توان شماره segment مورد نظر برای قرار گرفتن در فایل host را وارد کرد.

نکته‌ای که وجود دارد این است که کمتر پیش می‌آید پیکربندی input ها از طریق Web UI انجام شود، به‌خصوص روی Splunk Enterprise. معمولاً admin ها بیشتر با پیکربندی input روی Universal Forwarder ها سروکار دارند.

به خاطر داشته باشید که پیکربندی انجام شده در Web UI، به صورت text در فایل پیکربندی مرتبط (در app مشخص شده توسط App Context) ذخیره می‌شود. اکنون اگر به app Search & Reporting مراجعه کرده و فایل inputs.conf آن را در directory local بررسی کنیم، پیکربندی‌های انجام شده قابل مشاهده خواهند بود.

همانطور که مشاهده می‌شود، ابتدا یک stanza برای input network تعریف شده (که بعداً بررسی می‌شود) و پس از آن، دو stanzaی monitor وجود دارد که دقیقاً همان مواردی هستند که پیش‌تر تعریف کردیم.

بنابراین، برای مانیتور کردن یک فایل یا directory، باید از کلمه کلیدی monitor استفاده کرده، سپس دو نقطه (:) قرار داده و مسیر مورد نظر را (با توجه به سیستم‌عامل) وارد نماییم.

پس از آن، attribute هایی مانند disabled (که اگر true باشد، stanza غیرفعال می‌شود)، host (یا metadataی host) و index وجود دارند. می‌توان این موارد را به صورت مستقیم در اینجا تغییر داده و پس از restart، تغییرات را اعمال نمود. همچنین attribute sourcetype نیز قابل تغییر است.

Stanza ی بعدی نیز به همین صورت است.

اگر بخواهیم whitelist یا blacklist اضافه کنیم، می‌توانیم از attribute های whitelist و blacklist استفاده نماییم. همانطور که در تصویر مشاهده می‌شود، مثالی از TA Linux آورده شده که در آن whitelist و blacklist به صورت regex تعریف شده‌اند. نکته مهم این است که این whitelist/blacklist بر روی فایل اعمال نمی‌شود، بلکه بر روی directory کاربرد دارد. اگر مسیر فایل حذف شده و directory مانیتور شود، آنگاه این whitelist و blacklist منطقی شده و بر روی آن directory اعمال می‌گردند. در این حالت، هر log file یا directory دیگری داخل آن directory که با whitelist مطابقت داشته باشد، مانیتور شده و log آن ارسال می‌شود.

نکته بسیار مهم: می‌توان از همین نوع پیکربندی در Universal Forwarder نیز استفاده کرده و این موارد را اعمال نمود تا log های مورد نظر به وسیله Universal Forwarder به Splunk Enterprise ارسال شوند.

نکته تکراری دیگر: در حال حاضر، این input ها بر روی Splunk Enterprise پیکربندی می‌شوند و log ها نیز بر روی همین Splunk Enterprise index می‌گردند. اگر قرار بود این Splunk Enterprise، log را به جای دیگری ارسال کند، حتماً باید فایل outputs.conf پیکربندی شود (که در ویدئوهای آینده بررسی خواهد شد) تا امکان ارسال log به Splunk دیگر فراهم گردد.

سناریوی بعدی، دریافت log به وسیله یکی از network port ها است. فرض کنید تجهیزی وجود دارد که log های خود را به سمت Splunk Enterprise بر روی پورت 514 UDP ارسال می‌کند.

ابتدا برای اطمینان از رسیدن log های مورد نظر از source مشخص به Splunk Enterprise، حتماً از ابزار tcpdump استفاده کنید. می‌توان دستور tcpdump را بر روی Linux مورد نظر اجرا کرده و حتی شماره port و نام host مبدا را نیز در دستور وارد نمود تا در صورت دریافت log از آن source، log در خروجی نمایش داده شود و از رسیدن log به Splunk Enterprise اطمینان حاصل گردد. در محیط‌های واقعی، کار با tcpdump بسیار رایج است، پس حتماً در خصوص این دستور مطالعه کرده و بر آن مسلط شوید. زیرا معمولاً قبل از انجام پیکربندی توسط Splunk admin، نیاز به verify دریافت log از سمت admin های دیگر وجود دارد.

پس از اطمینان از دریافت log با این دستور، برای انجام پیکربندی، از قسمت Data Inputs بر روی گزینه UDP کلیک می‌کنیم. همانطور که مشاهده می‌شود، هیچ portی برای UDP از پیش باز نشده است.

بر روی New Local UDP کلیک می‌کنیم. در فرمی که باز می‌شود، ابتدا می‌توان نوع پروتکل (TCP یا UDP) را انتخاب کرد و سپس port مورد نظر را وارد نمود. در قسمت بعدی، می‌توان source را override کرد.

قسمت بعدی که بسیار مهم است، امکان ایجاد محدودیت بر اساس source ارسال‌کننده است. این محدودیت باعث می شود شما فقط از همان یک source روی این پورت log دریافت کنید. می‌توان در این فیلد، آدرس IP یا DNS name ارسال‌کننده log را وارد کرد تا این port باز شده بر روی Splunk Enterprise، فقط از همان source خاص log دریافت کند و log های ارسالی از source های دیگر را نادیده بگیرد.

پس از انجام تنظیمات، بر روی گزینه Next کلیک می‌کنیم. در اینجا می‌توان ابتدا sourcetype را مشخص کرد (می‌توان از لیست جستجو و انتخاب نمود) و سپس App Context، host (بر اساس IP, DNS یا custom) و در نهایت index را تنظیم نمود.

سپس بر روی Review و در نهایت Submit کلیک می‌کنیم. پس از ایجاد موفقیت‌آمیز پیکربندی، می‌توان از گزینه Start Searching استفاده کرده و به منوی search رفت تا log های دریافتی را مشاهده نمود.

همانطور که در تصویر مشاهده می‌شود، log های مورد نظر که ارسال شده بودند، در اینجا دریافت شده‌اند (محتوای log در این سناریوی تستی اهمیتی ندارد).

پس از اطمینان از index شدن log، به فایل inputs مراجعه می‌کنیم تا ببینیم چه نوع stanzaی در آنجا اضافه شده است.

همانطور که در تصویر مشاهده می‌شود، stanza ی UDP اضافه شده است (اگر TCP انتخاب می‌شد، stanza ی TCP ایجاد می‌گردید). پس از آن، آدرس IP ارسال‌کننده و portی که log بر روی آن ارسال می‌شود، مشخص شده‌اند و در نهایت، attribute های مرتبط با ذخیره‌سازی آن log (مانند index, sourcetype, host, connection_host) قرار دارند.

به عنوان جمع‌بندی، اگر نخواهید از طریق Web UI این پیکربندی‌ها را انجام دهید، می‌توانید به صورت دستی همین پیکربندی‌ها را در فایل inputs.conf وارد کرده و از آن‌ها استفاده کنید و در صورت نیاز، مقادیر sourcetype، نام index و سایر موارد را تغییر دهید.

با ماژول چهارم از دوره Splunk Enterprise Data Administration همراه شما هستیم. در این ماژول، به موضوعات heavy forwarder ها و forwarder management پرداخته خواهد شد. در ابتدای این آموزش، با heavy forwarder آشنا می‌شویم و تفاوت‌های آن با universal forwarder و همچنین پیکربندی‌های مرتبط با HF (Heavy Forwarder) را بررسی می‌کنیم. پس از آن، در خصوص deployment server صحبت خواهیم کرد و فرامی‌گیریم که چگونه app ها را بر روی universal forwarder ها و heavy forwarder ها deploy و مدیریت نماییم. در نهایت، قادر خواهیم بود به راحتی universal forwarder را نصب کنیم، deployment server را پیکربندی نماییم و از آن‌ها در محیط‌های عملیاتی استفاده کنیم.

Heavy forwarder یک Splunk Enterprise instance است که فقط license و feature مربوط به forwarder آن فعال است و کار می‌کند. این نوع forwarder، پیش از ارسال data، می‌تواند data را parse کند و همچنین قادر است بر اساس event، دیتاها را به سمت indexer های متفاوت یا solution های دیگر route نماید. یکی از نکات مهم در مورد heavy forwarder ها این است که آن‌ها نمی‌توانند search های توزیع‌شده را انجام دهند. اما تفاوت دقیق‌تر میان heavy forwarder و universal forwarder چیست؟

همان‌طور که اشاره شد، تمام feature هایی که در مورد universal forwarder مطرح گردید، بر روی heavy forwarder نیز وجود دارد و حتی امکانات بیشتری نیز ارائه می‌دهد. به طور کلی، universal forwarder برای مواردی مناسب است که شما قصد دارید data را از روی file هایی در سیستم عامل بخوانید یا از آن به عنوان یک forwarder intermediate (میانی) استفاده کنید. از آنجایی که universal forwarder منابع کمتری مصرف می‌کند، برای نصب بر روی server ها و سیستم‌عامل‌هایی که صرفاً قصد خواندن log از آن‌ها را داریم، مناسب است.

در splunk base، app ها و add-on هایی وجود دارند که منحصراً روی heavy forwarder ها نصب می‌شوند یا نصب آن‌ها بر روی heavy forwarder ها ارجحیت دارد، مانند DB Connect (app DB Connect). بر روی heavy forwarder، در صورت نیاز می‌توانیم splunk web را داشته باشیم، اما universal forwarder فاقد هرگونه web UI است. Heavy forwarder قادر به انجام وظایف پیچیده‌ای مانند routing مبتنی بر event یا routing در سطح event ها است. این در حالی است که در universal forwarder، تنها امکان selectively routing یا selectively forwarder وجود دارد که این یک simple routing محسوب می‌شود و در heavy forwarder نیز موجود است. حتی در heavy forwarder، امکان mask کردن بخش یا قسمتی از data وجود دارد؛ بدین ترتیب، زمانی که data ذخیره می‌شود، آن قسمت به نحوی mask شده و دیگر قابل مشاهده نخواهد بود. اما universal forwarder فاقد چنین قابلیتی است و UF (Universal Forwarder) از filtering مبتنی بر regular expression پشتیبانی نمی‌کند.

بسته به معماری پیاده‌سازی‌شده برای Splunk Enterprise، ممکن است نیاز باشد که heavy forwarder ما از چندین splunk forwarder دیگر log دریافت کند. برای این منظور، ضروری است که port مورد نظر بر روی heavy forwarder باز شود. پیش از این در خصوص باز کردن port و دریافت data از forwarder ها صحبت کرده‌ایم و این موارد دقیقاً مشابه توضیحات قبلی است. اگر قصد باز کردن portی بر روی heavy forwarder را داشته باشیم، می‌توانیم از CLI استفاده کرده و دستور مربوطه را وارد کنیم تا port مورد نظر باز شود. همچنین، در configuration فایل inputs.conf، می‌توان از stanzaی splunk tcp استفاده نمود، port مورد نظر را در آنجا assign کرد و attribute های لازم را وارد نمود. علاوه بر این، اگر نیاز به دریافت log از تجهیزاتی مانند firewall ها، switch ها یا router ها باشد، همان‌طور که در ویدیوهای قبلی در مورد input صحبت شد، باید یک input از نوع network باز کنیم که جزئیات بیشتر آن در ویدیوهای آتی مطرح خواهد شد.

همان‌طور که در ویدیوی قبلی توضیح داده شد، زمانی که قصد ارسال log از یک splunk instance به یک یا چند مقصد را داریم، باید configuration مرتبط با outputs.conf را پیکربندی نماییم. در آن configuration، بر اساس configuration level های تعریف‌شده، آدرس IP و port مقصد را وارد می‌کنیم یا از دستور splunk add forward-server استفاده می‌نماییم تا IP و port مقصد به configuration فایل outputs.conf اضافه شود.

در بخش بعدی این ویدیو، موضوع deployment server مورد بحث قرار خواهد گرفت. اما پیش از ورود به آن مبحث، لازم است اشاره شود که یک configuration به نام deploymentclient.conf در Splunk وجود دارد. در این configuration، آدرس deployment server ذخیره می‌شود تا universal forwarder یا heavy forwarder بتوانند app ها و configuration های مورد نظر را از deployment server دریافت کرده و بر اساس آن configuration عمل کنند. بنابراین، اگر نیاز دارید که universal forwarder یا heavy forwarder شما به deployment server متصل باشد، می‌توانید از دستور splunk set deployment-poll استفاده کرده و آدرس deployment server را assign نمایید. همچنین، امکان استفاده از پیکربندی فایل deploymentclient.conf وجود دارد که نمونه‌ای از آن در تصویر نمایش داده شده است. در attribute مربوط به target URI، باید IP آدرس deployment server و port پیش‌فرض ۸۰۸۹ را وارد کنید.

معمولاً برای optimization (بهینه‌سازی) heavy forwarder ها، ادمین‌های splunk اقدام به disable کردن splunk web در heavy forwarder می‌کنند و همچنین local indexing را بر روی heavy forwarder ها غیرفعال می‌نمایند. البته در صورت نیاز، می‌توانند مجدداً local indexing را فعال کنند. برای اینکه splunk admin بتواند indexing data را بر روی heavy forwarder غیرفعال کند، می‌تواند در configuration فایل outputs.conf، در stanzaی index and forward، attribute مربوط به index را برابر با false قرار دهد. این کار از طریق splunk web نیز امکان‌پذیر است. برای غیرفعال کردن splunk web، کافی است در فایل config مربوط به web.conf، در stanzaی settings، attribute مربوط به start web server را برابر با صفر یا false تنظیم کنید.

پیش‌تر در مورد selectively routing data صحبت کردیم، اما سناریوی زیر که بسیار کارآمد است، ارزش توضیح بیشتر را دارد: فرض کنید در universal forwarder با آدرس IP ۱۰.۰.۰.۱۰۰ (که در سمت چپ تصویر نمایش داده شده) دو دسته log داریم: metrics.log و runtime.log. نیازمندی ما این است که log های metric.log منحصراً به heavy forwarder با آدرس IP ۱۰.۰.۰.۷۷ ارسال شوند و همزمان، تمام data جمع‌آوری‌شده به صورت مستقیم به indexer ها ارسال گردد. با بررسی پیکربندی input، مشاهده می‌کنیم که stanza اول، که log های metric را monitor می‌کند، دارای یک attribute به نام TCP routing است که یک نام برای آن set شده است. اگر این نام را در پیکربندی outputs.conf جستجو کنیم، به یک پیکربندی output در سطح target group می‌رسیم که در آن از attribute مربوط به server استفاده شده و IP آدرس heavy forwarder برای آن set گردیده است. این تنظیم باعث می‌شود که این data به heavy forwarder ارسال شود.

اما پیکربندی‌های دیگری نیز وجود دارند. در پیکربندی input، log های runtime نیز جمع‌آوری و monitor می‌شوند. در پیکربندی output، یک TCP out در سطح global تعریف شده که یک default group برای آن set گردیده است. این default group به یک target group اشاره دارد. داخل آن target group، با استفاده از attribute مربوط به server، دو indexer تعریف شده‌اند که به صورت پیش‌فرض، هر ۳۰ ثانیه load balancing بین آن‌ها انجام می‌شود. در نتیجه، این target group به عنوان پیش‌فرض عمل کرده و تمام log ها به سمت آن ارسال می‌شوند. از طرف دیگر، log های metric از طریق heavy forwarder ارسال می‌گردند. بنابراین، با استفاده از selectively routing، log های metric از طریق heavy forwarder و target group مربوطه (HF) فرستاده می‌شوند.

تا این بخش از آموزش، موضوع heavy forwarder مورد بررسی قرار گرفت. به نظر می‌رسد بیشتر مطالب و feature های مطرح‌شده، تکراری بودند و صرفاً به یادآوری آن‌ها اکتفا گردید. در بخش بعدی این ویدیو، به موضوع deployment server پرداخته خواهد شد؛ ابتدا مفاهیم آن مرور شده و سپس وارد بخش عملی خواهیم شد.

deployment server

زمانی که قصد نصب و پیاده‌سازی forwarder را داریم، پس از اتمام نصب، باید پیکربندی‌های output و input را انجام دهیم. اما اگر تعداد forwarder ها بسیار زیاد باشد، مدیریت این موارد چگونه خواهد بود؟ آیا لازم است بر روی تک‌تک این forwarder ها، پیکربندی‌ها را به صورت manual ایجاد کنیم؟ یا یک solution مرکزی وجود دارد که بتوانیم پیکربندی‌ها را از طریق آن به forwarder مورد نظر اعمال کرده و forwarder پس از دریافت پیکربندی، موارد تنظیم‌شده را برای ما ارسال کند.

یک solution به نام deployment server وجود دارد که یک tool built-in در Splunk Enterprise است و به ما امکان می‌دهد package ها، app ها و configuration ها را به صورت مرکزی مدیریت کنیم. خوشبختانه، forwarder management دارای user interface (رابط کاربری) است و می‌توان به صورت graphical با آن کار کرد. هنگامی که پیکربندی را ایجاد کرده و بر روی deployment server قرار می‌دهید و آن را به forwarder مورد نظر ارسال می‌کنید، حتی می‌توانید splunk instance مقصد را restart نمایید.

برای استفاده از Splunk Enterprise به عنوان deployment server، حتماً به یک enterprise license نیاز دارید که بر روی Splunk Enterprise شما نصب شده باشد. سه اصطلاح و component بسیار مهم در مباحث deployment server وجود دارد:

1. Deployment App: هدف از deployment server چیست؟ هدف این است که به وسیله آن، configuration file ها، app ها و TA (Technical Add-on) های مورد نظر خود را بر روی deployment client ها (همان forwarder ها) deploy کرده و آن‌ها را مدیریت کنید. تمام این موارد (configuration file ها، app ها، TA ها) تحت عنوان deployment app شناخته می‌شوند و یک component برای deployment server به شمار می‌روند. زمانی که قصد ارسال یک configuration file یا یک app/TA بر روی forwarder های خود را دارید، باید آن را در مسیر splunk_home/etc/deployment-apps/ قرار دهید. توجه داشته باشید که در این مسیر، حتماً باید configuration file های خود را در قالب app، deploy کنید. به عنوان مثال، اگر input/outputی دارید که خودتان نوشته‌اید و می‌خواهید روی deployment client ها ارسال کنید، باید یک directory با یک نام مدنظرتان ایجاد کرده و داخل آن directory، حداقل یک directory به نام local داشته باشید که پیکربندی‌های شما در آن قرار گیرد. هنگامی که آن app را deploy می‌کنید، به directory مربوط به app ها در universal forwarder یا heavy forwarder منتقل شده و مانند یک app معمولی شروع به کار می‌کند. تمام قواعد مربوط به اولویت‌بندی app ها که پیش‌تر توضیح داده شد، در اینجا نیز معتبر و جاری است.
2. Server Class: ممکن است نیاز داشته باشید deployment client ها یا forwarder های خود را دسته‌بندی کنید (بر اساس نوع سیستم‌عامل، کاربرد یا هر معیار دیگری که admin تعیین می‌کند) و سپس پیکربندی‌ها و app ها را به آن دسته‌بندی خاص assign کنید. با استفاده از component مربوط به server class، به راحتی می‌توانید این دسته‌بندی را در سمت forwarder ها ایجاد کرده و app های مورد نظر را به آن server class، assign نمایید. تمام app های موجود در یک server class، به تمام deployment client ها یا forwarder های عضو آن server class، assign و در شاخه app آن‌ها copy می‌شوند و سپس شروع به کار می‌کنند. بنابراین، server class برای تعیین اینکه کدام app بر روی کدام deployment client یا forwarder باید deploy شود، ایجاد می‌گردد. تمام تنظیمات مربوط به server class در فایل configuration به نام serverclass.conf ذخیره می‌شود.
3. Deployment Client: احتمالاً تا کنون متوجه شده‌اید که deployment client دقیقاً چیست. تمام splunk instance هایی که به یک deployment server متصل می‌شوند، یک deployment client محسوب می‌گردند. این deployment client ها هستند که ارتباط را با deployment server آغاز کرده و به آن متصل می‌شوند.

برای پیکربندی یک deployment server، ابتدا لازم است configuration های مرتبط با server class ایجاد شده و app هایی که قصد deploy کردن آن‌ها را داریم، آماده شوند. پس از نصب Splunk Enterprise، برای سهولت در پیکربندی deployment server، نیاز است که ابتدا یک deployment client، پیکربندی‌های مرتبط با deployment client خود را تکمیل کند تا صفحه forwarder management در Splunk Enterprise فعال شود. پس از آن، می‌توانید server class ها را بسازید، app های مورد نظر را انتخاب کنید، deployment client ها را به server class ها assign نمایید و در نهایت، app ها و پیکربندی‌های مورد نظر بر روی deployment client ها اعمال خواهند شد. جزئیات عملی این فرآیند در ادامه بررسی می‌شود.

نکته حائز اهمیت این است که حتماً باید configuration خود را در قالب deployment app هایی ایجاد کرده و در directory مربوط به etc/deployment-apps قرار دهید تا بتوانید آن را در بخش forwarder management در Splunk مشاهده کرده و به یک server class، add کنید. به عنوان مثال، اگر یک input و output خاص مد نظرتان است، باید در شاخه deployment-apps، یک directory ایجاد کرده و نام مرتبط با آن app را انتخاب نمایید. توصیه می‌شود از نام‌های معنی‌دار استفاده کنید، زیرا در سازمان‌های بزرگ، تعداد این app ها افزایش یافته و نام‌گذاری نامناسب می‌تواند منجر به خطا شود. پس از ایجاد app در مسیر deployment-apps، حتماً باید directory به نام local داخل آن وجود داشته باشد (وجود سایر فایل‌ها یا دایرکتوری‌ها الزامی نیست) و configuration های خود را داخل directory local قرار دهید.

شما می‌توانید تعداد زیادی app در قسمت deployment-apps داشته باشید. همچنین، می‌توانید server class های متفاوتی تعریف کنید که هر کدام شامل deployment client های مختلفی باشند. سپس app مورد نظر را به server class مربوطه اختصاص می‌دهید و آن app بر روی deployment client های عضو آن کلاس، deploy می‌شود. لازم به ذکر است که لزومی ندارد همیشه app ها را از ابتدا بسازید. می‌توانید به splunk base مراجعه کرده، TA های مورد نیاز خود را download کنید، آن‌ها را در مسیر مذکور extract نمایید، در صورت نیاز به تغییرات، directory local را داخل TA ایجاد کرده، configuration مورد نظر را ویرایش کنید و سپس آن app را بر روی deployment client ها deploy نمایید. به عنوان مثال، برای جمع‌آوری log های ویندوز، می‌توانید TA ویندوز را download کرده، در مسیر مربوطه قرار دهید، directory local را برای آن ایجاد کنید، پیکربندی input را در directory local کپی و ویرایش نمایید (منظور از ویرایش، enable کردن input های مورد نظر است)، سپس در همان directory local، یک فایل output با تنظیمات مورد نظر (IP آدرس و port های indexer ها) ایجاد کنید و در نهایت، deployment app مربوط به ویندوز را بر روی deployment client های ویندوزی خود assign نمایید.

برای توضیح بیشتر در مورد server class، به تصویر توجه کنید. فرض کنید source های log متعددی دارید که بر روی هر کدام forwarder splunk نصب شده است و قصد دارید log های متفاوتی را از این server ها جمع‌آوری کنید. برخی از این server ها ویندوزی و برخی لینوکسی هستند. بسته به کاربرد، ممکن است log های خاصی فقط روی برخی server های ویندوزی وجود داشته باشند. در چنین شرایطی، پس از نصب universal forwarder ها و forwarder ها و تنظیم آدرس deployment server، آن‌ها به deployment server متصل می‌شوند. splunk admin می‌تواند روی deployment server، component هایی به نام server class با نام‌های متفاوت ایجاد کند. forwarder ها می‌توانند به راحتی عضو یک یا چند server class شوند و configuration ها و app های موجود در آن کلاس(ها) را دریافت کنند.

به عنوان مثال، ممکن است روی deployment server چهار app متفاوت با configuration input های مختلف داشته باشید که هر کدام dataی متفاوتی جمع‌آوری می‌کنند. Server اول پس از اتصال، چون پیکربندی شده تا به server class ویندوز متصل شود، تمام app ها و configuration های آن کلاس را دریافت کرده و بر اساس آن log ارسال می‌کند. Server دیگری ممکن است عضو دو server class باشد و app ها و configuration های هر دو کلاس را دریافت و اجرا کند. به همین ترتیب، server های لینوکسی به server class لینوکس متصل شده و configuration ها و app های مربوطه را دریافت می‌کنند. توجه داشته باشید که ارتباطات deployment server بر روی پورت ۸۰۸۹ و ارسال data توسط forwarder ها بر روی پورت ۹۹۹۷ (به صورت پیش‌فرض) انجام می‌شود.

خلاصه فرآیند به این صورت است: برای deploy کردن configuration ها روی deployment client ها، آن‌ها را در قالب app در مسیر etc/deployment-apps روی instance ای که نقش deployment server دارد، قرار می‌دهید. سپس از طریق UI مربوط به forwarder management، یک یا چند server class ایجاد می‌کنید. پس از نصب forwarder، با استفاده از دستور splunk set deployment-poll آدرس deployment server (با port پیش‌فرض ۸۰۸۹) را به آن معرفی می‌کنید (پس از این دستور، splunk باید restart شود). در نهایت، deployment app ها در مسیر splunk_home/etc/apps روی forwarder ها (deployment client ها) کپی شده و قابل استفاده خواهند بود.

دستور splunk set deployment-poll چه تغییری ایجاد می‌کند؟ این دستور فایل configuration به نام deploymentclient.conf را پیکربندی می‌کند. همان‌طور که در نمونه نمایش داده شده، پس از اجرای دستور، فایل ایجاد شده و در stanzaی [deployment-client]، اطلاعات وارد شده (مانند target URI) ثبت می‌شود. دو attribute دیگر نیز به صورت دستی قابل افزودن هستند: clientName و phoneHomeIntervalInSec. دومی، فاصله زمانی (به ثانیه) است که deployment client با deployment server ارتباط برقرار می‌کند (پیش‌فرض ۶۰ ثانیه). با تنظیم این attribute، می‌توانید این فاصله زمانی را تغییر دهید.

در این سناریو، یک Splunk Enterprise نصب شده که هم نقش deployment server و هم نقش indexer (دریافت‌کننده log از universal forwarder) را ایفا می‌کند. package مربوط به universal forwarder دانلود شده و آماده نصب است. با استفاده از دستور tar، package با فرمت .tgz مربوط به Splunk Universal Forwarder نصب می‌شود. فرآیند نصب مشابه نصب Splunk Enterprise است.

پس از extract شدن package، به مسیر نصب آن رفته و وارد directory bin می‌شویم. در این مسیر، می‌توانیم از دستور splunk مشابه Splunk Enterprise استفاده کرده و splunk forwarder را اجرا کنیم. پس از اجرا، مراحل اولیه‌ای وجود دارد: ابتدا باید agreement (توافق‌نامه) را بپذیریم و سپس یک user از نوع administrator برای Splunk Universal Forwarder ایجاد کنیم.

پس از تکمیل این مراحل، Splunk Universal Forwarder اجرا می‌شود، اما فاقد هرگونه پیکربندی بوده و logی را به مقصدی ارسال نمی‌کند. همان‌طور که پیش‌تر گفته شد، ابتدا باید پورت ۹۹۹۷ بر روی دریافت‌کننده log (در اینجا indexer) باز شود. این کار را می‌توان از طریق منوی Settings > Forwarding and receiving در indexer انجام داد. در بخش Configure receiving، می‌توان پورت ۹۹۹۷ را پیکربندی کرد یا از دستور CLI که قبلاً اشاره شد، استفاده نمود. با کلیک بر روی New Receiving Port، شماره port را وارد کرده و بر روی Save کلیک می‌کنیم.

پس از باز شدن port مورد نظر، می‌توانیم splunk forwarder ها را طوری پیکربندی کنیم که log های خود را به این port ارسال نمایند. همان‌طور که اشاره شد، به دلیل عدم پیکربندی input، log های معمول ارسال نمی‌شوند، اما log های internal به صورت پیش‌فرض دارای input هستند و باید به Splunk Enterprise ارسال شوند. برای تأیید این موضوع، در Splunk Enterprise، در منوی Search، index=internal را جستجو می‌کنیم تا log های universal forwarder قابل مشاهده باشند.

در تصویر خروجی، مشاهده می‌شود که universal forwarder، log های internal خود (مانند log های metric) را ارسال کرده است.

دستور splunk list forward-server که بر روی forwarder ها اجرا می‌شود، لیست مقصدها (indexer ها) یی که forwarder به آن‌ها log ارسال می‌کند را نمایش می‌دهد. برای اجرای این دستور، به directory bin در مسیر نصب splunk می‌رویم.

همچنین بر روی indexer (دریافت‌کننده log)، می‌توان از دستور splunk display listen برای مشاهده port های فعال استفاده کرد. خروجی این دستور نشان می‌دهد که پورت ۹۹۹۷ فعال و قابل استفاده است.

در ویدیوی قبلی در مورد troubleshooting صحبت شد. برای بررسی ارسال data توسط universal forwarder (یا هر forwarder دیگر)، می‌توان log file مربوط به splunkd را بررسی کرد. با اجرای دستور مربوطه (که قبلاً نشان داده شد)، خروجی log نشان می‌دهد که آیا splunk forwarder به indexer متصل شده است یا خیر. همچنین، در indexer، می‌توان با جستجو بر اساس host (نام یا IP آدرس universal forwarder)، log های دریافتی از آن forwarder خاص را مشاهده کرد و از دریافت data مطمئن شد.

در این ویدیو، نحوه استفاده از deployment server برای ارسال config به universal forwarder ها و forwarder ها توضیح داده شد. universal forwarderی که نصب کردیم، فاقد config برای input بود و فقط config مربوط به output به صورت دستی برای آن ایجاد شد. برای اتصال آن به deployment server، از دستور splunk set deploy-poll استفاده می‌کنیم تا آدرس deployment server که همان Splunk Enterprise نصب‌شده قبلی است و log های internal را دریافت می‌کرد به آن معرفی شود و سپس پیکربندی‌های مربوط به input از طریق deployment server روی آن deploy گردد. برای مشاهده صفحه forwarder management در Splunk Enterprise، به منوی Settings > Forwarder management مراجعه می‌کنیم. این صفحه زمانی فعال می‌شود که حداقل یک forwarder با تنظیمات deployment client صحیح به آن متصل شود. اکنون بر روی Splunk Forwarder، دستور splunk set deployment-poll  را اجرا می‌کنیم تا پیکربندی مرتبط با deployment client ایجاد شود.

پس از اجرای دستور، فایل configuration مربوط به deployment client به‌روزرسانی می‌شود. با مشاهده محتوای این فایل در مسیر etc/system/local فایل configuration مربوط به deployment client با دستور cat، می‌بینیم که آدرس IP وارد شده در دستور، ثبت گردیده است. پس از تغییر configuration، ضروری است که سرویس splunk یک بار restart شود.

پس از restart شدن splunk، به صفحه forwarder management در Splunk Enterprise بازگشته و صفحه را refresh می‌کنیم. اگر اتصال با موفقیت برقرار شده باشد، صفحه تغییر کرده و امکان ادامه پیکربندی فراهم می‌شود.

همان‌طور که در صفحه مشاهده می‌شود، پس از اتصال اولین forwarder، لیستی از forwarder های متصل (clients) نمایش داده می‌شود که شامل اطلاعاتی مانند نام host و آخرین زمان اتصال (Last phone home) است. پیش از ادامه توضیحات، یک سیستم‌عامل ویندوز آماده شده و universal forwarder بر روی آن نصب می‌گردد تا هر دو نوع client در مثال وجود داشته باشند.

فرآیند نصب universal forwarder بر روی ویندوز

پس از دانلود و اجرای فایل نصبی universal forwarder با چنین صفحه ای مواجه می شوید. ابتدا تیک agreement را زده و گزینه استفاده از Splunk Enterprise on-premise را انتخاب می‌کنیم. با کلیک بر روی Customize Options، ابتدا destination path (مسیر نصب) نمایش داده می‌شود. در مرحله بعد، می‌توان تنظیمات مربوط به SSL را انجام داد. سپس نوع account برای نصب انتخاب می‌شود: Local System (با دسترسی administrator و اجرای به عنوان  serviceو بالاترین سطح دسترسی را دارد)، Domain Account (اگر ویندوز عضو دامین باشد) یا Virtual Account (ایجاد یک اکانت مجازی با دسترسی محدود که باید به صورت دستی مدیریت شود). گزینه Local System انتخاب شده و Next را می‌زنیم. در مرحله بعد، می‌توان تنظیمات input را از طریق UI انجام داد. هر تیک معادل ایجاد یک پیکربندی در inputs.conf است. از آنجایی که قصد داریم input ها را از طریق deployment server مدیریت کنیم، از این مرحله عبور کرده و Next را می‌زنیم. سپس username (admin) و password برای ادمین لوکال universal forwarder وارد می‌شود.

در پنجره بعدی، آدرس deployment server (همان آدرس IP و پورت ۸۰۸۹) وارد می‌شود. سپس Next را می‌زنیم. در پنجره مربوط به Deployment Indexer، آدرس indexer ها را وارد می‌کنیم. اگر قرار است فایل outputs.conf از طریق deployment server، deploy شود، این قسمت را خالی رها کرده و Next را می‌زنیم. در نهایت، بر روی Install کلیک کرده تا فرآیند نصب آغاز شود. پس از اتمام نصب، با کلیک بر روی Finish، پنجره بسته می‌شود. اکنون با بررسی مسیر نصب Splunk Universal Forwarder در ویندوز، باید فایل پیکربندی deploymentclient.conf با تنظیمات صحیح وجود داشته باشد.

با بازگشت به صفحه forwarder management در Splunk Enterprise و refresh کردن آن، مشاهده می‌کنیم که اکنون دو client (یکی لینوکس و دیگری ویندوز) در لیست وجود دارند و هیچ appی هنوز بر روی آن‌ها deploy نشده است.

اکنون قصد داریم app هایی که پیش‌تر ایجاد کرده‌ایم را از طریق deployment server بر روی این دو forwarder، deploy کنیم. سه app آماده شده است:

• App لینوکس: شامل input مورد نظر برای لینوکس.
• App ویندوز: شامل input و فایل‌های transform و props برای ویندوز.
• App عمومی Output: شامل فایل conf.

این سه directory (app) را در مسیر etc/deployment-apps مربوط به deployment server کپی می‌کنیم. پس از چند دقیقه، forwarder management این app ها را شناسایی کرده و در تب Apps نمایش می‌دهد. همان طور که در تصویر می بینید، نام app ها مطابق نام directory ها خواهد بود و به راحتی می توانیم server class مدنظرمان را بسازیم و کلاینت ها و App های مورد نظر را اضافه کرده و در نهایت روی آن ها deploy کنیم.

در تب client که کلاینت ها را نمایش می دهد و یک سری مشخصه ها از هر forwarder قابل نمایش است. در قدم بعدی کافی است که ما server class ها را ایجاد ‌کنیم. دو تا server class لینوکس و ویندوز نیاز داریم. روی گزینه create one کلیک می کنیم و server class را می سازیم.

ابتدا برای لینوکس: بر روی New Server Class کلیک کرده، نام Linux-Servers را وارد و Save می‌کنیم. سپس در بخش Add Apps، app مربوط به لینوکس و app مربوط به output  را انتخاب می‌کنیم. Save را زده و در بخش Add Clients، client لینوکسی را (با وارد کردن نام یا IP آن در فیلد Include Name Filter و تأیید با Preview Changes) انتخاب و Save می‌کنیم. بعد از ایجاد server class به قسمت forwarder management می رویم و روی بخش app کلیک می کنیم. در این قسمت برای app ها یک سری تنظیماتی وجود دارد. برای مثال برای app لینوکسی روی edit کلیک می کنیم. در قسمت تنظیمات بهتر است که تیک Splunkd Restart را فعال کرده و همچنین در این بخش می‌توان app را با برداشتن تیک Enable ، disable کرد و روی save کلیک کرد. بعد منتظر می مانیم تا تغییرات اعمال شود و splunkd مجددا راه اندازی شود و بعد log های مدنظر را دریافت کنیم.

در همین فاصله به همین ترتیب، یک server class برای ویندوز با نام Windows-Servers ایجاد می‌کنیم. در بخش Add Apps، app مربوط به ویندوز و app مربوط به output را انتخاب و Save می‌کنیم. در بخش Add Clients، client ویندوزی را انتخاب و Save می‌نماییم. در این قسمت اگر بخواهیم تعداد زیادی client ذکر کنیم، می توانیم از کاما یا regex یا علامت * استفاده کنیم. می توانیم یک exclude list هم داشته باشیم و بر اساس machine type هم فیلتر کنیم. بعد از انجام تنظیمات روی save کلیک می کنیم. سپس به قسمت forwarder management می رویم و در بخش app، تیک restart رو میزنیم و منتظر deploy شدن app ها می شویم و بعد از آن لاگ های مدنظرمان را دریافت می کنیم.

بعد از گذشت چند دقیقه به یکی از universal forwarder ها مراجعه می کنیم و با بررسی مسیر etc/apps روی هر کدام از universal forwarder ها، مشاهده می‌کنیم که app های مربوطه (بر اساس عضویت در server class) deploy شده‌اند. به splunk universal  بعدی مراجعه می کنیم و در قسمت App، app های موردنظر deploy شده و به احتمال زیاد لاگ مدنظر را هم دریافت کردیم.

در نهایت، برای اطمینان از دریافت log ها، به app Search در Splunk Enterprise رفته و بر اساس index های تعریف شده (مثلاً index=windows یا index=linux) جستجو می‌کنیم. اگر در بازه زمانی پیش‌فرض (مثلاً Last 24 hours) لاگی مشاهده نشد، بازه زمانی را به All time یا Real-time تغییر دهید تا مطمئن شوید که log ها در حال دریافت هستند (ممکن است log های اولیه مربوط به زمان‌های گذشته باشند). مشاهده log ها در نتایج جستجو، تأییدی بر موفقیت‌آمیز بودن فرآیند deploy و دریافت data است.

پیکربندی و استفاده از deployment server به همین سادگی و کارایی است. امیدوارم توضیحات ارائه شده مفید و کاربردی بوده باشد. با تشکر.

با ماژول پنجم از دوره Splunk Enterprise Data Administration همراه شما هستیم. در این ماژول، به بررسی stanzaی monitor برای فایل‌ها و directoryها می‌پردازیم. همان‌طور که در ویدیوهای پیشین در خصوص این stanza صحبت شد، در این ویدیو موارد بیشتری درباره آن ارائه خواهد شد.

همان‌طور که می‌دانید، برخی از solutionها یا سرویس‌ها، logهایی را که تولید می‌کنند، در فایل‌هایی ذخیره می‌نمایند. اگر این log fileها به صورت text و خوانا باشند، شما می‌توانید یک input را به گونه‌ای پیکربندی کنید که آن log file را monitor کرده و content موجود در آن log file را خوانده و برای Splunk Enterprise ارسال نماید.

هنگامی که یک input را برای خواندن آن log file پیکربندی می‌کنید، می‌توانید attributeهای index، host و source type را به آن source log، assign نمایید. این عمل موجب می‌شود زمانی که آن log به Splunk Enterprise می‌رسد، این metadataها خوانده شده و مورد استفاده قرار گیرند.

آن log file که سرویس مربوطه logهای خود را در آن ثبت می‌کند، به صورت مداوم در حال update شدن است و logهای جدید آن سرویس در آن نوشته می‌شوند. هنگامی که برای آن فایل، input پیکربندی می‌کنید، با استفاده از stanzaی monitor می‌توانید اطمینان حاصل کنید که اگر log جدیدی در آن log file نوشته شود، برای شما ارسال خواهد شد. همچنین، اگر به هر دلیلی Splunk Forwarder را restart کنید، Splunk Forwarder از آخرین log ارسال شده، شروع به ارسال مجدد data کرده و dataهای جدید را ارسال می‌نماید. تقریباً می‌توان گفت یک checkpoint وجود دارد که مشخص می‌کند log تا کجا خوانده شده است.

یکی از نکات مهم این است که شما می‌توانید تمام فایل‌هایی را که فرمت text دارند (مانند CSV، XML، JSON) و همچنین Log4j، با استفاده از Splunk Forwarder خوانده و به سمت Splunk Enterprise ارسال کنید. حتی این قابلیت نیز وجود دارد که با استفاده از Universal Forwarder یا به طور کلی forwarderهای Splunk، فایل‌های compressed (فشرده) را که حاوی log file هستند، خوانده و برای Splunk Enterprise ارسال نمایید.

قابلیت مهم بعدی که در فایل‌های input قابل استفاده است، monitoring directoryها می‌باشد. یعنی شما می‌توانید directoryهایی را که شامل چندین log file هستند، monitor کنید. آن پیکربندی‌ها، directory را خوانده و محتوای تمام text fileهایی را که تشخیص می‌دهند، برای شما ارسال می‌کنند. اگر در چنین شرایطی، در آن directory فایل zip نیز وجود داشته باشد، تمام فایل‌های موجود در آن فایل zip خوانده شده و برای Splunk Enterprise ارسال می‌شوند. حتی زمانی که یک log file جدید به آن directory اضافه شود، آن log file جدید نیز خوانده و ارسال خواهد شد.

یکی از مهم‌ترین قابلیت‌های موجود در این بخش، تشخیص log file rotation است. اگر log fileای rotate شده و به نحوی archive شود، دیگر محتوای آن log file خوانده نخواهد شد و قطعاً چون data جدیدی در آن log file rotate شده وجود ندارد، هیچ dataای از آن log file ارسال نمی‌گردد. هنگامی که شما تنظیمات مرتبط با monitoring directoryها را انجام می‌دهید، attributeهایی که برای آن تعریف می‌شوند، بر روی تمام فایل‌های موجود در آن directory اعمال می‌گردند.

در ویدیوهای پیشین، ما توسط Splunk Web یک log file را monitor کرده و logهای موجود در آن log file را به سمت Splunk Enterprise ارسال نمودیم و Splunk Enterprise آن‌ها را index کرد. اما در این ویدیو، تمرکز بیشتر بر روی configuration file inputs.conf است تا Splunk Forwarder متوجه شود در مسیر مشخص شده، log fileهایی وجود دارد که باید آن‌ها را باز کرده و بخواند و در صورت ثبت log جدید در آن log fileها، آن را برای Splunk Enterprise ارسال نماید.

attributeهای این stanza در تصویر قابل مشاهده هستند: disabled, source type, host, index, blacklist و whitelist. با بیشتر این موارد در ویدیوهای قبلی آشنا شده‌ایم. اما نکته‌ای که در اینجا مطرح است، این است که هنگامی که شما یک مسیر directory را به stanzaی monitor اختصاص می‌دهید، می‌توانید blacklist و whitelist نیز تعریف کنید تا به Splunk Forwarder مشخص نمایید که در آن directory چه مواردی باید خوانده شوند و چه مواردی نباید خوانده شوند.

نکته دیگر قابل ذکر این است که ما یک stanza به نام monitor داریم و stanza دیگری به نام monitor_no_handle نیز وجود دارد. این دو stanza تفاوت‌هایی با یکدیگر دارند. برای مثال، اگر قصد دارید log fileای را monitor کنید که سیستم عامل به دلیل نوشتن log در آن، اجازه باز کردن آن log file را نمی‌دهد، باید از stanzaی monitor_no_handle استفاده نمایید. این stanzaی monitor_no_handle صرفاً برای سیستم عامل Windows است و در سیستم عامل‌های Linux کاربردی ندارد. در این ویدیو، به تفصیل در خصوص monitor_no_handle صحبت نخواهد شد تا از تداخل احتمالی مطالب جلوگیری شود و تمرکز صرفاً بر روی stanzaی monitor خواهد بود.

نکته‌ای که باید به آن توجه داشت این است که در سیستم عامل‌های مختلف، addressing متفاوت است. همان‌طور که در مثال‌های تصویر مشاهده می‌شود، یک stanzaی monitor نوشته شده است که یک مسیر directory را در سیستم عامل Linux، monitor می‌کند. در stanzaی بعدی، فایلی وجود دارد که در drive C سیستم عامل Windows قرار گرفته است. پس از آن، stanzaی monitor دیگری تعریف شده که مسیر یک directory در Windows برای آن مشخص گردیده است. تمام log fileهای موجود در این مسیر (یعنی drive C، پوشه log) خوانده شده و ارسال می‌شوند. پس از آن نیز، stanzaی monitor دیگری وجود دارد که به یک directory در سطح Linux اشاره می‌کند.

نکته بسیار مهم در addressing این است که شما می‌توانید از star (*) و سه نقطه (...) نیز استفاده نمایید. هنگامی که یک directory را در stanzaی monitoring پیکربندی می‌کنید، می‌توانید در انتهای آن مسیر از سه نقطه (...) استفاده کرده و به Splunk Forwarder مشخص نمایید که اگر در داخل آن directory، directoryهای دیگری نیز وجود داشت، وارد آن directoryها شده و هر log file موجود در آن‌ها را نیز خوانده و ارسال کند. بنابراین، wildcard (...) به directory و subdirectoryها اشاره دارد. شما می‌توانید از (...) در انتهای مسیر یا در یک segment خاص مورد نظر خود استفاده نمایید.

اما wildcard star (*) به Splunk Forwarder این مفهوم را می‌رساند که هر آنچه در مسیری قرار دارد که شما برای آن star (*) تعیین کرده‌اید، باید خوانده شده و برای شما ارسال گردد. از star (*) معمولاً در انتهای مسیر استفاده می‌شود. برای مثال، فرض کنید چندین log file با فرمت‌های مختلف وجود دارد و شما می‌خواهید تمام فرمت‌ها خوانده شوند. در این حالت، می‌توانید از علامت star (*) استفاده کنید تا تمام فرمت‌ها را شامل شده و برای شما ارسال نماید.

در مثالی که در صفحه مشاهده می‌شود، نحوه استفاده از star (*) و سه نقطه (...) نشان داده شده است. در پیکربندی اول، کاملاً مشخص است که به یک log file معین اشاره می‌شود و stanzaی monitor فقط همان log file را خوانده و ارسال می‌کند. در مثال بعدی (مثال دوم)، در انتهای مسیر به جای .log از star (*) استفاده شده است. در این حالت، در مسیر ww1، هر فایلی که نام آن secure باشد، با هر پسوندی، خوانده شده و data برای Splunk Enterprise ارسال می‌شود. این دو مثال به خوبی مفهوم را روشن می‌کنند.

در مثال سوم و مثال پس از آن، در مسیری که به stanzaی monitor داده شده، در segment سوم از star (*) استفاده شده است. سپس به فایلی با نام secure اشاره گردیده که به جای فرمت مشخص، از star (*) استفاده شده است. یعنی در مسیری که با ww شروع می‌شود، data مربوط به log fileهایی که نامشان secure است، خوانده و ارسال می‌گردد. در directory log، چندین directory وجود دارد که نام آن‌ها با ww آغاز می‌شود (ww1 و ww2). پس از آن، فایل‌های متفاوتی با پسوندهای مختلف قرار دارند. هر فایلی که نام آن secure باشد، با هر پسوندی، باز شده، data آن خوانده و ارسال می‌شود.

در مثال آخر، در segment سوم از (...) استفاده شده است. یعنی هر directory موجود در مسیر /var/log باز شده و هر log fileای که نام آن secure است، خوانده شده و محتوای آن برای شما ارسال می‌گردد. به جای پسوند مشخص، از star (*) استفاده شده و در segment سوم، به جای تعیین مسیر، از (...) استفاده گردیده است. بدین ترتیب، تمام log fileهای مورد نظر در این حالت match می‌شوند.

یکی از قابلیت‌ها و attributeهای موجود، مرتبط با whitelist و blacklist است. فرض کنید در یک directory چندین log file وجود دارد. شما نیاز دارید برخی از آن log fileها را به گونه‌ای پیکربندی کنید که محتوایشان ارسال شود، در حالی که به برخی دیگر از logها نیازی ندارید. برای این منظور، می‌توانید از whitelist و blacklist استفاده نمایید.

در مثالی که در صفحه مشاهده می‌شود، یک directory به نام ww1 وجود دارد که شامل چهار log file متفاوت است. با دقت در log fileها، مشاهده می‌شود که پسوند برخی از آن‌ها .log و پسوند برخی دیگر .log.2 است. در مثال اول، نیاز است log fileهایی که پسوندشان صرفاً .log است، خوانده و ارسال شوند. به همین منظور، stanzaی monitor را نوشته، مسیر مورد نظر را وارد کرده و سپس از attribute whitelist استفاده می‌کنیم.

اگر قصد استفاده از این attribute را دارید، مقداری که به آن assign می‌کنید باید در قالب regex باشد و لازم است regex مرتبط با فایل‌ها را از پیش نوشته باشید. regex در مثال مشاهده شده، بسیار ساده است. در regexای که به whitelist مثال اول assign شده است، ابتدا backslash dot (\.)، سپس کلمه log و پس از آن dollar sign ($) قراردارد. اگربا regex آشنایی داشته باشید، می‌دانیدکه dollarsign در اینجا، انتهای string را مشخص می‌کند و به whitelist این مفهوم را می‌رساند که انتهای نام فایل‌هایی که باید خوانده شوند، باید .log باشد و نه چیز دیگر.

در مثال بعدی، log fileهای موجود هر کدام نامی دارند و سه مورد از آن‌ها پسوند .log دارند. این whitelist از دو بخش تشکیل شده که این دو بخش توسط یک bar عمودی (|) از یکدیگر جدا شده‌اند و در اینجا، معنی و مفهوم آن OR است. در بخش اول، مجدداً regex ساده‌ای مشاهده می‌شود. regexای نوشته شده است که به فایل‌هایی با نام query.log اشاره می‌کند و پس از آن، به log fileهایی با نام my.log اشاره دارد. خروجی این whitelist، سه log file با نام‌های query.log، dbquery.log و my.log خواهد بود. همان‌طور که مشخص است، log file dbquery.log نیز به دلیل کلی بودن regex تعریف شده، جزو whitelist قرار گرفته و محتوای موجود در این log file نیز خوانده می‌شود. اگر بخواهیم آن را به فایل‌هایی با نام دقیق query.log محدود کنیم، باید حتماً از علامت slash (/) قبل از نام query استفاده نماییم که نشان‌دهنده شروع string است و پایان string نیز با علامت dollar sign ($) مشخص می‌گردد.

در مثال سوم که خروجی نهایی و مورد نظر این مثال را نشان می‌دهد، مشاهده می‌کنیم که دو log file مورد نظر match شده و در نهایت، همین دو log file خوانده شده و محتوای آن‌ها ارسال می‌گردد.

شماره گذاری segmentها

پیش‌تر در خصوص فیلد host توضیح داده شد که هنگام ایجاد یک input، می‌توان نام host را که جزو fieldهای اصلی است، به روش‌های مختلفی انتخاب نمود. می‌توان نام را به صورت static نوشت، از regex استفاده کرد یا از شماره segmentها بهره برد. کاربرد این قسمت چیست؟ کاربرد آن زمانی است که شما log fileهایی را از روی یک server می‌خوانید که متعلق به serverهای دیگری هستند و نام directoryهایی که stanzaی monitor قرار است آن‌ها را خوانده و فایل‌های درونشان را ارسال کند، مطابق با نام hostهای مورد نظر است.

در چنین حالتی، فرض کنید مسیری به نام /var/log وجود دارد که شامل سه directory به نام‌های ww1 تا ww3 است و شما می‌خواهید نام directoryهایی را که با w شروع می‌شوند، به عنوان host در نظر بگیرید. در این حالت، هنگامی که stanzaی monitor را پیکربندی کرده و مسیر مورد نظر (یعنی /var/log) را به آن assign می‌کنید، segment سوم دقیقاً نام directoryهای مورد نظر شما خواهد بود. شما در این سناریو می‌توانید از attribute host_segment استفاده کرده و value سه را به آن اختصاص دهید تا segment سومی که در مسیر وجود دارد، به عنوان نام host در نظر گرفته شود.

fishbucket   

یکی از مهم‌ترین مفاهیمی که یک Splunk Admin باید بداند، fishbucketها هستند. fishbucketها این قابلیت را به Splunk می‌افزایند که بتواند input fileهایی را که monitor شده و محتوای آن‌ها در حال ارسال است، track کند و با تنظیم checkpointها، مشخص نماید که data تا کجا خوانده و ارسال شده است. fishbucketها حاوی file metadataهایی هستند که هر کدام از آن‌ها، pointerی را به فایل‌ها مشخص می‌کند. آن pointer یا checkpoint، آخرین موقعیتی را نشان می‌دهد که Splunk از آن input، داده خوانده و ارسال کرده است.

توجه داشته باشید که fishbucketها بر روی تمام instanceهای Splunk وجود دارند. اگر بخواهید data مرتبط با fishbucketها را مشاهده کنید، باید به مسیر Splunk DB (مکانی که Splunk data خود را ذخیره می‌کند) مراجعه نمایید؛ در آنجا یک directory به نام fishbucket وجود دارد.

با توجه به وجود fishbucketها، هنگامی که شما یک input را تغییر می‌دهید، آن تغییر فقط موجب می‌شود که تغییرات شما بر روی dataهای جدید اعمال شود و هیچ تغییر یا re-indexی بر روی dataهای قدیمی شما رخ نمی‌دهد. اگر بخواهید re-index انجام دهید و dataها را از یک مبدأ مجدداً خوانده و ارسال کنید، لازم است ابتدا data قدیمی موجود بر روی indexer را پاک نمایید. سپس input را تغییر داده و پس از آن، fishbucketهای موجود را restart کنید (این restart به دو روش قابل انجام است) و در نهایت Splunk Forwarder خود را restart نمایید.

فقط توجه داشته باشید که این عمل موجب از دست رفتن dataهای قدیمی شما می‌شود و معمولاً Splunk Adminها این کار را انجام نمی‌دهند. اگر قصد re-index کردن data را دارید، بهتر است index قبلی را حفظ کرده و index جدیدی برای آن در نظر بگیرید. سپس می‌توانید input را change کرده، fishbucket را پاک و پس از آن Splunk Forwarder را restart کنید.

به طور کلی، از انجام اقداماتی که منجر به حذف data می‌شوند، خودداری کنید. اگرچه در این ویدیوها به برخی از این موارد اشاره می‌شود، اما اگر سابقه زیادی در کار با Splunk ندارید، اکیداً توصیه می‌شود جوانب احتیاط را رعایت فرمایید. برای restart کردن fishbucket، می‌توانید از command نشان داده شده در تصویر استفاده نمایید یا به طور کلی directory fishbucket را حذف کنید. پس از انجام این کار، حتماً لازم است Splunk را یک بار restart نمایید. هنگامی که این عمل را انجام می‌دهید، تقریباً Splunk را force می‌کنید تا تمام فایل‌هایی که monitor شده‌اند، re-index شوند و data آن‌ها مجدداً جمع‌آوری گردد. این کار دارای side effect قابل توجهی بوده و با مطالب دیگر نیز هم‌پوشانی دارد. بنابراین، توصیه می‌شود از انجام این کار خودداری کرده و صرفاً از وجود چنین امکانی مطلع باشید.

TA Linux

در بخش عملی، به بررسی TA Linux پرداخته می‌شود. هنگامی که قصد جمع‌آوری logهای سیستم عامل‌های Linux را دارید، این TA می‌تواند بسیار مفید واقع شود. همچنین، زمانی که نیاز است logهای Linux، parse شده، fieldهای آن extract گردند، tag بخورند و knowledge objectهای آن با CIM compatible باشند، این TA بسیار کاربردی است.

هنگامی که این TA را از Splunkbase دانلود می‌کنید، می‌توانید package آن را بر روی search headهای خود نصب نمایید. این عمل موجب می‌شود fieldهای data لینوکسی شما extract شده و بتوانید از آن fieldها استفاده کنید. همچنین، شما می‌توانید از این TA برای جمع‌آوری log نیز استفاده نمایید. با باز کردن این package و بررسی directoryهای موجود در آن، مشاهده می‌شود که directoryهای bin، default و lookup وجود دارند، اما directory local موجود نیست.

اگر بخواهید به وسیله deployment server خود، logهای مرتبط با Linux را جمع‌آوری کنید، کافی است ابتدا package دانلود شده از Splunkbase را extract کرده، همین directory را در مسیر deployment-apps مربوط به Splunk Deployment Server خود قرار دهید و پس از اعمال تغییرات لازم، آن را بر روی deployment clientهای خود deploy نمایید.

چه تغییراتی باید انجام شود و چه اقداماتی لازم است؟ ابتدا، یک directory به نام local ایجاد کرده و سپس از directory default، configuration file inputs.conf را به داخل directory local، copy می‌کنید. پس از انجام عمل copy، نوبت به ویرایش configuration inputs.conf (که وظیفه اصلی آن جمع‌آوری log است) متناسب با نیازهایتان می‌رسد. سپس، کل آن TA را بر روی سیستم عامل‌های Linuxی که قصد جمع‌آوری log از آن‌ها را دارید، deploy می‌کنید. در ادامه، این فایل باز شده و تحلیل می‌شود.

با باز کردن فایل، با یک configuration file مواجه می‌شوید. ابتدا باید موارد مورد نیاز خود را enable کنید. اگر نیاز دارید log fileهای مرتبط با هر stanza در یک index خاص ذخیره شوند، باید از attribute index استفاده کرده و نام index را در اینجا وارد نمایید.

بنابراین، به طور خلاصه، هر stanzaی مورد نیاز را enable کرده و نام index را به آن assign می‌کنید. اولین stanza قابل مشاهده، مربوط به یک script است که در مسیر bin داخل TA قرار دارد. اجرای این script منجر به تولید خروجی‌هایی می‌شود. اگر به آن خروجی‌ها نیاز دارید، باید این stanza را فعال کرده و مشخص کنید که خروجی در کدام index ذخیره شود.

در چند stanzaی اول، scriptهایی وجود دارند که در مسیر bin این TA قرار گرفته‌اند. اما این scriptها چه هستند و چه کاربردی دارند؟ موضوع این است که شما باید سطح مشخصی از data را از سیستم‌های Linux خود جمع‌آوری نمایید. تمام logهای مورد نیاز یک Security Operations Center (SOC) یا ماژول Splunk Enterprise Security (ES) به صورت پیش‌فرض در سیستم عامل‌ها وجود ندارند. لازم است روشی برای ایجاد آن logها و سپس استفاده از آن‌ها وجود داشته باشد.

یکی از روش‌های ایجاد آن logها، همین scriptهایی هستند که در TAها وجود دارند. این TAها اصطلاحاً CIM compatible هستند و تلاش شده است تا بیشتر dataهای مورد نیاز، ابتدا ایجاد و سپس ارسال شوند. برای این ایجاد data نیز به این scriptها نیاز است. پس از فعال‌سازی و انتخاب این scriptها، نوبت به بخش‌هایی مانند /var/log می‌رسد که در سیستم عامل وجود دارد و با استفاده از stanzaهایی مانند monitor، مسیرها خوانده شده و log مورد نظر ارسال می‌گردد.

تا این مرحله، باید قادر به تحلیل آسان این stanzaهای monitor باشید. stanzaی اول که disabled است، مسیر /Library و پس از آن مسیر /log را monitor می‌کند و هر log موجود در این مسیر را، در صورتی که disabled نباشد، برای شما ارسال می‌نماید.

stanzaی بعدی مربوط به /var/log است که مهم‌ترین پوشه log در سطح سیستم عامل Linux محسوب می‌شود. whitelist و blacklist برای آن تعریف شده‌اند. پس از آن نیز مسیر دیگری به نام /adm وجود دارد که برخی logها در این مسیر نیز ذخیره می‌شوند.

اما در بخش بعدی، directory /etc لینوکس monitor شده است. در این stanza، whitelistی تعریف گردیده که بر اساس آن، فایل‌های configuration, .ini و .profile خوانده شده و برای Splunk Enterprise ارسال می‌شوند. همان‌طور که پیش‌تر اشاره شد، برخی از dataهای دریافتی از نوع configuration هستند. این مورد نیز مثالی از آن نوع data است. اهداف مختلفی می‌تواند برای این کار وجود داشته باشد. یکی از اهداف این جمع‌آوری configuration، مسئله configuration management است. همچنین، تشخیص تغییراتی که در سطح سیستم عامل رخ می‌دهد نیز از دیگر اهداف است. اگر در یک SOC قصد دارید logهای مناسبی از سطح سیستم عامل‌ها جمع‌آوری کنید، توصیه می‌شود این مورد را نیز، در صورت داشتن plan مشخص، enable نمایید.

بخش بعدی که monitor برای آن تعریف شده، bash_history است. در یک سیستم عامل Linux، احتمالاً افراد مختلفی login کرده و commandهای گوناگونی اجرا می‌کنند. در یک SOC، لازم است مشخص شود در سطح user چه commandهایی در حال استفاده است. با دانستن این موضوع، می‌توان malicious commandها را تشخیص داده و alert صادر نمود. مجدداً در ادامه، scriptهایی وجود دارند که بسته به نیاز، باید آن‌ها را فعال کرده و استفاده نمود.

با ماژول ششم از دوره Splunk Enterprise Data Administration در خدمت شما هستیم. در این ماژول، به بررسی ایجاد input های networkی و input هایی که script اجرا می‌کنند، خواهیم پرداخت.

در ویدئوی قبلی، نحوه ایجاد یک input از نوع networkی از طریق Splunk Web آموزش داده شد. همانطور که به خاطر دارید، پس از انتخاب نوع input (TCP یا UDP)، در صفحه پیکربندی، ابتدا شماره port و سپس، در صورت نیاز به override کردن نام source، نام source مورد نظر وارد می‌شد. پس از آن، فیلدی وجود داشت که در صورت نیاز به محدود کردن input به یک source خاص، امکان وارد کردن آدرس آن source فراهم بود. اگر در این قسمت مقداری وارد نشود، input قادر خواهد بود data را از تمام source های ارسال‌کننده بر روی آن port دریافت کند.

پیش‌تر در خصوص برخی از پیکربندی‌های سطح فایل inputs.conf نیز صحبت شد. اگر نیاز به پیکربندی network input از طریق فایل inputs.conf باشد، پیکربندی‌های مورد نظر در تصویر قابل مشاهده است. ابتدا باید از stanza ی UDP یا TCP استفاده کرده و در آن stanza، IP host  و port را وارد نمود. اگر در این قسمت IP host وارد نشود و فقط port مشخص گردد، آن input دیگر به IP خاصی محدود نخواهد بود و تمام IP هایی که بر روی آن port، log  ارسال می‌کنند، توسط این input ، handle خواهند شد.

در مثال ارائه شده، stanza ی UDP، port 514 را باز کرده و قادر است log را از تمام تجهیزات بر روی این port دریافت کند. پس از آن، connection_host و sourcetype نیز assign شده‌اند. در مثال بعدی، از stanza ی TCP استفاده شده که یک IP:Port به آن اختصاص داده شده و همچنین attribute source نیز پیکربندی گردیده است. قابلیت‌های دیگری نیز در attribute ها وجود دارد که مرتبط با queue ها هستند و در ادامه به آن‌ها پرداخته خواهد شد.

در تنظیمات سطح web، قسمتی با عنوان host وجود داشت که امکان وارد کردن host به صورت custom و درج نام host مورد نظر را فراهم می‌کرد. این مورد از طریق attribute connection_host و attribute host در سطح configuration کنترل می‌شود. اگر هدف، تعیین نام host مبتنی بر DNS باشد، باید attribute connection_host را برابر با dns قرار داد. اگر هدف، تعیین بر اساس IP باشد، value آن باید ip باشد. اگر قصد وارد کردن نام host به صورت دستی وجود داشته باشد، attribute connection_host باید بر روی none تنظیم شده و attribute host برابر با نام مورد نظر قرار گیرد.

زمانی که پیکربندی stanza ی UDP یا TCP به گونه‌ای انجام می‌شود که به هیچ IP محدود نگردد، این امر می‌تواند خطرات امنیتی به همراه داشته باشد. اما attributeی با نام acceptFrom وجود دارد که با استفاده از آن می‌توان مشخص کرد Splunk forwarder از چه IP هایی log دریافت کند. در واقع، از این طریق می‌توان یک ACL (Access Control List) تعریف نمود. در این attribute می‌توان حتی از wildcard هایی مانند * (ستاره) و! (علامت تعجب) نیز استفاده کرد. در مثال نمایش داده شده، acceptFrom برابر با! (نقیض) یک IP خاص و همچنین! یک رنج IP (با فرمت CIDR) قرار داده شده است. با استفاده از علامت , (کاما) می‌توان موارد بیشتری مانند رنج شبکه، DNS name یا single IP و موارد دیگر را نیز اضافه نمود. بنابراین، با استفاده از این attribute می‌توان از دریافت log های تجهیزات و source های اضافه جلوگیری کرد.

Queue

هنگام ایجاد یک network input، queue هایی وجود دارند که به کنترل input flow ایجاد شده کمک می‌کنند. همانطور که در تصویر مشاهده می‌شود، input ورودی ابتدا وارد یک memory queue شده و سپس به یک output queue منتقل می‌شود. این queue ها زمانی فعال می‌شوند که input از نوع TCP، UDP یا script باشد. این سازوکار باعث می‌شود Splunk Enterprise بتواند حجم بالای data را کنترل کرده و data را به صورت کنترل‌شده به سمت indexer ها ارسال نماید. اگر indexer ها در دسترس نباشند، دچار مشکل شوند یا بار کاری زیادی داشته باشند و نتوانند data را به موقع پردازش کنند، data ابتدا در output queue ذخیره می‌شود. اگر این queue نیز پر شود، data در memory queue ذخیره خواهد شد. در صورت پر شدن memory queue نیز، data در queue جدیدی به نام persistent queue ذخیره می‌گردد. persistent queue بر روی hard disk قرار دارد و dataی که به آن ارسال می‌شود، بر روی disk نوشته می‌شود. به همین دلیل، زمانی که Splunk restart می‌شود، هر dataیی که در persistent queue وجود داشته باشد، حفظ شده و تغییری نمی‌کند.

دو attribute مهم مرتبط با queue ها وجود دارد که می‌توان در پیکربندی inputs.conf برای stanza های TCP، UDP و script از آن‌ها استفاده کرد:

queueSize: این attribute مرتبط با memory queue است و به صورت پیش‌فرض مقدار آن 500 KB (کیلوبایت) پیکربندی شده است. این یکی از بهترین queue ها برای اهداف buffering data قبل از ارسال محسوب می‌شود. زمانی که indexer، data ها را با سرعت کمتری نسبت به forwarder دریافت می‌کند، این queue نقش مهمی در جلوگیری از دست رفتن data ایفا می‌کند.

persistentQueueSize: این attribute مرتبط با persistent queue است که بر روی hard disk قرار دارد. به صورت پیش‌فرض، این attribute پیکربندی نشده است و برای استفاده از این queue، باید این attribute را پیکربندی نمود. persistent queue در واقع یک file system buffering از data را برای Splunk Enterprise فراهم می‌کند که برای data های حجیم یا network هایی که پایداری (stability) لازم را ندارند، بسیار مفید است.

در ویدئوهای قبلی، در خصوص wait queue توضیح داده شد. queue دیگری نیز با نام output queue وجود داشت. برای پیکربندی attribute مرتبط با آن، می‌توان از attribute maxQueueSize در فایل پیکربندی outputs.conf استفاده کرد. همانطور که پیش‌تر توضیح داده شد، اگر attribute useACK برابر با false باشد، output queue برابر با 500 KB و اگر attribute useACK برابر با true باشد، output queue برابر با 7 MB (مگابایت) خواهد بود (شرایط دیگری نیز وجود داشت که در آن ویدئو به آن‌ها پرداخته شد).

در این دوره، چندین بار به input هایی اشاره شد که منجر به اجرای script می‌شوند. در پیکربندی‌های input Splunk، قسمتی با عنوان script وجود دارد. به وسیله این قابلیت، می‌توان script هایی را که قبلاً توسعه داده شده‌اند، اجرا کرده و خروجی آن‌ها را به عنوان event ذخیره نمود. به عنوان مثال، چندین script در سطح Linux و در TA Linux مشاهده شد که امکان ذخیره خروجی آن‌ها به عنوان log وجود داشت. بنابراین، احتمالاً app ها و TA های دیگری نیز وجود دارند که حاوی script های متفاوتی هستند و می‌توان از آن‌ها استفاده کرد. script ها را می‌توان با زبان‌هایی مانند Python، PowerShell و Shell نوشت و آن‌ها را در تنظیمات input قرار داد تا Splunk به صورت زمان‌بندی شده آن‌ها را اجرا کرده و خروجی را index نماید.

نکته قابل توجه این است که script های ایجاد شده حتماً باید در یکی از مسیرهای زیر قرار داشته باشند:

• $SPLUNK_HOME/bin/scripts
• در directory bin مربوط به app های مختلف
• در مسیر /etc/system/bin

پس از توسعه script، ضروری است قبل از انتقال آن به یکی از این directory ها، آن را تست کرده و از داشتن خروجی اطمینان حاصل نمود. به عنوان مثال، یک script از پیش توسعه داده شده و در directory bin مربوط به app search قرار گرفته است. برای تست script می‌توان به وسیله خود Splunk و دستورات آن، script را تست کرده و خروجی آن را مشاهده نمود. کافی است به مسیر bin Splunk رفته، از دستور splunk استفاده کرده، سپس کلمه کلیدی cmd را به کار برده و پس از آن، آدرس script را وارد نمود. پس از اجرای این دستور، خروجی آن قابل مشاهده خواهد بود. همین خروجی می‌تواند توسط Splunk  ایندکس شود.

در قسمت بعدی، حتماً یک script به عنوان input از طریق Splunk Web به Splunk اضافه شده و خروجی آن مشاهده خواهد شد. اما برای بررسی پیکربندی‌های مرتبط با inputs.conf، ابتدا stanza ی script وجود دارد که مسیر script باید در آن وارد شود. پس از آن، attribute passAuth قرار دارد که اگر script نیاز به سطح دسترسی user خاصی داشته باشد، می‌توان user مربوطه را به وسیله این attribute وارد کرد. در انتها، attributeی به نام interval وجود دارد که می‌توان فواصل زمانی اجرای script را از طریق آن تنظیم نمود.

می‌توان از قسمت Setting وارد Data Input شده و سپس Script را انتخاب کرد تا تمام script هایی که بر روی Splunk Enterprise تنظیم شده‌اند، مشاهده گردند. برای اضافه کردن یک input از نوع script، script مورد نظر قبلاً به directory bin app search منتقل و کپی شده است. پس از کپی کردن script، می‌توان تنظیمات را انجام داد.

بر روی New کلیک می‌کنیم. در قسمتی که باز می‌شود، مسیر script را انتخاب کرده و سپس script مورد نظر را انتخاب می‌نماییم.

در قسمت command، یک command به صورت پیش‌فرض نمایش داده می‌شود. بسته به نوع script، در صورت نیاز به تغییر، این قسمت باید ویرایش شود.

در قسمت بعد، باید interval را وارد کرده و مشخص نمود که script هر چند وقت یکبار اجرا شود. این عدد بر روی 20 تنظیم می‌شود.

سپس بر روی Next کلیک می‌کنیم. با پیکربندی‌های این قسمت آشنا هستید. پیکربندی‌های مورد نظر را انجام می دهیم.

پس از انجام پیکربندی‌ها، بر روی دکمه Review کلیک کرده و در نهایت Submit را انتخاب می‌کنیم. پس از submit شدن تنظیمات، می‌توان بر روی دکمه Start Searching کلیک کرد تا به منوی search رفته و خروجی مرتبط نمایش داده شود.

تا زمان انجام search، در app search و در قسمت local، تنظیمات input بررسی می‌شود. همانطور که مشاهده می‌شود، تنظیمات مورد نظر در پیکربندی inputs.conf انجام شده و می‌توان از آن استفاده کرد یا آن را تغییر داد.

همانطور که در خروجی نیز قابل مشاهده است، script مورد نظر هر 30 ثانیه یکبار اجرا شده و خروجی آن index می‌شود.

می‌توانستیم همین script را در Universal Forwarder کپی کرده و تنظیمات inputی که مشاهده شد را به عنوان یکی از input های Universal Forwarder پیکربندی نماییم که در این صورت، خروجی مورد نظر به Splunk Enterprise ارسال شده و مطابق با index مشخص شده، index می‌گردید.

با ماژول هفتم از دوره Splunk Enterprise Data Administration همراه شما هستیم. در این ماژول، به بررسی Windows Input ها و همچنین ارائه توضیحاتی در خصوص HEC یا HTTP Event Collector پرداخته خواهد شد.

پیش از توضیح در مورد Windows، لازم به ذکر است که در این سیستم‌عامل، log ها به صورت کلی با فرمت باینری ذخیره می‌شوند. شما به راحتی می‌توانید پس از نصب Universal Forwarder، انواع مختلف input type را پیکربندی کرده و log مد نظر خود را ارسال نمایید. در سطح Windows و در Event Viewer، چندین channel مختلف وجود دارد که امکان مشاهده log های Windows را فراهم می‌کنند. اگر از سرویس‌های مایکروسافتی استفاده می‌کنید، به احتمال زیاد آن service دارای یک channel اختصاصی در Event Viewer است که log های خود را در آنجا ثبت می‌کند. برخی سرویس‌های مایکروسافتی مانند DHCP و DNS، log هایی دارند که در file نوشته می‌شوند و برای ارسال آن‌ها، تعریف input از نوع monitor ضروری است.

به طور کلی، در سطح Windows چندین input type متفاوت وجود دارد. نوع اول، Event Log است که پیش‌تر به آن اشاره شد و دقیقاً معادل همان channel های Event Viewer است. مورد بعدی، Performance است که عملکرد کلی system را اندازه‌گیری کرده و log هایی تولید می‌کند که قابل جمع‌آوری هستند. همچنین، اگر از Active Directory در Windows استفاده می‌کنید، می‌توانید به سادگی تغییرات Active Directory را monitor کرده و log های مرتبط با آن را جمع‌آوری نمایید. Registry نیز وجود دارد که با استفاده از Universal Forwarder می‌توان تغییرات آن را پایش کرد. Log های دیگری مانند Host، Network و Printer نیز موجود هستند؛ log های مرتبط با Host شامل اطلاعاتی درباره Windows Server شماست و log های Network اطلاعاتی در خصوص فعالیت‌های شبکه آن Windows Server را ارسال می‌کنند. همچنین امکان پایش فعالیت‌های مرتبط با Print Server ویندوزی نیز وجود دارد.

انجام تمام موارد ذکر شده به سادگی امکان‌پذیر است و در همین ویدیو، پیکربندی‌های مرتبط با آن‌ها شرح داده خواهد شد. بر اساس input type های مختلف، stanza های گوناگونی وجود دارند. زمانی که Universal Forwarder را نصب می‌کنید، در UI نصب می‌توانید برخی از این stanza ها را مستقیماً پیکربندی نمایید. پس از نصب، فایل configuration به نام inputs.conf پیکربندی شده و log های مرتبط را ارسال می‌کند. در سمت راست تصویر، stanza های مرتبط با input type های مختلف Windows نمایش داده شده‌اند که می‌توانید از آن‌ها برای جمع‌آوری log مد نظرتان استفاده کنید.

مواردی که تا اینجا توضیح داده شد، در انتهای ویدیو به صورت عملی مجدداً تشریح شده و پیکربندی‌های مرتبط نمایش داده خواهد شد. اما پیش از ورود به بخش عملی، آشنایی با HTTP Event Collector یا HEC ضروری است. HEC یک input از نوع token-based است که بر پایه پروتکل‌های HTTP و HTTPS عمل کرده و به صورت secure و scalable کار می‌کند. به وسیله HEC، می‌توانید event های خود را بدون نیاز به forwarder مستقیماً به سمت Splunk ارسال کنید. این قابلیت به‌خصوص در محیط‌های distributed، multi-model یا هنگام دریافت log از سیستم‌های قدیمی بسیار مفید است و HEC می‌تواند به راحتی به شما در دریافت log مد نظرتان در این محیط‌ها کمک کند.

لازم به ذکر است که HEC در محیط‌های cloud کاربرد فراوانی دارد و سازمان‌هایی که از Splunk Cloud استفاده می‌کنند، معمولاً log های خود را از طریق HEC به Splunk Cloud ارسال می‌نمایند. بسته به معماری پیاده‌سازی شده Splunk در محیط شما، HECرا می‌توان به روش‌های مختلفی پیاده‌سازی کرد:

1. یک  Indexer :  HEC روی همان indexer پیکربندی شده و log را دریافت می‌کند.
2. Heavy Forwarder  و چند  Indexer :  HEC روی یک heavy forwarder پیکربندی می‌شود.  Log ابتدا به heavy forwarder ارسال شده و سپس توسط آن به سمت indexer ها هدایت می‌شود.
3. چند Indexer و  Load Balancer :  HEC روی تمام indexer ها پیکربندی می‌شود. یک load balancer قبل از آن‌ها قرار گرفته، log ها را دریافت و بین indexer ها توزیع می‌کند.
4. چند Heavy Forwarder، Load Balancer  و چند  Indexer :  HEC روی چندین heavy forwarder  پیکربندی می‌شود. یک load balancer قبل از heavy forwarder ها قرار گرفته، log ها را دریافت و بین آن‌ها توزیع می‌کند. سپس heavy forwarder ها log های دریافتی را به سمت indexer ها ارسال می‌نمایند و indexer ها Log را ذخیره می کنند.

در قسمت عملی، ابتدا به input type های Windows پرداخته می‌شود. برای افزایش کاربرد عملی مباحث، توضیحات بر اساس TA مربوط به Windows که در Splunkbase موجود است، ارائه می‌گردد. استفاده از این TA در محیط‌های واقعی رایج است، زیرا امکان جمع‌آوری log های بیشتر و با کیفیت‌تری را فراهم می‌کند. این log ها CIM compatible هستند و برخی موارد و stanza های موجود در input این TA، از نیازمندی‌های ماژول ES محسوب می‌شوند؛ بنابراین جمع‌آوری آن‌ها برای عملکرد بهتر ES ضروری است.

پس از دانلود این TA، مشابه TA ی Linux، باید یک directory به نام local ایجاد کنید. سپس فایل inputs.conf پیش‌فرض را به این دایرکتوری کپی کرده و موارد مد نظر خود را در آن تغییر دهید. در نهایت، این TA را از طریق Deployment Server روی سیستم‌های Windows مورد نظر deploy کنید. نکته مهم این است که اگر در معماری سازمان شما، Universal Forwarder ها log را مستقیماً به indexer ها ارسال می‌کنند، استفاده از این TA ها و جمع‌آوری log از طریق آن‌ها اکیداً توصیه می‌شود. این موضوع به فاز parsing مربوط می‌شود که Universal Forwarder به صورت محدود در Windows انجام می‌دهد. دقت کنید فاز parsing در Universal Forwarder تنها برای Windows وجود دارد و طی آن، یک سری metadata به داده‌های Windows اضافه می‌شود.

اکنون، directory با نام local ایجاد شده، فایل inputs.conf به آن منتقل و محتوای آن بررسی می‌شود. همانطور که در فایل inputs.conf مشاهده می‌شود، stanza های مختلفی وجود دارند. برای فعال‌سازی، باید channel های مد نظر را انتخاب کرده و برای هر کدام، attribute با نام disabled را برابر با صفر قرار دهید و نام index مورد نظر را نیز مشخص کنید. Channel های Application، System و Security از مهم‌ترین‌ها هستند و معمولاً در اکثر سازمان‌ها جمع‌آوری می‌شوند. برای channel مربوط به Security، همانطور که مشخص است، blacklist هایی تعریف شده که مانع ارسال برخی log ها می‌شود. روش تعریف آن با استفاده از کلمه کلیدی blacklist است. Stanza های مربوط به Event Log با WinEventLog شروع می‌شوند و به channel های Event Viewer اشاره دارند. Attribute با نام start_from با مقدار پیش‌فرض oldest تعیین می‌کند که جمع‌آوری log از قدیمی‌ترین مورد آغاز شود. Attribute مهم دیگر renderXML است؛ اگر مقدار آن true باشد، log ها با فرمت XML ارسال می‌شوند که خوانایی بهتری دارند.

در ادامه این TA، توضیحاتی برای سرویس‌های مختلف ارائه شده است. با مطالعه آن‌ها می‌توانید متوجه شوید هر stanza مربوط به کدام سرویس است. برای مثال این stanza ایی که در تصویر مشاهده می کنید مرتبط با سرویس dfs است و اگر این سرویس و این چنل eventlog در event viewer وجود داشته باشد می توانید لاگ های آن را جمع آوری کنید. Stanza هایی نیز برای log های DNS و DHCP وجود دارند. Log های DHCP معمولاً در یک file ذخیره می‌شوند که مسیر آن با استفاده از stanza ی monitor در این input مشخص شده است. اگر سرویس DHCP فعال است، می‌توانید از این stanza برای جمع‌آوری log های آن استفاده کنید.

بخشی نیز به Windows Update log اختصاص دارد که دارای چندین stanza است. توضیحات مربوط به هر کدام را مطالعه کرده و بر اساس نیاز، stanza های مورد نظر را با تنظیم disabled=0 فعال کنید. Stanza ای نیز برای جمع‌آوری log های DNS که به صورت file ذخیره می‌شوند، وجود دارد. در این مورد از monitor_no_handle استفاده شده است؛ زیرا زمانی که سرویس DNS لاگ هایش را در این فایل می نویسد سیستم عامل به صورت پیش فرض file را قفل می کند و اجازه خواندن آن با روش عادی امکان‌پذیر نمی باشد. به همین دلیل باید از stanza ی monitor_no_handle استفاده کنیم.

پس از این موارد، script ها قرار دارند که نحوه عملکرد آن‌ها پیش‌تر توضیح داده شده است. این script ها log های مهمی (مانند log های مربوط به sync بودن time که برای dashboard های ES کاربرد دارد) را جمع‌آوری می‌کنند. Input های مرتبط با PowerShell نیز وجود دارند که با استفاده از stanza ی powershell تعریف می‌شوند. در این stanza ها می‌توانید script های PowerShell قرار دهید تا در فواصل زمانی معین اجرا شده و خروجی آن‌ها index شود. عملکرد stanza ی powershell مشابه stanza ی script است، با این تفاوت که آن script در attribute مربوطه (script) نوشته می‌شود. همان طور که می بینید stanza ی powershell متفاوت دیگری هم وجود دارد.

در ادامه، به قسمت Host Monitor با stanza ی WinHostMon می‌رسیم. موارد دیگری مانند WinPrintMon (برای مانیتور پرینتر) و WinNetMon (برای مانیتور ترافیک شبکه inbound و outbound) نیز وجود دارند. Stanza ی PerfMon امکان جمع‌آوری performance counter ها (مانند CPU, Disk, RAM و...) را فراهم می‌کند. استفاده از تمام این stanza ها مشابه است؛ کافیست disabled را برابر صفر قرار داده و index مناسب را تعیین کنید.

در انتهای فایل، stanza های admon (برای مانیتور Active Directory) و WinRegMon (برای مانیتور تغییرات Registry) قرار دارند. WinRegMon به صورت پیش‌فرض برای مانیتور سه مسیر مهم در رجیستری پیکربندی شده است که می‌توانید از آن استفاده کنید.

در بخش پایانی، نحوه پیکربندی HEC (HTTP Event Collector) شرح داده می‌شود. از منوی Settings وارد Data Input شده و HTTP Event Collector را انتخاب کنید. ابتدا در بخش Global Settings، با کلیک روی Enable، قابلیت HEC را فعال کنید. در اینجا می‌توانید تنظیمات پیش‌فرض مانند sourcetype، index، output group، فعال/غیرفعال کردن SSL و port مورد استفاده (پیش‌فرض 8088) را مشخص کنید. پس از تنظیم و ذخیره (Save)، باید یک token جدید ایجاد کنید.

لازم به یادآوری است که HEC باید در سمت ارسال‌کننده نیز پشتیبانی شود. Solution هایی مانند محصولات ManageEngine معمولاً از این متد پشتیبانی می‌کنند. برای ارسال log از Universal Forwarder ها از طریق HEC نیز تنظیمات خاصی در سمت Forwarder مورد نیاز است.

برای ایجاد token در Splunk Enterprise، پس از فعال‌سازی Global Settings، روی New Token کلیک کنید. در فرم ایجاد token، نام (Name) را مشخص کنید. گزینه مهم Enable indexer acknowledgement است که با فعال کردن آن، ارسال‌کننده منتظر تایید دریافت و index شدن داده توسط Splunk می‌ماند تا از miss شدن log جلوگیری شود. پس از دریافت تاییدیه، متوجه می شود که داده ایندکس شده و آن را دیگر ارسال نمی کند و آن را از حافظه release می کند. اینجا به صورت پیش فرض یک configuration انجام می دهیم. در صفحه بعد که تنظیمات آن برای شما آشنا است باید sourcetype و index را برای داده‌های دریافتی از این token مشخص کنید. پس از Review و Submit، یک token به شما نمایش داده می‌شود. این token باید در اختیار ارسال‌کننده قرار گیرد تا بتواند داده‌ها را به این HEC endpoint ارسال کند. شما باید داده‌های ارسالی را روی port مشخص شده در Global Settings دریافت کنید. برای مشاهده یا مدیریت token های ایجاد شده، می‌توانید مجدداً به بخش Settings > Data Inputs > HTTP Event Collector مراجعه کنید.

با ماژول هشتم از دوره Splunk Enterprise Data Administration در خدمت شما هستیم. در این ماژول، مفاهیمی در خصوص default processing که طی فاز input اتفاق می‌افتد، بیشتر بررسی خواهد شد و همچنین به پیکربندی‌های option هایی که در فاز input وجود دارد، پرداخته می‌شود.

همانطور که در ویدئوهای قبلی اشاره شد، در فاز input، مجموعه‌ای از metadata ها مانند host، sourcetype، source و index بر روی data اعمال می‌شوند. پس از آن، در فاز parsing، مجموعه‌ای از عملیات وجود دارد که بسته به نوع پیکربندی، بر روی data انجام می‌گیرند. زمانی که data از فاز input به فاز parsing وارد می‌شود، قطعاً دو مرحله  line breaking و timestamp extraction اتفاق می‌افتند. سایر موارد ذکر شده در این بخش به صورت optional هستند و در خصوص آن‌ها صحبت خواهیم کرد.

اما به صورت کلی، هنگامی که data ی جدیدی دریافت می‌شود، چه روش‌هایی برای اطمینان از ورود صحیح data وجود دارد؟ خود Splunk Enterprise پیشنهاد می‌کند که قبل از وارد کردن یک input به محیط production و استفاده از آن، حتماً یک محیط test ایجاد شود. ابتدا input مورد نظر در محیط test بررسی گردد و در صورت صحت عملکرد و اعمال صحیح پیکربندی‌های مد نظر، data به محیط production منتقل شده، input در آنجا ایجاد و پیکربندی‌ها اعمال شوند تا بتوان به نحو احسن از آن استفاده نمود. اما اگر محیط test در دسترس نباشد، می‌توان بر روی همان Splunk Enterprise اصلی، یک index برای موارد تستی ایجاد کرد و input های جدید را به سمت آن index ارسال نمود. در صورت اعمال صحیح موارد و عملکرد درست، data به index اصلی ارسال شود.

هنگامی که از یکی از این دو روش برای تست input استفاده می‌شود، انعطاف‌پذیری بیشتری وجود خواهد داشت. می‌توان index مورد نظر را حذف، clean یا مجدداً ایجاد کرد. هرگونه پیکربندی بر روی آن index بدون ریسک بوده و به راحتی قابل انجام است. ممکن است حتی نیاز به پاک کردن fish bucket ها باشد و data ی مرتبط با fish bucket آن index پاک شود. قطعاً در محیط لابراتواری، پاک کردن fish bucket هیچ‌گونه ریسکی به همراه ندارد و مشکلی ایجاد نمی‌کند. اما در محیط‌های production، پاک کردن fish bucket تا حدی ریسک دارد. بنابراین، در سازمان‌های enterprise که هرگونه تغییری می‌تواند ریسک‌هایی به همراه داشته باشد، ضروری است یا از محیط آزمایشگاهی استفاده شود یا حداقل چندین index به صورت تستی وجود داشته باشد تا بتوان data و input مورد نظر را تست نمود.

فرض کنید data ی جدیدی جمع‌آوری شده و input های مرتبط با آن data ی جدید ایجاد شده‌اند. پس از مشاهده data، متوجه وجود چندین مشکل در آن می‌شوید، مشکلاتی مانند timezone و character encoding. برای رفع این مشکلات، نیاز به پیکربندی attribute هایی در فایل props.conf است. در نتیجه، پس از شناسایی مشکلات data و attribute های مرتبط با رفع آن‌ها، باید اقدام به پیکربندی نمود.

پیش‌تر در خصوص inputs.conf صحبت شد و attribute های موجود و میزان انعطاف‌پذیری آن برای تغییر data بررسی گردید. اما برای رفع مشکلاتی مانند timestamp، character encoding، line break و همچنین استفاده از قابلیت‌هایی مانند mask کردن data و تغییر و تنظیم metadata file ها، نیاز به پیکربندی فایل props.conf است.

در خصوص parsing phase و attribute ها و configuration های مرتبط با این فاز، توضیحات ارائه شد. بنابراین، اگر نیاز به ایجاد پیکربندی در فایل props.conf و تغییر attributeی از data باشد، stanza های ایجاد شده باید به شکلی باشند که در تصویر مشاهده می‌شود. inputی پیکربندی شده و data ی مورد نظر دریافت گردیده است. قطعاً آن data، field هایی مانند source، host و sourcetype را دارا می‌باشد. اگر هدف، تغییر attribute های مرتبط با آن data در فایل props.conf باشد، باید syntax های نمایش داده شده در سمت چپ تصویر رعایت گردد. سه نوع syntax وجود دارد که می‌توان از هر کدام بسته به نیاز استفاده نمود:

• stanza ی source: در این stanza، پس از باز کردن آن و استفاده از کلمه source::، حتماً باید source input مورد نظر وارد شود. پس از بستن stanza، می‌توان attribute های مورد نظر را تغییر داد.
• stanza ی host: سینتکس بعدی stanzaی host است. ابتدا stanza باز شده، کلمه کلیدی host:: وارد می‌شود و سپس نام host مورد نظر درج می‌گردد. دقیقاً باید مقدار مربوط به هاست data input مورد نظرتان باشد. پس از بستن stanza، می‌توان attribute های مورد نظر را وارد کرد.
• stanza ی sourcetype: سینتکس بعدی که کاربرد بیشتری دارد. یک stanza باز شده و در داخل آن، فقط sourcetype مورد نظر نوشته می‌شود. پس از آن، می‌توان attribute های مورد نظر را وارد کرد.

به مثال‌ها توجه کنید. در مثال اول، data inputی وجود داشته که به وسیله stanza ی monitor، مسیری monitor می‌شود و log آن به سمت Splunk ارسال می‌گردد. source آن data input با /var/log/secure شروع می‌شود. نیازمندی در این مثال، تغییر sourcetype این source log به linux_secure بوده است. همانطور که مشاهده می‌شود، از stanza ی source:: استفاده شده، مسیر و source log ذکر گردیده و در انتها star (*) قرار داده شده است. پس امکان استفاده از wildcard ها نیز وجود دارد. پس از آن، از attribute sourcetype استفاده شده و مقدار جدیدی برای این لاگ  set گردیده است.

در مثال بعدی (مثال دوم)، در فایل props.conf از stanza ی host استفاده شده و نام یک host به همراه star استفاده شده که به مجموعه‌ای از host ها اشاره می کند. پس از آن، از attribute TZ (مرتبط با timezone) استفاده شده و timezone مرتبط با آن host ها تغییر کرده است.

در مثال سوم، از sourcetype استفاده شده است. قطعاً data inputی وجود داشته که sourcetype آن‌ها برابر با sales_increase بوده و نیاز به تغییر character encoding این data ها وجود داشته است. همانطور که در تصویر مشاهده می‌شود، در فایل props.conf چنین پیکربندی وارد شده که منجر به تغییر character encoding می‌گردد.

همانطور که قبلاً ذکر شد، فایل props.conf پیکربندی‌ای است که هم در فاز parsing و هم در فاز input کاربرد دارد. بسته به نوع پیکربندی‌ها و attribute های مورد استفاده، هر کدام به یک فاز مرتبط هستند. در تصویری که مشاهده می‌شود، این موضوع نمایش داده شده است که تنظیمات موجود در فایل props.conf به کدام یک از فازهای Splunk Enterprise مرتبط هستند که در اینجا فقط input و parsing وجود دارد. زمانی که data در فاز input قرار دارد، تنظیمات فایل props.conf می‌تواند character encoding را تغییر دهد یا می‌توان تنظیمات fine tuning بر روی فاز input انجام داد. از طرف دیگر، در فاز parsing، در پیکربندی props.conf می‌توان event breaking ها را تنظیم نمود و همچنین تنظیمات و قوانین مرتبط با time extraction را تغییر داد. در صورت نیاز به transformation و transform کردن data event، می‌توان از این قسمت شروع کرد (که در آینده به آن پرداخته خواهد شد).

چند مثال دیگر را با هم بررسی کنیم. در مثالی که در تصویر مشاهده می‌کنید، character encoding مجموعه‌ای از log ها تغییر کرده است. باید به این نکته توجه نمود که در فاز input، Splunk به صورت پیش‌فرض، character encoding تمام input ها را UTF-8 در نظر می‌گیرد. اگر نیاز به تغییر این مورد باشد، باید در فایل props، ابتدا stanza ی log مورد نظر را باز کرده و سپس از attribute CHARSET استفاده نمود و character encoding مورد نظر را در پیکربندی قرار داد.

مثال بعدی مرتبط با fine tuning directoryی است که در inputs.conf پیکربندی شده و log های موجود در آن directory در حال ارسال هستند. در آن directory، احتمالاً log file های متعدد و زیادی وجود دارد و در پیکربندی inputs.conf، قاعدتاً نمی‌توان یک sourcetype set کرد که به تمام log file های یک directory اعمال شود. ابتدا inputs.conf به گونه‌ای پیکربندی می‌شود که تمام log file های موجود در آن مسیر خوانده و ارسال شوند. سپس در پیکربندی props.conf، بر اساس source های مختلف، می‌توان sourcetype های متفاوتی set کرد. همانطور که در تصویر مشاهده می‌شود، پیکربندی props.conf به نحوی انجام شده که log های مختلفی از آن مسیری که در input پیکربندی شده، وجود دارد و پس از آن با استفاده از attribute sourcetype، sourcetype مورد نظر تغییر کرده است. این یکی از موارد کاربردی است که قطعاً در محیط‌های عملیاتی با آن مواجه خواهید شد.

این ماژول، کوتاه بود و مهم‌ترین نکته‌ای که باید از آن آموخت، این است که در صورت نیاز به انجام پیکربندی props.conf، چگونه باید آن را به پیکربندی inputs.conf متصل کرده و data ی مورد نظر را انتخاب نمود. همانطور که به خاطر دارید، یکی از روش‌ها، باز کردن stanza با کلمه کلیدی source و قرار دادن source log بود. همچنین stanza ی host و stanza ی sourcetype نیز وجود داشتند. در مثالی که در همین صفحه بررسی شد، امکان استفاده از stanza ی sourcetype وجود نداشت، زیرا از sourcetype input ایجاد شده اطلاعی در دست نبود. اما قطعاً از metadata ی source اطلاع وجود داشت و امکان استفاده از آن فراهم بود.

با ماژول نهم از دوره Splunk Enterprise Data Administration در خدمت شما هستیم. در این ماژول نیز قصد داریم در خصوص default processing که در فاز parsing وجود دارد، بیشتر صحبت کرده و همچنین به بررسی پیکربندی و optimize کردن event line breaking بپردازیم. در انتهای ویدئو نیز در خصوص نحوه extract کردن timestamp و timezone از event ها بحث خواهیم کرد.

هنگامی که data input تعریف می‌شود و data بر روی indexer یا heavy forwarder دریافت می‌گردد، پس از فاز input، فاز parsing وجود دارد. در این فاز، آن stream از data input موجود، به event های مجزا شکسته می‌شود که هر event، timestamp و timezone مختص به خود را دارد. به طور کلی، در فاز parsing می‌توان event ها را redirect، modify و حتی event هایی را ایجاد نمود. در فاز parsing، می‌توان یک step اضافی از transformation را اجرا نمود تا بتوان metadata field ها را modify کرد یا حتی raw data اصلی را modify و تغییر داد. هنگامی که data index می‌شود، دیگر قابلیت تغییری وجود ندارد و امکان ایجاد تغییر در آن data وجود ندارد. اما زمانی که data در فاز parsing قرار دارد، می‌توان data را تغییر داد، سپس data index می‌شود و پس از index شدن data، امکان تغییر آن وجود ندارد.

اما به طور کلی، event creation یا ایجاد event چگونه انجام می‌شود و چه فرآیندی رخ می‌دهد؟ Event creation یا ایجاد event در فاز parsing انجام می‌شد. هنگامی که data از فاز input وارد فاز parsing می‌شود، آن data به event های مجزا شکسته می‌شود و پس از آن، event level processing بر روی آن event ها اتفاق می‌افتد. تمام توضیحات ارائه شده، بر اساس event boundaries هایی است که Splunk Enterprise تشخیص می‌دهد. اگر به log هایی که در داخل یک log file قرار دارند، توجه کنید، مرزهای event را به احتمال زیاد به صورت بصری می‌توان تشخیص داد. همانطور که برای مطالعه و خواندن یک log file، باید مرز بین event ها را مشخص کرده و بدانید که یک event در کجا شروع و در کجا پایان می‌یابد، Splunk نیز باید به نحوی متوجه شود که یک event در کجا شروع شده و در کجا پایان یافته است. این فرآیند در فاز parsing و توسط line break ها اتفاق می‌افتد و Splunk با استفاده از line break ها متوجه می‌شود که یک event در کجا شروع شده و در کجا پایان یافته است.

Attribute هایی در فایل props.conf وجود دارد که به وسیله آن‌ها می‌توان مشخص کرد که یک event در کجا شروع می‌شود و یک event در کجا پایان می‌یابد. اما می‌توان گفت که به صورت پیش‌فرض، Splunk خود به درستی این مورد را تشخیص می‌دهد. زمانی که data ی شما دارای structure و ساختار است، می‌توان اطمینان داشت که Splunk 100% آن را به درستی تشخیص می‌دهد. و اگر data ی شما unstructured و فاقد ساختار باشد، می‌توان از TA ها و app های مرتبط با آن data استفاده کرد که configuration های مرتبط با event boundaries در داخل آن‌ها وجود دارد و به Splunk کمک می‌کند تا به طور دقیق‌تری ابتدا و انتهای log را مشخص نماید. بنابراین، در محیط‌های واقعی، کمتر پیش می‌آید که نیاز به مشخص کردن دستی مرزهای بین event ها و اعلام آن به Splunk باشد و محتوای ارائه شده در این ماژول، احتمالاً کاربرد عملی کمتری برای شما داشته باشد. اما لازم است بدانید که چنین مفاهیم و مواردی وجود دارند و تسلط بر این مطالب ضروری است تا زمانی که پیکربندی‌های props.conf را در یک app یا TA مشاهده می‌کنید، به راحتی بتوانید متوجه شوید که آن پیکربندی برای چه منظوری است و در کجا استفاده می‌شود و در صورت نیاز به تغییر، بتوانید آن را ویرایش کنید.

این مرزهای بین event ها چگونه در Splunk مشخص می‌شوند؟ به طور کلی، دو step وجود دارد که مرز بین event ها را مشخص می‌کنند:

1. Line Breaking: گام اول، line breaking است. در این step، آن جریان از data ها و byte های ورودی، به line های مجزا از آن dataی text ورودی شکسته می‌شود، به نحوی که خطوط از یکدیگر مجزا می‌گردند. در مثالی که در صفحه مشاهده می‌شود (مثال اول)، اگر دقت کنید، یک خط از data وجود دارد که در انتهای آن Enter زده شده است. پس از آن، مجدداً یک خط data ی دیگر، سپس مجدداً Enter و باز هم یک خط data ی دیگر وجود دارد. در Splunk، به وسیله attribute LINE_BREAKER، می‌توان regexی را مشخص کرد که آن regex نشان‌دهنده نقطه breaking در data ی شما باشد. به صورت پیش‌فرض، اکثر تجهیزاتی که log تولید می‌کنند، از این قاعده پیروی می‌نمایند که log های خود را فقط در یک خط می‌نویسند و اگر بخواهند log بعدی را ثبت کنند، در انتهای log قبلی، Enter ثبت شده یا زده می‌شود و پس از آن، line log بعدی نوشته شده و به همین ترتیب log های بعدی ثبت می‌گردند. بنابراین، این امکان وجود دارد که Enterی که در انتهای خط‌های log زده می‌شود، نشان‌دهنده انتهای log باشد و پس از آن، log های بعدی ثبت شوند. این پیکربندی به صورت پیش‌فرض در Splunk وجود دارد. و اگر logی وجود دارد که از این قاعده پیروی نمی‌کند، می‌توان به وسیله attribute LINE_BREAKER، regex مورد نظر را به آن sourcetype ، assign کرد و پس از آن، بر اساس قاعده‌ای که شما تعیین می‌کنید، line ها شکسته شده و event های مجزا تشخیص داده می‌شوند.
2. Line Merging: اما step بعدی، line merging است که به صورت optional می‌باشد. در این step، line هایی که از هم جدا شده‌اند، با یکدیگر merge شده و یک event مجزا را ایجاد می‌کنند. حال، دلیل وجود این step چیست؟ به این دلیل که log هایی وجود دارند که multi-line هستند. در این نوع log ها، Enter در انتهای line log وجود دارد، اما وجود Enter در انتهای log، 100% نشان‌دهنده پایان آن log نیست، زیرا log، multi-line است و این امکان وجود دارد که خطوط بعدی، بخشی از event قبلی باشند. برای حل این مشکل، می‌توان از step دوم استفاده کرد و log هایی را که multi-line هستند، به درستی تشخیص داد. در چنین شرایطی، در پیکربندی props.conf، پس از مشخص شدن LINE_BREAKER، می‌توان از attribute SHOULD_LINE_MERGE استفاده کرده و مقدار آن را برابر با true قرار داد تا Splunk متوجه شود که step دوم نیز وجود دارد. و پس از استفاده از این attribute، باید بر اساس attribute های دیگر به Splunk اعلام کرد که آن break نهایی چه زمانی اتفاق می‌افتد و تحت چه شرایطی آن event پایان یافته و event جدید شروع می‌شود. در چنین شرایطی، attribute هایی مانند BREAK_ONLY_BEFORE، BREAK_ONLY_BEFORE_DATE و همچنین attribute MUST_BREAK_AFTER وجود دارند. در مثالی که مشاهده می‌شود، از attribute BREAK_ONLY_BEFORE_DATE استفاده شده است و تا جایی که اطلاع دارم، اکثر log های multi-line، زمانی که قصد ثبت log جدید و بستن log قبلیِ پایان‌یافته را دارند، log جدید خود را با time شروع کرده و سایر اطلاعات را پس از time  قرار می دهند. به عبارت دیگر، زمانی که محتوای یک log file را که log های داخل آن multi-line هستند، مشاهده می‌کنید، به راحتی می‌توان شروع یک log را با مشاهده timestamp مشخص کرده و اطمینان حاصل کنید که زمانی که یک خط از log با timestamp شروع می‌شود، آن یک log مجزا است و همین مورد را در Splunk نیز پیکربندی نمایید. اکنون در این نمونه log که در اینجا وجود دارد و multi-line است، به خط اول log توجه کنید. در تصویر پایین صفحه، نمونه‌ای از log multi-line وجود دارد. در log های multi-line نیز، احتمالاً log هایی وجود دارند که فقط شامل یک line باشند. در همین مثال، خط اول، logی است که فقط یک line دارد، اما format کلی log، multi-line است. بنابراین، زمانی که Enter در انتهای آن خط وجود دارد، حتماً باید بررسی شود که آیا خط بعدی با timestamp شروع شده است یا خیر. اگر با timestamp شروع شده باشد، قطعاً آن log به انتها رسیده و log بعدی شروع شده است. اما اگر پس از Enter، خط بعدی با timestamp شروع نشده باشد، آن خط بخشی از همان log است و این log شامل چندین خط است که Splunk Enterprise آن را به راحتی تشخیص می‌دهد. اکنون در خط دوم، Enter در انتهای خط وجود دارد، اما خط سوم با timestamp شروع نشده است و همچنین خط چهارم نیز همین شرایط را دارد، یعنی timestampی در ابتدای خط وجود ندارد، اما در انتهای هر خط Enter زده شده است. بنابراین، هنوز به انتهای این log نرسیده‌ایم. خط پنجم فقط شامل یک کاراکتر است و باز هم با timestamp شروع نشده است و بلافاصله پس از آن کاراکتر، یک Enter وجود دارد. و زمانی که خط ششم و خط بعدی را بررسی می‌کنیم، مشاهده می‌شود که ابتدای خط با timestamp شروع شده است که این نشان‌دهنده یک log جدید است. بنابراین، آنچه تا کنون بررسی می‌کردیم، مجموعاً یک log بوده است و شامل چهار خط مجزا است که Splunk تمام این موارد را با هم merge کرده و به یک event مجزا تبدیل می‌کند.

پس برای جمع بندی این دو مثال، در مثال اول، لاگی داشتیم که انتهای تمام خطوط Enter وجود داشت که نشان دهنده انتهای Event بود و Splunk هر کدام از آن ها را یک Event درنظر می گیرد و فقط کافیست که از attribute Line_Breaker استفاده کنیم و Regex مربوط به Enter را در آن وارد کنیم که این موارد به صورت پیش فرض در Splunk پیکربندی شده است. در مثال دوم که مثالی از لاگ های Multi-Line است، ابتدا خطی وجود دارد که انتهای آن Enter دارد و به دلیل اینکه خط بعدی با timestamp شروع شده، نشان دهنده انتهای Event است و بعد از آن Event بعدی را داریم که شامل چهار خط است و انتهای هر خط Enter زده شده و زمانی که Spunk انتهای خط چهارم و ابتدای خط پنجم را می بیند که با timestamp شروع شده، متوجه می شود که Event قبلی به انتها رسیده و خطوط آن را merge می کند و تبدیل به یک Event مجزا می شود.

هنگام کار با log، یکی از مهم‌ترین مواردی که باید وجود داشته باشد و در Splunk نیز به درستی پیکربندی گردد، موارد مرتبط با timestamp  لاگ ها است. زمانی که یک log دریافت می‌شود، اولین اقدامی که برای بررسی آن log انجام می‌گیرد، حتماً باید verify کردن صحت timestamp باشد. به عبارت دیگر، حتماً باید بررسی شود که آیا در داخل آن log دریافتی، time درست و صحیحی وجود دارد یا خیر و پس از verify شدن این مورد، آیا آن time در Splunk به درستی extract می‌شود یا خیر. در اصل، باید قبل از وارد کردن آن log به محیط عملیاتی، این موارد بررسی شوند. در همان محیط آزمایشگاهی که توضیح داده شد، زمانی که log جمع‌آوری می‌شود، باید این موارد بررسی گردند. مورد اول، وجود timestamp صحیح در خود log و مورد دوم، صحت timestamp آن log در Splunk است.

تنظیماتی که به صورت پیش‌فرض در Splunk وجود دارد، به بهترین شکل ممکن عمل می‌کند، به طوری که format datetime های استاندارد را پشتیبانی کرده و اکثر موارد را تشخیص می‌دهد. اگر نیاز به extract کردن دستی timestamp باشد، حتماً باید این کار به وسیله configuration file props.conf انجام شود. در هر sourcetype و هر source logی که نیاز باشد، کافی است از attribute TIME_PREFIX استفاده کرده و regex مرتبط با timestamp log مورد نظر را به این attribute assign نمود. در مثالی که مشاهده می‌شود، یک خط log وجود دارد که ابتدای آن با یک timestamp شروع شده است. دقیقاً اگر بخواهیم این time را مد نظر قرار دهیم، باید regexی ایجاد کرد که آن regex تا انتهای آن timestamp را select کرده و به عنوان timestamp extract نماید.

استفاده از attribute TIME_PREFIX تنها یکی از attribute های مرتبط با timestamp است و attribute های دیگری نیز وجود دارند. Attribute های بعدی که به استخراج timestamp کمک می‌کنند، شامل مواردی مانند

• MAX_TIMESTAMP_LOOKAHEAD است که باید عددی را به این attribute assign نمود. اگر تا کنون توجه کرده باشید، اکثر log هایی که وجود دارند، ابتدای آن‌ها با timestamp شروع می‌شود. اگر بخواهید به وسیله این attribute، timestamp اینگونه log ها را به Splunk معرفی کنید، کافی است که از ابتدای log، کاراکترها را شمارش کرده تا به انتهای کاراکترهای مرتبط با timestamp برسید و تعداد کاراکترهای شمارش شده (به عنوان مثال 20 کاراکتر) را در اینجا قرار دهید. دقیقاً اتفاقی که رخ می‌دهد این است که Splunk آن 20 کاراکتر را بررسی کرده و اگر timestampی در داخل آن وجود داشته باشد، timestamp را استخراج می‌کند. نکته‌ای که در خصوص این attribute وجود دارد این است که اگر همزمان از attribute TIME_PREFIX نیز استفاده شود، این شمارش کاراکترها از نقطه‌ای شروع می‌شود که با attribute TIME_PREFIX مشخص شده است. با استفاده از attribute TIME_PREFIX، regexی مشخص شده و به Splunk اعلام می‌شود که timestamp log های شما، همان regexی است که در این attribute قرار دارد و اگر همزمان از این attribute نیز استفاده شود، این شمارش کاراکترهایی که در اینجا ذکر شد، از نقطه‌ای شروع می‌شود که attribute TIME_PREFIX پیکربندی شده است.
• Attribute بعدی، TIME_FORMAT است که با استفاده از آن می‌توان format timestamp را مشخص کرد.
• Attribute بعدی مرتبط با timezone است. اگر نیاز به تغییر timezone مرتبط با یک sourcetype و یک source از log باشد، می‌توان از attribute TZ استفاده کرده و timezone مورد نظر را به این attribute assign نمود.

یکی از مهم‌ترین نکاتی که وجود دارد و باید آن را به خاطر بسپارید، فرآیند timestamp processing است که در Splunk اتفاق می‌افتد. به صورت پیش‌فرض، زمانی که log به Splunk می‌رسد، برای استخراج timestamp چندین اتفاق رخ می‌دهد:

1. اولین مورد این است که Splunk سعی می‌کند با استفاده از attribute TIME_FORMAT که در configuration props.conf تعریف شده، timestamp event ها را شناسایی کند.
2. پس از آن، اگر attribute TIME_FORMAT پیکربندی نشده باشد، Splunk سعی می‌کند به صورت automatically، timestamp event ها را شناسایی نماید.
3. سپس، اگر time را شناسایی کرد اما date یا تاریخ را نتوانست شناسایی کند، سعی می‌کند تاریخ را از sourcename یا فایل sourceی که log از آن خوانده می‌شود، شناسایی نماید.
4. در نهایت، اگر موفق به شناسایی تاریخ نشد، از time modification فایل‌ها استفاده کرده و سعی می‌کند تاریخ را از آن موارد شناسایی نماید.
5. اگر در هر صورت نتوانست timestamp را پیدا کند، از timestampی استفاده می‌کند که اخیراً مورد استفاده قرار گرفته است.
6. یا در نهایت، از system timeی که بر روی indexer ها set شده است، استفاده می‌نماید.

بنابراین، هیچ eventی بدون timestamp باقی نمی‌ماند و بر اساس شرایط ذکر شده، Splunk به دنبال timestamp برای event ها می‌گردد تا بتواند آن را به نحوی به دست آورد.

با ماژول دهم از دوره Splunk Enterprise Data Administration همراه شما هستیم. در این ماژول، به چگونگی تعریف data transformation پرداخته خواهد شد. همچنین، با استفاده از transformation هایی که در پیکربندی props و transform تعریف می‌شوند، مثال‌های کاربردی ارائه خواهیم داد. در انتهای این آموزش نیز، با بهره‌گیری از transformation هایی که در پیکربندی‌های props.conf و transforms.conf تعریف می‌کنیم، مثال‌های کاربردی بیشتری را بررسی خواهیم نمود.

زمانی که data ها جمع‌آوری می‌شوند، در برخی موارد ضروری است که پیش از index شدن data، عملیات خاصی بر روی آن انجام شود. به عنوان مثال، فرض کنید data های مرتبط با transaction را جمع‌آوری می‌کنید و قصد دارید قسمتی از شماره کارت‌ها را mask نمایید. در چنین شرایطی، عملیات masking باید پیش از index شدن data صورت پذیرد؛ زیرا پس از index شدن، امکان تغییر data وجود ندارد. بنابراین، این‌گونه تغییرات الزاماً باید در فاز parsing انجام شوند. یا مواقعی وجود دارد که می‌خواهید برخی از data های امنیتی را به سمت index های دیگری route کرده و در آنجا ذخیره کنید. در این مورد نیز، نیاز است پیش از ارسال data به indexer های اصلی، به نحوی آن را به indexer های دیگر هدایت کنید تا data های امنیتی در indexer های مجزا ذخیره شوند. پس به طور کلی، شرایطی پیش می‌آید که نیاز به modify کردن (تغییر) raw data یا route کردن event ها بر اساس event های مختلف وجود دارد. در این ویدیو، به بررسی این موارد خواهیم پرداخت.

هنگام دریافت data ها، بهتر است metadata field ها در فاز input تعریف شوند تا بتوان در مراحل بعدی از آن‌ها استفاده کرد. با این حال، به صورت کلی Splunk دو method (روش) اصلی برای انجام raw data transformation ارائه می‌دهد (اصطلاحی که در این ویدیو به کرات از آن استفاده خواهیم کرد). این دو method عبارتند از: set_cmd و transform. در method اول (set_cmd)، تنها از پیکربندی props.conf استفاده می‌شود و صرفاً use case هایی مانند mask کردن یا truncate کردن raw data را پشتیبانی می‌کند. method دوم، transforms است که با استفاده از پیکربندی props.conf و فایل transforms.conf عمل می‌کند. این روش بسیار flexible تر (انعطاف‌پذیرتر) از متد  set_cmd است، به نحوی که با استفاده از آن می‌توان event ها را بر اساس source، sourcetype یا host، transform کرد.

تمرکز آموزش در این ویدئو روی متد  transform خواهد بود، اما در ابتدا مثالی از کاربرد set_cmd ارائه می‌شود و سپس به بررسی مثال‌های کاربردی‌تر با استفاده از متد  transforms می‌پردازیم. همان‌طور که در تصویر مشاهده می‌شود، هدف mask کردن قسمتی از data دریافتی است. به گونه‌ای که هنگام ذخیره‌سازی data، به جای برخی از اعداد موجود در raw data، کاراکتر X نمایش داده شود و بخشی از data به این ترتیب mask گردد. در این method، با استفاده از regular expression، قسمتی از data که مد نظر است، search شده و با pattern (الگوی) مورد نظر جایگزین می‌شود. در مثالی که در تصویر نمایش داده شده، هر event دارای یک field به نام ACCTID است که حاوی یک value (مقدار) ده رقمی است. هدف، mask کردن پنج رقم ابتدایی این value است. پیکربندی مربوطه در فایل props.conf انجام می‌شود: ابتدا stanzaی مربوط به source تعریف شده و source log مورد نظر در آن ذکر می‌شود. سپس از کلمه کلیدی set_cmd استفاده شده و نامی به آن اختصاص داده می‌شود. value اختصاص‌یافته به آن، یک regex است که به صورت capture group نوشته شده است. اگر به مباحث regex مسلط باشید به راحتی می توانید این بخش را درک کنید.

همان‌طور که در تصویر مشخص است، regex با کاراکتر s و سپس / آغاز می‌شود (نشان‌دهنده شروع جایگزینی). پس از آن، خود regex نوشته شده و در ادامه، مجدداً کاراکتر / و سپس بخشی که باید جایگزین شود، قرار می‌گیرد. در بخش اول (بین دو کاراکتر /)، باید قسمتی از متن که کاراکترهای آن باید تغییر کنند، با استفاده از regex انتخاب شود. در این مثال، regex از ابتدای ACCTID= شروع شده و تا انتهای رشته عددی ادامه می‌یابد، اما پنج رقم پایانی در یک capture group جداگانه قرار داده شده است. پس از انتخاب این قسمت، در بخش بعدی (بخش replacement)، نحوه جایگزینی مشخص می‌شود. از آنجایی که تنها پنج رقم اول باید جایگزین شوند، عبارت ACCTID= باقی می‌ماند، سپس به جای پنج رقم اول، کاراکتر مورد نظر (X) قرار داده می‌شود و در نهایت، محتوای capture group ای که حاوی پنج رقم پایانی است ذکر کردیم که در در نتیجه کل اون فیلد و مقدار آن انتخاب می شود و فقط برای پنج رقم اول کاراکتر set می شود و پنج رقم آخر دوباره به فیلد اضافه می شود.

برای نتیجه‌گیری از این بخش، این مثال صرفاً برای آشنایی با وجود چنین methodی ارائه شد. هرچند به نظر می‌رسد این روش کمی پیچیده بوده و فرآیند را دشوارتر می‌کند. در مقابل، استفاده از متد  transform، گرچه ممکن است به دلیل وجود attribute های بیشتر، در ظاهر پیچیده‌تر به نظر برسد، اما انعطاف‌پذیری بالاتر آن باعث می‌شود درک و پیاده‌سازی transformation ها ساده‌تر گردد.

اگر بخواهیم از transforms استفاده کنیم، باید ساختار منظم زیر را رعایت نماییم. لازم به ذکر است که per-event transformation (تغییرات بر روی هر event) مبتنی بر regex pattern هایی است که match می‌شوند. در واقع، regex در این solution ها نقش اساسی دارد؛ برای اینکه matching اتفاق بیفتد، باید regex مناسب نوشته و استفاده شود. transformation در فایل transforms.conf تعریف شده و در فایل props.conf، invoke (فراخوانی) می‌شود. برای استفاده از transform، چندین attribute وجود دارد که آشنایی با آن‌ها ضروری است:

• SOURCE_KEY: با استفاده از این attribute، مشخص می‌کنید که کدام یک از data stream های موجود باید برای pattern matching استفاده شود. منظور در اینجا نوع sourceی است که می‌خواهید transformation بر روی آن اعمال گردد. value ای که در اینجا قرار می‌گیرد، ارتباطی با host، source یا sourcetype ندارد (آن‌ها در props.conf مشخص شده‌اند). منظور دقیقاً همان data streamی است که می‌خواهید استفاده کنید. معمولاً اگر هدف کار بر روی log های اصلی آن sourcetype باشد، value این attribute برابر با _raw قرار داده می‌شود.
• REGEX: این attribute حاوی همان regular expression است که برای انتخاب event های مورد نظر از SOURCE_KEY استفاده می‌شود.
• DEST_KEY: این attribute مشخص می‌کند که نتیجه transformation (data پردازش‌شده) کجا باید نوشته شود.
• FORMAT: این attribute چگونگی و قالب نوشتن خروجی (نتیجه transformation) را تعیین می‌کند. با بررسی مثال‌های بعدی، کاربرد این attribute ها شفاف‌تر خواهد شد.

در مثالی که در صفحه مشاهده می‌شود، نیازمندی، mask کردن دوازده کاراکتر عددی در میانه log است. برای این منظور، ابتدا props.conf پیکربندی شده و سپس transforms.conf. یک regex نوشته شده که آن دوازده کاراکتر را select (match) می‌کند. پس از آن، DEST_KEY و FORMAT تعریف شده‌اند. در FORMAT از دو variable (متغیر) $1 و $2 استفاده شده است. زمانی که این regex قسمت مورد نظر را select می‌کند، هر آنچه پیش از آن قسمت قرار دارد، در variable $1 و هر آنچه پس از آن قرار دارد، در variable $2 ذخیره می‌شود. هنگام تعریف FORMAT، از این دو variable استفاده می‌کنیم: ابتدا محتوای $1 (متن قبل از ۱۲ کاراکتر) قرار داده می‌شود، سپس عبارت session_id=XXXXXXXXXXXX (بخش mask شده) و در نهایت محتوای $2 (متن بعد از ۱۲ کاراکتر). به این ترتیب، خروجی نهایی در raw data نوشته و index می‌شود. پس این روش خیلی آسان تر از روش قبلی است، چون اینجا متغیرهایی وجود دارد که قبل و بعد داده هایی که مدنظر ما است را نگه می دارد و به راحتی می توانیم از آن ها استفاده کنیم. پس برای جمع بندی، نکته اول اینکه در این transform، اصلا source_key وجود ندارد، چون به صورت پیش فرض _row دارد استفاده می شود. مهم ترین نکته ای که برای پیکربندی وجود دارد این است که شما بتوانید regex مناسبی بنویسید که آن قسمت از داده ها به درستی انتخاب شود و قبل و بعد آن داخل capture group هایی قرار بگیرد که در قالب متغیرهایی در دسترس باشند. در این مثال، regex ای که نوشته شده، همه آنچه که قبل از این 12 کاراکتر است در capture group اول قرار می گیرد و هرچه بعد از این 12 کاراکتر باشد در capture group بعدی قرار می گیرد. یعنی آن دوازده کاراکتر select می شود و می توانید فرمت آن را تغییر دهید. ابتدا باید از $1 استفاده کنید که حاوی text هایی است که قبل از آن 12 کاراکتر است و بعد از آن به جای 12 کاراکتر، کاراکتر مدنظر خودتان را قرار می دهید و بعد از آن ادامه لاگ مدنظر را که در متغیر $2 است وارد می کنید.

در مثال بعدی، هدف تغییر sourcetype بر اساس وجود کلمه custom در انتهای data است. اگر کلمه custom در انتهای data باشد، sourcetype تغییر می‌کند، در غیر این صورت، sourcetype پیش‌فرض باقی می‌ماند. data از source UDP 514 دریافت می‌شود. props.conf ایجاد شده و اکنون باید transforms.conf پیکربندی شود. stanzaی مورد نظر با نام مربوطه ایجاد می‌شود. SOURCE_KEY برابر با _raw تنظیم می‌شود. regex به گونه‌ای نوشته شده که تنها data هایی را select می‌کند که دقیقاً به کلمه custom ختم شوند (با استفاده از علامت $). در attribute بعدی، DESTKEY برابر با metadata:sourcetype تنظیم شده است؛ این بدان معناست که metadata field مربوط به sourcetype باید تغییر کند. در نهایت، attribute مربوط به FORMAT برابر با sourcetype::custom_log قرار داده شده است. custom_log نام sourcetype جدیدی است که به این نوع data، assign خواهد شد و عبارت sourcetype:: مشخص می‌کند که مقدار metadata field مربوط به sourcetype باید با این مقدار جدید جایگزین شود. (می‌توانستیم metadata:host یا metadata:source را نیز به عنوان DEST_KEY انتخاب کرده و format متناسب با آن را تعریف کنیم).

مثال بعدی مربوط به تغییر hostname بر اساس محتوای log است. فرض کنید در log ها یک field به نام server وجود دارد که مقادیر متفاوتی دارد. هدف این است که برای log های مربوط به هر server، مقدار metadata field مربوط به host با مقدار همان server جایگزین شود. ابتدا props.conf پیکربندی می‌شود. سپس در transforms.conf، stanzaی مربوطه ایجاد شده، SOURCE_KEY مشخص می‌شود. regex به گونه‌ای نوشته شده که field و value مربوط به server را match می‌کند و value موجود در field server در یک capture group قرار می‌گیرد (محتوای آن در variable $1 ذخیره می‌شود). سپس DEST_KEY برابر با metadata:host تنظیم شده (یعنی field host از metadata ها باید تغییر کند) و FORMAT برابر با host::$1 قرار داده می‌شود. پیشوند host:: مشخص می‌کند که مقدار field host باید تغییر کند و $1 حاوی مقدار value مربوط به field server است که با regex استخراج شده است.

مثال بعدی مرتبط با index routing است. می‌توان بر اساس شرایط موجود در log، برخی event ها را select کرده و آن‌ها را در یک index دیگر ذخیره نمود. البته توصیه می‌شود تا حد امکان، index مورد نظر در پیکربندی inputs.conf مشخص شود و تنها در صورت نیاز به routing پویا بر اساس محتوای log، از این روش استفاده گردد. در پیکربندی props.conf، transformation مربوطه فراخوانی می‌شود. سپس در transforms.conf، stanza تعریف می‌گردد. regex به گونه‌ای نوشته شده که log هایی که حاوی کلمه کلیدی error یا warning هستند را match کند. DEST_KEY برابر با metadata:index تنظیم شده یعنی index باید تغییر کند و FORMAT برابر با نام index جدیدی است (error_index) که این log ها باید در آن ذخیره شوند. پس در نتیجه در این مثال، هر لاگی که از این sourcetype دریافت شود و کلمه error یا warning داخل آن باشد، ایندکس آن تغییر می کند و در ایندکس دیگری که اینجا ذکر شده ذخیره می گردد.

تمام مثال‌های بررسی‌شده تا کنون، موارد کاربردی هستند که احتمالاً در محیط‌های سازمانی با آن‌ها مواجه خواهید شد. مثال مهم دیگر، ارسال event های غیرضروری به nullQueue است. ابتدا در props.conf، transformation مربوط به log های مورد نظر. در این مثال، log های سیستمی ویندوز فراخوانی می‌شود. سپس در transforms.conf، stanza تعریف می‌گردد. regex به گونه‌ای نوشته شده که event هایی با event code های ۵۹۲ و ۵۹۳ را انتخاب کند. برای ارسال این event ها به nullQueue، کافی است DEST_KEY را برابر با queue و FORMAT را برابر با nullQueue قرار دهید. اگر شرایط متفاوتی مد نظر باشد، کافی است regex و احتمالاً sourcetype در props.conf را تغییر دهید.

مثال آخر مربوط به routing event ها به سمت گروه‌های مختلف indexer (یا forwarder) است. فرض کنید می‌خواهیم log ها را بر اساس محتوایشان به گروه‌های مختلفی از server ها ارسال کنیم. در props.conf، دو transform مختلف فراخوانی شده‌اند. اولین transform با نام error_routing، log هایی که حاوی کلمه error هستند را انتخاب کرده و با استفاده از TCPROUTING، آن‌ها را به گروهی به نام error_group ارسال می‌کند. اگر output را بررسی کنیم یک target group وجود دارد که server ای داخل آن معرفی شده و در نتیجه تمام لاگ هایی که کلمه error داخل آن ها باشد به سمت این target group ارسال می شوند. در این transform، مقدار DEST_KEY برابر _tcp_routing قرار داده شده و براین اساس مقدار FORMAT برابر با نام target group مورد نظر است. پس نتیجه می گیریم که اگر DEST_KEY را برابر با tcp_routing قرار دهیم، باید در قسمت Format نام گروه مدنظرمان را وارد کنیم.

دومین transform با نام syslog_routing، با استفاده از regex . (که تمام event ها را match می‌کند)، تمام log های باقیمانده را با استفاده از TCPROUTING به target group دیگری به نام syslog_servers ارسال می‌کند. (هر دو target group باید در فایل outputs.conf تعریف شده باشند).

پس از بررسی این مثال‌ها، مروری بر فاز indexing خواهیم داشت. همان‌طور که در ویدیوهای قبلی گفته شد، پس از فاز parsing، فاز indexing قرار دارد. یکی از اجزای مهم این فاز، license meter است که usage (میزان مصرف) license را بررسی می‌کند. این بخش، raw data ورودی به این فاز را اندازه‌گیری کرده و از حجم license کسر می‌نماید. سپس، هنگام ذخیره‌سازی، raw data فشرده شده و به همراه index file های مربوطه بر روی disk نوشته می‌شود. نکته مهم این است که برای محاسبه مصرف license، تنها حجم raw data در نظر گرفته می‌شود و حجم metadata محاسبه نمی‌گردد. همچنین به یاد داشته باشید که تغییرات اعمال‌شده در props.conf و transforms.conf تنها بر روی data های جدید تأثیر می‌گذارند و data های قبلاً index شده را تغییر نمی‌دهند. پس از اعمال تغییرات در این فایل‌ها، بهتر است سرویس splunk را restart کنید یا حداقل یک reload انجام دهید تا پیکربندی‌های جدید خوانده شوند.

در انتهای ویدیو، یک مثال دیگر از masking data ارائه می‌شود. همانطور که در تصویر می‌بینید، logی وجود دارد و هدف mask کردن قسمت session id آن است. برای این منظور، یک regex نوشته شده است. خروجی این regex به گونه‌ای است که قسمت session id و مقداری که باید mask شود، select می‌گردد و همزمان، بخش‌های قبل و بعد از آن در capture group های جداگانه ذخیره می‌شوند. بنابراین، نوشتن regex برای این بخش بسیار مهم است. برای درک کامل این بخش، تسلط بر مباحث regex ضروری است. از طرفی، در configuration مربوط به transform از چنین configuration استفاده شده است. همان regex به attribute مربوط به REGEX داده شده و FORMAT به این صورت assign شده است: ابتدا $1 (محتوای قبل از session id که با رنگ سبز مشخص شده)، سپس عبارت session_id=XXXXXXXXXX (بخش mask شده) و در نهایت $2 (محتوای بعد از session id). پس در نتیجه، قسمتی که به رنگ سبز مشخص شده و در متغیر $1 قرار دارد، درج می‌شود و پس از آن عبارت session_id مساوی با number های mask شده و در انتها، محتوای متغیر $2 (که شامل تمام text های بعد از session id است و در تصویر به رنگ قهوه‌ای نمایش داده شده) قرار می‌گیرد. در نهایت، خروجی به دست آمده در raw data نوشته شده و index می‌شود.

با ماژول یازدهم از دوره Splunk Enterprise Data Administration همراه شما هستیم. این ماژول، آخرین ماژول است که در سرفصل‌های استاندارد این دوره وجود دارد. در این ماژول، به موضوعات search time field extraction و همچنین index time field extraction پرداخته خواهد شد و در انتهای این آموزش، در خصوص orphaned knowledge object ها صحبت خواهیم کرد.

با توجه به تصویری که مشاهده می‌کنید، زمانی که کاربر بر روی search head، یک search را اجرا می‌کند، search head آن search را به indexer ها ارسال می‌نماید. بسته به نوع search، ممکن است indexer بر روی log هایی که از قبل ذخیره شده و بر روی disk قرار دارند، search کند یا در مرحله indexing به دنبال data ی مورد نظر جستجو نماید. زمانی که کاربر time range مربوط به search خود را برابر با real-time قرار می‌دهد، indexer در فاز indexing به دنبال آن data های مورد نظر می‌گردد. اما اگر time range search مورد نظر، مقداری غیر از real-time باشد، indexer مستقیماً بر روی disk، یعنی دقیقاً محلی که data ها ذخیره شده‌اند، به دنبال data های مورد نظر جستجو می‌کند. پس از یافتن data و ارسال آن به search head، فرآیند search time transformation اتفاق می‌افتد؛ تنظیماتی که در مرحله search time تعریف شده‌اند، بر روی data اعمال می‌شوند و سپس data به کاربر نمایش داده می‌شود. به عنوان مثال، اگر در تنظیمات search time، پیکربندی‌های مرتبط با knowledge object هایی مانند alias یا calculated field ها از پیش انجام شده باشد، آن تنظیمات بر روی data اعمال شده و سپس data به کاربر نمایش داده خواهد شد. همچنین، تنظیمات دیگری مانند extract کردن field ها و اعمال تنظیمات مرتبط با regex هایی که منجر به extract شدن field و value ها می‌شوند، در این مرحله انجام می‌پذیرد و پس از اعمال این تنظیمات، data به کاربر نمایش داده می‌شود.

ما در دوره fundamental 2، در خصوص index time و search time، مباحث مقدماتی را توضیح داده‌ایم. لازم است پیش از ورود به این دوره، حتماً مباحث دوره‌های fundamental 1 و fundamental 2 (که توسط اینجانب تدریس شده) را مشاهده فرمایید. در خصوص index time field extraction باید گفت، زمانی که فرآیند index time در حال انجام است و data ها در حال index شدن هستند، event data ها در قالب index بر روی disk ذخیره می‌شوند. default field هایی که پیش‌تر در مورد آن‌ها صحبت کردیم، به صورت اتوماتیک extract شده و به data اضافه می‌گردند. همچنین، custom field هایی که وجود دارند، بر اساس customization انجام‌شده توسط admin، به data اضافه می‌شوند.

باید به این نکته توجه داشت که field ها به صورت کلی در مرحله search time، extract شده و به کاربر نمایش داده می‌شوند. با این حال، use case ها و موارد کاربردی خاصی وجود دارد که ایجاب می‌کند field extraction در index time اتفاق بیفتد. یکی از این موارد، زمانی است که بر روی forwarder ها، data یی با structure مشخص دریافت می‌کنیم و forwarder آن‌ها را به سمت indexer ارسال می‌کند. در چنین شرایطی که با structure data مواجه هستیم، field extraction در index time رخ داده و انجام می‌شود. use case دیگر، زمانی است که بر روی indexer، field هایی داریم که باعث کاهش search performance می‌شوند. در این مواقع، باید تنظیمات را به گونه‌ای پیکربندی کنیم که field extraction برای آن field ها در زمان index time صورت پذیرد.

بنابراین، به طور کلی، custom field ها را زمانی در index time  پیکربندی می‌کنیم که دو شرط زیر برقرار باشد:

1. مرتبط با Performance مربوط به search time  و indexing: یعنی فیلدهایی وجود دارند که تأثیر منفی بر performance مربوط به search time و indexing می‌گذارند. می‌توان این موارد را به نحوی پیکربندی کرد که پردازش آن field ها در زمان index time انجام شود تا تأثیر منفی آن‌ها بر performance search کاهش یابد.
2. مرتبط با سایز Index: زمانی که هدف، افزایش سایز searchable بودن index است. این مورد نیز پیکربندی‌های خاص خود را دارد و در صورت نیاز به تغییر این سایز، می‌توان custom field ها را در زمان index time پیکربندی نمود.

به طور کلی Index time field extraction دارای مزایا و معایبی است. یکی از مهم‌ترین معایب آن، افزایش سایز مورد نیاز storage است. این روش باعث افزایش حجم ذخیره‌سازی می‌شود که به طور میانگین بین دو تا پنج برابر است. مشکل دیگر، مرتبط با field name هایی است که شما assign می‌کنید؛ این field name ها به صورت static تعریف می‌شوند و اگر نیاز باشد از همان field name در level های مختلف استفاده شود، نیاز به انجام step های پیکربندی اضافی خواهد بود. مشکل دیگر این است که همانطور که اشاره شد، پیکربندی نادرست در این بخش می‌تواند منجر به کاهش performance سیستم شود. علاوه بر این، field extraction در زمان index time فاقد flexibility لازم است و برای تغییر field ها محدودیت وجود دارد. هر تغییری که ایجاد می‌کنید، تنها بر روی data های جدید اعمال می‌شود، در حالی که تغییرات در سطح search time، بر روی تمام data های موجود (قدیمی و جدید) قابل مشاهده است. از مزایای محدود index time field extraction می‌توان به امکان انجام پیکربندی بر روی Universal Forwarder، وجود قابلیت auto formatting و امکان drop کردن header ها و comment های غیرضروری در این مرحله به منظور دستیابی به log های بهینه‌تر اشاره کرد.

در این زمینه، Splunk یک recommendation نیز ارائه می‌دهد: برای منابع log که به طور مداوم در حال تغییر و پیکربندی مجدد هستند، استفاده از index time field extraction ارجحیت دارد. به عنوان مثال، برای log های مرتبط با IIS، خود Splunk تنظیمات پیش‌فرض را به گونه‌ای فراهم کرده که با انتخاب آن‌ها، index time field extraction برای این source فعال می‌شود. در مقابل، برای فایل‌هایی با فرمت ثابت مانند CSV (که فایل‌های static محسوب می‌شوند)، بهتر است از تنظیمات report و delimiter که مربوط به field extraction در زمان search time هستند، استفاده شود تا performance بهتری حاصل گردد.

همانطور که در تصویر نمایش داده شده، در پایین، log های مرتبط با IIS و در بالا، پیکربندی مرتبط با props.conf برای این log نشان داده شده است. در این پیکربندی، از attribute به نام INDEXED_EXTRACTIONS استفاده شده و مقدار آن برابر با W3C قرار گرفته است. برای این attribute می‌توان مقادیر دیگری مانند CSV, PSV, TSV, JSON, HEC را نیز انتخاب کرد. انتخاب هر یک از این value ها به Splunk اعلام می‌کند که انتظار دریافت data input با آن فرمت خاص را دارد و متعاقباً، برخی از field های آن data در زمان index time، extract خواهند شد. attribute بعدی در این پیکربندی، شماره خطی را مشخص می‌کند که حاوی نام field های مورد نظر است. به عنوان مثال، در log file نمایش داده شده، خط چهارم شامل نام field ها است. نیاز است که این اسامی به عنوان field name در نظر گرفته شده و استفاده شوند. در این مثال، چون مقدار attribute برابر ۴ است، اسامی field ها از خط چهارم خوانده می‌شود. data های موجود در خطوط بعدی log، هر کدام به یکی از این field name ها تعلق دارند و Splunk از این اسامی برای اختصاص field name صحیح استفاده می‌کند. attribute بعدی نیز field های مرتبط با timestamp را معرفی می‌کند که نام این دو field نیز در خط چهارم ذکر شده است.

در مثال بعدی، نیازمندی، استخراج یک field خاص از داخل log و اختصاص value متناظر با آن است، به طوری که این field در زمان index time، extract و ذخیره شود. همانطور که مشاهده می‌شود، ابتدا در indexer و forwarder، فایل props.conf به شکل مشخصی پیکربندی شده است. سپس configuration مربوط به transforms.conf انجام شده است. این configuration باعث می‌شود field مورد نظر از log، extract شده، value مناسب به آن اختصاص یابد و نهایتاً field ذخیره و write شود. در نهایت، با استفاده از configuration فایل fields.conf، attribute به نام INDEXED برابر با true قرار داده شده است. این attribute مشخص می‌کند که آیا field باید در index time ایجاد شود یا در search time. مقدار true به معنای ایجاد field در index time است. این مثال نشان داد که چگونه می‌توان یک field را در زمان index time ایجاد و extract کرد.

نکته کلیدی که تا این بخش مطرح شد، این است که هنگام ارسال structure data به forwarder، خود forwarder عمل parse را انجام نمی‌دهد و data را مستقیماً به indexer ارسال می‌کند. حتی اگر در تنظیمات props.conf مربوط به forwarder، attribute مرتبط با index extraction را set کرده باشید، forwarder همچنان structure data را parse نکرده و به indexer می‌فرستد. Indexer این data را در صف‌های parsing, aggregation و typing قرار می‌دهد تا نهایتاً field را extract و ذخیره نماید.

در خصوص search time field extraction باید توجه داشت که برای اکثر sourcetype ها و data هایی که دریافت می‌کنیم (و TA مربوطه را استفاده می‌کنیم)، field extraction در search time اتفاق می‌افتد. زمانی که شما آن data را search می‌کنید، Splunk با استفاده از sourcetype و regex هایی که برای extraction آن data تعریف شده‌اند، field های data را extract کرده و به شما نمایش می‌دهد. نکته مهم این است که هنگام استفاده از app ها و add-on ها، به عنوان مثال add-on مربوط به Linux، استخراج field های log های standard سیستم‌عامل Linux (مانند secure.log یا messages.log) در زمان search time انجام می‌شود. به طور مشابه، TA مرتبط با Windows نیز بیشتر field های data های Windows را در زمان search time، extract می‌کند.

به طور کلی، سه روش اصلی برای انجام search time field extraction وجود دارد:

1. استفاده از Search Bar: می‌توان از طریق search bar و با استفاده از command هایی مانند regex یا دستورات مشابه که بر روی data اعمال می‌شوند، field ها را extract کرد و نتیجه را بلافاصله مشاهده نمود. این روش نیازمند تسلط بر regex است.
2. استفاده از Field Extractor: زمانی که در Splunk Web یک search اجرا می‌کنید و data به همراه field های موجود نمایش داده می‌شود، می‌توانید از ابزار Field Extractor برای انجام search time field extraction استفاده کنید. (جزئیات استفاده از Field Extractor با روش‌های delimiter و regex-based در دوره fundamental 2 توضیح داده شده است). این روش نیازی به تسلط کامل بر regex ندارد.
3. استفاده از Configuration File: می‌توان با استفاده از configuration file های props.conf و transforms.conf، پیکربندی‌های مرتبط با field extraction را اعمال نمود. این روش انعطاف‌پذیری بیشتری دارد اما نیازمند آشنایی با regex است.

همانطور که گفته شد، field extraction یا در index time یا در search time رخ می‌دهد. Search time extraction می‌تواند به صورت inline باشد یا با استفاده از field transform پیکربندی شود. هنگامی که از روش inline استفاده می‌کنید، attribute به نام EXTRACT در فایل props.conf پیکربندی می‌شود (همان طور که در صفحه می بینید). زمانی که از روش delimiter استفاده می‌کنید، attribute به نام REPORT در props.conf و پیکربندی‌های مرتبط در transforms.conf ایجاد می‌شوند. در مثال نمایش داده شده، استفاده از attribute EXTRACT منجر به استخراج یک field خاص شده است. در مثال دیگر، استفاده از attribute REPORT به یک stanza در transforms.conf ارجاع داده که در آن، با استفاده از یک delimiter و لیست نام field ها، استخراج انجام می‌شود. تمام این پیکربندی‌ها می‌توانند از طریق ابزار Field Extractor در Splunk ایجاد شوند.

همانطور که در دوره‌های fundamental 1 و 2 در خصوص lookup ها توضیح داده شد، یکی از روش‌های data enrichment، استفاده از این نوع knowledge object است. زمانی که یک lookup definition ایجاد می‌شود، تنظیمات آن در search time مورد استفاده قرار می‌گیرد. چهار نوع lookup type وجود دارد که همگی در search time عمل می‌کنند. اگر مباحث knowledge object را به خاطر داشته باشید، این object ها در configuration file هایی مانند macros.conf, tags.conf, eventtypes.conf, savedsearches.conf ذخیره می‌شوند. ایجاد یا تغییر هر یک از این knowledge object ها از طریق UI، منجر به تغییر فایل configuration مربوطه می‌شود. می‌توان knowledge object ها را هم از طریق Splunk Web و هم با ویرایش مستقیم فایل configuration مربوطه، ایجاد و modify کرد. نکته بسیار مهم این است که هنگام ایجاد یک knowledge object، یک owner نیز برای آن set می‌شود که این owner همان username کاربری است که آن object را ایجاد کرده است.

سوالی که در اینجا مطرح می‌شود این است: اگر user ی که owner یک knowledge object است، حذف شود، چه اتفاقی برای آن knowledge object می‌افتد؟ زمانی که یک user حذف می‌شود، تمام knowledge object هایی که توسط آن user ایجاد شده‌اند، در سیستم باقی می‌مانند. به این knowledge object ها اصطلاحاً orphaned knowledge object گفته می‌شود یعنی knowledge object یتیم که user مرتبط با آن دیگر در سیستم وجود ندارد. وجود این orphaned knowledge object ها می‌تواند منجر به مشکلات performance و امنیتی شود که باید به نحوی برطرف گردند. فرض کنید یک username در سیستم وجود دارد که کاربر آن انواع search ها را ایجاد می‌کند. اگر این کاربر سازمان را ترک کند و username او از سیستم حذف شود، در صورتی که search های ایجاد شده توسط او از lookup ها و knowledge object های دیگری استفاده می‌کرده‌اند، ممکن است پس از حذف user، آن search ها به درستی عمل نکنند و باعث بروز مشکلات performance شوند. در چنین شرایطی، باید knowledge object هایی که توسط آن کاربر ایجاد شده‌اند را شناسایی کرده و owner آن‌ها را تغییر داد.

Splunk به صورت پیش‌فرض دارای search هایی است که روزانه اجرا می‌شوند و knowledge object های orphaned را شناسایی می‌کنند. این امر باعث می‌شود که در بخش Messages، پیغام‌هایی مرتبط با این موضوع دریافت کنید. برای تغییر  owner مربوط به knowledge object های orphaned، می‌توان از بخش All Configurations استفاده کرد. برای این کار، بر روی All Configurations کلیک کرده و سپس بر روی دکمه Reassign Knowledge Objects کلیک نمایید. در صفحه‌ای که باز می‌شود، با استفاده از گزینه Reassign، می‌توانید به راحتی owner مرتبط با آن knowledge object را تغییر دهید. پس از انتخاب owner جدید، بر روی دکمه Save کلیک کنید تا تغییرات اعمال شود.