Este tema describe los mensajes de error comunes de TSDB For InfluxDB® y proporciona soluciones.
¿Cómo solucionar el error "database name required"?
El error database name required ocurre cuando una consulta que incluye SHOW no especifica una base de datos. Para especificar una base de datos, utilice la cláusula ON en la consulta SHOW, use USE <database_name> en la interfaz de línea de comandos (CLI) o emplee el parámetro db en una solicitud de API HTTP.
Las consultas SHOW que pueden causar este error incluyen SHOW RETENTION POLICIES, SHOW SERIES, SHOW MEASUREMENTS, SHOW TAG KEYS, SHOW TAG VALUES y SHOW FIELD KEYS.
¿Cómo solucionar el error "max series per database exceeded: < >"?
El error max series per database exceeded ocurre cuando una operación de escritura provoca que el número de series en una base de datos supere el límite máximo permitido. El número máximo de series permitidas por base de datos depende del tipo de instancia.
La información dentro de < > muestra la medición y el conjunto de etiquetas de la serie que excedió el límite max-series-per-database.
¿Cómo solucionar el error "found < >, expected identifier at line < >, char < >"?
-
Sintaxis de InfluxQL
El error
expected identifierocurre cuando TSDB For InfluxDB® no encuentra un identificador esperado en una consulta. Los identificadores son nombres para consultas continuas, bases de datos, claves de campo, mediciones, políticas de retención, suscripciones, claves de etiqueta y nombres de usuario. Este error suele indicar un problema con la sintaxis de la consulta.Ejemplo:
> SELECT * FROM WHERE "blue"= true ERR: error parsing query: found WHERE, expected identifier at line 1, char 15A esta consulta le falta un nombre de medición entre
FROMyWHERE. -
Palabras clave de InfluxQL
En algunos casos, el error
expected identifierocurre cuando un identificador en una consulta es una palabra clave de InfluxQL. Para consultar un identificador que también es una palabra clave de InfluxQL, encierre el identificador entre comillas dobles.El error
expected identifierpuede ocurrir cuando un identificador en una consulta es una palabra clave de InfluxQL. Para consultar dicho identificador, enciérrelo entre comillas dobles.Ejemplo
> SELECT duration FROM runs ERR: error parsing query: found DURATION, expected identifier, string, number, bool at line 1, char 8En la consulta, la clave de campo
durationes una palabra clave de InfluxQL. Para evitar el error, encierredurationentre comillas dobles:> SELECT "duration" FROM runs
¿Cómo solucionar el error "found < >, expected string at line < >, char < >"?
El error expected string ocurre cuando TSDB For InfluxDB® espera un valor de cadena en una consulta pero no lo encuentra.
¿Cómo solucionar el error "mixing aggregate and non-aggregate queries is not supported"?
El error mixing aggregate and non-aggregate ocurre cuando una instrucción SELECT incluye tanto una función de agregación como una clave de campo o clave de etiqueta no agregada.
Una función de agregación devuelve un único resultado calculado. Para los campos o etiquetas que no están agregados, no existe un único valor obvio para devolver.
Ejemplo
Datos sin procesar: La medición peg tiene dos campos (square y round) y una etiqueta (force):
name: peg
---------
time square round force
2016-10-07T18:50:00Z281
2016-10-07T18:50:10Z4122
2016-10-07T18:50:20Z6144
2016-10-07T18:50:30Z7153
Consulta 1:
> SELECT mean("square"),"round" FROM "peg"
ERR: error parsing query: mixing aggregate and non-aggregate queries is not supported
La Consulta 1 incluye una función de agregación y un campo independiente.
mean("square") devuelve un valor agregado, que es el promedio de los cuatro valores de square en la medición peg. Sin embargo, no hay un único valor obvio para devolver correspondiente a los cuatro valores no agregados del campo round.
Consulta 2:
> SELECT mean("square"),"force" FROM "peg"
ERR: error parsing query: mixing aggregate and non-aggregate queries is not supported
La Consulta 2 incluye una función de agregación y una etiqueta independiente.
mean("square") devuelve un valor agregado, que es el promedio de los cuatro valores de square en la medición peg. Sin embargo, no hay un único valor obvio para devolver correspondiente a los cuatro valores no agregados de la etiqueta force.
¿Cómo solucionar el error "time and *influxql.VarRef are not compatible"?
El error time and \*influxql.VarRef are not compatible ocurre cuando se encierra una cadena de fecha y hora entre comillas dobles en una consulta. Las cadenas de fecha y hora deben encerrarse entre comillas simples.
Ejemplo
Encerrar una cadena de fecha y hora entre comillas dobles:
> SELECT "water_level" FROM "h2o_feet" WHERE "location"='santa_monica' AND time >="2015-08-18T00:00:00Z" AND time <="2015-08-18T00:12:00Z"
ERR: invalid operation: time and *influxql.VarRef are not compatible
Encerrar una cadena de fecha y hora entre comillas simples:
> SELECT "water_level" FROM "h2o_feet" WHERE "location"='santa_monica' AND time >='2015-08-18T00:00:00Z' AND time <='2015-08-18T00:12:00Z'
name: h2o_feet
time water_level
---------------
2015-08-18T00:00:00Z2.064
2015-08-18T00:06:00Z2.116
2015-08-18T00:12:00Z2.028
¿Cómo solucionar el error "bad timestamp"?
-
Sintaxis de tiempo
El error
bad timestampocurre cuando el protocolo de línea incluye una marca de tiempo que no está en formato de marca de tiempo UNIX.Ejemplo
> INSERT pineapple value=1'2015-08-18T23:00:00Z' ERR:{"error":"unable to parse 'pineapple value=1 '2015-08-18T23:00:00Z'': bad timestamp"}El protocolo de línea anterior utiliza una marca de tiempo en formato RFC3339. Para evitar el error y escribir correctamente el punto de datos en TSDB For InfluxDB®, reemplace la marca de tiempo con una marca de tiempo UNIX:
> INSERT pineapple,fresh=true value=11439938800000000000 -
Sintaxis del protocolo de línea
En algunos casos, el error
bad timestampocurre cuando hay un error de sintaxis más general en el protocolo de línea.Ejemplo
Escritura 1:
> INSERT hens location=2 value=9 ERR:{"error":"unable to parse 'hens location=2 value=9': bad timestamp"}En la Escritura 1, el protocolo de línea utiliza un espacio en lugar de una coma para separar la medición
heny la etiquetalocation=2. TSDB For InfluxDB® interpreta el campovalue=9como la marca de tiempo y devuelve un error.Para evitar el error, utilice una coma en lugar de un espacio para separar la medición y la etiqueta:
> INSERT hens,location=2 value=9Escritura 2:
> INSERT cows,name=daisy milk_prod=3 happy=3 ERR:{"error":"unable to parse 'cows,name=daisy milk_prod=3 happy=3': bad timestamp"}En la Escritura 2, el protocolo de línea utiliza un espacio en lugar de una coma para separar los campos
milk_prod=3yhappy=3. En consecuencia, TSDB For InfluxDB® interpretahappy=3como la marca de tiempo y devuelve un error.Para evitar el error, separe los dos campos con una coma en lugar de un espacio:
> INSERT cows,name=daisy milk_prod=3,happy=3
¿Cómo solucionar el error "time outside range"?
El error time outside range ocurre cuando la marca de tiempo en el protocolo de línea está fuera del rango de tiempo válido para TSDB For InfluxDB®.
La marca de tiempo mínima válida es -9223372036854775806 o 1677-09-21T00:12:43.145224194Z, y la marca de tiempo máxima válida es 9223372036854775806 o 2262-04-11T23:47:16.854775806Z.
¿Cómo solucionar el error "engine: cache maximum memory size exceeded"?
El error cache maximum memory size exceeded ocurre cuando una alta velocidad de escritura provoca que el tamaño de la caché del servidor supere temporalmente el umbral preestablecido. El umbral preestablecido depende del tipo de instancia.