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 Monitoring、Splunk RUM、Splunk 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 MonitoringとSplunk APMのトライアル版もご利用いただけます。

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

関連記事

OpenTelemetryによるアプリへの計装を全自動化する
オブザーバビリティ
4 分程度

OpenTelemetryによるアプリへの計装を全自動化する

Splunk Distribution of OpenTelemetry Collectorには様々な機能が追加されており、その内の一つにはアプリへの計装を自動化するAutomatic discovery and configurationがあります。本記事では全体像と主要な機能の用途、データ取込方法について解説します。
GigaOmレポートで明らかに:APMとオブザーバビリティのリーダーであり続けるSplunk
オブザーバビリティ
3 分程度

GigaOmレポートで明らかに:APMとオブザーバビリティのリーダーであり続けるSplunk

GigaOmレーダーで初となるアプリケーションパフォーマンス監視(APM)レポートの2021年版において、Splunkはリーダーおよびファストムーバー(Fast Movers)に選出されました。ファストムーバーに選ばれたのはSplunkのほかに1社のみです。
オブザーバビリティのコストコントロール - 予期せぬ課金・請求に困らないように
オブザーバビリティ
6 分程度

オブザーバビリティのコストコントロール - 予期せぬ課金・請求に困らないように

クラウドネイティブなシステム環境においてオブザーバビリティは欠かせませんが、一方で、そのコストに関する議論も多くの方々にとっての関心事です。特にクラウドネイティブな環境では予期せぬ課金が発生してしまう懸念を多くの方々が持っています。Splunk Observability Cloudを使う場合に、こういった事態をどのように防ぐことができるかをご紹介します。