Supervisión de Couchbase

Supervisión de Couchbase

Couchbase es una base de datos distribuida, de alto rendimiento, Cache y NoSQL en una arquitectura de clúster único. A pesar de un nombre similar y una herencia compartida, Couchbase es un producto muy diferente a CouchDB o cualquier otra oferta NoSQL. Es fundamental poder monitorizar y perfilar el rendimiento de Couchbase junto con las métricas de la aplicación. Con el tiempo, la monitorización es el elemento para un despliegue exitoso de cualquier sistema de misión crítica. Esto es cierto en general y aún más importante en entornos de computación distribuida en particular. Es la única forma de garantizar el éxito a largo plazo. Para esta discusión, queremos centrarnos en la monitorización, pero es importante tener en cuenta que proporcionamos registros verbose de Couchbase para facilitar la solución de problemas de la aplicación. Estos registros se almacenan en '/opt/couchbase/var/lib/couchbase/logs'. Para obtener más información sobre estos registros por favor revise el registrador de vuelo Couchbase (https://www.couchbase.com/blog/couchbase-server-recorder/).

Couchbase proporciona una consola de administración rica en información y todo lo capturado en nuestra consola también está disponible a través de utilidades de línea de comandos y nuestra interfaz REST. Como resultado, no sólo proporcionamos las estadísticas necesarias, sino que facilitamos herramientas de terceros para supervisar clústeres de producción de misión crítica. Aunque nuestro clúster almacena información histórica, agregamos los datos a lo largo del tiempo para ahorrar espacio y las herramientas de terceros pueden realizar sondeos a intervalos regulares para conservar la información histórica. 

Buenas prácticas de supervisión

Así que vamos a meternos en harina...

Para monitorizar Couchbase eficientemente necesitamos dos perspectivas diferentes. El clúster en su conjunto está formado por nodos o servidores individuales. Cada nodo proporciona nuestra capacidad de cálculo para cualquier aplicación que aproveche la base de datos distribuida por el clúster. En consecuencia, queremos supervisar el consumo de recursos y la capacidad de cálculo disponible por nodo. Dentro de cualquier aplicación específica también queremos saber cuántas peticiones se están sirviendo a través de la caché y estar seguros de que nuestro disco es capaz de persistir los datos rápidamente en el disco. A medida que repasamos las métricas a continuación, debemos tener en cuenta que el comportamiento de nuestro clúster dependerá de lo que demande nuestra aplicación. Nuestro objetivo es gestionar un conjunto de trabajo en memoria y detectar eventos de alerta temprana que indiquen que se necesitan nodos adicionales en el clúster.

Supervisión de nodos

El uso de nuestra API REST (https://:8091/pools/default) nos permite conocer los recursos informáticos consumidos por nodo.

1. Estado del nodo - (clusterMembership) Como parte del JSON devuelto por el punto final nodeStatuses, el estado del nodo se devuelve a través de clusterMembership. Esto proporciona una facilidad en una base por nodo para supervisar "activo" para garantizar que los nodos están participando en el clúster. Los eventos críticos se definirían por "inactiveFailed" mostrando que el nodo ha fallado y es necesaria la intervención del administrador.
2. Estadísticas del Sistema (systemStats) - Información adicional está disponible en el punto final proporcionando estadísticas básicas de consumo de capacidad para CPU (cpu_utilization), SWAP (swap_used) y memoria libre (mem_free). Para cada nodo en el clúster, si alguno de estos recursos muestra limitaciones, querremos tratar el nodo individual y evaluar si se merecen nodos adicionales.
3. Específicos de Couchbase (interestingStats) - La última sección proporciona información adicional sobre los recursos consumidos por el nodo individual. El disco de nodo individual consumido por Couchbase se define por couch_docs_actual_disk_size, la memoria física utilizada dentro del nodo se define la memoria utilizada por nodo y el número de background fetches ep_bg_fetched (datos no en caché y extraídos del disco) también se mide.

Control de cubos

El uso de nuestra API REST (https://:8091/pools/default/buckets/stats) permite conocer el estado del propio bucket. Un bucket determinado puede estar limitado aunque cada nodo individual tenga capacidad de cálculo adicional que ofrecer. En consecuencia, mantener el pulso de las estadísticas de los buckets proporcionará la mayor información sobre el estado de la aplicación.

1. Operaciones Por Segundo (ops) - Esta es una medida fundamental del número total de gets, sets, incrementos y decrementos que ocurren para un bucket dado. Aunque las vistas no se incluirían en la métrica, proporciona una medida muy rápida de la carga por aplicación. En resumen, todos los recursos pueden ser asignados al cluster pero esto proporcionaría una visión de la carga producida por una aplicación dada.
2. Cache Miss (ep_cache_miss_rate) - Esta métrica es un buen ejemplo de lo que puede o no ser problemático. Fundamentalmente, la métrica cuenta la proporción de objetos solicitados que se encuentran en la caché en relación con lo que es necesario recuperar del disco. Por ejemplo, si diez peticiones entraron en la base de datos y una necesitó ser recuperada del disco nuestra tasa de fallos sería 10%. La verdadera pregunta... ¿es esto un problema? Depende de lo que esperemos tener en memoria. El mejor rendimiento se obtiene con un clúster que mantiene este número lo más cerca posible de 0.
3. Fragmentación (couch_docs_fragmentation) - Couchbase almacena sólo en formato append en disco; como resultado, necesitamos vigilar la fragmentación que ocurre dentro de un cluster. Esto es particularmente importante para medir si la auto-compactación se establece de forma programada. Esto proporcionaría información sobre si el programa se está ejecutando el tiempo suficiente y con la frecuencia suficiente para mantener tu base de datos saludable.
4. Conjunto de trabajo (ep_bg_fetched y vb_active_resident_items_ratio) - Puede utilizar el ep_cache_miss_ratio mencionado anteriormente junto con las métricas de ratio de elementos residentes y espacio libre de memoria para comprender si su bucket tiene capacidad suficiente para almacenar los objetos más solicitados en memoria. Y lo que es más importante, puede prever la necesidad de nodos adicionales para ampliar la capacidad de memoria del clúster.
5. Drenaje de disco (ep_queue_size) - Una de las métricas más importantes a monitorizar independientemente de lo que esté haciendo tu aplicación es la tasa de drenaje. Vigile cuidadosamente la cantidad de cambios pendientes en la cola. Se puede encontrar información adicional en la utilidad de línea de comandos a continuación. Desde un punto de vista REST podemos monitorizar tanto el llenado de la cola (ep_diskqueue_fill) como la rapidez con la que se vacía (ep_diskqueue_drain) para seguir la tendencia a lo largo del tiempo.

En la interfaz REST se puede monitorizar todo un volumen de información adicional. No cubriremos todo lo disponible en la API aquí, sino que nos centraremos principalmente en las estadísticas clave para mantener un clúster saludable. Además de REST, también podemos ejecutar la monitorización mediante scripts a través de las utilidades couchbase-cli y cbstats para capturar las operaciones que se producen en cada nodo del clúster.

Línea de comandos

CBSTATS se puede encontrar en '/opt/couchbase/bin' y proporciona una visión de lo que está ocurriendo dentro de un cluster. A continuación se presentan algunas de las métricas clave y lo que te están diciendo:

1. Rastreando el número de conexiones abiertas y rechazadas a través de las estadísticas curr_connections y rejected_conns podemos entender si alguna petición de conexión fue rechazada por este nodo.
2. Cada vez que un objeto es solicitado por una aplicación y no se encuentra en la caché, Couchbase encontrará el objeto en el disco. Esta pérdida de caché requiere una búsqueda en segundo plano y se mide por elemento obtenido del disco mediante ep_bg_fetched. Si estamos gestionando un conjunto de trabajo de 100% esto podría ser un signo de un cluster bajo estrés; alternativamente, esto puede no ser un problema si tenemos un conjunto de trabajo más pequeño. En cualquiera de los dos casos, es importante comprender lo que es típico en un entorno, ya que un gran aumento proporcionará una señal de advertencia temprana.
3. El número de ítems en cola para persistencia es un área importante a monitorizar para entender si tienes los recursos i/o adecuados para mantener el ritmo de tu aplicación. Mientras que tu aplicación siempre será servida a través de nuestra capa de caché, uno de los grandes beneficios de Couchbase es nuestra capacidad para proporcionar también la durabilidad de los datos mediante la persistencia en disco. Si esta operación asíncrona se sobrecarga, podríamos afectar al rendimiento de la aplicación. Como resultado, especialmente en sistemas de escritura pesada, será importante vigilar ep_queue_size y ep_flusher_todo. Nunca queremos llegar a 1 millón de elementos y es probable que queramos marcar una advertencia alrededor de 500000 a 800000, especialmente si se trata de una tendencia al alza en el tiempo.
4. Siguiendo la estadística vb_num_eject_replicas nos da el número de veces que Couchbase ha expulsado valores de réplica de la memoria. Esto indica que un cubo específico ha alcanzado su marca de agua baja. Mientras que simplemente alcanzar este umbral podría no ser problemático ya que el cluster está simplemente liberando recursos de memoria, ver este comportamiento de forma consistente o una tendencia creciente podría serlo. Más importante aún, esta es una forma de evitar escenarios de falta de memoria (ep_oom_errors/ep_tmp_oom_errors) que nunca queremos ver en nuestros clusters de producción.
5. Couchbase por diseño evita escenarios de caché obsoleta realizando un proceso de "calentamiento" al inicio de un nodo. El calentamiento es el proceso de leer objetos del disco y precargar la caché. Monitorizar el warmup proporciona visibilidad sobre la rapidez con la que un nodo Couchbase completará su proceso de arranque y estará disponible para soportar la carga dentro del cluster. Mientras warmup está completo cuando ep_warmup_value_count es igual a vb_active_curr_items; sin embargo, obtener información más granular puede ser proporcionada por ep_warmup_state. A continuación se muestran los siete estados de calentamiento. Un nodo no se completará hasta que esté en un estado 'hecho'.
   1. Inicial - Iniciar procesos de calentamiento.
   2. EstimateDatabaseItemCount - Estimación del recuento de elementos de la base de datos.
   3. KeyDump - Comienza a cargar claves y metadatos, pero no documentos, en la RAM.
   4. CheckForAccessLog - Determina si hay un registro de acceso disponible. Este registro indica qué claves se han leído o escrito con frecuencia.
   5. LoadingAccessLog - Cargar información del registro de acceso.
   6. LoadingData - El servidor está cargando datos primero para las claves listadas en el registro de acceso, o si no hay registro disponible, basado en las claves encontradas durante la fase 'Key Dump'.
   7. Listo - El servidor está listo para gestionar peticiones de lectura y escritura.
6. Debido a que Couchbase no es sólo un motor de persistencia NoSQL, sino también una caché, queremos entender el consumo de memoria del servidor Couchbase ep_engine. Esto puede ser monitorizado por mem_used.
7. Cabe destacar que las estadísticas de cbstats mencionadas anteriormente también están disponibles a través de nuestra interfaz REST (https://:8091/pools/default/buckets//stats).
   1. ops, ep_cache_miss_rate, couch_docs_fragmentation, ep_queue_size, vb_active_resident_items_ratio, curr_connections, curr_items_tot, ep_bg_fetched, ep_diskqueue_drain, ep_diskqueue_fill, vb_replica_eject, ep_oom_errors, ep_queue_size, ep_tmp_oom_errors, mem_used, etc.

La intención aquí es proporcionar una guía sobre por dónde empezar a desarrollar una estrategia de monitorización de Couchbase. Este es un resumen de las mejores prácticas básicas que hemos visto implementar a nuestros clientes. Cada cliente es único y puede necesitar métricas adicionales en función de su aplicación.