-
Notifications
You must be signed in to change notification settings - Fork 17
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
Fix unstructured logging variable formatting #2029
Conversation
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.
looks pretty good! i marked a few things i think you mightve missed, and tried to change filename=
where it actually referred to a directory and not a singular file.
@@ -96,7 +93,7 @@ def run_module(params, logger=None): | |||
df = df.reset_index() | |||
sensor_name = "_".join([smoother, "search"]) | |||
if len(df) == 0: | |||
logger.info("No data for %s_%s_%s", geo_res, metric.lower(), sensor_name) | |||
logger.info("No data for signal", signal=f"{geo_res}_{metric.lower()}_{sensor_name}") |
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.
Match the above?
logger.info("No data for signal", signal=f"{geo_res}_{metric.lower()}_{sensor_name}") | |
logger.info("No data for signal", geo_res=geo_res, metric=metric.lower(), sensor_name=sensor_name) |
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 wasn't sure since the original log wanted to capture it as a signal and not into seperate metric, sensor, geo....
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.
Yea, these old pipelines like to mix together geo resolution, metric and sensor name into a single name and call it signal, though that doesn't match our definition of signal anywhere else. Seems better to me to separate these out, since then you can do granular search in the logs without doing substring search.
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.
Two lines below this is a call to create_export_csv()
which combines metric and sensor in the output file name, in what will ultimately be the signal name. How about:
logger.info("No data for signal", signal=f"{geo_res}_{metric.lower()}_{sensor_name}") | |
logger.info("No data for signal", geo_type=geo_res, signal=f"{metric}_{sensor_name}") |
Should we use this opportunity to add better logging to create_export_csv()
? @aysim319, you have something planned to change doctor visits and hospital admissions to use this method, right? Perhaps we can add the logging then.
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.
yeah.. I think it's better to revisit once all the indicators are using create_export_csv... because at least for hospital-admissions it doesn't quite use the metric and the sensor combination if I recall
Ah yeah, that was an intentional choice. I didn't see any output_path being used and it techincally also has the filename so whynot and worst comes to worst someone tells me it's not right and i'd fix it. |
Co-authored-by: george <[email protected]>
im gonna set this to "draft" and then back again to try to get ci to re-run |
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.
We'll likely make more adjustments, but this seems like a nice incremental change for the better to me. Let's make an issue to follow up on a few more changes once all indicators are migrated to create_export_csv.
…025-fix-unstruc-logging
The second one is one that I missed and third one, I didn't feel like parameterizing a wrong value made sense, but I could also see why it would be helpful... But for the rest, I think it's better to leave it as is as they're debugging logs where I think seeing the message as is seems more helpful instead of having it parameterized. Edited changed all of the instance |
@dshemetov since you and david is planning a formatting PR, thought I ping you about this in _delphi_utils.delphi_utils.runner.py
CI wants multi-line
|
Hm, is it resolved now or did you have to manually adjust it to make CI happy? I might need to point the format commands in both CI and Makefiles to the pyproject.toml just to eliminate the possibility that they're not finding it (it specifies line-length = 120 there and this seems like a disagreement about line-length). |
I had to manually adjust it .... :/ |
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.
last ones!
@aysim319 i removed some stray files that somehow wandered into your last commit, and i changed the format of a reverted logger call back to make it pass linting. |
Description
replacing logging with f strings with parameters
Associated Issue(s)