このログ管理シナリオでは、組織内のログ管理に共通する 12 の機能要件ケースを 3 つの側面 (構築設定、監視、クエリ) から理解することができ、シナリオのデモンストレーションにより、企業が期待される要件を満たすのをより効果的に支援できます。コンテキストを自分の組織に適用します。
ケースカンパニー
ゼクス・インフォメーションは、企業情報システムや端末機器などの統合情報プラットフォームの開発・構築、ITシステムの監視・分析を通じて企業の日常業務・サービスを維持し、企業目標を達成する「情報システム統合・構築サービス」を提供するテクノロジーカンパニーです。安定しています システムは動作します。
システム問題の原因を迅速かつ正確に検索するために、王マネージャーは、会社のログ管理センターとしてdigiLogs集中管理プラットフォームを導入し、単一のインターフェイスを通じてさまざまなソフトウェアおよびハードウェア システム データ レコードを簡単に管理し、時間コストを削減することにしました。チームの検索と効果的な管理効率の向上。その中でも、MIS、開発チーム、管理監督者は、Log 集中管理プラットフォームを使用する必要が多い組織のメンバーです。
このシナリオでは、digiLogsで組織図を構築し、さまざまなレベルに対応するプラットフォーム権限とさまざまな機能モジュールを与える方法を理解できるようになります。
IT 開発部門と MIS 部門は、チームのソフトウェアおよびハードウェア システム機器の集中ログ管理プラットフォームとしてdigiLogsを使用したいと考えています。両部門は独自の組織権限仕様を持ち、異なる作業内容を提供するためにそれぞれ異なる機能モジュールが必要です。 . メンバー (マネージャー、開発者) は、関連する作業を実行します。
プラットフォームの最高権限部門 (HQ_Admin) として、ログ戦略チームは IT 開発部門 (BU-01) の要件に基づいて垂直組織構造を設計し、組織内のさまざまな役割のユーザーにさまざまな権限と機能を割り当てます (例、マネージャー、開発者)。
BU-1 マネージャーには以下を含めることが許可されています。
認可権限：
認可ロール (BU_Manager として、部下を認可できるロールのリストが与えられます):
機能の説明
統合システム認証ログイン: Oauth2、LDAP、AD、および統合 SSO メカニズムをサポートします。主な方法は ID 認証に AD サーバーを使用することであり、AS サーバーが認証結果を返した後にログインが成功します。digiLogsでは、管理環境が分割されており、素早く環境切り替えを完了させたい場合は、ログインの「移行ページ」またはプラットフォーム右上の「ユーザーアイコン」から移行先の環境をクリックしてください。
構築する組織(BU-01、bu01_mgr)の関連情報を入力し、[追加]をクリックして組織ノードを作成します
[権限管理] > [ロールのメンテナンス] をクリックし、[作成] をクリックしてロールを作成します。
「ロールコード」、「ロール名」(BU-Manager)を入力し、このロールで利用可能な「新規機能リスト」をクリックし、[作成]をクリックします。
「権限管理」＞「ロール一覧設定」をクリックし、「BU_Manager」に権限のあるロールを付与します。許可されたロールのリスト: BU_Manager、BU_Developer
このシナリオでは、digiLogsの「機能バー」の観点から「関連ユーザー」を迅速にクエリする方法と、業界の使用法や優先用語に従って「機能の説明」を調整および更新する方法を学ぶことができます。
bu02_mgrでログイン後、「システム機能管理」>「機能メンテナンス」をクリックし、照会する関連情報(機能コードまたは機能名、EA0007)を入力し、「アクション」をクリック>
【関連ロール】では、該当するロールの一覧を取得できます。
「関数名」の入力ボックスに変更したい名前を入力し、「関数の説明」の入力ボックスにも変更したい説明（監視レポート、監視システムレポート）を入力し、［更新］をクリックします。 ]を押して設定を完了します。
IT 開発者のジョーは、最近、プラットフォームを操作する際の検索応答時間が比較的長いと感じたため、システムの動作パフォーマンスを確認したいと考えていました。このとき、「digiLogsサーバーダッシュボード」を通じて、ハートビート、ヒープ、CPU、スレッドプールなどのシステムの健全性状態やさまざまな指標をすぐに把握できます。
bu02_mgrでログイン後、「監視管理」>「監査ログ」をクリックし、クエリの開始時刻と終了時刻を選択して「開始時刻」(2021-12-01)と「終了時刻」(2021-12-31)を選択し、 【検索】 、すべての行動の詳細を取得します
「ログ クエリ、ログイン、インデックス管理」の 3 つのショートカット キーを使用して迅速に検索し、クエリ結果をファイルにエクスポートしてレポートを作成できます。
[監視管理] > [監査ログ] をクリックし、クエリの開始時刻と終了時刻 (2021-12-01 ～ 2021-12-31) を選択します。また、「ユーザー、リターン コード、トランザクション」などの他の条件を追加することもできます。 code" など。クエリ (user=johnmanager) を実行するには、[検索] をクリックしてクエリ オブジェクトの動作の詳細を取得します。
「アラーム設定」ページのフィールドの意味を簡単に説明します。
以下の状況はいずれもユーザーから受け取った異常な通知であり、調査の結果、システムの実行オペレーションの動作状態が非常に不安定であり、原因不明の実行中断や失敗が発生し、最終的なオペレーションプロセス全体に支障をきたす可能性が考えられます。これらの例外については、フォローアップの追跡と処理のために、関連するアラーム メカニズムを確立する必要があります。
MIS開発チームのTonyがユーザーから異常報告を受け、調査した結果、主な原因は「スケジュール運転」システムの稼働状況が不安定で実行に失敗したためであることが判明しました。最近の状況により、エンドユーザーの全体的な運用プロセスがスムーズに完了できないケースが多発しており、監視・観測のためのアラーム設定通知の対象に加えていただくようログ戦略チームに依頼することにしました。
「監視管理」＞「アラーム設定」をクリックし、「作成」をクリック
シナリオの説明: スケジュールされたジョブが「30 秒」ごとに 2 回「失敗」すると、役割: BU-
開発者と BU マネージャーのグループ全体がアラーム通知を受け取ります。
以下の「サンプル情報」に従ってページ上のフィールドを入力し、[作成]をクリックして完了してください。
確立が成功したことを確認する
例外通知レター
IT開発メンバーのジョーは、最近の「出荷プロセス」で何らかの異常が発生し、出荷が失敗する原因となっていることに気付き、二度とこのような問題が起こらないように、Logs戦略チームに積極的に組み込みを依頼することにしました。監視・観測用のアラーム設定通知のランクにあります。
「監視管理」＞「アラーム設定」をクリックし、「作成」をクリック
状況説明:「配送プロセスで「1」の失敗が発生した場合」、役割: BU-
開発者グループ全体がアラート通知を受け取ります。
確立が成功したことを確認する
例外通知レター
IT開発メンバーのジョーさんは、「API 管理 プラット フォーム(digiRunner)」の各モジュール(Module)の業務実行状況を毎日手動で監視していましたが、その主な理由は、モジュールの異常状態が広範囲に影響を及ぼしていたためでした。 、そしてスーパーバイザーはそれに非常に注意を払いました。digiLogsをインポートするときに、Joe はパッシブをアクティブに変えたいと考え、ログ戦略チームに「イベント ビューアー」 (すべての実行イベントの結果) をアラーム設定に追加し、アラームが発生した場合にのみシステムに戻るように依頼することにしました。異常通知を受信しました。
「監視管理」＞「アラーム設定」をクリックし、「作成」をクリック
シナリオの説明: イベント ビューアに「1 回」の「不明なエラー」イベントがある場合、役割: BU-Developer のグループ全体がアラーム通知を受け取ります。
以下の「サンプル情報」に従ってページ上のフィールドを入力し、[作成]をクリックして完了してください。
確立が成功したことを確認する
例外通知レター
これに関連して、digiLogs理解できるでしょう。終わり。
Bill は、「ゴールド フロー (オンライン バンキング) システム」に関する問題の要素は、システム アクション、ホスト名、時間の関係にあると考えています。そのため、提案されたカスタマイズ要件は、システム アクション、ログインの平均使用時間と時間になることを望んでいます。システムのホスト名と平均時間の情報を表形式、棒グラフ、折れ線グラフで表示します。
bu01_mgrのロールでログインし、「トランザクション監視」＞「オンラインバンキング平均トランザクション時間分析」をクリックし、クエリしたい時間間隔（月）を選択し、[検索]をクリックします。
bu01_mgr のロールでログインし、[トランザクション監視] > [オンライン バンキングの平均トランザクション時間分析] をクリックし、[日次表示] アイコンの右側にある関数ボックスで (絶対を使用して) 開始時刻 (2021-12-) を選択します。 01）と終了時刻（2021-12-15）を選択し、[更新]をクリックします
クエリ結果がこの目標に向かってプルダウンされると、「オンライン バンキング トランザクションの平均時間分析グラフ」グラフでは、最初の項目の平均アクション時間が最も長く (6 秒かかります)、明らかに平均線を超えていることがわかります。この情報は、データが妥当であるかどうか、および対応する改善を行う必要があるかどうかを判断するための参考として使用できます。
Bill は、「アプリケーション (App)」ディメンション、アプリケーション システムのアクションとホスト名と回数の関係を設定します。したがって、レポートの要件は、アプリの平均使用時間とアクションの時間、ホスト名とアプリへのログインの平均時間であり、表形式、棒グラフ、折れ線グラフを適切に組み合わせて情報を提示します。
bu01_mgrでログインし、「取引モニタリング」＞「APP平均取引時間分析」をクリックし、クエリしたい期間（月）を選択し、[検索]をクリックします。
[取引モニタリング] > [APP 平均取引時間分析] をクリックし、[毎日] アイコンの右側にある関数ボックスで、(絶対値を使用して) 開始時間 (2021-12-01) と終了時間 (2021-12) を選択します。 -15 )、【更新】をクリック
このゴールまでクエリ結果をプルダウンすると、「アプリトランザクション平均時間分析表」のグラフで、最初の項目のアクション平均時間が最も長い(2秒かかります)ことがわかりますので、この情報を参考・判断することができます。データが合理的かどうか、相応の改善が必要。
最近リリースされた「アプリケーション プログラミング インターフェイス (API) 管理システム」、ビルが使用したいと考えているレポート: トラフィック分析、応答時間 (最大/最小)、使用回数 (成功/失敗の区別)、API (成功のみ) 時間 -時間分析、API (成功のみ) 平均時間、クライアント API 使用時間、不正接続レポートおよびその他のデータ、および表形式、棒グラフ、折れ線グラフによる完全な情報プレゼンテーション。
bu01_mgrでログインし、「トランザクション監視」＞「API平均時間の計算と分析」をクリックし、クエリしたい時間間隔（月）を選択し、[検索]をクリックします。
[トランザクション監視] > [API 平均時間の計算と分析] をクリックし、[毎日] アイコンの右側にある関数ボックスで、(絶対を使用して) 開始時刻 (2021-12-01) と終了時刻 (2021-12) を選択します。 -15 )、【更新】をクリック
この目標に向けてクエリ結果をプルダウンすると、「7. TSMP API トラフィック分析」のグラフでは、この時間帯の API トラフィックのピーク値が「15:46」で、50 倍もの高さであることがわかりました。この情報を利用して、データが妥当かどうか、フロー制御を設定する必要があるかどうかを参照および判断できます。
このシナリオでは、企業がログ ルート マップを実現し、一連の監視システムをカスタマイズし、それらを 1 ページのグラフィカルな方法で表示することで、異常なシステムと連絡方法をすぐに知ることができるように、digiLogs理解できるでしょう。
IT ディレクターのビルは、オンライン銀行のサブシステムが相互に関連していることを発見しました。これらのサブシステムのログを統合して接続できれば、将来システムに異常が発生したときに、より迅速かつ明確に発見できるようになります。ご判断の上、適切な対応をお願いいたします。この点で、digiLogs部門のパス マップの作成を支援し、すべてのサブシステムが相互関係に従って接続および統合された後、それらは「1 ページの Web ページ」の形式で表示され、監視担当者が迅速かつ即座に確認できるようになりました。各システムの稼働状況をご案内します。
「取引ルートマップ」をクリックすると、各システムの正常稼働情報が確認できます。
異常が発生した場合、（個人向けオンラインバンキング）システムの「平均時間」が「赤文字」で表示されます
異常なシステムの「平均時間」をクリックし、「システムタイプ」と「トランザクションタイプ」のステータスを確認します。
例外制度『アイコン』＞をクリックすると、該当する担当者の連絡先が表示されます。
このシナリオでは、digiLogs「動的クエリ フィールド」を使用して正確なターゲット ログ データを見つける方法を理解できます。
ある日、「API集中システム」に異常事態が発生し、MISの一員であるトニーはタスク依頼を受けて、いずれかのAPIの実行が異常の原因となる可能性があると予備判断した。予測された条件に従ってプラットフォームに行って「動的クエリ」を実行し、異常の原因を検証・確認し、事後処理を完了する必要があります。従来は、通知を受け取った後、手がかりが少なかったため、ログの対象データソースを問い合わせる必要があることのみを知り、指示に従って全文から順次検索し、徐々に絞り込むことしかできませんでした。全体の検索プロセスが複雑になります。digiLogsをインポートすると、これまでの不便さが解消され、全文検索を完了するための「クリック モード」を提供するだけでなく、キーワードや動的条件をカスタマイズしてコンテンツをクエリすることもでき、操作がよりシンプルになり、クエリ結果を正確に把握できます。
(ログをクエリするための条件がすでにある場合は、このページの手順に従って設定することもできます)
bu02_devとしてログインし、「ログクエリ」>「ログクエリ」をクリックし、開始時刻と終了時刻（2021/12/27～2021/12/31）を選択し、クエリするデータソースを選択します（インデックス = dgr_sit_api_log_*）。 【検索】をクリック
前の手順を続けて、「キーワード検索」に「rtnCode」を入力し、[検索]をクリックし、フィールドを確認します: No.、cid、ResHeader.rtn、CodeResHeader.rtnMsg、mbody
(追記: キーワードを入力するときは、文字列の前後に「"」を追加する必要があります。例: 「test」)
前の手順に引き続き、「フィールド条件によるクエリの追加」で「追加」をクリックします。
プルダウンして、「フィールド」= 'ResHeader.rtnCode'、「演算子」= 'is not'、を選択します。
「値」= '1100' および「フィールド」= 'ResHeader.rtnCode'、「演算子」= 'is not'、「値」= 空白、[検索] をクリックすると、データ クエリが成功しました。
前の手順のクエリ結果を引き継ぎ、情報フィールド (「テーブル」と「エクスポート」の間にあります) で、表示するフィールドの内容を選択し、データ (.xlsx) をエクスポートします。 No.、cid、ResHeader.rtnCode、ResHeader.rtnMsg、mbody のフィールドを確認します。
画面表示切替（テーブル／カードタイプ）
このシナリオでは、digiLogs「関連クエリ」を通じて他のデータ ソースに関連する手がかりをどのように見つけ出すかを理解し、コンテキストに従って各システムを通過するログのトランザクション情報を知ることができます。
ある日、MISメンバーのトニーは、クエリタスクを受け取った後、「ゴールドフロー（オンラインバンク）システム」の異常の原因を調べるためにプラットフォームに行きました。キーワードを検索し、その手がかりに従って他のソースを検索します。各システムを通じて関連するログデータとトランザクション情報を取得します。従来は、問い合わせ業務を受けた後、専任担当者が特定のシステムに赴いてログを照会し、異常原因を究明する必要があり、複数のシステムが関係する場合、状況を完全に把握するには複数のシステムを切り替える必要がありました。情報と人間関係全体のプロセスは煩雑で時間がかかりました。この状況を改善するのがdigiLogsであり、複数のデータソースを統合してクエリ時に条件を設定し、その結果から他のソースに関するデータのヒントを見つけることができるサービスがプラットフォーム上で提供されます。
bu02_devとしてログインし、「ログクエリ」>「ログクエリ」をクリックし、開始時刻と終了時刻(2021/12/29~2021/12/31)を選択し、クエリするデータソースを選択します(Index=pb-)
*)を選択し、【検索】をクリックします。フィールド（No.、PmtID、logtime、action、source、message）を確認します。
クエリ結果表から一番右の「アクション」列に移動し、【メッセージ詳細】をクリックします。
「メッセージ詳細」から各システム間の関連情報を一つ一つ検索し、この例では5番目のデータからCall APIの手がかりを見つけます。最後に、必要に応じて、「キーワード検索」または「動的検索」を使用して、より正確な結果を見つけます。
このシナリオでは、digiLogs「Query More」を通じてカスタマイズされたログタイミングでログの上位と下位の連続ログを検索し、システム異常の根本原因 (根本原因) を特定する方法を理解できます。 。
ある日、MISメンバーのトニーは、「ゴールドフロー（インターネット銀行）システム」の異常の原因を調べるため、ある任務を受けてプラットフォームへ赴いた ログの完全かつ継続的なログを取得する「時間範囲」機能、適切な解決策を提案します。以前は、専任の担当者がログを検索する場合、ログの外観をより完全に理解するために、時間軸を中心として、ログの上部と下部の連続したログをクエリしていました。digiLogsも同様の機能を提供しており、簡単な動作ポイントの選択と独自に定義したタイミングによって、クエリの目的を達成し、異常の根本原因を見つけることができます。
bu02_dev としてログインし、[ログ クエリ] > [ログ クエリ] をクリックし、開始時刻と終了時刻 (2021-12-29 ～ 2021-12-31) を選択し、クエリするデータ ソースを選択します (インデックス = pb-*)をクリックし、【検索】を選択します。次のフィールドを確認します: No.、PmtID、logtime、action、source、message。
PmtID=2020122531279601 を選択し、「アクション」で > [さらに表示] をクリックし、ドラッグ アンド ドロップで時間範囲を設定し (時間範囲=200、ファイル サイズ=1)、[検索] をクリックします。
ドラッグ＆ドロップで時間範囲を設定し（Time Range(s)=200、File Size=50）、[検索]をクリックします。
このシナリオでは、digiLogsにアーカイブされた「履歴データ」を再アクティブ化した後、「ログ クエリ」を通じてプラットフォーム上でリアルタイム クエリを直接実行する方法を学ぶことができます。
従来、MIS チームは履歴データをパッケージ化して圧縮していましたが、過去のデータを確認する場合は、パッケージ全体を解凍してから、目的の日付のアーカイブ データを 1 つずつ検索する必要がありました。検索に時間がかかりすぎて手続きが面倒でした。またdigiLogsプラットフォームが保存されたデータからの距離に応じてデータをコールド データとホット データに分割するため、企業を支援するためのより便利な方法を提供します。コールド データをクエリする必要がある場合、「クエリ インデックス」設定により、再起動後の短時間データをクエリできます。
2022 年 1 月に、MIS のメンバーである Tony はタスクを受け取りました。今月の API 使用率が高すぎる疑いがあるため、スーパーバイザーからデータを確認するように求められたため、2021 年 12 月に API ログをクエリする必要がありました。 2022 年 1 月のデータ、データの結果を比較し、比較レポートを作成します。ただし、2021 年 12 月のデータは「コールド データ」になりました。このとき、プラットフォームが提供するリセット機能を使用して「コールド データ」を設定する必要があり、「」内のログ データを直接クエリしてエクスポートできます。クエリ インデックス」を選択し、統合比較を実行します。 はい、関連するレポートを完成させます。
bu02_dev としてログインします。 「インデックス管理」＞「クエリインデックス」をクリックし、開始時刻と終了時刻（2021-12-01～2021-12-31）を選択し、クエリ対象のデータソース（index=dgr_sit_api_log_*）を選択して、[検索]をクリックします。
クエリしたい日付データ(2021-12-01~2021-12-31)を選択し、クエリしたいデータソース(Index=dgr_sit_api_log_*)を選択し、[検索]をクリックして、開きたい日付を選択し、を選択し、[開く]をクリックします。
「ログクエリ」＞「ログクエリ」をクリックし、開始時刻と終了時刻（2021-12-01～2021-12-31）を選択し、クエリ対象のデータソース（Index=dgr_sit_api_log_*）を選択して、[検索]をクリックします。
上記の方法により、履歴データを迅速かつ一時的に再アクティブ化して比較対象のファイルを取得し、エクスポート後に MoM データの並べ替えやグラフの描画に使用できます。
このシナリオでは、digiLogs企業の「ファイル読み取り」ホスティングをどのように支援できるかを理解できます。設定後は、すぐにプラットフォーム上で直接使用でき、エンタープライズ ログ ファイルをリアルタイムで監視できます。
ワン マネージャーは、単一のインターフェイスを通じてさまざまなハードウェアとソフトウェアのシステム データ レコードを簡単に管理し、チームの検索にかかる時間コストを削減し、管理効率を効果的に向上させることを期待して、digiLogs集中管理プラットフォームを導入しました。企業が「ログ管理センター」の期待を満たすのを支援するために、digiLogs「ファイルの読み取り」ホスティング機能を提供し、完全な構成データ (IP、ポート、ID、PWD など) システムを入力する従来のプロセスを排除します。システムでは、シンプルでワンタイムの設定であれば、提供される単一のインターフェイスで、各ログファイルのリアルタイムデータを素早く切り替えて監視できます。
cat モード: ファイルの内容を表示するために Lunix によって使用されるコマンドであり、ファイル全体の内容を表示したり、複数のファイルをマージしたりするためによく使用されます。
tail モード: これは、Lunix がファイルの内容を表示するために使用するコマンドでもあります。主にファイルの最後の数行を表示するために使用されます。ファイルの内容が更新されると、自動的に並べ替えられ、ファイルの内容データは最新になります。 。
「読み取りファイル管理」＞「ホストメンテナンス」をクリックし、「ホストの追加」をクリックします。
対応するフィールドに、ログを保存するホスト名、IP、ディレクトリ パスを入力し、[作成] をクリックします。
「読み取りファイル管理」＞「カテゴリログメンテナンス」をクリックし、「作成」をクリックします。
該当するフィールドに、使用するメインシステム、業種、ホスト名、パスなどを入力し、[作成]をクリックします。
(違いを明確に確認するには、開始日と終了日を確認してください。現在の日付より前の日付を確認してください)
「ログクエリ」＞「ファイルの読み取り」をクリックし、対象の「システム」と「ビジネス」を選択します。
「サービス」を選択し、対象の「ディレクトリ（ホスト）」（host=apiModule(digirunner)）を選択し、クエリの開始時刻と終了時刻を選択するか、「キーワード検索」（dgr-cus）でクエリする内容を入力します。 -etb_cg-v3.8.4.24.log）を選択し、【検索】をクリックします。
cat モードを選択し、対象のファイル名を見つけて (「拡張子名.log」を選択する必要があります)、「アクション」列で【プレビュー】をクリックすると、単一のウィンドウで完全なコンテンツをクエリできます。
(違いを明確に確認するために、開始日と終了日の日付を確認してください)
「ログクエリ」＞「ファイルの読み取り」をクリックし、対象の「システム」と「ビジネス」を選択します。
「サービス」を選択し、対象の「ディレクトリ（ホスト）」（host = apiModule（digirunner））を選択し、クエリの開始時刻と終了時刻を選択し、クエリしたい内容を入力することもできます（tsmpc-v3.10.0） 「キーワード検索」で選択【検索】をクリック
末尾モードを選択し、ターゲット ファイルの名前を見つけて (「拡張子名.log」を選択する必要があります)、「アクション」列の [プレビュー] をクリックします。このアクションにより、単一ウィンドウ内のコンテンツの最後の数行をクエリできます。 、ファイルの内容が更新されると、このウィンドウにも自動的に並べ替えられて表示されます。
クエリ結果では、必要に応じて cat モードと tail モードを切り替え、複数の文字エンコーディング (BIG 5、UTF-8、ASCII) をサポートできます。
TPIソフトウエアは、ソフトウェア開発能力、モジュール設計、AIコアテクノロジーを活用して、DigiFusionエンタープライズサービスミドルウェア、SysTalk.ai会話型AI、ESGswift サステナビリティ、GadoSecurityエンタープライズセキュリティ保護などの革新的なエンタープライズソフトウェア製品を独自に開発し、台湾全土および海外に販売チャネルを展開しています。同時に、大規模なクロスボーダープロジェクト構築の経験があり、市場に柔軟に対応して、企業のデジタル・トランスフォーメーションを実現して、顧客の信頼と多くの国際的な賞を獲得しています。