Hosted Graphiteの複合アラートでアラートノイズを削減する方法

Great systems are not just built. They are monitored.

MetricFire is a managed observability platform that helps teams monitor production systems with clean dashboards and actionable alerts. Delivering signal, not noise. Without the operational burden of self-hosting.

はじめに

従来のアラートは設計上シンプルです。あるメトリクスがしきい値を超えた場合、アラートを発動します。この簡素さにより設定は容易ですが、一方でアラートノイズも生じます。これは単一のメトリクスでは全体像を捉えきれず、対応不要な状況でも頻繁にトリガーされるためです。

Hosted Graphiteの複合アラートは、この課題を解決します。AND（&&）や OR（||）といった論理演算子を使って複数のアラート条件を組み合わせることで、個別の症状ではなく、実際にユーザーへ影響を与える意味のあるシグナルの組み合わせに対してアラートを発火できるようになります。本記事では、以下のような収集しやすいメトリクスを使った、実践的な複合アラートの例を紹介します。

• Heroku
• NGINX
• PostgreSQL
• ディスク使用率

さらに、その他の一般的なサービスを想定した理論的な例についてもご紹介します。

複合アラートとは？

複合アラートでは、1つのアラートで複数のメトリクスを評価し、論理式が true になった場合のみアラートを発動させることができます。

仕組み（概要）：

• 各メトリクスには、それぞれ個別のアラート条件を設定します
• 各条件には ラベル（a、b、c など） が割り当てられ、アラート式内で参照できます
• AND / OR などの論理式によって、これらの条件をどのように組み合わせて評価するかを定義します

例1：a && b

• このアラートは、a と b の両方の条件が true の場合のみ発動します。

例2：(a && b) || c

• このアラートは、a と b の両方が true の場合、または c が true の場合に発火します。

備考：現在、複合アラートは Hosted Graphite Alerts API を通じてのみ作成・更新が可能です。ただし、複合アラート用のUI機能はHosted Graphiteの開発ロードマップに含まれており、今後の提供が予定されています。

複合アラートの curl 実行例：

curl -H "Content-Type: application/json" -X POST -d \
'{
  "name": "Composite Alert Example",
  "metric": "<your.alerting.metric>",
  "alert_criteria": {
    "type": "above",
    "above_value": 100,
    "time_period": 10
  },
  "additional_criteria": {
    "b": {
      "type": "above",
      "below_value": 10,
      "metric": "<your.secondary.metric>",
      "time_period": 10
    }
  },
  "expression": "a && b",
  "notification_channels": ["channel_id1", "channel_name1", "channel_id2"],
  "notification_type": "state_change" | ["state_change"] | ["every", 123],
  "info": "string"
}' \
"https://<YOUR-API-KEY>@api.hostedgraphite.com/v2/alerts/"

Heroku：メモリ圧迫とルーターエラー

Herokuのdynoでは、一時的なメモリ使用量の増加や短時間のルーターエラーが発生することがよくありますが、これらは必ずしも対応が必要とは限りません。しかし、メモリプレッシャーが発生している状態で、ユーザー影響のあるエラーが同時に起きている場合は、アプリケーションが不健全である強いシグナルとなります。以下で使用しているメトリクスは、Heroku連携を設定した場合、またはHeroku MarketplaceのHosted Graphiteアドオンを有効化した際に収集される、実際のメトリクス例です。

Dyno のメモリ使用量：

• heroku.<app-name>.web.<dyno>.memory.memory_rss

Router の 5XX エラー：

• heroku.<app-name>.router.status.503

アラートロジック：

• A：Dyno のメモリ使用量が安全なしきい値を超えている
• B：Router が 503 エラーを返している
• 式：A && B

複合アラートの JSON 例：

{
  "name": "Heroku dyno memory pressure with router errors",
  "metric": "heroku.<app-name>.web.*.memory.memory_rss",
  "alert_criteria": {
    "type": "above",
    "above_value": 200,
    "time_period": 10
  },
  "additional_criteria": {
    "b": {
      "type": "above",
      "above_value": 5,
      "metric": "heroku.<app-name>.router.status.5*",
      "time_period": 10
    }
  },
  "expression": "a && b"
}

これは有用なタイプのアラートです。なぜなら、メモリ使用量だけであればGCやトラフィックの一時的な増加によってスパイクすることがありますし、ルーターの 5XX エラーだけであればデプロイ時などにも発生し得るためです。

しかし、この2つが同時に発生している場合は、多くの場合、ユーザーに影響を与えるアプリケーション性能の劣化を示しています。

NGINX：継続的なトラフィックとリクエスト処理負荷

NGINXのメトリクスは、単体で見るとノイズが多くなりがちです。アクティブ接続数が多くても問題がない場合がありますし、リクエスト処理に関するメトリクスも常に変動します。これらを組み合わせることで、一時的なスパイクではなく、継続的で意味のある負荷を検知できるようになります。以下で使用しているメトリクスは、NGINXのTelegraf Inputプラグインを設定した際に収集される、実際のメトリクス例です。

アクティブ接続数：

• telegraf.<host>.<port>.<instance>.nginx.active

書き込み中のリクエスト数：

• telegraf.<host>.<port>.<instance>.nginx.writing

アラートロジック：

• A：アクティブ接続数が高い
• B：NGINX が多数のレスポンスを書き込み中である
• 式：A && B

複合アラートの JSON 例：

{
  "name": "NGINX sustained load under active traffic",
  "metric": "telegraf.<host>.*.*.nginx.active",
  "alert_criteria": {
    "type": "above",
    "above_value": 200,
    "time_period": 10
  },
  "additional_criteria": {
    "b": {
      "type": "above",
      "above_value": 50,
      "metric": "telegraf.<host>.*.*.nginx.writing",
      "time_period": 10
    }
  },
  "expression": "a && b"
}

これは有用なアラートです。接続数が多いだけであれば通常運用の範囲である場合がありますし、書き込みアクティビティが高いだけであれば短時間で収束することもあります。

しかし、この2つが同時に発生している場合は、スケーリングや詳細な調査が必要となる継続的な負荷を示している可能性が高いと言えます。

PostgreSQL：接続負荷とディスク読み取りレイテンシ

PostgreSQLのパフォーマンス問題は、多くの場合、接続数の飽和とディスクアクセスの遅延が組み合わさって発生します。どちらか一方のメトリクスだけでアラートを出すとノイズになりがちですが、組み合わせることではるかに実用的で対処しやすいシグナルを得ることができます。以下で使用しているメトリクスは、PostgreSQL Telegraf Inputプラグインを設定した際に収集される、実際のメトリクス例です。

アクティブ接続数：

• telegraf.<host>.postgres.host=<db_host>_user=<db_user>_.postgresql.numbackends

ブロック読み取り時間：

• telegraf.<host>.postgres.host=<db_host>_user=<db_user>_.postgresql.blk_read_time

アラートロジック：

• A：アクティブなデータベース接続数が多い
• B：ディスク読み取りレイテンシが高い
• 式：A && B

複合アラートの JSON 例：

{
  "name": "PostgreSQL connection saturation with disk latency",
  "metric": "telegraf.<host>.postgres.host=*_user=*_.postgresql.numbackends",
  "alert_criteria": {
    "type": "above",
    "above_value": 80,
    "time_period": 10
  },
  "additional_criteria": {
    "b": {
      "type": "above",
      "above_value": 50,
      "metric": "telegraf.<host>.postgres.host=*_user=*_.postgresql.blk_read_time",
      "time_period": 10
    }
  },
  "expression": "a && b"
}

これは有用な複合アラートです。接続数が多いだけでは必ずしも問題を示すとは限らず、ディスクレイテンシの一時的なスパイクもメンテナンス中などに発生することがあります。

しかし、この2つが同時に発生している場合は、クエリの遅延やユーザーに影響するレイテンシと強く相関するケースが多くなります。

ディスク：容量またはinodeの枯渇

ディスク関連のインシデントは、さまざまな形で表面化します。ファイルシステムは、容量がほぼ満杯になった場合や、空き容量が安全な最小値を下回った場合、あるいはinodeの枯渇によって新しいファイルを作成できなくなった場合に利用不能になることがあります。これらはいずれも、即時対応が必要な重大な状態です。

この複合アラートでは OR ロジックを使用し、いずれか1つでも重大なディスク容量条件が検知された時点でアラートを発報します。これにより、複数の個別アラートを作成することなく、広範なカバレッジを確保できます。以下のメトリクスは、任意のOSにTelegrafエージェントをインストールした際に収集される実際のメトリクス例です。

ディスク使用率（％）：

• telegraf.<host>.<disk>.<fstype>.<mode>.<mount>.disk.used_percent

ディスク空き容量：

• telegraf.<host>.<disk>.<fstype>.<mode>.<mount>.disk.free

inode 使用率（％）：

• telegraf.<host>.<disk>.<fstype>.<mode>.<mount>.disk.inodes_used_percent

アラートロジック：

• A：ディスク使用率が危険なレベルまで上昇している
• B：ディスクの空き容量が危険なレベルまで低下している
• C：inode 使用率が危険なレベルまで上昇している

複合アラートの JSON 例：

{
  "name": "Disk capacity or inode exhaustion detected",
  "metric": "telegraf.<host>.disk*.*.*.*.disk.used_percent",
  "alert_criteria": {
    "type": "above",
    "above_value": 90,
    "time_period": 10
  },
  "additional_criteria": {
    "b": {
      "type": "below",
      "below_value": 5000000000,
      "metric": "telegraf.<host>.disk*.*.*.*.disk.free",
      "time_period": 10
    },
    "c": {
      "type": "above",
      "above_value": 90,
      "metric": "telegraf.<host>.disk*.*.*.*.disk.inodes_used_percent",
      "time_period": 10
    }
  },
  "expression": "a || b || c"
}

ディスク障害はそれ単体でも非常に危険であるため、アラートには相関よりも広範なカバレッジが求められます。ファイルシステムが95％以上使用されている場合、inodeが枯渇している場合、あるいは空き容量がほとんど残っていない場合、どの制限に最初に到達したかに関係なく、アプリケーション障害が発生します。これら独立した障害モードを OR ベースの単一複合アラートにまとめることで、複数の重複アラートを管理することなく、重大なディスク問題を迅速に検知できます。

その他の理論的な複合アラート例

パターンを理解すれば、複合アラートはほぼあらゆる領域に適用できます。

• Kubernetes：ポッドの再起動とノードのメモリ負荷
• Redis：エヴィクションとコマンドのレイテンシ
• AWS ALB：5XXエラー率とリクエスト数
• バックグラウンドワーカー：キュー深度と処理時間

いずれの場合も目的は同じで、複数の独立したシグナルが実際の問題を裏付けたときのみアラートを出すことです。SREチームにとって、アラート疲れは単なる不便さではなく、信頼性上のリスクでもあります。アラートが頻繁に発報されると、エンジニアは次第に信頼しなくなり、対応が遅れ、結果として本当のインシデントを見逃す可能性が高まります。単一メトリクスのアラートは、通常運用でもスパイクや変動が起きやすいため、特にノイズを生みがちです。

複合アラートは、偶然ではなく相関を要求することで、このノイズを減らします。リソースの圧迫とユーザー影響のあるエラーといったシグナルを組み合わせることで、実際の影響が強く示唆される場合にのみアラートが発報されます。これは、経験豊富なエンジニアがインシデント時に行う思考プロセスを反映しており、アラートが鳴ったときに本当に重要であることを保証します。その結果、誤検知の減少、アラートへの信頼性向上、そして本当に対応が必要な問題に集中できる健全なオンコール体制が実現します。

まとめ

複合アラートは、単一メトリクスのしきい値を超え、本番環境での障害の起こり方を反映したコンテキスト重視のアラート設計を可能にします。複数のシグナルによる確認を必須とする、あるいは複数の重大な障害モードを明示的にカバーすることで、誤検知を排除し、自然に解消する状態でオンコールエンジニアが呼び出されることを防ぎます。

SREチームにとっては、中断の減少、アラートへの信頼向上、そして実際のインシデント発生時の迅速な対応につながります。Herokuアプリケーション、NGINXのエッジサービス、PostgreSQLバックエンドのいずれを監視する場合でも、複合アラートは継続的かつ実行可能な影響があるときだけアラートを発報します。すでにメトリクスを収集しているのであれば、複合アラートを使うことで、運用上の判断をアラートそのものに組み込み、監視の複雑さを増やすことなくノイズを削減できます。

ぜひ無料トライアルに登録し、インフラのあらゆる箇所で複合アラートをお試しください。また、デモを予約して MetricFire チームと直接お話しいただき、監視に関するご要望をご相談いただくことも可能です。