SP2016 site usage logging not working: no online instance for service Microsoft.SharePoint.Administration.SPUsageService

Question

I want to capture usage logging in a single server SharePoint 2016 in order to know which pages are being accessed and by which user. Nothing more and nothing less.

I went into Configure usage and health data collection under Central Administration and configured it a follows:

• Enable usage data collection: Enabled
• Events to log: Page requests
• Enable health data collection: originally disabled, but now selected

I wonder if enable health data collection should be selected? What is the implication of not having this selected? Would I still have the event(s) I selected (i.e. page requests) logged into the database?

If I click on log collection schedule and I then click on the jobs and choose to "run now", the job does not run. There is nothing in the job history to indicate that the job was run or not. All 3 jobs are enabled. View health reports gives me nothing. Also there are no errors or warnings reported at all.

What am I doing wrong?

EDIT1: I noticed that the "Usage and Health Data Collection Proxy" was stopped, so I managed to start it by following the instructions here (why was this stopped? bug?). Regardless I still can't seem to make those jobs run.

EDIT2: Upon further investigation, we found out the following error in the SharePoint ULS logs:

Job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition, id aee32ef7-5eee-4a06-a40f-a46d9aade916 has no online instance for service Microsoft.SharePoint.Administration.SPUsageService, id ee820682-3a34-4d36-a05e-79135ee82a22, ignoring

The following screenshots confirm that the error is pertinent:

Answer 1

Symptom:

Capture usage logging in a single server SharePoint 2016 in order to know which pages are being accessed and by which user

Microsoft SharePoint Foundation Usage Data Import job doesn't run Imports usage log files into the event store.

Cause:

SPUsageService Provisioning issue We found that there was a mismatch in the ID of the timer job

Resolution Summary:

The following commands had to be executed in a SharePoint PowerShell session (admin mode):

$instance = Get-SPUsageService
$instance.Provision()
$instance.Update()

I will post a full description of the problem later on. I simply don't have the time or the energy at the moment!

NOTE: I would like to restate that search is NOT required for these jobs to run. Whoever says it is, has no idea of what they are talking about. Amazingly, some people at Microsoft itself does not understand their own product. I had to waste about 2 days with their support engineers to prove them that search isn't required. Yes, like many others here I do know we need the search service for the out of the box reports to work, but this has NOTHING to do with these timer jobs failing. Plus the search service is irrelevant if you create your own reports from the populated database -- which is my case, which I made crystal clear from the start.

Answer 2

Thanks for such a clear explanation of the problem and resolution, pmdci! I had something very similar - I have a 4 server SharePoint 2016 farm running on SQL 2017 AlwaysOn, and per Microsoft's recommendation, the usage DB was not included in an availability group. I had a failover event, so SQL2 became primary, and I frankly forgot to do anything about the Usage service DB (we're just starting to use it).

The transaction logs on the Usage DB filled the log drive on the #1 server because our maintenance jobs were only running on the primary (#2), and after much gnashing of teeth, we decided to remove and rebuild the Usage service, placing the DB on SQL2.

Two months after doing that, the E: drives on my SharePoint servers were filling up, and it was because the Usage DB log location was growing. The timer job is supposed to clear the .usage files after it sweeps the data inside those files into the database, but that wasn't happening.

After finding your post, I found that the four instances of my SPUsage service (one for each server in my farm) were all disabled. Re-enabling them kicked things into gear, and the .usage files were deleted and swept the data into the DB, as expected.

The one variation I had was that I couldn't execute the looping script that Ben Lime posted from a single server because I would receive an error saying the instance couldn't be provisioned because it was on another server.
$instance.Instances | ForEach { $.Provision(); $.Update() }

I had to identify which service instance was homed on which server, and then provision the instance from each server. Not sure if that's something weird affecting only me, or if it is a global thing, hence this post to let folks know.

Enumerate all instances to see which one was on which server:

$instance = Get-SPUsageService

$instance.Instances | Format-List id,server

Login to each server and run (replace the GUID with the GUID matching the instance that lives on that server from the previous step):

$instance = Get-SPUsageService

$serverinstance = $instance.instances | where id -like 'bdac140f-dc51-40f3-b6c2-b4d0585b5b34'

$serverinstance.Provision()

$serverinstance.Update()

Check to make sure all are online:

$instance = Get-SPUsageService

$instance.Instances