giip
SES案件登録
15分で読了

サービスモニターガイド

GIIPエコシステムで稼働するサービス・cronスクリプトのリアルタイム状態、健全性、実行履歴を1つの管理者画面で監視します。サマリーダッシュボードで全体像を把握し、リスト・フロー・トリガーの各ビューで個々のサービスを詳細に確認できます。

🖥️ サービスモニターページへ移動 →

📋 概要

サービスモニターページは、GIIPエコシステムで稼働するcronスクリプト・エージェントワーカー・Azure Functionのリアルタイム状態を監視する管理者画面です。各サービスが最後に報告した状態（実行中/正常/エラー/未報告）、実行時刻、テレメトリ（成功・失敗・スキップなど）を表で表示し、上部のサマリーカードで全体の健全性を一目で把握できます。データはエージェントが時系列ストア（tKVS）に送信した状態レポートから取得され、この画面は運用者が「何が動き、何が止まっているか」を判断する管制画面です。

⚠️ この画面は管理者専用です。 アクセスには管理者レベル uLevel >= 70 が必要です。それ未満のユーザーはホームへリダイレクトされます。

🔍 画面構成

1. 上部ヘッダー

  • ページタイトル/説明: 「サービスモニター」（ローカライズ済み）とサマリー説明。
  • ビュー切替ボタン: リスト / フロー / トリガー の3ビューをトグルします。
  • スクリプトを追加 ボタン（リストビュー専用、giip #1307）: 新しい監視対象スクリプトを登録するモーダルを開きます。
  • 更新ボタン: サービス状態を即時に再取得します（読込中はアイコンが回転）。リストビューは30秒ごと、フロー・トリガービューは60秒ごとに自動更新されます。

2. サマリーダッシュボード

上部の4枚のカードで全サービスの集計状況を表示します。

カード意味
全体（Total）監視対象サービス/スクリプトの総数
実行中（Running）現在 RUNNING 状態で実行中のサービス数
正常（Healthy）IDLE（正常待機）状態で報告したサービス数
エラー（Error）ERROR（失敗/異常）状態で報告したサービス数

3. リストビュー（サービス表）

各行が1つのサービス/スクリプトを表し、クリックで展開して詳細（サブタスク・指標）を確認できます。

列説明
Script Nameスクリプト/サービス名
MigrationAzure Function移行状態（完了/保留/該当なし）
Hostnameレポートを送信したホスト
Status状態バッジ（RUNNING / IDLE / ERROR / UNKNOWN）
Last Execution最終実行時刻
Telemetry成功・失敗・スキップ・強制終了などの実行指標
Details展開（サブタスク・元レポートの確認）

各行の右側には最大2つのアクションアイコンがあります(giip #1307で明確に区別):

アイコン文言動作対象
🚫（丸+X、オレンジ）「監視対象から除外」tServiceMonitorScript.enabled をオフにします（ソフト削除）。tKVSテレメトリには触れません。監視対象一覧に由来する全ての行（raw/ksn のない UNKNOWN 行も含む）
🗑️（ゴミ箱、赤）「削除」（giip #1214）ksn を基準にtKVSテレメトリレコード1件を削除します。raw.ksn がある行のみ（実際にレポートが届いた行）

⚠️ この2つのボタンは全く別の機能です。赤いゴミ箱はテレメトリ履歴1件を削除するだけで、 画面からスクリプト行自体を消す（特に一度もレポートを送っていない UNKNOWN 行）には、必ず オレンジの「監視対象から除外」アイコンを使う必要があります。giip #1214当時この区別がなく UNKNOWN 行を消す方法がなかった問題（giip #1307）を解決した機能です。

4. フロービュー

サービス間の依存関係とデータフローを可視化します（ServiceMonitorFlow）。どのサービスがどのサービスへ続くかをフロー図で確認します。

5. トリガービュー

登録された通知トリガー(tKVSTrigger)のリアルタイム評価状況を表示します。バッチSP dbo.pKVSCheckSchd が5分ごと(Azure Function KVSCheckSchdTimer、giip #2098)にこれらの条件を再評価して ktChkDt を更新し、条件を超過したトリガーは Mail チャンネルが有効なら実際にメールが送信されます。

列の意味

列意味
キー(Key)監視対象の識別子。ktype='lssn' の場合はサーバー(lssn)番号。
ファクター(Factor)監視対象の指標名(例: DISKUSAGE, CPUUSAGE)。tKVSに実際のレポートが入る際と同じキー。この値が空だとtKVSと永久に結合できず、常に「無効」状態になります(下記の状態バッジ表参照)。
条件kAttrib kLogic kVal 形式(例: Capacity gt 90 = "Capacity値が90を超過")。kAttrib='giipLogDate' は特殊ケースで「最終レポートからの経過秒数」を比較します(例: giipLogDate gt 600 = "10分以上レポートなし")。
最終レポートこのキー+ファクターの組み合わせでtKVSに実際の値が最後に入った時刻。- は直近2日間レポートが全くないことを意味します。
通知チャンネルこのトリガーで有効な Mail / SMS / Slack。Mail は実際に送信されます(giip #2098、tEmailServerConfig のアクティブなSMTP設定 + giipApiSendEmail を再利用)。SMS は表示のみで、送信ゲートウェイが未連携のため実際には送信されません。Slack はトリガーごとのWebhook(kSlackWebhook)が設定されている場合のみ送信され、2026-09-07時点でWebhookが設定されたトリガーは0件です。 Mail宛先決定規則(giip #2412): (1) kMailが空白ではなく'-'でもない場合はその値、(2) そうではなく該当usnがtKVSTriggerDefaultMailに登録されていればそのデフォルト宛先、(3) 両方なければ送信せず[WARN] no recipient for ktSn=...ログのみ記録。kMailAct=0の場合は上記にかかわらず送信しません。
通知チャンネルこのトリガーで有効な Mail / SMS / Slack。Mail は実際に送信されます(giip #2098、tEmailServerConfig のアクティブなSMTP設定 + giipApiSendEmail を再利用)。SMS は表示のみで、送信ゲートウェイが未連携のため実際には送信されません。Slack はトリガーごとのWebhook(kSlackWebhook)が設定されている場合のみ送信され、2026-09-07時点でWebhookが設定されたトリガーは0件です。
状態下記4種のバッジのいずれか。

状態バッジ

バッジ条件意味
正常(緑)ファクターあり + 直近レポートあり + 条件未超過正常動作中。対応不要。
超過(赤、点滅)ファクターあり + 条件超過実際の異常信号。下記「対応例」参照。
データなし(灰)ファクターあり + 直近2日間レポートなし監視対象自体がレポートを送っていない(エージェント停止の可能性)。
無効(灰、薄い、デフォルト非表示)ファクター値が空tKVSとの結合条件自体が成立せず、永久に一致しない無効なトリガー定義です。実際の異常ではないため一覧からデフォルトで非表示になり、表上部の「無効なトリガーを表示」を押すと表示されます(giip #2098)。整理するにはDBで該当 tKVSTrigger 行の kfactor を設定するか、その行を削除してください。

対応例(条件の組み合わせ → 意味 → 対応)

キーファクター条件状態意味対応
584DISKUSAGECapacity gt 90超過(赤)lssn=584 サーバーのディスク使用率が90%を超過該当サーバー(lssn 584)に接続してディスク整理(ログ・一時ファイル削除)またはボリューム拡張。Mailチャンネルが有効なら既に kMail 宛にメールが送信されています。
2622CPUUSAGEgiipLogDate gt 600超過(赤)lssn=2622 サーバーのCPUUSAGEレポートが600秒(10分)以上途絶該当サーバーのエージェント(giipAgent)プロセス・スケジューラが生きているか確認。
(任意)(任意)(任意の条件)データなし(灰)直近2日間このキー+ファクターのレポートが全くないエージェントのインストール・ネットワーク・シークレットキーの問題をまず確認。トリガー定義自体が古い誤字(ファクター名不一致)の可能性もあります。
(任意)(空)条件が不完全に見える無効(灰、薄い、デフォルト非表示)ファクターがなく永久にマッチしない無効な定義実際に監視が必要なら kfactor を設定し直し、不要ならDBから削除してください。

🛠️ 状態チェックの方法

  1. 画面に入ったら、まず上部の サマリーカード でエラー（Error）件数を確認します。
  2. リスト ビューで状態バッジが ERROR または UNKNOWN（レポートなし）の行を探します。
  3. 該当行をクリックして展開し、Last Execution / Telemetry / サブタスク を確認します — 最終実行時刻が古い、または失敗指標が高い場合は非稼働の候補です。
  4. 更新 ボタンで最新レポートを再取得し、一時的な遅延かどうかを確認します。
  5. トリガー ビューへ移り、予定周期を過ぎた（超過）トリガーがないか相互確認します。

💡 参考

  • 状態値の意味: RUNNING=実行中、IDLE=正常待機（サマリーの「正常」に集計）、ERROR=失敗、UNKNOWN=直近のレポートなし（エージェントがtKVSに状態を送信していない状態）。
  • UNKNOWNが多い場合は、サービスが停止したというより、該当エージェント/スクリプトがテレメトリを報告できていない状態の可能性があります — まずエージェントの稼働可否を確認してください。
  • 自動更新: リストは30秒、フロー・トリガーは60秒周期で自動更新されるため、値が周期的に変わることがあります。
  • アクセス権限は propモード でページに minLevel={70} がハードコードされているため、常に uLevel >= 70 が必要です（メニュー設定値とは無関係）。

API参照

このページはディスパッチコマンド（fetchAzureCommand 経由）でバックエンドと通信します。別途APIガイドがないため、要点をここに記載します。

状態ポーリング（tKVS）

コマンド用途バックエンドSP
ApiServiceMonitorGetStatus監視対象スクリプトのtKVS状態（RUNNING/IDLE/ERROR）取得（30秒ポーリング）pApiApiServiceMonitorGetStatusbyAK
ApiServiceMonitorGetFlowフロービューのノード/エッジ取得（フロー用SP）
ApiServiceMonitorGetTriggerStatusトリガービューのトリガー別実行状況取得pApiApiServiceMonitorGetTriggerStatusbyAK
ApiServiceMonitorDeleteリストビューのサービス状態レコード1件を ksn で削除（ゴミ箱ボタン、確認モーダル必須）。ガード: 行の kFactor がサービスモニターの factor の場合のみ削除し、それ以外は 403 を返す。ペイロード { ksn }。(giip #1214)pApiApiServiceMonitorDeletebyAK

監視対象スクリプトCRUD（giip #1307、tServiceMonitorScript）

「行自体が画面に表示されるか」を決めるリストです。以前は useServiceStatus.ts の CRON_SCRIPTS 配列にハードコードされていましたが、このテーブル+APIに移行し、デプロイなしでUIからCRUDできる ようになりました。

コマンド用途バックエンドSP
ApiServiceMonitorScriptList監視対象スクリプト一覧取得（enabled=1、sortOrder 順）。ペイロードは空（{}）でも可。pApiApiServiceMonitorScriptListbyAK
ApiServiceMonitorScriptAdd新規スクリプト登録（「スクリプトを追加」モーダル）。ペイロード { scriptName(必須), category?, azureFunction?, migrationStatus? }。過去に除外された同名スクリプトがあれば再有効化（200）、新規なら201、既に有効な重複は409。pApiApiServiceMonitorScriptAddbyAK
ApiServiceMonitorScriptDelete監視対象から除外（オレンジアイコン）。tKVSには触れず tServiceMonitorScript.enabled のみオフにするため、UNKNOWN（未報告）行も除外可能。ペイロード { scriptId } または { scriptName }。pApiApiServiceMonitorScriptDeletebyAK
  • レスポンスは結果セットの配列形式（例: [データ, 状態]）で、クライアントは最初の（データ）配列を読み取ります。
  • 状態フィールド RstVal = 200（List/Delete/再有効化）または 201（Add新規）は正常、409 は既に監視中、401 はセッション期限切れ/未認証（再ログインが必要）を意味します。
  • 聖域（giipfaw run.ps1）は無修正: giipApiがコマンド名→SP名で汎用ルーティングするため、giipdbにSPを追加するだけでgiipfawのコード変更なしに動作します（giip-1214と同じパターン）。

トラブルシューティング

症状原因解決
アクセス直後にホームへ戻されるuLevel が70未満管理者アカウント（レベル70+）でログインしてください。
「セッション期限切れ」/401エラー認証トークンの期限切れまたは欠如再ログイン後、更新を押してください。
表の大半が UNKNOWNエージェント/スクリプトがtKVSに状態を報告していない該当エージェントの稼働可否とテレメトリ報告経路を確認してください。
灰色で薄い「無効」行が多く見えるkfactorが空でtKVSと永久にマッチしない無効なトリガー定義(正常な現象、実際の異常ではない)デフォルトで非表示です。必要な場合は上部の「無効なトリガーを表示」で確認し、DBでkfactorを設定するか削除して整理してください(giip #2098)。
「超過(赤)」トリガーがあるのにメールが来ないkMailActが無効、kMailもusnデフォルト(tKVSTriggerDefaultMail)も空、またはバッチ(KVSCheckSchdTimer)가まだこのトリガーを評価していない可能性まず「最終チェック」時刻が最近か確認(バッチ稼働状況)、「通知チャンネル」にMailが表示されているか確認。Mailが表示されていてもメールが来ない場合は、DBでkMailアドレス(トリガー行)とtKVSTriggerDefaultMail(該当usn)を両方確認してください。kMailが空白でもusnデフォルトがあればそこにフォールバック送信されます(giip #2412)。
「通知チャンネル」にSMS/Slackが表示されているのに通知が来ないSMSは送信ゲートウェイが未連携、Slackはトリガーごとのwebhookが実際に設定されている場合のみ動作(2026-09-07時点で設定済みトリガーは0件)現在はMailチャンネルのみ実際に送信されます。SMS/Slackが必要な場合はgiip issueでゲートウェイ・webhook連携を依頼してください。
値が変わり続ける30秒/60秒の自動更新が動作している正常です。特定時点を固定して見たい場合は値をキャプチャしてください。
上部のガイドボタン（📖）が表示されないガイドマッピング未反映（旧バージョン配信）このガイドが配信・インデックス化されると表示されます。
UNKNOWN 行が消せない赤いゴミ箱ボタンを押したが、それはtKVSレコード削除なので UNKNOWN 行（ksn なし）にはそもそも表示されないオレンジの「監視対象から除外」アイコンを使ってください（giip #1307）。
「スクリプトを追加」後も表示されない同名スクリプトが既に有効な状態で登録済みのため409応答（追加失敗）一覧に同名のスクリプトが既にないか確認してください。

バージョン: 1.2 最終更新: 2026-09-07（giip #2098: トリガービューUI改善(無効トリガー非表示/通知チャンネル状態明示) + 通知バッチ復活反映） ソースファイル: giipv3/public/help/service-monitor.ja.md

関連ガイド

ネットワークトポロジーインフラのネットワークトポロジーを可視化・探索しますGraphify (ナレッジグラフ)あらゆる入力をインタラクティブなナレッジグラフに変換しますtKB ナレッジベース管理Graphifyグラフの元データとなるプロジェクト別ナレッジベース項目を管理します
← PreviousSES提案書管理Next →サービスパターン自動発見