URL:
https://github.com/SSSD/sssd/pull/261
Title: #261: Add systemtap probes into the top-level data provider requests
jhrozek commented:
"""
On Tue, May 23, 2017 at 07:33:50AM -0700, Justin Stephenson wrote:
@jhrozek thanks a lot for your input and sorry for the delayed
response. I wanted to give a chance for other developers to provide any comments and I
know everyone is busy.
I will work on documenting the high-level probes as you mention in a `sssd-systemtap` or
`sssd-stap` man page and update the PR accordingly. Based on this, does it make sense to
add tests to ensure stability ?
I don't think tests are needed..
If you have other thoughts/suggestions i'm open to those, please go ahead and add
**Changes Requested** (as it looks like I cannot)
Finally I was able to find some time to play with the PR and I only have
one more suggestion which is to also print the `enum dp_targets target`
and `enum dp_methods method`. I think they change quite rarely, so it
might even be a good idea to provide a stringified representation of the
request types as we already do in src/systemtap/sssd_functions.stp for
acct_req_desc().
I think we can merge the code then and continue decorating the code with
other probes..I think the handlers of the respective providers could be
next so that the admin could observe not only what requests were
flowing, but also what the requests were actually for (e.g. that the
request was for a group called XXX, then the admin will know, if the
request was taking too long that they might want to suppress group
members or restrict nesting..)
"""
See the full comment at
https://github.com/SSSD/sssd/pull/261#issuecomment-303728425