Event Hubs × New Relic / サードパーティSIEM 連携設計メモ
- 山崎行政書士事務所
- 2025年9月11日
- 読了時間: 3分

1) 典型アーキ(ざっくり像)
送信元(App/AKS/IoT/Firewall/Platform Logs) → Event Hubs(ingest & バッファ) → 連携レイヤ → New Relic/SIEM
連携レイヤの実装候補:
Logstash / Fluent Bit(Event Hubs Kafka互換 or EH SDK)
Azure Functions / Container Apps(EHトリガーで加工→HTTP/HTTPS転送)
New Relic Ingest もしくは SIEMベンダーの専用コネクタ(Splunk HEC / QRadar、等)
2) 連携“パターン”早見表
P1. ダイレクト・プッシュ(軽量〜中規模)
EH Consumer → 変換 → New Relic Logs API / SIEM HTTP Collectorへ直接POST
長所:シンプル、レイテンシ小
注意:スロットリングと再送/重複排除の実装必須
P2. ログ収集基盤経由(拡張性重視)
EH → Logstash / Fluent Bit → New Relic / SIEM
長所:プラグイン豊富、フォーマット変換/正規化が楽、スケールアウト容易
注意:運用(プラグイン/バージョン管理)の手間
P3. 閉域・厳密統制(規制強め)
Private Link/EH Firewallで閉域化
EH → Azure Functions(VNET統合) → Private Egress → SIEM
長所:通信経路を厳密に制御
注意:ネットワーク設計と証明書/秘密管理が増える
P4. フェイルセーフ併用
EH Capture(ADLS/Blobに生イベントを自動保管)+ P1/P2/P3のどれか
長所:下流停止時もロスレス、後追い再処理OK
注意:ストレージ管理/ライフサイクル設定
3) スキーマと正規化の“型”
統一Envelopeを決める:
{ "ts":"2025-09-11T01:23:45Z", "source":"aks-app-a", "env":"prd", "region":"japaneast", "event_type":"app_log|audit|fw|sys", "severity":"INFO|WARN|ERROR", "msg":"…", "labels":{"team":"x","service":"y"}, "trace":{"trace_id":"…","span_id":"…"}, "kv":{ "user":"…", "ip":"…", "path":"…" } }
時刻/環境/リージョン/サービス名は必須タグ化(NR/SIEMでのパーティショニング・保存ポリシー・検索効率向上)
セキュリティ系(Firewall/EDR/WAf)ログはMITRE/CEF/LEEF等のマッピング表を用意して“どのフィールドに何を入れるか”を固定
4) Event Hubs 設計の勘所(取り込み側)
パーティション数:ピークTPS×処理併行度で見積(将来増も考慮。増やすとコンシューマ再均衡が発生)
スループット/TU or CU:ピーク+20〜30%のヘッドルーム
保持期間:リトライ窓+障害復旧時間に合わせて設計(典型:1〜7日)
チェックポイント:Blob Storageでコンシューマのオフセット管理(重複・欠落防止)
Capture:必須級(ロスレス&再処理用の真実ソース)
5) セキュリティ/ネットワーク
認証は**Entra ID(RBAC)**優先、SASは短期キー+Key Vaultでローテ
Private Link+EH IP Firewallで到達元/先を限定
送信先(New Relic/SIEM)もPrivate egress(Private Link/Private NAT/専用線)を検討
PII/秘匿データはデータ分類→マスキング/トークナイズを連携レイヤで実装
監査ログ(成功/失敗の転送件数、再送回数、ドロップ件数)を別ストリームで記録
6) 可用性・DR
Geo-DR(Namespaceペア)でテールオーバ計画
下流停止時はDLQ(擬似)=Capture格納+再生ジョブ(Functions/Container Apps/Databricks)
Idempotency:イベントIDで重複取り込み防止(ハッシュ/デデュープ)
7) 運用監視(SLO/SLIサンプル)
SLO例:
取り込み→送信先到達 P95 < 60秒
ロスト率 0.01%未満(Captureで後追い補填)
SLI:EHのIncoming/Outgoing、Server Errors、Consumer Lag、下流のIngest成功率
アラート:Lag急増、失敗率上昇、スロットリング、リトライ上限到達、Capture未実行
8) コスト最適化のコツ
バッチ/圧縮でAPIコール回数を削減(HTTP送信コスト最適化)
TU/CUの自動スケール(上限は固めに、下限は控えめに)
サンプリングや低価値ログのTTL短縮(SIEM側の保存期間コスト対策)
Marketplace経由のエージェント/コネクタはMACC対象か事前確認
9) 最小構成の“リファレンス”
Ingest:Event Hubs(Partition=4〜8、保持3日、Capture ON)
Bridge:Container Apps(EHトリガー→JSON正規化→NR/SIEM API、バッチ送信、再送ロジック)
Security:Private Link、Managed Identity、Key Vault、SAS短期
Ops:Diag Settings→Log Analytics、SLOダッシュボード、アラート
10) 失敗しがちなポイント(事前チェック)
Retention短すぎ(再処理できない)
チェックポイント未実装(重複/欠落)
スキーマ未固定(可視化・相関が崩壊)
ネットワーク閉域の穴(Outboundだけ公開)
監査証跡が“人手運用”(自動ダッシュボード化を)




コメント