よくある質問¶

イベントの表示と時間範囲¶

「未復旧イベント」はデフォルトで48時間以内のものだけが表示されますが、それより前の未復旧イベントを確認するにはどうすればよいですか？

ページ右上の時間ウィジェットで、時間範囲を自由に調整できます。

「すべてのイベント」と「未復旧イベント」の2つのタブの違いは何ですか？どちらでも未復旧イベントを絞り込めるのはなぜですか？

主な違い：「未復旧イベント」はショートカットで、自動的にフィルター条件が設定されます。「すべてのイベント」は手動でフィルター条件を追加する必要がありますが、柔軟性が高くなります。

時間ウィジェットを調整すると、以前設定したフィルター条件はリセットされますか？

リセットされません。時間範囲の調整は独立しており、設定したフィルター条件（イベントレベル、アラートポリシー、モニター名など）は保持され、システムは新しい時間範囲内でこれらのフィルター条件を適用します。

イベント内容と変数¶

イベント内容の変数（{{df_dimension_tags}}、{{Result}} など）が空または形式が正しくない場合、どうデバッグすればよいですか？

変数の出所：イベント内容の変数はモニターのイベント通知設定領域で定義され、システムが実際の監視データに基づいて置き換えます。

空値になる一般的な原因：

1. DQLクエリが対応するフィールドを返していない
2. 変数名のスペルミス（大文字と小文字を区別）
3. 検出ディメンションのタグが空

デバッグ方法：

1. イベント詳細の検出指標領域を確認し、元のクエリ結果を確認する
2. モニターのDQLクエリ文が正しいか確認する

よく使う変数のリファレンス：

• {{Result}} - 検出値
• {{df_dimension_tags}} - 検出ディメンションのタグJSON
• {{df_status}} - イベントステータス
• {{df_monitor_name}} - モニター名
• {{date}} - イベント発生タイムスタンプ

イベントタイトルとイベント内容の違いは何ですか？通知時にはどちらが送信されますか？

• イベントタイトル：イベント一覧に表示され、アラート通知のタイトルにもなります（メールの件名、DingTalkメッセージのタイトルなど）
• イベント内容：イベント詳細ページに表示される内容で、デフォルトのアラート通知本文でもあります

通知内容のカスタマイズ：

モニターでは「カスタム通知内容」スイッチを有効にすることができます。この場合：

• イベント内容は引き続きイベント詳細に保存されます
• ただし、アラート通知はカスタムテンプレートを使用して送信されます
• 通知チャネルごとに内容をカスタマイズする必要がある場合に適しています

イベント内容でサポートされているテンプレート関数は何ですか？数値をパーセンテージにフォーマットできますか？

現在明確にサポートされているテンプレート関数：

イベントステータスと復旧¶

イベントの復旧は自動ですか、それとも手動ですか？一部のイベントがずっと未復旧のまま表示されるのはなぜですか？

自動復旧：モニターが指標の正常化を検出すると、自動的に復旧イベントが生成され、df_status が ok に変わります

手動復旧：イベント一覧または詳細ページでイベントを手動で復旧できます

未復旧の一般的な原因：

1. モニター設定の問題：復旧条件が正しく設定されていない
2. データ断絶イベント：復旧ポリシーが設定されていない、またはデータが再送信されていない
3. 検出ロジックの問題：閾値設定により自動復旧の判定ができない

モニターのミュート期間中に生成されたイベントはイベント一覧に表示されますか？ステータスはどうなりますか？

イベント一覧には表示されますが、次の点に注意してください：

• アラート通知は送信されません
• 障害の同期作成は行われません（同期作成を設定している場合）
• イベントステータスは正常に記録されます（critical/warningなど）

ミュートは通知送信を一時停止するだけで、イベント自体の生成と記録には影響しません。

データ断絶イベント¶

データ断絶イベントとは何ですか？どのようなシナリオで有効にする必要がありますか？

データ断絶とは、モニターが検出サイクル内に予期したデータをクエリできなかったことを指します。

設定場所：モニターの「データ断絶イベント」設定領域（一部のモニタータイプでのみサポート）

3つの処理ポリシー：

1. イベントをトリガーしない - サイレント処理
2. 復旧イベントをトリガー - データ断絶を異常からの復旧とみなす
3. データ断絶イベントをトリガー - 専用の断絶アラートを生成（レベルを設定可能）

データが実際に送信されていないのに、データ断絶イベントがトリガーされないのはなぜですか？

Guanceではデータ断絶の判定に「エッジトリガー」メカニズムを採用しています：

前回のクエリで X が見つかり、今回のクエリで X が見つからない場合、X でデータ断絶が発生したと判定されます

重要な制限：

• 初回検出時のデータなしではアラートは生成されません（システムは「本来あるべきデータ」を把握していないため）
• 「データあり」の状態を一度経験した後、再度検出できない場合にのみ断絶と判定されます

調査の推奨事項：

1. モニターが少なくとも1つの検出サイクル正常に実行され、データをクエリできていることを確認する
2. 「検出範囲のドリフト」メカニズムを確認する（実際の検出時間範囲は1分ドリフトします）
3. モニターの実行ログを確認し、DQLクエリが成功しているか確認する

データ断絶イベントとデータ復旧イベントの生成ロジックは何ですか？

交互生成メカニズム：

• データ断絶イベントとデータ復旧イベントは常に交互に生成されます
• 連続するデータ断絶イベントは生成されません
• 連続するデータ復旧イベントも生成されません

判定フロー：

初回検出でデータなし → アラートなし
↓
データを検出 → 「データあり」状態を記録
↓
再度検出でデータなし → データ断絶イベントをトリガー
↓
データが再送信される → データ復旧イベントをトリガー
↓
再度検出でデータなし → データ断絶イベントをトリガー（新しい）

イベントの関連付けと調査¶

イベント詳細ページの「関連イベント」はどのように関連付けられますか？なぜ空の場合があるのですか？

関連付けのロジック： - 同じ検出ディメンションのタグに基づく（host、service など） - 時間ウィンドウに基づく（同じ時間帯の関連イベント）

関連付けが空になる一般的な原因：

1. そのディメンションのタグが他のイベントに存在しない
2. 時間ウィンドウ内に他の関連イベントがない
3. 現在のイベントタイプが関連付けをサポートしていない（一部のモニタータイプ）

「関連 SLO」が0と表示されるのはどういう意味ですか？いつデータが表示されますか？

• 0と表示：そのイベントがどの SLO タスクにも関連付けられていないことを意味します
• データが表示される場合：イベントが SLO タスクによってトリガーされた場合にのみ、関連する SLO 情報が表示されます
• モニターによってトリガーされたイベントは、デフォルトでは SLO に関連付けられません

履歴トレンドチャートの「検出区間」の点線はどういう意味ですか？時間範囲を調整できますか？

• 検出区間の点線：そのアラートをトリガーした具体的な検出時間ウィンドウを示します
• チャート表示：その検出指標のより長い時間範囲での推移を表示します

チャート右上の「チャートクエリを取得」ボタンをクリックすると、メトリクスまたはログエクスプローラーに移動し、エクスプローラーで時間範囲を柔軟に調整して、より長期的なトレンド分析を行うことができます。

イベントのソースとフィールド¶

異なるソースのイベント（モニター、AI モニター、監査、OpenAPI）では、フィールドにどのような違いがありますか？

df_source の値が異なると、対応する追加フィールドも異なります：

OpenAPI で書き込まれたカスタムイベントと、システムが生成したイベントでは、使用上の違いは何ですか？

機能の違い： - カスタムイベントでは df_status、df_title、df_message などのフィールドを設定できます - 関連付け用に df_dimension_tags を指定できます - モニターイベントのようにダッシュボードに自動的に関連付けられることはありません - イベントの復旧ロジックは自分で処理する必要があります（API 経由で復旧インターフェースを呼び出す）

ユースケース：外部システムとの連携、カスタムビジネスアラート、履歴イベントの一括インポートなど。

監査イベント¶

監査イベントには具体的にどのような操作が記録されますか？どこで確認できますか？

確認場所：管理 > 基本設定 > セキュリティ > 操作監査

一般的な記録範囲：

• データアクセス権限の追加/削除（クロスワークスペース認可）
• モニター、SLO、アラートポリシーなどの設定の追加・削除・変更
• ワークスペースメンバーの権限変更

フィールドの特徴：df_source = audit で、操作者、操作時間、操作タイプなどの監査専用フィールドが含まれます。

よくある問題のトラブルシューティング¶

イベント詳細に表示される時間と、実際の障害発生時刻が合わないのはなぜですか？

これは正常な現象です。理由は2つあります：

1. 計画トリガー時刻 vs 実際の実行時刻：

   • イベントに表示される時刻はモニターの計画トリガー時刻です（Crontab に基づく正規化された時刻）
   • イベントがシステムで実際に生成された時刻ではありません

2. 検出範囲のドリフト：

   • 実際の検出データ範囲は、計画トリガー時刻 - 検出範囲 - 1分 から 計画トリガー時刻 - 1分 までです
   • そのため、障害データのタイムスタンプがイベント表示時刻より前になる場合があります

調査の推奨事項：イベント詳細の「検出指標」領域を確認し、実際に検出されたデータの時間範囲を確認してください。

プラットフォームで直接クエリすると障害データを確認できるのに、モニターがイベントを生成しないのはなぜですか？

一般的な原因：

1. データ保存の遅延：検出実行時に障害データがまだクエリ可能になっていない（モニターは自動的に1分ドリフトして回避しますが、遅延が1分を超えると効果がありません）
2. DQLクエリの失敗：検出プロセスがクエリ失敗により中断された
3. モニターのミュート：ミュート期間中は通知が送信されませんが、イベントは生成されます（イベント一覧を確認する必要があります）
4. 閾値設定：実際の検出値がトリガー閾値に達していない

イベントデータはどのくらい保持されますか？エクスポートやアーカイブはどうすればよいですか？

長期的な保存方法：

• Dataway Sink 機能を使用してイベントデータを外部ストレージに振り分ける
• OpenAPI を使用してイベントデータを定期的にローカルストレージに取得する
• データ転送機能を使用して Kafka、S3 などの外部システムに転送する