監査ログ

Solo Enterprise for agentregistry の監査ログにアクセスして、レジストリリソースに対して誰が特定の操作を実行したかを追跡します。

Solo Enterprise for agentregistry は、レジストリとガバナンスのアクティビティについて構造化された監査証跡を取得します。監査イベントには、誰が操作を実行したか、影響を受けたリソース、操作が成功したかどうか、操作が実行されたタイムスタンプが記録されます。レジストリ管理者は監査ログを使用して、インシデントの調査、コンプライアンスの検証、レジストリ全体のアクセスパターンの把握を行えます。

監査イベントは 4 つのアクティビティタイプに整理され、それぞれ専用の OTel ロガースコープに出力されるため、個別にルーティングして保持できます。設定例については、スコープを別々のバックエンドにルーティングするを参照してください。

アクティビティタイプ	OTel スコープ	取得される内容
`lifecycle`	`audit.resource_activity`	エージェント、MCP サーバー、スキル、プロンプト、アクセスポリシー、ゲートウェイ、Secret など、レジストリリソースの作成、更新、削除。
`approval`	`audit.resource_activity`	送信、承認、取り消し、撤回された承認リクエスト。
`applied_resource`	`audit.resource_activity`	AWS Bedrock AgentCore や Solo Enterprise for kagent など、接続済みランタイムにデプロイされた AI アーティファクト。
`authorization`	`audit.authz`	承認、拒否、失敗したすべての権限チェック。

イベントストリームに含まれるフィールドの詳細については、イベントスキーマを参照してください。

監査ログを有効にする

監査ログはデフォルトで無効です。監査ログを有効にするには、Helm インストールを audit.* フィールドで更新するか、対応する環境変数を設定します。

監査ログを有効にすると、audit.collector.enabled Helm 値を使用して専用の OTel コレクターもデプロイできます。このコレクターは、イベントストリームを書き込み先行ログ (WAL) にバッファリングし、audit.destination.otlp.endpoint Helm 値で定義した独自の OTLP 互換監査プラットフォームへイベントを転送するように設定されます。たとえば、Splunk や Microsoft Sentinel などの SIEM プラットフォーム、または Loki や OpenSearch などのログアグリゲーターを使用できます。監査プラットフォームが利用できなくなった場合、イベントはディスクに蓄積され、プラットフォームが再び利用可能になるとリトライとバックオフ設定に従って再送されます。組み込みのリレーコレクターの使用は任意です。レジストリサーバーから監査プラットフォームへイベントストリームを直接転送することもできます。この場合は audit.collector.enabled=false を設定します。

次の表に、Solo Enterprise for agentregistry で監査ログを有効にするために使用できる Helm 値と対応する環境変数を示します。

Helm 値	環境変数	説明	デフォルト
`audit.enabled`	`AUDIT_ENABLED`	監査ログを有効にします。有効にした場合は、OTLP 互換監査プラットフォームのエンドポイントを `audit.destination.otlp.endpoint` に設定する必要があります。	`false`
`audit.destination.otlp.endpoint`	`AUDIT_OTLP_ENDPOINT`	監査イベントを受信する OTLP/gRPC エンドポイント。例: `audit-collector.namespace.svc.cluster.local:4317`。`audit.enabled=true` の場合は必須です。	—
`audit.destination.otlp.insecure`	`AUDIT_OTLP_INSECURE`	OTLP 接続のトランスポートセキュリティを無効にします。クラスター内の平文通信には `true` に設定します。	`false`
`audit.collector.enabled`	—	バンドルされた OTel コレクターリレーをレジストリサーバーとともにデプロイします。`audit.enabled=true` の場合にのみ設定できます。	`false`
`audit.authz.allowedDecisions`	`AUDIT_AUTHZ_ALLOWED_DECISIONS`	`audit.authz` OTel スコープに出力される成功した認可判断を制御します。拒否とエラーは常に出力されます。次の値をサポートします。 `sensitive` (デフォルト): Secret など、機密リソースの読み取り成功を出力します。拒否とエラーは常に出力されます。 `all`: 成功したすべての権限チェックを含む、すべての認可判断を出力します。 `none`: 成功した認可判断をすべて抑制します。拒否とエラーのみを出力します。	`sensitive`

ローカルテスト

ローカルテストでは、レジストリサーバーから監査イベントを直接受信して stdout に出力する軽量なデバッグコレクターをデプロイします。これにより、SIEM やその他の監査プラットフォームを使用しなくても、kubectl logs コマンドでイベントを確認できます。

Note

使用する既存の監査プラットフォームがある場合は、代わりに本番: バンドルされた OTel コレクターリレーガイドを参照してください。

デバッグ OTel コレクターをデプロイします。このコレクターは、ポート 4317 でレジストリサーバーからの OTLP/gRPC イベントを待ち受け、各イベントを完全な詳細付きで stdout に出力します。永続ストレージはなく、開発とテスト専用です。

kubectl apply -f- <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: audit-debug-collector
  namespace: agentregistry-system
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: "0.0.0.0:4317"
    exporters:
      debug:
        verbosity: detailed
    service:
      pipelines:
        logs:
          receivers: [otlp]
          exporters: [debug]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: audit-debug-collector
  namespace: agentregistry-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: audit-debug-collector
  template:
    metadata:
      labels:
        app: audit-debug-collector
    spec:
      containers:
        - name: collector
          image: otel/opentelemetry-collector-contrib:0.148.0
          args: ["--config=/conf/config.yaml"]
          volumeMounts:
            - name: config
              mountPath: /conf
      volumes:
        - name: config
          configMap:
            name: audit-debug-collector
---
apiVersion: v1
kind: Service
metadata:
  name: audit-debug-collector
  namespace: agentregistry-system
spec:
  selector:
    app: audit-debug-collector
  ports:
    - name: otlp-grpc
      port: 4317
EOF

コレクターが正常にデプロイされたことを確認します。

kubectl get pods -n agentregistry-system | grep debug

出力例:

audit-debug-collector-77c4bf9964-mt6h2                          1/1     Running   0          71s

現在の Helm 値をファイルに保存します。

helm get values agentregistry --namespace agentregistry-system -o yaml > agentregistry-values.yaml
open agentregistry-values.yaml

Helm values ファイルに次の値を追加して監査ログを有効にします。レジストリサーバーは監査イベントを出力し、デバッグコレクターへ直接送信します。バンドルされたリレーコレクターは有効にしない点に注意してください。リレーコレクターを有効にする場合は、本番: バンドルされた OTel コレクターリレーガイドを参照してください。
```
audit:
  enabled: true # Instructs the registry server to emit audit events
  destination:
    otlp:
      endpoint: "audit-debug-collector.agentregistry-system.svc.cluster.local:4317" # Debug collector endpoint
      insecure: true
```

Helm インストールを更新します。

helm upgrade agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --namespace agentregistry-system \
  --version 2026.9.0 \
  -f agentregistry-values.yaml

lifecycle 監査イベントをトリガーする AccessPolicy リソースを作成します。

arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: AccessPolicy
metadata:
  name: audit-test
spec:
  principals:
    - kind: Role
      name: registry-viewer
  rules:
    - actions:
        - "registry:read"
      resources:
        - kind: agent
          name: "*"
EOF

デバッグコレクターのログを確認し、監査イベントが表示されることを確認します。監査ログに含まれる各フィールドの詳細については、イベントスキーマを参照してください。

kubectl logs -n agentregistry-system deploy/audit-debug-collector -f --since=1m

出力例:

2026-07-07T07:19:18.921Z	info	Logs	{"resource": {"service.instance.id": "778040e4-db9c-42b6-a839-47fbec21055e", "service.name": "otelcol-contrib", "service.version": "0.148.0"}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "logs", "resource logs": 1, "log records": 1}
2026-07-07T07:19:18.922Z	info	ResourceLog #0
Resource SchemaURL: 
Resource attributes:
  -> service.name: Str(agentregistry)
  -> service.namespace: Str(agentregistry-system)
ScopeLogs #0
ScopeLogs SchemaURL: 
InstrumentationScope audit.resource_activity 
LogRecord #0
ObservedTimestamp: 2026-07-06 21:31:49.631142674 +0000 UTC
Timestamp: 2026-07-06 21:31:49.631130633 +0000 UTC
SeverityText: 
SeverityNumber: Info(9)
EventName: agentregistry.audit.lifecycle
Body: Empty()
Attributes:
  -> event.name: Str(agentregistry.audit.lifecycle)
  -> event.schema_version: Str(v1)
  -> event.activity: Str(lifecycle)
  -> event.action: Str(create)
  -> actor.subject: Str(b0875cff-fa22-4fac-b3a9-90c81c6ae83c)
  -> actor.type: Str(user)
  -> log.record.uid: Str(0dc4b541-b246-44d3-a684-3db49a4ab78d)
  -> actor.roles: Slice(["admins"])
  -> actor.email: Str(admin-user@example.com)
  -> actor.name: Str(Admin User)
  -> resource.kind: Str(AccessPolicy)
  -> resource.namespace: Str(default)
  -> resource.name: Str(audit-test)
Trace ID: 
Span ID: 
Flags: 0
    {"resource": {"service.instance.id": "778040e4-db9c-42b6-a839-47fbec21055e", "service.name": "otelcol-contrib", "service.version": "0.148.0"}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "logs"}

オプション: AccessPolicy を削除します。
```
arctl delete accesspolicy audit-test
```

本番: バンドルされた OTel コレクターリレー

本番環境では、Solo Enterprise for agentregistry は、レジストリサーバーと SIEM プラットフォームの間に配置される専用のクラスター内 OTel コレクターリレーをデプロイできます。リレーコレクターは、イベントストリームを書き込み先行ログ (WAL) にバッファリングし、audit.destination.otlp.endpoint Helm 値で定義した独自の OTLP 互換監査プラットフォームへイベントを転送するように設定されます。たとえば、Splunk や Microsoft Sentinel などの SIEM プラットフォーム、または Loki や OpenSearch などのログアグリゲーターを使用できます。監査プラットフォームが利用できなくなった場合、イベントはディスクに蓄積され、プラットフォームが再び利用可能になるとリトライとバックオフ設定に従って再送されます。

監査プラットフォームのエンドポイントを取得します。このエンドポイントは、クラスターの Pod ネットワークから到達できる必要があります。

現在の Helm 値をファイルに保存します。

helm get values agentregistry --namespace agentregistry-system -o yaml > agentregistry-values.yaml
open agentregistry-values.yaml

Helm values ファイルに次の値を追加します。事前に取得した監査プラットフォームのエンドポイントを audit.destination.otlp.endpoint フィールドに設定してください。また、レジストリサーバーからイベントストリームを受信し、監査プラットフォームのエンドポイントへ転送するバンドル済みリレーコレクターも有効にします。
```
audit:
  enabled: true # Instructs the registry server to emit audit events
  collector:
    enabled: true  # Deploys the bundled relay collector
  destination:
    otlp:
      endpoint: "<your-siem-or-audit-backend>.<namespace>.svc.cluster.local:4317" # Endpoint to your audit platform
      insecure: true
```

Helm インストールを更新して変更を適用します。

helm upgrade agentregistry \
  oci://us-docker.pkg.dev/solo-public/agentregistry-enterprise/helm/agentregistry-enterprise \
  --namespace agentregistry-system \
  --version 2026.9.0 \
  -f agentregistry-values.yaml

lifecycle 監査イベントをトリガーする AccessPolicy リソースを作成します。

arctl apply -f- <<EOF
apiVersion: ar.dev/v1alpha1
kind: AccessPolicy
metadata:
  name: audit-test
spec:
  principals:
    - kind: Role
      name: registry-viewer
  rules:
    - actions:
        - "registry:read"
      resources:
        - kind: agent
          name: "*"
EOF

監査プラットフォームでイベントを確認し、次のようなライフサイクルイベントが表示されることを確認します。監査ログに含まれる各フィールドの詳細については、イベントスキーマを参照してください。

{
 "severityNumber": 9,
 "severityText": "",
 "body": "",
 "scope": "audit.resource_activity",
 "attributes": {
   "log.record.uid": "01960f2a-8b3c-7d4e-9a1b-2c3d4e5f6a7b",
   "event.name": "agentregistry.audit.lifecycle",
   "event.schema_version": "v1",
   "event.activity": "lifecycle",
   "event.action": "create",
   "actor.subject": "b0875cff-fa22-4fac-b3a9-90c81c6ae83c",
   "actor.type": "user",
   "actor.email": "admin-user@example.com",
   "actor.name": "Admin User",
   "actor.roles": ["admins"],
   "resource.kind": "AccessPolicy",
   "resource.namespace": "default",
   "resource.name": "audit-test"
 }
}

オプション: AccessPolicy を削除します。
```
arctl delete accesspolicy audit-test
```

イベントスキーマ

監査イベントは、OTLP 経由の構造化された OpenTelemetry (OTel) ログレコードとして出力され、2 つの OTel ロガースコープにまたがる 4 つのアクティビティタイプに整理されます。スコープは OTel レベルで分離されているため、必要に応じて設定した別々のコレクターパイプラインにルーティングできます。たとえば、保持期間を変えたり、データを別々の監査バックエンドに転送したりできます。

次の例は、エージェントが作成されたときに出力されるライフサイクルイベントを示しています。

{
  "severityNumber": 9,
  "severityText": "",
  "body": "",
  "scope": "audit.resource_activity",
  "attributes": {
    "log.record.uid": "01960f2a-8b3c-7d4e-9a1b-2c3d4e5f6a7b",
    "event.name": "agentregistry.audit.lifecycle",
    "event.schema_version": "v1",
    "event.activity": "lifecycle",
    "event.action": "create",
    "actor.subject": "b0875cff-fa22-4fac-b3a9-90c81c6ae83c",
    "actor.type": "user",
    "actor.email": "user@example.com",
    "actor.name": "Example User",
    "actor.roles": ["registry-viewer"],
    "resource.kind": "Agent",
    "resource.namespace": "default",
    "resource.name": "summarizer",
    "resource.tag": "v1"
  }
}

Caution

監査イベントには、actor.subject、actor.email、actor.name、actor.roles、approval.submitter など、アクター ID フィールドが含まれます。これらのフィールドには、個人情報や機密情報が含まれる場合があります。Solo Enterprise for agentregistry は、Secret 値、発行済みトークン、認証情報、完全なリソースペイロードを監査イベントに含めることはありません。下流での保持、アクセス制御、データ分類は、監査プラットフォームまたは SIEM プラットフォームの責任です。

次の表では、すべてのイベントフィールドと指定可能な値について説明します。optional と示されたフィールドは、該当しない場合は省略されます。

フィールド	説明	指定可能な値
`severityNumber` / `severityText`	OTel ログの重大度。重大度は数値コード (`severityNumber`) として保持されます。`severityText` フィールドはワイヤ形式では空です。	`9` (`INFO`): 操作が正常に完了しました。 `13` (`WARN`): 操作が拒否されたか、ビジネス上の失敗になりました。 `17` (`ERROR`): 内部エラーが発生したか、ポリシー評価操作が失敗しました。
`body`	OTel ログ本文。自由形式の失敗詳細が含まれます。成功時、このフィールドは空です。	string
`scope`	OTel ロガースコープ。スコープには発生したイベントのタイプが含まれます。	`audit.resource_activity`: `lifecycle`、`approval`、`applied_resource` イベントを含みます。 `audit.authz`: `authorization` イベントを含みます。
`log.record.uid`	下流での重複排除に使用する一意のログレコード ID。	string
`event.name`	発生したイベントの名前。スキーマはイベント名に `agentregistry.audit` プレフィックスを使用し、Splunk、Microsoft Sentinel、IBM QRadar などの Security Information and Event Management (SIEM) プラットフォームで扱いやすいように設計されています。これらのプラットフォームは、OTel ログレコードを直接取り込み、カスタム解析ルールなしでクエリやアラートを実行できます。イベントの詳細については、`event.activity` フィールドと `event.action` フィールドを参照してください。	`agentregistry.audit.lifecycle`: ライフサイクルイベント。 `agentregistry.audit.approval`: 承認イベント。 `agentregistry.audit.authorization`: 認可イベント。 `agentregistry.audit.applied_resource`: デプロイ済みリソースイベント。
`event.schema_version`	スキーマバージョン。	`v1` (現在のスキーマバージョン)
`event.activity`	アクティビティのタイプ。このフィールドにより、OTel `scope` とイベントに存在する追加フィールドが決まります。イベント中に実行された操作の詳細については、`event.action` フィールドを参照してください。	`lifecycle`: エージェント、MCP サーバー、スキル、プロンプト、アクセスポリシー、ゲートウェイ、Secret など、レジストリリソースの作成、更新、削除。 `approval`: 送信、承認、取り消し、撤回された承認リクエスト。 `authorization`: 承認、拒否、失敗したすべての権限チェック。 `applied_resource`: AWS Bedrock AgentCore や Solo Enterprise for kagent など、接続済みランタイムにデプロイされた AI アーティファクト。
`event.action`	実行された操作。	`create`: 新しいリソースが作成されました。 `update`: 既存のリソースが更新されました。 `delete`: リソースが削除されました。 `read`: 機密リソースが読み取られました。 `submit`: 承認リクエストが送信されました。 `approve`: 承認リクエストが承認されました。 `revoke`: 承認判断が取り消されました。 `withdraw`: 承認リクエストが送信者によって撤回されました。 `deploy`: デプロイが開始されました。 `apply`: 最終的な作成または更新の結果が不明なライフサイクルイベントが発生しました。 `materialize`: 下流リソースが接続済みランタイムに適用されました。 `admin`: 特権的な管理操作が実行されました。 `invoke`: リソースが呼び出されました。
`actor.subject`	安定したアクター ID。	OIDC `sub` クレーム: 認証済みユーザーの JWT トークンに含まれる subject クレーム。 `anonymous`: リクエストに認証情報が含まれていませんでした。 `system`: ユーザー認証をバイパスするバックグラウンド同期タスクなど、信頼済みの内部レジストリプロセスによってリクエストが行われました。
`actor.type`	操作を実行したアクターのタイプ。このタイプは `actor.subject` フィールドとは別に記録されるため、JWT の `sub` クレームが `system` に設定されたユーザーによって実行された操作も、システムアクティビティではなくユーザー操作として分類されます。	`user`: 認証済みユーザー。 `anonymous`: 未認証リクエスト。 `system`: 内部レジストリプロセス。
`actor.roles`	Optional. OIDC セッションからマッピングされた RBAC ロール。	string array
`actor.email`	Optional. OIDC セッションの email クレーム。	string
`actor.name`	Optional. OIDC セッションの名前または preferred username。	string
`resource.kind`	イベントに関与したレジストリリソースの kind。	`Agent`: エージェントリソース。 `MCPServer`: MCP サーバーリソース。 `Skill`: スキルリソース。 `Prompt`: プロンプトリソース。 `Runtime`: ランタイムリソース。 `Deployment`: デプロイリソース。 `AccessPolicy`: アクセスポリシーリソース。 `Gateway`: ゲートウェイリソース。 `Secret`: Secret リソース。
`resource.namespace`	リソースネームスペース。レジストリカタログ内のリソースの論理グループを表します。	string
`resource.name`	リソース名。	string
`resource.tag`	Optional. バージョンやデプロイ済み環境など、参照リソースのリソースタグ。	string
`resource.uid`	Optional. 既知の場合の外部識別子。	string
`event.correlation_id`	Optional. 1 回のデプロイ中に適用されたすべてのリソースなど、論理的な原因を共有する関連イベントをグループ化します。	string
`event.dry_run`	Optional. リクエストが変更をコミットせずにシミュレートした場合にのみ存在します。	`true`: リクエストはドライランを表します。
`error.type`	Optional. 成功以外のイベントの安定した分類子。成功時は省略されます。	`denied`: 認可リクエストが拒否されました。 `internal_error`: 内部エラーまたはポリシー評価エラーが発生しました。 `_OTHER`: 分類できない成功以外のイベントが発生しました。
`approval.id`	Optional. `approval` events only. タグが存在する場合はそれを含む承認 ID。	string
`approval.state`	Optional. `approval` events only. 現在の承認状態。	`pending` — リクエストが送信され、判断待ちです。 `approved` — リクエストが承認されました。 `revoked` — 承認済み判断が取り消されました。 `withdrawn` — リクエストが送信者によって撤回されました。
`approval.submitter`	Optional. `approval` events only. 承認リクエストを最初に送信した subject。	string
`authz.reason`	Optional. `authorization` events only. 認可結果の理由。	`permission_match`: リクエストがアクセスポリシー内のルールに一致しました。 `registry_admin`: アクターが registry-admin ロールを保持しています。 `system_session`: 信頼済みの内部システムセッションによってリクエストが行われました。 `no_matching_permission`: リクエストされた操作に一致するアクセスポリシールールがありませんでした。 `unauthenticated`: リクエストに認証情報が含まれていませんでした。 `empty_action_or_resource`: リクエストに操作またはリソース識別子がありませんでした。
`target_resource.runtime`	Optional. `applied_resource` events only. レジストリリソースをデプロイしたランタイムのタイプ。	`Kagent`: Solo Enterprise for kagent。 `BedrockAgentCore`: AWS Bedrock AgentCore。 `Virtual`: MCP ゲートウェイランタイム。
`target_resource.api_group`	Optional. `applied_resource` events only. 下流リソースが Kubernetes オブジェクトの場合の Kubernetes API グループ。	string
`target_resource.kind`	Optional. `applied_resource` events only. ランタイムにデプロイされた下流リソースの kind。	`Agent`: Agent リソース。 `MCPServer`: MCPServer リソース。 `AgentRuntime`: AgentRuntime リソース。 `EnterpriseAgentgatewayBackend`: agentgateway バックエンドリソース。 `HTTPRoute`: Kubernetes HTTPRoute リソース。
`target_resource.namespace`	Optional. `applied_resource` events only. 下流リソースのネームスペース。	string
`target_resource.name`	Optional. `applied_resource` events only. 下流リソースの名前。	string
`target_resource.uid`	Optional. `applied_resource` events only. 下流リソースの外部 UID、ARN、またはプロバイダー ID。	string

その他の設定

スコープを別々のバックエンドにルーティングする

audit.resource_activity と audit.authz は別々の OTel instrumentation scope であるため、異なるバックエンドにルーティングできます。たとえば、ライフサイクルイベントを 1 つの監査プラットフォームに送信し、認可判断をより長い保持ポリシーを持つ別のログアグリゲーターに送信できます。

同じ otlp レシーバーを共有する 2 つのパイプラインを持つカスタム OTel Collector をデプロイします。各パイプラインは filter プロセッサーを使用して、そのスコープに属さないレコードをドロップし、独自の宛先へエクスポートします。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"

processors:
  filter/resource_activity:
    error_mode: ignore
    logs:
      log_record:
        - 'instrumentation_scope.name != "audit.resource_activity"'
  filter/authz:
    error_mode: ignore
    logs:
      log_record:
        - 'instrumentation_scope.name != "audit.authz"'

exporters:
  otlp/siem:
    endpoint: "siem.namespace.svc.cluster.local:4317"
  otlp/log_aggregator:
    endpoint: "loki.namespace.svc.cluster.local:4317"

service:
  pipelines:
    logs/resource_activity:
      receivers: [otlp]
      processors: [filter/resource_activity]
      exporters: [otlp/siem]
    logs/authz:
      receivers: [otlp]
      processors: [filter/authz]
      exporters: [otlp/log_aggregator]

レジストリサーバーまたはリレーコレクターがイベントストリームをこのコレクターに転送するように、コレクターのエンドポイントを audit.destination.otlp.endpoint Helm フィールドに追加してください。コレクターは、受信したレコードを両方の監査パイプラインへ自動的にファンアウトします。

イベントを複数の宛先に転送する

アラート用の SIEM プラットフォームと長期保持用のログアーカイブなど、すべての監査イベントを同時に複数のバックエンドへ送信するには、次の OTel 設定のように同じパイプライン内に複数のエクスポーターを列挙します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"

exporters:
  otlp/siem:
    endpoint: "siem.namespace.svc.cluster.local:4317"
  otlp/archive:
    endpoint: "loki.namespace.svc.cluster.local:4317"

service:
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlp/siem, otlp/archive]

コレクターは各レコードをリスト内のすべてのエクスポーターに書き込みます。1 つの宛先が低速または利用不能でも、もう一方への配信はブロックされません。

イベントにクラスターメタデータを付加する

複数のクラスターから監査ログを単一の SIEM に集約する場合は、cluster.name や environment などのリソース属性をすべてのイベントに追加して、クエリ内で区別できるようにします。転送前に resource プロセッサーを使用して属性を付与します。

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"

processors:
  resource:
    attributes:
      - key: cluster.name
        value: "prod-us-east-1"
        action: upsert
      - key: environment
        value: "production"
        action: upsert

exporters:
  otlp/siem:
    endpoint: "siem.namespace.svc.cluster.local:4317"

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [resource]
      exporters: [otlp/siem]

upsert アクションは、属性が存在しない場合は追加し、すでに存在する場合は上書きします。デプロイする前に、クラスターと環境に合わせて値を設定してください。