なぜmunin
ムニンは美しい：
-リソースを要求しません（サーバーが少ない間）。
-シンプルなセットアップ（便利なデフォルト、シンプルなテキスト設定）;
-プラグインは単純に記述されています（既製のプラグインがたくさんあります）。
ムニンはひどいです：
-便利なデフォルトは変更されません。
-Nagiosとの統合は役に立ちません。
-グラフの不快なグループ化。
-実行時間の長いプラグインが「好きではない」場合、松葉杖を作成する必要があります。
-内部のコードも美しさで輝きません。
rrdに基づいて、これは長所と短所の両方を追加します。
Muninのプラグインモデルは便利であることが判明し、開発者は誰かが中央データベースで何かを開始するのを待たずに、ロールにグラフィックを追加できます。 configのサイズはまだありますが、便利です。
最も重要なことは、Muninはすでに存在していることです。 別のシステムに切り替えるとは、既存のソフトウェアをやり直し、人々を再訓練することです。
問題
-尾を踏み始めました（5分で完了する時間はありません）。
-ディスクの負荷が非常に高い。
-構成を編集するのは不便です（新しいサーバーを追加したり、古いサーバーを削除したりするのを常に忘れています）。
-集約されたグラフは作成が困難です。
-Nagiosとの統合はありませんでした。
さらに、集約されたグラフが存在します。 10台のサーバーからのリクエスト数を集計してから5をオフにすると、履歴データが2倍減少するためです！ 当然、合計スケジュールは毎回計算され、保存されないため、式が変更されました-前のスケジュールが変更されました。
そして彼らの決定
オーバークロック
グラフの生成は必ずCGI / FastCGIとして行ってください。速度は向上しますが、それほどではありません。
高価な方法でのみ、Muninを根本的にオーバークロックし、すべてのrrdをメモリ（tmpfs）に入れることができます。 残念ながら、RAIDもSSDも役立ちません。 275K RRDは14GBを占有しますが、これはそれほど多くありません。32GBRAMを搭載したサーバーは珍しくありません（さらに数GBがMunin自体のプロセスを消費します）。 しかし、ディスクは最も一般的です。
当然のことですが、念のため、2時間ごとに1回ディスクにフラッシュし、既存のRRDをパックする必要があります。 パックされたアーカイブは、SATAドライブに完全に書き込まれます。
Munin自体はrrdをクリーニングしないため、未使用のrrdをクリーニングする必要があります
/ usr / bin / find / mnt / ramdrive / -type f -mtime +5 -delete
メモリ使用の必然性についての小さな余談
このようなすべてのシステムの問題は、データが「横方向」（各メトリックから1回の測定）になりますが、「縦方向」（1つのメトリックのすべての測定）に処理され、このストリームのシャッフルが非常に難しいことです。 すぐに「縦方向」にrrdとして書き込み、レコードを待つことができます。データベースに「横方向」に書き込み（一度に1つずつ大きなテーブルにレコードを追加するだけ）、その後ゆっくり読むことができます。
いずれにしても、メモリ内の大きなキャッシュ/インデックスは不可欠です。
いずれにしても、メモリ内の大きなキャッシュ/インデックスは不可欠です。
大量のメモリがあるため、プロセスを制限せずに更新を実行するため、プラグインの速度が遅くなります。 munin-updateを強制終了するタイマーを設定したのは3分以上です。
次は、青写真の描画チャートです。 プロファイリングは、サーバーが多いほど設定が多く、munin-graph-cgiが起動されるたびに解析されることを示しました。 私の設定は64メガバイトに成長し、解析に最大7秒かかりました（100％のCPU負荷）。 解決策は明らかです。再度解析する必要はありませんが、この松葉杖を置き換えるには、Muninコードを編集する必要があります。
munin-updateは通常通り設定を読み書きし、Storableモジュールを使用して設定オブジェクトを保存します。 munin-graphは、Storableファイルがあればそれを読み取ります。
これにより、グラフの描画が高速化されますが、メモリが消費され、64 MBの構成がプロセスごとに375MBの仮想メモリになります。
奇妙なことに、これはmunin-updateにとって大きな問題ではありません。最初にメモリ内の構成を展開し、次にforkするからです。 その結果、RSSが250 MBで、使用されているRAMが21 GBである上位1000プロセスで（そのうち14がrrd！）
munin-graphには大きな問題があります。各プロセスが400MBのメモリを正直に消費するためです。しかし、これまでのところ十分なメモリがあります。
次の問題はmunin-htmlの起動にあり、解決する時間がありませんでした。 非同期に実行し、コードにいくつかの分岐を追加することで、問題を解決しました。 HTMLは5分ではなく10分ごとに描画されますが、特に新しいサーバーを追加する場合は特に必要ありません。
より便利に
テキスト設定を手で編集するのは不便ですが、スクリプトを生成することは非常に便利です。 幸いなことに、その頃には、システム（仮想マシン）とデータセンター（物理ホスト）で分けられたサーバーのデータベースが既にありました。 簡単なスクリプトは、このデータベースに基づいてMunin構成を書き換え、システム（Muninの観点からはドメイン）ごとにサーバーをグループ化します。 新しいサーバーは自動的に表示され、古いサーバーも自動的に表示されなくなります。 美人！
次の問題は、集約グラフの描画です。
このような計画では、スクリプトを使用して必要なrrdを選択し、それらから最後の値を取得して、たとえば追加します。
サーバーへのリクエストの合計を描画するためのmuninプラグインがここにあります
絶対にしないでください！ これはデモンストレーション用であり、不要なexecのクラウドを作成します。本番環境でRRDを使用することは必須です。
#!/usr/bin/perl -w use strict; use warnings; if($ARGV[0] && $ARGV[0] eq 'config') { print <<<'EOS'; host_name Aggregated graph_title Total requests graph_args --base 1000 -l 0 graph_vlabel requests graph_category Nginx graph_info Total count of requests total.label total requests total.info total requests EOS exit(0); } my @rrd_files = `/bin/ls /mnt/ramdrive/munin/oMobile/*-nginx_log_access-total-d.rrd`; my $sum = 0; foreach my $filename (@rrd_files) { next unless(-f $filename); my $lastline = `/usr/bin/rrdtool fetch $filename AVERAGE -s -15M -e now | fgrep -v 'nan' | tail -n 1`; if($lastline =~ m/^\d+: ([-+.0-9e]+)\s*$/) { $sum+=$1; } } print "total.value $sum\n"; exit(0);
絶対にしないでください！ これはデモンストレーション用であり、不要なexecのクラウドを作成します。本番環境でRRDを使用することは必須です。
ほとんどの場合、1つのチャート上で合計または複数の行のグループ化が行われます（誰かが群衆をノックアウトしているかどうかは非常にはっきりと見えます）。 しかし、より複雑なものを計算することもできます。 たとえば、各サーバーでの平均クエリ処理時間とサーバーへのリクエスト数が指定されている場合、システム全体の平均クエリ時間を計算できます。
host_nameに注意してください。Muninで仮想ホストとドメインを作成し、それらに興味深いグラフィックをグループ化できます。
RRDの最後の値だけでなく、チャートの急激な上昇と下降を読み取ることができます。 原則として、リクエスト数、応答時間、LAなどの20％の急激な変化。 良くないので注意が必要です。 過去1時間、1日、1週間のデータを取得して比較します。 不一致が大きい場合は、アラートを送信できます（たとえば、Nagiosのパッシブチェック）。
合計
-rrdベースのシステムは、rrdファイルをメモリ（tmpfs）に置くことでオーバークロックできます。
-小規模プロジェクトに便利なMuninは、目立った数のサーバーに拡張できます（私にとっては> 1500 munin-node）。
-小さなスクリプトで、非常に複雑なグラフィックを描画できます。
-小さなスクリプトで、傾向を分析してアラートを報告できます。