監視とログ機能設定

監視・ログのセットアップ

現代のシステム運用において、監視とログの適切なセットアップは不可欠です。運用中のシステムは常に可視化され、異常やパフォーマンス低下を早期に検知し、迅速に対応できることが求められます。この章では、主要な監視ツールの選定、ログ管理、異常検出、アラート設定の基本と応用について説明します。

監視とログの重要性

システムが正常に動作しているかを確認し、異常や問題を速やかに発見するために、適切な監視とログのセットアップは不可欠です。以下に、その主な理由を挙げます。

• システムの状態をリアルタイムに把握するための可視化が可能である。
• 異常が発生した際、迅速に対応するためのアラートを設定できる。
• 過去の動作を分析し、将来的なパフォーマンス改善や問題予防に役立てることができる。

監視は一般にメトリックと呼ばれる定量的なデータ（CPU使用率、メモリ使用量など）を中心に行われ、一方、ログは詳細なイベント履歴としてシステム内の動作を記録します。この両者を組み合わせることで、システムの健全性を包括的に監視することが可能となります。

ログ管理の基本

ログはシステムのあらゆるイベントを記録する重要なデータソースです。適切な管理が行われていないと、必要な情報を見つけ出すことが困難になり、問題の解決やトラブルシューティングが遅れる可能性があります。

• ログの種類には、システムログ、アプリケーションログ、セキュリティログなどがある。
• ログの形式は標準化されていることが望ましい（例: JSON形式）。
• ログの保存期間は、法律や運用ポリシーに従って適切に設定する。

また、ログは集中管理されるべきです。分散した環境では、各サーバーからのログを一元的に収集し、容易に検索・分析できる仕組みを導入する必要があります。代表的なログ管理ツールとして、ELKスタック（Elasticsearch, Logstash, Kibana）があります。

ELKスタックによるログ管理

ELKスタックは、ログ管理において非常に強力なツールセットです。それぞれのコンポーネントは以下の役割を果たします。

• Elasticsearch: 大量のログデータをリアルタイムに検索・分析するための検索エンジン。
• Logstash: 様々なログソースからデータを収集し、Elasticsearchへ送信するデータパイプライン。
• Kibana: Elasticsearchから取得したデータを視覚化し、ダッシュボード形式で表示するツール。

例えば、以下のようにLogstashを設定し、サーバーログを集約できます。

input {
  file {
    path => "/var/log/syslog"
    start_position => "beginning"
  }
}
 
filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:program}[%{POSINT:pid}]: %{GREEDYDATA:message}" }
  }
}
 
output {
  elasticsearch {
    hosts => ["localhost:9200"]
  }
  stdout { codec => rubydebug }
}

この設定では、/var/log/syslogからログを収集し、Elasticsearchに送信します。Kibanaを使うことで、収集されたログをダッシュボード形式で可視化し、異常なパターンをすぐに検出することができます。

メトリック監視

メトリックは、システムの健全性を数値化したものです。CPU使用率、メモリ使用量、ディスクI/Oなど、リアルタイムのメトリックを監視することで、潜在的な問題を未然に防ぐことができます。

• 主要な監視ツールとしては、PrometheusやGrafanaがある。
• Prometheusはメトリックの収集・蓄積を行い、アラート機能も備えている。
• GrafanaはPrometheusのデータを使って、ダッシュボードで視覚的に監視できる。

Prometheusの設定例として、以下のように基本的なメトリックを収集することができます。

global:
  scrape_interval: 15s
 
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

この設定では、localhost:9100からメトリックを15秒ごとに収集します。Grafanaと連携することで、これらのメトリックをリアルタイムで監視し、異常値を検知した場合にアラートを設定することができます。

アラートの設定

異常検出の一環として、メトリックやログの監視に基づいてアラートを設定することが重要です。アラートは、事前に定義した閾値を超えた場合に通知を行う仕組みであり、システムの健全性を維持するための即時対応を促します。

• アラートは通知チャネル（例: Slack、メール、SMSなど）を通じて配信される。
• アラートの閾値は、適切なメトリックに基づき慎重に設定する必要がある。
• アラートの種類には、警告とクリティカルアラートの二段階を設けることが多い。

例えば、New Relicを使ったアラートの設定では、特定のメトリックが指定の閾値を超えた場合、次のようにアラートポリシーを設定できます。

name: "High CPU Usage Alert"
condition:
  type: "metric"
  metric: "cpu.usage"
  threshold: 80
  duration: 5m
  notification:
    - type: "slack"
      channel: "#alerts"

この設定では、5分間CPU使用率が80%以上に達した場合、Slackの#alertsチャンネルに通知されます。

ダッシュボードの作成

システムの監視状況を一目で確認できるように、ダッシュボードを作成することは重要です。ダッシュボードは、メトリックやログをグラフィカルに表示し、異常が発生しているかどうかを迅速に判断する手助けをします。

• ダッシュボードには、システムの健全性指標を示すメトリックを表示する。
• 主要な監視ポイントを集中して表示することで、トラブルシューティングを迅速に行うことができる。
• リアルタイム更新に対応したダッシュボードを設置し、最新の情報を常に把握する。

Grafanaを使って、CPU使用率やメモリ使用量を表示するダッシュボードを作成する例は以下の通りです。

{
  "dashboard": {
    "panels": [
      {
        "type": "graph",
        "title": "CPU Usage",
        "targets": [
          {
            "expr": "cpu.usage"
          }
        ]
      },
      {
        "type": "graph",
        "title": "Memory Usage",
        "targets": [
          {
            "expr": "memory.usage"
          }
        ]
      }
    ]
  }
}

このダッシュボードでは、CPUとメモリの使用状況をリアルタイムに監視でき、異常検出時にはすぐに対応できるようになります。

異常検出の高度化

システムの監視は、単純な閾値によるアラートだけでなく、機械学習や異常検出アルゴリズムを活用して高度化することが可能です。これにより、従来の手法では検知できなかった異常や、パターン化された異常動作を早期に発見することが可能です。

• 異常検出のアルゴリズムには、異常値検出、

自己回帰モデルなどがある。

• New RelicやDatadogなどの監視ツールは、機械学習を活用した異常検出機能を提供している。
• 異常なパターンやトレンドを学習し、自動的にアラートを生成する。

たとえば、New Relicでは、機械学習を使って自動的に異常検出を行い、通常の振る舞いから外れた動作を検知してアラートを生成することができます。

監視とログの統合

監視ツールとログ管理システムを統合することで、システムの健全性をさらに深く理解し、トラブルシューティングを効率化することが可能です。メトリックとログを同じプラットフォーム上で一元的に管理することで、異常検出時の原因追跡が容易になります。

• メトリックとログを統合した監視システムでは、異常が発生した際、該当するログを即座に参照できる。
• ELKスタックやPrometheus、New Relicなどのツールは、ログとメトリックを統合したダッシュボードを提供している。
• メトリックの異常を検知し、直後に対応するイベントログを自動的に関連付けることで、根本原因の特定が迅速化する。

New Relicによる統合監視

New Relicは、メトリック、ログ、アラート、異常検出を一元的に管理できるプラットフォームで、リアルタイムの可視化と自動アラートの設定が可能です。New Relicを活用すると、以下のような監視統合が実現できます。

• システムの全体的なパフォーマンスメトリックと、特定のアプリケーションログの両方をリアルタイムに表示する。
• メトリックの異常を検知した場合、対応するログを瞬時に引き出し、詳細な分析を行う。
• 自動アラートに加え、異常なログパターンを検知し、自動でアクションをトリガーすることも可能。

たとえば、New Relicでアプリケーションパフォーマンスを監視しながら、同時に関連するログをリアルタイムで表示する設定は次のようになります。

name: "Application Performance Dashboard"
metrics:
  - cpu.usage
  - memory.usage
logs:
  - app.log
  - error.log
alerts:
  - type: "cpu"
    threshold: 90
    notification: "slack"

この設定により、CPU使用率が90%以上に達した場合、関連するアプリケーションログとエラーログを即座に参照し、Slackで通知が行われる仕組みが構築できます。

高可用性のための監視戦略

システムの稼働時間を最大化するためには、高可用性を目指した監視戦略が不可欠です。単一の障害点（SPOF）を排除し、障害が発生しても迅速に復旧できる仕組みを作ることが重要です。

• 分散監視を導入し、監視システム自体が障害に強くなるように設計する。
• 監視対象のシステムが冗長化されている場合、それぞれのインスタンスに個別に監視を設定する。
• 障害時の対応計画（SLA）や復旧手順を明確にし、監視ツールから即座にその情報へアクセスできるようにする。

また、冗長化された監視システムには、例えばPrometheusやELKスタックの複数インスタンスを用いた監視の冗長化が有効です。これにより、監視システム自体がダウンした場合でも、別のインスタンスが引き継ぐ形で監視を継続できます。

Prometheusによる冗長監視

Prometheusでは、メインの監視サーバーに加えて、バックアップ監視サーバーを導入することで、監視システムの冗長性を高めることが可能です。以下はその基本的な構成例です。

global:
  scrape_interval: 15s
 
scrape_configs:
  - job_name: 'primary'
    static_configs:
      - targets: ['primary-server:9100']
 
  - job_name: 'backup'
    static_configs:
      - targets: ['backup-server:9100']

この設定では、primary-serverがダウンした場合でも、backup-serverが監視を引き継ぐことができるようになっています。これにより、障害時にも監視が途切れることなく、重要なアラートやメトリック収集が継続されます。

まとめ

この章では、監視とログのセットアップに関する基本から応用まで、包括的に解説しました。システムの健全性をリアルタイムで把握し、異常が発生した際に迅速に対応するための仕組みを整えることは、システム運用の要です。適切な監視ツールとログ管理を組み合わせることで、システムの安定稼働を維持し、障害発生時の復旧を最小限のダウンタイムで行うことが可能です。

次の章では、これらの監視システムを実際に導入し、運用する際の具体的な手順や、運用中に発生する可能性のある課題とその解決策についてさらに詳しく説明します。

実運用における監視とログ管理のベストプラクティス

監視とログ管理の理論を理解することは重要ですが、実際の運用環境ではさまざまな課題が発生します。そのため、監視とログ管理システムを効率的に運用するためのベストプラクティスを習得することが不可欠です。この章では、実運用における具体的なシナリオに対処するための手法や、システムの安定性とスケーラビリティを確保するための工夫について説明します。

監視対象の優先順位付け

全てのシステムやサービスを一律に監視するのではなく、システムの重要度や利用状況に応じて優先順位をつけることが、リソースの最適な利用と監視精度の向上につながります。

• クリティカルパスに位置するサービスやインフラを最優先で監視する。これには、データベースやAPIゲートウェイなど、他のシステムやユーザーに大きな影響を与える要素が含まれる。
• 負荷が高いシステムやピーク時の利用が多いサービスは、リアルタイムの監視と詳細なログ管理が必要。
• バックエンドサービスやバッチ処理など、障害発生時に即座の対応が不要なものは、リソースを節約するために定期監視に切り替えることが可能。

優先順位に基づいて監視を設定することで、運用チームは本当に重要なアラートに迅速に対応することができ、誤検知やノイズを減らすことができます。

アラートのチューニング

アラートが多すぎたり、不必要にトリガーされると、オペレーターが本当に重要な問題を見逃すリスクが高まります。適切なアラート設定を行うことは、監視システムの効果を最大化するための基本です。

• しきい値の適切な設定：アラートを発生させる閾値を適切に設定することが重要。CPU使用率が90%を超える状況は通常動作でありえるが、95%以上が続く場合にアラートを発生させるなど、業務環境に合わせた設定が求められる。
• アラートの階層化：軽度な問題（例：ディスク使用率が70%を超えた場合）は通知のみ、中度な問題（80%を超えた場合）は警告、重大な問題（90%を超えた場合）は即座にオペレーターへ通知する、といったようにアラートを段階的に設定する。
• ダウンタイムの自動対応：特定のアラートに対しては、スクリプトによる自動修復手順を設定することが可能。たとえば、サービスの再起動やリソースの再割り当てを自動化することができる。

alerts:
  - alert: "DiskUsageWarning"
    expr: node_filesystem_avail_bytes < 50000000000
    for: 5m
    labels:
      severity: "warning"
    annotations:
      summary: "ディスク容量が不足しています"
      description: "ディスクの空き容量が50GB未満です。手動で対処するか、スクリプトによる自動対応を検討してください。"

この例では、ディスク容量が50GB未満になるとアラートが発生し、問題が継続する場合にはオペレーターに対処を促します。

スケーラブルな監視システムの設計

システムの規模が拡大すると、監視やログ管理システム自体のスケーラビリティが課題となります。監視インフラが拡大に対応できるように設計することが、将来的な成長に対応する鍵です。

• クラウドベースの監視システムを導入することで、物理的なインフラ制約を排除し、必要に応じてリソースを柔軟に拡張できる。PrometheusやGrafanaはクラウド上でスケーラブルに動作するツールの一例である。
• 監視データのサンプリングを行うことで、すべてのデータを詳細に記録するのではなく、重要なデータにフォーカスすることができる。これにより、ストレージの使用量を最適化しつつ、必要な情報を確保できる。
• モジュール化された監視アーキテクチャを採用することで、特定のコンポーネントに障害が発生してもシステム全体が停止しないようにする。たとえば、ログ収集システム（Fluentdなど）とメトリック収集システム（Prometheusなど）を分離して運用することが可能。

SLAとSLOに基づく監視

監視システムを運用する際は、サービスレベルアグリーメント（SLA）やサービスレベル目標（SLO）に基づいて監視基準を設定することが重要です。これにより、ビジネス要件に即した監視を実現することができます。

• SLAは、システムの稼働率や応答時間など、ビジネスにとって重要な指標を定義し、契約として明文化される。監視システムではこれらの指標を基にアラートを設定する。
• SLOは、SLAを満たすために日常的に達成すべき性能目標を設定する。たとえば、99.9%の稼働率を達成するために、特定のメトリックが基準内に収まっているかを監視し、超過した場合にアラートをトリガーする。

次の例は、SLAをもとにしたメトリック監視の設定です。

alerts:
  - alert: "ServiceAvailability"
    expr: probe_success == 0
    for: 1m
    labels:
      severity: "critical"
    annotations:
      summary: "サービスのダウンタイムが発生しています"
      description: "SLAに基づき、サービスが1分間ダウンしていることが確認されました。即時対応が必要です。"

この設定により、サービスの可用性が失われた場合に即座にアラートが発生し、SLAに違反する可能性があることが通知されます。

課題と解決策

監視とログ管理システムを実装し運用する中で、いくつかのよくある課題に直面することがあります。これらの課題に対する具体的な解決策を以下に示します。

• 誤検知が多い：しきい値の再調整や、メトリックの優先順位付け、アラートの階層化が有効。適切にフィルタリングを行うことで、不要なアラートを減らすことができる。
• ログの検索が遅い：ログ量が膨大になると、検索のパフォーマンスが低下することがある。Elasticsearchのクエリ最適化や、ログのアーカイブ、ログローテーションを実施することで、検索速度を向上させることが可能。
• スケール不足：分散システムの導入や、クラウドベースの監視ソリューションを導入することで、スケーラビリティの問題を解決できる。New RelicやPrometheusなど、クラウド対応の監視ツールを活用するのが効果的。

監視システムの具体的なツールと設定例

監視とログ管理の効率を最大化するためには、適切なツールの選定とその設定が不可欠です。この章では、さまざまな用途に応じた主要な監視ツールを取り上げ、それぞれの設定例と活用方法について解説します。

Prometheusによるメトリクス監視

Prometheusは、オープンソースのメトリクス監視ツールで、時系列データの収集と監視に特化しています。Prometheusは、エクスポーターというプラグインを介してシステムのリソースやアプリケーションのパフォーマンスデータを収集し、アラートを発生させることができます。

Prometheusの基本設定

Prometheusは、prometheus.ymlという設定ファイルを用いて動作します。このファイルには、監視対象やアラートのルールを定義します。

global:
  scrape_interval: 15s
  evaluation_interval: 15s
 
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

• scrape_interval: データを収集する間隔を設定。デフォルトは15秒で、これによりシステムリソースの使用状況を定期的にモニタリングできる。
• evaluation_interval: 収集したメトリクスの評価間隔を設定する。アラートの発生基準の評価タイミングを調整できる。

node_exporterは、システムのCPU、メモリ、ディスク使用量など、主要なメトリクスを収集するエクスポーターです。監視対象のサーバーにインストールし、Prometheusからこれをスクレイピングしてメトリクスを取得します。

Grafanaとの連携

Grafanaは、Prometheusなどのデータソースから収集したメトリクスを可視化するダッシュボードツールです。Prometheusと組み合わせることで、リアルタイムでシステムのパフォーマンスをモニタリングし、インタラクティブなダッシュボードを作成することが可能です。

datasources:
  - name: Prometheus
    type: prometheus
    url: http://localhost:9090

この設定をGrafanaのdatasources.ymlファイルに追加することで、Prometheusから収集されたデータを可視化できます。Grafanaは、豊富なプラグインを活用することで、カスタマイズ性に優れたダッシュボードを作成できます。

ELKスタックによるログ管理

ELKスタックは、Elasticsearch、Logstash、Kibanaから成り立つオープンソースのログ管理ツールです。このスタックを使用することで、膨大なログデータを効率的に収集・保存・分析し、可視化することが可能です。

Logstashでのログ収集

Logstashは、ログデータを収集して解析するためのツールです。設定ファイルには、データ入力、フィルタリング、出力を指定します。

input {
  file {
    path => "/var/log/syslog"
    start_position => "beginning"
  }
}
 
filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{WORD:logsource} %{GREEDYDATA:message}" }
  }
}
 
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "syslog-%{+YYYY.MM.dd}"
  }
}

• inputセクションでは、ログファイルのパスを指定し、Logstashがどのファイルからデータを収集するかを設定。
• filterセクションでは、grokフィルターを使って、ログのパターンを解析し、構造化データに変換する。
• outputセクションでは、解析済みのログデータをElasticsearchに送信し、保存先のインデックスを指定する。

Kibanaによるログの可視化

Kibanaは、Elasticsearchに保存されたデータを可視化するツールです。Kibanaを使用することで、膨大なログデータを効率的に検索・分析し、ダッシュボードに表示できます。

server.port: 5601
elasticsearch.hosts: ["http://localhost:9200"]
kibana.index: ".kibana"

この設定ファイルにより、KibanaはElasticsearchのデータを取得し、ダッシュボードを通じてログの可視化が可能になります。

New Relicによる異常検出とパフォーマンスモニタリング

New Relicは、アプリケーションパフォーマンス管理（APM）ツールとして広く使われており、リアルタイムでの異常検出や詳細なパフォーマンス解析を可能にします。New Relicの強力な分析機能を利用することで、アプリケーションの潜在的な問題を迅速に発見し、修正することができます。

New Relicエージェントのインストール

New Relicエージェントをアプリケーションにインストールすることで、詳細なパフォーマンスデータを取得できます。例として、Node.jsアプリケーションへのエージェント設定を紹介します。

require('newrelic');

New Relicの設定ファイルには、APIキーやアプリケーション名、環境情報を記述します。

license_key: 'your_new_relic_license_key'
app_name: ['Your App Name']
logging:
  level: 'info'

この設定により、New Relicはアプリケーションのメトリクスを収集し、ダッシュボード上で詳細なパフォーマンス解析が可能になります。

自動アラートと異常検出

New RelicやPrometheusといったツールは、異常なパターンを自動的に検出し、適切なタイミングでアラートを発生させる機能を備えています。異常検出のためのルールを設定することで、運用チームはシステムの異常に迅速に対応できます。

• ベースラインアラート：通常のパフォーマンスパターンを自動的に学習し、それを基に異常を検出する。たとえば、特定のAPI呼び出しが通常よりも大幅に遅くなった場合、New Relicはアラートをトリガーし、問題を報告する。
• 異常検出の自動化：機械学習を活用した異常検出を設定することで、手動でのルール設定を減らし、システムの動作を自動で学習して、異常時に即座に通知することが可能。

異常検出とアラート設定例

異常検出のための設定例を以下に示します。

alerts:
  - alert: "HighMemoryUsage"
    expr: process_resident_memory_bytes > 1e9
    for: 5m
    labels:
      severity: "warning"
    annotations:
      summary: "メモリ使用率が高い"
      description: "プロセスのメモリ使用量が1GBを超えています。詳細な調査が必要です。"

この設定により、メモリ使用量が1GBを超えた場合にアラートが発生し、必要に応じて自動対応や手動での調査を行うことができます。

高度なカスタマイズと統合

監視システムの有効性を最大限に引き出すためには、ツールの統合や高度なカスタマイズが不可欠です。この章では、複数の監視ツールを統合し、システム全体のパフォーマンスと異常検出の精度を向上させる方法について詳しく解説します。また、異なるツール間でのデータ連携や、カスタムアラートルールの作成方法も紹介します。

異なる監視ツールの連携とデータ統合

複数の監視ツールを効果的に連携させることで、システム全体の状況をより深く把握し、アラートの精度を向上させることが可能です。たとえば、Prometheusでメトリクスを監視し、ELKスタックでログを管理することで、パフォーマンスの異常検出とその原因特定が迅速に行えるようになります。

PrometheusとElasticsearchの連携

PrometheusとElasticsearchを連携させることで、メトリクスとログの両方を統合的に管理できます。これにより、特定のエラーや異常が発生した際に、関連するメトリクスデータとログデータを同時に分析することが可能になります。

以下は、Prometheusのアラートが発生した際に、Elasticsearchから関連するログを自動的に取得する設定例です。

alerting:
  alertmanagers:
    - static_configs:
      - targets: ['localhost:9093']
 
receivers:
  - name: 'elasticsearch-logs'
    webhook_configs:
      - url: 'http://localhost:9200/_search?q=error'
        send_resolved: true

• alertmanagers：PrometheusのAlertmanagerにアラートを送信し、アラートが発生した際に指定された受信者（ここではElasticsearchのAPI）に通知する。
• webhook_configs：Alertmanagerがアラート発生時にElasticsearchに対して検索リクエストを行い、関連するログを取得する。

この設定により、アラートが発生すると即座に対応するログが検索され、異常の原因を迅速に特定できます。

Grafanaによる統合ダッシュボードの作成

Grafanaは、PrometheusやElasticsearchなど、複数のデータソースを統合して一元的なダッシュボードを作成することが可能です。これにより、メトリクスデータとログデータを横断的に監視し、異常の相関関係を素早く発見することができます。

datasources:
  - name: Prometheus
    type: prometheus
    url: http://localhost:9090
 
  - name: Elasticsearch
    type: elasticsearch
    url: http://localhost:9200
    access: proxy
    jsonData:
      esVersion: 7

Grafanaのダッシュボード上で、異なる監視ツールからのデータを一元管理できるようになると、異常検出とその分析がより迅速かつ正確に行えるようになります。

カスタムアラートルールの作成

アラートルールをカスタマイズすることで、システムに応じた最適な監視体制を構築できます。たとえば、異常検出の際に、特定のメトリクスやログパターンに基づいたアラートを発生させるようにルールを設定することで、無駄なアラートの発生を抑え、重要な問題に迅速に対応できるようになります。

Prometheusのカスタムアラート

Prometheusでは、メトリクスに基づいてカスタムアラートを設定することが可能です。以下は、HTTPリクエストのエラー率が高くなった際にアラートを発生させるカスタムルールの例です。

groups:
  - name: http_errors
    rules:
      - alert: "HighErrorRate"
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 10m
        labels:
          severity: "critical"
        annotations:
          summary: "HTTP 5xxエラー率が高い"
          description: "5xxステータスのHTTPリクエストが急増しています。システムの調査が必要です。"

• expr: http_requests_totalメトリクスのうち、5xxエラーが5分間の間に一定の割合（ここでは5%）を超えた場合にアラートを発生させるルールを設定している。
• for: この条件が10分以上継続した場合にアラートを発生させる。
• annotations: アラートの内容を詳細に記述し、対応するエンジニアに適切な情報を提供する。

ELKスタックでのカスタムログアラート

ElasticsearchとKibanaを使って、ログに基づくカスタムアラートを設定することも可能です。たとえば、特定のエラーメッセージが頻発している場合、その頻度に基づいてアラートを設定することができます。

trigger:
  schedule:
    interval: "5m"
 
input:
  search:
    request:
      indices: ["logs-*"]
      body:
        query:
          bool:
            must:
              - match: { "message": "OutOfMemoryError" }
 
condition:
  compare:
    count: { "gte": 10 }
 
actions:
  - log: { "text": "OutOfMemoryErrorが10件以上検出されました。" }

この設定では、OutOfMemoryErrorというエラーメッセージが5分間で10件以上発生した場合にアラートをトリガーします。

ログとメトリクスを組み合わせた異常検出

メトリクスとログを組み合わせた異常検出は、システムのパフォーマンス問題や異常を深く理解するための強力な手法です。例えば、メモリ使用量が異常に高くなっている場合、その原因を特定するために関連するログを即座に検索することができます。

ケーススタディ: メモリ異常とログ分析

システムが異常に高いメモリ使用量を示している場合、まずPrometheusを使用してメモリ使用量のメトリクスを監視します。同時に、ELKスタックで関連するログ（例えば、OutOfMemoryErrorやメモリリークに関する警告）を監視し、両者を関連付けることで原因を迅速に特定します。

alerts:
  - alert: "HighMemoryUsage"
    expr: process_resident_memory_bytes > 1e9
    for: 10m
    annotations:
      description: "メモリ使用量が1GBを超えています。関連するログを確認してください。"
 
trigger:
  schedule:
    interval: "1m"
 
input:
  search:
    request:
      indices: ["logs-*"]
      body:
        query:
          bool:
            must:
              - match: { "message": "OutOfMemoryError" }

このケーススタディでは、メトリクスとログを連携させることで、システム全体の異常を迅速に把握し、適切な対応を取ることができます。