Closed onion83 closed 1 week ago
Thank you @onion83 for reporting! We're investigating in order to fix this soon.
@onion83, hey. Can you try creating a ping job directly on netdata-sz-ctc
? You will need to select the node
Unknown config id given
This may indicate that the go.d.plugin (it has ping functionality) is not running on that particular node.
As shown in the attached video, I recreated a brand-new node, netdata-sz-ctc2
, and added it to the dashboard, confirming it is online. The video shows netdata.cloud
on the left and the local node on the right.
netdata-sz-ctc2
and confirm via the ps
command that go.d.plugin
is running in the system processes.localtest
and confirm its success.netdata.cloud
management console, attempt to sync an existing node's (netdata-cmc
) apps
monitoring task to netdata-sz-ctc2
. This failed.netdata-sz-ctc2
, attempt to add a task named apps
with the monitoring target 1.1.1.1
.netdata-cmc
node, use the "Submit to multiple nodes" feature and select netdata-sz-ctc2
as the sync target. This time, the task succeeded.apps
monitoring task on netdata-sz-ctc2
, the monitoring target is now fully synchronized with netdata-cmc
.Therefore, the current bug is: After adding a new node, an empty task with the same name must be created to sync with other nodes (only tested with the ping plugin, other plugins not tested).
Expected:
https://github.com/user-attachments/assets/107211c2-fd1c-45b8-9d9b-e25392fdf517
@onion83, hey. Not related to the issue, but: performance in the "privileged" mode can become less efficient as the number of targets grows. This is because CPU usage scales disproportionately, meaning it increases much faster than the number of targets. That is a bug in the upstream library we use for go.d/ping. See netdata/netdata#15410.
hey @ilyam8 Please take a look at the title, issue, and video description. This is specifically about the task distribution issue with the Dynamic Configuration Manager and not related to ping values or system permissions 、cpu etc...
I know that, that is why I started with "Not related to the issue".
@ilyam8 : Is this a bug at the agent side? I don't see why the user needs to create a local job (on the local Agent dashboard) before submitting it to multiple nodes? Or @kapantzak have you identified some issue on the FE side for this?
@sashwathn I don't see any FE issue here
Is this a bug at the agent side?
What is happening:
We need to provide another way to copy dyncfg items from Node to Node, or treat "update" as "add" if there is no existing job.
or treat "update" as "add" if there is no existing job.
I think we need this, I will discuss it with @ktsaou when he returns.
So for all nodes is an update, but for the new nodes it has to be an add.
The solution is to convert an update to an add if the item is not already there?
The solution is to convert an update to an add if the item is not already there?
Yes.
cc @onion83
An alternative is to use this workflow:
This will result in "add" - no issues.
https://github.com/user-attachments/assets/d4c102cd-8f38-4ae3-8c73-eb8f45e4e964
@kapantzak hey 👋 We discussed the issue with @ktsaou and suggest the following changes to frontend:
Hi @onion83, we released some changes for this that hopefully fixes the issue.
It works! thank you
Bug description
When using the Dynamic Configuration Manager in Netdata Cloud, encounter an error message "Unknown config id given" when trying to assign existing monitoring tasks to a new node by clicking "Submit to multiple nodes"
Expected behavior
Success
Steps to Reproduce
Perform a Full New Install of a Node (LXC by Proxmox):
Install Using Integrations Auto Shell Script:
kickstart.sh
and wait for the node to appear as active in the Netdata Cloud dashboard.Submit Tasks to Multiple Nodes:
Installation method
kickstart.sh
System info
Netdata build info
Additional info
No response