Ubuntu18.04でElasticStackを使用してマネージドRedisデータベースの統計を分析する方法

提供:Dev Guides
移動先:案内検索

著者は、 Write for DOnations プログラムの一環として、 Free and Open SourceFundを選択して寄付を受け取りました。

序章

データベースの監視は、データベースのパフォーマンスを示すさまざまなメトリックを体系的に追跡する継続的なプロセスです。 パフォーマンスデータを観察することで、貴重な洞察を得て、考えられるボトルネックを特定し、データベースのパフォーマンスを向上させる追加の方法を見つけることができます。 このようなシステムは、問題が発生したときに管理者に通知するアラートを実装することがよくあります。 収集された統計は、データベースの構成とワークフローだけでなく、クライアントアプリケーションの構成とワークフローを改善するためにも使用できます。

Elastic Stack (ELKスタック)を使用して管理対象データベースを監視する利点は、検索の優れたサポートと、新しいデータを非常に迅速に取り込む機能です。 データの更新には優れていませんが、このトレードオフは、過去のデータがほとんど変更されない監視とログの目的には受け入れられます。 Elasticsearch は、データをクエリする強力な手段を提供します。これを Kibana で使用すると、データベースがさまざまな期間でどのように処理されるかをよりよく理解できます。 これにより、データベースの負荷を実際のイベントと相関させて、データベースがどのように使用されているかについての洞察を得ることができます。

このチュートリアルでは、Redis INFO コマンドによって生成されたデータベースメトリックを、Logstashを介してElasticsearchにインポートします。 これには、コマンドを定期的に実行し、その出力を解析し、直後にインデックスを作成するためにElasticsearchに送信するようにLogstashを構成する必要があります。 インポートされたデータは、後でKibanaで分析および視覚化できます。 チュートリアルが終了するまでに、後で分析するためにRedis統計を取得する自動システムができあがります。

前提条件

  • 少なくとも8GBのRAM、root権限、およびセカンダリの非rootアカウントを持つUbuntu18.04サーバー。 これは、この初期サーバーセットアップガイドに従ってセットアップできます。 このチュートリアルでは、root以外のユーザーはsammyです。
  • サーバーにインストールされているJava8。 インストール手順については、 Ubuntu 18.04にaptを使用してJavaをインストールする方法にアクセスし、最初のステップで概説したコマンドに従ってください。 Java Development Kit(JDK)をインストールする必要はありません。
  • Nginxがサーバーにインストールされています。 その方法のガイドについては、 Ubuntu18.04チュートリアルにNginxをインストールする方法を参照してください。
  • サーバーにElasticsearchとKibanaがインストールされています。 Ubuntu 18.04 チュートリアルにElasticsearch、Logstash、およびKibana(Elastic Stack)をインストールする方法の最初の2つのステップを完了します。
  • DigitalOceanからプロビジョニングされたRedisマネージドデータベースで、接続情報を利用できます。 サーバーのIPアドレスがホワイトリストに含まれていることを確認してください。 DigitalOceanコントロールパネルを使用してRedisデータベースを作成するためのガイドについては、Redisクイックスタートガイドにアクセスしてください。
  • Ubuntu18.04チュートリアルで管理対象データベースに接続する方法に従ってサーバーにインストールされたRedli。

ステップ1—Logstashのインストールと構成

このセクションでは、Logstashをインストールし、Redisデータベースクラスターから統計を取得するように構成してから、それらを解析してElasticsearchに送信してインデックスを作成します。

次のコマンドを使用してLogstashをインストールすることから始めます。

sudo apt install logstash -y

Logstashをインストールしたら、起動時にサービスを自動的に開始できるようにします。

sudo systemctl enable logstash

統計を取得するようにLogstashを構成する前に、データ自体がどのように見えるかを見てみましょう。 Redisデータベースに接続するには、管理対象データベースのコントロールパネルに移動し、接続の詳細パネルで、ドロップダウンからフラグを選択します。

Redli クライアント用に事前構成されたコマンドが表示されます。これを使用して、データベースに接続します。 コピーをクリックし、サーバーで次のコマンドを実行して、redli_flags_commandをコピーしたコマンドに置き換えます。

redli_flags_command info

このコマンドからの出力は長いので、これをさまざまなセクションに分けて説明します。

Redis infoコマンドの出力では、セクションはコメントを示す#でマークされています。 値はkey:valueの形式で入力されるため、比較的簡単に解析できます。

Serverセクションには、バージョンやベースとなるGitコミットなど、Redisビルドに関する技術情報が含まれ、Clientsセクションには、現在開いている接続の数が表示されます。

Output# Server
redis_version:6.2.6
redis_git_sha1:4f4e829a
redis_git_dirty:1
redis_build_id:5861572cb79aebf3
redis_mode:standalone
os:Linux 5.11.12-300.fc34.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:11.2.1
process_id:79
process_supervised:systemd
run_id:b8a0aa25d8f49a879112a04a817ac2acd92e0c75
tcp_port:25060
server_time_usec:1640878632737564
uptime_in_seconds:1679
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:13488680
executable:/usr/bin/redis-server
config_file:/etc/redis.conf
io_threads_active:0

# Clients
connected_clients:4
cluster_connections:0
maxclients:10032
client_recent_max_input_buffer:24
client_recent_max_output_buffer:0
...

Memoryは、RAM Redisがそれ自体に割り当てたRAMの量と、使用できる可能性のあるメモリの最大量を確認します。 メモリが不足し始めると、コントロールパネルで指定した戦略を使用してキーが解放されます(この出力のmaxmemory_policyフィールドに表示されます)。

Output...
# Memory
used_memory:977696
used_memory_human:954.78K
used_memory_rss:9977856
used_memory_rss_human:9.52M
used_memory_peak:977696
used_memory_peak_human:954.78K
used_memory_peak_perc:100.00%
used_memory_overhead:871632
used_memory_startup:810128
used_memory_dataset:106064
used_memory_dataset_perc:63.30%
allocator_allocated:947216
allocator_active:1273856
allocator_resident:3510272
total_system_memory:1017667584
total_system_memory_human:970.52M
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:455081984
maxmemory_human:434.00M
maxmemory_policy:noeviction
allocator_frag_ratio:1.34
allocator_frag_bytes:326640
allocator_rss_ratio:2.76
allocator_rss_bytes:2236416
rss_overhead_ratio:2.84
rss_overhead_bytes:6467584
mem_fragmentation_ratio:11.43
mem_fragmentation_bytes:9104832
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:61504
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
...

Persistenceセクションでは、Redisが最後に保存したキーをディスクに保存した時刻と、それが成功したかどうかを確認できます。 Statsセクションには、クライアントおよびクラスター内の接続に関連する数値、要求されたキーが検出された(または検出されなかった)回数などが表示されます。

Output...
# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1640876954
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:217088
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:202
total_commands_processed:2290
instantaneous_ops_per_sec:0
total_net_input_bytes:38034
total_net_output_bytes:1103968
instantaneous_input_kbps:0.01
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:29
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:452
total_forks:1
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:0
dump_payload_sanitizations:0
total_reads_processed:2489
total_writes_processed:2290
io_threaded_reads_processed:0
io_threaded_writes_processed:0
...

Replicationの下のroleを見ると、プライマリノードとレプリカノードのどちらに接続しているかがわかります。 このセクションの残りの部分では、現在接続されているレプリカの数と、プライマリに関してレプリカに不足しているデータの量を示します。 接続しているインスタンスがレプリカの場合は、追加のフィールドが存在する可能性があります。

注: Redisプロジェクトでは、ドキュメントやさまざまなコマンドで「マスター」および「スレーブ」という用語を使用しています。 DigitalOceanは通常、「プライマリ」と「レプリカ」という代替用語を好みます。 このガイドでは、可能な限りデフォルトで「プライマリ」と「レプリカ」という用語を使用しますが、「マスター」と「スレーブ」という用語がやむを得ず登場する場合があることに注意してください。


Output...
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:f727fad3691f2a8d8e593b087c468bbb83703af3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:45088768
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
...

CPUの下に、Redisが現在消費しているシステム(used_cpu_sys)とユーザー(used_cpu_user)のCPUパワーの量が表示されます。 Clusterセクションには、Redisクラスターが実行されていることを示すcluster_enabledという一意のフィールドが1つだけ含まれています。

Output...
# CPU
used_cpu_sys:1.617986
used_cpu_user:1.248422
used_cpu_sys_children:0.000000
used_cpu_user_children:0.001459
used_cpu_sys_main_thread:1.567638
used_cpu_user_main_thread:1.218768

# Modules

# Errorstats

# Cluster
cluster_enabled:0

# Keyspace

Logstashは、Redisデータベースでinfoコマンドを定期的に実行し(これまでと同様)、結果を解析してElasticsearchに送信するように指示されます。 その後、Kibanaからそれらにアクセスできるようになります。

/etc/logstash/conf.dディレクトリの下のredis.confという名前のファイルに、ElasticsearchでRedis統計のインデックスを作成するための構成を保存します。ここで、Logstashは構成ファイルを保存します。 サービスとして開始すると、バックグラウンドで自動的に実行されます。

お気に入りのエディター(nanoなど)を使用してredis.confを作成します。

sudo nano /etc/logstash/conf.d/redis.conf

次の行を追加します。

/etc/logstash/conf.d/redis.conf

input {
    exec {
        command => "redis_flags_command info"
        interval => 10
        type => "redis_info"
    }
}

filter {
    kv {
        value_split => ":"
        field_split => "\r\n"
        remove_field => [ "command", "message" ]
    }

    ruby {
        code =>
        "
        event.to_hash.keys.each { |k|
            if event.get(k).to_i.to_s == event.get(k) # is integer?
                event.set(k, event.get(k).to_i) # convert to integer
            end
            if event.get(k).to_f.to_s == event.get(k) # is float?
                event.set(k, event.get(k).to_f) # convert to float
            end
        }
        puts 'Ruby filter finished'
        "
    }
}

output {
    elasticsearch {
        hosts => "http://localhost:9200"
        index => "%{type}"
    }
}

redis_flags_commandを、前の手順で使用したコントロールパネルに表示されているコマンドに置き換えることを忘れないでください。

収集されたデータに対して実行されるフィルターのセットであるinputと、フィルター処理されたデータをElasticsearchに送信する出力を定義します。 入力はexecコマンドで構成され、設定された時間interval(秒単位で表される)の後、サーバー上でcommandを定期的に実行します。 また、Elasticsearchでインデックスを作成するときにドキュメントタイプを定義するtypeパラメーターも指定します。 execブロックは、commandmessageの2つのフィールドを含むオブジェクトを渡します。 commandフィールドには実行されたコマンドが含まれ、messageにはその出力が含まれます。

入力から収集されたデータに対して順次実行される2つのフィルターがあります。 kvフィルターはキー値フィルターの略で、Logstashに組み込まれています。 keyvalue_separatorvalueの一般的な形式でデータを解析するために使用され、値とフィールドの区切り文字と見なされるものを指定するためのパラメーターを提供します。 フィールドセパレータは、一般的な形式でフォーマットされたデータを相互に分離する文字列に関係します。 Redis INFOコマンドの出力の場合、フィールド区切り文字(field_split)は改行であり、値区切り文字(value_split)は:です。 定義された形式に従わない行は、コメントを含めて破棄されます。

kvフィルターを構成するには、:value_splitパラメーターに渡し、\r\n(改行を示す)をfield_splitに渡します。パラメータ。 また、commandフィールドとmessageフィールドを配列の要素としてremove_fieldに渡すことにより、現在のデータオブジェクトから削除するように命令します。これらのフィールドには、現在は役に立たないデータが含まれているためです。 。

kvフィルターは、設計により文字列(テキスト)タイプとして解析された値を表します。 Kibanaは、実際には数値であっても、文字列型を簡単に処理できないため、これにより問題が発生します。 これを解決するには、カスタムRubyコードを使用して、可能な場合は数値のみの文字列を数値に変換します。 2番目のフィルターはrubyブロックで、実行するコードを含む文字列を受け入れるcodeパラメーターを提供します。

eventは、Logstashがコードに提供する変数であり、フィルターパイプラインの現在のデータが含まれています。 前に述べたように、フィルターは次々に実行されます。つまり、Rubyフィルターはkvフィルターから解析されたデータを受け取ります。 Rubyコード自体がeventをハッシュに変換し、キーをトラバースしてから、キーに関連付けられた値が整数または浮動小数点数(10進数の数値)として表現できるかどうかを確認します。 可能であれば、文字列値は解析された数値に置き換えられます。 ループが終了すると、進行状況を報告するメッセージ(Ruby filter finished)が出力されます。

出力は、処理されたデータをElasticsearchに送信してインデックスを作成します。 結果のドキュメントはredis_infoインデックスに保存され、入力で定義され、パラメータとして出力ブロックに渡されます。

ファイルを保存して閉じます。

aptを使用してLogstashをインストールし、Redisに統計を定期的に要求して処理し、Elasticsearchインスタンスに送信するように構成しました。

ステップ2—Logstash構成をテストする

次に、Logstashを実行して構成をテストし、データが適切にプルされることを確認します。

Logstashは、ファイルパスを-fパラメーターに渡すことにより、特定の構成の実行をサポートします。 次のコマンドを実行して、最後の手順からの新しい構成をテストします。

sudo /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d/redis.conf

出力が表示されるまでに時間がかかる場合がありますが、すぐに次のようなものが表示されます。

OutputUsing bundled JDK: /usr/share/logstash/jdk
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults
Could not find log4j2 configuration at path /usr/share/logstash/config/log4j2.properties. Using default config which logs errors to the console
[INFO ] 2021-12-30 15:42:08.887 [main] runner - Starting Logstash {"logstash.version"=>"7.16.2", "jruby.version"=>"jruby 9.2.20.1 (2.5.8) 2021-11-30 2a2962fbd1 OpenJDK 64-Bit Server VM 11.0.13+8 on 11.0.13+8 +indy +jit [linux-x86_64]"}
[INFO ] 2021-12-30 15:42:08.932 [main] settings - Creating directory {:setting=>"path.queue", :path=>"/usr/share/logstash/data/queue"}
[INFO ] 2021-12-30 15:42:08.939 [main] settings - Creating directory {:setting=>"path.dead_letter_queue", :path=>"/usr/share/logstash/data/dead_letter_queue"}
[WARN ] 2021-12-30 15:42:09.406 [LogStash::Runner] multilocal - Ignoring the 'pipelines.yml' file because modules or command line options are specified
[INFO ] 2021-12-30 15:42:09.449 [LogStash::Runner] agent - No persistent UUID file found. Generating new UUID {:uuid=>"acc4c891-936b-4271-95de-7d41f4a41166", :path=>"/usr/share/logstash/data/uuid"}
[INFO ] 2021-12-30 15:42:10.985 [Api Webserver] agent - Successfully started Logstash API endpoint {:port=>9600, :ssl_enabled=>false}
[INFO ] 2021-12-30 15:42:11.601 [Converge PipelineAction::Create<main>] Reflections - Reflections took 77 ms to scan 1 urls, producing 119 keys and 417 values
[WARN ] 2021-12-30 15:42:12.215 [Converge PipelineAction::Create<main>] plain - Relying on default value of `pipeline.ecs_compatibility`, which may change in a future major release of Logstash. To avoid unexpected changes when upgrading Logstash, please explicitly declare your desired ECS Compatibility mode.
[WARN ] 2021-12-30 15:42:12.366 [Converge PipelineAction::Create<main>] plain - Relying on default value of `pipeline.ecs_compatibility`, which may change in a future major release of Logstash. To avoid unexpected changes when upgrading Logstash, please explicitly declare your desired ECS Compatibility mode.
[WARN ] 2021-12-30 15:42:12.431 [Converge PipelineAction::Create<main>] elasticsearch - Relying on default value of `pipeline.ecs_compatibility`, which may change in a future major release of Logstash. To avoid unexpected changes when upgrading Logstash, please explicitly declare your desired ECS Compatibility mode.
[INFO ] 2021-12-30 15:42:12.494 [[main]-pipeline-manager] elasticsearch - New Elasticsearch output {:class=>"LogStash::Outputs::ElasticSearch", :hosts=>["http://localhost:9200"]}
[INFO ] 2021-12-30 15:42:12.755 [[main]-pipeline-manager] elasticsearch - Elasticsearch pool URLs updated {:changes=>{:removed=>[], :added=>[http://localhost:9200/]}}
[WARN ] 2021-12-30 15:42:12.955 [[main]-pipeline-manager] elasticsearch - Restored connection to ES instance {:url=>"http://localhost:9200/"}
[INFO ] 2021-12-30 15:42:12.967 [[main]-pipeline-manager] elasticsearch - Elasticsearch version determined (7.16.2) {:es_version=>7}
[WARN ] 2021-12-30 15:42:12.968 [[main]-pipeline-manager] elasticsearch - Detected a 6.x and above cluster: the `type` event field won't be used to determine the document _type {:es_version=>7}
[WARN ] 2021-12-30 15:42:13.065 [[main]-pipeline-manager] kv - Relying on default value of `pipeline.ecs_compatibility`, which may change in a future major release of Logstash. To avoid unexpected changes when upgrading Logstash, please explicitly declare your desired ECS Compatibility mode.
[INFO ] 2021-12-30 15:42:13.090 [Ruby-0-Thread-10: :1] elasticsearch - Using a default mapping template {:es_version=>7, :ecs_compatibility=>:disabled}
[INFO ] 2021-12-30 15:42:13.147 [Ruby-0-Thread-10: :1] elasticsearch - Installing Elasticsearch template {:name=>"logstash"}
[INFO ] 2021-12-30 15:42:13.192 [[main]-pipeline-manager] javapipeline - Starting pipeline {:pipeline_id=>"main", "pipeline.workers"=>2, "pipeline.batch.size"=>125, "pipeline.batch.delay"=>50, "pipeline.max_inflight"=>250, "pipeline.sources"=>["/etc/logstash/conf.d/redis.conf"], :thread=>"#<Thread:0x5104e975 run>"}
[INFO ] 2021-12-30 15:42:13.973 [[main]-pipeline-manager] javapipeline - Pipeline Java execution initialization time {"seconds"=>0.78}
[INFO ] 2021-12-30 15:42:13.983 [[main]-pipeline-manager] exec - Registering Exec Input {:type=>"redis_info", :command=>"redli --tls -h db-redis-fra1-68603-do-user-1446234-0.b.db.ondigitalocean.com -a hnpJxAgoH3Om3UwM -p 25061 info", :interval=>10, :schedule=>nil}
[INFO ] 2021-12-30 15:42:13.994 [[main]-pipeline-manager] javapipeline - Pipeline started {"pipeline.id"=>"main"}
[INFO ] 2021-12-30 15:42:14.034 [Agent thread] agent - Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}
Ruby filter finished
Ruby filter finished
Ruby filter finished
...

Ruby filter finishedメッセージが定期的に(前の手順で10秒に設定されて)印刷されているのがわかります。これは、統計がElasticsearchに送信されていることを意味します。

キーボードのCTRL + Cをクリックすると、Logstashを終了できます。 前述のように、Logstashは、サービスとして開始されると、バックグラウンドで/etc/logstash/conf.dの下にあるすべての構成ファイルを自動的に実行します。 次のコマンドを実行して開始します。

sudo systemctl start logstash

Logstashを実行して、Redisクラスターに接続してデータを収集できるかどうかを確認しました。 次に、Kibanaの統計データのいくつかを調べます。

ステップ3—Kibanaでインポートされたデータを探索する

このセクションでは、Kibanaでのデータベースのパフォーマンスを説明する統計データを調べて視覚化します。

Webブラウザーで、前提条件の一部としてKibanaを公開したドメインに移動します。 デフォルトのウェルカムページが表示されます。

LogstashがElasticsearchに送信するデータを調べる前に、まずredis_infoインデックスをKibanaに追加する必要があります。 これを行うには、まずウェルカムページから自分で探索を選択してから、左上隅にあるハンバーガーメニューを開きます。 Analytics の下で、Discoverをクリックします。

次に、Kibanaは新しいインデックスパターンを作成するように促します。

インデックスパターンの作成を押します。 新しいインデックスパターンを作成するためのフォームが表示されます。 Kibanaのインデックスパターンは、複数のElasticsearchインデックスから一度にデータを取得する方法を提供し、1つのインデックスのみを探索するために使用できます。

右側に、Kibanaは、使用するようにLogstashを構成したredis_infoなど、使用可能なすべてのインデックスを一覧表示します。 Name テキストフィールドに入力し、ドロップダウンからTimestampフィールドとして@timestampを選択します。 完了したら、下のインデックスパターンの作成ボタンを押します。

既存のビジュアライゼーションを作成して表示するには、ハンバーガーメニューを開きます。 Analytics で、Dashboardを選択します。 ロードしたら、ビジュアライゼーションの作成を押して、新しいビジュアライゼーションの作成を開始します。

左側のパネルには、Kibanaが視覚化を描画するために使用できる値のリストが表示されます。これは画面の中央部分に表示されます。 画面の右上には、日付範囲ピッカーがあります。 @timestampフィールドが視覚化で使用されている場合、Kibanaは範囲ピッカーで指定された時間間隔に属するデータのみを表示します。

ページのメイン部分にあるドロップダウンから、 Line andareaセクションの下のLineを選択します。 次に、左側のリストからused_memoryフィールドを見つけて、中央部分にドラッグします。 すぐに、時間の経過に伴う使用済みメモリの中央値の線の視覚化が表示されます。

右側では、水平軸と垂直軸の処理方法を構成できます。 そこで、表示された軸を押すことにより、中央値ではなく平均値を表示するように垂直軸を設定できます。

別の機能を選択するか、独自の機能を提供することができます。

グラフは、更新された値ですぐに更新されます。

このステップでは、Kibanaを使用して管理対象のRedisデータベースのメモリ使用量を視覚化しました。 これにより、データベースがどのように使用されているかをよりよく理解できるようになり、データベース自体だけでなく、クライアントアプリケーションを最適化するのに役立ちます。

結論

これで、Elasticスタックがサーバーにインストールされ、管理対象のRedisデータベースから統計データを定期的にプルするように構成されました。 Kibanaまたはその他の適切なソフトウェアを使用してデータを分析および視覚化できます。これにより、データベースのパフォーマンスに関する貴重な洞察と実際の相関関係を収集できます。

Redisマネージドデータベースでできることの詳細については、 productdocsにアクセスしてください。 別の視覚化タイプを使用してデータベース統計を表示する場合は、 Kibanadocsで詳細な手順を確認してください。