In my last post, I walked through how Uptime Cloud Monitor (UCM) monitors Amazon, Microsoft SQL Server and Microsoft Azure SQL. In this post, I will walk through monitoring CouchDB with UCM.
If you do a simple Google search for CouchDB Monitoring you get a set of results which walk through the common metrics in which to monitor and why. CouchDB requires that each request start with an HTTP method, which is why you see so many HTTP metrics listed below. I will walk through the metrics below, in which I will take text directly from the documentation site for CouchDB to define what is meant by the metric.
Authentication Cache Hits – shows rate of authentication cache hits. More specifically, CouchDB keeps some user credentials in memory to speedup authentication process by elimination of additional database lookups. This cache size is limited by the configuration option auth_cache_size.
Authentication Cache Misses – shows rate of authentication cache misses.
DB Reads – number of reads per seconds
DB Writes – number of writes per seconds
Open Databases – shows amount of currently opened databases. CouchDB only keeps open databases which have seen some activity, been requested or running the compaction. The maximum amount of opened databases in the same moment of time is limited by max_dbs_open configuration option.
Request Time – request times based on sampling time frame.
Bulk Requests – shows amount of bulk updates were done
Total HTTP Requests – total of HTTP requests
Temporary View Reads – shows the amount of requests to the temporary view indexes
View Reads – show the amount of requests to the view indexes
HTTP COPY Responses – A special method that can be used to copy documents and objects.
HTTP DELETE Responses – Deletes the specified resource, including documents, views, and design documents.
HTTP GET Responses – Request the specified item. As with normal HTTP requests, the format of the URL defines what is returned. With CouchDB this can include static items, database documents, and configuration and statistical information. In most cases the information is returned in the form of a JSON document.
HTTP HEAD Responses – The HEAD method is used to get the HTTP header of a GET request without the body of the response.
HTTP POST Responses – Upload data. Within CouchDB POST is used to set values, including uploading documents, setting document values, and starting certain administration commands.
HTTP PUT Responses – Used to put a specified resource. In CouchDB PUT is used to create new objects, including databases, documents, views and design documents.
HTTP 200 Responses – 200 = OK. Meaning specifically, request completed successfully.
HTTP 201 Responses – 201 = Created. Meaning specifically, document created successfully.
HTTP 202 Responses – 202 = Accepted. Meaning specifically, request has been accepted, but the corresponding operation may not have completed. This is used for background operations, such as database compaction.
HTTP 301 Responses – 301 = Moved Permanently. Meaning specifically the resource attempting to be access has permanently move and been redirected.
HTTP 304 Responses – 304 = Not Modified. Meaning specifically that the additional content requested has not been modified. This is used with the ETag system to identify the version of information returned.
HTTP 400 Responses – 400 = Bad Request. Meaning specifically, a Bad request structure. The error can indicate an error with the request URL, path or headers. Differences in the supplied MD5 hash and content also trigger this error, as this may indicate message corruption.
HTTP 401 Responses – 401 = Unauthorized. Meaning specifically, the item requested was not available using the supplied authorization, or authorization was not supplied.
HTTP 403 Responses – 403 = Forbidden. Meaning specifically, the requested item or operation is forbidden.
HTTP 404 Responses – 404 = Not Found. Meaning specifically, the requested content could not be found. The content will include further information, as a JSON object, if available. The structure will contain two keys, error and reason.
HTTP 405 Responses – If you use an unsupported HTTP request type with an URL that does not support the specified type then a 405 - Resource Not Allowed will be returned.
HTTP 409 Responses – 409 = Conflict. Meaning specifically, the request resulted in an update conflict.
HTTP 412 Responses – 412 = Precondition Failed. Meaning specifically, the request headers from the client and the capabilities of the server do not match.
HTTP 500 Responses – 500 = Internal Server Error. Meaning specifically, the request was invalid, either because the supplied JSON was invalid, or invalid information was supplied as part of the request.
So this looks fantastic you say, but how do I go about setting this up and configuring it in my environment? Well I am glad you asked, that is a great question and it is very simple. 
Log into the UCM web console and click on the Custom Tab
Click CouchDB, It should navigate to Quick Install Page.
Install Couch DB on the server by using sudo apt-get install couchdb –y
Run the CouchDB script on putty command.
Once the script is run, it should prompt for agent name, group name, label name and frequency.
Followed by CouchDB Group details
Next the install will ask for Username, Password, Port and Host details. The install should also ask if you have another CouchDB to be configured.
The install will ask if init file should be configured. Enter Y and hit enter and the install should display “Install Complete”.
On UI Click Metric Groups from left panel, it should display the Metric group which has been created, with the same details giving during configuration.
Click Edit to see the Metric Group Metrics
Click Custom Objects from the left pane and select the object configured.
That’s it, simple as can be. Just click on details and see the metrics being monitored, then add them to your dashboards and alerts and you are set and good to go. Don’t believe me, log in and try it yourself or if you need a trial, create one here for 14 days free of charge. No credit card needed, no monthly commitments required.
The team is hard at work at more content and functionality. If there is an application or other functionality you are interested in seeing added to the product, please leave a comment here or email feedback-ucm@idera.com.