簡單來說我覺得 Splunk admin 課程對於現在的我來說實在有點太簡單，簡單的原因有兩個
- 操作大多使用 Web UI
對我這種控制狂來說，使用 Web UI 實在讓我無法有效控制 Splunk 系統中每行設定，此外我是很喜歡在設定上寫很多註解的人，使用 Web UI 基本上我甚麼都做不到，這讓我無法接受。當然我也是會看人是否使用 config 做系統設定，來評斷這個人是否擅長維護一套系統的。 - 本身就維護一套中型的 Splunk Cluster
因為工作上需求，我個人已經可以獨立建置與維護一套中型的 Splunk Cluster 因此 System Admin 課程確實對我沒什麼實質幫助。
也因為也上兩點，所以這篇寫得蠻隨興的，基本上不會教怎麼配置啦，這種簡單的東西就去查 Splunk document 就好了，人家寫 Document 不就為了方便你上手嗎? 為什麼還要花錢去上課呢?
Configure Splunk
Splunk 在系統設定上分成三種模式，分別是
- Splunk Web UI 控制
- Splunk CLI 控制
- Config 編修控制
個人不太喜歡在 Cluster 架構上使用 Web UI 與 CLI 做系統設定編輯，因為這樣的設定最後會被寫入 $SPLUNK_HOME/etc/system/local 下，會造成未來若需編修 config 則不一定生效，或是同 stanza 設定放置到不同檔案向，變得更難維護。
在多個官方文件中也寫出，用 Web UI 修改 Splunk 系統設定是可行的，但是如果需要做非常細節的控制，建議還是直接修改 Config。目前在公司的架構裡面，所有的設定還經過 version control 系統，那使用 config 設定系統才更方便，而在後續才能繼續採用 GitLab CI/CD。
但是 Web UI 確實會帶來一些好處，例如在接 LDAP 與建立 Index 時候不用重新啟動 Splunk service，而往往在重新啟動的過程中影響各種使用者與 repor, alert 的執行。因此各有好處，但是個人認為在系統越趨向巨大發展的情況下，選擇編修Config 來控制 Splunk 是絕對具好諸多好處的。
Splunk License Management
合不合法使用授權，在我們公司或是在各個公司都是極度看重的，因此前段時日就依據授權使用規則訂製公司內部的審核規範。
這邊還要說明，因為一天產生的 internal log 實在太多了，如果為了每天產生一個 Splunk License 依據 index 資料量的報表，這份報表會跑兩個小時然後跑到 timeout，所以特別使用 Accelerate reports 來加速特定幾個 search，讓報表可以順利產生。
PS. 因目前在做 SIEM migration 專案，跟 Splunk 申請非常大的 trial license，但是還是會有超量使用的狀況，但因為我設定時把 Enterprise license 與 trial license 何在一起使用，因此 trial license 那種連續五天超用就會鎖 search 功能的限制就被覆蓋了。
Install an App
其實在做 SIEM migration 的過程中，我仍然認為 Splunk 的 Add-On 還是極度缺乏，連 Splunk 官方維護的幾個產品 Add-On 都有殘缺不全的部分，例如: Linux (auditd 無 CIM), VMware 的 vCenter 沒有 SSO (CIM authentication)，這些讓我在專案中基本上都要再客製化開發。
此外我認為產品公司自己開發的 Add-On 就很全面，有用過的有 Cisco, Palo alto 或是 Bluecoat，很多都是 Add-On 套上去，資料欄位就已經完成 parsing，甚至已經可以進 CIM 做資料欄為加速。
其實 Add-On 也是增加 Splunk Input 功能的一種方式，當然也有增加 Output 功能，但是 Splunk Output 功能真的太多了，凡舉想到的應該除了 SMS 外所有的企業用通訊軟體都支援了。但是 Input 的功能除了官方提供的 TCP, UDP, HEC, File monitor 外基本上就沒有了，當然簡單的 input 對於 System Admin 來說是輕鬆很多，但是當大家都往 cloud 走的今天，支援不夠多的 cloud service，就會造成 Admin 的負擔了，因為必須為此多開發程式。
Examine User Configuration Files
其實有時候覺得 User 真的會搞出很多很神奇的東西，在 Splunk 的世界裡，一個設定檔案可能真的會存放在多個目錄下，例如有一個 search macro，他可能會被同時定義在以下兩個地方
- $SPLUNK_HOME/etc/app/<appname>
- $SPLUNK_HOME/etc/users/<username>/<appname>
因此確實有可能兩個使用者看到的 search 結果相異，結果就會來找 admin 問東問西，問時不是 admin 做 change 的時候沒有通知使用者。身為 admin 真的會想把這種使用者打死在地上。
不過 global context 情況設定的優限度會是以下在這個情況下，Splunk 會嘗試合併個個設定檔案，例如
- $SPLUNK_HOME/etc/system/local <– Web UI, CLI 修改的位置
- $SPLUNK_HOME/etc/app/<appname>/local
- $SPLUNK_HOME/etc/app/<appname>/default
- $SPLUNK_HOME/etc/system/default
在這個情況下，Splunk 會嘗試合併各個設定檔案，例如: inputs, authentication 就屬於此類，也因為這樣 Web UI, CLI 的改動才有可能造成 app 內設定並不一定會能正確工作。
如果是 app or user context 來運行 Splunk 時的狀態又不相同了
- User directories for the current user
- App directories for currently running app (local, followed by default)
- App directories for all other apps (local, followed by default)
- System directories (local, followed by default)
而那些屬於前者，又或那些屬於後者，Splunk 的文件上也有很清楚地說明了，這便就送個連結 List of configuration files and their context