diff --git a/ja_JP/changes/all-changes-ee.md b/ja_JP/changes/all-changes-ee.md index 5fdfe1a9c..d5487867b 100644 --- a/ja_JP/changes/all-changes-ee.md +++ b/ja_JP/changes/all-changes-ee.md @@ -1,13 +1,15 @@ # EMQX Enterprise リリースノート -EMQX Enterprise のリリースノートページでは、各バージョンに含まれるアップデート、機能強化、および修正の詳細な記録を提供しています。 +EMQX Enterprise のリリースノートページでは、各バージョンに含まれる更新内容、機能強化、および修正の詳細な記録を提供しています。 ## v5.9 +- [5.9.1](./changes-ee-v5.md#_5-9-1): 2025-07-02 - [5.9.0](./changes-ee-v5.md#_5-9-0): 2025-05-02 ## v5.8 +- [5.8.7](./changes-ee-v5.md#_5-8-7): 2025-07-02 - [5.8.6](./changes-ee-v5.md#_5-8-6): 2025-03-25 - [5.8.5](./changes-ee-v5.md#_5-8-5): 2025-02-25 - [5.8.4](./changes-ee-v5.md#_5-8-4): 2024-12-26 diff --git a/ja_JP/changes/changes-ee-v5.md b/ja_JP/changes/changes-ee-v5.md index 1db1bbeff..df68617c3 100644 --- a/ja_JP/changes/changes-ee-v5.md +++ b/ja_JP/changes/changes-ee-v5.md @@ -1,5 +1,77 @@ # EMQX Enterprise Version 5 +## 5.9.1 + +*Release Date: 2025-07-02* + +Make sure to check the breaking changes and known issues before upgrading to EMQX 5.9.1. + +### Enhancements + +- [#15364](https://github.com/emqx/emqx/pull/15364) Added support for custom HTTP headers in the OpenTelemetry gRPC (over HTTP/2) integration. This enhancement enables compatibility with collectors that require HTTP authentication. + +- [#15160](https://github.com/emqx/emqx/pull/15160) Added the `DELETE /mt/bulk_delete_ns` API for multi-tenancy management, which allows deleting namespaces in bulk. + +- [#15158](https://github.com/emqx/emqx/pull/15158) Added new `emqx ctl conf remove x.y.z` command, which removes the configuration key path `x.y.z` from the existing configuration. + +- [#15157](https://github.com/emqx/emqx/pull/15157) Added support for specifying private key file path for Snowflake Connector instead of using password. + + Users should either use password, private key, or neither (set parameters in `/etc/odbc.ini`). + +- [#15043](https://github.com/emqx/emqx/pull/15043) Instrument the DS Raft backend with basic metrics to provide insights into cluster status, database overview, shard replication, and replica transitions. + +### Bug Fixes + +#### Data Integration + +- [#15331](https://github.com/emqx/emqx/pull/15331) Fixed an issue in the InfluxDB action where line protocol conversion failed if the `timestamp` in `WriteSyntax` was left blank and no timestamp field was provided in the rule. + Now the system's current millisecond value is used instead, and millisecond precision is enforced. + +- [#15274](https://github.com/emqx/emqx/pull/15274) Improved the resilience of Postgres, Matrix, and TimescaleDB connectors by triggering a full reconnection on any health check failure. Previously, failed health checks could leave the connection in a broken state, causing operations to hang and potentially leading to out-of-memory issues. + +- [#15154](https://github.com/emqx/emqx/pull/15154) Fixed a rare race condition in Actions running in aggregated mode (e.g., S3, Azure Blob Storage, Snowflake) that could lead to a crash with errors like: + + ``` + ** Reason for termination == + ** {function_clause,[{emqx_connector_aggregator,handle_close_buffer,[...], ... + ``` + +- [#15147](https://github.com/emqx/emqx/pull/15147) Fixed an issue where some Actions failed to emit trace events during rule testing with simulated input data, even after request rendering. + + Affected Actions: + + - Couchbase + - Snowflake + - IoTDB (Thrift driver) + +- [#15383](https://github.com/emqx/emqx/pull/15383) Fixed a potential resource leak in the MQTT bridge. When the bridge failed to start, the topic index table was not properly cleaned up. This fix ensures that the index table is correctly deleted to prevent resource leaks. + +#### Smart Data Hub + +- [#15224](https://github.com/emqx/emqx/pull/15224) Fixed an issue where updating an External Schema Registry via the Dashboard would unintentionally overwrite the existing password with `******`. The password is now correctly preserved during updates. +- [#15190](https://github.com/emqx/emqx/pull/15190) Enhanced Message Transformation by allowing hard-coded values for QoS and topic. + +#### Observability + +- [#15299](https://github.com/emqx/emqx/pull/15299) Fixed a `badarg` error that occurred when exporting OpenTelemetry metrics. + +#### Telemetry + +- [#15216](https://github.com/emqx/emqx/pull/15216) Fixed a crash in the `emqx_telemetry` process that could occur when plugins were activated. + +#### Access Control + +- [#15184](https://github.com/emqx/emqx/pull/15184) Fixed the formatting of error messages returned when creating a blacklist fails. + +#### Clustering + +- [#15180](https://github.com/emqx/emqx/pull/15180) Reduced the risk of deadlocks during channel registration by fixing improper handling of `badrpc` errors in the `ekka_locker` module. These errors previously led to false positives in lock operations, potentially causing inconsistent cluster state and deadlocks. + +#### Security + + +- [#15159](https://github.com/emqx/emqx/pull/15159) Improved handling of Certificate Revocation List (CRL) Distribution Point URLs by stopping their refresh after repeated failures (default: 60 seconds). This prevents excessive error logs from unreachable URLs and improves overall system stability. + ## 5.9.0 *Release Date: 2025-05-02* @@ -118,7 +190,7 @@ Make sure to check the breaking changes and known issues before upgrading to EMQ - [#14892](https://github.com/emqx/emqx/pull/14892) Enhanced cluster load rebalancing: - Fixed load imbalance in core/replicant cluster. Previously, under certain conditions, all transactions from the replicants could be sent to a single core node. - + - Add CLI commands for rebalancing replicant nodes in relation to core nodes: - `emqx_ctl cluster core rebalance plan` @@ -434,6 +506,23 @@ Make sure to check the breaking changes and known issues before upgrading to EMQ - [#14775](https://github.com/emqx/emqx/pull/14775) QUIC Listener: Fixed issue where zone configurations are not applied after a config reload. +## 5.8.7 + +*Release Date: 2025-07-02* + +### Enhancements + +- [#15364](https://github.com/emqx/emqx/pull/15364) Added support for custom HTTP headers in the OpenTelemetry gRPC (over HTTP/2) integration. This enhancement enables compatibility with collectors that require HTTP authentication. + +### Bug Fixes + +- [#15383](https://github.com/emqx/emqx/pull/15383) Fixed a potential resource leak in the MQTT bridge. When the bridge failed to start, the topic index table was not properly cleaned up. This fix ensures that the index table is correctly deleted to prevent resource leaks. +- [#15331](https://github.com/emqx/emqx/pull/15331) Fixed an issue in the InfluxDB action where line protocol conversion failed if the `timestamp` in `WriteSyntax` was left blank and no timestamp field was provided in the rule. Now the system's current millisecond value is used instead, and millisecond precision is enforced. +- [#15274](https://github.com/emqx/emqx/pull/15274) Improved the resilience of Postgres, Matrix, and TimescaleDB connectors by triggering a full reconnection on any health check failure. Previously, failed health checks could leave the connection in a broken state, causing operations to hang and potentially leading to out-of-memory issues. +- [#15224](https://github.com/emqx/emqx/pull/15224) Fixed an issue where updating an External Schema Registry via the Dashboard would unintentionally overwrite the existing password with `******`. The password is now correctly preserved during updates. +- [#14989](https://github.com/emqx/emqx/pull/14989) Optimized the Kinesis Connector and Action to significantly reduce the number of AWS API calls during startup and health checks. This change helps prevent exceeding AWS Kinesis API rate limits (e.g., `ListStreams` and `DescribeStream`), which previously led to frequent health check failures when using larger connection pools or multiple connectors. +- [#15299](https://github.com/emqx/emqx/pull/15299) Fixed a `badarg` error that occurred when exporting OpenTelemetry metrics. + ## 5.8.6 *Release Date: 2025-03-25* diff --git a/ja_JP/data-integration/data-bridge-rocketmq.md b/ja_JP/data-integration/data-bridge-rocketmq.md index 2cc7db057..6cdd79b14 100644 --- a/ja_JP/data-integration/data-bridge-rocketmq.md +++ b/ja_JP/data-integration/data-bridge-rocketmq.md @@ -1,52 +1,52 @@ -# Bridge MQTT Data into RocketMQ +# MQTTデータをRocketMQにブリッジする -EMQXは[RocketMQ](https://rocketmq.apache.org/)へのデータブリッジをサポートしており、MQTTメッセージやクライアントイベントをRocketMQに転送できます。例えば、RocketMQを使ってデバイスからのセンサーデータやログデータを収集することが可能です。 +EMQXは[RocketMQ](https://rocketmq.apache.org/)へのデータブリッジをサポートしており、MQTTメッセージやクライアントイベントをRocketMQに転送できます。たとえば、RocketMQを使ってデバイスからのセンサーデータやログデータを収集することが可能です。 -本ページでは、EMQXとRocketMQ間のデータ連携の詳細な概要と、データ連携の作成および検証に関する実践的な手順を提供します。 +本ページでは、EMQXとRocketMQ間のデータ統合について詳細に解説し、データ統合の作成および検証手順を実践的に説明します。 ::: tip 注意 -Alibaba CloudがホストするRocketMQサービスを利用する場合、このデータ連携はバッチモードをサポートしていません。 +Alibaba Cloudが提供するRocketMQサービスを利用する場合、本データ統合はバッチモードをサポートしていません。 ::: -## 動作原理 +## 動作概要 -RocketMQデータ連携は、EMQXに標準搭載された機能であり、EMQXのリアルタイムデータキャプチャと送信機能をRocketMQの強力なメッセージキュー処理機能と組み合わせています。組み込みの[ルールエンジン](./rules.md)コンポーネントにより、EMQXからRocketMQへのデータ取り込みが簡素化され、複雑なコーディングが不要になります。 +RocketMQデータ統合はEMQXの標準機能であり、EMQXのリアルタイムデータキャプチャと送信機能をRocketMQの強力なメッセージキュー処理機能と組み合わせています。組み込みの[ルールエンジン](./rules.md)コンポーネントにより、EMQXからRocketMQへのデータ取り込みが簡素化され、複雑なコーディングを不要にしています。 -以下の図は、EMQXとRocketMQ間の典型的なデータ連携アーキテクチャを示しています。 +以下の図は、EMQXとRocketMQ間の典型的なデータ統合アーキテクチャを示しています。 ![EMQX Integration RocketMQ](./assets/emqx-integration-rocketmq.png) -MQTTデータをRocketMQに取り込む流れは次の通りです： +MQTTデータをRocketMQに取り込む流れは以下の通りです： -1. **メッセージのパブリッシュと受信**：産業用IoTデバイスはMQTTプロトコルを通じてEMQXに正常に接続し、リアルタイムMQTTデータをEMQXにパブリッシュします。EMQXがこれらのメッセージを受信すると、ルールエンジン内でマッチング処理を開始します。 -2. **メッセージデータの処理**：メッセージが到着するとルールエンジンを通過し、EMQXで定義されたルールによって処理されます。ルールは事前定義された条件に基づき、RocketMQにルーティングすべきメッセージを判別します。ペイロードの変換が指定されている場合は、データ形式の変換、特定情報のフィルタリング、追加コンテキストによるペイロードの強化などが適用されます。 -3. **RocketMQへのデータ取り込み**：ルールによる処理が完了したメッセージは、RocketMQへの転送アクションがトリガーされます。処理済みデータはシームレスにRocketMQに書き込まれます。 -4. **データの保存と活用**：データがRocketMQに保存された後、企業はそのクエリ機能を活用して様々なユースケースに対応できます。例えば金融業界では、RocketMQを信頼性の高い高性能メッセージキューとして利用し、決済端末や取引システムからのデータを管理します。これにより、リスク管理、不正検知・防止、規制遵守などの要件を満たすためのデータ分析や規制プラットフォームと連携可能です。 +1. **メッセージのパブリッシュと受信**：産業用IoTデバイスはMQTTプロトコルを通じてEMQXに正常に接続し、リアルタイムのMQTTデータをEMQXにパブリッシュします。EMQXがこれらのメッセージを受信すると、ルールエンジン内でマッチング処理を開始します。 +2. **メッセージデータの処理**：メッセージが届くとルールエンジンを通過し、EMQXで定義されたルールにより処理されます。ルールは事前定義された条件に基づき、RocketMQへルーティングすべきメッセージを判別します。ペイロード変換が指定されている場合は、データ形式の変換、特定情報のフィルタリング、追加コンテキストによるペイロードの拡充などが適用されます。 +3. **RocketMQへのデータ取り込み**：ルールによる処理が完了すると、メッセージをRocketMQに転送するアクションがトリガーされます。処理済みのデータはシームレスにRocketMQに書き込まれます。 +4. **データの保存と活用**：データがRocketMQに保存された後、企業はそのクエリ機能を活用して様々なユースケースに対応できます。たとえば金融業界では、RocketMQを高信頼・高性能なメッセージキューとして利用し、決済端末や取引システムからのデータを管理します。これによりリスク管理、不正検知・防止、規制遵守などの要件を満たすためのデータ分析や監査プラットフォームと連携が可能です。 ## 特長と利点 -RocketMQとのデータ連携は、以下の特長と利点をビジネスにもたらします： +RocketMQとのデータ統合により、以下の特長と利点が得られます： - **信頼性の高いIoTデータメッセージ配信**：EMQXはMQTTメッセージを信頼性高くバッチ送信でき、IoTデバイスとRocketMQおよびアプリケーションシステムの統合を実現します。 -- **MQTTメッセージの変換**：ルールエンジンを活用し、EMQXはMQTTメッセージの抽出、フィルタリング、強化、変換を行い、RocketMQに送信します。 -- **クラウドネイティブな弾力的スケーリング**：EMQXとRocketMQは共にクラウドネイティブアーキテクチャで構築されており、Kubernetes（K8s）をはじめとしたクラウドネイティブエコシステムとの親和性が高く、ビジネスの急速な成長に対応する無限の弾力的スケールが可能です。 -- **柔軟なトピックマッピング**：RocketMQデータ連携はMQTTトピックとRocketMQトピックの柔軟なマッピングをサポートし、RocketMQメッセージ内のキー（Key）や値（Value）の設定を簡単に行えます。 -- **高スループットシナリオでの処理能力**：RocketMQデータ連携は同期・非同期の両書き込みモードをサポートし、シナリオに応じてレイテンシとスループットのバランスを柔軟に調整可能です。 +- **MQTTメッセージの変換**：ルールエンジンを用いてMQTTメッセージの抽出、フィルタリング、拡充、変換が可能で、RocketMQへ送信する前にデータを柔軟に加工できます。 +- **クラウドネイティブな弾力的スケーリング**：EMQXとRocketMQは共にクラウドネイティブアーキテクチャ上に構築されており、Kubernetes（K8s）との親和性が高く、クラウドネイティブエコシステムと連携可能です。ビジネスの急速な成長に対応し、無限かつ弾力的にスケールアウトできます。 +- **柔軟なトピックマッピング**：RocketMQデータ統合はMQTTトピックとRocketMQトピックの柔軟なマッピングをサポートし、RocketMQメッセージ内のキー（Key）や値（Value）を簡単に設定できます。 +- **高スループット環境での処理能力**：RocketMQデータ統合は同期・非同期の書き込みモードをサポートし、シナリオに応じてレイテンシとスループットのバランスを柔軟に調整可能です。 ## はじめる前に -このセクションでは、RocketMQデータ連携を作成する前に必要な準備とRocketMQサーバーのセットアップ方法を説明します。 +RocketMQデータ統合の作成を開始する前に必要な準備とRocketMQサーバーのセットアップ方法を説明します。 ### 前提条件 -- EMQXデータ連携の[ルール](./rules.md)に関する知識 -- [データ連携](./data-bridges.md)に関する知識 +- EMQXデータ統合の[ルール](./rules.md)に関する知識 +- [データ統合](./data-bridges.md)に関する知識 ### RocketMQのインストール -1. RocketMQをセットアップするためのdocker-composeファイル`rocketmq.yaml`を準備します。 +1. RocketMQをセットアップするためのdocker-composeファイル`rocketmq.yaml`を用意します。 ```yaml version: '3.9' @@ -81,7 +81,7 @@ services: - mqnamesrv ``` -2. RocketMQの実行に必要なフォルダと設定を作成します。 +2. RocketMQ実行に必要なフォルダーと設定を作成します。 ```bash mkdir rocketmq @@ -131,7 +131,7 @@ docker run --rm -e NAMESRV_ADDR=host.docker.internal:9876 apache/rocketmq:4.9.4 ::: tip -Linux環境では、`host.docker.internal`を実際のIPアドレスに変更してください。 +Linux環境では`host.docker.internal`を実際のIPアドレスに変更してください。 ::: @@ -139,32 +139,32 @@ Linux環境では、`host.docker.internal`を実際のIPアドレスに変更し このセクションでは、SinkをRocketMQサーバーに接続するためのコネクター作成方法を説明します。 -以下の手順は、EMQXとRocketMQをローカルマシンで実行している場合を想定しています。リモートで実行している場合は設定を適宜調整してください。 +以下の手順は、EMQXとRocketMQをローカルマシンで実行していることを前提としています。リモート環境で実行している場合は設定を適宜調整してください。 1. EMQXダッシュボードに入り、**Integration** -> **Connectors**をクリックします。 2. ページ右上の**Create**をクリックします。 3. **Create Connector**ページで**RocketMQ**を選択し、**Next**をクリックします。 -4. **Configuration**ステップで以下を設定します： +4. **Configuration**ステップで以下の情報を設定します： - **Connector name**：コネクター名を入力します。英数字の組み合わせで、例：`my_rocketmq` - - **Servers**：`127.0.0.1:9876`を入力 - - **Namespace**：RocketMQサービスにネームスペースが設定されていなければ空欄のまま。 - - **AccessKey**、**SecretKey**、**Secret Token**：サービス構成に応じて空欄または入力 - - その他はデフォルトのまま -5. 詳細設定（任意）：[Sinkの機能](./data-bridges.md#features-of-sink)を参照 -6. **Create**をクリックする前に、**Test Connectivity**でRocketMQサーバーへの接続確認が可能です。 -7. ページ下部の**Create**ボタンをクリックしてコネクター作成を完了します。ポップアップで**Back to Connector List**か**Create Rule**を選択可能です。ルール作成については、[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)および[イベント記録用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-events-recording)を参照してください。 + - **Servers**：`127.0.0.1:9876`を入力します。 + - **Namespace**：RocketMQサービスにネームスペース設定がある場合のみ入力し、なければ空欄のままにします。 + - **AccessKey**、**SecretKey**、**Secret Token**：RocketMQサービスの設定に応じて入力するか空欄のままにします。 + - その他はデフォルトのままにします。 +5. 詳細設定（任意）：詳細は[Sinkの特長](./data-bridges.md#features-of-sink)を参照してください。 +6. **Create**をクリックする前に、**Test Connectivity**をクリックしてコネクターがRocketMQサーバーに接続可能かテストできます。 +7. ページ下部の**Create**ボタンをクリックしてコネクター作成を完了します。ポップアップダイアログで**Back to Connector List**をクリックするか、**Create Rule**をクリックしてSinkを用いたルール作成に進めます。詳しい手順は[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)および[イベント記録用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-events-recording)を参照してください。 ## メッセージ保存用RocketMQ Sinkのルール作成 -このセクションでは、ダッシュボードでソースMQTTトピック`t/#`のメッセージを処理し、処理済みデータを設定済みのSink経由でRocketMQトピック`TopicTest`に転送するルールの作成方法を説明します。 +このセクションでは、ソースMQTTトピック`t/#`からのメッセージを処理し、処理済みデータを設定済みSink経由でRocketMQトピック`TopicTest`に転送するルールをダッシュボード上で作成する方法を説明します。 1. EMQXダッシュボードで**Integration** -> **Rules**をクリックします。 2. ページ右上の**Create**をクリックします。 -3. ルールIDに`my_rule`を入力します。メッセージ保存用ルールのSQL文は以下の通りです。これはトピック`t/#`配下のMQTTメッセージをRocketMQに保存することを意味します。 +3. ルールIDに`my_rule`と入力し、メッセージ保存用のルールとして以下のSQL文を**SQL Editor**に入力します。これはトピック`t/#`配下のMQTTメッセージをRocketMQに保存することを意味します。 - 注意：独自のSQL文を指定する場合は、Sinkが必要とするすべてのフィールドを`SELECT`句に含めてください。 + 注意：独自のSQL文を指定する場合、Sinkが必要とするすべてのフィールドを`SELECT`句に含めていることを確認してください。 ```sql SELECT @@ -175,47 +175,47 @@ Linux環境では、`host.docker.internal`を実際のIPアドレスに変更し ::: tip - 初心者の方は**SQL Examples**や**Enable Test**を使ってSQLルールの学習とテストが可能です。 + 初心者の方は**SQL Examples**や**Enable Test**をクリックしてSQLルールを学習・テストできます。 ::: -4. + **Add Action**ボタンをクリックし、ルールでトリガーされるアクションを定義します。このアクションによりEMQXはルールで処理したデータをRocketMQに送信します。 +4. + **Add Action**ボタンをクリックし、ルールによりトリガーされるアクションを定義します。このアクションにより、EMQXはルールで処理されたデータをRocketMQに送信します。 -5. **Type of Action**ドロップダウンから`RocketMQ`を選択します。**Action**はデフォルトの`Create Action`のままにします。既存のSinkがあれば選択可能ですが、ここでは新規Sinkを作成します。 +5. **Type of Action**ドロップダウンから`RocketMQ`を選択します。**Action**はデフォルトの`Create Action`のままにします。既に作成済みのSinkがあれば選択可能ですが、本例では新規Sinkを作成します。 -6. Sinkの名前を入力します。英数字の組み合わせで指定してください。 +6. Sink名を入力します。英数字の組み合わせで指定してください。 -7. **Connector**ドロップダウンから先に作成した`my_rocketmq`を選択します。新規コネクターはドロップダウン横のボタンで作成可能です。設定パラメータは[コネクターの作成](#create-a-connector)を参照してください。 +7. **Connector**ドロップダウンから先ほど作成した`my_rocketmq`を選択します。新規コネクターを作成する場合はドロップダウン横のボタンをクリックしてください。設定パラメーターは[コネクターの作成](#create-a-connector)を参照してください。 -8. **RocketMQ Topic**欄に`TopicTest`を入力します。 +8. **RocketMQ Topic**欄に`TopicTest`と入力します。 9. **Template**はデフォルトで空欄のままにします。 ::: tip - 空欄の場合、メッセージ全体がRocketMQに転送されます。実際にはJSONテンプレートデータです。 + この値が空欄の場合、メッセージ全体がRocketMQに転送されます。実際の値はJSONテンプレートデータです。 ::: -10. **Fallback Actions（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義できます。詳細は[Fallback Actions](./data-bridges.md#fallback-actions)を参照してください。 +10. **フォールバックアクション（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義可能です。詳細は[フォールバックアクション](./data-bridges.md#fallback-actions)を参照してください。 -11. **詳細設定（任意）**：[Sinkの機能](./data-bridges.md#features-of-sink)を参照してください。 +11. **詳細設定（任意）**：詳細は[Sinkの特長](./data-bridges.md#features-of-sink)を参照してください。 -12. **Create**をクリックする前に、**Test Connectivity**でSinkがRocketMQサーバーに接続できるか確認できます。 +12. **Create**をクリックする前に、**Test Connectivity**をクリックしてSinkがRocketMQサーバーに接続可能かテストできます。 -13. **Create**ボタンをクリックし、Sink設定を完了します。新しいSinkが**Action Outputs**に追加されます。 +13. **Create**ボタンをクリックしてSink設定を完了します。新しいSinkが**Action Outputs**に追加されます。 -14. **Create Rule**ページに戻り、設定内容を確認後、**Create**ボタンをクリックしてルールを生成します。 +14. **Create Rule**ページに戻り、設定内容を確認してから**Create**ボタンをクリックしルールを生成します。 -これでRocketMQ Sink用のルール作成が完了しました。**Integration** -> **Rules**ページで新規作成したルールを確認できます。**Actions(Sink)**タブをクリックすると新しいRocketMQ Sinkが表示されます。 +これでRocketMQ Sink用のルールが正常に作成されました。**Integration** -> **Rules**ページで新規ルールを確認できます。**Actions(Sink)**タブをクリックすると新しいRocketMQ Sinkが表示されます。 -また、**Integration** -> **Flow Designer**でトポロジーを確認すると、トピック`t/#`配下のメッセージがルール`my_rule`で解析され、RocketMQに送信・保存されていることがわかります。 +また、**Integration** -> **Flow Designer**をクリックするとトポロジーが表示され、トピック`t/#`のメッセージがルール`my_rule`で解析され、RocketMQに送信・保存されていることが確認できます。 ## イベント記録用RocketMQ Sinkのルール作成 このセクションでは、クライアントのオンライン／オフライン状態を記録し、イベントデータを設定済みSink経由でRocketMQトピック`TestTopic`に転送するルールの作成方法を説明します。 -ルール作成手順は[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)とほぼ同様ですが、SQLルールの文法が異なります。 +ルール作成手順は[メッセージ保存用RocketMQ Sinkのルール作成](#create-a-rule-with-rocketmq-sink-for-message-storage)とほぼ同様ですが、SQLルール文が異なります。 オンライン／オフライン状態記録用のSQLルール文は以下の通りです： @@ -228,7 +228,7 @@ FROM ::: tip -便宜上、オンライン／オフラインイベントの受信用に`TopicTest`トピックを再利用します。 +利便性のため、`TopicTest`トピックをオンライン／オフラインイベントの受け取りに再利用します。 ::: @@ -240,11 +240,11 @@ MQTTXを使ってトピック`t/1`にメッセージを送信し、オンライ mqttx pub -i emqx_c -t t/1 -m '{ "msg": "hello RocketMQ" }' ``` -Sinkの稼働状況を確認すると、新規の受信メッセージと送信メッセージが1件ずつあるはずです。 +Sinkの稼働状況を確認すると、新規の受信メッセージと送信メッセージが1件ずつ増えているはずです。 データが`TopicTest`トピックに転送されているか確認してください。 -以下のようなデータがコンシューマーに表示されます。 +以下のようなデータがコンシューマーにより出力されます。 ```bash ConsumeMessageThread_please_rename_unique_group_name_4_1 Receive New Messages: [MessageExt [brokerName=broker-a, queueId=3, storeSize=581, queueOffset=0, sysFlag=0, bornTimestamp=1679037578889, bornHost=/172.26.83.106:43920, storeTimestamp=1679037578891, storeHost=/172.26.83.106:10911, msgId=AC1A536A00002A9F000000000000060E, commitLogOffset=1550, bodyCRC=7414108, reconsumeTimes=0, preparedTransactionOffset=0, toString()=Message{topic='TopicTest', flag=0, properties={MIN_OFFSET=0, MAX_OFFSET=8, CONSUME_START_TIME=1679037605342, CLUSTER=DefaultCluster}, body=[...], transactionId='null'}]] diff --git a/ja_JP/data-integration/snowflake.md b/ja_JP/data-integration/snowflake.md index 1d7858735..a07251c6c 100644 --- a/ja_JP/data-integration/snowflake.md +++ b/ja_JP/data-integration/snowflake.md @@ -1,93 +1,146 @@ -# Snowflake への MQTT データ取り込み +# SnowflakeへのMQTTデータ取り込み -[Snowflake](https://www.snowflake.com/en/) は、クラウドベースのデータプラットフォームであり、高いスケーラビリティと柔軟性を備えたデータウェアハウジング、分析、および安全なデータ共有のソリューションを提供します。構造化データおよび半構造化データの処理に優れ、大量のデータを高速なクエリ性能で保存し、さまざまなツールやサービスとシームレスに統合できるよう設計されています。 +[Snowflake](https://www.snowflake.com/en/) は、クラウドベースのデータプラットフォームであり、高いスケーラビリティと柔軟性を備えたデータウェアハウジング、分析、セキュアなデータ共有のソリューションを提供します。構造化データおよび半構造化データの処理に優れており、大量のデータを高速なクエリ性能で保存し、さまざまなツールやサービスとシームレスに統合できるよう設計されています。 -本ページでは、EMQX と Snowflake 間のデータ統合について詳しく紹介し、ルールおよび Sink の作成方法について実践的なガイドを提供します。 +本ページでは、EMQXとSnowflake間のデータ統合について詳細に紹介し、ルールおよびSinkの作成方法について実践的なガイダンスを提供します。 ## 動作概要 -EMQX における Snowflake データ統合はすぐに使える機能であり、複雑なビジネス開発にも簡単に設定可能です。典型的な IoT アプリケーションでは、EMQX がデバイス接続とメッセージ送受信を担う IoT プラットフォームとして機能し、Snowflake はメッセージデータの取り込み、保存、分析を担当するデータストレージおよび処理プラットフォームとして利用されます。 +EMQXにおけるSnowflakeデータ統合はすぐに利用可能な機能であり、複雑なビジネス開発に対しても簡単に設定できます。典型的なIoTアプリケーションでは、EMQXがデバイス接続とメッセージ伝送を担うIoTプラットフォームとして機能し、Snowflakeはメッセージデータの取り込み、保存、分析を行うデータストレージおよび処理プラットフォームとして役割を果たします。 ![snowflake-architecture](./assets/snowflake-architecture.png) -EMQX はルールエンジンと Sink を利用してデバイスイベントやデータを Snowflake に転送します。エンドユーザーやアプリケーションは Snowflake のテーブル内のデータにアクセスできます。具体的なワークフローは以下の通りです： +EMQXはルールエンジンとSinkを利用してデバイスのイベントやデータをSnowflakeに転送します。エンドユーザーやアプリケーションはSnowflakeのテーブル内のデータにアクセスできます。具体的なワークフローは以下の通りです： -1. **デバイスの EMQX への接続**：IoT デバイスは MQTT プロトコルで正常に接続するとオンラインイベントをトリガーします。イベントにはデバイスID、送信元IPアドレスなどの情報が含まれます。 -2. **デバイスメッセージのパブリッシュと受信**：デバイスは特定のトピックを通じてテレメトリや状態データをパブリッシュします。EMQX はメッセージを受信し、ルールエンジン内で比較処理を行います。 -3. **ルールエンジンによるメッセージ処理**：組み込みのルールエンジンはトピックマッチングに基づき特定のソースからのメッセージやイベントを処理します。対応するルールをマッチングし、データ形式変換、特定情報のフィルタリング、コンテキスト情報の付加などの処理を行います。 -4. **Snowflake への書き込み**：ルールはメッセージを Snowflake Stage に書き込み、そこから Snowflake テーブルにロードするアクションをトリガーします。 +1. **デバイスのEMQXへの接続**：IoTデバイスはMQTTプロトコルで正常に接続するとオンラインイベントをトリガーします。このイベントにはデバイスID、送信元IPアドレスなどのプロパティ情報が含まれます。 +2. **デバイスのメッセージパブリッシュと受信**：デバイスは特定のトピックを通じてテレメトリやステータスデータをパブリッシュします。EMQXはメッセージを受信し、ルールエンジン内で比較処理を行います。 +3. **ルールエンジンによるメッセージ処理**：組み込みのルールエンジンはトピックマッチングに基づき特定のソースからのメッセージやイベントを処理します。対応するルールをマッチングし、データフォーマット変換、特定情報のフィルタリング、コンテキスト情報の付加などの処理を行います。 +4. **Snowflakeへの書き込み**：ルールはSnowflake Stageへのメッセージ書き込みアクションをトリガーし、その後Snowflakeテーブルにロードします。 -イベントやメッセージデータが Snowflake に書き込まれた後は、以下のようなビジネスや技術的な目的で利用可能です： +イベントやメッセージデータがSnowflakeに書き込まれた後は、以下のような多様なビジネスおよび技術目的で利用可能です： -- **データアーカイブ**：IoT データを Snowflake に安全に長期保存し、コンプライアンスや過去データの利用を保証します。 -- **データ分析**：Snowflake のデータウェアハウジングおよび分析機能を活用し、リアルタイムまたはバッチ分析を行い、予知保全、運用インサイト、デバイス性能評価を可能にします。 +- **データアーカイブ**：IoTデータをSnowflakeに安全に長期保存し、コンプライアンスや履歴データの利用を保証します。 +- **データ分析**：Snowflakeのデータウェアハウジングおよび分析機能を活用し、リアルタイムまたはバッチ分析を実施。予知保全、運用インサイト、デバイス性能評価などを可能にします。 ## 特長と利点 -EMQX の Snowflake データ統合を利用することで、以下の特長と利点が得られます： +EMQXでSnowflakeデータ統合を利用することで、以下の特長と利点をビジネスにもたらします： -- **メッセージ変換**：メッセージは EMQX のルール内で高度な処理や変換を経てから Snowflake に書き込まれるため、後続の保存や利用が容易になります。 -- **柔軟なデータ操作**：Snowflake Sink は、書き込むフィールドを選択可能であり、ビジネスニーズに応じた効率的かつ動的なストレージ構成が可能です。 -- **統合されたビジネスプロセス**：Snowflake Sink によりデバイスデータを Snowflake の豊富なエコシステムアプリケーションと組み合わせ、データ分析やアーカイブなど多様なビジネスシナリオを実現します。 -- **低コストの長期保存**：Snowflake のスケーラブルなストレージ基盤は、従来のデータベースに比べて低コストで長期データ保持に最適なソリューションです。大量の IoT データ保存に適しています。 +- **メッセージ変換**：メッセージはEMQXのルール内で高度な処理や変換を経てSnowflakeに書き込まれるため、後続の保存や利用が容易になります。 +- **柔軟なデータ操作**：Snowflake Sinkは書き込むフィールドを選択可能で、ビジネスニーズに応じた効率的かつ動的なストレージ構成を実現します。 +- **統合されたビジネスプロセス**：Snowflake Sinkにより、デバイスデータをSnowflakeの豊富なエコシステムアプリケーションと組み合わせ、データ分析やアーカイブなど多様なビジネスシナリオを実現します。 +- **低コストの長期保存**：Snowflakeのスケーラブルなストレージ基盤は、従来のデータベースより低コストで大量のIoTデータを長期保存するのに最適です。 -これらの特長により、効率的で信頼性が高くスケーラブルな IoT アプリケーションを構築し、ビジネスの意思決定や最適化に役立てることができます。 +これらの特長により、効率的で信頼性が高くスケーラブルなIoTアプリケーションを構築し、ビジネスの意思決定や最適化に役立てることができます。 ## はじめる前に -このセクションでは、EMQX で Snowflake Sink を作成する前に必要な準備について説明します。 +このセクションでは、EMQXでSnowflake Sinkを作成する前に必要な準備について説明します。 ### 前提条件 -- [ルール](./rules.md) の理解 -- [データ統合](./data-bridges.md) の理解 +- [ルール](./rules.md)の理解 +- [データ統合](./data-bridges.md)の理解 -### Snowflake ODBC ドライバーの初期化 +### Snowflake ODBCドライバーの初期設定 -EMQX が Snowflake と通信し効率的にデータ転送を行うために、Snowflake Open Database Connectivity (ODBC) ドライバーのインストールと設定が必要です。これは通信の橋渡し役となり、データの適切なフォーマット、認証、転送を保証します。 +EMQXがSnowflakeと通信し、効率的にデータ転送を行うためには、SnowflakeのOpen Database Connectivity（ODBC）ドライバーをインストールおよび設定する必要があります。ODBCドライバーは通信の橋渡し役を担い、データの適切なフォーマット化、認証、転送を保証します。 -詳細は公式の [ODBC Driver](https://docs.snowflake.com/en/developer-guide/odbc/odbc) ページおよび [ライセンス契約](https://sfc-repo.snowflakecomputing.com/odbc/Snowflake_ODBC_Driver_License_Agreement.pdf) を参照してください。 +詳細は公式の[ODBC Driver](https://docs.snowflake.com/en/developer-guide/odbc/odbc)ページおよび[ライセンス契約](https://sfc-repo.snowflakecomputing.com/odbc/Snowflake_ODBC_Driver_License_Agreement.pdf)を参照してください。 #### Linux -以下のスクリプトを実行して Snowflake ODBC ドライバーをインストールし、`odbc.ini` ファイルを設定します： +EMQXはDebian系（Ubuntuなど）向けにSnowflake ODBCドライバーの迅速な導入と必要なシステム設定を行う[インストールスクリプト](https://github.com/emqx/emqx/blob/master/scripts/install-snowflake-driver.sh)を提供しています。 +::: tip 注意 + +このスクリプトはテスト用であり、本番環境でのODBCドライバー設定方法の推奨ではありません。公式の[Linux向けインストール手順](https://docs.snowflake.com/en/developer-guide/odbc/odbc-linux)を参照してください。 + +::: + +**インストールスクリプトの実行** + +`scripts/install-snowflake-driver.sh`スクリプトをローカルマシンにコピーし、実行権限を付与してから`sudo`で実行します： + +```bash +chmod a+x scripts/install-snowflake-driver.sh +sudo ./scripts/install-snowflake-driver.sh ``` -scripts/install-snowflake-driver.sh + +スクリプトはSnowflake ODBCの`.deb`インストールパッケージ（例：`snowflake-odbc-3.4.1.x86_64.deb`）をカレントディレクトリに自動ダウンロードし、ドライバーをインストール後、以下のシステム設定ファイルを更新します： + +- `/etc/odbc.ini`：Snowflakeデータソース設定を追加 +- `/etc/odbcinst.ini`：Snowflakeドライバーパスを登録 + +**設定例** + +`/etc/odbc.ini`の内容確認： + ``` +emqx@emqx-0:~$ cat /etc/odbc.ini -::: tip 注意 +[snowflake] +Description=SnowflakeDB +Driver=SnowflakeDSIIDriver +Locale=en-US +PORT=443 +SSL=on -このスクリプトはテスト用であり、本番環境での ODBC ドライバー設定方法の推奨ではありません。公式の [Linux 向けインストール手順](https://docs.snowflake.com/en/developer-guide/odbc/odbc-linux) を参照してください。 +[ODBC Data Sources] +snowflake = SnowflakeDSIIDriver +``` -::: +`/etc/odbcinst.ini`の内容確認： + +``` +emqx@emqx-0:~$ cat /etc/odbcinst.ini + +[ODBC Driver 18 for SQL Server] +Description=Microsoft ODBC Driver 18 for SQL Server +Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.5.so.1.1 +UsageCount=1 + +[ODBC Driver 17 for SQL Server] +Description=Microsoft ODBC Driver 17 for SQL Server +Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.10.so.6.1 +UsageCount=1 + +[SnowflakeDSIIDriver] +APILevel=1 +ConnectFunctions=YYY +Description=Snowflake DSII +Driver=/usr/lib/snowflake/odbc/lib/libSnowflake.so +DriverODBCVer=03.52 +SQLLevel=1 +UsageCount=1 +``` #### macOS -macOS で Snowflake ODBC ドライバーをインストールおよび設定する手順は以下の通りです： +macOSでSnowflake ODBCドライバーをインストールおよび設定する手順は以下の通りです： -1. unixODBC をインストール（例）： +1. unixODBCをインストール（例）： ``` brew install unixodbc ``` -2. [iODBC をダウンロードしてインストール](https://github.com/openlink/iODBC/releases/download/v3.52.16/iODBC-SDK-3.52.16-macOS11.dmg)。 +2. [iODBCのダウンロードとインストール](https://github.com/openlink/iODBC/releases/download/v3.52.16/iODBC-SDK-3.52.16-macOS11.dmg)。 -3. [Snowflake ODBC ドライバーをダウンロードしてインストール](https://sfc-repo.snowflakecomputing.com/odbc/macuniversal/3.3.2/snowflake_odbc_mac_64universal-3.3.2.dmg)。 +3. [Snowflake ODBCドライバーのダウンロードとインストール](https://sfc-repo.snowflakecomputing.com/odbc/macuniversal/3.3.2/snowflake_odbc_mac_64universal-3.3.2.dmg)。 -4. 詳細なインストールおよび設定手順は [macOS 向け ODBC ドライバーのインストールと設定](https://docs.snowflake.com/en/developer-guide/odbc/odbc-mac) を参照してください。 +4. 詳細なインストール・設定手順は[macOS向けODBCドライバーのインストールと設定](https://docs.snowflake.com/en/developer-guide/odbc/odbc-mac)を参照。 -5. インストール後、以下の設定ファイルを更新します： +5. インストール後、以下の設定ファイルを更新： - - Snowflake ODBC ドライバーの権限と設定を更新： + - Snowflake ODBCドライバーの権限と設定を更新： ```bash chown $(id -u):$(id -g) /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini echo 'ODBCInstLib=libiodbcinst.dylib' >> /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini ``` - - `~/.odbc.ini` ファイルを作成または更新して ODBC 接続を設定： + - `~/.odbc.ini`ファイルを作成または更新し、ODBC接続を設定： ``` cat << EOF > ~/.odbc.ini @@ -108,124 +161,150 @@ macOS で Snowflake ODBC ドライバーをインストールおよび設定す ### ユーザーアカウントとデータベースの作成 -Snowflake ODBC ドライバーをインストールしたら、データ取り込み用のユーザーアカウント、データベース、および関連リソースを設定します。これらの認証情報は後で EMQX のコネクターおよび Sink 設定時に使用します。 +Snowflake ODBCドライバーのインストールが完了したら、データ取り込み用のユーザーアカウント、データベース、および関連リソースを設定します。以下の認証情報は後でEMQXのコネクターおよびSink設定時に必要となります： -| フィールド名 | 値 | -| -------------------------- | ------------------------------------------------ | -| Data Source Name (DSN) | `snowflake` | -| ユーザー名 | `snowpipeuser` | -| パスワード | `Snowpipeuser99` | -| データベース名 | `testdatabase` | -| スキーマ | `public` | -| ステージ | `emqx` | -| パイプ | `emqx` | -| パイプユーザー | `snowpipeuser` | -| プライベートキー | `file://` | +| 項目 | 値 | +| ----------------------- | ------------------------------------------------ | +| データソース名（DSN） | `snowflake` | +| ユーザー名 | `snowpipeuser` | +| パスワード | `Snowpipeuser99` | +| データベース名 | `testdatabase` | +| スキーマ | `public` | +| ステージ | `emqx` | +| パイプ | `emqx` | +| パイプユーザー | `snowpipeuser` | +| プライベートキー | `file://` | -#### RSA キーペアの生成 +#### RSA鍵ペアの生成 -Snowflake への安全な接続のため、以下のコマンドで認証用の RSA キーペアを生成します： +Snowflakeへの安全な接続のため、以下のコマンドでRSA鍵ペアを生成します： ```bash openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_rsa_key.private.pem -nocrypt openssl rsa -in snowflake_rsa_key.private.pem -pubout -out snowflake_rsa_key.public.pem ``` -詳細は [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth) を参照してください。 +詳細は[鍵ペア認証と鍵ペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth)を参照してください。 -#### SQL を使った Snowflake リソースのセットアップ +#### SQLによるSnowflakeリソースの設定 -ODBC ドライバーのセットアップと RSA キーペア生成後、Snowflake のリソースを設定します。SQL コマンドを使ってデータベース、テーブル、ステージ、パイプを作成します。 +ODBCドライバーの設定とRSA鍵ペアの生成が完了したら、SnowflakeコンソールのSQLワークシートで以下のSQLを実行し、データベース、テーブル、ステージ、パイプを作成します： -1. Snowflake コンソールの SQL ワークシートを開き、以下の SQL を実行してデータベース、テーブル、ステージ、パイプを作成します： +```sql +USE ROLE accountadmin; - ```sql - USE ROLE accountadmin; - - CREATE DATABASE IF NOT EXISTS testdatabase; - - CREATE OR REPLACE TABLE testdatabase.public.emqx ( - clientid STRING, - topic STRING, - payload STRING, - publish_received_at TIMESTAMP_LTZ - ); - - CREATE STAGE IF NOT EXISTS testdatabase.public.emqx - FILE_FORMAT = (TYPE = CSV PARSE_HEADER = TRUE FIELD_OPTIONALLY_ENCLOSED_BY = '"') - COPY_OPTIONS = (ON_ERROR = CONTINUE PURGE = TRUE); - - CREATE PIPE IF NOT EXISTS testdatabase.public.emqx AS - COPY INTO testdatabase.public.emqx - FROM @testdatabase.public.emqx - MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE; - ``` +CREATE DATABASE IF NOT EXISTS testdatabase; -2. 新しいユーザーを作成し、そのユーザーに RSA 公開鍵を設定します： +CREATE OR REPLACE TABLE testdatabase.public.emqx ( + clientid STRING, + topic STRING, + payload STRING, + publish_received_at TIMESTAMP_LTZ +); - ```sql - CREATE USER IF NOT EXISTS snowpipeuser - PASSWORD = 'Snowpipeuser99' - MUST_CHANGE_PASSWORD = FALSE; - - ALTER USER snowpipeuser SET RSA_PUBLIC_KEY = ' - - - - - '; - ``` +CREATE STAGE IF NOT EXISTS testdatabase.public.emqx +FILE_FORMAT = (TYPE = CSV PARSE_HEADER = TRUE FIELD_OPTIONALLY_ENCLOSED_BY = '"') +COPY_OPTIONS = (ON_ERROR = CONTINUE PURGE = TRUE); - ::: tip +CREATE PIPE IF NOT EXISTS testdatabase.public.emqx AS +COPY INTO testdatabase.public.emqx +FROM @testdatabase.public.emqx +MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE; +``` - PEM ファイルの `-----BEGIN PUBLIC KEY-----` および `-----END PUBLIC KEY-----` 行は削除し、残りの内容を改行を保持したまま含めてください。 +次に、新規ユーザーを作成し、そのユーザーにRSA公開鍵を設定します： - ::: +```sql +CREATE USER IF NOT EXISTS snowpipeuser + PASSWORD = 'Snowpipeuser99' + MUST_CHANGE_PASSWORD = FALSE; + +ALTER USER snowpipeuser SET RSA_PUBLIC_KEY = ' + + + + +'; +``` -3. ユーザーが Snowflake リソースを管理できるように必要なロールを作成し割り当てます： +::: tip - ```sql - CREATE OR REPLACE ROLE snowpipe; - - GRANT USAGE ON DATABASE testdatabase TO ROLE snowpipe; - GRANT USAGE ON SCHEMA testdatabase.public TO ROLE snowpipe; - GRANT INSERT, SELECT ON testdatabase.public.emqx TO ROLE snowpipe; - GRANT READ, WRITE ON STAGE testdatabase.public.emqx TO ROLE snowpipe; - GRANT OPERATE, MONITOR ON PIPE testdatabase.public.emqx TO ROLE snowpipe; - GRANT ROLE snowpipe TO USER snowpipeuser; - ALTER USER snowpipeuser SET DEFAULT_ROLE = snowpipe; - ``` +PEMファイルの`-----BEGIN PUBLIC KEY-----`および`-----END PUBLIC KEY-----`の行は削除し、残りの内容を改行を保持したまま貼り付けてください。 + +::: + +最後に、Snowflakeリソース管理用のロールを作成し、ユーザーに割り当てます： + +```sql +CREATE OR REPLACE ROLE snowpipe; + +GRANT USAGE ON DATABASE testdatabase TO ROLE snowpipe; +GRANT USAGE ON SCHEMA testdatabase.public TO ROLE snowpipe; +GRANT INSERT, SELECT ON testdatabase.public.emqx TO ROLE snowpipe; +GRANT READ, WRITE ON STAGE testdatabase.public.emqx TO ROLE snowpipe; +GRANT OPERATE, MONITOR ON PIPE testdatabase.public.emqx TO ROLE snowpipe; +GRANT ROLE snowpipe TO USER snowpipeuser; +ALTER USER snowpipeuser SET DEFAULT_ROLE = snowpipe; +``` ## コネクターの作成 -Snowflake Sink を追加する前に、EMQX で Snowflake への接続を確立するためのコネクターを作成します。 +Snowflake Sinkを追加する前に、EMQXでSnowflakeとの接続を確立するためのコネクターを作成する必要があります。 1. ダッシュボードの **Integration** -> **Connector** ページに移動します。 + 2. 右上の **Create** ボタンをクリックします。 + 3. コネクタータイプとして **Snowflake** を選択し、次へ進みます。 -4. コネクター名を入力します。英数字の組み合わせで、ここでは `my-snowflake` と入力します。 + +4. コネクター名を入力します。英数字の大文字・小文字の組み合わせで、ここでは `my-snowflake` と入力します。 + 5. 接続情報を入力します。 - - **Account**：Snowflake の組織IDとアカウント名をハイフン（`-`）で区切って入力します。これは Snowflake プラットフォームの URL の一部で、Snowflake コンソールで確認可能です。 - - **Server Host**：Snowflake のエンドポイント URL で、通常 `-.snowflakecomputing.com` の形式です。`-` はご自身の Snowflake インスタンス固有のサブドメインに置き換えてください。 - - **Data Source Name(DSN)**：ODBC ドライバー設定時に `.odbc.ini` ファイルで設定した `snowflake` を入力します。 - - **Username**：前述の設定で作成した `snowpipeuser` を入力します。 - - **Password**：前述の設定で定義した `Snowpipeuser99` を入力します。 -6. 暗号化接続を確立したい場合は、**Enable TLS** のトグルスイッチをオンにします。TLS 接続の詳細は [TLS for External Resource Access](../network/overview.md/#tls-for-external-resource-access) を参照してください。 -7. 詳細設定（任意）：[Advanced Settings](#advanced-settings) を参照してください。 -8. **Create** をクリックする前に、**Test Connectivity** ボタンでコネクターが Snowflake に接続できるかテストできます。 -9. 最後に、ページ下部の **Create** ボタンをクリックしてコネクター作成を完了します。 + - **Server Host**：SnowflakeのエンドポイントURLで、通常 `-.snowflakecomputing.com` の形式です。`-` はご利用のSnowflakeインスタンス固有のサブドメインに置き換えてください。 + + - **Data Source Name(DSN)**：ODBCドライバー設定時に`.odbc.ini`で設定した`snowflake`を入力します。 + + - **Account**：Snowflakeの組織IDとアカウント名をハイフン（`-`）で繋いだものを入力します。SnowflakeコンソールのURLに含まれる情報です。 + + - **Username**：前述のセットアップで定義した`snowpipeuser`を入力します。 + + - **Password**：ODBCのユーザー名/パスワード認証でSnowflakeに接続するためのパスワードです。任意入力項目です： + + - ここにパスワード（例：`Snowpipeuser99`）を入力するか、 + - `/etc/odbc.ini`に設定するか、 + - キーペア認証を使用する場合は空欄にしてください。 + + ::: tip + + 認証にはパスワードかプライベートキーのいずれか一方を使用してください。両方を設定しないでください。ここで設定しない場合は、適切な認証情報が`/etc/odbc.ini`に設定されていることを確認してください。 + + ::: + + - **Proxy**：HTTPプロキシ経由でSnowflakeに接続する場合の設定です。HTTPSプロキシはサポートされていません。デフォルトはプロキシなしです。プロキシを有効にする場合は`Enable Proxy`を選択し、以下を入力します： + - **Proxy Host**：プロキシサーバーのホスト名またはIPアドレス + - **Proxy Port**：プロキシサーバーのポート番号 + - **Private Key Path**：SnowflakeへのODBC認証に使用するRSAプライベートキーの絶対ファイルパスです。クラスター内の全ノードで同一パスかつEMQXアプリケーションユーザーがアクセス可能である必要があります。`file://`で始まるパスを指定してください（例：`file:///etc/emqx/certs/snowflake_rsa_key.private.pem`）。 + - **Private Key Password**：プライベートキーが暗号化されている場合の復号パスワードです。OpenSSLの`-nocrypt`オプションで生成した場合は空欄にしてください。 + +6. 暗号化接続を確立する場合は、**Enable TLS** トグルスイッチをオンにします。TLS接続の詳細は[外部リソースアクセスのTLS](../network/overview.md/#tls-for-external-resource-access)を参照してください。 -これでコネクターの作成が完了し、次にルールと Sink を作成してデータの書き込み方法を指定できます。 +7. 高度な設定（任意）：[高度な設定](#advanced-settings)を参照してください。 -## Snowflake Sink を使ったルールの作成 +8. **Create**をクリックする前に、**Test Connectivity**でSnowflakeへの接続テストが可能です。 -このセクションでは、EMQX でソース MQTT トピック `t/#` からのメッセージを処理し、処理結果を設定済みの Snowflake Sink を通じて Snowflake に書き込むルールの作成方法を示します。 +9. 画面下部の **Create** ボタンをクリックしてコネクター作成を完了します。 + +これでコネクター作成が完了し、次にルールおよびSinkを作成してSnowflakeへのデータ書き込み方法を指定できます。 + +## Snowflake Sinkを用いたルールの作成 + +このセクションでは、EMQXでソースMQTTトピック`t/#`からのメッセージを処理し、処理結果を設定済みのSnowflake Sinkを通じてSnowflakeに書き込むルールの作成方法を示します。 1. ダッシュボードの **Integration** -> **Rules** ページに移動します。 2. 右上の **Create** ボタンをクリックします。 -3. ルールID に `my_rule` と入力し、SQL エディターに以下のルール SQL を入力します： +3. ルールIDに `my_rule` を入力し、SQLエディタに以下のルールSQLを入力します： ```sql SELECT @@ -239,52 +318,51 @@ Snowflake Sink を追加する前に、EMQX で Snowflake への接続を確立 ::: tip - SQL に不慣れな場合は、**SQL Examples** をクリックし、**Enable Debug** を有効にしてルール SQL の結果を学習・テストできます。 + SQLに不慣れな場合は、**SQL Examples**や**Enable Debug**をクリックしてルールSQLの学習やテストが可能です。 ::: - ::: tip - - Snowflake 連携では、選択するフィールドが Snowflake 側で定義したテーブルのカラム数および名前と完全に一致していることが重要です。余分なフィールドを追加したり、`*` で全選択することは避けてください。 - + + Snowflake連携では、選択するフィールドはSnowflake側テーブルのカラム数および名前と正確に一致させることが重要です。余分なフィールドを追加したり`*`で選択しないよう注意してください。 + ::: -4. アクションを追加し、**Action Type** ドロップダウンリストから `Snowflake` を選択します。アクションのドロップダウンはデフォルトの `create action` のままにするか、既存の Snowflake アクションを選択します。ここでは新しい Sink を作成してルールに追加します。 +4. アクションを追加し、**Action Type**ドロップダウンから`Snowflake`を選択します。アクションドロップダウンはデフォルトの`create action`のままにするか、既存のSnowflakeアクションを選択します。ここでは新規Sinkを作成し、ルールに追加します。 -5. Sink の名前（例：`snowflake_sink`）と簡単な説明を入力します。 +5. Sink名（例：`snowflake_sink`）と簡単な説明を入力します。 -6. 先に作成した `my-snowflake` コネクターをコネクタードロップダウンから選択します。ドロップダウン横の作成ボタンをクリックしてポップアップで新規コネクターを素早く作成することも可能です。必要な設定パラメータは [Create a Connector](#create-a-connector) を参照してください。 +6. 先ほど作成した`my-snowflake`コネクターをコネクタードロップダウンから選択します。ドロップダウン横の作成ボタンをクリックしてポップアップで新規コネクターを素早く作成することも可能です。必要な設定パラメータは[コネクターの作成](#コネクターの作成)を参照してください。 7. 以下の設定を行います： - - **Database Name**：`testdatabase` を入力。EMQX データ保存用に作成した Snowflake データベースです。 - - **Schema**：`public` を入力。`testdatabase` 内のデータテーブルがあるスキーマです。 - - **Stage**：`emqx` を入力。Snowflake でデータをテーブルにロードする前に保持するステージです。 - - **Pipe**：`emqx` を入力。ステージからテーブルへのロード処理を自動化するパイプです。 - - **Pipe User**：`snowpipeuser` を入力。パイプ管理権限を持つ Snowflake ユーザーです。 - - **Private Key**：RSA プライベートキーのパス（例：`file://`）または RSA プライベートキーファイルの内容を入力します。これは安全な認証に使用され、Snowflake パイプへの安全なアクセスに必要です。ファイルパスを使用する場合は、クラスタ内のすべてのノードでパスが一貫しており、EMQX アプリケーションユーザーがアクセス可能である必要があります。 + - **Database Name**：`testdatabase`を入力。EMQXデータ保存用に作成したSnowflakeのデータベース名です。 + - **Schema**：`public`を入力。`testdatabase`内のデータテーブルが存在するスキーマ名です。 + - **Stage**：`emqx`を入力。Snowflakeでデータをテーブルにロードする前に保持するステージ名です。 + - **Pipe**：`emqx`を入力。ステージからテーブルへのロードを自動化するパイプ名です。 + - **Pipe User**：`snowpipeuser`を入力。パイプ管理権限を持つSnowflakeユーザー名です。 + - **Private Key**：プライベートRSA鍵のパス（例：`file://`）またはRSAプライベートキーファイルの内容を入力します。Snowflakeパイプへの安全な認証に使用します。ファイルパスを使用する場合はクラスター内全ノードで同一かつEMQXアプリケーションユーザーがアクセス可能である必要があります。 -8. **Upload Mode** を選択します。現在は `Aggregated Upload` のみサポートしています。この方法は複数のルールトリガー結果を単一ファイル（例：CSV ファイル）にまとめて Snowflake にアップロードし、ファイル数を減らして書き込み効率を向上させます。 +8. **Upload Mode**を選択します。現在は`Aggregated Upload`のみサポートしています。この方式は複数のルールトリガー結果を1つのファイル（例：CSVファイル）にまとめてSnowflakeにアップロードし、ファイル数を減らして書き込み効率を向上させます。 -9. **Aggregation Type** を選択します。現在は `csv` のみサポートしています。データはカンマ区切りの CSV 形式で Snowflake にステージングされます。 +9. **Aggregation Type**を選択します。現在は`csv`のみサポートしています。データはカンマ区切りのCSV形式でSnowflakeにステージングされます。 - - **Column Order**：ドロップダウンリストから列の順序を選択します。生成される CSV ファイルは、選択した列の順序でソートされ、未選択の列はアルファベット順にソートされます。 + - **Column Order**：ドロップダウンから列の並び順を選択します。生成されるCSVファイルは選択した列順にソートされ、未選択列はアルファベット順に並びます。 - - **Max Records**：集約がトリガーされる最大レコード数を設定します。例えば `1000` に設定すると、1000 レコード収集後にアップロードされます。最大レコード数に達すると単一ファイルの集約が完了しアップロードされ、時間間隔がリセットされます。 + - **Max Records**：集約がトリガーされる最大レコード数を設定します。例えば`1000`に設定すると、1000レコード収集後にアップロードされます。最大レコード数到達時に単一ファイルの集約が完了しアップロードされ、時間間隔がリセットされます。 - - **Time Interval**：集約が行われる時間間隔（秒）を設定します。例えば `60` に設定すると、最大レコード数に達していなくても 60 秒ごとにデータがアップロードされ、最大レコード数がリセットされます。 + - **Time Interval**：集約が行われる時間間隔（秒）を設定します。例えば`60`に設定すると、最大レコード数に達していなくても60秒ごとにデータがアップロードされ、最大レコード数がリセットされます。 -10. **フォールバックアクション（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義できます。これらはプライマリ Sink がメッセージ処理に失敗した場合にトリガーされます。詳細は [Fallback Actions](./data-bridges.md#fallback-actions) を参照してください。 +10. **フォールバックアクション（任意）**：メッセージ配信失敗時の信頼性向上のため、1つ以上のフォールバックアクションを定義可能です。プライマリSinkがメッセージ処理に失敗した場合にこれらのアクションがトリガーされます。詳細は[フォールバックアクション](./data-bridges.md#fallback-actions)を参照してください。 -11. **Advanced Settings** を展開し、必要に応じて詳細設定を行います（任意）。詳細は [Advanced Settings](#advanced-settings) を参照してください。 +11. **高度な設定**を展開し、必要に応じて設定を調整します（任意）。詳細は[高度な設定](#advanced-settings)を参照してください。 -12. 残りの設定はデフォルト値のままにし、**Create** ボタンをクリックして Sink 作成を完了します。作成成功後、ルール作成画面に戻り、新しい Sink がルールアクションに追加されます。 +12. 残りの設定はデフォルト値を使用し、**Create**ボタンをクリックしてSink作成を完了します。作成成功後はルール作成画面に戻り、新規Sinkがルールアクションに追加されます。 -13. ルール作成画面で **Create** ボタンをクリックし、ルール作成全体を完了します。 +13. ルール作成画面で**Create**ボタンをクリックし、ルール作成全体を完了します。 -これでルールの作成が完了しました。**Rules** ページで新規作成したルールを確認でき、**Actions (Sink)** タブで新しい Snowflake Sink を確認できます。 +これでルールが正常に作成されました。**Rules**ページで新規ルールを確認でき、**Actions (Sink)**タブで新規Snowflake Sinkを確認できます。 -また、**Integration** -> **Flow Designer** をクリックするとトポロジーを視覚的に確認できます。トポロジーは、トピック `t/#` のメッセージがルール `my_rule` によって解析され、Snowflake に書き込まれる流れを示します。 +また、**Integration** -> **Flow Designer**をクリックするとトポロジーが表示され、トピック`t/#`のメッセージがルール`my_rule`で解析されSnowflakeに書き込まれる流れを視覚的に確認できます。 ## ルールのテスト @@ -292,44 +370,44 @@ Snowflake Sink を追加する前に、EMQX で Snowflake への接続を確立 ### テストメッセージのパブリッシュ -MQTTX を使ってトピック `t/1` にメッセージをパブリッシュします： +MQTTXを使用してトピック`t/1`にメッセージをパブリッシュします： ```bash mqttx pub -i emqx_c -t t/1 -m '{ "msg": "Hello Snowflake" }' ``` -この操作を数回繰り返して複数のテストメッセージを生成してください。 +複数回繰り返して複数のテストメッセージを生成してください。 -### Snowflake 内のデータ確認 +### Snowflake内のデータ確認 -テストメッセージ送信後、Snowflake にデータが正常に書き込まれたかを確認します。 +テストメッセージ送信後、Snowflakeにデータが正常に書き込まれたかを確認します。 -1. Snowflake のウェブインターフェースを開き、認証情報で Snowflake コンソールにログインします。 +1. SnowflakeのWebインターフェースを開き、認証情報でSnowflakeコンソールにログインします。 -2. Snowflake コンソールで以下の SQL クエリを実行し、ルールによって書き込まれた `emqx` テーブルのデータを表示します： +2. コンソールで以下のSQLクエリを実行し、ルールによって書き込まれた`emqx`テーブルのデータを確認します： ``` SELECT * FROM testdatabase.public.emqx; ``` - これにより、`emqx` テーブルにアップロードされたすべてのレコードが表示され、`clientid`、`topic`、`payload`、`publish_received_at` フィールドを確認できます。 + これにより`emqx`テーブルにアップロードされたすべてのレコードが表示され、`clientid`、`topic`、`payload`、`publish_received_at`フィールドを確認できます。 -3. 送信したテストメッセージ（例：`{ "msg": "Hello Snowflake" }`）や、トピック、タイムスタンプなどのメタデータが確認できるはずです。 +3. 送信したテストメッセージ（例：`{ "msg": "Hello Snowflake" }`）やトピック、タイムスタンプなどのメタデータが表示されているはずです。 -## 詳細設定 +## 高度な設定 -このセクションでは、Snowflake Sink の詳細設定オプションについて説明します。ダッシュボードで Sink を設定する際、**Advanced Settings** を展開して以下のパラメータをニーズに応じて調整できます。 +このセクションでは、Snowflake Sinkの高度な設定オプションについて説明します。ダッシュボードのSink設定画面で**Advanced Settings**を展開し、必要に応じて以下のパラメータを調整できます。 -| フィールド名 | 説明 | デフォルト値 | -| -------------------------- | ------------------------------------------------------------------------------------------------ | -------------- | -| **Max Retries** | アップロード失敗時の最大リトライ回数を設定します。例えば `3` を入力すると3回までリトライします。 | `3` | -| **Buffer Pool Size** | バッファワーカープロセスの数を指定します。これらのワーカーは EMQX と Snowflake 間のデータフローを管理し、一時的にデータを保持・処理します。パフォーマンス最適化とスムーズなデータ送信に重要です。 | `16` | -| **Request TTL** | リクエストの有効期間（秒）を設定します。リクエストがバッファに入ってからの最大有効時間を指定し、この期間を超えたリクエストは期限切れとみなされます。レスポンスやアックがタイムリーに返らない場合も期限切れとなります。 | | -| **Health Check Interval** | Snowflake との接続の自動ヘルスチェックを行う間隔（秒）を指定します。 | `15` | -| **Max Buffer Queue Size** | Snowflake Sink の各バッファワーカーが保持可能な最大バイト数を指定します。バッファワーカーはデータを一時保管し、効率的にデータストリームを処理します。システム性能やデータ送信要件に応じて調整してください。 | `256` | -| **Query Mode** | リクエストモードを `synchronous` または `asynchronous` から選択し、メッセージ送信を最適化します。非同期モードでは Snowflake への書き込みが MQTT メッセージのパブリッシュをブロックしませんが、クライアントがメッセージ到達前に受信する可能性があります。 | `Asynchronous` | -| **Batch Size** | EMQX から Snowflake へ一度に送信するデータバッチの最大サイズを指定します。サイズ調整によりデータ転送の効率と性能を微調整できます。
`1` に設定すると、データレコードを個別に送信し、バッチ化しません。 | `1` | -| **Inflight Window** | "インフライトキューリクエスト" は開始済みでまだレスポンスやアックを受け取っていないリクエストを指します。この設定は Snowflake との通信中に同時に存在可能なインフライトリクエストの最大数を制御します。
**Request Mode** が `asynchronous` の場合、同一 MQTT クライアントからのメッセージを厳密に順序処理したい場合はこの値を `1` に設定してください。 | `100` | -| **Connect Timeout** | Snowflake への接続試行時のタイムアウト時間（秒）を指定します。例えば `30` 秒に設定すると、その時間内に接続できなければリトライ（**Max Retries** に基づく）またはエラーを発生させます。ネットワークレイテンシや接続信頼性管理に役立ちます。 | `15` | -| **HTTP Pipelining** | レスポンス待ちをせずに送信可能な HTTP リクエストの最大数を指定します。 | `100` | -| **Connection Pool Size** | EMQX が Snowflake に同時に維持可能な接続数を定義します。大きいほど同時リクエスト数が増え高負荷に対応可能ですが、システムリソース消費も増加します。 | `8` | +| 項目名 | 説明 | デフォルト値 | +| ------------------------ | -------------------------------------------------------------------------------------------------------- | ------------- | +| **Max Retries** | アップロード失敗時の最大リトライ回数を設定します。例：`3`で3回までリトライ可能。 | `3` | +| **Buffer Pool Size** | EMQXとSnowflake間のデータフローを管理するバッファワーカーの数を指定します。これらのワーカーはデータを一時的に保持・処理し、パフォーマンス最適化とスムーズなデータ送信に重要です。 | `16` | +| **Request TTL** | バッファに入ったリクエストが有効とみなされる最大時間（秒）を指定します。TTLを超えるか、Snowflakeからの応答やアックがタイムリーに得られない場合、リクエストは期限切れと見なされます。 | | +| **Health Check Interval** | Snowflakeとの接続状態を自動的にヘルスチェックする間隔（秒）を指定します。 | `15` | +| **Max Buffer Queue Size** | Snowflake Sinkの各バッファワーカーがバッファリング可能な最大バイト数を指定します。バッファワーカーはデータを一時保持し、効率的にデータストリームを処理します。システム性能やデータ送信要件に応じて調整してください。 | `256` | +| **Query Mode** | `synchronous`（同期）または`asynchronous`（非同期）リクエストモードを選択し、メッセージ送信を最適化します。非同期モードではSnowflakeへの書き込みがMQTTメッセージパブリッシュをブロックしませんが、クライアントがSnowflake到着前にメッセージを受信する可能性があります。 | `Asynchronous` | +| **Batch Size** | EMQXからSnowflakeへ一度に転送するデータバッチの最大サイズを指定します。サイズ調整により転送効率と性能を最適化可能です。
`1`に設定すると、データレコードはバッチ化せず個別に送信されます。 | `1` | +| **Inflight Window** | 送信済みだが応答やアックをまだ受け取っていない「インフライト」キューリクエストの最大数を制御します。
`Request Mode`が`asynchronous`の場合に特に重要です。同一MQTTクライアントからのメッセージを厳密に順序処理する必要がある場合は`1`に設定してください。 | `100` | +| **Connect Timeout** | Snowflakeへの接続試行がタイムアウトするまでの待機時間（秒）を指定します。例：`30`秒。接続できない場合、**Max Retries**に基づきリトライまたはエラーを返します。ネットワークレイテンシや接続信頼性管理に有用です。 | `15` | +| **HTTP Pipelining** | 応答待ち前に送信可能なHTTPリクエストの最大数を指定します。 | `100` | +| **Connection Pool Size** | EMQXがSnowflakeに同時に維持可能な接続数を定義します。大きいほど高負荷時に多くのリクエストを並行処理可能ですが、システムリソース消費も増加します。 | `8` | diff --git a/ja_JP/last_translation_commit b/ja_JP/last_translation_commit index f7b95ede3..c5db755f1 100644 --- a/ja_JP/last_translation_commit +++ b/ja_JP/last_translation_commit @@ -1 +1 @@ -c55404f5618e14f7e22283490c620bc71fe5cb6c +4e392a24a592aef8c84f5041d9848b6fde29d870 diff --git a/ja_JP/observability/opentelemetry/assets/e2e-dashboard-conf-en.png b/ja_JP/observability/opentelemetry/assets/e2e-dashboard-conf-en.png new file mode 100644 index 000000000..119d9bdbd Binary files /dev/null and b/ja_JP/observability/opentelemetry/assets/e2e-dashboard-conf-en.png differ diff --git a/ja_JP/observability/opentelemetry/e2e-traces.md b/ja_JP/observability/opentelemetry/e2e-traces.md index 0f8030741..63717e12e 100644 --- a/ja_JP/observability/opentelemetry/e2e-traces.md +++ b/ja_JP/observability/opentelemetry/e2e-traces.md @@ -1,100 +1,124 @@ # OpenTelemetryベースのエンドツーエンドMQTTトレーシング -現代の分散システムにおいて、リクエストの流れを追跡しパフォーマンスを分析することは、信頼性と可観測性を確保するために不可欠です。エンドツーエンドトレーシングは、リクエストの開始から終了までの全経路をキャプチャすることを目的とした概念であり、システムの挙動やパフォーマンスに関する深い洞察を得ることができます。 +現代の分散システムにおいて、リクエストの流れを追跡しパフォーマンスを分析することは、信頼性と可観測性を確保するために不可欠です。エンドツーエンドトレーシングは、リクエストの開始から終了までの全経路をキャプチャすることを目的とした概念であり、システムの挙動やパフォーマンスに関する深い洞察を得ることを可能にします。 -EMQXはバージョン5.8.3以降、MQTTプロトコルに特化したOpenTelemetryベースのエンドツーエンドトレーシング機能を統合しています。この機能により、特にマルチノードクラスター環境において、メッセージのパブリッシュ、ルーティング、配信を明確にトレースできます。これにより、システムパフォーマンスの最適化だけでなく、迅速な障害箇所の特定やシステム信頼性の向上にも役立ちます。 +EMQXはバージョン5.8.3以降、MQTTプロトコルに特化したOpenTelemetryベースのエンドツーエンドトレーシング機能を統合しています。この機能により、特にマルチノードクラスター環境において、メッセージのパブリッシュ、ルーティング、配信の流れを明確にトレースできます。これにより、システムパフォーマンスの最適化だけでなく、迅速な障害箇所の特定やシステムの信頼性向上にも寄与します。 -本ページでは、MQTTメッセージのフローを包括的に可視化するために、EMQXでエンドツーエンドトレーシング機能を有効化する方法を詳しく解説します。 +本ページでは、MQTTメッセージのフローを包括的に可視化するためのEMQXにおけるエンドツーエンドトレーシング機能の有効化手順を詳しく解説します。 ## OpenTelemetry Collectorのセットアップ 設定の詳細については、[OpenTelemetry Collectorのセットアップ](./traces.md#setting-up-opentelemetry-collector)を参照してください。 -## EMQXでエンドツーエンドトレーシングを有効化する +## EMQXでのエンドツーエンドトレーシングの有効化 ::: tip -エンドツーエンドトレーシングはシステムパフォーマンスに影響を与える可能性があるため、必要な場合のみ有効化してください。 +エンドツーエンドトレーシングはシステムパフォーマンスに影響を与える可能性があるため、必要な場合にのみ有効化してください。 ::: -このセクションでは、EMQXでOpenTelemetryベースのエンドツーエンドトレーシングを有効化する手順と、マルチノード環境でのMQTT分散トレーシング機能のデモを紹介します。 +本節では、EMQXでOpenTelemetryベースのエンドツーエンドトレーシングを有効化する方法を案内し、マルチノード構成におけるMQTT分散トレーシング機能を紹介します。 ### ダッシュボードからエンドツーエンドトレーシングを設定する -1. ダッシュボードの左メニューから **Management** -> **Monitoring** をクリックします。 -2. Monitoringページで **Integration** タブを選択します。 -3. 以下の設定を行います： - - **Monitoring platform**: `OpenTelemetry` を選択します。 - - **Feature Selection**: `Traces` を選択します。 - - **Endpoint**: トレースデータのエクスポート先アドレスを設定します。デフォルトは `http://localhost:4317` です。 - - **Enable TLS**: 必要に応じてTLS暗号化を有効にします。通常、本番環境のセキュリティ要件に合わせて設定します。 - - **Trace Mode**: `End-to-End` を選択し、エンドツーエンドトレーシング機能を有効化します。 - - **Cluster Identifier**: span属性に追加するプロパティ値を設定し、どのEMQXクラスターからのデータかを識別できるようにします。プロパティキーは `cluster.id` です。通常はシンプルで識別しやすい名前やクラスター名を設定します。デフォルトは `emqxcl` です。 - - **Traces Export Interval**: トレースデータのエクスポート間隔を秒単位で設定します。デフォルトは `5` 秒です。 - - **Max Queue Size**: トレースデータキューの最大サイズを設定します。デフォルトは `2048` エントリです。 +1. ダッシュボードの左メニューから **Management** -> **Monitoring** をクリックします。 -4. 必要に応じて **Trace Advanced Configuration** をクリックし、詳細設定を行います。 +2. Monitoringページの **Integration** タブを選択します。 - - **Trace Configuration**: クライアント接続やメッセージ送受信、ルールエンジンの実行など、特定イベントのトレース有無を設定できます。 - - **Follow Traceparent**: `traceparent` を追跡するかどうかを設定します。`true` に設定すると、EMQXはクライアントから送信された `User-Property` 内の `traceparent` 識別子を取得し、エンドツーエンドトレーシングに紐付けます。`false` の場合は新規トレースを生成します。デフォルトは `true` です。 - - **Client ID White List**: トレース対象とするクライアント接続やメッセージを制限するホワイトリストを設定できます。不要なトレースを避け、システムリソースの消費を抑制できます。 - - **Topic White List**: トピックのホワイトリストを設定し、マッチするトピックのみをトレース対象とします。クライアントホワイトリストと同様にトレース範囲の制御に役立ちます。 +3. 以下の設定を行います： + - **Monitoring platform**：`OpenTelemetry` を選択します。 - 設定後、**Confirm** をクリックして設定を保存しウィンドウを閉じます。 + - **Feature Selection**：`Traces` を選択します。 -5. **Save Changes** をクリックして設定を保存します。 + - **Endpoint**：トレースデータのエクスポート先アドレスを設定します。デフォルトは `http://localhost:4317` です。 -OpenTelemetryエンドツーエンドトレーシング ダッシュボード設定画面 + - **Headers**：トレースエクスポートリクエストにカスタムHTTPヘッダーを追加します。OpenTelemetry Collectorが認証やAPIキー、トークンなどのカスタムヘッダーを必要とする場合に使用します。各ヘッダーはキーと値のペアで指定してください。 + + OpenTelemetry CollectorがBasic認証を使用している場合は、`authorization` ヘッダーに以下の形式で値を設定する必要があります： + `Basic ` + + 例： + ``` + Key: authorization + Value: Basic dXNlcjpwYXNzd29yZA== + ``` + + この設定により、HTTPベースの認証を強制するCollectorとの互換性が向上します。 + + - **Enable TLS**：必要に応じてTLS暗号化を有効にします。通常は本番環境のセキュリティ要件に応じて設定します。 + + - **Trace Mode**：`End-to-End` を選択し、エンドツーエンドトレーシング機能を有効にします。 + + - **Cluster Identifier**：span属性にクラスタ識別用のプロパティ値を追加します。プロパティキーは `cluster.id` です。EMQXクラスターを識別しやすいシンプルな名前やクラスター名を設定してください。デフォルトは `emqxcl` です。 + + - **Traces Export Interval**：トレースデータのエクスポート間隔を秒単位で設定します。デフォルトは `5` 秒です。 + + - **Max Queue Size**：トレースデータのキュー最大サイズを設定します。デフォルトは `2048` エントリです。 + +4. 必要に応じて **Trace Advanced Configuration** をクリックし、高度な設定を行います。 + + - **Trace Configuration**：クライアント接続、メッセージ送受信、ルールエンジンの実行など、特定のイベントをトレースするかどうかの追加オプションを設定します。 + - **Follow Traceparent**：`traceparent` を追従するかどうかを設定します。`true` に設定すると、EMQXはクライアントから送信された `User-Property` 内の `traceparent` 識別子を取得し、それに紐づけてエンドツーエンドトレーシングを行います。`false` の場合は新規トレースを生成します。デフォルトは `true` です。 + - **Client ID White List**：トレース対象とするクライアント接続やメッセージを制限するホワイトリストを設定します。不要なトレースを避け、システムリソースの消費を抑制できます。 + - **Topic White List**：トピックのホワイトリストを設定し、マッチするトピックのみをトレース対象にします。クライアントホワイトリストと同様にトレーシング範囲の制御に役立ちます。 + + 設定を保存後、**Confirm** をクリックしてウィンドウを閉じます。 + +5. 最後に **Save Changes** をクリックして設定を保存します。 + +Otel-E2E-Trace-dashboard-page ### 設定ファイルからエンドツーエンドトレーシングを設定する -EMQXがローカルで稼働している前提で、`cluster.hocon` ファイルに以下の設定を追加します。 +EMQXがローカルで稼働している場合、`cluster.hocon` ファイルに以下の設定を追加します。 -設定オプションの詳細は、[EMQXダッシュボード監視統合のOpenTelemetry項目](http://localhost:18083/#/monitoring/integration)を参照してください。 +設定オプションの詳細は、[EMQXダッシュボード監視統合](http://localhost:18083/#/monitoring/integration)のOpenTelemetryセクションを参照してください。 ```bash opentelemetry { - exporter { endpoint = "http://localhost:4317" } + exporter { + endpoint = "http://localhost:4317" + headers { + authorization = ""Basic dXNlcjpwYXNzd29yZA==" + } + } traces { - enable = true - # エンドツーエンドトレーシングモード - trace_mode = e2e - # エンドツーエンドトレーシングオプション - e2e_tracing_options { - ## クライアント接続/切断イベントをトレース - client_connect_disconnect = true - ## クライアントのサブスクライブ/アンインサブスクライブイベントをトレース - client_subscribe_unsubscribe = true - ## クライアントのメッセージングイベントをトレース - client_messaging = true - ## ルールエンジンの実行をトレース - trace_rule_engine = true - ## クライアントIDホワイトリストの最大長 - clientid_match_rules_max = 30 - ## トピックフィルターホワイトリストの最大長 - topic_match_rules_max = 30 - ## クラスター識別子 - cluster_identifier = emqxcl - ## メッセージトレースレベル（QoS） - msg_trace_level = 2 - ## ホワイトリスト外イベントのサンプリング率 - ## 注：トレースが有効な場合のみサンプリングが適用されます - sample_ratio = "100%" - ## traceparentの追跡 - ## クライアントから渡された`traceparent`をエンドツーエンドトレーシングで追跡するか - follow_traceparent + enable = true + # エンドツーエンドトレーシングモード + trace_mode = e2e + # エンドツーエンドトレーシングオプション + e2e_tracing_options { + ## クライアント接続/切断イベントのトレース + client_connect_disconnect = true + ## クライアントメッセージ送受信イベントのトレース + client_messaging = true + ## クライアントのサブスクライブ/アン・サブスクライブイベントのトレース + client_subscribe_unsubscribe = true + ## クライアントIDホワイトリストの最大長 + clientid_match_rules_max = 30 + ## トピックフィルターホワイトリストの最大長 + topic_match_rules_max = 30 + ## クラスター識別子 + cluster_identifier = emqxcl + ## メッセージトレースレベル（QoS） + msg_trace_level = 2 + ## ホワイトリスト外イベントのサンプリング率 + ## 注意：トレースが有効な場合のみサンプリングが適用されます + sample_ratio = "100%" + ## traceparentの追従 + ## クライアントから渡された `traceparent` をエンドツーエンドトレーシングで追従するかどうか + follow_traceparent } } max_queue_size = 50000 scheduled_delay = 1000 - } } ``` -## EMQXでのエンドツーエンドトレーシングのデモ +## EMQXでのエンドツーエンドトレーシングの実演 -1. EMQXノードを起動します。例として、`emqx@172.19.0.2` と `emqx@172.19.0.3` の2ノードクラスターを起動し、分散トレーシング機能をデモします。 +1. EMQXノードを起動します。例として、`emqx@172.19.0.2` と `emqx@172.19.0.3` の2ノードクラスターを起動し、分散トレーシング機能を実演します。 2. MQTTX CLIをクライアントとして使用し、異なるノードで同じトピックをサブスクライブします。 @@ -112,7 +136,7 @@ opentelemetry { 3. 約5秒後（EMQXのトレースデータエクスポートのデフォルト間隔）、[http://localhost:16686](http://localhost:16686/) のJaeger WEB UIにアクセスし、トレースデータを確認します。 - `emqx` サービスを選択し、**Find Traces** をクリックします。`emqx` サービスがすぐに表示されない場合は、少し待ってページを更新してください。クライアント接続およびサブスクライブイベントのトレースが確認できます： + `emqx` サービスを選択し、**Find Traces** をクリックします。`emqx` サービスがすぐに表示されない場合は、しばらく待ってページを更新してください。クライアントの接続やサブスクライブイベントのトレースが表示されます： ![Jaeger-WEB-UI-e2e-Client-Events](./assets/e2e-client-events.png) @@ -124,34 +148,34 @@ opentelemetry { 5. 少し待つと、Jaeger WEB UIでMQTTメッセージの詳細なトレースが確認できます。 - トレースをクリックすると、詳細なspan情報とトレースタイムラインが表示されます。サブスクライバー数、ノード間のメッセージルーティング、QoSレベル、`msg_trace_level` 設定により、MQTTメッセージのトレースに含まれるspan数は異なります。 + トレースをクリックすると、詳細なspan情報とトレースタイムラインが表示されます。サブスクライバー数、ノード間のメッセージルーティング、QoSレベル、`msg_trace_level` の設定により、MQTTメッセージトレースに含まれるspan数は異なります。 - 以下は、2クライアントがQoS 2でサブスクライブし、パブリッシャーがQoS 2のメッセージを送信、`msg_trace_level` が2に設定されている場合のトレースタイムラインとspan情報の例です。 + 以下は、2つのクライアントがQoS 2でサブスクライブし、パブリッシャーがQoS 2のメッセージを送信、`msg_trace_level` が2に設定されている場合のトレースタイムラインとspan情報の例です。 - 特に、クライアント `mqttx_9137a6bb` がパブリッシャーとは異なるEMQXノードに接続しているため、ノード間の送信を表す2つの追加span（`message.forward` と `message.handle_forward`）が表示されています。 + 特に、クライアント `mqttx_9137a6bb` はパブリッシャーとは異なるEMQXノードに接続されているため、ノード間の送信を表す2つの追加span（`message.forward` と `message.handle_forward`）が表示されています。 ![Jaeger-WEB-UI-e2e-Message](./assets/e2e-message.png) - また、メッセージやイベントがルールエンジンの実行をトリガーする場合、ルールエンジンのトラッキングオプションが有効であれば、ルールおよびアクションの実行トラッキング情報も取得可能です。 + また、メッセージやイベントがルールエンジンの実行をトリガーする場合、ルールエンジンのトレースオプションが有効であれば、ルールおよびアクションの実行トレース情報も取得可能です。 ![Jaeger-WEB-UI-e2e-With-Rule-Engine](./assets/e2e-with-rule-engine.png) ::: tip - ルールエンジンの実行を含むエンドツーエンドトレーシング機能は、EMQXバージョン5.9.0以降でサポートされています。 + ルールエンジン実行を含むエンドツーエンドトレーシング機能は、EMQXバージョン5.9.0以降でサポートされています。 ::: ::: warning 重要なお知らせ - この機能は慎重に有効化してください。メッセージやイベントが複数のルールやアクションをトリガーすると、単一のトレースで大量のspanが生成され、システム負荷が増加します。 - メッセージ量やルール・アクション数に応じて適切なサンプリング率を見積もってください。 + この機能は慎重に有効化してください。メッセージやイベントが複数のルールやアクションをトリガーすると、1つのトレースで大量のspanが生成され、システム負荷が増加します。 + メッセージ量やルール・アクション数に基づき、適切なサンプリング率を見積もってください。 ::: -## トレースspanのオーバーロード管理 +## トレースspanの過負荷管理 -EMQXはトレースspanを蓄積し、定期的にバッチでエクスポートします。エクスポート間隔は `opentelemetry.trace.scheduled_delay` パラメータで制御され、デフォルトは5秒です。バッチトレースspanプロセッサにはオーバーロード保護機能があり、最大蓄積数（デフォルト2048span）を超えると新規spanは破棄されます。以下の設定でこの制限を調整可能です。 +EMQXはトレースspanを蓄積し、定期的にバッチでエクスポートします。エクスポート間隔は `opentelemetry.trace.scheduled_delay` パラメータで制御され、デフォルトは5秒です。バッチトレースspanプロセッサには過負荷保護機能があり、蓄積可能なspan数の上限（デフォルトは2048span）を超えると新規spanは破棄されます。この上限は以下の設定で調整可能です： ```yaml opentelemetry { @@ -164,12 +188,12 @@ opentelemetry { `max_queue_size` の上限に達すると、現在のキューがエクスポートされるまで新規トレースspanは破棄されます。 -::: tip 補足 +::: tip 注意 -トレース対象メッセージが多数のサブスクライバーに配信される場合や、メッセージ量が多くサンプリング率が高い場合、オーバーロード保護により多くのspanが破棄され、エクスポートされるspanはごく一部になる可能性があります。 +トレース対象のメッセージが多数のサブスクライバーに配信される場合や、メッセージ量が多くサンプリング率が高い場合、過負荷保護により多くのspanが破棄され、エクスポートされるspanはごく一部になる可能性があります。 -エンドツーエンドトレーシングモードでは、メッセージ量やサンプリング率に応じて `max_queue_size` を増やし、`scheduled_delay` を短縮してspanのエクスポート頻度を上げることを検討してください。これによりオーバーロード保護によるspanの損失を抑制できます。 +エンドツーエンドトレーシングモードでは、メッセージ量やサンプリング率に応じて `max_queue_size` を増やし、`scheduled_delay` を短縮してspanのエクスポート頻度を上げることを検討してください。これにより過負荷保護によるspanの損失を防止できます。 -**ただし、エクスポート頻度の増加やキューサイズの拡大はシステムリソース消費を増加させるため、メッセージTPSや利用可能なシステムリソースを十分に見積もった上で適切に設定してください。** +**ただし、エクスポート頻度の増加やキューサイズの拡大はシステムリソース消費の増加を招くため、メッセージTPSや利用可能なシステムリソースを十分に見積もった上で適切な設定を適用してください。** ::: diff --git a/ja_JP/observability/opentelemetry/logs.md b/ja_JP/observability/opentelemetry/logs.md index c38f0624c..a0c8dccd0 100644 --- a/ja_JP/observability/opentelemetry/logs.md +++ b/ja_JP/observability/opentelemetry/logs.md @@ -1,11 +1,12 @@ -# OpenTelemetryを使ったログ管理の統合 -ファイルログと同様に、OpenTelemetryログは重要なイベント、ステータス情報、エラーメッセージを記録し、開発者や運用チームがアプリケーションの動作を理解しトラブルシューティングを行うのに役立ちます。ただし、OpenTelemetryログは標準化されたログフォーマットを採用しているため、ログの解析や分析、処理が容易です。さらに、Trace ID、タグ、属性などの豊富なコンテキスト情報をログに付加できる点も特徴です。 +# OpenTelemetryを統合したログ管理 -本ページでは、EMQXとOpenTelemetryログハンドラーを統合して高度なログ管理を実現する方法を詳しく解説します。OpenTelemetry Collectorのセットアップ、EMQXでのOpenTelemetryログハンドラーの設定およびログのエクスポート方法、ログ過負荷の管理について説明します。この統合により、EMQXのログイベントを[OpenTelemetryログデータモデル](https://opentelemetry.io/docs/specs/otel/logs/data-model/)に準拠した形式で出力し、設定したOpenTelemetry Collectorやバックエンドにエクスポートできるため、監視やデバッグの効率が向上します。 +ファイルログと同様に、OpenTelemetryログは重要なイベント、ステータス情報、エラーメッセージを記録し、開発者や運用チームがアプリケーションの動作を理解しトラブルシューティングを行うのに役立ちます。ただし、OpenTelemetryログは標準化されたログフォーマットを採用しているため、ログの解析、分析、処理が容易になる点が異なります。さらに、OpenTelemetryログはTrace ID、タグ、属性などの豊富なコンテキスト情報をレコードに追加できることも特徴です。 + +本ページでは、EMQXにOpenTelemetryログハンドラーを統合して高度なログ管理を実現するための包括的なガイドを提供します。OpenTelemetry Collectorのセットアップ、EMQXでのOpenTelemetryログハンドラーの設定およびログのエクスポート方法、ログの過負荷管理について説明します。この統合により、EMQXのログイベントを[OpenTelemetryログデータモデル](https://opentelemetry.io/docs/specs/otel/logs/data-model/)に準拠した形式でフォーマットし、設定済みのOpenTelemetry Collectorやバックエンドシステムにエクスポートできるため、監視やデバッグ機能が向上します。 ## OpenTelemetry Collectorのセットアップ -EMQXのOpenTelemetryログを有効にする前に、OpenTelemetry CollectorおよびOpenTelemetry対応のログ収集システムをデプロイし設定する必要があります。本ガイドでは、[OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started)のデプロイ方法と、debugエクスポーターを使ってログを`stdout`にリダイレクトする設定手順を説明します。 +EMQXでOpenTelemetryログを有効にする前に、OpenTelemetry CollectorおよびOpenTelemetry対応のログ収集システムをデプロイし設定する必要があります。本ガイドでは、[OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started)のデプロイと、デバッグエクスポーターを用いてログを`stdout`にリダイレクトする設定方法を説明します。 1. `otel-logs-collector-config.yaml`という名前でOpenTelemetry Collectorの設定ファイルを作成します。 @@ -63,20 +64,25 @@ EMQXのOpenTelemetryログを有効にする前に、OpenTelemetry Collectorお ## EMQXでOpenTelemetryログハンドラーを有効化 -1. EMQXの`cluster.hocon`ファイルに以下の設定を追加します（EMQXがローカルで動作している想定です）。 +1. EMQXがローカルで動作している前提で、`cluster.hocon`ファイルに以下の設定を追加します。 ```bash opentelemetry { - exporter {endpoint = "http://localhost:4317"} + exporter { + endpoint = "http://localhost:4317" + headers { + authorization = ""Basic dXNlcjpwYXNzd29yZA==" + } + } logs {enable = true, level = warning} } ``` または、ダッシュボードの **Management** -> **Monitoring** にある **Integration** タブからOpenTelemetryログ統合を設定することも可能です。 - ::: tip 補足 + ::: tip 注意 - `opentelemetry.logs.level`の設定は、[EMQXログハンドラー](../../observability/log.md)で設定されたデフォルトのログレベルにより上書きされます。例えば、OpenTelemetryのログレベルが`info`でも、EMQXのコンソールログレベルが`error`の場合は、`error`以上のレベルのイベントのみがエクスポートされます。 + `opentelemetry.logs.level` の設定は、[EMQXログハンドラー](../../observability/log.md)で設定されたデフォルトのログレベルによって上書きされます。例えば、OpenTelemetryのログレベルが`info`でも、EMQXのコンソールログレベルが`error`の場合は、`error`以上のレベルのイベントのみがエクスポートされます。 ::: @@ -86,15 +92,15 @@ EMQXのOpenTelemetryログを有効にする前に、OpenTelemetry Collectorお Otel-logs-HTTP-bridge-example -4. 数秒以内（デフォルトは約1秒）に、Otel CollectorがHTTPブリッジ接続失敗などのEMQXログイベントを受信していることを確認できます。 +4. しばらくすると（デフォルトで約1秒後）、Otel CollectorにHTTPブリッジ接続失敗などのEMQXログイベントが表示されます。 ![Otel-collector-logs-debug-output](./assets/otel-collector-logs-debug-output.png) ## ログ過負荷の管理 -EMQXはログイベントを蓄積し、一定間隔でバッチ処理としてエクスポートします。 -このエクスポートの頻度は`opentelemetry.logs.scheduled_delay`パラメータで制御され、デフォルトは1秒です。 -バッチ処理のログハンドラーは過負荷保護機構を備えており、蓄積できるイベント数に上限を設けています。デフォルトの上限は2048件です。以下の設定でこの上限を変更できます。 +EMQXはログイベントを蓄積し、定期的にバッチでエクスポートします。 +このエクスポート頻度は`opentelemetry.logs.scheduled_delay`パラメータで制御され、デフォルトは1秒です。 +バッチングログハンドラーには過負荷保護機構が組み込まれており、蓄積できるイベント数の上限が設定されています。デフォルトは2048件です。以下の設定でこの上限を変更可能です。 ```bash opentelemetry { @@ -104,9 +110,8 @@ opentelemetry { `max_queue_size`の上限に達すると、新しいログイベントは現在のキューがエクスポートされるまで破棄されます。 -::: tip 補足 +::: tip 注意 OpenTelemetryログの過負荷保護は、デフォルトの[EMQXログハンドラー](../log.md)の過負荷保護とは独立して動作します。 -そのため、設定によっては同じログイベントがOpenTelemetryハンドラーで破棄される一方、EMQXのデフォルトログハンドラーでは記録される場合や、その逆もあり得ます。 - +そのため、設定によっては同じログイベントがOpenTelemetryハンドラーで破棄され、デフォルトのEMQXログハンドラーでは記録される、またはその逆が発生することがあります。 ::: diff --git a/ja_JP/observability/opentelemetry/metrics.md b/ja_JP/observability/opentelemetry/metrics.md index 233044f34..9c08baafc 100644 --- a/ja_JP/observability/opentelemetry/metrics.md +++ b/ja_JP/observability/opentelemetry/metrics.md @@ -1,14 +1,14 @@ # OpenTelemetryを統合してメトリクスを表示する -EMQXは、gRPC OTELプロトコルを介してメトリクスを直接OpenTelemetry Collectorにプッシュする機能を標準でサポートしています。Collectorはデータを任意のバックエンドにルーティング、フィルタリング、変換し、保存および可視化が可能です。 +EMQXは、gRPC OTELプロトコルを介してメトリクスを直接OpenTelemetry Collectorにプッシュする機能を標準でサポートしています。Collectorはその後、データを任意のバックエンドにルーティング、フィルタリング、変換して保存および可視化を行います。 -本ページでは、EMQXとOpenTelemetryの統合方法をダッシュボードを通じて紹介し、[Prometheus](../../observability/prometheus.md)でEMQXのメトリクスを表示する方法を説明します。 +このページでは、EMQXとOpenTelemetryをダッシュボードを通じて統合し、[Prometheus](../../observability/prometheus.md)でEMQXのメトリクスを表示する方法を紹介します。 ## 前提条件 -OpenTelemetryとの統合を行う前に、OpenTelemetryとPrometheusをデプロイおよび設定しておく必要があります。 +OpenTelemetryとの統合を行う前に、OpenTelemetryおよびPrometheusをデプロイして設定する必要があります。 - [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started)をデプロイします。 -- CollectorのgRPC受信ポート（デフォルトは4317）とPrometheusメトリクスエクスポートポート（8889）を設定します。 +- CollectorのgRPC受信ポート（デフォルトは4317）およびPrometheusメトリクスエクスポートポート（8889）を設定します。 ```yaml # otel-collector-config.yaml @@ -33,7 +33,7 @@ service: ``` - [Prometheus](https://prometheus.io/docs/prometheus/latest/installation)をデプロイします。 -- Prometheusを設定し、Collectorが収集したメトリクスをスクレイプするようにします。 +- PrometheusがCollectorで収集されたメトリクスをスクレイプするよう設定します。 ```yaml # prometheus.yaml @@ -47,13 +47,18 @@ scrape_configs: ## EMQXでOpenTelemetryメトリクスを有効化する -EMQXのOpenTelemetryメトリクス機能との統合は、EMQXダッシュボードまたは設定ファイルで行えます。ダッシュボードでは、左側のナビゲーションメニューから **Management** -> **Monitoring** をクリックし、**Integration** タブでメトリクスの設定を行います。 +EMQXのOpenTelemetryメトリクス機能との統合は、EMQXダッシュボードまたは設定ファイルで行えます。EMQXダッシュボードでは、左のナビゲーションメニューから **Management** -> **Monitoring** をクリックし、**Integration** タブでメトリクスの設定を行います。 EMQXがローカルで動作している場合、以下の設定をEMQXの `cluster.hocon` ファイルに追加してください。 ```bash opentelemetry { - exporter { endpoint = "http://localhost:4317" } + exporter { + endpoint = "http://localhost:4317" + headers { + authorization = "Basic dXNlcjpwYXNzd29yZA==" + } + } metrics { interval = "10s" } diff --git a/ja_JP/observability/opentelemetry/opentelemetry.md b/ja_JP/observability/opentelemetry/opentelemetry.md index e3c32ffb7..1568c6d6b 100644 --- a/ja_JP/observability/opentelemetry/opentelemetry.md +++ b/ja_JP/observability/opentelemetry/opentelemetry.md @@ -1,13 +1,17 @@ # OpenTelemetryとの統合 -[OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/)は、トレース、メトリクス、ログなどのテレメトリーデータを生成・管理するためのオブザーバビリティフレームワークおよびツールキットです。重要な点として、OpenTelemetryはベンダーやツールに依存しないため、JaegerやPrometheusなどのオープンソースツールから商用製品まで、幅広いオブザーバビリティバックエンドと連携可能です。 +[OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/)は、トレース、メトリクス、ログなどのテレメトリデータを生成および管理するためのオブザーバビリティフレームワークおよびツールキットです。重要な点として、OpenTelemetryはベンダーやツールに依存しないため、JaegerやPrometheusなどのオープンソースツールから商用製品まで、幅広いオブザーバビリティバックエンドと連携可能です。 -EMQXはgRPC OTELプロトコルを介してOpenTelemetry Collectorへテレメトリーデータを直接プッシュすることをサポートしており、Collectorを通じてデータの転送、フィルタリング、変換を行い、Jaegerや[Prometheus](../../observability/prometheus.md)などの任意のバックエンドに統合して保存・可視化できます。OpenTelemetryとの統合により、EMQXのメトリクス収集、メッセージパブリッシュの分散トレーシング、ログの統合収集およびコンテキスト関連付けが最適化されます。この統合は、EMQXの可視化監視やアラート通知の実現、異なるシステムやサービス間のメッセージフローの追跡に役立ちます。これにより、継続的なパフォーマンス最適化、迅速な問題特定、システム監視が可能となります。 +EMQXは、gRPC OTELプロトコルを介してOpenTelemetry Collectorにテレメトリデータを直接プッシュし、その後Collectorを通じてデータを転送、フィルタリング、変換し、Jaegerや[Prometheus](../../observability/prometheus.md)などの任意のバックエンドに統合して保存および可視化できます。OpenTelemetryとの統合により、EMQXのメトリクス収集、メッセージパブリッシュの分散トレーシング、ログの統合収集とコンテキスト関連付けが最適化されます。この統合は、EMQXの可視化監視やアラート通知の実現、異なるシステムやサービス間のメッセージフローの追跡に役立ちます。これにより、継続的なパフォーマンス最適化、迅速な問題特定、システム監視が可能となります。 emqx-opentelemetry -本セクションでは、EMQXがOpenTelemetry Collectorとテレメトリーデータを統合し、以下のオブザーバビリティ情報に対して完全な組み込みOpenTelemetryサポートを実現する方法を紹介します。 +本セクションでは、EMQXがOpenTelemetry Collectorとテレメトリデータを統合し、以下のオブザーバビリティ情報に対する完全な組み込みOpenTelemetryサポートを実現する方法を紹介します。 - [メトリクス](./metrics.md) - [トレース](./traces.md) - [ログ](./logs.md) + +さらに、EMQXバージョン5.8.3以降では、OpenTelemetryに基づくエンドツーエンドトレーシングもサポートしています。 + +- [エンドツーエンドトレース](./e2e-traces.md)