OpenTelemetry（OTel）Collector を入れると、アプリのテレメトリは整います。一方で、Collector 自体が詰まったり落ちたりすると「観測できているつもりで、実は欠損していた」という状態になりがちです。この記事では、スクレイパー（クローラー）だけを監視するのではなく、OTel のパイプライン（receiver→processor→exporter）を健全に保つための監視ポイントと、実装の具体例（設定例・メトリクス・アラート設計）を整理します。 スクレイピング基盤でありがちなのが「スクレイパーの稼働監視はしているが、観測基盤は監視していない」状態です。ところが実務では、障害はスクレイパー以外でも起きます。たとえば以下です。 押さえたい前提：OTel Collector は「受信」「加工」「転送」のパイプラインです。したがって健全性も、CPU/メモリのようなプロセス監視だけでは足りず、データフローの監視が必要になります。 「パイプラインが健全」と言うと曖昧です。監視設計では、少なくとも次の3つに分けると事故が減ります。 Collector プロセスが生きていて、受信エンドポイントが応答している状態です。Kubernetes の readiness/liveness、HTTP のヘルスエンドポイントが該当します。 receiver が想定通りに受信し、processor へ流れている状態です。証拠は「受信件数」「拒否/エラー」「キュー増加」です。 exporter がバックエンドへ送れている状態です。証拠は「送信成功」「送信失敗」「再試行」「ドロップ」「キュー滞留」です。 注意：ヘルスチェックが OK でも、exporter 先が詰まってキューが増え続けていることがあります。生存監視だけで「観測基盤は健康」と判断すると、欠損に気づけません。 Collector には、運用を助ける extension が用意されています。公式ドキュメントでも、extensions に health_check/pprof/zpages を追加する例が示されています。opentelemetry.io ロードバランサや Kubernetes の probe から叩くためのエンドポイントです。「生存」を見る用途で使います。 Collector 内部のライブ状態を覗くための UI です。公式トラブルシューティングでも、receiver/exporter のライブデータ確認に使える旨が案内されています。opentelemetry.io CPU/メモリのプロファイルを取る用途です。データ詰まりの根因が「高負荷」なのか「設定」なのかを切り分ける際に効きます。 OTel Collector は、自身のメトリクス（self-metrics）も出せます。これを Prometheus などで収集し、ダッシュボードとアラートに落とすのが王道です。ここからが本題です。 具体的なメトリクス名はディストリビューションやバージョンで差が出ることがあります。とはいえ「何を監視するか」は普遍です。最低限、次の観点を揃えてください。 運用上のコツ：まず「入口（受信）と出口（送信）の差分」を可視化します。差分が増え続けるなら、どこかで滞留・再試行・ドロップが発生しています。 Collector の事故で多いのが OOM（メモリ不足）です。そこで 以下は「ヘルス」「内部可視化」「自己メトリクス収集」を最小構成で揃える例です。実際の exporter（Prometheus/OTLP/ベンダー）や認証は環境に合わせて調整してください。監視対象はスクレイパーだけじゃない：OpenTelemetryパイプライン健全性の監視
なぜ監視が必要か
健全性の定義
1) 生存
2) 受信できている
3) 転送できている
まず入れる拡張
health_check
zPages
pprof
Collector自己監視
見るべき指標
メモリ事故の防止
memory_limiter processor を入れて、閾値超過時に制御します。公式の Go パッケージドキュメントには「メモリリミッタが拒否する前に追加メモリを消費し得る」という警告が明記されています。つまり、入れて終わりではなく、適切な余裕を持って設計が必要です。pkg.go.dev設定例
extensions:
health_check: {}
pprof: {}
zpages: {}
receivers:
otlp:
protocols:
grpc: {}
http: {}
processors:
memory_limiter:
# 値は環境に合わせて調整
check_interval: 1s
limit_mib: 512
spike_limit_mib: 128
batch: {}
exporters:
debug: {}
service:
extensions: [health_check, pprof, zpages]
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [debug]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [debug]
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [debug]
extensions を service.extensions に紐付ける点が重要です。Collector の設定の全体像（pipelines/receivers/processors/exporters/extensions）は公式ドキュメントでも説明されています。opentelemetry.io
よくある異常パターン
受信は増えるが送信が増えない
exporter 先の障害、認証切れ、DNS/ネットワーク断、レート制限が典型です。再試行やキュー長の増加を合わせて見ます。
ドロップが増える
メモリ制限、キュー飽和、exporter の恒久エラーなどが原因になり得ます。欠損が確定するので最優先で検知します。
遅延が増える
batch の設定、サンプリング、exporter のバックプレッシャーなどが関係します。SLO を持つなら「遅延」も監視対象です。
Collectorが落ちる
OOM のほか、設定不備や証明書不足で「受信ができていないように見える」ことがあります。distroless などでツールが入っていないと切り分けが難しいため、health_check/zPages の露出は運用上の保険になります（現場知見として有用です）。reddit.com
注意：Reddit の内容は経験談です。判断の補助としては有効ですが、最終的には自環境のメトリクスと公式ドキュメントで裏取りしてください。
アラート設計
アラートは「落ちたら鳴らす」だけだと遅すぎます。データフローの劣化を早期に拾う条件を用意しましょう。
おすすめ条件
- ドロップ：5分間で drop が 0 以外になったら即通知
- 受信-送信差分：差分が継続的に増える（10〜15分）なら通知
- exporter 失敗率：一定割合（例 1% 超）が継続したら通知
- メモリ逼迫：limit 近傍に張り付く、または GC 圧が継続するなら通知
通知先の分離
「すぐ直す（オンコール）」と「翌営業日対応（改善）」を分けると運用が回ります。ドロップや collector down は前者、遅延増やキュー増は後者に寄せるのが現実的です。
比較：監視手段
パイプライン監視に使う代表的な手段を、目的別に整理します。
| 手段 | 主な目的 | 強み | 弱み |
|---|---|---|---|
| health_check | 生存確認 | 軽量でLB/Probe向き | データ欠損は見えない |
| zPages | 即時デバッグ | ライブ状態を目視できる | 常時監視には不向き |
| self-metrics | 継続監視 | アラート/可視化の中核 | 設計と整備が必要 |
| pprof | 根因分析 | CPU/メモリの原因追跡 | 運用者のスキルが必要 |
運用の落とし穴
「Collectorは安定」の思い込み
Collector は Go 製で堅牢ですが、入力が増えたり export 先が詰まれば当然不安定化します。特にスクレイピングはピークが尖りやすいので、メモリ保護（memory_limiter）とバッチングの前提で設計したいところです。pkg.go.dev
監視が分断される
アプリは APM、Collector は別監視、バックエンドは別…となると、障害時のトリアージが遅れます。「入口→Collector→出口」の一連を同じダッシュボードに載せると、切り分けが高速化します。
参考リンク
設定・デバッグ・メモリ保護は、まず公式情報を起点に確認してください。
監視設計を改善しませんか？
スクレイピング基盤の観測欠損は、Collector・exporter・バックエンドまで含めた監視設計で大きく減らせます。現状の構成を前提に、指標設計とアラートの最適化をご相談ください。
まとめ
- OTel の健全性は「生存」だけでなく「受信できている」「転送できている」で定義する
- health_check/zPages/pprof に加え、self-metrics を中核にして継続監視を組む
- ドロップ、受信-送信差分、失敗率、キュー滞留を先回りでアラート化する
