問題タブ [whisper]

グラフィカルに監視したいアプリケーションがあります。

このStatsD クライアントを使用しています。バックエンドとしてグラファイトを使用しています。基本的なワークフローについて質問があります。

アプリケーション内にメトリクスを含めるために、StatsD クライアントを使用します。これらのメトリックは、UDP パケットの形式で送信されます (通常)。Graphite (具体的には Graphite 内のCarbon ) は、これらのパケットをキャプチャし、Whisperデータベースに時系列データとして保存します。

では、 StatsDデーモンの役割とは正確には何でしょうか? StatsD クライアントと Graphite のみを使用して、動作するアプリケーションを作成しました。StatsD デーモンの使用法がどこにありませんか?

私の元のカーボン ストレージ スキーマ構成は 10s:1w、60s:1y に設定され、数か月間正常に動作していました。最近、1s:7d、10s:30d、60s、1y に更新しました。次の bash を使用して、すべてのウィスパー ファイルのサイズを変更し、新しい保持スキーマを反映させました。

whisper-info.py を使用して、正しい保持とデータ ポイントで更新されていることを確認しました。また、ストレージ スキーマ検証スクリプトを使用して、ストレージ スキーマが有効であることを確認しました。

carbon-cache{1..8}、carbon-relay、carbon-aggregator、および collectd サービスは、ウィスパーのサイズ変更前に停止され、サイズ変更が完了すると開始されました。

しかし、Grafana ダッシュボードにチェックインすると、collectd プラグイン グラフに正しいデータ ポイント (1 秒あたりのデータはありますが、データはありません) を含む空のグラフが表示されます。しかし、データを提供しているグラフでは、1 秒ではなく 10 秒ごと (古い保持期間) にデータとデータ ポイントが表示されます。

/var/log/carbon/console.log は問題ないようで、collectd whisper ファイルにはすべて carbon ユーザー アクセス権があるため、書き込み時にアクセス許可が拒否されることはありません。

グラファイト ホストのポート 2003 で ngrep を実行すると、リレーへの接続と送信されているメトリックが表示されます。これらのメトリクスは、8 つのキャッシュのプールから pickle ポートに中継されます。

他の誰かが同様の問題を経験しましたか、または問題をさらに診断するのに役立つ可能性がありますか? ここで何かを見逃しましたか？