How to monitor Couchbase with Google Cloud Ops

You can now easily monitor couchbase metrics and logs in Google Cloud. All of our logging and monitoring Google Cloud contributions are available through the Google Ops Agent GitHub repository. You can check it out here!

The Google Ops Agent uses the built-in Prometheus exporter and receiver to monitor Couchbase sources running Couchbase 7.0. You can find documentation on the Prometheus exporter in the Couchbase documentation. Information on the Prometheus receiver is available in the observIQ OpenTelemetry distribution on GitHub.

What signals matter?

Couchbase is a distributed noSQL database. It’s easy to distribute across multiple systems and scale. Signals that are often monitored on Couchbase include evictions, errors, and memory usage, as well as access logs:

Spiking Evictions
- If ‘bucket.item.ejection.count’ spikes, it could show that there is unexpected memory pressure.
Unrecoverable OOM Errors
- If ‘bucket.error.oom.count’ signals unrecoverable errors, it indicates that the couchbase server is running out of memory and is unrecoverable.
High Memory Usage
- If ‘bucket.memory.usage’ bytes is higher than what is anticipated, it could show that the bucket needs to be allocated more memory.
Couchbase HTTP Access Logs
- These access logs indicate what kind of traffic the couchbase is undergoing via its REST API. Could be an indication of bad requests or if things are operating normally.

All of the above categories can be gathered with the Couchbase receiver – so let’s get started.

Before you begin

If you’re already a Google Cloud user, You can set up your Google Cloud workspace to receive metrics and logs by following Google’s Ops Agent documentation.You can find installation and setup instructions here.

Configuring the Couchbase receiver

Navigate to your Ops Agent configuration file.

/etc/google-cloud-ops-agent/config.yaml (Linux)
C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml (Windows)

Edit the configuration file to include the Couchbase receiver as shown below:

metrics:
 receivers:
   couchbase:
     type: couchbase
     username: admin
     password: password
     collection_interval: 30s

In the same yaml config file, add Couchbase into your Service pipeline so it looks similar to the following. Note that your processors and exporters will likely be different, and you will need to insert your admin username and password.

service:
   pipelines:
     couchbase:
       receivers:
         - couchbase

logging:
 receivers:
   couchbase_general:
     type: couchbase_general
   couchbase_http_access:
     type: couchbase_http_access
   couchbase_goxdcr:
     type: couchbase_goxdcr
 service:
   pipelines:
     couchbase:
       receivers:
         - couchbase_general
         - couchbase_http_access
         - couchbase_goxdcr

You can further edit the config file to include specific labels under the “processors” field, but the Google Ops Agent already has default labels for the data collected.

Relevant Editable Fields in Config:

Field	Default	Description
type	required	Must be couchbase
endpoint	localhost:8091	The address of the couchbase node that exposes the prometheus exporter metrics endpoint
username	required	the configured username to authenticate couchbase
password	required	the configured password to authenticate to couchbase
collection_interval	60s	A time.Duration value, such as 30s or 5m

Viewing the telemetry collected

If you followed the steps detailed above, the following Couchbase metrics will now be delivered to your preferred destination.

List of Metrics Collected:

Metric	Description
bucket.operation.count	Number of operations on the bucket
bucket.item.count	Number of items that belong to the bucket.
bucket.vbucket.count	Number of non-resident vBuckets
bucket.memory.usage	Usage of total memory available to the bucket
bucket.item.ejection.count	Number of item value ejections from memory to disk
bucket.memory.high_water_mark.limit	The memory usage at which items will be ejected.
bucket.memory.low_water_mark.limit	The memory usage at which ejections will stop that were previously triggered by a high water mark breach.
bucket.error.oom.count	Number of out of memory errors

observIQ’s distribution of the OpenTelemetry collector is a game-changer for companies looking to implement OpenTelemetry standards. The single line installer, seamlessly integrated receivers, exporter, and processor pool make working with this collector simple. Follow this space to keep up with all our future posts and simplified configurations for various sources. For questions, requests, and suggestions, reach out to our support team at support@observIQ.com.

The Observability Blog