運用ランブック

このページでは、EdgeSentry-RS の本番環境デプロイにおけるオブザーバビリティの設定、アラート閾値、バックアップ・リストア手順を説明します。

オブザーバビリティ

tracing を使った構造化ログ

EdgeSentry-RS は tracing ファサードを使用しています。サブスクライバーはバンドルされていません。デプロイ側がアプリケーション起動時に任意のバックエンドを接続します。サブスクライバーが登録されていない場合、ライブラリのオーバーヘッドはゼロです。

本番環境向け推奨サブスクライバー（JSON を stdout に出力し、Loki / CloudWatch に取り込む）：

# ホストアプリケーションの Cargo.toml
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }

use tracing_subscriber::{fmt, EnvFilter};

fn main() {
    fmt()
        .json()
        .with_env_filter(EnvFilter::from_default_env()) // RUST_LOG=edgesentry_rs=info
        .init();
    // ...
}

本番環境では RUST_LOG=edgesentry_rs=info、インシデント調査時は edgesentry_rs=debug を設定してください。

ライブラリが出力する構造化ログイベント

すべてのイベントにはモジュールパスが target として含まれます。主要なイベントの一覧：

推奨 Prometheus メトリクス（ログから導出）

ログ→メトリクスパイプライン（Promtail + Loki、または Vector など）を使い、構造化ログイベントからカウンターを導出します：

OpenTelemetry（トレーシングスパン）

IngestService::ingest メソッドは tracing スパンを出力します。OTLP エクスポーターに接続することで分散トレーシングが利用できます：

opentelemetry = "0.26"
opentelemetry-otlp = { version = "0.26", features = ["grpc-tonic"] }
tracing-opentelemetry = "0.27"

アラート定義

復旧目標

バックアップ手順

PostgreSQL — 監査台帳・操作ログ

前提条件： WAL アーカイブが有効化されていること（archive_mode = on、archive_command で S3 等に転送）。

1. ベースバックアップの取得

pg_basebackup \
  --host=<DB_HOST> \
  --username=<DB_USER> \
  --pgdata=/backup/pg_base_$(date +%Y%m%d_%H%M%S) \
  --format=tar \
  --gzip \
  --wal-method=stream \
  --checkpoint=fast \
  --progress

2. バックアップの検証

pg_restore --list /backup/pg_base_<timestamp>/base.tar.gz | head -20

3. WAL の継続アーカイブ

postgresql.conf の archive_command が WAL セグメントを耐久性のあるストレージ（例：S3）に転送していることを確認します：

archive_command = 'aws s3 cp %p s3://<BUCKET>/wal/%f'

4. 保持ポリシー

S3 / MinIO — ペイロード生データストア

バケットでバージョニングとクロスリージョンレプリケーションを有効化します：

# バージョニングの有効化
aws s3api put-bucket-versioning \
  --bucket <BUCKET> \
  --versioning-configuration Status=Enabled

# レプリケーションの有効化（宛先バケットと IAM ロールを別途設定した上で）
aws s3api put-bucket-replication \
  --bucket <BUCKET> \
  --replication-configuration file://replication.json

最低限のレプリケーション先：別リージョン 1 か所。CLS Level 3 のエビデンス完全性を確保するため、オブジェクトロックまたはバージョニングを有効化し、ペイロードが上書き削除されないようにします。

リストア手順

PostgreSQL — ポイントインタイムリカバリ（PITR）

# 1. Postgres サービスを停止
systemctl stop postgresql

# 2. ベースバックアップを展開
tar -xzf /backup/pg_base_<timestamp>/base.tar.gz -C /var/lib/postgresql/data/

# 3. リカバリ設定を作成
cat > /var/lib/postgresql/data/recovery.conf <<EOF
restore_command = 'aws s3 cp s3://<BUCKET>/wal/%f %p'
recovery_target_time = '<TARGET_TIMESTAMP>'
recovery_target_action = 'promote'
EOF

# 4. Postgres を起動 — 指定時刻まで WAL をリプレイする
systemctl start postgresql

# 5. 確認：デバイスごとの最終受理シーケンスを確認
psql -U <DB_USER> -d <DB_NAME> \
  -c "SELECT device_id, MAX(sequence) FROM audit_records GROUP BY device_id;"

復旧確認チェックリスト

• デバイスごとの最終シーケンスがインシデント前のスナップショットと一致する
• ハッシュチェーンの連続性を確認：eds verify-chain <exported-records.json>
• 操作ログにリカバリ対象時刻前後のギャップがないことを確認する
• 確認完了後、アラート抑制を解除する

S3 / MinIO — オブジェクトのリストア

# 特定バージョンのオブジェクトをリストア
aws s3api get-object \
  --bucket <BUCKET> \
  --key <OBJECT_KEY> \
  --version-id <VERSION_ID> \
  <OUTPUT_FILE>

障害訓練スケジュール

以下の訓練を四半期ごとに実施し、ランブックの正確性を検証します：