Sections Server Health Check
Manual informationServer Health Check
1.1 | Dec 16, 2021 | Improve document branding | VP Dev
Document conventions
Convention | Explanation |
|---|---|
Bold | For file names, commands, fields, menus, options, and window names. |
Courier New | Commands as you should type them. |
Lucida Console | Example output generated by the system. |
Italics | For configuration variables, including variable portions of file names and URLs. Also indicates a document name. |
Note / Blue Callout | The Blue Callout text indicates information that is of special interest or importance, an idea that could be useful or additional information about a product or a feature. |
| The Caution icon along with the text indicates actions that can lead to problems in system operation or configuration settings if the instructions are not followed properly. |
Revision history
This section tracks the initial creation of the document after each major version thereafter.
Ver: | Date | Description | Reviewed / Approved By |
|---|---|---|---|
1.0 | Nov 8, 2021 | Initial Version | Team |
1.1 | Dec 16, 2021 | Improve document branding | VP Dev |
Purpose#
This guide is intended to be used by IT staff to identify aspects of Viewpoint which can be monitored to detect unexpected system outages. The audience is expected to be familiar with general IT terminology. This guide does not require or promote any particular 3rd party monitoring product.
Aspects to Monitor#
Hardware Checks#
For each PC in the Viewpoint solution – including database servers, the file store, web servers, worker PCs, Click-Once deployment PC (if Click Once is used) and any hosting server (Citrix, Terminal Server etc.) Checks should include:
- Verify sufficient free HDD space
- Check for unusually high sustained CPU usage
- Check for unusually high memory load
File Store#
Periodically verify read access to the file store. Select a file in the file store and ensure that it can be read.
Database#
Viewpoint uses two SQL Server instances per environment. Perform general health checks on each database, such as ensuing that a user can log into the LDControl database without error.
Web Server#
Test each web server in the farm. Below are two ways to test if the web server is serving up web pages:
Method 1: Simple HTTP test
Perform an HTTP GET on the web root. It will redirect you to the login page. Be sure that you receive a 200 response and a valid HTML document in your response. Perform this task on each web server.
Method 2: Login and execute a web method (Viewpoint 7.2 and later)
To perform a login you will need to have a valid username / password. You will also need to know the ProjectID of an active Viewpoint Project which you can use to execute a simple search. Viewpoint Web uses bearer tokens for authorization. These tokens are specific to a user / web server and will time out after a set duration (typically a few hours). Viewpoint exposes a Swagger page (found at $/swagger/index.html) which you may choose to use to assist you in crafting your HTTP requests.
First call web method $/api/GetTokenFromBasic with a valid username and password. You will receive the bearer token in the response. The response will b e a JSON package – look for the “token” property.
Second, execute $/api/Project/CountByCustodian/{projectId} using the bearer token you received from the call to GetTokenFromBasic and the ProjectID of an active Viewpoint Project. To use the bearer token add a it as a property to the HTTP Header with the name “Authorization”. Your result will be a number. By performing this operation you have asserted that the web server and the database server are able to serve content.
Detect Excessive Soft Errors#
Execute the following MSSQL query on the LDControl database of both Review and Processing. The query will return the number of errors encountered in the past 8 hours – if you detect an extreme amount for your population, for example 10,000 errors, it is possible that a process is failing and the logs should be examined.
DECLARE @hours int; set @hours = 8
select COUNT(*)
from log with (nolock)
where Level = 'error'
and Date > DATEADD(HOUR, -@hours, GETDATE())
The user executing the query requires at least VP_USER role access.
