Metrics
組み込みのリクエスト、メモリ、インフラ、データベースのメトリクス、env.metrics によるカスタムメトリクス、そしてログから生成するメトリクスです。
組み込みメトリクス
すべてのプロジェクトで、何も有効にせずに収集されます。
| セクション | メトリクス |
|---|---|
| Overview | リクエスト数、エラー、ステータスクラス、経過時間の p50/p95/p99。デプロイと OOM のマーカー付き |
| Infrastructure | 上限に対するメモリ使用量、CPU 使用量とスロットリング、CPU・メモリ・I/O のプレッシャーストール(PSI)、I/O バイト数、原因別のプロセスの起動と終了、ウェイクのレイテンシを含むパークとウェイク、クラスごとの Durable Objects |
| Database | env.db のステートメントのフィンガープリント、データベースのサイズと増加、テーブルとインデックスのサイズ |
メモリはプロジェクト自身の cgroup から読み取るため、グラフに表示されるのは、ご自身のプロセスとご自身の上限です。隣のプロジェクトのものでも、ノード全体のものでもありません。直近 24 時間は 10 秒ごと、15 日までは 1 分ごと、それ以降は 1 時間ごとの値になります。メモリがソフトリミットに達し、プロセスが強制終了されずに減速された場合、グラフには throttled の印が付きます。
メトリクスは Free プランで 15 日間、Pro プランで 15 か月間さかのぼって読めます。
Database
Observability → Database は env.db のステートメントをフィンガープリントでまとめます。リテラルは $n になり、IN のリストは 1 つにまとめられるため、SELECT * FROM orders WHERE id = 8812 と … id = 9001 は 1 行になります。フィンガープリントごとに、直近 48 時間の呼び出し回数、合計と平均の時間、p95 と p99、SQLSTATE 別のエラー、発行したルートを表示します。サンプルのステートメントは正規化した形で、リテラルがノードの外に出ることはありません。クエリの監視は Pro プランの機能です。
状態タブには、データベースのサイズとその履歴、テーブルとインデックス、次のパーク時の VACUUM を待っている pgvector の削除マーカーが表示されます。ご自身の SQL ではなく決まったカタログのステートメントを実行し、member ロールと db:read が必要です。
カスタムメトリクス
env.metrics はすべてのハンドラーの env にあります。runlot.json でのバインディングは不要です。
export default {
async fetch(request, env) {
const started = Date.now();
const order = await placeOrder(request, env);
env.metrics.count("orders.placed", 1, { plan: order.plan });
env.metrics.distribution("orders.cents", order.cents, { plan: order.plan });
env.metrics.gauge("queue.depth", order.queueDepth);
env.metrics.distribution("checkout.ms", Date.now() - started);
return Response.json(order);
},
};| メソッド | 記録する内容 |
|---|---|
count(name, value = 1, tags) | 区間ごとに合計するカウント |
gauge(name, value, tags) | 最後の値 |
distribution(name, value, tags) | すべての値。p50 から p999 は 1 時間ごとの値の平均ではなく、任意の期間について計算されます |
env が手元にないコードでは、同じ 3 つの関数をインポートします。
import { count, distribution } from "runlot:metrics";
count("cache.miss");-
名前は英字または
_で始まり、英字、数字、_ . : - /を含められます。最大 200 文字です。1 つのポイントにつきタグは最大 16 個で、値は文字列に変換されます。 -
ポイントはサンプリングされません。そのため、ログがサンプリングされていてもメトリクスは正確です。
-
observability.tagsのタグは、すべてのポイントに追加されます。runlot.json { "observability": { "tags": { "team": "payments" } } }タグは最大 16 個です。キーは小文字で、プラットフォームが設定するキー(
org、project、env、version、commit、handler、route、region、binding、peer.host、service、do.class)は使えません。 -
プロジェクトにすでに
metricsという名前のバインディングがある場合、そのバインディングが名前を保ち、ファサードはenv.RUNLOT_METRICSになります。 -
カスタムメトリクスは、Runlot Errors のアイソレート内のキャプチャを利用します。
"observability": { "errors": false }にするとenv.metricsは定義されず、runlot:metricsの関数は何もしません。 -
runlot devは各ポイントを[runlot:metrics]としてコンソールに出力します。
系列
系列とは、1 つのメトリクス名とタグの値の 1 つの組み合わせです。各プロジェクトには、Free プランで月 100、Pro プランで月 2,000 の異なる系列の枠があります。それを超えると、新しい系列は拒否されて数えられ、すでにある系列は記録を続けます。Observability → Metrics に拒否の件数が表示されます。Pro プランでは上限を引き上げるか解除でき、2,000 を超えた系列は系列あたり月 $0.05 で課金されます。ユーザー ID やリクエスト ID のように値の種類に限りがないタグは、値ごとに系列を作ります。そうした値はログのフィールドに入れてください。
ログからのメトリクス
ログからのメトリクスは、ログイベントまたは呼び出しの記録に対するフィルターで定義するカウントまたは分布です。取り込み時に、サンプリングと 1 日の上限の前に計算されるため、保存されたログが 1 % にサンプリングされていても正確なままです。
{
"logMetrics": [
{
"name": "checkout.failed",
"kind": "count",
"dataset": "events",
"filter": [{ "key": "event", "op": "eq", "value": "checkout_failed" }],
"groupBy": ["reason"]
},
{
"name": "slow_requests",
"kind": "distribution",
"dataset": "invocations",
"filter": [{ "key": "$wall_ms", "op": "gt", "value": 1000 }],
"valueKey": "$wall_ms",
"groupBy": ["$route"]
}
]
}それぞれがカスタムメトリクス log.<name> になり、グループ化のキーはそれぞれタグになります。その系列は、ほかの系列と同じく系列の枠に数えられます。名前は小文字で、英字で始まり、英字、数字、_、. を含められます。最大 64 文字です。プロジェクトあたり最大 50 件です。上のファイル(パイプラインを参照)または Settings → Log metrics で定義します。