この記事では、Tealiumシステムログを外部の監視、保存、およびアラートプラットフォームにルーティングするためのログストリーミングの使用方法について説明します。
概要
ログストリーミングは、Tealiumのログを既存の監視、保存、およびアラートプラットフォームにルーティングし、既に使用しているツールでシステムの動作を監視できます。
ログストリーミングを使用して:
- 中央の場所でコネクタの信頼性を監視します。
- 詳細なログレコードで障害を調査します。
- 目的地プラットフォームでダッシュボードとアラートを構築します。
- 保持またはコンプライアンスのニーズのために自分のシステムにログを保存します。
要件
サーバーサイド構成でログストリーミングが有効になっています。詳細については、ログストリーミングを有効にするを参照してください。
動作原理
ログストリーミングは、主に以下の2つのコンポーネントを使用します:
宛先
宛先はログエントリが送信される場所を定義します。各宛先はコネクタによってバックアップされ、専用のログストリーミングアクションを使用してログデータを外部システムに配信します。
ログストリーミング宛先はログストリーミングUIで構成され、標準コネクタ画面で構成されたコネクタとは別です。
例としては、DatadogやNew Relicのような監視プラットフォーム、Amazon S3のような保存システム、Confluent Kafkaのようなストリーミングプラットフォームがあります。さらに多くの例については、#available-destination-connectorsを参照してください。
ログソース
ログソースは、どのログが収集され、配信前にどのようにグループ化されるかを定義します。各ログソースはログタイプを指定し、どのコネクタまたはアクションが監視されるかを制御します。ログソースインスタンスは単一の宛先に紐づけられています。同じログを複数の宛先に送信するには、別々のログソースインスタンスを作成します。
ログソースがログエントリを生成すると、次のプロセスが発生します:
- ログソースがイベントをキャプチャします。
- ログソースは、コネクタタイプ、HTTPレスポンスステータス、エラーコード、実行時間などのフィールドを含む構造化されたレコードを組み立てます。
- レコードは関連する宛先に転送されます。
- 宛先コネクタはログエントリを外部プラットフォームに配信します。
- 外部プラットフォームはログを監視、分析、アラート、または長期保持のために取り込みます。
たとえば、優先度の高いキャンペーンのコネクタエラーを監視し、それらのログをDatadogに送信して、チームが障害を確認し、エラー数が増加したときにアラートをトリガーすることができます。
ログストリーミングはコネクタを通じてログを配信し、Tealium内でログを保存または分析しません。
利点
- コネクタエラーに関する外部からの可視性
コネクタエラー情報はデフォルトでTealium UI内でのみ利用可能です。ログストリーミングはそれらのエラーを監視スタックにルーティングするため、Tealiumにログインせずにチームがそれらを監視できます。 - プログラムによる分析のための構造化データ
各ログレコードには、HTTPステータスコード、エラータイプ、実行時間などのフィールドが含まれています。これらのフィールドを使用してエラーを分類し、ノイズをフィルタリングし、目的地プラットフォームでターゲットを絞ったアラートを構築します。 - 相関監視
インフラの残りの部分を監視している同じプラットフォームにコネクタエラーを送信し、Tealiumの障害をより広範なシステムイベントと相関させます。 - 長期的なエラー履歴
Tealiumは歴史的なエラーデータを保持しません。ログを自分のシステムに保存することで、監査、コンプライアンス、またはトレンド分析のための永続的な記録を提供します。 - 選択的なフィールド配信
Send Log Eventアクションを使用して、宛先に到達するフィールドを制御し、使用ケースに関連するものだけを転送します。
利用可能な宛先コネクタ
ログエントリを送信するために以下のコネクタを使用します:
| コネクタ | Send Log Event | Send Entire Log Event |
|---|---|---|
| Amazon Redshift | ✓ | ✓ |
| Amazon S3 | ✓ | ✓ |
| AWS Firehose | ✓ | ✗ |
| AWS Firehose (Tealium Provided Credentials) | ✓ | ✗ |
| Confluent Kafka Connect | ✓ | ✓ |
| Datadog | ✓ | ✗ |
| File Transfer Protocol (SFTP, FTPS) | ✓ | ✓ |
| Google BigQuery | ✓ | ✓ |
| Google Cloud Pub/Sub | ✓ | ✗ |
| Google Cloud Storage | ✓ | ✓ |
| Microsoft Fabric Eventhouse | ✓ | ✓ |
| New Relic | ✓ | ✓ |
| Splunk | ✓ | ✓ |
| Webhook JDBC | ✓ | ✓ |
各宛先は、2つのログストリーミングアクションのいずれかを使用します:
- Send Entire Log Event
利用可能なすべてのログ属性を単一のペイロードで宛先に送信します。初期構成中に完全なデータ構造を確認し、使用ケースに関連するフィールドを特定するためにこのアクションを使用します。 - Send Log Event
コネクタアクション構成で明示的にマッピングした属性のみを送信します。ペイロードにはマッピングされた属性のみが含まれます。宛先に到達するフィールドを制御するために、本番環境でこのアクションを使用します。詳細については、イベント属性をベンダーパラメータにマッピングするを参照してください。
利用可能なログソース
以下のログソースタイプがサポートされています:
- Connector Errors
コネクタアクションによって生成されるエラーログ。これらのログには、エラーコード、実行ステータス、タイムスタンプ、トラブルシューティングに使用される識別子などの詳細が含まれています。
ワークフロー
始める前に、監視するコネクタとアクション、ログを受け取る外部プラットフォームを決定します。
ログストリーミングは、アウトバウンドイベントコネクタの呼び出しにカウントされます。使用ケースに必要なコネクタとアクションのみを監視してください。
- 宛先を作成するログを受け取る各外部システム用。
- ログソースを作成する監視するコネクタとアクションを定義します。
- イベント属性をベンダーパラメータにマッピングするログフィールド値を抽出するためのエンリッチメントを作成し、それらの属性を宛先固有のパラメータにマッピングします。
- 宛先システムに正しくマッピングされたフィールドでログレコードが到着することを確認します。
- ログストリーミングの管理ページを使用してログストリーミング活動を監視します。配信メトリックは、監視されているコネクタ操作の健全性ではなく、ログ配信パイプラインの健全性を反映します。
ログでキャプチャされたコネクタエラーのトラブルシューティングについては、コネクタエラーログを参照してください。
次のステップ
最終更新日 :: 2026年August月5日