Разрабатываю шаблон для мониторинга серверов HP G10 по протоколу Redfish. Всё достаточно прозрачно, делаем https запрос, получаем ответ JSON, вытаскиваем данные в зависимые элементы данных. Всё было прекрасно, пока не натолкнулся на локализованный Windows 2016 Какой то чудак перевёл слово Microsoft на русский язык - Майкрософт. Поскольку это Windows - во всех базах WMI кодировка 1251. Нетрудно догадаться, что когда я запрашиваю https//URL/redfish/v1/Systems/1/ приходит JSON объект внутри которого имеется параметр OsName со значением Майкрософт Windows Server 2016 Standard. До предобработки дело не доходит. Разработчики zabbix по прежнему считают, что в мире есть только одна кодировка UTF-8. И поэтому вместо того, чтобы отдать объект as is, выдают - Server returned invalid UTF-8 sequence. Пробую получить данные не через HTTPS элемент данных, а командой wget. Чудесным образом получаю объект с кодировкой 1251. Никто мне не мешает удалить из метрики слово Майкрософт. Теперь вопрос: кому нужна проверка на соответствие кодировки UTF-8 в ответе запроса htps? Сайтов с кодировкой отличной от UTF-8 в мире предостаточно.
-
-
Всё понятно, кроме цели данной публикации на форуме. Излить душу в эфир? Ну излили, мы посочувствовали...
Если же хочется как-то повлиять на команду разработчиков Zabbix (которые здесь на форуме появляются крайне редко), то более действенным способом было бы зарегистрироваться на сайте support.zabbix.com и проголосовать, например, за вот этот тикет (ссылка), описывающий подобную проблему (секция "Votes:" справа вверху). А то на данный момент там всего два голоса (один из которых - автора тикета, второй - мой), из-за чего у разработчиков резонно складывается впечатление, что эта проблема для подавляющего большинства пользователей совершенно неактуальна
-
Уважаемый Kos, цель публикации узнать, что делают другие в подобных случаях. Не все имеют время и возможности постоянно просматривать ZBX. Насколько я понимаю, Вы это делаете на регулярной основе. Может быть вам стоит публиковать на форуме посты с предложением проголосовать за наиболее злободневные проблемы в ZBX? Я уже создавал три года назад тикет на эту тему ( ссылка ). Его закрыли с отметкой, что подобная проблема уже есть как раз в том тикете на который вы ссылаетесь.
За предложенный тикет проголосовал. Но у Владышева непробиваемая позиция: "А workaround to solve this problem is to do the conversion with JS in preprocessing steps" Если бы разработчики не перехватывали метрику, я бы так и сделал:
function request(url) {
api_request = new HttpRequest();
.........
}
try {
response = JSON.parse(value);
}
catch (error) {
response = null;
}
if (!response) {
response = request(url + '/redfish/v1/Systems/1/')
}
К сожалению, до этого не доходит. Вот я решил узнать, есть ли какой способ вместо потока stderror получить stdoutComment
-
Script с HttpRequest вместо http agent не прокатит? К сожалению, не на чем проверить, поэтому в качестве идеи
Comment
-
Да конечно прокатит. Можно и не писать никаких скриптов: wget --no-proxy --no-check-certificate --auth-no-callenge --http-user=USER --http-password=PASSWORD -T20 https://URL/redfish/v1/Systems/1/ --header="Content-Type: application/json" --header="OData-Version: 4.0" -O
Что-то подобное можно и на curl написать. Можно и скрипт на JS с HttpRequest. Вся кривость этого решения в порождении новых процессов в OS вместо использования уже созданных пулеров. При этом нужность этого обходного пути в 2% случаев, в остальных запросах таких проблем нет. К сожалению, обработка ошибок в препроцессинге тоже не предполагает вызова какого-то скрипта.Comment
-
Ну я не вижу никакой кривизны в замене http agent на JS там, где http agent не справляется с задачей. При этом ведь не создается никаких внешних скриптов или юзерпараметров. Более того, почти всегда использую такое, т.к. http agent никак не позволяет получить время выполнения запроса.Comment
-
Спасибо за совет, зациклился на HTTP и совсем забыл про элемент скрипт. В сухом остатке после получения данных через HttpRequest() пропустил текст (до применения JSON.parse(res) через фильтр, отбрасывающий все символы с кодом больше 255. Выяснилось, что виноваты умельцы из HP Вот как они закодировали слово "Майкрософт" - 800 2666 39600 44078 191598 60526 453938 60722 1255447 656873 Какая-то чепуха. Даже символ О встречающийся 2 раза имеет разные представления. На серверах других вендоров (Lenovo, DELL, Huawei) таких проблем нет. Там нормально приходит двухбайтный юникод кириллических символов.Comment
Comment