Guía de mejores prácticas de registro

Bienvenido a la guía de mejores prácticas de registro de New Relic. Aquí encontrará recomendaciones detalladas sobre cómo optimizar nuestra característica de registro y administrar el consumo de datos.

Sugerencia

¿Tienes muchos logs? Consulte nuestro tutorial sobre cómo optimizarlos y administrarlos.

Registro de reenvío

A continuación se ofrecen algunos consejos sobre el reenvío de registros para complementar nuestros documentos de reenvío de registros:

Al reenviar el registro, recomendamos utilizar nuestro agente New Relic Infrastructure y/o agente APM. Si no puede utilizar el agente New Relic , utilice otro agente compatible (como FluentBit, Fluentd y Logstash).
Aquí hay algunos ejemplos de configuración de Github para el agente de registro admitido:
- Ejemplos de FluentBit
- Ejemplos Fluentd
- Ejemplos de logstash
  Importante
  Si su registro está almacenado en un directorio en un host/contenedor subyacente y nuestro agente de infraestructura lo instrumenta para recopilar el registro, es posible que vea registros duplicados recopilados tanto por el agente de infraestructura como por el agente . Para evitar enviar registros duplicados, consulte nuestras recomendaciones en esta guía.
Añade un atributo logtype a todos los datos que reenvíes. El atributo es required para usar nuestras reglas de análisis integradas y también se puede usar para crear reglas de análisis personalizadas basadas en el tipo de datos. El atributo logtype se considera un atributo bien conocido y se utiliza en nuestro panel de inicio rápido para obtener información resumida log .
Utilice nuestras reglas de análisis integradas para tipos de registros conocidos. Analizaremos automáticamente los registros de muchos tipos log conocidos diferentes cuando configure el atributo logtype relevante.
A continuación se muestra un ejemplo de cómo agregar el atributo logtype a un log reenviado por nuestro agente de infraestructura:
```
logs:
  - name: mylog
    file: /var/log/mylog.log
    attributes:
      logtype: mylog
```
Utilice la integración New Relic para reenviar registros para otros tipos de datos comunes, como:
- Entornos de contenedor: Kubernetes (K8S)
- Integración de proveedores de nube: AWS, Azure o GCP
- Cualquiera de nuestras otras integraciones admitidas en el host con registro

Particiones de datos

Si consume más de 1 TB por día de datos de log , definitivamente debería trabajar en un plan de gobernanza de ingesta para el registro, incluido un plan para particionar los datos de una manera que proporcione agrupaciones funcionales y temáticas. Sugerimos mejores prácticas de no más de 1 TB por partición. Esto sirve tanto para el rendimiento como para la usabilidad. Si envió todo su registro a un "depósito" gigante (la partición log predeterminada) en una sola cuenta, podría experimentar una consulta lenta o una consulta fallida. Para obtener más detalles, consulte Límites de tarifas de consultaNRQL .

Una forma de mejorar el rendimiento de la consulta es limitando el rango de tiempo en el que se busca. La búsqueda de registros durante largos períodos de tiempo arrojará más resultados y requerirá más tiempo. Evite búsquedas de más de una semana siempre que sea posible y utilice el selector de rango de tiempo para limitar las búsquedas a períodos de tiempo más pequeños y específicos.

Otra forma de mejorar el rendimiento de la búsqueda es mediante el uso de particiones de datos. Estas son algunas de las mejores prácticas para particiones de datos:

Asegúrese de utilizar particiones al principio de su proceso de incorporación de registros. Cree una estrategia para usar particiones para que su usuario sepa dónde buscar y encontrar un registro específico. De esa manera, no es necesario modificar sus alertas, panel de control y vistas guardadas si implementa particiones más adelante en su recorrido de registro.
Para evitar límites y mejorar el tiempo de consulta, cree una regla de partición de datos para tipos de datos específicos cuando su ingesta diaria total supere 1 TB por día. Ciertos registros de infraestructura de gran volumen (es decir, registros K8S, registros CDN, registros VPC, registros Syslog o registros Web) pueden ser buenos candidatos para sus propias particiones.
Incluso si su volumen de ingesta es bajo, también puede usar particiones de datos para una separación lógica de los datos o simplemente para mejorar el rendimiento de la consulta entre tipos de datos separados.
Utilice un espacio de nombres de partición de datos secundaria para los datos para los que desee un tiempo de retención más corto. Las particiones de datos secundarias tienen un período de retención predeterminado de 30 días.
Para buscar particiones de datos en la UI Logs, debe seleccionar las particiones apropiadas, abrir el selector de particiones y marcar las particiones que desea buscar. Si está utilizando NRQL, utilice la cláusula FROM para especificar Log o Log_<partion> para buscar. Por ejemplo:
```
FROM Log_<my_partition_name> SELECT * SINCE 1 hour ago
```
O para buscar registros en múltiples particiones:
```
FROM Log, Log_<my_partition_name> SELECT * SINCE 1 hour ago
```

Registro de análisis

Analizar su registro durante la ingesta es la mejor manera de hacer que usted y otros usuarios de su organización puedan utilizar mejor sus datos log . Cuando analiza los atributos, puede usarlos fácilmente para buscar en la UI Logs y en NRQL sin tener que analizar los datos en el momento de la consulta. Esto también le permite usarlos fácilmente en y en el panel.

Para analizar el registro le recomendamos que:

Analice su registro en la ingesta para crear attributes (o campos), que puede usar al buscar o crear y alertas. El atributo puede ser cadenas de datos o valores numéricos.
Utilice el atributo logtype que agregó a su registro durante la ingesta, junto con otras cláusulas WHERE NRQL para que coincidan con los datos que desea analizar. Escriba reglas de coincidencia específicas para filtrar el registro con la mayor precisión posible. Por ejemplo:
```
WHERE logtype='mylog' AND message LIKE '%error%'
```
Utilice nuestras reglas de análisis integradas y el atributo logtype asociado siempre que sea posible. Si las reglas integradas no funcionan para sus datos, use un nombre de atributo logtype diferente (es decir, apache_logs frente a apache, iis_w3c_custom frente a iis_w3c) y luego cree una nueva regla de análisis en la UI utilizando una versión modificada de las reglas integradas para que funcione para su formato de datos log .
Utilice nuestra UI Parsing para probar y validar sus reglas de Grok. Usando la opción Paste log , puede pegar uno de sus mensajes de registro para probar su expresión de Grok antes de crear y guardar una regla de análisis permanente.
Utilice la configuración externa de FluentBit para analizar el registro de varias líneas y para otro análisis previo más extenso antes de incorporarlo a New Relic. Para obtener detalles y configuración del análisis multilínea con nuestro agente de infraestructura, consulte esta publicación de blog.
Cree patrones de Grok optimizados para que coincidan con el registro filtrado para extraer el atributo. Evite el uso excesivo de patrones costosos de Grok como GREEDYDATA. Si necesita ayuda para identificar reglas de análisis subóptimas, hable con su representante de cuenta de New Relic.

GROK mejores prácticas

Utilice tipos de Grok para especificar el tipo de valor de atributo que se extraerá. Si se omite, los valores se extraen como cadenas. Esto es importante especialmente para valores numéricos si desea poder utilizar funciones NRQL (es decir, monthOf(), max(), avg(), >, <, etc.) en estos atributos.
Utilice la UI
Parsing
para probar sus patrones de Grok. Puede pegar un registro de muestra en la UI
Parsing
para validar sus patrones Grok o Regex y si están extrayendo el atributo como esperaba.
Agregue anclajes a la lógica de análisis (es decir, ^) para indicar el comienzo de una línea o $ al final de una línea.
Utilice ()? alrededor de un patrón para identificar campos opcionales
Evite el uso excesivo de patrones Grok costosos como '%{GREEDYDATA}. Intente utilizar siempre un patrón Grok válido y un tipo Grok al extraer atributos.

Reglas de filtro de caída

Soltar registro durante la ingesta

Cree reglas de filtrado de caída para descartar registros que no sean útiles o que no sean necesarios para satisfacer ningún caso de uso para el panel, alertas o resolución de problemas.

Elimina el atributo de tu registro al ingerir

Cree reglas de eliminación para eliminar atributos no utilizados de su registro.
Elimine el atributo message después del análisis. Si analiza el atributo del mensaje para crear un nuevo atributo a partir de los datos, suelte el campo del mensaje.
Ejemplo: si está reenviando datos desde la infraestructura de AWS, puede crear reglas de eliminación para eliminar cualquier atributo de AWS que pueda crear un exceso de datos no deseados.

New Relic Logs

La forma en que facturamos el almacenamiento puede diferir de la de algunos de nuestros competidores. La forma en que contabilizamos los datos log es similar a cómo contabilizamos y facturamos otros tipos de datos, que se define en Cálculo de uso.
Si nuestra integración en la nube (AWS, Azure, GCP) está instalada, agregaremos metadatos de la nube a cada log , lo que se sumará a la factura de ingesta general. Sin embargo, estos datos se pueden eliminar para reducir la ingesta.
Los principales impulsores de la sobrecarga de datos log se encuentran a continuación, en orden de impacto:
- Integracion en la nube
- Formato JSON
- patrones de registros (Puedes habilitar/deshabilitar patrones en la UI
  Logs
  .)

Registro de búsqueda

Para búsquedas log comunes, cree y utilice Saved views en la UI. Cree una búsqueda para sus datos y haga clic en + Add Column para agregar un atributo adicional a la tabla de la UI . Luego puede mover las columnas para que aparezcan en el orden que desee y luego guardarlas como una vista guardada con permisos públicos o privados. Configure las vistas guardadas para que sean públicas, de modo que usted y otros usuarios puedan ejecutar fácilmente búsquedas comunes mostrando todos los datos de atributos relevantes. Esta es una buena práctica para aplicaciones de terceros como Apache, nginx, etc., para que el usuario pueda ver fácilmente esos registros sin buscar.
Utilice el generador de consultas para ejecutar búsquedas utilizando NRQL. El generador de consultas le permite utilizar todas las funciones avanzadas disponibles en NRQL.
Cree o utilice el panel de inicio rápido disponible para responder preguntas comunes sobre su registro y ver sus datos log a lo largo del tiempo en gráficos de series temporales. Cree un panel con múltiples paneles para dividir y dividir sus datos log de muchas maneras diferentes.
Utilice nuestras funciones NRQL avanzadas como capture() o aparse() para analizar datos en el momento de la búsqueda.
Instale el panel Logs analysis y/o APM logs monitoring quickstart para obtener rápidamente más información valiosa en sus datos log . Para agregar estos paneles, vaya a one.newrelic.com > Add Data > Logging > Dashboards.

¿Que sigue?

Consulte Comenzar con .

Te ofrecemos esta traducción automática para facilitar la lectura.