本文へ移動
runlot
ObservabilityMetrics

Metrics

組み込みのリクエスト、メモリ、インフラ、データベースのメトリクス、env.metrics によるカスタムメトリクス、そしてログから生成するメトリクスです。

組み込みメトリクス

すべてのプロジェクトで、何も有効にせずに収集されます。

セクションメトリクス
Overviewリクエスト数、エラー、ステータスクラス、経過時間の p50/p95/p99。デプロイと OOM のマーカー付き
Infrastructure上限に対するメモリ使用量、CPU 使用量とスロットリング、CPU・メモリ・I/O のプレッシャーストール(PSI)、I/O バイト数、原因別のプロセスの起動と終了、ウェイクのレイテンシを含むパークとウェイク、クラスごとの Durable Objects
Databaseenv.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 % にサンプリングされていても正確なままです。

.runlot/logs.json
{
  "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 で定義します。

このページの目次