Te ofrecemos esta traducción automática para facilitar la lectura.
In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
Si recibe los siguientes errores, verifique sus permisos de usuario:
La UI ha deshabilitado la opción para guardar un SLI/SLO.
La API devuelve el mensaje de error "No se puede consultar el campo \"eventExportRegisterRule\" en el tipo \"RootMutationType\".”.
Para organizaciones New Relic que tienen varias cuentas: el nivel de servicio solo se puede asociar con una sola cuenta. Si está intentando crear un nivel de servicio para una carga de trabajo con entidad en varias cuentas, es posible que desee reestructurar las cargas de trabajo para que todas sus entidades asociadas estén en la misma cuenta. Puede crear un máximo de 500 SLI en una cuenta.
New Relic ingiere datos de muchas maneras diferentes y de fuentes muy diferentes. Cada uno tiene su propio sabor individual, lo que crea muchas posibilidades sobre cómo se consumen los datos. Existen algunos escenarios donde es imposible configurar el nivel de servicio debido a las características de los datos:
Subqueries
. No se admiten subconsultas.
Addition of sum functions
. Si bien es posible utilizar SELECT sum(attributeA) o SELECT sum(attributeA + attributeB), la expresión SELECT sum(attributeA) + sum(attributeB) no es compatible.
Conceptos clave para crear SLI y SLO
Tenga en cuenta estos conceptos al definir SLI y SLO.
Define tu experiencia clave del usuario
Comience pensando en la experiencia clave del usuario de más alto nivel que posee su equipo, luego concéntrese en la experiencia clave del usuario subyacente hasta que una mayor granularidad no proporcione valor. Al elegir con qué SL comenzar, recomendamos utilizar un enfoque de arriba hacia abajo, es decir, comenzar con los menos granulares y crear otros más granulares solo si es necesario.
En primer lugar, identifique un "límite del sistema". Esta es una parte de su sistema que su usuario percibe como una "caja negra" de funcionalidad. Algunos ejemplos:
En el caso de una API, podría ser simplemente un servicio.
Para una canalización de datos, podría ser una cadena de servicios necesarios para procesar datos de un extremo a otro.
Una vez que haya establecido estos niveles de servicio de nivel superior, es posible que descubra que no todos los extremos de su servicio se comportan de la misma manera y que desee dividirlos aún más. Por ejemplo:
La transacción de inicio de sesión puede necesitar un SLO más alto en errores que uno de navegación
La duración de algunas operaciones es mucho mayor que la del resto
Por ejemplo, en un nivel alto, una experiencia clave del usuario en New Relic podría ser: un cliente nos envía telemetry data y esos datos luego están disponibles para ser consultados en la API o UI de nuestro producto.
Para esa experiencia del usuario, podríamos crear un SLO como:
período
objetivo
categoría
indicador
últimos 28 días
99,9%
latencia
Los datos ingeridos por un usuario están disponibles para su consulta en menos de 1 minuto.
Tenga en cuenta que estos tipos de experiencia del usuario generalmente involucran más de un servicio y se extienden a través de múltiples límites de equipos y organizaciones.
Al aumentar la granularidad de la experiencia subyacente del usuario, otra experiencia clave del usuario en New Relic podría ser: un cliente puede utilizar un panel personalizado para visualizar sus telemetry data.
Este SLO podría verse así:
período
objetivo
categoría
indicador
últimos 28 días
99,9%
disponibilidad
el usuario interactúa correctamente con la dashboard UI
Como ejemplo de llevar la granularidad demasiado lejos, agregar un widget de gráfico en un dashboard también es una experiencia del usuario. Sin embargo, la creación de un SLO específico para esta acción no proporciona valor adicional en comparación con el SLO anterior sobre la interacción exitosa de los usuarios con la dashboard UI.
En resumen, utilice un enfoque de arriba hacia abajo y comience con el nivel de servicio menos granular. Cree un nivel de servicio más granular solo si es necesario.
La entidad relacionada
En el ecosistema de New Relic, cada nivel de servicio está vinculado a otra entidad, que es cualquier elemento de su stack que nos reporta datos o que genera datos a los que tenemos acceso. La entidad con la que está relacionado un nivel de servicio determina dónde se muestran los resultados de SLI/SLO.
Puede definir SLI en cualquier evento NRDB o métrica dimensional que se informe a New Relic. La mayoría de los eventos personalizados no están relacionados con una sola entidad de New Relic, pero brindan Insights sobre negocios y experiencia del usuario de nivel superior. En este caso, aún puedes relacionar el SLI con una entidad específica o con una carga de trabajo.
Tenga en cuenta que la consulta SLI deberá estar bajo el alcance de la misma cuenta donde vive la entidad relacionada.
Consulta SLI
Los SLI se definen como el porcentaje de buenas respuestas sobre el número total de solicitudes válidas. La mayoría de las veces configurará sus SLI definiendo las piezas válidas y buenas:
Un
valid request
es cualquier solicitud que desee que se considere significativa para sus SLI (por ejemplo, todas las transacciones relacionadas con un extremo que no se iniciaron mediante una verificación de estado).
Un
good response
es cualquier respuesta que considere que proporciona un buen resultado para el usuario final o el servicio del cliente (por ejemplo, el servicio respondió en menos de 2 segundos, brindando una buena experiencia de navegación para el usuario final).
Alternativamente, puedes definir cuáles consideras que son malas respuestas:
Un
bad response
es cualquier respuesta que considere que proporciona un resultado incorrecto (por ejemplo, el servicio respondió con un error del servidor, lo que provocó que el cliente fallara en su flujo). New Relic derivará automáticamente el recuento de buenas respuestas como valid - bad.
Los SLO basados en solicitudes se basan en un SLI definido como la relación entre el número de solicitudes correctas y el número total de solicitudes. Un SLO basado en solicitudes se cumple cuando esa proporción cumple o excede el objetivo para el período de cumplimiento.
SLI sugeridos
En esta sección encontrará algunos SLI que normalmente se utilizan para medir el rendimiento de los servicios y la aplicación browser .
SLIs para servicios APM y transacción clave instrumentada con el agente New Relic
Según Transaction evento, estos SLI son los más comunes para servicios basados en solicitudes:
El éxito del servicio es la relación entre el número de respuestas exitosas y el número de todas las solicitudes. Esto efectivamente es una tasa de errores, pero puedes filtrarla, por ejemplo eliminando el error esperado.
Valid events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'
Donde {entityGuid} es el GUID del servicio.
Bad events fields
FROM TransactionError
WHERE entityGuid ='{entityGuid}'AND error.expected !=true
Donde {entityGuid} es el GUID del servicio.
Un SLI de latencia mide la proporción de solicitudes válidas que se atendieron más rápido que el umbral establecido como buena experiencia.
Para determinar ese umbral de duración, verifique cómo se ha desempeñado el servicio en las últimas semanas y utilice ese resultado como una línea de base realista y alcanzable. Luego, puede iterar sobre el umbral SLI y alinearlo con un rendimiento más ambicioso.
Para seleccionar un valor apropiado para la condición de duración, una práctica típica es seleccionar la duración del percentil 95 de las respuestas de los últimos 7 o 15 días. Encuentre este umbral de duración usando el generador de consultas y utilícelo para determinar cuál considera que es un buen evento para su SLI:
SELECT percentile(duration,95)FROMTransactionWHERE entityGuid ='{entityGuid}' since 7 days ago limit max
Valid events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'AND transactionType ='Web'
Donde {entityGuid} es el GUID del servicio.
Good events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'AND transactionType ='Web'AND duration < {duration}
Donde {entityGuid} es el GUID del servicio.
Donde {duration} es el tiempo de respuesta que considera que brinda una buena experiencia para su servicio de atención al cliente o usuario final, en segundos.
SLIs para servicios APM y transacción clave instrumentado con OpenTelemetry
Según los intervalos de OpenTelemetry, estos SLI son los más comunes para servicios basados en solicitudes:
El éxito del servicio es la relación entre el número de respuestas exitosas y el número de todas las solicitudes. Esto efectivamente es una tasa de errores, pero puedes filtrarla, por ejemplo eliminando el error esperado.
Valid events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))
Donde {entityGuid} es el GUID del servicio.
Bad events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))AND otel.status_code ='ERROR'
Donde {entityGuid} es el GUID del servicio.
Un SLI de latencia mide la proporción de solicitudes válidas que se atendieron más rápido que el umbral establecido como buena experiencia.
Para determinar ese umbral de duración, verifique cómo se ha desempeñado el servicio en las últimas semanas y utilice ese resultado como una línea de base realista y alcanzable. Luego, puede iterar sobre el umbral SLI y alinearlo con un rendimiento más ambicioso.
Para seleccionar un valor apropiado para la condición de duración, una práctica típica es seleccionar la duración del percentil 95 de las respuestas de los últimos 7 o 15 días. Encuentre este umbral de duración usando el generador de consultas y utilícelo para determinar cuál considera que es un buen evento para su SLI:
SELECT percentile(duration.ms,95)FROM Span WHERE entityGuid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer')) SINCE 7 days ago LIMIT MAX
Valid events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))
Donde {entityGuid} es el GUID del servicio.
Good events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))AND duration.ms < {duration}
Donde {entityGuid} es el GUID del servicio.
Donde {duration} es el tiempo de respuesta que considera que brinda una buena experiencia para su servicio de atención al cliente o usuario final, en segundos.
SLI para servicios APM utilizando datos de intervalo de tiempo de métrica
Las APM métricas se reportan como datos de intervalo de tiempo. También puede aprovechar los datos de intervalo de tiempo para sus SLI.
Nota: Esta característica aún está en versión beta.
El éxito del servicio es la relación entre el número de respuestas exitosas y el número de todas las solicitudes. Esto efectivamente es una tasa de errores.
WHERE appName ='{appName}'AND metricTimesliceName ='Custom/CrossClusterQuery/DataAvailability/status/success'
Donde {appName} es el nombre de la aplicación APM.
SLI para aplicaciones browser
Los siguientes SLI se basan en las Métricas web principales del browser de Google.
Es la proporción de páginas vistas que se publican sin errores.
Valid events fields
FROM PageView
WHERE entityGuid ='{entityGuid}'
Donde {entityGuid} es el GUID de la aplicación browser .
Bad events fields
FROM JavaScriptError
WHERE entityGuid ='{entityGuid}'AND firstErrorInSession IStrue
Donde {entityGuid} es el GUID de la aplicación browser .
Es la proporción de visitas a páginas válidas en las que el elemento de contenido más grande visible en la ventana gráfica se representó más rápido que el umbral que se considera correspondiente a una buena experiencia.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND largestContentfulPaint ISNOTNULL
Donde {entityGuid} es el GUID de la aplicación browser .
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND largestContentfulPaint <'{largestContentfulPaint}'
Donde {entityGuid} es el GUID de la aplicación browser .
Donde {largestContentfulPaint} es la cantidad de tiempo (en milisegundos) para mostrar el elemento de contenido más grande visible en la ventana gráfica que considera que brinda una buena experiencia para el usuario final. Un estándar frecuente es 4000 ms.
Para determinar un número realista a utilizar para {largestContentfulPaint} en su entorno, una práctica típica es seleccionar la duración del percentil 95 de las respuestas de los últimos 7 o 15 días. Encuéntrelo usando el generador de consultas:
SELECT percentile(largestContentfulPaint,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' SINCE 7 days ago LIMIT MAX
Es la proporción de visitas a una página en la que el tiempo entre la primera interacción de un usuario con la página y el momento en que el browser responde a esa interacción es inferior a un cierto umbral.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND interactionToNextPaint ISNOTNULL
Donde {entityGuid} es el GUID de la aplicación browser .
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND interactionToNextPaint < {interactionToNextPaint}
Donde {entityGuid} es el GUID de la aplicación browser .
Donde {interactionToNextPaint} es la cantidad de tiempo (en milisegundos) que el browser debe responder para brindar una buena experiencia al usuario final. Un estándar frecuente es 300 ms.
Para determinar un número realista a utilizar para {interactionToNextPaint} en su entorno, una práctica típica es seleccionar la duración del percentil 95 de las respuestas de los últimos 7 o 15 días. Encuéntrelo usando el generador de consultas:
SELECT percentile(interactionToNextPaint,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' SINCE 7 days ago LIMIT MAX FACET deviceType
Es la proporción de páginas vistas con un buen cambio de diseño acumulativo (CLS). CLS se describe como la suma total de todas las puntuaciones de cambios de diseño individuales para cada cambio de diseño inesperado que ocurre durante toda la vida útil de la página. Un cambio de diseño ocurre cada vez que un elemento visible cambia su posición de un cuadro renderizado al siguiente.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND cumulativeLayoutShift ISNOTNULL
Donde {entityGuid} es el GUID de la aplicación browser .
Si desea crear SLI independientes para realizar un seguimiento de CLS en dispositivos móviles y de escritorio por separado, agregue una de estas cláusulas al final del campo:
and deviceType = 'Mobile'
and deviceType = 'Desktop'
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND cumulativeLayoutShift < {cumulativeLayoutShift}
Donde {entityGuid} es el GUID de la aplicación browser .
Donde {cumulativeLayoutShift} es un valor preestablecido. Para brindar una buena experiencia al usuario, su sitio debe esforzarse por tener una puntuación CLS de 0,1 o menos. Una puntuación CLS de 0,25 o más se considera una mala experiencia del usuario.
Si decidió crear SLI independientes para realizar un seguimiento de CLS en dispositivos móviles y de escritorio por separado cuando definió la consulta de evento válida, agregue esta cláusula al final del campo:
and deviceType = 'Mobile'
and deviceType = 'Desktop'
Para determinar un número realista para seleccionar {cumulativeLayoutShift} en su entorno, una práctica típica es seleccionar el percentil 75 de cargas de página durante los últimos 7 o 15 días, segmentado entre dispositivos móviles y de escritorio. Encuéntrelo usando el generador de consultas:
SELECT percentile(cumulativeLayoutShift,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' since 7 days ago limit max facet deviceType
SLIs para checks sintéticos
El éxito es la relación entre el número de comprobaciones sintéticas exitosas y el número de todas las comprobaciones.
Valid events fields
FROM SyntheticCheck
WHERE entity.guid ='{entityGuid}'
Donde {entityGuid} es el GUID de los checks sintéticos.
Good events fields
FROM SyntheticCheck
WHERE entity.guid ='{entityGuid}'AND result='SUCCESS'
Donde {entityGuid} es el GUID de los checks sintéticos.
Crear y editar nivel de servicio
Puede crear SLI y SLO desde varios lugares de nuestra UI:
. Puede asociar el SLI con cualquier entidad de sus cuentas, incluida la carga de trabajo.
Desde la página
Service levels
en cualquier
Servicio, clave de transacción, aplicación browser o monitor Sintético. El SLI estará asociado con esa entidad específica. Si utiliza este punto de partida, New Relic creará automáticamente los indicadores de nivel de servicio más comunes para este tipo de entidad, basándose en los últimos datos disponibles.
Desde la pestaña
Service levels
en cualquier carga de trabajo. Puede asociar el SLI con cualquier entidad de la carga de trabajo o con toda la carga de trabajo.
Los datos no aparecen inmediatamente después de crear un SLI. Espere unos minutos de retraso antes de ver los primeros resultados del logro del SLI. Los datos tienen una retención de 13 meses de forma predeterminada.
Recuerde que el nivel de servicio sólo puede asociarse a una única cuenta. Para obtener detalles al respecto, consulte los requisitos.
Para crear un nivel de servicio, siga estos pasos:
Para definir su nuevo SLI, elija una de estas tres opciones:
Entity data
: Basar el SLI en datos estándar provenientes de nuestro agente o de tu propio evento personalizado. Esta es la opción más común. Si esta es su elección, seleccione la entidad (por ejemplo, servicio APM) que desea utilizar.
Custom data
: Alternativamente, puede basar el SLI en su evento NRDB personalizado o métrica dimensional. Utilice esta opción cuando no pueda relacionar los datos del nivel de servicio con una entidad específica o cuando desee relacionar el nivel de servicio directamente con una carga de trabajo.
Metric data
: Basado en los datos provenientes de Prometheus, OTel o su propia métrica dimensional personalizada.
En este paso, configurará la consulta SLI que determina qué evento es válido, bueno o malo.
Si asocia el SLI con un servicio APM o una aplicación browser , New Relic le sugerirá algún SLI típico y su consulta. Usaremos los datos más recientes como línea de base para sus objetivos de nivel de servicio y luego podrá editar el SLI y el SLO.
Si está utilizando un tipo diferente de entidad, desea consultar dimensional métrica o desea personalizar los valores de línea de base proporcionados por New Relic, puede personalizar el SLI según sus necesidades. Por ejemplo, puede utilizar la cláusula WHERE para filtrar las comprobaciones de estado. También puedes usar diferentes tipos de eventos en cada consulta; en este caso, asegúrese de que cada evento válido corresponda solo a uno o menos eventos en la consulta buena o mala.
La cuenta de donde se recopilan los datos coincide con la cuenta de la entidad a la que se refiere el SLI. Consulte la sección anterior para saber qué incluye cada campo.
A la derecha verás la consulta final, y en la parte inferior obtendrás una vista previa del número de eventos válidos y buenos/malos de los últimos días.
A continuación se muestra un ejemplo de la tasa de éxito basada en porcentaje para una métrica dimensional. Convirtámosla en el evento válido/bueno para SLI:
FROM Metric
SELECT percentage(sum(scrooge_do_expire_count),
WHEREstatus='success')AS'Success Rate'
WHERE env='production'
ANDstatus!='attempt'
Para la consulta válida simplemente copiaremos la cláusula WHERE exterior:
FROM Metric
SELECTsum(scrooge_do_expire_count))
WHERE env='production'
ANDstatus!='attempt'
Mientras que el buen evento sería la cláusula externa WHERE y la cláusula WHERE de la función de porcentaje:
FROM Metric
SELECTsum(scrooge_do_expire_count))
WHERE env='production'
ANDstatus!='attempt'
ANDstatus='success'
Las cuatro funciones de agregación que admitimos actualmente son count(), sum(), getField() y getCdfCount(). Count y sum están disponibles para todos los tipos de eventos, mientras que getField y getCdfCount solo están disponibles al seleccionar entre Metric.
Utilice la función count() con datos de eventos para contar el número de eventos válidos/buenos/malos.
La función sum() es útil si tiene contadores preagregados en datos de eventos o métrica dimensional. Requiere un parámetro: el atributo a utilizar en la suma.
Utilice las funciones getField() y getCdfCount() para ver con qué frecuencia un atributo de métrica de distribución está por debajo o en un umbral. Ambas funciones requieren un atributo, y getCdfCount() también requiere un umbral para medir el valor.
Ejemplo usando count():
FROM JavaScriptError
SELECTcount(*)
WHERE entityGuid ='{entityGuid}'AND firstErrorInSession IStrue
Ejemplo usando sum():
FROM ServerlessSample
SELECTsum(provider.errors.Sum)
WHERE awsAccountId ='XXX'And provider LIKE'LambdaFunction%'
Ejemplo usando getField() combinado con getCdfCount():
También puedes utilizar comodines en tu consulta SLI, aquí tienes un ejemplo:
FROM ApiGatewaySample
SELECTsum(provider.cache%Count.Sum)
WHERE awsAccountId ='XXX'
En este paso, obtendrá una vista previa del valor de SLI y agregará un SLO para este SLI: simplemente seleccione la duración de la ventana de tiempo y el porcentaje objetivo. El cuadro de la derecha le ayudará a anticipar si el objetivo que se está fijando es factible o si a menudo no se alcanza.
Se admiten SLO de ventana de tiempo móvil. Con una ventana de tiempo móvil, el cumplimiento del SLO tiene en cuenta los últimos N días. Cada minuto, los datos más antiguos desaparecen del cálculo actual y los datos nuevos los reemplazan.
Seleccione un nombre corto para su SLI que le ayude a reconocer lo que está midiendo.
Le recomendamos que agregue etiquetas a su SLI, para que luego pueda usarlas para buscar, filtrar y agrupar SLI en la UI.
Puede configurar cualquier etiqueta que sea significativa para su organización. Un menú desplegable sugerirá claves de etiquetas útiles como las siguientes:
owner: el equipo o unidad de negocio propietario de este nivel de servicio y reaccionará cuando no se alcance el objetivo de SLO.
category: una palabra clave que describe lo que mide el SLI, como latency. Si sigue el flujo de nivel de servicio sugerido, New Relic completará esta etiqueta por usted y podrá editarla más adelante.
environment: el entorno que mide el nivel de servicio y que tiene sentido para su caso de uso.
maturity: Útil para comunicar a las partes interesadas qué tan estable es el SLO. Le recomendamos que utilice valores de etiqueta como test, commitment o aspirational.
user_journey y application: este tipo de etiquetas le ayudan a agrupar los SLI que se aplican a la misma experiencia del usuario, ya sea un recorrido de usuario completo o solo una aplicación específica.
Además, el menú desplegable también muestra la etiqueta de entidad relacionada, por lo que también puede agregarla rápidamente al SLI.
Para finalizar, opcionalmente puedes agregar una descripción para ese nivel de servicio.
Editar SLI
Una vez que haya creado un SLI, puede editarlo a través de la página de lista de nivel de servicio, haciendo clic en el menú ... y luego Edit, como se muestra aquí:
o puedes hacer lo mismo a través de la página de resumen, haciendo clic en Edit: