Log 管理應用情境

在此 Logs 管理情境案例中,您將從三大面向(建置設定、監控、查詢) 來了解組織中常見在 Logs 管理的 12 種功能需求案例,藉由情境演示將能更有效協助企業將期使情境套用於自身組織中。

案例公司

XX 資訊是一家是提供”資訊系統整合建置服務”的科技公司,開發打造企業資訊系統與端末設備統整資訊平台,並透過監控與分析 IT 系統,以維持公司日常作業與服務,實現穩定的系統運作。

XX 資訊負責資訊科技部門的主管是王經理,他掌管技術開發與 MIS 等二個部門。配合公司的維運與開發,運用了多套軟硬體系統設備。 王經理發現,經常是系統發生異常問題時,IT 是最後一個知道,過於被動。且系統設備過多,Log 資料分散存放,總是需要花很多時間進行人工查找,再加上資料多、欄位格式不相同與無設定關聯性,都大大增加查詢的困難度,既耗時又耗力。

為了能快速精確的搜尋系統問題來源,王經理決定導入 digiLogs 集中管理平台作為公司的 Logs 管理中心,透過單一介面來輕鬆管理各式軟硬體的系統資料記錄,降低團隊查找的時間成本並有效提升管理效率。其中 MIS、開發團隊及管理主管為組織中較常需求使用 Log 集中管理平台的成員。

digiLogs 支援彈性部屬架構

面向一 | 建置設定

情境一:平台使用權限

在這個情境中您將能了解如何在 digiLogs 中建構出組織圖,並賦予不同階層相對應的平台權限以及各式功能模組。

使用者案例

IT 開發部門及 MIS 部門希望將 digiLogs 作為其團隊的軟硬體系統設備之 Log集中管理平台,兩個部門都希望有自己的組織權限規範以及各自需要不同的功能模組來提供給不同工作內容的成員 (Manager , Developer) 進行執行相關工作。

Organization & Roles

Logs 策略團隊作為平台的最高權限單位(HQ_Admin) 從 IT 開發部(BU-01)的需求來設計垂直的組織結構並附賦予組織中不同角色使用者(ex, Manager , Developer) 不同的權限以及功能。

BU-1 Manager 所被授權的內容包含:

授權權限:

  • 權限管理-使用者維護/個人資料維護/登出
  • 系統功能管理-功能維護
  • 監控管理-All
  • Log 查詢- All
  • 交易監控-All
  • Index 管理- All
  • 交易路徑-All

授權角色(作為 BU_Manager, 被賦予可授權下屬的角色列表):

  •  單位主管: BU_Manager
  • 單位開發人員: BU_Developer

功能說明

整合系統認證登入:支援 Oauth2、LDAP、AD、整合 SSO 機制,作法主要是運用 AD Server 作身分驗證,等 AS Server 回傳認證結果後登入成功。在 digiLogs 若管理環境有做切割又想快速完成環境切換的話,可利用登入的「導轉頁」或平台的右上方之「使用者圖示」來點選目標環境。

「整合系統認證登入」示意圖

步驟

步驟一:組織單位維護
點選『權限管理』>『組織單位維護』,進行組織建立

輸入欲建構組織的相關訊息(BU-01, bu01_mgr), 點擊【新增】 創建組織節點

輸入『角色代號』、『角色名稱』(BU-Manager)並點選此角色可使用的『新功能清單』,點選【建立】
步驟二:角色建立

點選『權限管理』>『角色維護』,點選【建立】,進行角色建立

輸入『角色代號』、『角色名稱』(BU-Manager)並點選此角色可使用的『新功能清單』,點選【建立】

步驟三:角色清單設定

點選『權限管理』>『角色清單設定』,將可授權角色授予 “BU_Manager” 此角色。可授權之角色清單: BU_Manager, BU_Developer

步驟四:使用者建立
點選『權限管理』>『使用者維護』,建立一個隸屬於 BU-01 組織底下的使用者: bu01_mgr,並將剛剛創建好的角色授予該使用者以取用其角色被授權之功能。
*若使用 LDAP 驗證,則不需填入密碼。

情境二:平台功能設定

在此情境中您將能了解如何從 digiLogs 的「功能列」角度快速查詢「關聯使用者」,與如何將「功能描述」依產業慣用或喜好名詞做出調整更新。

使用者案例

Alex 身為 MIS 主管在公司的資安稽核期間,會需要整理出一份針對 digiLogs管理平台的所開放的使用者與相應功能權限的報告;也覺得平台上「交易監 控」功能名稱,沒辦法快速連結其功能意義,想要依企業或內部習慣用語做出調整。此時透過「功能查詢」可以一目瞭然 digiLogs 所有功能列表和各別單一功能相關使用者的資訊,若想修改功能名稱和描述,也可自行在平台介面操作修改後達成。

步驟

步驟一:功能搜尋

使用 bu02_mgr 登入後,點選『系統功能管理』>『功能維護』,輸入欲查詢的相關訊息 (功能代碼或功能名稱 , EA0007 ),點擊『動作』>
【關聯角色】,可得到符合條件的角色清單。

步驟二:更新
點選『系統功能管理』>『功能維護』,輸入欲查詢的相關訊息(功能代碼或功能名稱, EA01),點擊『動作』>【更新】。

在『功能名稱』的輸入框,輸入欲修改名稱,也在『功能描述』的輸入框,輸入欲修改的描述(監控報表, 監控系統報表),點擊【更新】,即設定完成。

面向二 | 監控

情境一:平台系統運作

在此情境中您將能了解如何透過平台提供的介面查詢,來確認 digiLogs 本身的運作(健康)狀況。

使用者案例

IT 開發成員 Joe 最近在操作平台時,感覺好像搜尋回覆時間有比較長,所以想確認其系統運作效能狀況。此時可以透過「digiLogs Server 儀表板」可快速了解系統健康狀況及各項指標,包含 Heart beat、Heap、CPU、Thread Pool。

步驟

步驟一:一般搜尋
使用 bu01_dev 登入後,點選『監控管理』>『digiLogs Server 儀表板』,選擇欲查詢時間區間(Week),點擊【搜尋】
步驟二:進階搜尋 (自訂查詢區間)
點選『監控管理』>『digiLogs Server 儀表板』,選擇欲查詢時間區間 (Month),在『日暦』圖示的右邊功能框,(使用 Absolute) 選擇 Start Time 及 End Time,點擊【Update】

情境二:使用者軌跡

在此情境中您將能了解 digiLogs 如何操作查詢介面,來即時查詢平台內的所有使用者的操作行為記錄。

使用者案例

MIS 主管 Alex 因管理需求,要監控 digiLogs 平台的使用狀況,及不定期的抽查特定使用者的詳細操作行為。又到了該執行例行抽查的時候,此時預先準備名單後,再透過平台的「稽核日誌」就可查詢所有或指定使用者,本次欲搜尋檢視 12 月份整體使用情況及抽查 IT 開發成員,如 Joe 等人的使用軌跡。

步驟

步驟一:一般搜尋 (不限條件)

使用 bu02_mgr 登入後,點選『監控管理』>『稽核日誌』,選擇欲查詢起訖時間『Start Time 』(2021-12-01)及 『End Time』(2021-12-31), 點擊【搜尋】,得到所有行為細節

步驟二:快速查詢

可利用「Log 查詢、登入、Index 管理」三項快速鍵來快速查找,並將查詢結果匯出檔案後製作報表。

步驟三:進階搜尋 (特定使用者或條件)

點選『監控管理』>『稽核日誌』,選擇欲查詢起訖時間(2021-12-01~2021-12-31),還可加上「使用者、回傳碼、交易代碼」等其他條件等來查詢(使用者=johnmanager),點擊【搜尋】,得到查詢對象的行為細節

情境三:告警通知

下列情境中您將能了解 digiLogs 如何建立告警設定,協助 IT 化被動為主動,此後只要發生異常,可即時發現立即處理,改善總是被動通知的問題。

使用者案例

MIS 主管 Alex 有注意到,常會發生突然被通知系統有異常狀況,需要緊急指派組內開發人員 Tony 協助處理。Alex 對此流程想做出改善,在 digiLogs 導入 後,發現平台除了預設的 Server Node 之外,可利用 keyword 模式、告警條件及通知對象來設定告警,可以達到化被動為主動的需求,以後再發生相同異常時,被設定通知的人員就會收到主動的告警通知,後續再回到 digiLogs 找原因進行處理即可。
(若您手上已有欲建立的告警設定,也可依步驟於此頁操作設定)

在此先簡單說明『告警設定』的頁面欄位意義如下:

下列情境,皆是接獲來自使用者的異常通報,經查發現疑似因系統執行作業運作狀況很不穩定,會發生不明原因的執行中斷或失敗,造成終端使用者整體操作流程不能順利完成,想要針對這幾個異常,建立相關的告警機制,以便後續追蹤、處理。

- 排程作業

MIS 開發成員 Tony 接獲來自使用者的異常通報,經查發現主因是”排程作業”系統的執行作業運作狀況不穩定而導致執行失敗,造成終端使用者整體操作流程不能順利完成,因為近期發生此類情況較多,決定向 Logs 策略團隊請求將其列入告警設定通知的行列,進行監控觀察。

步驟

步驟一:新增告警

點選『監控管理』>『告警設定』,點擊【建立】

步驟二:告警條件設定

情境描述:當排程作業每”30 秒”發生2次執行”失敗”時,角色:BU-
Developer, BU-Manager 的全群組人員就會收到告警通知。

頁面的欄位請依下列”範例資料”輸入完畢後,點選【建立】即可完成。

確認建立成功

異常通知信件

- 寄件歷程

IT 開發成員 Joe 發現最近的”寄件歷程”好像有些異常發生,造成寄件失敗,為避免此類問題再次發生,決定主動向 Logs 策略團隊請求將其列入告警設定通知的行列,進行監控觀察。

步驟
步驟一:新增告警

點選『監控管理』>『告警設定』,點擊【建立】

步驟二:告警條件設定

情境描述:當寄件歷程有發生”1 次”寄件”失敗”的情況,角色:BU-
Developer 的全群組人員就會收到告警通知。

頁面的欄位請依下列”範例資料”輸入完畢後,點選【建立】即可完成。

確認建立成功

異常通知信件

- 事件檢視器

IT 開發成員 Joe 以往每日都需人工監控”API 管理平台(digiRunner)”各模組 (Module)之工作執行狀況,主要是因 Module 發生異常狀態,影響甚遠,主管相當重視。在導入 digiLogs 之時,Joe 想要化被動為主動,決定向 Logs 策略團隊請求將”事件檢視器”(所有執行事件結果)加入告警設定,往後便只有在收到異常通知才回到系統查看即可。

步驟
步驟一:新增告警

點選『監控管理』>『告警設定』,點擊【建立】

步驟二:告警條件設定

情境描述:當事件檢視器有發生”1 次”的”未知的錯誤”的事件時,角色:BU-Developer 的全群組人員就會收到告警通知。

頁面的欄位請依下列”範例資料”輸入完畢後,點選【建立】即可完成。

確認建立成功

異常通知信件

情境四:交易分析圖表

在此情境中您將能了解 digiLogs 還可依企業需求協助開發客製相應的監控報表,並以圖像化的報表讓運作狀況能一目瞭然,也可做簡單分析。

使用者案例

IT 主管 Bill 以往就需定期向王經理匯報各系統運作與使用狀況,尤其在重大系統上線後,其運作與使用狀況的相關數據報告被視為重點關注的項目。因為會議時間有限,Bill 希望能一目瞭然且簡單易懂方式來呈現報表內容,另外還可即時監控報表各指標有沒有時間過長、異常等問題,需要做出改善。對此 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 秒)且明顯超出平均線,可以借由此資訊來參考判斷數據是否合理,需不需要做出相應的改善。

- 應用程式(App)系統情境

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)管理系統情境

最近才上線的”應用程式介面(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 全貌
  • 關鍵字查詢:找到線索來鎖定目標
  • 動態查詢:快速的找出 log 異常點
  • 屏蔽保護:在敏感性資料加上安全性保護,可自行設定屏蔽條件,來確保內容涉及個資等問題時,能自動以隱碼屏蔽來得到保護

步驟

(若您手上已有欲查詢 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。

(* 圖示中,cid 是經屏蔽保護的資料呈現方式)

畫面顯示切換(表格/卡片式)

情境二:關聯查詢

在此情境中您將能了解 digiLogs 如何透過「關聯查詢」從中找到與其他資料源的相關連之線索,依其脈絡得知該 Log 經過各系統的交易資訊。

使用者案例

某日,MIS 成員 Tony 在接到查詢任務後,至平台來查找”金流(網路銀行)系統”發生異常的原因,因其系統涉及到其他系統,在過程中需要解析出每列 Log 特定關鍵字,再依線索去檢索其他來源,找到相關聯 Log 資料及經過各系統的交易資訊。以往接到查詢任務後,專責人員就需至某系統來查詢 Log 來查找異常原因,若涉及多個系統,就需要切換多個系統,才能完整掌握相關資訊與關 連,整體過程既麻煩又攏長。運用 digiLogs 可改善此情況,透過平台提供統整多個資料源的服務,查詢時設定目標條件後,從結果中找到與其他來源的相關聯資料線索。

步驟

(若您手上已有欲查詢 log 的條件,也可依步驟於此頁操作設定)
步驟一:設定查詢條件

以 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 也提供相同功能,可透過簡單的操作點選及自訂時序,達到查詢的目標,找到發生異常的根本原因。

步驟

(若您手上已有欲查詢 log 的條件,也可依步驟於此頁操作設定)
步驟一:設定查詢條件

以 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」設定重啟後,該資料可短暫被查詢。

功能說明
  • 熱資料:是近期、可直接在 digiLogs 查詢的資料
  • 冷資料:距今較久遠的歷史資料,digiLogs 會將不被使用的資料,做封存處理。可透過操作設定,將其暫時轉換成「熱資料」以便直接查詢使用。

在 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 的數據整理歸納及繪製圖表。

情境五:Read File 代管

在此情境中您將能了解 digiLogs 如何協助企業做「Read File」代管,設定過後直接於平台開箱使用,可即時監看企業 log 檔案。

使用者案例

王經理導入 digiLogs 集中管理平台,就是希望透過單一介面來輕鬆管理各式軟硬體的系統資料記錄,降低團隊查找的時間成本並有效提升管理效率。為了協助企業完成「Logs 管理中心」的期望,digiLogs 提供「Read File」的代管功能,免去傳統需逐個系統輸入完整設定資料(IP、Port、ID、PWD 等)的工序,只要透過簡單且一次性的設定,在提供的單一介面裡,就可快速切換監看各 Log 檔案的即時資料。

功能說明

cat 模式:是 Lunix 用來檢視檔案內容的指令;常用於顯示整個檔案的內容,或者合併多個檔案。

tail 模式:亦是 Lunix 用來檢視檔案內容的指令;主要用來顯示檔案的最後幾行內容,當檔案內容有更新時,它會主動重新整理,檔案內容資料是最新的。

步驟

(若您手上已有欲設定的主機,也可依步驟於此頁操作設定)
步驟一:設定主機

點選『Read File 管理』>『主機維護』,點選【新增主機】

在對應欄位內,輸入欲使用的主機名稱、IP 及存放 Log 的目錄路徑,點選【建立】

步驟二:設定分類日誌

點選『Read File 管理』>『分類日誌維護』,點選【建立】

在對應欄位內,輸入欲使用的主系統、業務別、主機名稱、路徑及其他相關資料,點選【建立】

步驟三:查詢已發生之過往 File - cat 模式

(為明顯看出差異,查詢起訖日期,請查詢當日以前之日期)

點選『Log 查詢』>『Read File』,拉選目標的『系統』及『業

務』,再選擇目標的『目錄(主機) 』(主機=apiModule(digirunner)),選擇欲查詢起訖時間,亦可在『關鍵字搜尋』輸入欲查詢的內容(dgr-cus-etb_cg-v3.8.4.24.log),點選【搜尋】

選擇 cat 模式,找到目標檔案名稱後(需選擇”副檔名為.log”),在『動作』欄位,點選【預覽】,此動作可於單一視窗查詢完整的內容。

步驟四:查詢即時 File - tail 模式

(為明顯看出差異,查詢起訖日期,請查詢當日日期)

點選『Log 查詢』>『Read File』,拉選目標的『系統』及『業

務』,再選擇目標的『目錄(主機) 』(主機=apiModule(digirunner)),選擇欲查詢起訖時間,亦可在『關鍵字搜尋』輸入欲查詢的內容 (tsmpc-v3.10.0),點選【搜尋】

選擇 tail 模式,找到目標檔案名稱後(需選擇”副檔名為.log”),在『動作』欄位,點選【預覽】,此動作可於單一視窗查詢到最後幾行內容,當檔案內容有更新時,亦會主動整理至該視窗呈現。

在查詢結果中,可依需求做 cat、tail 模式切換與支援多個字元編碼( BIG 5、 UTF-8、ASCII)。