3

アプリケーションのタイミング メトリックを追跡するために statsd (正確には django-statsd ライブラリ) を使用しています。スタックの複数のレベルで何かをテストする必要がある場合、問題が発生します。代表的な例: オブジェクトが作成され、そのオブジェクトから post_save メソッドが呼び出され、そこから celery タスクがトリガーされ、続いて twilio を呼び出してユーザーにテキスト メッセージを送信する別の celery タスクがトリガーされ、最終的にヒットします。サーバーのエンドポイントをアップして、テキストが正常に送信されたことを知らせてくれます。

各関数のタイミングを手動でつなぎ合わせる必要なしに、この全体の時間を追跡したいと思います (とにかく、呼び出し間の待ち時間が失われます)。また、コール スタック トリップの最後に参照する「開始時間」をデータベースに書き込むことも避けたいと思います。開始時間のデータベース ルックアップ時間もメトリックを歪めるからです。ただし、ある種のキャッシュへの呼び出しは、無視できるほど低レイテンシーになる場合があります。しかし、それには、このプロトタイプの段階で必要になると思っていたよりも少し多くのインフラストラクチャが必要です。

これに対する最善のアプローチに関するアイデアはありますか?

4

1 に答える 1

1

また、コール スタック トリップの最後に参照する「開始時間」をデータベースに書き込むことも避けたいと思います。開始時間のデータベース ルックアップ時間もメトリックを歪めるからです。ただし、ある種のキャッシュへの呼び出しは、無視できるほど低レイテンシーになる場合があります。

Statsd は、デフォルトで UDP に設定され、オーバーヘッドがほとんどないファイア アンド フォーゲット メカニズムであるため、これに適しています。また、UDP は非同期であるため、パケットをスローする関数は ACK を待たずにすぐに移動します。

Any ideas on the best approach for this?

また、レイテンシーをプロファイルすることもできますが、少し手間がかかります。関数から関数、モジュールに余分な変数を渡したくない場合は、制御フローのセマンティクスに従って生データを「処理」する必要があります。

a(){
    statsd(a.begin_time)    
    ...
    statsd(a.end_time)
}
.........................
.......LATENCY SEA.......
.........................

b(){
    statsd(b.begin_time)
    ...
    statsd(b.end_time)
}

.........................
.......LATENCY SEA.......
.........................

c(){
    statsd(c.begin_time)
    ...
    statsd(c.end_time)
}

制御フローでは「B は A の後に来る」ため、

latency(a,b) = b.begin_time - a.end_time
于 2014-02-12T05:45:08.410 に答える