remote-monitoring-host-integrations.mdx

title	tags	metaDescription	redirects	freshnessValidatedDate
Remote monitoring for on-host integrations	Integrations On-host integrations Understand and use data	How remote monitoring works for some New Relic on-host integrations (particularly Apache, Cassandra, MySQL, NGINX, and Redis)	/docs/integrations/host-integrations/understand-use-data/remote-monitoring-host-integrations /docs/remote-monitoring-host-integrations /docs/remote-monitoring-host-legacy-integrations	never

From a New Relic perspective, entity is a broad concept. An entity is anything New Relic can identify that has data you can monitor.

Our on-host integrations can be configured to create their own entity, called a remote entity, by setting the remote_monitoring option to true. If set to false, an integration will be considered a local entity, and the data related to it will be attached to the host entity that the agent creates. Remote monitoring requires infrastructure agent version 1.2.25 or higher.

For the Apache, Cassandra, MySQL, NGINX, and Redis integrations, remote monitoring (and multi-tenancy) is enabled by activating the configuration parameter remote_monitoring.

If your Apache, Cassandra, MySQL, NGINX, or Redis service is located in the same host as the agent, when you activate remote monitoring the resulting entity will be considered as remote, regardless of its actual location. This may affect alerts, alter attributes, and have other effects, as explained here.

Effects of activating remote_monitoring [#effects-activating-remote-monitoring]

By enabling remote_monitoring, the integration becomes a different entity which is no longer attached to the infrastructure agent. As a result, the following items may be affected:

[**Enabling remote monitoring can affect your configured alerts**](/docs/verify-your-alerts-after-activating-remote-monitoring) in case they are using any of the values that are affected by this new feature. We strongly recommend checking your existing to make sure they keep on working as expected.

<Collapser id="new-entity-attributes" title="New entity attributes"

These attributes are modified in the resulting entity:

* <DNT>**Display name**</DNT>: New entity unique key (instead of using the display name)
* <DNT>**Entity GUID**</DNT>: New entity GUID
* <DNT>**Entity ID**</DNT>: New entity ID
* <DNT>**Entity key**</DNT>: New entity unique key (instead of using the display name)
* <DNT>**External key**</DNT>: Using integration entity name (instead of using the agent display)

<Collapser id="new-decoration" title="Changes in recorded metrics"

When remote monitoring is enabled, we will add the `hostname` and `port` values to all metrics. If the `nricluster` name or `nriservice` are defined in the integration configuration file, they will also be decorated.

<Collapser id="lost-attributes" title="Unrecorded attributes"

Since the integration is now an independent entity which is not attached to the agent, the following agent attributes are not collected:

* `agentName`
* `agentVersion`
* `coreCount`
* `criticalViolationCount`
* `fullHostname`
* `instanceType`
* `kernelVersion`
* `linuxDistribution`
* `entityType`
* `operatingSystem`
* `processorCount`
* `systemMemoryBytes`
* `warningViolationCount`
* Your [custom attributes](/docs/infrastructure/new-relic-infrastructure/configuration/configure-infrastructure-agent#attributes)

<Collapser id="updated-hostname" title="Updated hostname"

For the `ApacheSample`, `RedisSample`, `CassandraSample`, and `NginxSample` integration metrics, we will use the integration configuration hostname instead of the short hostname from the agent.

When the integration hostname is a [loopback address](/docs/integrations/integrations-sdk/file-specifications/integration-executable-file-specifications#h2-loopback-address-replacement-on-entity-names), the agent will replace it in order to guarantee uniqueness.