VISIÓN GENERAL
Hace varios años escribí un blog que refleja cómo muchos clientes monitorizan sus clusters de Couchbase (https://www.couchbase.com/blog/monitoring-couchbase-cluster). Aunque anticuada, la información sigue siendo relevante y vamos a actualizar ese original. Las estadísticas y métricas descritas en esa visión general son a menudo consumidas por marcos de monitorización para medir la salud y el rendimiento de Couchbase para casos de uso específicos. Desde entonces, a menudo nos encontramos con gente que nos pide ejemplos de implementaciones que consumen estas estadísticas. Normalmente, la necesidad real de los equipos de desarrollo no son marcos de monitorización más amplios, sino simples scripts que se pueden aprovechar. Muchas veces los equipos funcionales cruzados están diagnosticando problemas en entornos de "sala de guerra" y quieren formas sencillas de digerir eventos recientes dentro de un clúster.
El objetivo aquí no es proporcionar un modelo completo, sino esbozar una implementación sencilla que consuma métricas de Couchbase a través de nuestra API REST y herramientas de línea de comandos. Una vez que tengamos algo en marcha que pueda digerir estas métricas de forma regular, necesitaremos almacenarlas en algún lugar. En este tutorial almacenaremos estas métricas en un bucket de Couchbase y utilizaremos N1QL para comprender lo que ocurre en un clúster determinado. Hay otras formas de visualizar este tipo de información (http://www.couchbase.com/blog/2016/march/http-packages.couchbase.com-releases-4.5.0-dp1-couchbase-server-enterprise_4.5.0-dp1-windows_amd64.exe.md5) pero para este ejemplo nos centraremos en la monitorización de Couchbase y las consultas N1QL asociadas.
DIGERIR LA INFORMACIÓN
Quería ofrecer un ejemplo que fuera relevante y útil para que los equipos lo asimilaran y utilizaran. A menudo, el uso de Python es familiar para la gente y se puede implementar fácilmente en una variedad de sistemas. Obviamente, estos mismos métodos podrían utilizarse en shell o en cualquier otro lenguaje, pero Python parecía el más adecuado para un debate generalizado.
El código completo se encuentra aquí ... pythonlab/MonitorStats.py ... pero recorreremos algunos de los detalles y las diferentes formas en que estamos recopilando información de Couchbase.
Lo primero que necesitamos establecer es dónde podemos encontrar los binarios locales de Couchbase, que es todo lo que binPath hace por nosotros.
|
1 2 3 |
# binPath = "C:Archivos de programaCouchbase Server" binPath = "/Applications/couchbase-server-enterprise_4/Couchbase Server.app/Contents/Resources/couchbase-core/bin" # binPath = "/opt/couchbase/bin" |
La interfaz de usuario administrativa es una gran característica de Couchbase y se instala por defecto en cada nodo de un clúster Couchbase; sin embargo, esta interfaz está diseñada para proporcionar una visión de "lo que está pasando ahora" en el clúster. Las estadísticas se agregan con el tiempo por el clúster y no proporciona información granular para revisar "lo que pasó" en el clúster. Porque womo estamos consumiendo estadísticas que son creadas en tiempo real por el cluster de Couchbase necesitamos algún lugar donde almacenar los resultados. Aunque podría haber otras opciones, utilizaremos Couchbase para almacenar nuestras estadísticas históricas. El cluster que usaremos para almacenar las estadísticas estará controlado por seedNode y seedBucket (un SDK de Couchbase sólo necesita un nodo y el nombre del bucket para crear una conexión con todos los nodos de un cluster).
|
1 2 |
seedNode = "192.168.61.101" cubo de semillas = "testload" |
Este script se ejecutaría localmente en cada nodo del clúster y capturaría un perfil estadístico de la salud de ese nodo y su visión del clúster. Como resultado, el clúster que estamos monitorizando se definirá como "localhost" y usaremos la API REST de Couchbase para determinar el nombre del host local.
|
1 |
clusterNode = "localhost" |
Todo está dirigido por la comprensión de qué nodo se está ejecutando el script y cuántos nodos componen el clúster. Aquí capturaremos esta información y dirigiremos la parte restante del script de monitorización.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
numNodes = int(comandos.salida("curl -s -u Administrador:contraseña http://" + clusterNode + ":8091/pools/default |jq '.nodos | longitud'")) para i en gama(0,numNodes-1): rtn = solicita.consiga('http://Administrator:password@' + clusterNode + ':8091/pools/default') si rtn.código_estado != 200: # Esto significa que algo ha ido mal. imprimir("oh mierda" + rtn.código_estado) z = json.cargas(rtn.texto) ctr = str((json.vuelca(z[nodos][i][esteNodo]))) #ctr = (str(commands.getoutput("curl -s -u Administrador:contraseña http://" + clusterNode + ":8091/pools/default |jq .nodes[" + str(i) + "].thisNode"))) si ctr == "true": esteNodo = (str(comandos.salida("curl -s -u Administrador:contraseña http://" + clusterNode + ":8091/pools/default |jq .nodes[" + str(i) + "].otpNode"))) esteNodo = esteNodo.dividir("@")[1] esteNodo = esteNodo.dividir(""")[0] #print ("este nodo" + str(esteNodo)) |
Para el resto del script podemos consumir estadísticas específicas de varias maneras. Aquí sacaremos información de la utilidad cbstats de Couchbase o directamente de nuestra API REST. Aquí usamos cbstats para obtener la utilización de memoria de un nodo y usamos un cliente REST de Python (requests) para obtener la cola de drenaje y medir cómo está funcionando el cluster en la persistencia de datos en disco. Estas son algunas de las estadísticas más importantes a monitorizar para un cluster Couchbase.
|
1 2 3 4 5 6 7 8 9 10 |
memUsado = int(comandos.salida(binPath + '/cbstats ' + str(esteNodo) + ':11210 -b ' + clusterBucket + ' all -j |jq .mem_used')) # diskDrain = commands.getoutput("curl -s -u Administrador:contraseña http://" + seedNode + ":8091/pools/default/buckets/testload/stats |jq .op.samples.ep_diskqueue_drain[59]") # Cola de drenaje a través de REST API resp = solicita.consiga('http://Administrator:password@' + str(esteNodo) + ':8091/pools/default/buckets/' + clusterBucket + /stats) si resp.código_estado != 200: # Esto significa que algo ha ido mal. imprimir("oh mierda" + resp.código_estado) a = json.cargas(resp.texto) diskDrain = int((json.vuelca(a[op][muestras][ep_diskqueue_drain][0], sangría=4, separadores=(',', ': ')))) |
El script real muestra información adicional, pero en última instancia capturamos todo en un documento JSON y establecemos un valor TTL durante 30 días.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
json_str = { tipo: "estadísticas", 'descarga': flushFail, desagüe: diskDrain, OOM: tempOOM, "señorita: cacheMiss, memoria: memUsado, operaciones: opsPor, nodos: nodeHealth } cb.upsert(str(esteNodo) + "::" + nowStamp, json_str, ttl=2505600) |
Con los datos de monitorización en Couchbase podemos consumir cosas a través de nuestro lenguaje de consulta N1QL para buscar anomalías. Los datos en sí están utilizando un modelo de datos de series temporales basado en una marca de tiempo; como resultado, podemos consultar cosas que suceden en el clúster y la CLAVE (meta.id) nos mostrará el período de tiempo de interés. Puede que tengamos que ser inteligentes con los índices necesarios para soportar el análisis, pero para una plataforma de lucha contra incendios es muy factible aprovechando el lenguaje de consulta N1QL de Couchbase.
|
1 |
SELECCIONE meta().id, operaciones DESDE `carga de prueba` DONDE OOM = 0 |
CONCLUSIÓN:
Esto no es algo que deba ser lanzado en producción, pero debería proporcionar una guía sobre cómo monitorizar un entorno Couchbase. Hay mucho disponible a través de la interfaz REST y cbstats, todo lo cual puede ser consumido y monitoreado de manera similar.
