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

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

28 monitoring  metrics  graphite  opentsdb 

仮想化プラットフォーム上の精度を監視し、パフォーマンスを評価するために、CPUは時間が盗むますます関連するメトリックになっている-を参照してEC2を監視：盗まれたCPUの場合の文脈で有益要約のためのAmazon EC2上で、IBMの紙CPU時間が占め Aのために概念のより詳細な技術的説明（図を含む）： スチール時間は、ハイパーバイザーが別の仮想プロセッサーにサービスを提供している間に仮想CPUが実際のCPUを待機する時間の割合です。 したがって、最近ではほとんどの関連するUnix / Linux監視ツールで公開されています-たとえば、％stealまたはst in sarまたはcolumnを参照してくださいtop： st-スチール時間 他のタスク（別の仮想マシンの実行など）のためにハイパーバイザーによってこの仮想マシンから「盗まれた」CPUの量。 Windowsで同じメトリックをキャプチャする方法を理解できませんでしたが、これはすでに可能ですか？（理想的には、EC2上のWindows 2008 Server R2 AMI 用であり、もちろんそれぞれのWindowsパフォーマンスカウンターを介します。）

24 windows  amazon-ec2  monitoring  cpu-usage  metrics 

Linuxは、ルーティングの選択を行うときに、宛先への最も具体的なルートを選択することを理解しています。しかし、ルートのメトリックはどうでしょうか？ルートの特異性よりも高い優先度を持っていますか？ Linuxで使用されるルーティング選択アルゴリズムの詳細を参照していただければ幸いです。

17 linux  routing  route  iproute2  metrics 

仮想化にはいくつかの大きな利点がありますが、仮想化されたサーバーがより高いパフォーマンスを必要とし、物理に移行する必要がある場合があります。 私の質問は、これらの時間はいつですか？サーバーを専用の物理ボックスに移動するとパフォーマンスが大幅に向上することを示す測定可能なデータとメトリックを探しています。個人的に私はWindowsに興味がありますが、おそらく基本的なことはすべてのプラットフォームで同じです。

12 virtualization  performance  metrics  cross-platform  v2p 

私は、高可用性アプリケーション（つまり、5秒のページ間ナビゲーションで99.5％増加しているアプリ）のパフォーマンスと可用性を正確に測定することに苦労しているFortune 500企業で働いています。この可用性の数値を決定するために、予定されたダウンタイムと予定外のダウンタイムの両方を考慮します。ただし、最近CDNをミックスに追加したため、メトリックが少し複雑になります。現在、CDNはトラフィックの約75％を処理し、残りを独自のサーバーに送信しています。 「真のユーザーエクスペリエンス」と呼ばれるものの測定を試みます（つまり、テストスクリプトは、一般的なユーザーがアプリケーションをクリックすることをエミュレートします）。これらの監視スクリプトは、ネットワークの外側にあります。時間。 経営陣は、可用性を測定するために最悪のシナリオを採用することを決定しました。したがって、オリジンサーバーに問題があり、CDNがコンテンツを正常に提供している場合でも、可用性が低下します。同じことが逆の場合にも当てはまります。私は、「ユーザーエクスペリエンス」が成功している限り、不必要に自分を罰するべきではないと考えています。結局のところ、パフォーマンスと可用性を改善するためにCDNがあります！ 他のフォーチュン500企業が可用性の数値をどのように計算するかについての知識を持っている人がいるかどうか疑問に思っています。たとえば、ダウンしていないように見えるCDNを使用する店頭のapple.comを見てください（主要な製品発表がある場合を除きます）。これらの指標で不必要に自分自身を傷つける必要があるとは思わない。私たちはされているこれらの数字に基づいてビジネス上の意思決定を行います。 しかし、これらの指標が経営陣に見えることを考えると、問題は非常に迅速に解決され、解決されます（読む：すぐに赤テープを切り抜けます）。何らかの外部要因（CDN）が数値に影響しているため、アプリケーションがアップまたはダウンしていること。 考え？ （誤ってこの質問をStackOverflowに投稿しましたが、クロスポストは事前に申し訳ありません）

11 high-availability  reporting  cdn  metrics 

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 明らかに、システムで何かが変更されましたが、何が原因であるか、どのようにしてこの原因を見つけることができるのかわかりません... 何か助け？

8 graphite  metrics 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ サーバー障害のトピックになるように質問を更新します。 5年前休業。 私は長年複数のサーバーでmuninを使用して大きな成功を収めてきましたが、100を超えるmunin-nodeでクライアントに負荷がかかると、処理がタイムアウトします。 cronジョブとクライアントプロセスの数にいくつかのスケーリングの変更を加え、実行中のプラグインの数などを減らしましたが、よりスケーラブルなアーキテクチャを持つ代替案を探すことにしました。 提案や経験があれば歓迎します。私は基本的に、キャパシティプランニングに使用できるサーバーメトリックと、リソース使用状況の診断に関心があります。（アラート用のnagiosがあります）

8 munin  metrics  monitoring  resource-management