You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When invoked as a plugin, the ProjectName attribute in the job ad should be set to a string that is the relevant monitoring ID for the OSDF.
Right now, we aggregate our monitoring by looking at the path prefix and guessing who is accessing the data from the path name. This is bad because:
We have to document all the known prefixes by hand. These are ever-evolving and we are always behind the ball in doing the manual updates.
The person storing the data is not necessary the person accessing the data.
Multiple prefixes are based on usernames which shouldn't be exposed to the monitoring system (only the relevant project is considered public information).
When present, let's add the project name to the user agent data.
We'll have to do a corresponding change on the xrootd server side to pass through the user agent to the monitoring subsystem -- let's at least get it populated though!
The text was updated successfully, but these errors were encountered:
When invoked as a plugin, the
ProjectName
attribute in the job ad should be set to a string that is the relevant monitoring ID for the OSDF.Right now, we aggregate our monitoring by looking at the path prefix and guessing who is accessing the data from the path name. This is bad because:
When present, let's add the project name to the user agent data.
We'll have to do a corresponding change on the xrootd server side to pass through the user agent to the monitoring subsystem -- let's at least get it populated though!
The text was updated successfully, but these errors were encountered: