Is your feature request related to a problem? Please describe.
Recently, I've been organizing the scripts and data output related to dragonfly monitoring, and I've seen the official monitoring based on Prometheus and Grafana before, but I feel that the monitoring items are a bit less than enough to support the monitoring needs of the production environment, so I'd like to do more monitoring data extraction. This time there are a places I want to propose, let's communicate together to see if there is a need to improve.
support for process_id in info Serveroutput
The output of process_id ininfo Server, this requirement is due to the fact that in the process of monitoring, we may need to get a lot of information through the process_id, such as through the ps -ef command to find the instance of the data directory and configuration file, as well as through the process_id with a lot of system commands to output the monitoring data we want to, such as lsof , top command, etc...
Of course, you may say that the process_id can be filtered byps -ef|dragonfly. Yes, but if you deploy multiple instances, it may not be convenient, you need to add other filtering rules, such as adding ports to the startup command to pinpoint the pid of the desired instance, which can be a bit tricky, and in the case of multi-instance deployments, the pid fetch may be inaccurate. Although it is recommended to deploy only one instance on a single machine, in my environment there are physical servers with 96 cores or 128 cores, so if only one instance is assigned, it may be a waste of resources if the number of requests does not reach it.
So still I feel that by supporting this command in info Server, I can get it directly when I get the instance configuration dictionary, which will become convenient and accurate that this process_id belongs to this instance only.
support for config_file in info Serveroutput
Physical machine multi-instance deployment, the configuration file may have to use commands and paths to distinguish between the time to do monitoring and configuration files and instances of the configuration against the time need to get the contents of the configuration file, so I hope that according to the instance information can be directly access to the configuration file address, so as to carry out the subsequent monitoring of the metrics output, I hope to give support.
Similar to : config_file:/home/dba/redis/redis6383/redis6383.cnf
Additional context
I'm sorry I'm here to raise requirements again, hahaha, these requirements are trying to usability and reliability after using our dragonfly on-line to the production environment, I hope dragonfly is getting better and better, looking forward to the reply, together to discuss. 😃
Is your feature request related to a problem? Please describe. Recently, I've been organizing the scripts and data output related to dragonfly monitoring, and I've seen the official monitoring based on Prometheus and Grafana before, but I feel that the monitoring items are a bit less than enough to support the monitoring needs of the production environment, so I'd like to do more monitoring data extraction. This time there are a places I want to propose, let's communicate together to see if there is a need to improve.
process_id
ininfo Server
outputThe output of
process_id
ininfo Server
, this requirement is due to the fact that in the process of monitoring, we may need to get a lot of information through theprocess_id
, such as through theps -ef
command to find the instance of the data directory and configuration file, as well as through theprocess_id
with a lot of system commands to output the monitoring data we want to, such aslsof
,top
command, etc... Of course, you may say that theprocess_id
can be filtered byps -ef|dragonfly
. Yes, but if you deploy multiple instances, it may not be convenient, you need to add other filtering rules, such as adding ports to the startup command to pinpoint the pid of the desired instance, which can be a bit tricky, and in the case of multi-instance deployments, the pid fetch may be inaccurate. Although it is recommended to deploy only one instance on a single machine, in my environment there are physical servers with 96 cores or 128 cores, so if only one instance is assigned, it may be a waste of resources if the number of requests does not reach it. So still I feel that by supporting this command ininfo Server
, I can get it directly when I get the instance configuration dictionary, which will become convenient and accurate that thisprocess_id
belongs to this instance only.config_file
ininfo Server
output Physical machine multi-instance deployment, the configuration file may have to use commands and paths to distinguish between the time to do monitoring and configuration files and instances of the configuration against the time need to get the contents of the configuration file, so I hope that according to the instance information can be directly access to the configuration file address, so as to carry out the subsequent monitoring of the metrics output, I hope to give support.Similar to : config_file:/home/dba/redis/redis6383/redis6383.cnf
Additional context I'm sorry I'm here to raise requirements again, hahaha, these requirements are trying to usability and reliability after using our dragonfly on-line to the production environment, I hope dragonfly is getting better and better, looking forward to the reply, together to discuss. 😃