MySQL/NoSQLデータベースのトラブルシューティングを迅速化するSplunk APMの新機能

Observability Mat Ball

Splunk Observabilityに、MySQL/NoSQLデータベースでの実行時間が長いクエリーや実行頻度が高いクエリーをよりすばやく簡単にトラブルシューティングするために役立つ2つの新機能が追加されました。1つ目は、追加設定なしで利用できる、NoSQLデータベースの監視とトラブルシューティング機能です。現時点でサポートされるのはRedisのみですが、今後順次追加されます。2つ目は、Splunk Infrastructure Monitoringで表示されるホストまたはインスタンスのパフォーマンスと、Splunk Application Performance Monitoring (APM)で表示されるデータベースクエリーのパフォーマンスを相関付ける、便利なコンテキスト機能です。Splunk Synthetic MonitoringSplunk RUMSplunk On-Callとこれらの新機能を組み合わせることで、問題をより迅速に検出、トラブルシューティングし、解決できます。

データベースの相関付けによるRedisのトラブルシューティング

SplunkでNoSQLデータベースの監視とトラブルシューティングが可能になりました。まずサポートされたのがRedisデータベースです。Redisデータベースでの遅延、大量リクエスト、エラーによるボトルネックをトラブルシューティングして、原因となっているインスタンスやコマンドを特定できます。

ではさっそく、データベースの相関付けを使ったRedisインスタンスのトラブルシューティング例をご紹介します。

SREが、RedisインスタンスでCPU使用率のスパイクが発生していることを知らせるアラートを受け取ったとします。Splunk Infrastructure MonitoringでRedisのパフォーマンスメトリクスを調べると、最近のデプロイの後で、1秒あたりの実行回数、CPU使用率、1秒あたりのネットワークバイト数でスパイクが発生していることがわかりました。

Redisのパフォーマンスメトリクス

Infrastructure Monitoringで概要を確認した後、画面下部に追加された関連コンテンツからデータベースとの相関付けができます。[Queries for redis] (Redisのクエリー)では、実行時間が長いクエリーと実行頻度が高いクエリーを確認できます。また、[Map for redis] (Redisのマップ)では、データベースとそのすべての依存関係を包括的に把握できます。

ここではまず、[Map for redis]をクリックします。cartserviceへのリクエストがデータベースで大量に実行されていることがわかります。どのコマンドの実行に異常があるかを調べてみましょう。[Database Query Performance] (データベースクエリーパフォーマンス)を展開すると詳細が表示されます。

Database Query Performanceの詳細画面

または、前の画面で[Queries for redis]をクリックし、Splunk APMを使って、クエリーのパフォーマンスでスパイクが発生しているコマンドを調べることもできます。

APMのRedisコマンドパフォーマンス画面では、遅延、リクエスト量、合計実行時間の順にコマンドを並べ替えることができます。このRedisインスタンスでは、SCANコマンドで大量のリクエストが実行されていることがわかります。その変動は、Splunk Infrastructure Monitoringで見たスパイクと一致します。

Redisコマンドパフォーマンス画面

そこでTag Spotlightを使うと、cartservice:grpc.requestでのリクエスト数が1秒あたり11万3,000件に達していることがわかります。この問題がワークフローの他の部分にどのような影響を及ぼしているかもここで調査できます。

Tag Spotlight

これで、cartserviceサービス、cartservice:grpc.requestワークフロー、そのSCANコマンドのパフォーマンスの問題をデータベース管理者やサービスオーナーに明確に伝えることができます。

Splunk ObservabilityでのMySQL/NoSQLデータベースのパフォーマンス監視

Splunkでは、データベースのパフォーマンスについて、十分な情報に基づいてエンドツーエンドでトラブルシューティングを行い、遅延の原因を特定できます。豊富なコンテキストが提供されるので、問題をデータベース管理者に効果的に伝えることもできます。特別な設定をしなくても、クライアント側のメトリクスをデータベースのパフォーマンスと相関付けて、Splunk Infrastructure MonitoringからAPMにすばやく切り替えられます。Splunk Observabilityでこれらの新しいデータベース機能を使用するために追加コストはかかりません。OpenTelemetryを活用している場合は、独自のインストルメンテーションによる負荷も発生しません。

ぜひお試しください

MySQL/NoSQLデータベースでの実行時間が長いクエリーと実行頻度が高いクエリーのトラブルシューティングがかつてないほど簡単になります。追加設定は不要です。Splunk APMまたはSplunk Infrastructure Monitoringで、データベースとインフラを詳細に可視化しましょう。詳しくは、こちらのドキュメントをご覧ください。Splunk Infrastructure MonitoringSplunk APMのトライアル版もご利用いただけます。

このブログはこちらの英語ブログの翻訳、加藤 教克によるレビューです。

関連記事

Syntheticsを活用して計画的なダウンタイムを適切に管理する方法
オブザーバビリティ
6 Minute Read

Syntheticsを活用して計画的なダウンタイムを適切に管理する方法

計画的なダウンタイムを正しく管理することで、環境の変更時に生じる外形テストの品質を保ち、有用なシグナルを得ることができます。Syntheticsを活用してダウンタイムを適切に管理しましょう。
OpenTelemetry、自動インストルメンテーション、Splunk Observability Cloudの活用促進
オブザーバビリティ
6 分程度

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

OpenTelemetryの自動インストルメンテーションを使用するアプリケーションやマイクロサービスをすばやく構築、デプロイする方法について説明します。
組織内ネットワークへの外形監視でオブザーバビリティを向上
オブザーバビリティ
3 分程度

組織内ネットワークへの外形監視でオブザーバビリティを向上

Splunk Observability CloudのSynthetic Monitoring(外形監視)ではPrivate Locationにより組織内のネットワーク内から外形監視を実施できます。これにより外部に公開していないシステムやAPIへのユーザーエクスペリエンス監視が可能になり、オブザーバビリティの更なる向上を実現します。本記事ではその利点と実装方法について詳しく見ていきます。