web-dev-qa-db-ja.com

muninのより良い/代替のフロントエンド/グラフ？

Muninセットアップを実行していますが、ログに記録されたデータのより長く詳細なビューを取得しながら、munin-nodeセットアップはそのままにしておきたいと思います。ログに記録されたすべてのデータを無期限に保持したいと思います。理想的な解決策は、 注釈付きタイムライン ウィジェットのようなものを使用して、履歴の任意のポイントにズームインできるようにすることです。

編集：muninが不可逆データベースを使用していることはすでにわかっているので、それに代わるものが必要になると思います。つまり、私が間違っていない限り、ムニンに取って代わらない答えは私には役に立たない可能性が高いです。

私が望んでいるのは、munin構成ファイルの適切なセクション（すべてのmunin-nodeのアドレスなど）を読み取ることができ、munin-nodeのインストールをまったく変更する必要がないmuninの代替品のドロップです。

munin
6
BCS

Muninは、私が知っているそのタイプのすべてのツールと同様に、ラウンドロビンデータベース（RRD）ファイルを使用してデータを格納します。これが RRDの基本の説明 です。 RRDファイルは、ラウンドロビンアーカイブ（RRA）で構成されています。 RRAは、Wordの2つの意味で「不可逆」であり、複数のデータポイントを1つに結合し、特定の量が収集された後にデータを上書きします。これがどのように行われるかを指定できます。たとえば、次のコマンドでRRDファイルを作成したとします。

rrdtool create example.rrd \
[skip some necessary options]
--step 300
RRA:LAST:0.5:1:288 \ 
RRA:AVERAGE:0.5:12:168 \
RRA:AVERAGE:0.5:288:28

のステップは、rrdtoolがプライマリデータポイントまたはPDPと呼ぶメトリックを5分ごとに収集していることを示しています。各RRA行は、CF：xff：steps：rowsの4つを指定します。

1）CF、または統合機能。これにより、RRDが複数のプライマリデータポイントを統合データポイント（CDP）に結合する方法が決まります。 [〜＃〜]平均[〜＃〜]すべての値、[〜＃〜] min [〜＃〜]最大値を使用、-を使用できます[〜＃〜] max [〜＃〜]最大値、または[〜＃〜] last [〜＃〜]値を使用します。

2）「xファイル係数」は、CFが[〜＃〜]不明[〜＃〜]の値を返す前に欠落している必要があるデータの比率です。欠測データを操作するもの。

3）ステップ。これは、統合データポイントの計算に使用されるプライマリデータポイントの数です。

4）行。これは保持する統合データポイントの数です。

この例では、最初のRRAはプライマリデータポイントを1日保持し、2番目はプライマリデータポイントを1時間ごとに平均して、1日の平均を1週間保持し、3番目はプライマリデータポイントを毎日平均して、 4週間の1日平均。

Muninでより長く、より詳細なデータを保持する場合は、ステップが低く行が多いRRAを持つRRDファイルを使用します。これは graph_data_size オプションによって制御されます。 Muninには 人間が読める構文 があり、これを簡単に構成できます。前の例のオプションは、次のように変換されます。

graph_data_size custom 5m for 1d, 1h for 1w, 1d for 4w

プライマリデータポイントを2年間保持する場合は、ショートカットを使用してgraph_data_sizeをhugeに設定できます。

このオプションを変更した後、既存のRRDファイルを削除して、Muninが新しい保持設定で新しいファイルを作成するようにする必要があります。

2
sciurus

私は最近、たくさんのトレンド/アラートツールを評価しました。

少なくともエージェント/コレクターモデルには、「nagios /リクエストモデル」と「syslog /レポート」モデルの2つの異なるモデルがあるようです。

したがって、アクティブなモデルでは、

  • Nagios ：主にアラート用ですが、一部の グラフ機能 が移植されています。

  • Zabbix ：トレンド/アラートの組み合わせ。データをバックエンドSQLデータベースに格納します（したがって、RRDデータベースのようにデータが失われたり丸められたりすることはありません）。

  • Munin ：トレンド/ nagiosにデータを送信するプラグインを使用（つまり、muninを使用してデータを収集し、ローカルデータを参照するnagiosプログラムを実行するため、muninとnagiosの両方のエージェントは必要ありませんリモートシステム）。

「syslog」モデルは、マルチキャストまたはユニキャストUDPモデルのいずれかを使用します。このモデルでは、監視対象のシステムが時間間隔ごとにUDPパケットをコレクターに送信します。トラフィックは一方的なものです。レポートシステムは、監視システムが稼働しているかどうかに関係なく、間隔ごとに送信します。

collectd と ganglia 両方ともこのモデルに従います。私はガングリアを使ったことがありませんが、collectdにはnagiosに報告/警告/クリティカルステータスを報告できる小さなプラグインがあります（また、ホストからのデータが3時間間隔で表示されていないかどうかも報告するため、システムがクラッシュしたかどうかを確認できます自宅に電話しないため）。

Collectdには、すぐに使用できる恐ろしいグラフ作成/レポートツールがありますが、RRDとCSVの両方のテキストファイル（名前、time_t、値）を出力するため、独自のダッシュボードを非常に簡単に作成できます。

私は神経節であまり遊んでいませんでした。

2
chris

MuninはRRDToolを使用してデータを保存します。 RRDスタイルのデータストレージでは、時間が経つにつれてデータポイントの解像度が失われるため、「履歴の任意のポイントにズームイン」できるという要件は機能しません。

Muninに他のタイプのバックエンドストレージを使用させる方法があるかもしれませんが、私はそれを必要としたことがないので、これが実際に可能であるかどうかを確認できません。

0
EEAA