• /
  • EnglishEspañol日本語한국어Português
  • Inicia sesiónComenzar ahora

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

En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.

Crea una propuesta

Archivo ejecutable de integración en el host: especificaciones JSON

La integración en el host del agente de infraestructura de New Relic constará de al menos dos archivos: un archivo ejecutable y al menos un archivo de configuración. El archivo ejecutable genera datos JSON que el agente de monitoreo de infraestructura consume y envía a New Relic. Nos referimos al objeto JSON como el protocolo de integración SDK.

Requisitos del archivo ejecutable

El ejecutable puede ser cualquier archivo que se ejecute desde una interfaz de línea de comando; Por ejemplo:

  • Un script de shell
  • Una scripten lenguaje de escritura
  • Un binario compilado

El único requisito de su archivo ejecutable es que exporte datos JSON, en formato de una sola línea, que cumpla con las especificaciones de este documento.

Recommendation: Utilice Ir para crear integración; es el lenguaje que utilizamos para crear integración en el host y las herramientas de creación de integración. Sin embargo, puedes crear una integración en cualquier idioma.

Colocación de archivos

El archivo ejecutable va en este directorio:

  • Linux:

    /var/db/newrelic-infra/custom-integrations
  • Windows:

    C:\Program Files\New Relic\newrelic-infra\newrelic-integrations

Protocolo de integración v4: ejemplo de salida JSON

La siguiente sección explica el nuevo esquema JSON (protocolo de integración v4). El SDK v4 solo admite esta nueva versión del protocolo. Estos son los cambios más importantes:

  • Un nuevo objeto integration en el nivel superior.
  • Los objetos entity y metrics han sido modificados.

Consulte la guía de migración de v3 a v4 para obtener más información.

{
"protocol_version":"4", # protocol version number
"integration":{ # this data will be added to all metrics and events as attributes,
# and also sent as inventory
"name":"integration name",
"version":"integration version"
},
"data":[ # List of objects containing entities, metrics, events and inventory
{
"entity":{ # this object is optional. If it's not provided, then the Entity will get
# the same entity ID as the agent that executes the integration.
"name":"redis:192.168.100.200:1234", # unique entity name per customer account
"type":"RedisInstance", # entity's category
"displayName":"my redis instance", # human readable name
"metadata":{} # can hold general metadata or tags. Both are key-value pairs that will
# be also added as attributes to all metrics and events
},
"metrics":[ # list of metrics using the dimensional metric format
{
"name":"redis.metric1",
"type":"count", # gauge, count, summary, cumulative-count, rate or cumulative-rate
"value":93,
"attributes":{} # set of key-value pairs that define the dimensions of the metric
}
],
"inventory":{...}, # Inventory remains the same
"events":[...] # Events remain the same
}
]
}

Protocolo de integración v3: ejemplo de salida JSON

El JSON incluye:

  • Un encabezado, con datos básicos de integración (nombre, versión)
  • Una lista de datos, que incluye uno o más datos de reporte de entidad (datos métricos, de inventario y/o de eventos)

Este diagrama muestra esta estructura:

New Relic Integrations SDK data structure diagram

A continuación se muestra un ejemplo de salida JSON (formateada con saltos de línea para facilitar la lectura). Las definiciones y especificaciones siguen este ejemplo:

{
"name": "my.company.integration",
"protocol_version": "3",
"integration_version": "x.y.z",
"data": [
{
"entity": {
"name": "my_garage",
"type": "building",
"id_attributes": [
{
"key": "environment",
"value": "production"
},
{
"key": "node",
"value": "master"
}
]
},
"metrics": [
{
"temperature": 25.3,
"humidity": 0.45,
"displayName": "my_garage",
"entityName": "building:my_garage",
"event_type": "BuildingStatus"
}
],
"inventory": {
"out_door": {
"status": "open"
}
},
"events": []
},
{
"entity": {
"name": "my_family_car",
"type": "car",
"id_attributes": [
{
"key": "environment",
"value": "production"
},
{
"key": "node",
"value": "master"
}
]
},
"metrics": [
{
"speed": 95,
"fuel": 768,
"displayName": "my_family_car",
"entityName": "car:my_family_car",
"event_type": "VehicleStatus"
}
],
"inventory": {
"motor": {
"brand": "renault",
"cc": 1800
}
},
"events": [
{
"category": "gear",
"summary": "gear has been changed"
}
],
"add_hostname": true
}
]
}

JSON: Especificaciones generales

A continuación se muestran las especificaciones generales para la salida JSON:

JSON: encabezado

A continuación se muestra un ejemplo de la primera parte de la salida JSON de una integración en el host:

"name":"com.myorg.nginx",
"protocol_version":"3",
"integration_version":"1.0.0",
"data": [ {entities}...]

Una carga útil mínima sería un objeto JSON con solo los campos de encabezado. Recommendation: Si no hay datos que recopilar, utilice el código de retorno del programa y el mensaje de registro escrito en stderr.

Campos de encabezado JSON

Descripción

name

Requerido. Debe ser idéntico al campo name en el archivo de configuración.

Recommendation: Utilice nombres de dominio inversos para generar nombres de integración únicos.

protocol_version

Requerido. El número de versión del protocolo de intercambio entre la integración y el agente que utiliza el ejecutable de integración.

  • La versión actual es la 3. Este protocolo requiere el agente de infraestructura 1.2.25 o superior.

  • El protocolo 2 requiere el agente de infraestructura 1.0.859 o superior.

  • El protocolo 1 es compatible con todos los agentes.

    Para obtener más información, consulte Cambios en el SDK.

integration_version

Opcional. La versión de integración. Se utiliza para realizar un seguimiento de la versión de integración que se ejecuta en cada host.

Una integración puede tener más de un ejecutable. Por lo tanto, esta no es simplemente la versión del ejecutable.

data

Requerido para reportar datos. Una lista que contiene los datos reportados por una o más entidades.

JSON: entidad

Dentro de la listadata de la salida JSON hay una o más entidades. Los campos de entrada de la entidad incluyen:

Campos JSON de entidad

Descripción

entity

Requerido. Datos o propiedades de la entidad.

metrics

Opcional. Lista métrica relacionada con entidades.

inventory

Opcional. Artículos de inventario relacionados con la entidad.

events

Opcional. Lista de eventos relacionados con la entidad.

add_hostname

Opcional. Booleano. Si es true, la entidad métrica se decorará con el hostname.

Dentro de la listadata de la salida JSON hay una o más entidades y sus datos. La entrada entity tiene dos campos:

Campos JSON de datos de entidad

Descripción

name

Requerido. El identificador/nombre de la entidad.

Recommendation: Utilice nombres de dominio inversos para generar nombres de integración únicos.

type

Requerido. El tipo de entidad. Será utilizado por el agente de infraestructura como namespace para componer un unique identifier junto con el name.

id_attributes

Opcional. Una lista de atributos de valor principal que brindan unicidad a una entidad. Se adjuntan al nombre en forma de key=value para facilitar la lectura, proporcionar información adicional y mejorar la unicidad del nombre de la entidad.

El atributo identificador es útil cuando el nombre de la entidad no es suficiente para funcionar como identificador único, o cuando no proporciona suficiente información significativa. Por ejemplo:

[
{
"key": "service",
"value": "mysql"
},
{
"key": "role",
"value": "master"
}, ...
]

Reemplazo de dirección de loopback en nombres de entidades

A partir de la versión 1.2.25 o superior del agente de infraestructura, el protocolo v3 mejora la unicidad de la entidad remota agregando reemplazo de direcciones locales en los nombres de las entidades a nivel de agente.

Cuando varias entidades remotas tienen su nombre basado en un extremo (ya sea ip o hostname), y este nombre contiene direcciones loopback, hay dos problemas:

  • Este valor de localhost no proporciona información valiosa sin más contexto.
  • El name podría colisionar con otro servicio cuyo nombre tenga una dirección local.

Esto sucede cuando:

  • Los nombres de los extremos son como localhost:port.
  • Los puertos tienden a ser los mismos para un servicio determinado; por ejemplo, 3306 para MySQL.

En los datos entrantes del protocolo v3, el agente de infraestructura reemplaza las direcciones de bucle invertido en el nombre de la entidad (y la clave) con el primer elemento disponible de la siguiente lista:

  1. ID del proveedor de la nube de la instancia, recuperado por el agente si corresponde
  2. Nombre para mostrar, configurado a través de la opción de configuración del agente display_name
  3. Nombre de host, recuperado por el agente

Por ejemplo, si una integración que utiliza el protocolo v3 devuelve una entidad con el nombre localhost:3306 y el agente se ejecuta en bare metal (no tiene el ID de proveedor de la nube de la instancia), display_name no se ha configurado y el nombre El host es prod-mysql-01, entonces el agente reemplazará el localhost y producirá el nombre de la entidad prod-mysql-01:3306.

El agente de infraestructura permite el reemplazo automático de direcciones de bucle invertido para el protocolo de integración v3. También puede habilitar esto para v2 a través del indicador de configuración del agente replace_v2_loopback_entity_names. En este caso, todas las integraciones ejecutadas por el agente usando v2 tendrán sus nombres reemplazados siempre que tengan una dirección local.

JSON: datos métricos, de inventario y de eventos

Los valores de los datos siguen el encabezado del archivo ejecutable. Puede registrar tres tipos de datos:

Importante

Desde la perspectiva del tablero de New Relic, la infraestructura métrica y el evento se clasifican como datos de eventos.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.