Add logging for Jira service methods

[grahamalama]

Add logging for all Jira service methods:

• fetch_visible_projects
• check_health
• _all_projects_visible
• _all_projects_permissions
• _fetch_project_permissions
• _validate_permissions
• _all_projects_components_exist
• _all_project_issue_types_exist
• get_issue
• create_jira_issue
• add_jira_comment
• add_jira_comments_for_changes
• delete_jira_issue_if_duplicate
• add_link_to_bugzilla
• clear_assignee
• find_jira_user
• assign_jira_user
• update_issue_status
• update_issue_summary
• update_issue_resolution
• update_issue_components
• update_issue_labels

[bsieber-mozilla]

Could we possibly reuse the instrumentation (we use for statsd) to add these logs?

jira-bugzilla-integration/jbi/services/common.py

Lines 37 to 44 in 26255e9

	def wrapper(*args, **kwargs):
	# Increment the call counter.
	statsd.incr(f"jbi.{prefix}.methods.{func.__name__}.count")
	# Time its execution.
	with statsd.timer(f"jbi.{prefix}.methods.{func.__name__}.timer"):
	return func(*args, **kwargs)
	return wrapper

[grahamalama]

That's a good idea, and I thought the same thing 🙌🏻. Some thoughts there:

• We might want to log both client methods (via the decorator you linked, or maybe a new decorator) and service methods (the methods contained in this issue). Logging service methods would be good for when we bail out of a method, such as delete_jira_issue_if_duplicate:

        jira_key_in_bugzilla = latest_bug.extract_from_see_also(
            project_key=context.jira.project
        )
        _duplicate_creation_event = (
            jira_key_in_bugzilla is not None and issue_key != jira_key_in_bugzilla
        )
        if not _duplicate_creation_event:
+           logger.debug("No Jira issue to delete")
            return None

• I wish we "owned" the Jira client, I've tried to think of a few ways to inject our request ID into logging so that we can correlate requests, and it's ended up feeling a little invasive.

[bsieber-mozilla]

Upon quick glance--most of the service methods call the client methods; so we'd be logging as we make the service call internally, and then as we make the client call. Some of the service methods are minimally different than the client ones, but I can imagine there being value in a more in-depth breadcrumb trail for logging.

What if we followed a similar format that we did with the client logging: create a decorator and apply it to the service methods in question--possibly format with method_name: {method_name}; parameters: {parameters}; results: {results} (not pushing for this as a solution--just a formulaic possibility)

...As I write this out--it depends on what we plan on using this information for and how it would be most useful for our team; if we wanted to be able to follow an error stack to determine where something went wrong? For audit trails (for a bug_id)?

//It might be worthwhile to have a context object that tracks the methods and results and submits it all to the logging agent when the processing finishes? //

(fin brain dribble 😵 )

[bsieber-mozilla]

It might be nice to have a visual as to where we're at with our current logging practices to understand where our largest "holes" are to cover.

And if our current logging is not at all where we want to be--then rethinking the entire logging strategy could be worth some time (but possibly something we do at a later time--not to take away from this card, as there is still value by increasing the transparency of what the service is doing).