物理サーバとNodeとPodの配置関係の一致判定をもとにしたグルーピングによるチケット件数の削減

Cloud and Distributed Systems Laboratory では，ESXi をインストールした物理サーバ，Kubernetesクラスタ上のNode やPod をPrometheus をもちいて監視している．監視ルールで設定した監視対象のメトリクスの値が閾値を超えた際，Alertmanager がアラートを通知し，Redmine にチケットとして登録する．課題は，通知されたアラートをRedmine に登録する際に，同一の障害が原因で通知されたアラートをまとめてチケットとして登録しなければ，チケット件数が増加することである．提案では，アラートが通知された際に，ESXi をインストールした物理サーバ，Kubernetes クラスタ上のNode，Pod の配置関係をチケットに記録する．例えば，Kubernetes クラスタ上のNode のFilesystem が40GB のうち36GB使用され閾値である90%を超えたアラートが通知され，チケットが登録された際，Node 上に配置されているPod 名をそのチケットに記録する．その後，最初に登録されたチケット内に記録されたPod 名のアラートが通知された際は，最初に登録されたチケットに関連したチケットとして登録する．評価では，Kubernetes クラスタ上のNode のメモリ使用量が8GB 全て使い切りPod がダウンした事例，Node で使用されるFilesystem の容量が40GB のうち36GB 使用され使用率が90%を超えた事例，物理サーバに対してBlackbox exporter による疎通確認ができなくなった事例の3 つを再現する．評価指標は，監視対象ごと，アラート名ごと，Job ごと，配置関係ごと，提案手法の5 種類で登録されたチケットの件数を比較した．評価の結果，Kubernetes クラスタ上のNode のメモリ使用量が8GB 全て使い切りPod がダウンした事例では，提案手法は，チケット件数が9 件となりチケットをまとめて登録することができなかった．Node で使用されるFilesystem の容量が40GB のうち36GB 使用され使用率が90%を超えた事例では，提案手法は，チケット件数が1 件となり登録されるチケットをまとめることができた．物理サーバに対してBlackbox exporter による疎通確認ができなくなった事例では，提案手法は，チケット件数が14 件となりまとめることができなかった．また，2025 年12 月4 日から12 月8 日までで登録されたチケットの件数を提案手法ありとなしで比較した．2025 年12 月4 日で登録されたチケットは，提案手法なしで124 件，提案手法ありで55 件となりチケットをまとめることができた．一方で，2025 年12 月5 日から12 月8 日は登録されたチケット件数が，提案手法ありとなしで変わらなかった． ...