MarkLogic Server 11.0 Product Documentation

Query Performance and Tuning Guide — Chapter 7

Monitoring History Dashboard

The Monitoring History dashboard is used to capture and make use of historical performance data for a MarkLogic cluster. Once the performance data has been collected, you can view the data in the Monitoring History page. The top-level Monitoring History page provides an overview of the performance metrics for all of the key resources in your cluster. For each resource, you can drill down for more detail. You can also adjust the time span of the viewed data and apply filters to view the data for select resources to compare and spot exceptions.

For details on the Monitoring History dashboard, see the MarkLogic Server Monitoring History chapter in the Monitoring MarkLogic Guide.

Server Logs

The logs for MarkLogic Server are an important source of information about activity on the server, particularly information about error conditions. The logs are all stored in the Logs directory under the MarkLogic Server data directory (typically c:\Program Files\MarkLogic\Data\Logs in windows, /var/opt/MarkLogic/Logs under UNIX-based systems). There are two types of logs:

• ErrorLog.txt, which logs MarkLogic Server exceptions, startup activity, and so on.
• port_no_AccessLog.txt, which logs access requests (for example, HTTP requests) for the App Server running at the specified port.

You can configure how long to keep a log before starting a new one, at which level to log activity, and how many old log files to keep before deleting (they have a number appended to their name, for example, ErrorLog_5.txt indicates 5 new log files have been created since this one was used). For more details on configuring the log files, see the Administrator's Guide.

Another option you can configure, at the App Server level, is for any uncaught application exceptions to be written to the ErrorLog.txt file. This way, if your application throws an exception (for example, if it has a syntax error), the error message is logged in addition to being sent to the client. This is useful in debugging, especially if queries are being generated via user activity on a browser or through a WebDAV client.

You can also code your own log messages into an application using xdmp:log. You can use xdmp:log to log any message at any level, and that message is written to the ErrorLog.txt file when it is called. Log messages are useful in debugging during development, and are also useful in logging certain activities in production.

For operational purposes, some developers write scripts or programs to monitor the logs for specific messages. Then, if the specific message is logged, the script or program can send some sort of alert out (for example, page someone or send a message to someone).

The logs contain important information that can be used in monitoring MarkLogic Server. The logs can be a powerful tool in an overall monitoring policy. How you use that information depends on your requirements.

There must be sufficient disk space on the filesystem in which the log files reside. If there is no space left on the log file device, MarkLogic Server will abort. Additionally, if there is no disk space available for the log files, MarkLogic Server will fail to start.

Status Screens in the Admin Interface

The Admin Interface includes many pages that list current activity and status for various parts of MarkLogic Server. To access the status pages, click the status tab in the part of the Admin Interface to which you want to find current system information.

The following table lists the status pages available in the Admin Interface, along with the location path to the status tab in the Admin Interface and a description of each page.

Create Your Own Server Reports

The status pages in the Admin Interface provide a lot of detail about many parts of the system. If you want information about MarkLogic Server status in a different form, however, or if you want to combine it with some other application-specific information, you can build your own server reports using the Server Monitoring APIs. For more details, see the next section.