This topic provides an overview of the event categories and types that are recorded in event logs. It also lists some of the factors that determine how much historical data is retained.
Event categories and types
When you view data logged from system or user activity, one of the ways to filter that data is to select a specific event category. When you do this, the view is broken down by event types for the selected category. Event types represent the specific actions or errors that occurred, such as a power-state transition to sleep or wake, a user action that delayed a power-state change, and so on.
The following table lists the event categories and describes the event types logged under each.
|Admin Actions||Includes all manual transitions to low-power states that an administrator sets on devices.|
|Idle Timer Actions||Transitions to low power states that occur specifically when the client is inactive (idle) for the length of time set in the policy assigned to it.|
|Policy Actions||This category includes events that occur through power state transition manager (PSTM) rules, and other events that occur when policies set schemes and change power states.|
Other events recorded in this category include initial power scheme value when the client service is started, when a power scheme is set according to the policy schedule, when scheme is set by the user (because the scheme is created to allow the user to override it), and so on.
|Scheduled Actions||Any power-state change that occurs according to the schedule set in the policy assigned to the client.|
|Service Events||Events logged by the client service, such as start, stop, or device check in. Events also include new database creation, and if data collection stops or starts for power state changes and user activity.|
|State Changes||Detailed power state change data and the request source (Surveyor server, a third party, or an unknown trigger). Also includes display-only logs for power-state changes.|
|User Actions||This category includes events that are logged when users take actions on power schemes or power-state change notifications, when you make these actions available to them through the policy configuration. For example, you can allow users to skip or delay a power-state change or to change the power scheme in the Windows Control Panel.|
|User Activity||Events that indicate whether a user is active or not, whether a transition to a low power state based on idle time is pending, and if user activity is unknown (in which case data and activity collection may have stopped, which will be indicated by an event in the Service Events category).|
|Configuration Errors||Errors setting, querying, or deleting a power scheme; changing wake settings on mouse, keyboard (including whether it’s a USB device); or loading, parsing, or saving .config files.|
|Policy Errors||Errors that prevent a PSTM rule from running. For example, PSTM fails to veto a power state change, terminate an application, or report that an application has terminated.|
|Service Errors||Errors that cause the client service to stop running properly. For example, the client computer loses power abnormally; the service fails to parse or run a request from the power management service; performance counter for the idle timer missing or failed; errors that occur while querying the user or display state.|
|Transition Errors||Problems that occur when the API for a power state transition is called but returns a failure code; errors occurring while processing a power state transition; failure to dispatch a Wake on LAN magic packet; unexpected errors while trying to prevent narcolepsy (computer transitions to sleep while in use).|
|EnergyWise Power Level||Events that occur in the setting or operation of any of the 11 EnergyWise power levels.|
If you want to make the event report view more granular, you can combine the event category filter with any combination of the other standard filters that are available for searching. For example, view successful transitions for a particular policy or user actions in a particular device group or subnet.
How much data is retained
The historical period for which you can report on events depends upon a variety of system factors. These include the number of devices being managed, the reporting interval, the database server hardware, and so on. These factors determine the rate at which events are generated and the speed at which the database can process large numbers of events.
Under reasonable circumstances, you should be able to view events for 2–7 months in the past. However, you might need to trim the data sooner to achieve acceptable performance.
The Surveyor database contains a table for all events, along with a separate table for PC power state and user activity events. The latter events are retained for a longer period of time than error events. Error events are generally used for troubleshooting and resolved relatively shortly after a problem occurs.
Where to find client log files
Log file location:
C:\Program Files\Verdiem\Surveyor Agent\Logs
Log file names:
- The current file is named PwrMgrService.log.
- Files that contain older log messages are named PwrMgrService.log.1, PwrMgrService.log.2, and so on.
On 64-bit versions of Windows, the client agent folders and files are under Program Files (x86).