Ошибка Error getting history: MQTT RPC request timed out

Здравствуйте!
Появилась ошибка, предположительно после того, как закончилось свободное место.
Как исправить?

Добрый день!
Проверьте, сколько осталось свободного места, а если осталось мало, то куда ушло:

Проблема появилась после мереполнения и очистки диска от разросшихся логов. Исчезло само по себе через несколько дней.
Важно понять причину, тк история стала недоступна.

Не думаю, что мы сможем определить ошибку по описанию “ошибка была, но сейчас её нет. Данных по моменту, когда она была, тоже нет”.
Чтобы её не допустить, предлагаю наблюдать за размером /var/log/messages, иногда это вызывало проблемы.

Какие встроенные инструменты в wb есть для мониторинга свободного места?

Никаких. Можно написать своё правило в вызовом df, чтобы значение выводилось в виртуальное устройство.

Почему?

А что именно и в каком виде вы хотели бы видеть?

Хотел бы автоматическую отправку сообщения по почте о заканчивающемся месте, о превышении температуры и высокой загрузке процессора

Температура в интерфейсе есть, настроить уведомления о ней можно стандартными средствами: https://wirenboard.com/wiki/index.php?title=Notification_module
Добавить в интерфейс информацию о свободном месте и загрузке процессора можно через движок правил, а уведомления потом настроить тем же способом.
Делать это из коробки, наверно, не будем, потому что это первый такой запрос на моей памяти, и при этом его можно решить на уровне пользователя.

К сожалению я не нашел информацию, какая температура нормальная, а какая нет. Также в руководстве пользователя нет информации, сколько свободного места хорошо, а сколько плохо. Есть только куча сообщений на форуме о проблемах из-за закончившегося свободного места. Причем отсутствие свободного места в папке с логами делает устройство нерабочим.
Делать или нет - решать конечно вам, а никак не покупателям.
Но всем известен факт, что потребитель поощряет рублем.

С этим всё довольно просто: Wiren Board 6 — Wiren Board

Эксплуатация: Рабочая температура 0…+70 °С / -40…+85 °С (в зависимости от комплектации)

Если у вас индустриальная версия, каких большинство, то до +85 °С.

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

Вот например здесь мы уже создали задачу по оптимизации логирования, и она сейчас ждёт свободного времени инженера.
При этом лично меня расстраивает вот какой факт: вместо того, чтобы вместе разобраться с источником проблемы (которая точно не одна), что я неоднократно предлагал, пользователи просто что-то удаляют, и больше их эта проблема не тревожит. Нам это, разумеется, никак не помогает увидеть причину проблем.

А почему вы таким способом не хотите решить вашу задачу?

С температурой разобрался, спасибо!

Остается решить вопрос с свободным местом.
Если это так просто, как вы утверждаете, то почему бы не сделать вам самим скрипт и выложить его для доступа общественности? На мой взгляд знать информацию о состоянии устройства - это крайне важно с точки зрения эксплуатационных характеристик.

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

Да, согласен, ответили не очень быстро. Сейчас дописал ответ в другую тему, чтобы все замечали. Но считаю, что если кончилось место, то довольно логично проверить, из-за чего именно.

defineVirtualDevice("freeDiskSpace", {
  title:"Free Disk Space, in kB",
  cells: {
  'mnt data': {
    type: "text",
    value: "1200000"
  },
  }
});

function updateFreeDiskSpace() {
  runShellCommand("df -k /mnt/data | tail -1 | awk '{print $4}'", {
    captureOutput: true,
    exitCallback: function (exitCode, capturedOutput) {
      dev["freeDiskSpace"]["mnt data"] = capturedOutput.toString();
    }
  });
};

updateFreeDiskSpace();
setInterval(updateFreeDiskSpace, 1000);

Но я мог потратить это время на более важную задачу. А чтобы включить это в стандартное ПО, нужно потратить ещё больше времени: тестирование, включение в пакет, проверка установки пакета. Вы мне кажетесь заинтересованным пользователем, поэтому решил пойти навстречу; надеюсь, мои усилия не пропадут.

Чтобы нам понять, нужно ли это включать в стандартное ПО, давайте поступим так: каждый пользователь может отметиться в этой теме.

При этом нужно учитывать, что:

  1. Отдельная задача на исследование проблем логирования уже поставлена.
  2. Но сроки её выполнения неизвестны.
1 Like

Спасибо! Для меня этого вполне достаточно.
Теперь я могу без использования микроскопа в качестве молотка получать уведомление по почте о превышении температуры и о заканчивающемся свободном месте.

Хорошо бы еще проверять, все ли обязательные демоны запущены, и сообщать письмом о явных проблемах (эдакий вочдог-failover). Да, все возможные проблемы не перебрать, но наиболее частые вполне.

Место закончилось из-за включенного режима отладки - вырос лог. Я предполагаю, что ошибка в сабже связана именно с нехваткой места. После отключения логирования и очистки лога свободное место появилось, но ошибка не исчезла сразу. Спустя несколько дней ошибка пропала.

Думаю, адаптировать мой пример (а это на самом деле адаптированное системное правило, которое выводит IP-адрес в интерфейс: wb-rules-system/network.js at master · wirenboard/wb-rules-system · GitHub) не должно быть слишком сложно.

А какое у вас в целом применение? Мне казалось, что мониторинг по email не слишком часто используется.

Это звучит очень странно. В следующий раз лучше сразу установить причину проблемы.

В целом - управление всей электрикой в доме (свет, рольставни, розетки - например, отключение ненужных потребителей при переходе на генератор), отоплением, контроль за состоянием воздуха, контроль температуры теплоносителя, подачи, в колодцах и т.п.

Я настроил ежедневные отчеты о состоянии по почте - теплые ли полы, нет ли заморозков в колодце и др. Если письмо не пришло - значит проблема.

Но я мог потратить это время на более важную задачу. А чтобы включить это в стандартное ПО, нужно потратить ещё больше времени: тестирование, включение в пакет, проверка установки пакета. Вы мне кажетесь заинтересованным пользователем, поэтому решил пойти навстречу; надеюсь, мои усилия не пропадут.

Спасибо за пример скрипта! Нам необходимо контролировать основные параметры контроллера (загрузка CPU, использование оперативной памяти, свободное место на диске), при увеличении которых более определенных порогов, принимать решение например об апгрейде того или иного контроллера (например, сейчас на WB7).

Подскажите, пожалуйста, как нужно изменить скрипт, чтобы в нем получать значения загрузки CPU и оперативной памяти (в основном интересуют правильные команды в runShellCommand для получения нужной информации).

Здравствуйте!
Где-то на просторах портала пользователь выложил пример правила определения степени загрузки процессора. К сожалению, не нашел этого сообщения. Я немного доработал это правило, добавив данные по ОЗУ контроллера. Вот, что получилось:

defineVirtualDevice("controller_data", {
    title: "Controller Data",
    cells: {
        "CPU Utilization (prcnt)": {
            type: "range",
            min: 0,
            max: 100,
            value: 0.0,
            forceDefault: true,
        },
        "RAM Total": {
            type: "value",
            value: 0.0,
            forceDefault: true,
        },
        "RAM Available": {
            type: "value",
            value: 0.0,
            forceDefault: true,
        },
        "RAM Used (prcnt)": {
            type: "range",
            min: 0,
            max: 100,
            value: 0.0,
            forceDefault: true,
        },
    },
});

var prev_total = 0;
var prev_idle = 0;

function update_cpu_utilization() {
    runShellCommand("grep 'cpu ' /proc/stat", {
        captureOutput: true,
        exitCallback: function (exitCode, capturedOutput) {
            if (exitCode == 0) {
                var splittedOutput = capturedOutput.split(" ");
                if (splittedOutput != null && splittedOutput.length > 0) {
                    var idle = parseInt(splittedOutput[5]);
                    var total = 0;
                    for (i = 2; i <= splittedOutput.length - 1; i++) {
                        total += parseInt(splittedOutput[i]);
                    }
                    var utilization = (
                        (1 - (idle - prev_idle) / (total - prev_total)) *
                        100
                    ).toFixed();
                    dev["controller_data"]["CPU Utilization (prcnt)"] = parseInt(utilization);
                    prev_idle = isNaN(idle) ? 0 : idle;
                    prev_total = isNaN(total) ? 0 : total;
                }
            }
        },
    });
}

function update_ram_utilization() {
    runShellCommand("grep MemTotal /proc/meminfo | sed -e 's/MemTotal:s*//g'", {
        captureOutput: true,
        exitCallback: function (exitCode, capturedOutput) {
            if (exitCode == 0) {
                dev["controller_data"]["RAM Total"] = Math.round(parseInt(capturedOutput) / 1024);
            }
        },
    });

    runShellCommand("grep MemAvailable /proc/meminfo | sed -e 's/MemAvailable:s*//g'", {
        captureOutput: true,
        exitCallback: function (exitCode, capturedOutput) {
            if (exitCode == 0) {
                dev["controller_data"]["RAM Available"] = Math.round(
                    parseInt(capturedOutput) / 1024
                );
            }
        },
    });

    dev["controller_data"]["RAM Used (prcnt)"] = Math.round(
        ((dev["controller_data/RAM Total"] - dev["controller_data"]["RAM Available"]) /
            dev["controller_data/RAM Total"]) *
            100
    );
}

function update_controller_data() {
    update_cpu_utilization();
    update_ram_utilization();
}

setInterval(update_controller_data, 2000);


Результат выполнения:
image

2 Likes

Добрый день!

Если ещё что-то понадобится, команды проще всего загуглить запросами типа такого: linux how to get free ram single number - Поиск в Google

Но сегодня мне программист пообещал, что эти данные скоро (точно не скажу, но я бы ориентировался на март) появятся и в основном ПО контроллера.