Home / Infrastructure Migration / How to Fix a Graylog Input Still Receiving Logs on the Old Node After Migration

Infrastructure Migration

How to Fix a Graylog Input Still Receiving Logs on the Old Node After Migration

Fix a Graylog input still receiving logs on the old node after migration by checking input bindings, load balancer targets, sidecar config, and stale sender endpoints.

Published: Nov 2, 20256 min readBy FixWikiHub Editorial Team

Abstract illustration for infrastructure migration troubleshooting guides.

Introduction

A logging migration can move ingestion to a new Graylog node or cluster while one input still receives traffic on the old node. The new platform appears healthy, but live log streams continue landing on the retired path, one sender reaches the new input while another still targets the previous node, or failures begin only after the old listener is shut down because input bindings, load balancer targets, and sender configuration often change separately.

Treat this as an ingestion-target problem instead of a generic Graylog outage. Start by checking which input and node an affected log sender actually connects to, because migrations often validate the new input from the Graylog UI while real agents continue following older listener addresses.

Symptoms

A Graylog input still receives logs on the old node after migration
The new input is healthy, but production logs still land on the retired listener
One sender or source group uses the new node while another still uses the previous one
Logging failures begin only after the old node, port binding, or load balancer target is removed
The new cluster is healthy, but migrated senders never use it consistently
The issue started after moving Graylog nodes, inputs, load balancers, or sender management paths

Common Causes

The input still binds only on the old node or old address path
Load balancer or DNS targets still include the retired Graylog node
Sidecar-managed collector config or sender output settings still point to the previous listener
A node-specific input was recreated on the new cluster, but senders still target the earlier endpoint
Automation or bootstrap config restored older sender or load balancer settings
Validation confirmed the new input accepted test data but did not verify which node live log senders actually reached

Step-by-Step Fix

1.Capture one affected sender and record the output target, input type, listening address, and Graylog node it actually reaches, because the live ingestion path determines where logs really land.
2.Compare that active sender path with the intended post-migration logging design, because one stale listener target or load balancer member can keep production logs tied to the retired node.
3.Review Graylog input bindings, load balancer config, DNS records, sidecar collector config, and sender output templates for references to the old node, because Graylog ingestion depends on both platform listeners and sender-side targeting.
4.Check each input type, sender class, and network path separately if behavior differs, because migrations often update one log stream while another still reaches the previous listener.
5.Update the authoritative input endpoint and sender configuration so affected logs land on the intended node or cluster, because creating the new input alone does not retarget existing senders.
6.Run a controlled log event and confirm the intended Graylog input and node receive it, because a healthy dashboard does not prove the right listener handled production traffic.
7.Verify the old node no longer receives log traffic from migrated senders, because split ingestion paths can remain hidden while both listeners stay available.
8.Review TLS trust, firewall rules, and collector backpressure if logs still fail, because the destination can be correct while transport policy or sender health still blocks the new path.
9.Document which team owns Graylog inputs, sender config, and migration validation so future logging cutovers verify the actual runtime ingestion target before retiring the previous node.

Verification

After applying fixes:

1.Send test log and verify arrival on new node
2.Check old node for any continued log traffic
3.Verify load balancer targets only new nodes
4.Confirm all senders point to correct endpoints
5.Test all input types are working correctly

Prevention

To prevent Graylog ingestion issues during future migrations:

1.Document input configurations - Before migration, inventory all inputs, their bindings, and connected senders.
2.Update sender configuration centrally - Use Graylog Sidecar or configuration management to update sender targets consistently.
3.Update load balancers first - Change load balancer targets before shutting down old nodes to redirect traffic gracefully.
4.Monitor both nodes - During migration, monitor ingestion metrics on both old and new nodes.
5.Use DNS with low TTL - Use short DNS TTL for Graylog endpoints to enable quick redirection.
6.Test each sender type - Verify that each distinct sender configuration (syslog, beats, etc.) is correctly updated.
7.Document sender ownership - Maintain clear documentation of which teams manage which log senders

Common Pitfalls

Updating Graylog inputs without updating sender config
Forgetting to update load balancer targets
Not checking all sender types
Missing Sidecar-managed collectors
Assuming input creation redirects traffic
Not verifying DNS changes have propagated

[WordPress troubleshooting: Fix CloudFormation Permission Denied - C](fix-cloudformation-permission-denied)
[Technical troubleshooting: Fix Cloud Migration Data Transfer Incomplete Issue](cloud-migration-data-transfer-incomplete)
[Fix Database Migration Schema Lock Timeout in Infrastructure Migration](database-migration-schema-lock-timeout)
[Fix DNS Cutover Propagation Delay Issue in Infrastructure Migration](dns-cutover-propagation-delay)
[How to Fix Ansible Automation Controller Still Running Jobs Against the Old Execution Environment After Migration](fix-ansible-automation-controller-still-running-jobs-against-old-execution-environment-after-migration)

Was this guide helpful?

Related search paths

People also search for

If the symptom is close but not identical, these search paths usually surface the right neighboring fixes faster than scrolling the full archive.

a Graylog Input Still Receiving Logs on the Old Node a Graylog Input Still Receiving Logs on the Old Node Infrastructure Migration a Graylog Input Still Receiving Logs on the Old Node troubleshooting a Graylog Input Still Receiving Logs on the Old Node fix Fix a Graylog input still receiving logs on the old node after migration by checking input bindings, load balancer targets, sidecar config, and stale sender endpoints Infrastructure Migration Fix a Graylog input still receiving logs on the old node after migration by checking input bindings, load balancer targets, sidecar config, and stale sender endpoints

Explore Related Topics

Browse Guides from Other Categories

Discover troubleshooting guides from related categories to expand your knowledge.

FAQ

Infrastructure Migration Troubleshooting FAQs

Common questions about troubleshooting and preventing similar issues

How do I know if this infrastructure-migration troubleshooting guide applies to my situation?

This guide is designed for infrastructure-migration issues. If you're experiencing similar symptoms described in the article, follow the step-by-step instructions. Start with the most common causes and work through the diagnostic process.

Is it safe to follow these infrastructure-migration troubleshooting steps?

Yes, all steps are designed to be safe and non-destructive. We recommend creating backups before making significant changes and testing each step before proceeding to the next.

How long does it typically take to resolve this type of infrastructure-migration issue?

Most infrastructure-migration issues can be resolved within 30 minutes to 2 hours, depending on the complexity and root cause. Follow the troubleshooting flow to identify and fix the problem efficiently.

How can I prevent this infrastructure-migration issue from happening again?

Regular maintenance, monitoring, and following best practices for infrastructure-migration configuration can help prevent recurrence. Consider implementing automated checks and alerts for early detection.

Written by

FixWikiHub Editorial Team

Our editorial team consists of experienced DevOps engineers, systems administrators, and cloud architects with hands-on experience in production environments across AWS, Azure, GCP, and on-premises infrastructure.

Every guide undergoes technical review for accuracy and is updated when software versions, commands, or best practices change.

Last updated: Nov 2, 2025

About our team

Important Notice

Disclaimer & Safety Guidelines

The troubleshooting steps in this guide are provided for educational and informational purposes. Before applying any changes to production systems:

Test in a staging environment first — Always verify commands and configurations in a non-production environment before deploying to live systems.
Create backups — Ensure you have current backups of databases, configurations, and critical files before making changes.
Understand the impact — Review how each step may affect your specific environment, dependencies, and users.
Consult official documentation — This guide supplements, but does not replace, official vendor documentation and best practices.

FixWikiHub is not responsible for any damages arising from the use of this content. See our Terms of Use for more information.

Resources

Official Documentation & Further Reading

For authoritative information, consult the official documentation for the technologies discussed in this guide. Our troubleshooting content supplements, but does not replace, vendor documentation.

AWS Documentation — Official Amazon Web Services guides and API references
Kubernetes Documentation — Official Kubernetes documentation
Nginx Documentation — Official Nginx web server documentation
Apache Documentation — Official Apache HTTP Server documentation
Docker Documentation — Official Docker container documentation