New Relic Servers End of Life
To handle the new relic servers end of life, replace the old agent with the new host agent. You must install the new agent on each host and remove the old server monitor. Teams often run these install scripts with broad root permissions across every machine. Broad roles create big risks when an engineer or script makes a mistake on a live host. How to manage the new relic servers end of life migration The legacy server monitor only tracks basic CPU, memory, and disk metrics. It cannot link ho
End-to-End Encryption + DPoP (Demonstration of Proof-of-Possession): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To handle the new relic servers end of life, replace the old agent with the new host agent. You must install the new agent on each host and remove the old server monitor. Teams often run these install scripts with broad root permissions across every machine. Broad roles create big risks when an engineer or script makes a mistake on a live host.
How to manage the new relic servers end of life migration
The legacy server monitor only tracks basic CPU, memory, and disk metrics. It cannot link host health to app logs or cloud tags. The vendor ended support for the old server agent and replaced it with a modern host agent. Moving to the new agent requires a clean setup on every Linux and Windows machine.
First, teams audit all hosts to find where the old server agent still runs. Next, they add the vendor package source and install the new host agent with a license key. The new agent starts a background service that reads local system metrics and host state. It then sends this data over an encrypted link to the main dashboard. After the new metrics show up, admins stop and remove the old server agent. Finally, teams update their alert rules to point at the new host data streams.
What the native host setup solves and what it misses
The new host agent solves the core metric gap left by the old server tool. It collects rich data on processes, network traffic, and storage health in real time. Teams can filter hosts by custom tags and see when a config change breaks an app. You also get role controls inside the dashboard to limit who can view or edit alerts.
Still, dashboard roles only control what users see in the web view. When an alert fires, engineers still log in to the actual host to fix the issue. Native OS roles decide who can log in, not what commands they run during a session. A user with root rights can run any command or read sensitive files on that machine. Standard host permissions cannot block dangerous commands in flight or redact private data from screen output. If a log file contains emails, phone numbers, or card numbers, the raw text prints on screen.
End-to-End Encryption + DPoP (Demonstration of Proof-of-Possession): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing host sessions during agent updates
During a fleet migration, many people need shell sessions on live servers. Giving every team member full admin rights on every host invites human error. One bad command can wipe a disk or stop a critical app service.
Teams need a way to check every command before the server runs it. They also need to rewrite matched fields like national IDs in results before data leaves the host. Controlling the active session closes the gap between dashboard alerts and safe server fixes.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens if we keep running the old server agent?
The old server agent no longer gets security patches, bug fixes, or support from the vendor. Data ingestion and old alert views stop working once the vendor shuts down the legacy backend endpoints.
Can the old server monitor and the new host agent run together?
Yes, both agents can run on the same machine for a short time during your transition. You should remove the old agent soon after to save CPU and memory on the host.
Do we need to rebuild our server alert rules after migrating?
Yes, the new host agent uses a different data format and metric naming style. You must create new alert rules that read from the updated host data tables.