Seems like I'm not the only one. Kinda confused as to why it is happening, maybe the error is a misnomer
When I run telegraf --test /etc/telegraf the output for system is:
> system,host=134e7e15f4ba load1=2.21,load15=1.92,load5=2.31,n_cpus=1i,n_users=0i 1667813275000000000
> system,host=134e7e15f4ba uptime=245239i 1667813275000000000
> system,host=134e7e15f4ba uptime_format="2 days, 20:07"...
Thank you for taking the time to check the code and confirm it isn't proxmox. Considering The only two sources I have writing to the influxdb are proxmox and telegraf I'm confused as to what could have created the metric as a float.
I will investigate further. Thanks again.
I happened to look at my influx logs and noticed the following error occurring:
ts=2022-11-03T15:52:15.241668Z lvl=info msg="Failed to write point batch to database" log_id=0dwTt70G000 service=udp db_instance=udp error="partial write: field type conflict: input field \"uptime\" on...
with mine this happens when my session is stale and/or I'm logging on to another node in the cluster from a logon session on a different server.
normally just refreshing the page and logging in again fixes it.
Not saying that's the answer, just that I've seen it before.
I think, but am not sure, that lxc provides a certain level of isolation, but not as much as a vm. If you run docker in lxc some containers may not work if they require access to the kernel that lxc will not permit ?
If someone could clarify or correct me I would appreciate it.
I'm interested in doing some terraform with Proxmox. As far as I can see, the most maintained and up to date provider is https://registry.terraform.io/providers/bpg/proxmox/latest
located at https://github.com/bpg/terraform-provider-proxmox
Does anyone know if there is a better provider...
If you're wondering why I don't just mount the remote nfs share inside the guest there is a rationale. It is on an isolated network with no visibility of any other machine, but I want to mount some data within it for docker.
Thank you for the replies. I appreciate your effort. It appears it didn't achieve any result for me anyway.
2022-09-28 10:08:47 starting VM 106 on remote node 'test'
2022-09-28 10:08:49 start remote tunnel
2022-09-28 10:08:50 ssh tunnel ver 1
2022-09-28 10:08:50 starting online/live migration...