ブログに戻る

フォロー&ご登録

Fastly リアルタイムログ機能を Compute で活用するためのガイド

Alex Kesler

Senior Software Engineer, Fastly

エンジニアリング WebAssembly コンピューティング

現在 Fastly では、コミットメントなしで Compute を試すことができる、無料トライアルキャンペーンを実施しています。エッジコンピューティングを実際に試してみたい方は、ぜひこの機会に無料トライアルをご利用ください。

Compute で WebAssembly (通称 Wasm) ベースのアプリケーションを構築し、Fastly エッジキャッシュを使用するには、VCL (Varnish Configuration Language) で CDN の動作を設定する方法から、従来型のソフトウェアを構築するのと同様に、Rust や JavaScript、AssemblyScript などを使用するプログラミングへのパラダイムシフトが必要です。

今まで VCL を使用してきた方も、Compute を初めて使う方も、効果的なトラブルシューティングや継続的な指標の取得のために、いずれは Wasm アプリケーションから診断テキストの出力を送信する方法を学ぶ必要があります。

Compute 上で Wasm を使用して構築されたアプリから出力をストリームする方法は、メッセージを取得・保存する送信先の種類に合わせて、2通りあります。

  1. STDIO
    stdout と stderr ファイル記述子への出力は、ホスト環境によって取得され、監視可能な場所に送信されます。これは、ターミナルやファイルへ出力がリダイレクトされる方法と似ています。Compute@ で「Log Tailing」と呼ばれているこの機能は、Fastly CLI によってサポートされています。Log Tailing 機能は、Wasm ベースのアプリからの未処理ランタイムエラーも取得・表示することができます。

  2. ログフレームワーク
    Computeのログフレームワークは、形式的な構造体の追加、目的のコード化、出力の送信先システムの設定などをサポートしています。Fastly のログ・ストリーミング・プラットフォームで利用可能な統合機能のいずれかを使用して、ログメッセージを Apache Kafka、S3、Splunk などさまざまなシステムに送信できます。ログは、情報、警告、エラーの種類などの重要性に基づいて分類可能です。送信先に到達したログは、この分類または任意の基準によって自動的に処理されます。

今回は、STDIO に出力したメッセージを Fastly CLI を使って監視するための基本的な手順のほか、ログ・ストリーミング・エンドポイントの設定、アプリでのログ送信、適切な送信先へのログ配信の確認方法などをご紹介します。ログストリーミングには、Apache Kafka プロトコルと互換性のあるサービスバスである Azure Event Hubs をログ集約ポイントとして使用します。別のログ集約ポイントを使用する場合は、ログストリーミングに関するドキュメントをご確認の上、ログエンドポイント設定を調整してください。

プロジェクトの初期設定

今回は、手順を分かりやすくするために CLI ツールのみを使用します。このチュートリアルでは、あらかじめ Fastly アカウントの作成および、Fastly CLI と Rust のインストールが完了していることを前提としています。まだアカウントをお持ちでない方は、こちらから作成してください。また、このチュートリアルでは Fastly CLI のバージョン 1.0.0 を使用しています。別バージョンをご利用の場合は、コマンドフラグが異なる場合がありますのでご注意ください。今回は Rust のみを使用しますが、手順の一部は JavaScript や AssemblyScript でも実行可能です。

まず、CLI トークンを作成します。アカウントの管理者として以下のコマンドを実行し、後続の CLI ツールの設定コマンド用の API トークンを生成します。その際、トークンに適切な有効期限 (日時) を設定してください。

fastly auth-token create --password=<your-Fastly-acct-password> \
--name='My WASM API Token' --scope=global \
--expires 2021-12-31T23:59:59Z

次のような出力が表示されます。

SUCCESS: Created token ‘<token-string>’ ...

引用符の間の文字列が、Fastly API トークンの値です。次に、以下のコマンドを実行し、プロンプトが表示されたら作成したトークンを指定します。

fastly configure

これで、Fastly サービスと Compute の Wasm アプリケーションを作成、設定、管理する準備ができました。

以下のコマンドを実行し、Wasm ベースのサービスを作成します。

fastly service create --name=MyService --type=wasm

なお、このコマンドでは従来の VCL ベースのサービスではなく、Wasm ベースの Fastly サービスが作成されます。この新しいサービスは、Fastly のコントロールパネルでも確認することができます。

サービス設定を有効化するには、最低でも専用のドメイン名が必要になります。そのためには、まず新しいサービスのサービス ID が必要です。以下のコマンドを実行し、サービス ID を取得します。

fastly service list

レスポンスの ID 欄に、サービス ID が表示されます。また、生成された出力に表示されるサービスタイプが、wasm であることをご確認ください。

次に以下のコマンドを実行します。その際、Wasm サービスにドメインを割り当てるために、サブドメインの具体的な名前を入力します。

fastly domain create --name=<your-name>.edgecompute.app \
--version=latest --service-id=<your-Fastly-service-ID>

Fastly のプラットフォームでは、Compute で構築された Wasm サービスのドメイン名に、Fastly の CDN インフラストラクチャに関連している edgecompute.app のサフィックスが含まれる必要があります。ただし、本番環境における Compute のデプロイでは、ドメイン名サービスプロバイダーの CNAME レコードを使用して、お好きなエイリアスを割り当てることができます。

今回は、少し面白みを加えるために、Wasm サービスに www.w3.org と www.iana.org をバックエンドオリジンホストとして割り当てます。これらは、Web コンテンツを配信する実際のオリジンサーバーの代理を務めます。以下の2つのコマンドを実行し、この2つのバックエンドを追加します。

fastly backend create --name=backend_name --address=www.w3.org \
--override-host=www.w3.org --use-ssl --ssl-sni-hostname=www.w3.org \
--ssl-cert-hostname='*.w3.org' --version=latest \
--service-id=<your-Fastly-service-ID>


fastly backend create --name=other_backend_name \
--address=www.iana.org --override-host=www.iana.org --use-ssl \
--ssl-sni-hostname=www.iana.org \
--ssl-cert-hostname='*.iana.org' --version=latest \
--service-id=<your-Fastly-service-ID>

バックエンドオリジンサービスが設定できたら、最後に Wasm コードを作成・アップロードして、Wasm アプリの初期セットアップを完了します。幸い、Wasm スターターキットを使用することで、このステップを CLI で簡単に行うことができます。

以下のコマンドを実行して、ユーザー名を確認し、「Default starter for Rust」(または似たようなオプション) を選択します。

fastly compute init --language=Rust --directory=./MyEdgeComputeApp \
--name=MyEdgeComputeApp \
--description='My first Compute@Edge app'

ディレクトリを MyEdgeComputeApp に変更し、内容を確認します。特に ./src. 内のファイルを確認してください。プロジェクトルートディレクトリ内の ./fastly.toml のサービスバックエンド設定を、以下の内容と一致するように編集します。

[setup]

 [setup.backends]

    [setup.backends.backend_name]
      address = "www.w3.org"
      description = "A backend able to serve `/articles` path"
      port = 443

    [setup.backends.other_backend_name]
      address = "www.iana.org"
      description = "A backend able to serve `/anything` path"
      port = 443

上記の設定を削除し、CLI のみを使用してバックエンドを管理することも可能ですが、CLI Wasm のパブリッシングプロセスで ./fastly.toml ファイルを使って Wasm アプリのバックエンドを自動的に設定することもできます。

次のコマンドを実行し、Wasm アプリを構築・デプロイします。

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

これで Compute で Wasm サービスが有効化され、リクエストを処理できるようになりました。

以下の URL をフェッチし、レスポンスを確認してみましょう。

  • https://<your-name>.edgecompute.app/
  • https://<your-name>.edgecompute.app/articles
  • https://<your-name>.edgecompute.app/anything

/articles と /anything のパスでは、www.w3.org と www.iana.org によって HTTP 404 エラーのランディングページが返されるはずです。ぜひ練習として、./src/main.rs の Rust コードを使用して、有効なページや、両サイトのページアーティファクトへのパスを解決してみてください。

これで Compute で構築した Wasm アプリのデプロイが完了しました！次は、プログラム出力の送信と、アプリから外部のログ収集ポイントへログをストリームする方法を、3つのセクションに分けてご紹介します。

CLI を使った print デバッグ

このセクションでは、Compute の Wasm アプリケーションからシンプルな print ステートメントを送信し、モニタリングする手順をご紹介します。

先ほどの MyEdgeComputeApp へ戻り、./src/main.rs の fn main(mut req: Request) -> Result<Response, Error> { の下に以下の行を追加します。

fn main(mut req: Request) -> Result<Response, Error> {
    // Log request path to stdout.
    println!("Request received for path {}", req.get_path());
    // Filter request methods...
    match req.get_method() {
    ...

Wasm アプリを構築し、再度デプロイします。

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

このデプロイステップにより、Wasm サービス設定のバージョンが自動的に繰り上げられ、新たな Wasm アプリパッケージが使用されているこの新バージョンが有効化されます。

ターミナル内にて次のコマンドを入力して、Wasm アプリの出力の監視を開始します。

fastly log-tail --service-id=<your-Fastly-service-ID>

その際、出力の監視が有効化された旨を知らせるログメッセージが表示されることがありますが、これは単に初期設定によるものです。

アプリケーションの出力の監視を確認するには、https://<your-name>.edgecompute.app/ など Wasm サービスの URL をフェッチします。そして、同じサブドメインの仮想パスである /articles と /anything の2つをフェッチします。

これらのフェッチリクエストに対して、次のような出力が表示されるはずです。

stdout | 5ee29b16 | Request received for path /
stdout | f438ba38 | Request received for path /articles
stdout | 44c848ca | Request received for path /anything

Web ブラウザからリクエストを発行した場合は、JavaScript や画像アーティファクトに関するエントリーが追加されていることがあります。このような出力が見られない場合は、フェッチリクエストを再度発行してみてください。出力メッセージの隣に表示されるハッシュ値は、各リクエストの相関 ID です。一つのリクエストに対して複数の出力メッセージが表示される場合があります。これは、次のステップで詳しくお見せします。^C キーを押して終了します。

MyEdgeComputeApp へ戻り、 "/articles" => { の下に以下のコードを追加します。

       "/articles" => {
            eprintln!("Request will be redirected to {}", BACKEND_NAME);
            // Request handling logic could go here...  E.g., send the request to an origin backend
            ...

Wasm アプリを構築し、再度デプロイします。

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

次に、再度 Wasm アプリからの出力を監視します。

fastly log-tail --service-id=<your-Fastly-service-ID>

次に、https://<your-name>.edgecompute.app/articles へのフェッチリクエストを発行し、出力を確認します。以下のような内容が表示されるはずです。

stdout | ad3d576e | Request received for path /articles
stderr | ad3d576e | Request will be redirected to backend_name

一見、特に変わったところが無さそうに見えますが、よく見ると以下の2つのことに気付きます。

  1. stdout と stderr の2つの別々の出力ストリームにそれぞれメッセージが送信されている

  2. 出力は両方とも、単一のリクエストの処理によって生成されている (上記の例ではリクエストは ad3d576e で識別されます)

ちなみに、CLI でストリームの種類に基づいて出力をフィルタリングすることも可能です。

では、このセクションで学んだことをおさらいしましょう。まず、Rust STDOUT と STDERR の出力ストリームを使用することで、Compute の Wasm アプリケーションから重要な情報を送信できること、そして fastly log-tail を使って送信された出力をシステム内でローカルに追跡・表示できることが分かりました。さらに、fastly log-tail を使用して、過去に遡って特定の時間枠にてキャプチャされた出力を表示させることも可能です。この機能について詳しくは、こちらのドキュメントをお読みください。

では、Compute で構築された Wasm アプリケーションを本番環境でデプロイする際、ターミナルから通常の出力ストリームへログを送信したくない場合、またはログ情報をより優れた方法で保存・クエリしたい場合はどうすれは良いでしょうか？また、Wasm アプリが受信するリクエストに基づいて異常を特定したり、重要なビジネスチャンスを発見するためにログ分析を自動化したい場合は、どうすれば良いのでしょうか？

この課題を解決してくれるのが Fastly のログ・ストリーミング・プラットフォームです。従来の VCL 設定と同じく、Wasm ベースのサービスやアプリケーションでもこのプラットフォームを利用できます。次のセクションでは、高度なログ集約エンドポイントの設定方法や、Wasm アプリからログを送信する方法について詳しくご紹介します。また、分析プラットフォームでログの利用を可能にする方法についてもご説明します。

ログエンドポイントの設定

ターゲットとする集約システムにログを送信するためには、エンドポイントを実際に設定する必要があります。この例では、Azure Event Hubs に Kafka クラウドエンドポイントを設定します。今回は最もシンプルな設定方法をお見せしますので、より詳しく知りたい場合は、Microsoft Azure プラットフォームのドキュメントをご参照ください。また、今回はエンドツーエンドの統合のみに注目するため、Kafka ツールについては基本的な使用方法に限られています。

ではまず、Azure CLI のインストールと、Azure アカウント (トライアルアカウントでも可) の作成が完了している上で、CLI を使ってアカウントにログインします。認証のため、ログインの際にテナント ID が必要になる場合があります。

az login --tenant <your-tenant-ID>

上記のコマンドの出力によって、有効な Azure サブスクリプションが表示されます。サブスクリプションのタイプは Basic で十分です。コマンドの出力に表示されたサブスクリプション ID をメモしてください。以下のコマンドを実行して、Azure で Event Hubs Cluster をセットアップします。下記のコマンドでは、ターゲット地域として「West Central US」が入力されていますが、az account list-locations コマンドを実行して任意の地域を選ぶことも可能です。

az group create --location westcentralus --name MyAzureGroup \
--subscription <your-subscription-ID>

az eventhubs namespace create --name <your-unique-namespace> \
--resource-group MyAzureGroup --enable-kafka true \
--location westcentralus --sku Standard \
--subscription <your-subscription-ID> \
--enable-auto-inflate false

az eventhubs eventhub create --resource-group MyAzureGroup \
--namespace-name <your-unique-namespace> --name MyEventHub \
--message-retention 1 --partition-count 1 --enable-capture false \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule create \
--eventhub-name MyEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup --rights Listen Send \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule keys list \
--eventhub-name MyEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup \
--subscription <your-subscription-ID>

選択した Event Hubs 名前空間名が利用不可能な場合は、別の名前を選んでください。上記の最後のコマンドによって表示される Azure Event Hubs のセキュアな接続文字列 (primaryConnectionString) は、次のステップで Fastly ログストリーミングの Kafka エンドポイントを設定する際に必要になります。

上記のコマンドは、Kafka トピックと同様に、単一の Event Hub をセットアップします。では、さまざまなイベント用に2つの異なるデータ処理パイプラインがあり、イベントの種類ごとに分析を別々に行いたい場合はどうすれば良いのでしょうか。その場合には、もう一つ Event Hub をセットアップする必要があります。そこで、以下のコマンドを実行し、異なるイベント用のセカンダリイベントバスを初期化します。

az eventhubs eventhub create --resource-group MyAzureGroup \
--namespace-name <your-unique-namespace> --name MyOtherEventHub \
--message-retention 1 --partition-count 1 --enable-capture false \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule create \
--eventhub-name MyOtherEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup --rights Listen Send \
--subscription <your-subscription-ID>

az eventhubs eventhub authorization-rule keys list \
--eventhub-name MyOtherEventHub --name Fastly \
--namespace-name <your-unique-namespace> \
--resource-group MyAzureGroup \
--subscription <your-subscription-ID>

先ほどと同様、上記の最後のコマンドによって表示される Azure Event Hubs のセキュアな接続文字列 (primaryConnectionString) は、Fastly ログストリーミングの 2つ目の Kafka エンドポイントを設定する際に必要になります。

次に、以下の CLI コマンドを実行して、1つ目の Azure Event Hubs エンドポイントを Compute の Wasm サービスに追加します。

fastly logging kafka create --name=AzureEventHubs --version=latest \
--topic=MyEventHub \
--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \
--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \
--use-sasl --auth-method=plain --username='$ConnectionString' \
--password='<value-of-first-Azure-primaryConnectionString>' --autoclone --placement=none

なお、このコマンドの実行後、サービス設定の新しい仮バージョンが作成されますが、有効化はされていません。後ほど、Wasm アプリの更新されたコードをパブリッシュする際に有効化します。また、上記のコマンドではこのログエンドポイントが「AzureEventHubs」と名付けられており、Wasm アプリケーションコード内で同じログエンドポイント名を参照する必要があることにご注意ください。

次に、以下の CLI コマンドを実行して、2つ目に作成した Azure Event Hubs エンドポイントを Compute の Wasm サービスに追加します。

fastly logging kafka create --name=AnotherAzureEventHubs --version=latest \
--topic=MyOtherEventHub \
--brokers=<your-unique-namespace>.servicebus.windows.net:9093 \
--service-id=<your-Fastly-service-ID> --required-acks=-1 --use-tls --max-batch-size=2048 \
--use-sasl --auth-method=plain --username='$ConnectionString' \
--password='<value-of-second-Azure-primaryConnectionString>' --autoclone --placement=none

先ほどと同様、2つ目のログエンドポイントの名前「AnotherAzureEventHubs」をメモしてください。特定のイベントを適切なログの送信先に向けるために、コードでこのエンドポイント名を参照する必要があります。

以下のコマンドを実行することで、Compute の Wasm サービスに対して2つのログエンドポイントが適切に設定されたことを確認できます。

fastly logging kafka list --version=latest --service-id=<your-Fastly-service-ID>

「AzureEventHubs」と「AnotherAzureEventHubs」のエンドポイントが出力に並んで表示されるはずです。

本番環境向けのログ設定


Wasm サービスのログエンドポイントの設定が完了したところで、次は Wasm アプリケーションコード内からこれらのエンドポイントを参照しましょう。

まず、Rust プロジェクトの MyEdgeComputeApp に必要な依存関係を追加します。./Cargo.toml ファイルを選択し、次のように依存関係を追加します。

[dependencies]
fastly = "^0.8.0"
log-fastly = "0.8.0"
log = "0.4.14"
fern = "0.6"
chrono = "0.4"

log-fastly クレートに関するドキュメントはこちらからご覧ください。

ご使用のエディターが Rust 言語と統合されている場合、これらの依存関係が即座にエディターによってプルされることが可能ですが、そうでない場合は Wasm アプリを構築する際にダウンロードされます。また、この記事を読む頃には、依存関係のバージョンが新たに更新されている可能性があります。最新のバージョンを確認した上で、そちらを使用してください。

./src/main.rs の fn main(mut req: Request) -> Result<Response, Error> { の下に、次の初期化コードを追加します。

fn main(mut req: Request) -> Result<Response, Error> {
    let logger: Box<dyn log::Log> = Box::new(log_fastly::Logger::builder()
        .max_level(log::LevelFilter::Info)
        .default_endpoint("AzureEventHubs")
        .endpoint("AnotherAzureEventHubs").build()
        .expect("Unable to init Fastly logger"));
    fern::Dispatch::new()
        .format(|out, message, record| {
            out.finish(format_args!(
                "{}[{}] {}",
                chrono::Local::now().format("[%Y-%m-%d][%H:%M:%S]"),
                record.level(),
                message
            ))
        })
        .chain(logger)
        .apply()?;

    ...

同様に、“/articles” の match 句の下にログステートメントを追加します。

       "/articles" => {
            log::info!("Processing request to {}", req.get_path());
            ...

そして、“/anything” パスプリフィックスのmatch 句の下にログステートメントを追加します。

       path if path.starts_with("/anything") => {
            log::warn!(target: "AnotherAzureEventHubs", "Processing request to {}", req.get_path());
            ...

Wasm アプリを構築し、再度デプロイします。

fastly compute build
fastly compute deploy --service-id=<your-Fastly-service-ID>

このデプロイは、Wasm サービスの仮設定の最新バージョンに対して実行され、デプロイによってそのバージョンも有効化されることにご注意ください。

https://<your-name>.edgecompute.app/articles に対して、フェッチリクエストを4-5回発行してみます。その後、https://<your-name>.edgecompute.app/anything に対して、フェッチリクエストを4-5回発行します。

では、Wasm アプリによって異なる Azure Event Hubs エンドポイントに送信されたメッセージをフェッチしてみましょう。

まずは https://kafka.apache.org/downloads から Apache Kafka をダウンロードして抽出しますが、そのディストリビューションの中から Kafka クライアントのみを使用します。Kafka ディストリビューションには、システムに Java がインストールされている必要がありますが、kafkacat/kcat など、別の Kafka クライアントを使用しても構いません。その際は、コマンドラインフラグを調整してください。Kafka アーティファクトを抽出し、現ディレクトリをアーカイブのルートに変更した後、ディレクトリを ./bin に変えます。

次に、以下の内容で ./azure_client.properties ファイルを作成します。

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="$ConnectionString" \
    password="<value-of-first-Azure-primaryConnectionString>";
sasl.mechanism=PLAIN
security.protocol=SASL_SSL

以下のコマンドを実行し、1つ目の Azure Event Hubs インスタンスからパブリッシュされた Kafka イベントを読み取ります。

./kafka-console-consumer.sh --bootstrap-server \
<your-unique-namespace>.servicebus.windows.net:9093 \
--topic MyEventHub \
--consumer.config ./azure_client.properties --from-beginning

レスポンスに以下のような出力が表示されるはずです。

[2021-09-16][21:00:08][INFO] Processing request to /articles
[2021-09-16][21:00:08][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles
[2021-09-16][21:00:09][INFO] Processing request to /articles

^C キーを押して、kafka-console-consumer.sh を終了します。

上記のメッセージが表示されず、Kafka クライアントが切断されたことを示す出力が表示された場合は、kafka-console-consumer.sh と Azure Event Hubs の接続がオペレーティングシステムのファイアウォール、またはローカル・ネットワーク・アプライアンスのファイアウォールによってブロックされている可能性があります。その場合は、ファイアウォール設定で windows.net ドメインでのポート9093へのアクセスを許可してください。

各ログメッセージのタイムスタンプは、メッセージの作成時間が反映されています。ご覧のように、“/articles” リクエストを処理するために Rust コードに追加したログ行が、1つ目の Azure Event Hub のメッセージに現れています。これらは、INFO ログレベルにてログされています。また、“/anything” リクエスト処理に関連するログメッセージは表示されていません。

次に、以下の内容で今度は ./another_azure_client.properties ファイルを作成します。

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="$ConnectionString" \
    password="<value-of-second-Azure-primaryConnectionString>";
sasl.mechanism=PLAIN
security.protocol=SASL_SSL

以下のコマンドを実行し、2つ目の Azure Event Hubs インスタンスからパブリッシュされた Kafka イベントを読み取ります。

./kafka-console-consumer.sh --bootstrap-server \
<your-unique-namespace>.servicebus.windows.net:9093 \
--topic MyOtherEventHub \
--consumer.config ./another_azure_client.properties --from-beginning

レスポンスに以下のような出力が表示されるはずです。

[2021-09-16][21:02:06][WARN] Processing request to /anything
[2021-09-16][21:02:07][WARN] Processing request to /anything
[2021-09-16][21:02:07][WARN] Processing request to /anything
[2021-09-16][21:02:10][WARN] Processing request to /anything
[2021-09-16][21:02:10][WARN] Processing request to /anything

^C キーを押して、kafka-console-consumer.sh を終了します。今回は WARN ログレベルにてログされた、“/anything” リクエストの処理のみに関連したログメッセージが表示されていることに注目してください。“/articles” リクエストの処理に関連したメッセージはありません。

このように、異なるログエントポイントをターゲットにする方法は、Kafka だけではなく、さまざまなクラウドやサービスプロバイダーにも応用できます。それによって、多様なログメッセージを Amazon S3 Storage、Google BigQuery、Splunk など、Fastly のログストリーミングがサポートする異なる送信先へ、一度または重複して送信することができます。Compute の Wasm サービスと Fastly ログストリーミング機能を組み合わせて使用することにより、ビジネスに関連する重要な情報や異常の特定など、目的に基づいてログメッセージを異なる送信先に振り分けることが可能になります。

このチュートリアルを完了したら、Azure CLI のドキュメントを使ってリソースグループなどのプロビジョニングされたリソースを削除してください。グループを削除する前に Event Hub と Event Hubs 名前空間を削除する必要がある場合があります。

まとめ

おめでとうございます！これで Compute の Wasm サービスの設定方法と、Rust アプリケーションを構築し、サービスにパブリッシュする方法が習得できました。そのほかにも、STDOUT と STDERR への出力や、コマンドラインでその出力を追跡する方法を学びました。そして、Azure Event Hubs をログストリーミング先として設定し、Rust Wasm アプリに形式的なログステートメントを追加し、Azure Event Hubs へのログの送信を確認することに成功しました。

Fastly の CLI、Compute の Wasm ベースのサービス、ログストリーミングについて詳しくは、ぜひドキュメントをご覧ください。まだ Compute をご利用でない方は、3か月間の無料テストと設定期間に加え、毎月10万ドル相当のクレジットを6か月間使用可能な、期間限定トライアルキャンペーンをご利用ください。

Fastly
© Fastly 2024