よくある質問¶

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

「未復旧イベント」はデフォルトで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 に関連付けられません

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

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

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

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

異なるソースのイベント（モニター、監査、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 などの外部システムに転送する