The Observer Actions are a way to track any number of metrics on your ServiceNow instance. These metrics are then packed into messages and sent through MBS to access through your Observer portal. We provide a set of out of box actions to detail response, application, transaction, and operation metrics.
The actions can be found by going to the Actions module underneath Observer, or by going directly to the (u_psp_actions) table.
These actions are executed through three different scheduled jobs. “Perspectium Observer Actions,” “Perspectium Observer Actions Hourly,” and “Perspectium Observer Actions Daily”. The first option defaults to run every minute, the Hourly job runs every hour, and the Daily job runs every day.
The Hourly option was added so users can schedule high volume actions to run hourly instead of the default minute job so as to minimize impact on a customer's instance.
You will see some of these jobs “Execute” column as “On Interval,” as “Hourly, or as “Daily”. This will correspond to the ”Perspectium Observer Actions,“ ”Perspectium Observer Actions Hourly,“ and ”Perspectium Observer Actions Daily“ respectively.
You can modify these Actions to be daily metrics if you would like this data, but at a macro level as opposed to the interval based updates.
Similarly, if you have a ServiceNow instance which has many application nodes (10+) you may want to modify your ”Perspectium Observer Actions“ to a more conservative interval to start with. A common recommendation is to modify it from 1 minute to 5 minutes.
These Actions will only execute if their Active flag is set to true. You may de-activate the metrics which you do not care about without impacting any of the other metrics.
The “Start All Jobs” module will re-active the Scheduled Jobs responsible for processing these actions, but it will not re-active any of your de-activated Actions. The same logic applies for the “Stop All Jobs” module.
This portion is to provide a high level explanation of the Actions and metrics which we track. Under the “Interval” column are recommendations for the type of job (Default, Hourly, Daily) that Action should run on.
|Active Requests with Closed Items||Will poll the request table (sc_request) for those which have requested items (sc_req_item) which are no longer active.||Keep track of requests which are no longer valid/necessary.||Hourly|
|Caller is deactivated on incidents||Will poll the incident table for active records whose caller (caller_id) is no longer active||To track the count of incidents where the caller is no longer valid||Hourly|
|Approval on Closed Tasks||Will poll the Approval table (sysapproval_approver) for approval requests on an inactive task||Keep track of approvals which were not completed in time or properly.||Hourly|
|Approver is deactivated||Will poll the Approval table (sysapproval_approver) for approval requests on where the assigned approver is inactive||Keep track of approvals which were not assigned properly.||Hourly|
|Open Tasks with Assigned to Deactivated||Will poll the Task table (task) for those which are assigned to an inactive user||To track when tasks are improperly assigned. Can also be easily modified to track the count of unassigned tasks.||Hourly|
|Local User Accounts||Will poll the User table (sys_user) for a count of local users, by keying off the “source” column.||Track the growth of local users on an instance.||Daily|
|External User Accounts||Will poll the User table (sys_user) for a count of external users, by keying off the “source” column.||Track the growth of external users on an instance.||Daily|
|Inactive Users||Will poll the User table (sys_user) for a count of user's who have not logged in the last 60 days||Track user access/retention on an instance.||Daily|
|Aggregate Active User Roles||Will aggregate the data for the count of user's who have been granted each role (sys_user_has_role)||To track how much access has been granted to certain areas of the instance.||Daily|
|Application Access Count||Will aggregate the data for the count of user's who have accessed certain applications, per application. Done through polling the app usage table (ua_app_usage)||To track the traffic of each application||On Interval|
|Import Set Queue||Over the last 60 seconds how many import sets (sys_import_set) are in each state (processed/loading/loaded)||Track how “backed up” the instance is in processing its import sets.||On Interval|
|Import Set Run Queue||Over the last 60 seconds track the counts of all the states of the current Import Set Runs (sys_import_set_runs)||Track the current processing of the Import Sets.||On Interval|
|Customer Updates||Over the last 60 seconds how many customer updates were made (those which are tracked in sys_update_xml)||Track how much work is being performed on the instance.||On Interval|
|Email Queue||Over the last 60 seconds track how many emails (sys_email) are in each state are in the instance.||Track how many emails you are generating compared to how quickly you are sending them out.||On Interval|
|Observe Nodes||Track the computing/sql metrics of each node (as well as averaged) on the instance||Track the CPU usage, response metrics, SQL response metrics, available semaphores, worker threads, etc. Type “stats.do” in the filter navigator for an example.||On Interval|
|Run on Login Failed||Ran when the event “login.failure” is fired||Track login failures on an instance as well as the common users which see this.|
|Daily Health Check||Ran nightly to capture a common set of data.||You can read more about the metrics here.|