HTTPステータスコードを含むログとメトリクスの対応関係を用いたアラート件数の削減

東京工科大学コンピュータサイエンス学部のCloud and Distributed Systems Laboratory(以下CDSL と呼ぶ) では，インターネットに公開しているサイトであるDoktor を，Prometheus で監視し，ログをElasticsearch に保存している．Prometheus はDoktor のHTTP ステータスコードのメトリクスを取得し，その値が200 以外になった場合にアラートを発行する．Alertmanager はPrometheus で発行されたアラートをRedmine に送信し，Redmine でチケットが作成される．課題は，Alertmanager からRedmineに送信されるアラートの中に，Prometheus の誤検知が含まれていることである．提案ではRedmine にチケットが作成された際，Prometheus が取得した対象のHTTP ステータスコードのメトリクスの値と，その時刻の前後にElasticsearch に記録されたHTTP リクエストのログのステータスコードを1 つのデータセットとして保存する．調査者はチケットの作成時刻と，その前後の時間に記録されたログを確認し，データセットに対して「要確認」か「問題なし」かのラベル付けを行う．チケット作成時には，新たに作成されたデータセットに含まれるPrometheus が取得したHTTP ステータスコードのメトリクス値と，Elasticsearch に記録されたHTTP リクエストのログのステータスコードを過去のデータセットに含まれる同じ値の組み合わせと比較する．一致する場合には，過去のデータセットに付けられた「要確認」か「問題なし」のラベルを新しいセットに付ける．一致しない場合は「要確認」のラベルをつけアラート通知を行う．「問題なし」の場合にはアラート通知は行わない．実験では，提案手法の適用により削減できるアラート通知の数を評価する．2025 年11 月24 日から11 月26 日において作成された55 件のチケットに対応するデータセットを実験の対象とする．そのうち11 月24 日に作成された25 件のデータセットについては調査者がログを確認しラベル付けを行い，提案手法が使用する過去の複数のデータセットとした．調査者はCDSL に所属する学生4 人である．ラベル付けの結果，全員が「問題なし」と判断したデータセットは25 件中7 件で，全員が「要確認」と判断したデータセットはなかった．また，4 人中1 人が「要確認」と判断したデータセットが6 件，2 人が「要確認」と判断したデータセットが5 件，3 人が「要確認」と判断したデータセットが7 件だった．全員が「問題なし」と判断した過去のデータセットのみを「問題なし」のデータセットとして使用し，11 月25 日から11 月26 日に作成された30 件のデータセットを評価対象として提案手法を適用した．その結果，30 件中6 件が「問題なし」とラベル付けされた過去のデータセットと一致したため，アラート通知の対象外となることが確認でき，残りの24 件は「要確認」となりアラート通知の対象となることが確認できた． ...