-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modifying logic to provide metrics per MINIO endpoint #83
Modifying logic to provide metrics per MINIO endpoint #83
Conversation
@nsarras, why the commit message is empty? don't we follow any specific commit message template? |
I am not sure what you are referring to, each commit has a message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each thread is having its own logger thread to log into their own files. This is not right way to do. We need to implement Queue handle based logger (you can borrow from DM repo) and pass the logger function handle to the thread.
if each thread is writing their log files, then someone has to go through all the files to debug
dss_metrics/metrics.py
Outdated
|
||
os.makedirs(os.path.dirname(logfile_path), exist_ok=True) | ||
if not os.path.exists(logfile_path): | ||
os.mknod(logfile_path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
os.mknod() is used to create /dev/ usually.
Instead of that you can do
with os.open(file_path, flags) as f:
pass
@nsarras, I mean
|
dss_metrics/minio_rest_collector.py
Outdated
continue | ||
metrics_data_buffer.append( | ||
metrics.MetricInfo( | ||
metric[0], metric[0], metric[1], tags, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why pass metrics selectively?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is because we may not want to expose all metrics to the end user all of the time, hence why we filter using a whitelist if the filter flag is given
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, why not metrics.MetricInfo(metric, tags..)
? Let MetricInfo
filter out.
metrics.MetricInfo(metric[0], metric[0], metric[1], tags,
doen't really help readability, else its better to use named params.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See new commits on PR, I made a lot of changes and not using this approach anymore
@mssawant I think you have a good suggestion and would be open to adopting that if we have the entire team agree that we want all of the details in each commit vs JIRA. The standard should be consistent across the team, and if you see other commits, the commit messages just indicate what was done, vs give a full summary & justification. |
@nsarras, good that you find my suggestion helpful. So, is this code open? if so, community does not have access to internal Jira servers. Even though is the code is used for internal purposes, an elaborate commit message helps to give more defined information about the problem and corresponding fix to someone who is just looking at git history searching for a particular case. |
…, add scope tagging for metrics, other bug fixes
Kudos, SonarCloud Quality Gate passed! 0 Bugs 0.0% Coverage The version of Java (11.0.17) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can fix those issues if needed. otherwise looks good
while True: | ||
time.sleep(1) | ||
except Exception as error: | ||
print(f"Failed to start Metrics http server: {str(error)}") | ||
logger.info(f"Failed to start Metrics http server: {str(error)}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can call logger.exception to catch the backtrace
|
||
name = key | ||
metric = Metric(name, key, 'gauge') | ||
metric.add_sample( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this kind of code just increases the lines decreasing the readability.
If the logic is too complicated, makes sense to have each lines for arguments
No description provided.