In version v1.32 of Netdata, we announced a remarkable new update that we are extremely proud of; Netdata Cloud now runs on the most reliable and stable backend that we’ve ever built.
Migration to the new Netdata Cloud architecture
To give you the best experience of Netdata Cloud, we started migrating nodes running on the old architecture to the new one. Most users don’t have to take any action on their part. If you need to take action, you will see the pop-up window above in Netdata Cloud.
Get ready for the new architecture
Let’s look at what you need to do to ensure that your nodes are still reachable after 15th of March 2022. To determine what steps you need to take, you need to check what type of installation you have.
Starting with Netdata v1.33.0, you can use Netdata itself to determine the installation type by running: netdata -W buildinfo | grep 'Install type:'
If you are using an older version of Netdata, or the above command produces no output, you can run our one-line installation script in dry-run mode to attempt to determine what method to use to update by running the following command:
wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh --dry-runNote that if you installed Netdata using an installation prefix, you will need to add an --install option specifying that prefix to make sure it finds the existing install.
The value of INSTALL_TYPE indicates the type of installation.
If you use Netdata in Docker, or have installed Netdata as a static build, for example, by using the kickstart script:
• Update your Netdata agents to the latest version
📄 Update Netdata
Because the new architecture of Netdata Cloud relies on protobuf:
• Update your Netdata agents to the latest version
📄 Update Netdata
• Install a C++ compiler
If you still encounter issues, check if your node meets all requirements for Netdata Cloud.
Binpkg type of installations should not experience any difficulties with the new architecture. If you run into an error:
Other installation methodsAs per Netdata’s platform support policy, there are packages that are not maintained by us. If a community-maintained package isn’t compatible with the new architecture:
• File a bug with the appropriate package maintainer
Why we built a new architecture
Our motivation to overhaul the Netdata Cloud backend was to build a sleek, reliable foundation for all the exciting features we have planned ahead. The architectural changes allow us to deliver new features, such as parent-child relationships and improved alert handling.
Goodbye Legacy Agent Cloud Link (ACLK). Say hello to the next generation ACLK
Along with an overhauled backend, we also updated the Agent Cloud Link, which lets you connect nodes to the Netdata Cloud. ACLK-ng (new generation) is up to 4x faster than ACLK legacy. Since we introduced ACLK-ng back in v1.30, we deprecated the ACLK legacy in v1.33 of Netdata.
Switching from JSON to Protocol Buffers (protobuf)
We’re constantly looking for ways to make Netdata Cloud even faster and work as seamless as possible with the Netdata Agent. In the past, we’ve used JSON to transmit metadata between nodes. However, making the switch to protobuf allows us to leverage high speeds and reliability because of its message format and schemas. Another benefit: protobuf uses less bandwidth than its predecessor.
We hope you are just as excited as we are for the switch to the new architecture. While you can already enjoy benefits like lightning speed and extreme reliability, we have created a solid foundation to make your troubleshooting experience even more fun. In our upcoming releases, you will get access to an enhanced alert management experience.