Wb-metrics потребляет много оперативной памяти

1

После 3-4 месяцев uptime wb-metrics потребляет 85-90% оперативной памяти.
После перезагрузки 0,5-1% (по показаниям top)
для чего нужен этот сервис, может я могу его отключить?
версия прошивки 202412261556

3

Добрый день!

Можете, пожалуйста, уточнить:

  • установлено ли стороннее ПО;
  • вносились ли изменения в настройки штатных служб;
  • есть ли скриншоты с описываемым поведением.

Также для диагностики проблемы прошу прислать архив с диагностической информацией контроллера. Порядок создания архива описан в документации.

Описанное поведение ранее не встречал. Сервис предназначен для работы с метриками, возможные последствия уточню у коллег.

4

приложен диагностический архив, доступен только сотрудникам поддержки
(324,0 КБ)
из стороннего по только моя программа.
Программа делает каждую минту http запрос из которого получает аварии из winCC (json).
Cохраняет в фаил, и если есть новые аварии шлёт уведомления уведомления через firebase cloud messaging
ещё общается через mqtt достаточно большими json-ами.
(если есть необходимость могу сбросить исходники (на dart))
В настройках штатых служб изменял только логин и пароль для mqtt
Скриншотов сейчас нет, но думаю будут через 3-4 месяца.

приложен диагностический архив, доступен только сотрудникам поддержки
(324,0 КБ)

Моя программа запускается systemd

7

Добрый день!

Проанализировал логи — есть подозрительные повторяющиеся записи:

Jan 22 07:38:58 wirenboard-A43DI7YV systemd[1]: wb-cloud-agent-telegraf.service: Main process exited, code=exited, status=1/FAILURE
Jan 22 07:38:58 wirenboard-A43DI7YV systemd[1]: wb-cloud-agent-telegraf.service: Failed with result 'exit-code'.
Jan 22 07:39:09 wirenboard-A43DI7YV systemd[1]: wb-cloud-agent-telegraf.service: Scheduled restart job, restart counter is at 37.
Jan 22 07:39:09 wirenboard-A43DI7YV systemd[1]: Stopped telegraf metric sender for Wiren Board Cloud (default).
Jan 22 07:39:09 wirenboard-A43DI7YV systemd[1]: Starting telegraf metric sender for Wiren Board Cloud (default)...
Jan 22 07:39:09 wirenboard-A43DI7YV systemd[1]: Started telegraf metric sender for Wiren Board Cloud (default).
Jan 22 07:39:09 wirenboard-A43DI7YV telegraf[1500518]: 2026-01-22T07:39:09Z I! Loading config: /var/lib/wb-cloud-agent/telegraf.conf
Jan 22 07:39:09 wirenboard-A43DI7YV telegraf[1500518]: 2026-01-22T07:39:09Z E! error loading config file /var/lib/wb-cloud-agent/telegraf.conf: error parsing exec array, undefined but requested output: exec

Технически метрики как раз используются в облаке, и возможно именно этим вызвано повышенное потребление памяти, однако это пока гипотеза, а не утверждение.

Вижу два возможных пути:

  • исправить проблему с облачным агентом и понаблюдать за памятью;
  • дождаться момента утечки памяти и попытаться определить её причину.
8

суда по логу, сервис не может загрузить конфиг
вот вывод `cat /var/lib/wb-cloud-agent/telegraf.conf`:

Autogenerated config!

Created at: 2026-01-22 10:04:56.059275+00:00

Config Version: 1.0.1

[agent]
interval = “40s”
round_interval = true
metric_batch_size = 1000
metric_buffer_limit = 100000
collection_jitter = “5s”
flush_interval = “120s”
flush_jitter = “5s”

hostname = “A43DI7YV”
omit_hostname = false

[[outputs.exec]]
command = [
“bash”, “-lc”,
“out=$(curl --silent --show-error --fail --connect-timeout 5 --max-time 20 --engine ateccx08 --key-type ENG --cert /var/lib/wb-cloud-agent/device_bundle.crt.pem --key ‘ATECCx08:00:02:C0:00’ -H ‘Content-Type: text/plain’ --data-binary @- ‘https://timescale.wirenboard.cloud/telegraf’ -o /dev/null -w ‘http status=%{http_code} data size in bytes=%{size_upload}’); rc=$?; [ $rc -eq 0 ] && logger -t telegraf-exec "Metrics sent. $out"; exit $rc”
]
timeout = “30s”
data_format = “influx”

[[inputs.disk]]
name_override = “disk”
interval = “60s”
mount_points = [“/”, “/mnt/data”]
fieldinclude = [“free”]  # Собирать только указанные поля

[[inputs.mem]]
name_override = “mem”
interval = “40s”
fieldinclude = [“available”]

[[inputs.system]]
name_override = “system”
interval = “40s”
fieldinclude = [“load15”]

[[inputs.mqtt_consumer]]
alias = “mqtt-consumer-string”
name_override = “mqtt_consumer_string”
client_id = “wb-cloud-agent-telegraf-yfmxh9J1”

topics = [
“/devices/hwmon/controls/Board Temperature”,
“/devices/hwmon/controls/CPU Temperature”,
“/devices/power_status/controls/Vin”,
“/devices/system/controls/Release name”,
“/devices/system/controls/Release suite”,
“/devices/system/controls/Current uptime”,
“/devices/system/controls/HW Revision”,
]

servers = [“unix:///var/run/mosquitto/mosquitto.sock”]

qos = 0
persistent_session = false
data_format = “value”
data_type = “string”
9

также я вспомнил, что запускал команду
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
эта позваоляет пользоватся iptable в место nftable.
мне это нужно было для настроек wireguard

настройки wireguard:

[Interface]
PrivateKey = xxxxxxx
Address = 11.12.14.210/24
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT
PostUp = iptables -A FORWARD -o wg1 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg1 -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT
PostDown = iptables -D FORWARD -o wg1 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o wg1 -j MASQUERADE
PostDown = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = xxxxxx
AllowedIPs = 11.12.14.0/24
Endpoint = xx.xx.xx.xx:12001
PersistentKeepalive = 10

возможно настройки ip tables как-то повлияли на работу wb-cloud-agent-telegraf

Я не специалист по ip tables просто нашол в интрнети настройки которые мне нужны и копирую их везде. А тут на тебе `nftables` подвезли =)

10

Рекомендую проверить выполнив данные команды для диагностики облака.

Возможно они как раз и дадут ответ связанно ли это с изменениями с ip tables

11

вот сдесь что-то не так:
systemctl status wb-cloud-agent@wirenboard.cloud
● wb-cloud-agent@wirenboard.cloud.service - Wiren Board Cloud Agent (wirenboard.cloud)
Loaded: loaded (/lib/systemd/system/wb-cloud-agent@.service; enabled; vendor preset: enabled)
Active: inactive (dead)

янв 22 15:39:02 wirenboard-A43DI7YV systemd[1]: Condition check resulted in Wiren Board Cloud Agent (wirenboard.cloud) being skipped.

команда `traceroute` не найдена.
остальное всё ОК

при этом ssh досутп и web интрефейс из wirenboard.cloud работает

буду ждать момента утечки памяти

12

Добрый день!
Рекомендую посмотреть подробные логи сервиса.

journalctl -u wb-cloud-agent@wirenboard.cloud -n 50
13

весь журнал - это 1 строка
Jan 22 15:39:02 wirenboard-A43DI7YV systemd[1]: Condition check resulted in Wiren Board Cloud Agent (wirenboard.cloud) being skipped.

14

Уточню, а контроллер к облаку подключен же верно?

15

Да подключён. И доступ по ssh и к web интерфейсу работает

16

Самый быстрый способ привести конфигурацию к исходному состоянию — переустановить пакет облачного агента. Для этого выполните следующие команды:

systemctl stop wb-cloud-agent@wirenboard.cloud
apt purge wb-cloud-agent
apt update
apt install wb-cloud-agent
systemctl enable wb-cloud-agent@wirenboard.cloud
systemctl start wb-cloud-agent@wirenboard.cloud
17

Добрый день!

Подскажите, пожалуйста, удалось ли вам решить проблему?

18

я ещё не выполнял эти рекомендации:
systemctl stop wb-cloud-agent@wirenboard.cloud apt purge wb-cloud-agent apt update apt install wb-cloud-agent systemctl enable wb-cloud-agent@wirenboard.cloud systemctl start wb-cloud-agent@wirenboard.cloud

19

переустановил wb-cloud-agent@wirenboard.cloud
теперь wb-cloud-agent работает :
root@wirenboard-A43DI7YV:~# journalctl -u wb-cloud-agent@wirenboard.cloud -n 50
– Journal begins at Fri 2026-01-09 06:29:50 UTC, ends at Mon 2026-01-26 06:19:31 UTC. –
Jan 22 15:39:02 wirenboard-A43DI7YV systemd[1]: Condition check resulted in Wiren Board Cloud Agent (wirenboard.cloud) being skipped.
Jan 26 06:18:22 wirenboard-A43DI7YV systemd[1]: Starting Wiren Board Cloud Agent (wirenboard.cloud)…
Jan 26 06:18:23 wirenboard-A43DI7YV systemd[1]: Started Wiren Board Cloud Agent (wirenboard.cloud).
Jan 26 06:18:23 wirenboard-A43DI7YV wb-cloud-agent[551650]: ====== Cloud Agent started (provider: ``https://wirenboard.cloud``) ======
Jan 26 06:18:23 wirenboard-A43DI7YV wb-cloud-agent[551650]: Start checking cloud reachability (interval: 10s, max_attempts: 100)
Jan 26 06:18:24 wirenboard-A43DI7YV wb-cloud-agent[551650]: Cloud reachability - OK
Jan 26 06:18:25 wirenboard-A43DI7YV wb-cloud-agent[551650]: Cloud Agent initialization - OK
Jan 26 06:18:30 wirenboard-A43DI7YV wb-cloud-agent[551650]: Cloud Agent is successfully connected to the cloud!

что касается wb-metrics:
пеcле ребута потребление оперативной памяти сервисом около 1 %
после 5 дней up time → 4.9%.

изображение
изображение882×472 168 KB

наблюдаю дальше

20

Добрый день!

Подскажите, пожалуйста, сохраняется ли проблема?

Также дополнительно обсудили ситуацию с коллегами для исключения влияния внешних факторов и пришли к выводу, что наиболее надёжный способ проверки — выполнить сброс к заводским настройкам, обновиться до последней версии и проверить, сохранится ли проблема после этого.

21

uptime почти 9 дней, потреблейние памяти увеличелось.

изображение
изображение883×451 128 KB

и проблема с `телеграф` осталось

изображение
изображение1907×245 136 KB

делать сброс до зоводских настрояк я не хочу, так как контроллер на объект работает. А объект в сочи а я в белоруси.

Я бы лучше предпочёл делать рестарт раз в сутки по крону wb-metrics.
подскожите команду для cron, что бы перезапукать wb-metrics.
типа `systemctl restart “{wb-metrics-service-name}“`

24

Добрый день!

Рекомендую еще обновиться до актуального на данный момент релиза 2507 и проверить, сохраняется ли проблема после обновления.

25

помогите мне лучше отключить
wb-metrics и wb-cloud-agent-telegraf@wirenboard.cloud.service

Просто обновление системы иногда может привести к проблемам,
а если при этом контроллер отключится от облака - это не страшно, у меня всёрано есть удалённый доступ через мой VPN