本トピックでは、Simple Log Service のアラートモニタリングルールに関するよくある質問 (FAQ) を紹介します。アラートの重大度、データなしアラート、復旧、クォータ管理などについて説明します。
動的に異なるアラートの重大度を設定できますか？
はい。アラートモニタリングルールを設定する際に、条件に応じて異なるアラートの重大度を定義できます。詳細については、「アラートの重大度の設定」をご参照ください。
Simple Log Service はデータなしアラートをサポートしていますか？
はい。アラートモニタリングルールを設定する際に、データなしアラートを有効にし、その重大度を個別に指定できます。詳細については、「データなしアラート」をご参照ください。
Simple Log Service はアラートの自動復旧をサポートしていますか？
はい。アラートモニタリングルールを設定する際に、アラート復旧を有効にできます。詳細については、「復旧通知の設定」をご参照ください。
アラートの複数ターゲットへの送信
はい。アラートモニタリングルールを設定する際に、グループ評価を有効にできます。詳細については、「グループ評価の設定」をご参照ください。
アラートルールの一時的な無効化
はい。アラームルール ページで、操作列の 無効化 をクリックします。
RAM ユーザーへの権限付与
RAM ユーザーにアラートの管理を許可するには、必要な権限を付与する必要があります。詳細については、「RAM ユーザーへのアラート管理権限の付与」をご参照ください。
「Alert count exceeds the maximum limit」エラー
アラートモニタリングルールの作成時に「Alert count exceeds the maximum limit」エラーが表示された場合、プロジェクト内のアラートモニタリングルールの数が上限 (デフォルトで 100) に達しています。リソースクォータの管理の手順に従ってクォータを増やすことができます。
クォータは、プロジェクトごとに最大 200 ルールまで増やすことができます。さらに多くのアラートモニタリングルールが必要な場合は、次の方法をご検討ください：
-
プロジェクトから不要なアラートモニタリングルールを削除します。
-
単一プロジェクト内のアラートモニタリングルールの数を減らすために、ログを異なるプロジェクトに収集します。
たとえば、サービス A からのログを Project1 に、サービス B からのログを Project2 に収集します。その後、異なるプロジェクトでアラートモニタリングルールを作成できます。
-
類似のアラートモニタリングルールを統合します。
たとえば、同じ Logstore 内のデータをモニタリングするには、単一のアラートモニタリングルールを作成し、グループ評価を使用して複数のターゲットをモニタリングできます。詳細については、「グループ評価の設定」をご参照ください。
-
アラートモニタリングルールを作成する前に、データ変換または Scheduled SQL を使用して、データを単一の Logstore に集約します。
たとえば、複数の Logstore からのエラーログをモニタリングする必要がある場合、すべてのエラーログを 1 つの Logstore に統合し、その Logstore に対して単一のアラートモニタリングルールを作成できます。
ログキーワードに基づくアラートの設定
ログが Simple Log Service に収集された後、特定のキーワードでトリガーされるアラートモニタリングルールを設定できます。詳細については、「ログキーワードに基づくアラートの設定」をご参照ください。
異なるフィールド値のモニタリング
事前にフィールドが取りうるすべての値を把握していなくても、いずれかの値がトリガー条件を満たした場合にアラートを送信するには、グループ評価を使用します。グループ評価は、指定されたフィールドでデータをグループ化し、各グループに対して個別にトリガー条件を評価します。詳細については、「グループ評価の設定」をご参照ください。
たとえば、複数のサーバーからのメトリックデータを 1 つの Metricstore に保存し、各サーバーの CPU 使用率 (cpu_util) が 95% を超えたときに個別のアラートを受信したい場合は、グループ評価を使用できます。
トリガー条件の評価順序
クエリと分析の結果は、トリガー条件と照合して順番に評価されます。結果が 1 つの条件に一致すると、後続の条件はスキップされます。したがって、トリガー条件は、重大度が最も高いものから順に設定してください。詳細については、「アラートの重大度の設定」をご参照ください。
検知漏れまたは誤検知
-
検知漏れ：エラーログ数が 10 を超えるとトリガーされるようにアラートが設定されています。しかし、Logstore の検索・分析ページでログを照会すると、特定の期間中にエラー数が 10 を超えていたにもかかわらず、アラートがトリガーされませんでした。
-
誤検知：1 秒あたりのクエリ数 (QPS) が 100 を下回るとトリガーされるようにアラートが設定されています。しかし、特定の期間中に QPS が 100 を超えていてもアラートがトリガーされました。
検知漏れや誤検知は通常、データが Logstore に書き込まれてからクエリできるようになるまでの遅延が原因で発生します。アラートモニタリングルールの時間範囲で相対時間を使用すると、クエリが最新のデータを除外してしまい、不正確な結果につながる可能性があります。これを防ぐには、クエリの時間範囲を拡張するか、クエリを固定のタイムウィンドウに合わせる必要があります。詳細については、「モニタリングの適時性」をご参照ください。
原因：通知のしきい値に未達
[アラート履歴統計] ダッシュボードの アラート履歴 チャートで、[アラートのトリガー] が 'true' で、理由 が 'Notify threshold not reached' の場合、トリガー条件は満たされたものの、連続トリガー回数が設定された 連続トリガーのしきい値 に達していないことを示します。 たとえば、連続トリガーのしきい値 を 3 に設定した場合、トリガー条件が 3 回連続で満たされた後にのみアラートが送信されます。