Service Usage Statistics By User

BillMitchell

At my organization, we maintain a number of different services that are used by a variety of clients. We need to bill clients for the services they use, so two questions come up fairly frequently:
1) Which users are using service X, and

2) How much is user Y using service X?

It would be very helpful if, in addition to the statistics on overall service usage available from ArcGIS Server, there were also a breakdown of which users were making requests. This functionality is also helpful when working with deprecated services, because it provides an easy way to see which users we need to contact about moving to new services.

The requests are generally already using the ArcGIS Server or Portal authentication, so logging (timestamp, service, user) and then getting statistics on that should be fairly straightforward.

John_Spence · ‎07-06-2022

You could give this a whirl to see if it helps you out https://github.com/wagisdev/AGOL-Meta-Snagger.

It can snag data about all your items in AGOL, how many are owned by a user, the use of those services (can't tell by who, but it does give you a count), etc. I used it to build dashboards like this.

BillMitchell · ‎07-06-2022

What I need is statistics like the following:

Sample World Cities usage, 6/1/2022-6/30/2022

User	Requests
Robin	15
Taylor	8
Jamie	22
Alex	142

Being able to export the (timestamp, service, user) data to use with other analytics tooling would be a nice bonus, but the basic per-user usage report is the main ask.

John_Spence · ‎07-06-2022

Sorry to say, but that is likely not easily possible. You might be able to narrow it down to the clients IP range via IIS, but you would have to parse those logs pulling out every call and determine which ones you want to count.

BillMitchell · ‎07-06-2022

Right. This would need to be implemented by Esri, which is why it's posted in the ArcGIS Enterprise Ideas forum. There is an authentication routine happening when the ArcGIS Server service is being used, and in that authentication routine logging the timestamp, user, and endpoint should be known to the handling function. It may need to be logged to a separate file or given a certain tag or something, but collecting these usage statistics shouldn't be that difficult and it would be very helpful.

John_Spence · ‎07-06-2022

LOL! Oh no! I am obviously not firing on all cylinders this morning. Sorry about that and yes...that is a good idea.

BillMitchell · ‎09-14-2022

After further discussions with Esri, they suggested that there was certain logging that could be done already and then parsed via a system log parser. In investigating that option, I found that it required the log output level to be set to Fine rather than where we had it set, Warning.

I changed the log level to Fine, and soon started seeing user/service events being logged (they're Info level, and event code 9029). For log export, there's an API endpoint which can pre-filter to just the event code you're looking for over a specified time. Logs are also stored in the /arcgisserver/logs/ directory. The user/service events (code 9029) are in the /arcgisserver/logs/server/ directory, though response information can be found in the /arcgisserver/logs/services/<service> directory.

One potentially significant caveat, though, is that if a user is geocoding/reverse-geocoding sensitive information, the response to their query will be logged at the Info level too. This is an unfortunate design choice, and we are still considering how to handle measuring geocoder usage via metadata while not logging any of the data being sent/returned. We may have to implement a Server Object Interceptor (SOI) to log just what we need instead of changing the ArcGIS Server log level.

John_Spence · ‎09-14-2022

Oh that is good info and makes sense as that is the same configuration needed for ArcGIS Monitor. Thank you for the update!

BillMitchell · ‎12-12-2023

To clarify what this request is really getting at, let me explain why we need this feature. I work at a state geospatial agency, which offers enterprise GIS services and support to other agencies and boards within the state government. We are funded through direct appropriations, but primarily through service contracts with the agencies we support. For ventures such as our in-house geocoding service, we need to charge back for the cost of providing that service. Some of the agencies using these services are wary about logging, since they deal with personally identifiable information, personal health information, or other sensitive/protected data types. To alleviate those concerns, we need to minimize our logging of request and response data.

We may have a large agencies (for instance, department of health, department of public safety), where geocoding is part of high-traffic automated business processes that generate around 10k geocodes/day. Meanwhile, a small board may need to geocode 100 addresses or so every quarter. Without data on the usage of these two, in order to recover costs for the geocoding service, we either charge a flat rate for both clients (which seems unfair to the small agency), or make some guess about the relative cost of support and try to proportion it out subjectively. Having per-user service usage statistics would allow us to create a data-driven cost recovery model, not unlike the credit system used by the Esri world geocoder.

Other services, such as a statewide parcel service, may have disparate usage by various applications. Knowing the relative usage can again help apportion costs of providing the service, or demonstrate who might need to be approached regarding the need for improved service reliability/performance.

There are other benefits to having the service usage statistics broken down per-user. If we are deprecating a service, it could let us find out easily who/what application is still using the old service. Or if there were questions about a dataset, identifying the frequent users may point to which users have expertise in that data.

BillMitchell · ‎06-17-2024

There is an enhancement request for this feature, ENH-000164419.

AnjulPandey

Thanks @BillMitchell , I would appreciate it if you could share the URL for this ENH-000164419 enhancement so I can check its status. I searched for this ENH-000164419 enhancement on Google, ESRI Community site, ESRI bug site but was unable to find any additional information.