Criar e editar SLIs e SLOs

O sucesso do serviço é a razão entre o número de respostas bem-sucedidas e o número de todas as solicitações. Esta é efetivamente uma taxa de erros, mas você pode filtrá-la, por exemplo, removendo o erro esperado.

Valid events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}'

Onde {entityGuid} é o GUID do serviço.

Bad events fields

FROM TransactionError
WHERE entityGuid = '{entityGuid}' AND error.expected != true

Onde {entityGuid} é o GUID do serviço.

Um SLI de latência mede a proporção de solicitações válidas que foram atendidas mais rapidamente do que o limite estabelecido como uma boa experiência.

Para determinar esse limite de duração, verifique o desempenho do serviço nas últimas semanas e use esse resultado como uma baseline realista e alcançável. Depois, você poderá iterar no limite do SLI e alinhá-lo com um desempenho mais ambicioso.

Para selecionar um valor apropriado para a condição de duração, uma prática típica é selecionar a duração do percentil 95 das respostas dos últimos 7 ou 15 dias. Encontre esse limite de duração usando o criador de consulta e use-o para determinar o que você considera um bom evento para o seu SLI:

SELECT percentile(duration, 95) FROM Transaction WHERE entityGuid = '{entityGuid}' since 7 days ago limit max

Valid events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}' AND transactionType = 'Web'

Onde {entityGuid} é o GUID do serviço.

Good events fields

FROM Transaction
WHERE entityGuid = '{entityGuid}' AND transactionType = 'Web' AND duration < {duration}

• Onde {entityGuid} é o GUID do serviço.
• Onde {duration} é o tempo de resposta que você considera que proporciona uma boa experiência para seu atendimento ao cliente ou usuário final, em segundos.

O sucesso do serviço é a razão entre o número de respostas bem-sucedidas e o número de todas as solicitações. Esta é efetivamente uma taxa de erros, mas você pode filtrá-la, por exemplo, removendo o erro esperado.

Valid events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer'))

Onde {entityGuid} é o GUID do serviço.

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'

Onde {entityGuid} é o GUID do serviço.

Um SLI de latência mede a proporção de solicitações válidas que foram atendidas mais rapidamente do que o limite estabelecido como uma boa experiência.

Para determinar esse limite de duração, verifique o desempenho do serviço nas últimas semanas e use esse resultado como uma baseline realista e alcançável. Depois, você poderá iterar no limite do SLI e alinhá-lo com um desempenho mais ambicioso.

Para selecionar um valor apropriado para a condição de duração, uma prática típica é selecionar a duração do percentil 95 das respostas dos últimos 7 ou 15 dias. Encontre esse limite de duração usando o criador de consulta e use-o para determinar o que você considera um bom evento para o seu 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'))

Onde {entityGuid} é o GUID do serviço.

Good events fields

FROM Span
WHERE entity.guid = '{entityGuid}' AND (span.kind IN ('server', 'consumer') OR kind IN ('server', 'consumer')) AND duration.ms < {duration}

• Onde {entityGuid} é o GUID do serviço.
• Onde {duration} é o tempo de resposta que você considera que proporciona uma boa experiência para seu atendimento ao cliente ou usuário final, em segundos.

O sucesso do serviço é a razão entre o número de respostas bem-sucedidas e o número de todas as solicitações. Isto é efetivamente uma taxa de erros.

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = '{appName}'

Onde {appName} é o nome do aplicativo APM.

Bad events fields

FROM Metric
SELECT sum(getField(apm.service.error.count, count))
WHERE appName = '{appName}' AND getField(`apm.service.error.count`, count) > 0

Onde {appName} é o nome do aplicativo APM.

Imagine que bons eventos são relatados por uma métrica personalizada. As contagens de eventos válidas podem ser as mesmas.

Valid data

FROM Metric
SELECT sum(getField(apm.service.transaction.duration, count))
WHERE appName = '{appName}'

Onde {appName} é o nome do aplicativo APM.

E agora usamos a métrica personalizada para descobrir o evento bom.

Good data

FROM Metric
SELECT sum(getField(newrelic.timeslice.value, count))
WHERE appName = '{appName}' AND metricTimesliceName = 'Custom/CrossClusterQuery/DataAvailability/status/success'

Onde {appName} é o nome do aplicativo APM.

É a proporção de visualizações de páginas exibidas sem erros.

Valid events fields

FROM PageView
WHERE entityGuid = '{entityGuid}'

Onde {entityGuid} é o GUID do aplicativo do browser.

Bad events fields

FROM JavaScriptError
WHERE entityGuid = '{entityGuid}' AND firstErrorInSession IS true

Onde {entityGuid} é o GUID do aplicativo do browser.

É a proporção de visualizações de páginas válidas em que o maior elemento de conteúdo visível na janela de visualização foi renderizado mais rapidamente do que o limite considerado correspondente a uma boa experiência.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND largestContentfulPaint IS NOT NULL

Onde {entityGuid} é o GUID do aplicativo do browser.

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND largestContentfulPaint < '{largestContentfulPaint}'

• Onde {entityGuid} é o GUID do aplicativo do browser.

• Onde {largestContentfulPaint} é o tempo (em milissegundos) para renderizar o maior elemento de conteúdo visível na janela de visualização que você considera proporcionar uma boa experiência para o usuário final. Um padrão frequente é 4.000 ms.

  Para determinar um número realista a ser usado para {largestContentfulPaint} em seu ambiente, uma prática típica é selecionar a duração do percentil 95 das respostas dos últimos 7 ou 15 dias. Encontre-o usando o criador de consulta:

  SELECT percentile(largestContentfulPaint, 95) FROM PageViewTiming WHERE entityGuid = '{entityGuid}' SINCE 7 days ago LIMIT MAX

  Copiar

É a proporção de visualizações de páginas em que o tempo entre a primeira interação do usuário com a página e o tempo em que o browser responde a essa interação é inferior a um determinado limite.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND interactionToNextPaint IS NOT NULL

Onde {entityGuid} é o GUID do aplicativo do browser.

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND interactionToNextPaint < {interactionToNextPaint}

• Onde {entityGuid} é o GUID do aplicativo do browser.

• Onde {interactionToNextPaint} é o tempo (em milissegundos) que o browser deve responder para fornecer uma boa experiência ao usuário final. Um padrão frequente é 300 ms.

  Para determinar um número realista a ser usado para {interactionToNextPaint} em seu ambiente, uma prática típica é selecionar a duração do percentil 95 das respostas dos últimos 7 ou 15 dias. Encontre-o usando o criador de consulta:

  SELECT percentile(interactionToNextPaint, 95) FROM PageViewTiming WHERE entityGuid = '{entityGuid}' SINCE 7 days ago LIMIT MAX FACET deviceType

  Copiar

É a proporção de visualizações de página com uma boa mudança cumulativa de layout (CLS). CLS é descrito como a soma total de todas as pontuações individuais de mudança de layout para cada mudança inesperada de layout que ocorre durante toda a vida útil da página. Uma mudança de layout ocorre sempre que um elemento visível muda sua posição de um quadro renderizado para o próximo.

Valid events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND cumulativeLayoutShift IS NOT NULL

Onde {entityGuid} é o GUID do aplicativo do browser.

Se desejar criar SLIs separados para rastrear CLS em desktops e dispositivos móveis separadamente, adicione uma destas cláusulas no final do campo:

• and deviceType = 'Mobile'
• and deviceType = 'Desktop'

Good events fields

FROM PageViewTiming
WHERE entityGuid = '{entityGuid}' AND cumulativeLayoutShift < {cumulativeLayoutShift}

• Onde {entityGuid} é o GUID do aplicativo do browser.

• Onde {cumulativeLayoutShift} é um valor predefinido. Para fornecer uma boa experiência ao usuário, seu site deve se esforçar para ter uma pontuação CLS de 0,1 ou menos. Uma pontuação CLS de 0,25 ou mais é considerada uma experiência do usuário ruim.

  Se você decidiu criar SLIs separados para rastrear CLS em desktops e dispositivos móveis separadamente quando definiu a consulta de evento válida, adicione esta cláusula no final do campo:

  • and deviceType = 'Mobile'
  • and deviceType = 'Desktop'

  Para determinar um número realista a ser selecionado para {cumulativeLayoutShift} em seu ambiente, uma prática típica é selecionar o 75º percentil de carregamentos de página nos últimos 7 ou 15 dias, segmentados em dispositivos móveis e desktop. Encontre-o usando o criador de consulta:

  SELECT percentile(cumulativeLayoutShift, 95) FROM PageViewTiming WHERE  entityGuid = '{entityGuid}' since 7 days ago limit max facet deviceType

  Copiar

O sucesso é a razão entre o número de verificações sintéticas bem-sucedidas e o número de todas as verificações.

Valid events fields

FROM SyntheticCheck
WHERE entity.guid = '{entityGuid}'

Onde {entityGuid} é o GUID das verificações sintéticas.

Good events fields

FROM SyntheticCheck
WHERE entity.guid = '{entityGuid}' AND result='SUCCESS'

Onde {entityGuid} é o GUID das verificações sintéticas.

Para definir seu novo SLI, escolha uma destas três opções:

• Entity data

  : Baseie o SLI em dados padrão provenientes do nosso agente ou do seu próprio evento personalizado. Esta é a opção mais comum. Se esta for sua escolha, selecione a entidade (por exemplo, serviço APM) que deseja usar.

• Custom data

  : Alternativamente, você pode basear o SLI em seu evento NRDB personalizado ou métrica dimensional. Use esta opção quando não for possível relacionar os dados de nível de serviço a uma entidade específica ou quando desejar relacionar o nível de serviço diretamente a uma workload.

• Metric data

  : Com base nos dados provenientes do Prometheus, OTel ou na sua própria métrica dimensional personalizada.

Nesta etapa, você configurará a consulta SLI que determina qual evento é válido, bom ou ruim.

Se você associar o SLI a um serviço APM ou a um aplicativo de browser, a New Relic irá sugerir alguns SLI típicos e suas consultas. Usaremos os dados mais recentes como baseline para seus objetivos de nível de serviço e você poderá editar o SLI e o SLO posteriormente.

Se você estiver usando um tipo diferente de entidade, quiser consultar métricas dimensionais ou quiser personalizar os valores baseline fornecidos pela New Relic, você pode personalizar o SLI de acordo com suas necessidades. Por exemplo, você pode usar a cláusula WHERE para filtrar verificações de integridade. Você também pode usar diferentes tipos de eventos em cada consulta; neste caso, certifique-se de que cada evento válido corresponda apenas a um ou menos eventos da consulta boa ou ruim.

A conta de onde os dados são coletados corresponde à conta da entidade à qual o SLI se refere. Consulte a seção acima para saber o que se passa em cada campo.

À direita você verá a consulta final, e na parte inferior você terá uma prévia da quantidade de eventos válidos e bons/ruins dos últimos dias.

Aqui está um exemplo de taxa de sucesso baseada em porcentagem para uma métrica dimensional, vamos convertê-la em um evento válido/bom para SLI:

FROM Metric
SELECT percentage(sum(scrooge_do_expire_count), 
WHERE status = 'success') AS 'Success Rate'
WHERE env='production' 
AND status != 'attempt'

Para a consulta válida, apenas copiaríamos a cláusula externa WHERE :

FROM Metric
SELECT sum(scrooge_do_expire_count))
WHERE env='production'
AND status != 'attempt'

Embora o evento bom seja a cláusula externa WHERE e a cláusula WHERE da função percentual:

FROM Metric
SELECT sum(scrooge_do_expire_count))
WHERE env='production'
AND status != 'attempt'
AND status = 'success'

As quatro funções de agregação que oferecemos suporte atualmente são count(), sum(), getField() e getCdfCount(). Count e sum estão disponíveis para todos os tipos de eventos, enquanto getField e getCdfCount estão disponíveis apenas ao selecionar Metric.

Use a função count() com dados de eventos para contar o número de eventos válidos/bons/ruins.

A função sum() é útil se você tiver contadores pré-agregados em dados de eventos ou métricas dimensionais. Requer um parâmetro: o atributo a ser usado na soma.

Use as funções getField() e getCdfCount() para ver com que frequência um atributo de métrica de distribuição está abaixo ou dentro de um limite. Ambas as funções requerem um atributo e getCdfCount() também requer um limite para medir o valor.

Exemplo usando count():

FROM JavaScriptError
SELECT count(*)
WHERE entityGuid = '{entityGuid}' AND firstErrorInSession IS true

Exemplo usando sum():

FROM ServerlessSample
SELECT sum(provider.errors.Sum)
WHERE awsAccountId = 'XXX'  And provider LIKE 'LambdaFunction%'

Exemplo usando getField() combinado com getCdfCount():

FROM Metric
SELECT getField(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, count) as 'Valid'

FROM Metric
SELECT getCdfCount(`newrelic.goldenmetrics.synth.monitor.medianDurationS`, 0.5) as 'Good'

Você também pode usar curingas em sua consulta SLI, veja um exemplo:

FROM ApiGatewaySample
SELECT sum(provider.cache%Count.Sum)
WHERE awsAccountId = 'XXX'

Nesta etapa você terá uma prévia do valor do SLI e adicionará um SLO para este SLI: Basta selecionar a duração da janela de tempo e a porcentagem de destino. O gráfico à direita irá ajudá-lo a prever se o destino que você está definindo é viável ou se é frequentemente esquecido.

SLOs de janela de tempo contínuo são suportados. Com uma janela de tempo contínua, a conformidade do SLO leva em consideração os últimos N dias. A cada minuto, os dados mais antigos são eliminados do cálculo atual e novos dados os substituem.

Selecione um nome curto para o seu SLI que o ajude a reconhecer o que ele está medindo.

Recomendamos que você adicione tags ao seu SLI, para que possa usá-las posteriormente para pesquisar, filtrar e agrupar SLIs na interface.

Você pode definir qualquer tag que seja significativa para sua organização. Um dropdown sugerirá chaves tag úteis, como as seguintes:

• owner: a equipe ou unidade de negócios que possui esse nível de serviço e reagirá quando o destino do SLO for perdido.

• category: uma palavra-chave que descreve o que o SLI está medindo, como latency. Se você seguir o fluxo de nível de serviço sugerido, a New Relic preencherá essa tag para você e você poderá editá-la posteriormente.

• environment: o ambiente que o nível de serviço está medindo e que faz sentido para seu caso de uso.

• maturity: útil para comunicar às partes interessadas o quão estável é o SLO. Recomendamos que você use valores de tag como test, commitment ou aspirational.

• user_journey e application: esses tipos de tags ajudam a agrupar os SLIs que se aplicam à mesma experiência do usuário, seja uma jornada completa do usuário ou apenas um aplicativo específico.

  Além disso, o dropdown também exibe a tag da entidade relacionada, para que você também possa adicioná-la rapidamente ao SLI.

  

  Para finalizar, você pode opcionalmente adicionar uma descrição para esse nível de serviço.