サーバー監視用のニューラルネット

サーバーモニターアラームを取得し、問題の根本的な原因を特定するためのpybrainを調べています。教師あり学習を使用してトレーニングしたり、トレーニングデータセットをキュレーションしたりして満足しています。データは次のような構造になっています。

• サーバータイプA＃1
  • 警報タイプ1
  • 警報タイプ2
• サーバータイプA＃2
  • 警報タイプ1
  • 警報タイプ2
• サーバータイプB＃1
  • アラームタイプ99
  • 警報タイプ2

だから、あるn個のサーバーがして、XのことができるアラームUPまたはDOWN。どちらnとx可変です。

サーバーA1のアラーム1および2がDOWNである場合、そのサーバーでサービスaがダウンしており、問題の原因であると言えます。

すべてのサーバーでアラーム1がダウンしている場合、サービスaが原因であると言えます。

原因には複数のオプションが存在する可能性があるため、単純な分類は適切ではないようです。

また、後のデータソースをネットに結び付けたいと思います。一部の外部サービスにpingを実行するスクリプトだけなど。

シリアルサービスチェックのため、適切なアラームがすべて一度にトリガーされるとは限らないため、あるサーバーがダウンしてから5分後に別のサーバーがダウンする可能性があります。

私は最初にいくつかの基本的なことをしようとしています：

from pybrain.tools.shortcuts import buildNetwork
from pybrain.datasets import SupervisedDataSet
from pybrain.supervised.trainers import BackpropTrainer


INPUTS = 2
OUTPUTS = 1

# Build network

# 2 inputs, 3 hidden, 1 output neurons
net = buildNetwork(INPUTS, 3, OUTPUTS)


# Build dataset

# Dataset with 2 inputs and 1 output
ds = SupervisedDataSet(INPUTS, OUTPUTS)


# Add one sample, iterable of inputs and iterable of outputs
ds.addSample((0, 0), (0,))



# Train the network with the dataset
trainer = BackpropTrainer(net, ds)

# Train 1000 epochs
for x in xrange(10):
    trainer.train()

# Train infinite epochs until the error rate is low
trainer.trainUntilConvergence()


# Run an input over the network
result = net.activate([2, 1])

しかし、可変数のアラームを静的な入力数にマッピングするのに苦労しています。たとえば、サーバーにアラームを追加したり、サーバーを追加したりする場合、ネット全体を再構築する必要があります。それを行う必要がある場合、私はそれを行うことができますが、もっと良い方法があるかどうかを知りたいです。

私が考えている別のオプションは、サーバーのタイプごとに異なるネットを使用することですが、環境全体の結論を引き出す方法がわかりません。一度にすべてのホスト。

どのタイプのアルゴリズムを使用する必要がありますか。また、データセットをマッピングして、全体として変数入力を使用して環境全体の結論を引き出すにはどうすればよいですか？

私の意見では、あなたはあなたの問題を解決するために間違った方法を調べています。

厳密には数値データはありません。

統計ベースの機械学習は、このような問題に非常に苦労しています。あなたの問題は、ルールベースのシステムで解決すべき問題の1つに似ています。私の最初の本能は、ルールを理解し、それらを分類につながるコードに組み込むことです。

ただし、ロジックに基づいてこのようなルールベースのシステムを学習する方法があります。それらは、今日の機械学習ではまったく流行遅れです。https://en.wikipedia.org/wiki/Rule-based_system

上記のコメントに沿って、ルールベースのアプローチを試すことをお勧めします。使用しているサーバーごとに、そのサービスをクエリします。サーバーですべてのサービスが停止している場合は、サーバーに問題があります。各サービスについて、サービスが実行されていることを報告するサーバーがない場合は、サービスに問題があります。両方の場合は、それぞれに通知が届き、任意の構成要素で何が起こっているかを検査できます。

コスト、メンテナンス、およびANNモデルを使用した結果が悪いというリスクはすべて、単純なルールベースのソリューションを超えており、上司はおそらく、ここで意味のあることをするだけで後悔するでしょう。

サーバーとプロセスの機能を維持することに真剣に取り組んでいる場合は、運用環境で何が起こっているかについて信頼できるリアルタイムの通知を提供するAPMサービスに投資することをお勧めします。

ANNのしくみを学びたいだけの場合は、別の問題を試してください。分類または異常検出用のよく知られたデータセットは、カスタムデータセットよりもANNの機能についてより多くの洞察を提供します。カスタムデータセットは、効果的な学習スキームに強制するのが非常に難しい場合があります。