ログとシステムのバイタルを監視するための Graphite と Kibana 3 の統合を理解するのに苦労しています。ここで説明されているログ管理システムの図を参照しています。
前もって感謝します。
statsd-graphite を使用する理由:
Statsd と Graphite は、ログやシステム バイタルだけでなく、あらゆるものを視覚化するのに役立ちます。statsd-graphite スタックを使用すると、たとえば、サイトの左下に 10 秒以上ホバリングしたユーザー数を測定するのは非常に簡単です。
間にログが含まれていないため、グラファイトが提供するスケーラビリティは、IO の観点から見て比類のないものです。また、statsd が UDP と通信することも考慮してください。したがって、1 分あたり 300K のメトリクスを簡単に収集できます。
見るために何かを記録する必要はありません。
統合：
共有したアーキテクチャ図に明確に示されているように、視覚化する統計をフィルタリングして、statsd に転送することができます。これは、logstash-elasticsearch から直接視覚化するキバナと並行しています。Graphite と Kibana の両方のデータを Graphite 経由で表示したい場合は、データを冗長化する方が簡単な方法です。これは、webapp が Elasticsearch に直接クエリを実行しないためです。
Vimeo のGraph Explorerを調べてみるとよいでしょう。これは、elasticsearch を照会します。
アップデート:
Logstash ができないわけではありませんが、その役割のために「設計」されていませんが、statsd などはそうです。
より単純なクエリ言語があるかどうか疑問に思っていました。
グラファイトの組織の固有のスキームはツリー状であるため、検索は異なるサブツリーからの結果を生成しない/生成できません。これにより、クロスディメンション検索にはあまり適していません。GE は、パワーが必要な場合に最も単純です。
Graph Explorer の流れ -
Graph Explorer は、メトリックにタグを追加し、 elasticsearch と統合することで、これに対処します。GEが実際に行っていることは、
1 回 - Graphite フロントエンドに接続し、API 呼び出しを行ってすべてのメトリックを取得します。
次に、古いスタイルの proto 1 メトリック (ABC) をタグベースの proto 2 メトリック (host=A.app=B.username=C) に「変換」します。
これは、インデックスを維持する ES にエクスポートされます。
GE フロントエンドにクエリを実行すると、ES に接続して必要なものを理解します。
次に、GE は Graphite-API にクエリを実行し、結果を GE フロントエンドに配信します。
さらに、グラフエクスプローラーは、コレクションにダイヤモンドを使用していると想定していますか?
いいえ。
鉛筆、オリオン、グラファイトと比べてどうですか?
これらは視覚化に対する表面上の最適化です。彼ら-
グラフのルック アンド フィールを変更します。
API のクエリをより簡単にします。
より良い監視フローを可能にします。
情報を保存または検索する方法を変更するものではありません。GE は、それ自体をメトリック データに「より深く」埋め込んでいるため、メトリックのクエリ方法に対して真の優位性があります。(次元横断検索)
注意喚起-
GE の指標インポート プラグインは完璧とはほど遠いものです。1000 個のメトリックのうち 300 個が正常にインポートされました。レンダリングも重く、フロントエンドはより多くの NW を消費します (ホバー可能、ズーム可能機能のため)。
アップデート-
グラファナが出ました。