Windows services integration

New Relic's Windows services integration collects data about the services running on your Microsoft Windows hosts and sends it to our platform. You can check the state and start mode of each service, find out which hosts are running a service, set up alerts for services, and more.

Our integration is bundled with the Windows infrastructure agent. If you're monitoring Windows hosts on New Relic, you only need to enable the integration to get Windows services data into our platform.

Why it matters

Microsoft Windows services are the Windows equivalent of daemons in Unix and Linux: long-running executables that can be started, stopped, paused, and restarted without a graphical interface. Knowing which services are enabled, or their state or health, is essential when monitoring Windows infrastructure.

With our Windows services integration you can:

• Check all your Windows services, their state (running, stopped, etc.), start mode (auto, manual, etc.), and other service metadata.
• See which hosts are running specific Windows services.
• Set alerts based on any Windows services that you are monitoring using New Relic.
• Install the Windows Services Quickstart or create your own dashboards to track your Windows services.

Compatibility and requirements

Our integration is compatible with all Windows versions supported by the New Relic agent.

You must have version 1.12.1 or higher for our infrastructure monitoring agent installed on a supported host. The x86 Windows versions are not yet supported.

Install and activate

To install the Windows services integration:

1. Change the directory to the integrations folder:

   bash

   Copy

   $
   cd C:\Program Files\New Relic\newrelic-infra\integrations.d\

2. Copy of the sample configuration file:

   bash

   Copy

   $
   copy winservices-config.yml.sample winservices-config.yml

3. Edit the winservices-config.yml file as described in the configuration settings and save it.

Update your integration

The Windows services integration is bundled with the infrastructure monitoring agent. To update the integration, update the agent to the latest version.

Configure the integration

To enable the integration, edit and save the winservices-config.yml:

• Uncomment exporter_bind_address: and exporter_bind_port:
• Add the name of the services you want to monitor to include_matching_entities:

By default, no service is included. To include and filter services, you must edit include_matching_entities:.

Also, the configuration option inventory_source is not compatible with the integration.

Here's an example of the Windows services integration configuration:

integrations:
  - name: nri-winservices
    config:
      # IP address and port used by the Prometheus exporter to bind the server.
      # 
      # exporter_bind_address: 127.0.0.1  
      # exporter_bind_port: 9182

      # To include services, create a list of filters to be applied to the service names.
      # Services that find a match with any of the matching lists are included. By default,
      # no service is included.
      #
      # Currently, only windowsService.name metadata is supported for filtering.
      # Prepend "regex" to indicate that the pattern is a regular expression
      #
      include_matching_entities:
        windowsService.name:
          # - regex ".*"
          # - "newrelic-infra"

      # Time between consecutive metric collection of the integration.
      # It must be a number followed by a time unit (s, m or h), without spaces.
      #
      scrape_interval: 30s

    # Timeout used by the agent to restart the integration if no heartbeats are
    # sent from the integration. Heartbeats are sent every 5s, so this timeout
    # shouldn't be less than that.
    #
    timeout: 60s

    # Since this is a long-running integration, interval is ignored. To
    # configure the interval period for collecting and sending data, edit
    # the scrape_interval parameter.
    #
    # interval:

Set up an alert

You can create Windows services alerts using NRQL conditions to get notified about state changes of the services you wish to monitor. Here are two examples of alert conditions that use Windows services data:

SELECT count(*) FROM Metric WHERE metricName = 'windows_service_state' AND state != 'running' AND service_name = 'lfsvc' FACET entity.name

FROM Metric SELECT count(*) WHERE start_mode='auto' AND state!='running' FACET service_name

How it works

To get data from Windows hosts, our Windows services integration uses a reduced version of the Prometheus exporter for Windows, which exposes Prometheus metrics on the port specified in the agent configuration. The integration collects these metrics, transforms them into entities, filters them, and then sends them to New Relic.

Metric data

The Windows services integration provides the following data:

Metadata

The Windows services integration sends the following metadata to New Relic:

• display_name: Name of the service as viewed in the services snap-in.

• service_name: Unique identifier of the service.

• process_id: Process identifier of the service.

• run_as: Account name under which a service runs. Depending on the service type, the format of the account name may be DomainName\Username or Username@DomainName (UPN). The value is taken from the StartName attribute of the Win32_Service class, which can be NULL (in that case, the label is reported as an empty string).

  Important

  If the StartName attribute is NULL, the service is logged on under the LocalSystem account. For kernel or system-level drive, it runs with a default object name created by the I/O system based on the service name, for example, DWDOM\Admin.

Source code

The Windows services integration is open source software. That means you can browse its source code and send improvements, or create your own fork and build it. For more information, see the README.