タグ付けされた質問 「graphite」

2
OpenTSDBとGraphiteの違いは何ですか?
私が知る限り、主な違いは次のとおりです。 データベースのサイズが事前に決定されているGraphiteとは異なり、OpenTSDBは時間の経過とともにデータを劣化させません。 OpenTSDBは1分あたりのメトリックを保存できますが、分単位の間隔があるGraphiteとは対照的です(これについてはわかりませんが、Graphiteのドキュメントには毎分メトリックを保存する保持ポリシーが示されていますが、これが最小時間単位であるかどうかはわかりません)と遊ぶことができます) メトリックスを保存するためにどのツールを使用するかについて情報に基づいた決定をしたいのですが、これら2つのシステムで他の違いを見逃していませんか?それらはどの程度パフォーマンス/スケーラブルですか? ボーナス質問:他に見なければならない時系列システムはありますか?

1
statsdとグラファイトの高可用性、Webアクセスおよびスケーラブルな展開
statsd / graphiteをセットアップして、HTMLデバイスで実行されているJSアプリをログに記録できるようにします(つまり、収容されたLAN環境ではなく、直接制御できない大量の着信データがある場合)。 私の制約: エントリポイントはHTTPを話す必要があります:これは単純なHTTP-to-UDP-statsdプロキシ(たとえば、githubのhttpstatsd)によって解決されます 単一のサーバーの障害に抵抗する必要があります(マーフィーの法則と戦うために:) 水平方向にスケーラブルでなければなりません:webscale、baby!:) アーキテクチャは可能な限りシンプル(かつ安価)に保つ必要があります 私のサーバーは仮想マシンです データファイルはファイラーアプライアンスに保存されます(NFSを使用) tcp / udpハードウェアロードバランサーを自由に使用できます 要するに、データパス:[client]-(http)-> [http2statsd]-(udp)-> [statsd]-(tcp)-> [graphite]-(nfs)-> [filer] これまでの私の調査結果: http2statsd部分のスケーリングは簡単です(ステートレスデーモン) statsd部分のスケーリングは簡単ではないようです(sum、avg、min、maxなどの集計データのグラファイトで一貫性のない値になると思います)。HTTPデーモンがキーを分割するために一貫したハッシュを行わない限り。たぶんアイデア...(しかし、HAの質問があります) グラファイト部分のスケーリングは、シャーディング(カーボンリレーを使用)で実行できます(ただし、HAの問題も解決しません)。明らかに、いくつかのささやきインスタンスは同じNFSファイルを書き込むべきではありません。 ファイラー部分のスケーリングは問題の一部ではありません(ただし、IOが少ないほど良いです:) 共有NFSデータのみを読み取るため、webappのスケーリングは明らかです(私はテストしていませんが)。 だから、誰もが安定したstatsd /グラファイト展開のために共有する経験とベストプラクティスを持っているのだろうかと思っていましたか?

4
WSGIグラファイトスクリプトにアクセスするときにクライアントを拒否する
Mac OS X 10.7ライオンにグラファイトを設定しようとしています。WSGI経由でPythonグラファイトスクリプトを呼び出すようにApacheを設定しましたが、アクセスしようとすると、Apacheとエラーログにアクセス禁止が表示されます。 。 "client denied by server configuration: /opt/graphite/webapp/graphite.wsgi" スクリプトの場所がhttpd.confで許可されていることと、ファイルのアクセス許可を確認しましたが、正しいようです。アクセスするには何をしなければなりませんか。以下はhttpd.confで、ほぼグラファイトの例です。 <IfModule !wsgi_module.c> LoadModule wsgi_module modules/mod_wsgi.so </IfModule> WSGISocketPrefix /usr/local/apache/run/wigs <VirtualHost _default_:*> ServerName graphite DocumentRoot "/opt/graphite/webapp" ErrorLog /opt/graphite/storage/log/webapp/error.log CustomLog /opt/graphite/storage/log/webapp/access.log common WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120 WSGIProcessGroup graphite WSGIApplicationGroup %{GLOBAL} WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL} # XXX You will need …

5
グラファイトのささやきでカウンターを削除するにはどうすればよいですか?
にカウンターがstats.message.fooあり、それをに移動したいstats.messages.foo。 コードを更新して新しいカウンターを追加しましたが、古いカウンターはまだ存在しています。 私がしまし読んグラファイトからのstatを削除するために行うには、すべてのIの必要性をディスク上の適切なささやきのファイルを削除することです、しかし、削除の数秒以内にいるようだwspそれは(データなし)に再生されます。 どのキーが正しいキーかを覚えておく必要があるため、データが保存されているキーの名前を変更する場合、これは面倒です。 古いカウンターを永久に削除する方法を知っている人はいますか?
14 graphite  statsd 


4
tcpdumpはudpのパフォーマンスを向上させます
一連の負荷テストを実行して、次のセットアップのパフォーマンスを判断しています。 Node.js test suite (client) --> StatsD (server) --> Graphite (server) つまり、node.jsテストスイートは、x秒ごとに一定量のメトリックを別のサーバーにあるStatsDインスタンスに送信します。次に、StatsDは、メトリックを毎秒同じサーバーにあるGraphiteインスタンスにフラッシュします。次に、テストスイートによって実際に送信されたメトリックの数と、グラファイトによって受信されたメトリックの数を調べて、テストスイートとグラファイトの間のパケット損失を判断します。 しかし、20〜50%の範囲の非常に大きなパケットドロップ率(UDPプロトコルで送信されていることに注意してください)が得られることがあることに気付きました。そのため、これらのパケットがドロップされる場所を調べ始めたのは、StatsDのパフォーマンスの問題の可能性があるからです。そこで、このドロップが発生した場所を追跡するために、システムのすべての部分でメトリックの記録を開始しました。そして、これは物事が奇妙になる場所です。 私が使用していtcpdumpのを、私は、テストの実行が行われた後、検査キャプチャファイルを作成します。しかし、tcpdumpを実行してテストを実行すると、パケット損失はほとんどありません。tcpdumpがテストのパフォーマンスを何らかの形で向上させているように見えますが、これがなぜ、どのように行われるのかわかりません。次のコマンドを実行して、サーバーとクライアントの両方でtcpdumpメッセージを記録しています。 tcpdump -i any -n port 8125 -w test.cap 特定のテストケースでは、40000メトリック/秒を送信しています。tcpdumpの実行中のテストでは約4%のパケット損失がありますが、テストなしでは約20%のパケット損失があります。 両方のシステムは、次のセットアップでXen VMとして実行されています。 Intel Xeon E5-2630 v2 @ 2.60GHz 2GB RAM Ubuntu 14.04 x86_64 潜在的な原因についてすでに確認したこと: UDPバッファーの受信/送信サイズを増やします。 テストに影響するCPU負荷。(クライアント側とサーバー側の両方で最大負荷40〜50%) 「any」の代わりに特定のインターフェイスでtcpdumpを実行します。 「-p」を指定してtcpdumpを実行し、混合モードを無効にします。 サーバーでのみtcpdumpを実行します。これにより、20%のパケット損失が発生し、テストには影響がないようです。 クライアントでのみtcpdumpを実行します。これにより、パフォーマンスが向上しました。 netdev_max_backlogおよびnetdev_budgetを2 ^ 32-1に増やします。これは違いはありませんでした。 すべてのNICで無差別モードの可能な設定をすべて試しました(サーバーのオンとクライアントのオフ、サーバーのオフとクライアントのオン、両方のオン、両方のオフ)。これは違いはありませんでした。

2
Ext4の使用法とパフォーマンス
CarbonとGraphiteを実行しているマシンのクラスターを持っているので、ストレージを増やすためにスケールする必要がありますが、スケールアップする必要があるか、スケールアウトする必要があるかはわかりません。 クラスターは現在、次のもので構成されています。 1リレーノード:すべてのメトリックを受信し、関連するストレージノードに転送します 6ストレージノード:すべてのWhisper DBファイルを収容 問題は、ディスクの使用率が80%近くになると、パフォーマンスが崖から落ちたように見えることです。クラスター書き込みIOPSは、ほぼ一定の13kから約7kのより混aroundとした平均に低下し、IOwait時間の平均は54%です。 構成レポを確認しましたが、4月上旬以降変更はないため、これは構成変更の結果ではありません。 質問:ディスクサイズを増やすとIOパフォーマンスが制御下に戻りますか、それともストレージノードを追加する必要がありますか? 注:ここにはSSDはありません。たくさんのスピンドルがあります。 関連グラフ: 統計ともの: e2freefrag: [root@graphite-storage-01 ~]# e2freefrag /dev/vda3 Device: /dev/vda3 Blocksize: 4096 bytes Total blocks: 9961176 Free blocks: 4781849 (48.0%) Min. free extent: 4 KB Max. free extent: 81308 KB Avg. free extent: 284 KB Num. free extent: 19071 HISTOGRAM OF FREE …

2
ディスクがいっぱいになるまでの日数の計算
グラファイトを使用して、ディスク使用率の履歴を経時的に追跡します。アラートシステムは、グラファイトのデータを調べて、空き容量が特定のブロック数を下回ったときにアラートを出します。 よりスマートなアラートを取得したい-私が本当に気にかけているのは、「空き領域について何かをしなければならない前にどれくらいの時間が必要か」ということです。たとえば、トレンドが7日間でディスクがなくなるスペースは警告を発生させ、2日未満の場合はエラーを発生させます。 グラファイトの標準ダッシュボードインターフェイスは、デリバティブとHolt Winters Confidenceバンドでかなりスマートにできますが、これまでのところ、これを実用的なメトリックに変換する方法を見つけていません。他の方法で数値をクランチすることにも問題はありません(グラファイトから生の数値を抽出し、それを実行するスクリプトを実行するだけです)。 複雑な点の1つは、グラフが滑らかではないことです。ファイルは追加および削除されますが、時間の経過に伴う一般的な傾向として、ディスク領域の使用量が増加するため、おそらくローカルミニマム(「ディスク空き」メトリックを参照する場合)を調べる必要があります。 )そして、谷間のトレ​​ンドを描きます。 誰かこれをやったことがありますか?

3
Linux Ubuntuで平均奇妙さを読み込む
過去数日間、インフラストラクチャで起こっている奇妙さを理解しようと努めてきましたが、それを理解することができなかったので、皆さんにヒントを与えます。 私はGraphiteで、約2時間ごとに致命的な規則性で発生するload_avgのスパイクに気づいてきました-正確に2時間ではありませんが、非常に規則的です。グラファイトから撮ったスクリーンショットを添付しています 私はこれを調査することに行き詰まりました-これの定期性は、それが何らかのcronジョブまたはそのようなものであると考えるようになりましたが、これらのサーバーで実行されているcronjobはありません-これらは実際にはRackspaceクラウドで実行されているVMです。私が探しているのは、これらの問題を引き起こしている可能性のある種の兆候と、これをさらに調査する方法です。 サーバーはかなりアイドル状態です。これはステージング環境であるため、トラフィックがほとんど入らないか、サーバーに負荷がかかりません。これらはすべて4つの仮想コアVMです。私が確かに知っていることは、約10秒ごとに一連のグラファイトサンプルを取得していることですが、それが負荷の原因である場合、異なるサーバーで2時間ごとに発生するのではなく、常に高いことが予想されます。 これを調査する方法を助けていただければ幸いです! 以下は、sarからのapp01のデータです。これは、上の画像の最初の青いスパイクです。データから結論を出すことはできませんでした。また、バイト書き込みスパイクが30分ごと(2時間ごとではない)に発生していることがわかるのは、30分ごとに実行するchef-clientが原因です。すでにデータを収集してみますが、実際にそれらから結論を出すことはできませんでした。 負荷 09:55:01 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked 10:05:01 PM 0 125 1.28 1.26 0.86 0 10:15:01 PM 0 125 0.71 1.08 0.98 0 10:25:01 PM 0 125 4.10 3.59 2.23 0 10:35:01 PM 0 125 0.43 0.94 1.46 3 10:45:01 PM 0 …

2
データを送信しても、グラファイトですべてのデータポイントに「なし」と表示される
nginxとPostgresSQLを使用してPuppet(https://forge.puppetlabs.com/dwerder/graphite)からGraphiteをインストールしました。データを手動で送信すると、メトリックが作成されますが、そのデータポイントはすべて「なし」(別名null)です。これは、Graphiteに付属のexample-client.pyを実行した場合にも発生します。 echo "jakub.test 42 $(date +%s)" | nc 0.0.0.0 2003 # Carbon listens at 2003 # A minute or so later: $ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | head -n1 Sun May 4 12:19:00 2014 None $ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | tail -n1 Mon May 5 12:09:00 2014 None $ whisper-fetch.py --pretty …

2
グラファイトはランダムにデータを収集しなくなります
collectd、statsd、JMXTransを介してデータを収集するためのGraphiteサーバーがあります...数日以来、私たちは頻繁にデータに穴を開けています。まだ保持しているデータを掘り下げてみると、カーボンキャッシュサイズが増加しています(50Kから4Mに)。収集されるメトリックの数は増加していません(metricsReceivedは約300Kで安定しています)。クエリの数が平均で1000から1500に増加しています。 奇妙なことに、キャッシュサイズが大きくなると、cpuUsageは100%(4 CPU)から50%にわずかに減少します。 不思議なことに、ディスクから読み取ったオクテットの数が増加し、書き込まれたオクテットの数が減少しています。 ほとんどの場合、デフォルト値でカーボンを構成します。 MAX_CACHE_SIZE = inf MAX_UPDATES_PER_SECOND = 5000 MAX_CREATES_PER_MINUTE = 2000 明らかに、システムで何かが変更されましたが、何が原因であるか、どのようにしてこの原因を見つけることができるのかわかりません... 何か助け?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.