Through my searching I discovered the following troubleshooting steps to diagnose the issue:
- Make sure the Usage and Health Data Collection was configured:
- Go to Central Admin - Monitoring - Configure Usage and Health Data Collection.
- Validate that Enable Usage Data Collection was checked.
- Validate that Events were selected to log.
- Validate the Log File Location exists (SAVE THIS FOR THE NEXT STEP), it's usually "c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS\"
- Validate the Database Server and Name of database are set and correct
- Verify that the WSS_Admin_WPG and WSS_WPG groups both had full access to the Log File Location (FROM ABOVE) on all the servers.
- I made sure both the Microsoft SharePoint Foundation Usage Data Import and Microsoft SharePoint Foundation Usage Data Processing timer jobs were enabled and able to run successfully.
- The easiest way to get there is to go to Central Admin - Monitoring - Configure Usage and Health Data Collection - Log Collection Schedule link.
- This will take you to the Timer job definitions.
- Make sure both definitions are enabled, the data import job should run every 5 minutes and the data processing job should run daily.
- Validate that they run by clicking run now and monitor the running jobs and job history.
- Check the WSS_Logging (the database name configured in the usage service application configuration) database's permissions, the web service web application account and the farm account both have ownership rights over it.
- Check the contents of the WSS_Logging database, the request tables are populated with information.
- Validate that there are receivers configured per this blog post: http://geekswithblogs.net/bjackett/archive/2013/08/26/powershell-script-to-workaround-no-data-in-sharepoint-2013-usage.aspx. There is a fix within if they don't exist
- If none of this works, you can try adding a SQL server account to the database authentication, but every time I set this it reverted...you may only be able to set this on initial configuration.
- Check to make sure that data is being generated in the Log File Location in the RequestUsage folder. There should be a .tmp file and occasionally a .usage file will appear. After a few minutes the .usage files will disappear and be imported into the Event Store(every time the data import job runs).
- Check the EventStore (found on the analytics server (check in Search administration topology) usually in C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server in a folder named Analytics with a GUID, you can also try looking at the file shares on the active analytics server) verify information is being created there, it won't be identical to what is in the usage folder because that information gets filtered out.
- Check to see if there's anything there
- Make sure file sharing is enabled between the servers to the analytics processing server and that the WSS groups have write access in both file sharing and NTFS permissions to the EventStore.
As a note for all of these changes, nothing will be seen in the reports until the processing job runs, often you'll have to wait over night to see if your changes worked.
In the end, I noticed the eventstore hadn't generated anything since a couple weeks ago. I had to add permissions as described above to the log folder, the event store, enabled file sharing (port 445) and permissions, and made sure that permissions were set to the database. After all that, nothing was working still.
After setting all of that I deleted the service application from Manage Service Applications and recreated it by going to Monitoring - Configure Usage and Health Data Collection and checking the Enable usage data collection box. After that, the next day, we had results.
When in doubt, kick it.
For more info, here's an interesting blog post on how the data collection works with the EventStore: http://blogs.msdn.com/b/spblog/archive/2014/04/03/sharepoint-2013-usage-analytics-the-story.aspx