Not found service: name=#{service.name} #{service.host}:#{se

Error message

Not found service: name=#{service.name} #{service.host}:#{service.port}

What it means

ServiceDiscovery::Manager#handle_message processes SERVICE_OUT by deleting @services[service.discovery_id]. When the id is not present — the service was never added (no prior SERVICE_IN reached the manager) or was already removed (duplicate/out-of-order OUT event) — the removal is a no-op and this warning names the unknown service. Discovery state stays consistent; the event is simply unactionable.

Source

Thrown at lib/fluent/plugin_helper/service_discovery/manager.rb:133

        private

        def handle_message(msg)
          service = msg.service

          case msg.type
          when Fluent::Plugin::ServiceDiscovery::SERVICE_IN
            if (n = build_service(service))
              @log.info("Service in: name=#{service.name} #{service.host}:#{service.port}")
              @services[service.discovery_id] = n
            else
              raise "failed to build service in name=#{service.name} #{service.host}:#{service.port}"
            end
          when Fluent::Plugin::ServiceDiscovery::SERVICE_OUT
            s = @services.delete(service.discovery_id)
            if s
              @log.info("Service out: name=#{service.name} #{service.host}:#{service.port}")
            else
              @log.warn("Not found service: name=#{service.name} #{service.host}:#{service.port}")
            end
          else
            @log.error("BUG: unknow message type: #{msg.type}")
          end
        end

        def build_service(n)
          @custom_build_method ? @custom_build_method.call(n) : n
        end
      end
    end
  end
end

View on GitHub (pinned to dd45c6e18d)

Solutions

If sporadic during deployment churn, treat as informational — the manager's state remains correct.
Verify the discovery source emits balanced IN/OUT events per discovery_id and does not duplicate OUTs.
Ensure the discovery manager is actually started and processing (no 'There is no discovery_manager' warning) so IN events are not missed.
Upgrade Fluentd if warnings are persistent, as ordering handling has been improved across releases.

Defensive patterns

Strategy: validation

Validate before calling

# Track known discovery ids and only act on OUT for services previously seen
known_ids = Set.new
def on_event(evt, known_ids)
  case evt.type
  when :service_in then known_ids.add(evt.discovery_id)
  when :service_out
    return unless known_ids.delete?(evt.discovery_id) # ignore unknown OUT
  end
end

Prevention

Emit discovery events from a single ordered source per service (balanced IN/OUT per discovery_id).
Expect harmless warnings during startup or pod churn; alert only on persistent repetition.
Ensure the discovery manager starts (no missing discovery_manager warning) so IN events are never missed.

When it happens

Trigger: A discovery source emits SERVICE_OUT for a service the manager never saw SERVICE_IN for (missed initial event, static config where start was skipped, service removed before its IN was processed); duplicate OUT events; discovery refresh racing service churn.

Common situations: DNS/file-based discovery where a target disappears between refreshes; Kubernetes pod churn delivering out-of-order events; transient mismatch right after Fluentd (re)start.

Related errors

AI-assisted analysis of fluent/fluentd@dd45c6e18d (2026-08-21). Data as JSON: /api/errors/b0b70c611e6d2806. Report an issue: GitHub.