OpenTelemetry、自動インストルメンテーション、Splunk Observability Cloudの活用促進

OpenTelemetryの活用法や、アプリケーションとサービスで収集できるすべてのテレメトリを統合する方法を学びたいと思ったことはありますか？実践的に学びたい場合は、OpenTelemetryとSplunk Observability Cloudを使うと便利です。以下のデモとガイドを活用すると、OpenTelemetryの自動インストルメンテーションとOpenTelemetry Collectorについて自分のペースですばやく学べます。

• Observability Quick Start Demo (オブザーバビリティクイックスタートデモ)とHipster Shop Guided Example (ガイド付きHipster Shopサンプル)：マイクロサービスのデモアプリケーション「Hipster Shop」を使って、OpenTelemetryとSplunk Observability Cloudの機能をすばやく評価できます。
• もっと詳しくOpenTelemetry：Splunk-OTEL-JSとExpressからOpenTelemetry Collectorへ(英語)：メトリクスをOpenTelemetry (OTEL) Collector経由でSplunk Observability Cloudに送信するための、splunk-otel-jsを使ったアプリケーション作成と自動インストルメンテーションを動画で学べます。
• もっと詳しくOpenTelemetry：OpenTelemetry-JSとExpressのクイックスタートガイド(英語)：トレースデータとログデータをコンソールに出力するための、OpenTelemetry-JSとExpress JSの自動インストルメンテーションを動画で学べます。
• マイクロサービスデモによるOpenTelemetryの学習：ローカルでOpenTelemetry Collectorを実行するKubernetesクラスターにデモを導入します。クラスターにPodをデプロイした数分後に、インストルメンテーションからのすべての出力をSplunk Observability Cloud (Application Performance Monitoring、Infrastructure Monitoring、Real User Monitoring)で監視できます。

テレメトリ、監視、オブザーバビリティで問題を解決

• すべてのテレメトリ出力を1カ所から監視したい！さらに、組織に合った方法でオブザーバビリティを導入、活用したい！
• ユーザーエクスペリエンスで発生しているクリック数やエラー数を確認したい！
• 新しいソフトウェアのデプロイのタイミングと稼働状況を知りたい！ボトルネックやリリースゲートでの問題を把握したい！

OpenTelemetryを使ってアプリケーションやサービスを自動インストルメントするのは簡単です。アプリケーション本体、設定ファイル、またはビルドパイプラインに少し変更を加えるだけです。パイプラインの場合は、サポートライブラリを取り込み、環境変数を挿入するようにプロセスを変更します。これにより、Jenkinsパイプラインを監視することもできます。これは、ソフトウェア開発ライフサイクルの可視化と、カスタマーエクスペリエンスの低下防止に役立ちます。

既存のアプリケーションの自動インストルメンテーションも簡単です。Node.jsアプリケーションの場合、ローカルでOpenTelemetry Collectorが実行されていれば、npm起動スクリプトでsplunk-otel-jsライブラリを取り込んでインスタンス化するように変更するだけです。まずは、既存のアプリケーションを変更するか、空のExpress.jsプロジェクトから始めるとよいでしょう。空のプロジェクトを使用する場合は、package.jsonに自動インストルメンテーションのコードを追加するだけです。Splunk Observability Cloudにテレメトリを直接送信するCollectorを使用しない場合は、環境変数をいくつか追加する方法もあります。

Splunk Observability Cloudでのアプリケーションパフォーマンス監視とリアルユーザー監視

OpenTelemetryを使ってアプリケーションのインストルメンテーションと設定を行うと、Hipster Shopを実行するKubernetesクラスターからのメトリクスがCollector経由でSplunk Observability Cloudに送信されます。さっそく確認してみましょう。ログイン後、[APM Overview] (APMの概要)内をクリックすると、テレメトリ、インサイト、インテグレーションがすべて連携しているのがわかります。

サービスマップでは、サービスとアプリケーションの分散トレースを調査できます。デモ用マイクロサービスのWebサイトで操作を行うと、サービスマップに表示されるトレースが広がります。状態を観察するだけであれば、Hipster Shopデモとともに提供されるトラフィック生成ツールを使って負荷生成を自動化することもできます。

Kubernetesでマイクロサービスデモやその他のサービスを実行している場合は、Splunk Observability Cloudのインフラ監視画面でインフラの状況を確認できます。下の画像は、Splunkが提供するHelmチャートとともに導入されるOpenTelemetry Collectorのクラスターマップの例です。

Webアプリケーションでの実際のユーザーエクスペリエンスを確認したい場合は、Splunk Observability Cloudのリアルユーザー監視(RUM)セクションに移動します。RUMサービスダッシュボードには、LCP (最も大きいコンテンツが表示されるまでの時間)、CLS (レイアウトのずれの累積量)、FID (最初のユーザー操作に対する反応時間)、TTFB (最初の1バイトを送信するまでの時間)、JavaScript/ネットワークエラー数、バックエンド/リソースリクエストの処理時間など、主要なメトリクスが表示されます。また、Splunk Synthetic Monitoringでプロアクティブな監視を行えば、サポートチケットを受け取る前にカスタマーエクスペリエンスの低下を検出できます(注：Splunk Synthetic Monitoringは現時点でトライアル版には含まれません)。

オブザーバビリティで監視を強化して安心を手に入れる

以上のように、OpenTelemetryによるアプリケーションの自動インストルメンテーションと、ローカルOpenTelemetry Collectorの導入と設定は簡単に行うことができます。それが完了すれば、フロントエンドからバックエンドまでサービスとアプリケーションをプロアクティブに監視し、必要に応じてアラートを生成して、問題にすばやく対応できます。オブザーバビリティ、OpenTelemetry、Splunk Observability Cloudを組み合わせれば、DevOpsチーム、DevSecOpsチーム、運用チーム、経営幹部の連携を強化できます。

このブログでは以下のテクニックをご紹介しました。

• Hipster Shop Guided Exampleを使ってリアルユーザー監視の仕組みを理解し、プロアクティブな監視の実現に役立てる。
• splunk-otel-jsまたはotel-jsを使ってサンプルNode.jsアプリケーションをインストルメントし、アプリケーションのトレース、メトリクス、ログをOpenTelemetry Collector経由でSplunk Observability Cloudに直接送信する。
• サンプルアプリケーション、サービス、インフラを準備し、Kubernetesにデプロイして、ローカルのOpenTelemetry Collectorを使ってテレメトリをSplunk Observability Cloudに送信する。
• インストルメンテーションからのすべての出力をSplunk Observability Cloud (Application Performance Monitoring、Infrastructure Monitoring、Real User Monitoring)で監視する。

次のステップ

SplunkとOpenTelemetryの自動インストルメンテーションでアプリケーションとサービスの監視を始めましょう。SplunkとOpenTelemetryの機能を活用すれば、継続的デリバリー、セキュリティ、バージョン/プロセス管理にオブザーバビリティを組み込んで、ソフトウェアデリバリーのパフォーマンスを向上させることができます。また、Splunk Real User Monitoringで問題にプロアクティブに対応することで、カスタマーエクスペリエンスの低下を防ぎ、顧客満足度を向上させることもできます。サービスとアプリケーションのインストルメンテーションを実現すれば、より的確な意思決定を行い、より多くの課題を探って解決策を見つけ出し、ビジネス価値の向上につなげることができるでしょう。Splunk Observability Cloud製品スイートの無料トライアル版で、ほぼリアルタイムでのインフラの健全性監視と本番環境のボトルネック検出をぜひご体験ください！

このブログ記事はSplunkのソリューションイノベーションエンジニアであるAdam Schalockが執筆しました。また、協力いただいた同僚のJeremy Hicksに感謝申し上げます。