選單
在此 Logs 管理情境案例中，您將從三大面向(建置設定、監控、查詢) 來了解組織中常見在 Logs 管理的 12 種功能需求案例，藉由情境演示將能更有效協助企業將期使情境套用於自身組織中。
案例公司
XX 資訊是一家是提供”資訊系統整合建置服務”的科技公司，開發打造企業資訊系統與端末設備統整資訊平台，並透過監控與分析 IT 系統，以維持公司日常作業與服務，實現穩定的系統運作。
為了能快速精確的搜尋系統問題來源，王經理決定導入 digiLogs 集中管理平台作為公司的 Logs 管理中心，透過單一介面來輕鬆管理各式軟硬體的系統資料記錄，降低團隊查找的時間成本並有效提升管理效率。其中 MIS、開發團隊及管理主管為組織中較常需求使用 Log 集中管理平台的成員。
在這個情境中您將能了解如何在 digiLogs 中建構出組織圖，並賦予不同階層相對應的平台權限以及各式功能模組。
IT 開發部門及 MIS 部門希望將 digiLogs 作為其團隊的軟硬體系統設備之 Log集中管理平台，兩個部門都希望有自己的組織權限規範以及各自需要不同的功能模組來提供給不同工作內容的成員 (Manager , Developer) 進行執行相關工作。
Logs 策略團隊作為平台的最高權限單位(HQ_Admin) 從 IT 開發部(BU-01)的需求來設計垂直的組織結構並附賦予組織中不同角色使用者(ex, Manager , Developer) 不同的權限以及功能。
BU-1 Manager 所被授權的內容包含：
授權權限：
授權角色(作為 BU_Manager, 被賦予可授權下屬的角色列表)：
功能說明
整合系統認證登入：支援 Oauth2、LDAP、AD、整合 SSO 機制，作法主要是運用 AD Server 作身分驗證，等 AS Server 回傳認證結果後登入成功。在 digiLogs 若管理環境有做切割又想快速完成環境切換的話，可利用登入的「導轉頁」或平台的右上方之「使用者圖示」來點選目標環境。
輸入欲建構組織的相關訊息(BU-01, bu01_mgr), 點擊【新增】 創建組織節點
點選『權限管理』>『角色維護』，點選【建立】，進行角色建立
輸入『角色代號』、『角色名稱』(BU-Manager)並點選此角色可使用的『新功能清單』，點選【建立】
點選『權限管理』>『角色清單設定』，將可授權角色授予 “BU_Manager” 此角色。可授權之角色清單: BU_Manager, BU_Developer
在此情境中您將能了解如何從 digiLogs 的「功能列」角度快速查詢「關聯使用者」，與如何將「功能描述」依產業慣用或喜好名詞做出調整更新。
使用 bu02_mgr 登入後，點選『系統功能管理』>『功能維護』，輸入欲查詢的相關訊息 (功能代碼或功能名稱 , EA0007 )，點擊『動作』>
【關聯角色】，可得到符合條件的角色清單。
在『功能名稱』的輸入框，輸入欲修改名稱，也在『功能描述』的輸入框，輸入欲修改的描述(監控報表, 監控系統報表)，點擊【更新】，即設定完成。
IT 開發成員 Joe 最近在操作平台時，感覺好像搜尋回覆時間有比較長，所以想確認其系統運作效能狀況。此時可以透過「digiLogs Server 儀表板」可快速了解系統健康狀況及各項指標，包含 Heart beat、Heap、CPU、Thread Pool。
使用 bu02_mgr 登入後，點選『監控管理』>『稽核日誌』，選擇欲查詢起訖時間『Start Time 』(2021-12-01)及 『End Time』(2021-12-31)， 點擊【搜尋】，得到所有行為細節
可利用「Log 查詢、登入、Index 管理」三項快速鍵來快速查找，並將查詢結果匯出檔案後製作報表。
點選『監控管理』>『稽核日誌』，選擇欲查詢起訖時間(2021-12-01~2021-12-31)，還可加上「使用者、回傳碼、交易代碼」等其他條件等來查詢(使用者=johnmanager)，點擊【搜尋】，得到查詢對象的行為細節
在此先簡單說明『告警設定』的頁面欄位意義如下：
下列情境，皆是接獲來自使用者的異常通報，經查發現疑似因系統執行作業運作狀況很不穩定，會發生不明原因的執行中斷或失敗，造成終端使用者整體操作流程不能順利完成，想要針對這幾個異常，建立相關的告警機制，以便後續追蹤、處理。
MIS 開發成員 Tony 接獲來自使用者的異常通報，經查發現主因是”排程作業”系統的執行作業運作狀況不穩定而導致執行失敗，造成終端使用者整體操作流程不能順利完成，因為近期發生此類情況較多，決定向 Logs 策略團隊請求將其列入告警設定通知的行列，進行監控觀察。
點選『監控管理』>『告警設定』，點擊【建立】
情境描述：當排程作業每”30 秒”發生２次執行”失敗”時，角色：BU-
Developer, BU-Manager 的全群組人員就會收到告警通知。
頁面的欄位請依下列”範例資料”輸入完畢後，點選【建立】即可完成。
確認建立成功
異常通知信件
IT 開發成員 Joe 發現最近的”寄件歷程”好像有些異常發生，造成寄件失敗，為避免此類問題再次發生，決定主動向 Logs 策略團隊請求將其列入告警設定通知的行列，進行監控觀察。
點選『監控管理』>『告警設定』，點擊【建立】
情境描述：當寄件歷程有發生”1 次”寄件”失敗”的情況，角色：BU-
Developer 的全群組人員就會收到告警通知。
確認建立成功
異常通知信件
IT 開發成員 Joe 以往每日都需人工監控”API 管理平台(digiRunner)”各模組 (Module)之工作執行狀況，主要是因 Module 發生異常狀態，影響甚遠，主管相當重視。在導入 digiLogs 之時，Joe 想要化被動為主動，決定向 Logs 策略團隊請求將”事件檢視器”(所有執行事件結果)加入告警設定，往後便只有在收到異常通知才回到系統查看即可。
點選『監控管理』>『告警設定』，點擊【建立】
情境描述：當事件檢視器有發生”1 次”的”未知的錯誤”的事件時，角色：BU-Developer 的全群組人員就會收到告警通知。
頁面的欄位請依下列”範例資料”輸入完畢後，點選【建立】即可完成。
確認建立成功
異常通知信件
在此情境中您將能了解 digiLogs 還可依企業需求協助開發客製相應的監控報表，並以圖像化的報表讓運作狀況能一目瞭然，也可做簡單分析。
Bill 認為針對”金流(網路銀行)系統”所關心的維度在於系統 action 及 hostname與時間次數的相互關係，因此提出的客製需求，希望是系統 action 之平均使用次數與時間、登入系統 hostname 與平均時間，再適當著表格式、長條圖、折線圖來呈現資訊。
以 bu01_mgr 角色登入，點選『交易監控』>『網銀平均交易時間分析』，選擇欲查詢時間區間 (Month)， 點擊【搜尋】
以 bu01_mgr 角色登入，點選『交易監控』>『網銀平均交易時間分析』，在『日暦』圖示的右邊功能框，(使用 Absolute) 選擇 Start Time(2021-12-01) 及 End Time(2021-12-15)，點擊【Update】即可
查詢結果向下拉至本次目標，發現在圖表「網銀交易平均時間分析 圖」內，第一項的 action 平均時間最長(需耗時 6 秒)且明顯超出平均線，可以借由此資訊來參考判斷數據是否合理，需不需要做出相應的改善。
Bill 將”應用程式(App)”維度設定，在 App 系統的 action 及 hostname 與時間次數的相互關係。所以報表需求為：App 的 action 之平均使用次數與時間、登入 App 的 hostname 與平均時間，並適當搭配著表格式、長條圖、折線圖來呈現資訊。
以 bu01_mgr 角色登入，點選『交易監控』>『APP 平均交易時間分析』，選擇欲查詢時間區間 (Month)， 點擊【搜尋】
點選『交易監控』>『APP 平均交易時間分析』，在『日暦』圖示的右邊功能框，(使用 Absolute) 選擇 Start Time(2021-12-01) 及 End Time(2021-12-15)，點擊【Update】即可
查詢結果向下拉至本次目標，發現在圖表「APP 交易平均時間分析 Table」內，第一項的 action 平均時間最長(需耗時 2 秒)，可以借由此資訊來參考判斷數據是否合理，需不需要做出相應的改善。
最近才上線的”應用程式介面(API)管理系統”，Bill 希望的報表以：流量分析、回應時間(Max/Min)、使用次數(區分成功/失敗) “、API(僅成功)次數-時間分析、 API(僅成功)平均時間、Client-API 使用次數、Bad Attempt 連線報告等數據，並搭配著表格式、長條圖、折線圖來完整呈現資訊。
以 bu01_mgr 角色登入，點選『交易監控』>『API 平均時間計算分析』，選擇欲查詢時間區間 (Month)， 點擊【搜尋】
點選『交易監控』>『API 平均時間計算分析』，在『日暦』圖示的右邊功能框，(使用 Absolute) 選擇 Start Time (2021-12-01)及 End Time(2021-12-15)，點擊【Update】即可
查詢結果向下拉至本次目標，發現在圖表「7.TSMP API 流量分析」內，此段時間區間的 API 流量高峰在於”15:46″且高達 50 次，可以借由此資訊來參考判斷數據是否合理，需不需要做流量控管的設定。
在此情境中您將能了解 digiLogs 可協助企業實現 Log 路徑地圖，客製化將監控系統串連，以一頁式圖像化方式呈現，可快速得知發生異常系統及聯繫對象方式。
IT 主管 Bill 發現網路銀行的子系統相互之間是具有關連性的，若能將這些子系統的 Logs 整合串連在一起，未來當系統異常發生時能更快且清楚的查找，再做出適當的處理。對此 digiLogs 協助該部門開發路徑地圖，將所有的子系統依關聯性串連整合後，採取「一頁式網頁」方式呈現，讓監控人員能快速且即時的查看各系統之間的運作狀況。
點選『交易路徑地圖』，即可一覧各系統資料運作正常。
當異常發生時，該(個人網銀)系統的『平均時間』會出現「紅字」
點擊異常系統『平均時間』>確認其『系統別』及『交易別』狀態
點擊異常系統『 icon』>可查看相關負責人聯繫方式
在此情境中您將能了解 digiLogs 要如何使用「動態查詢欄位」找到精確的找到目標 Log 資料。
某日”API 集中系統”發生異常情況，MIS 成員 Tony 在接到任務需求後，初步研判可能是當中某一隻 API 執行造成異常。需至平台依其預測條件做”動態查詢 “，來驗證及確認該異常原因，並完成後續處理作業。過去在接獲通報後，因線索不多，僅得知需查詢 Log 的目標資料源，只能透過指令，以循序的方式從全文開始探索，逐漸縮小範圍，才能掌握相關資訊，整個查找程序是繁瑣的。在導入 digiLogs 後，過去不便可得以解決，平台除了提供”點選模式”來完成全文檢索之外，還可自訂關鍵字或動態條件來查詢內容，操作更加簡單又可精確掌握查詢結果。
(若您手上已有欲查詢 log 的條件，也可依步驟於此頁操作設定)
以 bu02_dev 登入，點選『Log 查詢』>『Log 查詢』，選擇欲查詢起訖時間（2021/12/27~2021/12/31) ，選擇要查詢的資料來源(Index＝ dgr_sit_api_log_*)，點選【搜尋】
承接上個步驟，於「關鍵字搜尋」輸入”rtnCode”，點選【搜尋】，欄位勾選：No.、cid、ResHeader.rtn、CodeResHeader.rtnMsg、 mbody
(ps:關鍵字輸入時，字串的前後需加上”，例：”test”)
承接上個步驟，在『新增依欄位條件查詢』，點選『增加』
下拉選擇「欄位」＝’ResHeader.rtnCode’、「運算子」＝’is not’、
「值」＝’1100’及「欄位」＝’ResHeader.rtnCode’、「運算子」＝’is not’、「值」＝空白，點選【搜尋】，資料查詢成功
承接上一步的查詢結果，在資訊欄位(位於『表格』與『匯出』中間)裡，選擇欲呈現的欄位內容，還可將資料匯出(.xlsx)。欄位勾選： No.、cid、ResHeader.rtnCode、ResHeader.rtnMsg、mbody。
畫面顯示切換(表格/卡片式)
在此情境中您將能了解 digiLogs 如何透過「關聯查詢」從中找到與其他資料源的相關連之線索，依其脈絡得知該 Log 經過各系統的交易資訊。
某日，MIS 成員 Tony 在接到查詢任務後，至平台來查找”金流(網路銀行)系統”發生異常的原因，因其系統涉及到其他系統，在過程中需要解析出每列 Log 特定關鍵字，再依線索去檢索其他來源，找到相關聯 Log 資料及經過各系統的交易資訊。以往接到查詢任務後，專責人員就需至某系統來查詢 Log 來查找異常原因，若涉及多個系統，就需要切換多個系統，才能完整掌握相關資訊與關 連，整體過程既麻煩又攏長。運用 digiLogs 可改善此情況，透過平台提供統整多個資料源的服務，查詢時設定目標條件後，從結果中找到與其他來源的相關聯資料線索。
以 bu02_dev 登入，點選『Log 查詢』>『Log 查詢』，選擇欲查詢起訖時間(2021/12/29~2021/12/31)，選擇要查詢的資料來源(Index＝pb-
*)，點選【搜尋】。欄位勾選(No.、PmtID、logtime、action、 source、message)
從查詢結果表，移至最右側的『動作』欄位，點擊【Message 詳細資料】。
從『Message 詳細資料』中，逐一查找各系統間的相關連資訊，在本例在第五筆資料中找到 Call API 的線索。最後可視需求，搭配『關鍵字查詢』或『動態查詢』，找到更精確的結果。
在此情境中您將能了解 digiLogs 如何透過「查詢更多」，以自訂日誌時序找到該 Log 上下連續性日誌，以找出系統異常的根本原因(Root Cause)。
某日，MIS 成員 Tony 在接到任務後，至平台來查找”金流(網路銀行)系統”發生異常的原因，過程中想更加了解發生系統異常的根本原因，因此利用平台提供的設定「時間範圍」功能，得到該 Log 完整上下連續日誌，藉以提出適切的解決方案。過去專責人員在查找 Log 的時候，為能更加完整的了解 Log 的樣貌，會以時間軸當中心，來查詢該 Log 的上下連續性日誌。digiLogs 也提供相同功能，可透過簡單的操作點選及自訂時序，達到查詢的目標，找到發生異常的根本原因。
以 bu02_dev 登入，點選『Log 查詢』>『Log 查詢』，選擇欲查詢起訖時間(2021-12-29~2021-12-31)，選擇要查詢的資料來源(Index＝ pb-*)，點選【搜尋】。欄位勾選：No.、PmtID、logtime、action、 source、 message。
選擇 PmtID=2020122531279601，於『動作』>點選【查詢更多】，拖拉設定時間範圍(Time Range(s)=200 ，File Size=1），點選【搜尋】
拖拉設定時間範圍(Time Range(s)=200， File Size=50），點選【搜尋】。
在此情境中您將能了解如何在 digiLogs 將封存的「歷史資料」重新啟用後，就直接在平台中透過「Log 查詢」做即時的查詢。
過去，MIS 團隊會將歷史資料做打包壓縮的處理，當翻查過去資料時，就得將整包資料解壓縮後，再逐一查找到目標日期的檔案資料，不僅查找時間過長、過程又麻煩。而 digiLogs 提供了更簡便的方法來協助企業，因平台會依儲存資料距今時間的遠近，將資料分成冷、熱資料。當需查詢冷資料時，可透過「查詢 Index」設定重啟後，該資料可短暫被查詢。
在 2022 年 01 月時，MIS 成員 Tony 接到任務，因查覺本月的 API 使用率有疑似過高的情況，主管要求驗證數據，因此需查詢 2021 年 12 月與 2022 年 01 月的 API Log 資料，將其資料結果比對，做出比較的報告書。然而當中的 2021 年 12 月資料已經成為「冷資料」，此時需利用平台提供的重啟設定「冷資料」功能，就能在「查詢 Index」直接查詢與匯出 Log 資料，之後再做彙整比對，完成相關報告書。
以 bu02_dev 登入。點選『Index 管理』>『查詢 Index』，選擇欲查詢起訖時間(2021-12-01~2021-12-31)，選擇要查詢的資料來源 (index=dgr_sit_api_log_*)，點選【搜尋】
選擇欲查詢的日期資料(2021-12-01~2021-12-31)，選擇要查詢的資料來源(Index=dgr_sit_api_log_*)，點選【搜尋】，選擇欲開啟的日期後，點選【開啟】
點選『Log 查詢』>『Log 查詢』，選擇欲查詢起訖時間(2021-12-01~2021-12-31)，選擇要查詢的資料來源(Index=dgr_sit_api_log_*)，點選【搜尋】
透過上述的方式，可協助將歷史資料快速、暫時的重新啟用，以取得欲比對的檔案，經匯出後，可做 MoM 的數據整理歸納及繪製圖表。
在此情境中您將能了解 digiLogs 如何協助企業做「Read File」代管，設定過後直接於平台開箱使用，可即時監看企業 log 檔案。
王經理導入 digiLogs 集中管理平台，就是希望透過單一介面來輕鬆管理各式軟硬體的系統資料記錄，降低團隊查找的時間成本並有效提升管理效率。為了協助企業完成「Logs 管理中心」的期望，digiLogs 提供「Read File」的代管功能，免去傳統需逐個系統輸入完整設定資料(IP、Port、ID、PWD 等)的工序，只要透過簡單且一次性的設定，在提供的單一介面裡，就可快速切換監看各 Log 檔案的即時資料。
cat 模式：是 Lunix 用來檢視檔案內容的指令；常用於顯示整個檔案的內容，或者合併多個檔案。
tail 模式：亦是 Lunix 用來檢視檔案內容的指令；主要用來顯示檔案的最後幾行內容，當檔案內容有更新時，它會主動重新整理，檔案內容資料是最新的。
點選『Read File 管理』>『主機維護』，點選【新增主機】
在對應欄位內，輸入欲使用的主機名稱、IP 及存放 Log 的目錄路徑，點選【建立】
點選『Read File 管理』>『分類日誌維護』，點選【建立】
在對應欄位內，輸入欲使用的主系統、業務別、主機名稱、路徑及其他相關資料，點選【建立】
(為明顯看出差異，查詢起訖日期，請查詢當日以前之日期)
點選『Log 查詢』>『Read File』，拉選目標的『系統』及『業
務』，再選擇目標的『目錄(主機) 』(主機=apiModule(digirunner))，選擇欲查詢起訖時間，亦可在『關鍵字搜尋』輸入欲查詢的內容(dgr-cus-etb_cg-v3.8.4.24.log)，點選【搜尋】
選擇 cat 模式，找到目標檔案名稱後(需選擇”副檔名為.log”)，在『動作』欄位，點選【預覽】，此動作可於單一視窗查詢完整的內容。
(為明顯看出差異，查詢起訖日期，請查詢當日日期)
點選『Log 查詢』>『Read File』，拉選目標的『系統』及『業
務』，再選擇目標的『目錄(主機) 』(主機=apiModule(digirunner))，選擇欲查詢起訖時間，亦可在『關鍵字搜尋』輸入欲查詢的內容 (tsmpc-v3.10.0)，點選【搜尋】
選擇 tail 模式，找到目標檔案名稱後(需選擇”副檔名為.log”)，在『動作』欄位，點選【預覽】，此動作可於單一視窗查詢到最後幾行內容，當檔案內容有更新時，亦會主動整理至該視窗呈現。
在查詢結果中，可依需求做 cat、tail 模式切換與支援多個字元編碼( BIG 5、 UTF-8、ASCII)。