Settings

ここにある設定はすべて Observability → Settings にあり、それぞれに /v1/orgs/{org}/projects/{project}/observability/ の下の API ルートがあります。

サンプリング

リクエスト記録は常に保管されます。サンプリングが決めるのは、呼び出しの内容(コンソール出力と例外(logs)、そしてスパン(traces))を収集するかどうかです。これらを作るにはリクエストごとにワーカーの CPU を消費するため、どちらも既定ではオフです。

{
  "observability": {
    "logs": { "enabled": true, "head_sampling_rate": 0.25, "invocation_logs": true },
    "traces": { "enabled": true, "head_sampling_rate": 0.05 }
  }
}

判定はリクエストごとに、到着時に 1 回だけ行います。そのため、サンプリングされたリクエストにはすべての行とスパンがあり、サンプリングされなかったリクエストには何もありません。ワーカーが stdout と stderr に出力した内容は、これとは関係なく保存されます。

ダッシュボードでは、デプロイせずに 4 つのいずれも上書きできます。空のままにしたフィールドは、公開中のデプロイの runlot.json の値になります。

curl -X PUT https://api.runlot.io/v1/orgs/my-org/projects/my-app/observability/sampling \
  -H "Authorization: Bearer $RUNLOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"logsEnabled": true, "logSampleRate": 0.1, "tracesEnabled": null, "traceSampleRate": null}'

リクエストには、次のルーティングマップの更新時に変更が反映されます。通常は数秒以内、遅くとも約 30 秒後です。cron、キュー、メール、Durable Object のアラームによる呼び出しには、次にアプリが起動したときに反映されます。設定には admin ロールが必要です。

上限とコスト

計測されるすべてのシグナルは、1 つのルールに従います。

• 上限は既定でオンで、プランの込みの量に設定されています。
• Pro プランでは、プロジェクトごとに上限を引き上げるか解除できます。込みの量を超えた使用分は課金され、変更の前後に、現在のペースでの当月の予測コストがページに表示されます。
• Free プランは込みの量で固定です。どのプランでも上限を下げることはできます。
• 組織の支出上限は、すべての上限より上位にあります。支出上限に達すると収集が止まりますが、アプリが止まることはありません。
• 上限に達すると収集が縮退しますが、それが起きたという記録は失われません。件数は常に保持されます。

プラットフォームのエラーイベント(Runlot がアプリの代わりに応答しなければならなかったときに記録するもの)に上限はありません。

curl -X PUT https://api.runlot.io/v1/orgs/my-org/projects/my-app/observability/caps \
  -H "Authorization: Bearer $RUNLOT_TOKEN" -H "Content-Type: application/json" \
  -d '{"logEventsDaily": 10000000, "customSeries": -1}'

logEventsDaily、customSeries、rumSessions はそれぞれ、数値、上限なしを表す -1、またはプランの込みの量を表す null を受け取ります。指定しなかったメーターは変わりません。エラーとスパンの上限は runlot errors settings(--cap、--span-cap)にあります。上限の変更には admin ロールと observability:admin が必要です。

パイプラインと機密データスキャナー

ログイベントは取り込み時に、保存とエクスポートの前に、パイプラインとスキャナーを通ります。どちらも .runlot/logs.json で管理し、runlot deploy がデプロイとともに送ります。

{
  "pipeline": [
    { "type": "json_parse" },
    { "type": "regex", "pattern": "took (?P<took_ms>\\d+)ms" },
    { "type": "rename", "from": "uid", "to": "userId" },
    { "type": "level", "field": "severity", "mapping": { "W": "warn", "E": "error" } },
    { "type": "drop", "filter": [{ "key": "$message", "op": "starts_with", "value": "healthcheck" }] }
  ],
  "scanner": {
    "builtins": { "email": "hash", "card": "redact", "jwt": "redact" },
    "rules": [{ "name": "order-token", "pattern": "ot_[A-Za-z0-9]{24}", "action": "redact" }]
  },
  "logMetrics": []
}

• プロセッサーは順に実行されます。json_parse、kv、regex(名前付きグループ付きの RE2)、rename、level、url、user_agent、drop、sample です。最大 32 個です。パイプラインがない場合は json_parse だけが実行されます。
• 組み込みのスキャナールール: jwt、bearer、api_key、email、card(Luhn で確認)、kr_rrn(チェックサムを満たす韓国の住民登録番号)。それぞれ redact、hash、drop、off のいずれかで、指定しなかったルールは redact になります。ご自身の RE2 ルールを最大 50 件追加できます。同じスキャナーがエラーイベントにも適用されます。
• パイプラインまたはスキャナーが捨てたイベントは、1 日の上限に数えられません。
• logMetrics はログからのメトリクスです。
• ファイルは最大 64 KiB です。そのデプロイが公開されるときに適用されます。ダッシュボードで行った編集は、このファイルを含む次のデプロイまで有効です。ダッシュボードの Export で、現在の設定をこの形式で取得できます。
• 保存する前に、サンプル文字列に対してスキャナーをテストしてください。テストでは何も保存されません。

エクスポート

ログ、トレース、メトリクスをご自身のツールへ送ります。Pro プランで、プロジェクトあたり最大 5 件の送信先を設定できます。

• OTLP: 公開アドレスのポート 443 または 4318 にある HTTPS のコレクターへ OTLP/HTTP JSON を送ります。ヘッダーを任意に指定できます(暗号化して保存され、再表示されるのは名前だけです)。シグナルは logs、traces、metrics です。persist: false にすると、ログとトレースは Runlot に保存されずにエクスポートされます。
• Logpush: logs と invocations を、1 時間ごとに gzip 圧縮した NDJSON オブジェクトとして <prefix>/yyyy/mm/dd/hh/<signal>-<n>.ndjson.gz に書き込みます。書き込み先は、指定した S3 互換のバケット、またはプロジェクト自身の env.storage バケットです。

各送信先には、配信の状態と最後の失敗が表示されます。遅い送信先や失敗している送信先はバックオフ付きで再試行され、アプリを止めることはありません。

リハイドレーション

プランの保管期間より古いログは、Logpush のアーカイブからクエリ用に戻せます。Logpush の送信先と最大 72 時間の期間を選ぶと、保管期間より古い部分が読み込まれ、7 日間同じクエリに応答します。リハイドレーションした行は再びエクスポートされることはなく、メトリクスのグラフも変わりません。Pro プランの機能です。

テールコンシューマー

テールコンシューマーは、Cloudflare の tail_consumers と同じく、各呼び出しのトレースをランタイムから受け取る、ご自身のワーカーのエクスポートです。

{ "main": "src/index.ts", "tail_consumers": [{ "entrypoint": "AuditTail" }] }

import { WorkerEntrypoint } from "cloudflare:workers";

export class AuditTail extends WorkerEntrypoint {
  async tail(events) {
    for (const e of events) if (e.outcome !== "ok") console.log({ audit: e.outcome });
  }
}

export default { fetch: () => new Response("ok") };

エントリーポイントはメインモジュールのエクスポートでなければならず、Durable Object のクラスや runlot で始まる名前は使えません。読むかどうかにかかわらず、すべての呼び出しがそのためにトレースを作るため、CPU を消費します。Free プランは 1 件、Pro プランは 5 件まで使えます。

プロファイラーとヒープスナップショット

継続的プロファイラーは、およそ 10 分ごとに 10 秒間アプリの CPU プロファイルをサンプリングし、デプロイのソースマップでシンボル化して、バージョンごとのフレームグラフ、自己時間の長い上位の関数、2 つのバージョンの比較を表示します。プロファイルは、同じ分の遅いトレースからリンクされます。

この機能は Pro プラン専用で、既定ではオフです。有効にすると、次のデプロイまたは再起動から反映されます。プロファイラーを接続するためにアプリを再起動することはありません。プロファイルした時間は 1 時間あたり $0.03 で課金されます。

プロファイラーが有効な場合、管理者は実行中のアプリのヒープスナップショットを取得できます。取得中はアプリが一時停止し、スナップショットには秘密情報を含め、アプリがメモリに持つすべてが含まれます。そのため、管理者のみが取得でき、監査の対象となり、同時に 1 つ、10 分に最大 1 回までで、7 日後に期限切れになります。

ロールと監査

プロジェクトのオブザーバビリティのデータは、3 つの権限で管理されます。

組織の viewer と member には read が付き、admin には 3 つすべてが付きます。管理者は、1 つのプロジェクトで 1 人について権限を広げたり狭めたりできます。pii と admin には read も必要で、自分自身の admin を外すことはできません。個人アクセストークンは作成時のスコープだけを持つため、トークンを使うと権限はさらに狭まります。

監査ログは、すべての設定変更(上限、エクスポート、リハイドレーション、ロールの上書き、パイプライン、スキャナー、モニター)と、PII スコープのデータの読み取りをすべて記録します。バグレポートを送った場合、Runlot のスタッフによるその読み取りもここに表示されます。監査ログを読むには observability:admin が必要です。

Data には、プロジェクトのオブザーバビリティのデータが保管されている場所と、エクスポート先が表示されます。