LINUX.ORG.RU

python: как организовать взаимодействие сервера и его rest api?

 


0

1

Доброго времени суток

Сабж

Сейчас у меня написан модуль для работы с удалённым железом по SNMP и к нему интерфейсы rest api ( на flask_restful ) и cli

Возникла задача автоматически ( без запросов через api или cli ) собирать данные в цикле. И клиентам по возможности отдавать из кэша, без опроса железа

Правильно ли я понимаю, что для взаимодействия сервера и его rest api мне нужно использовать внешнюю БД ? Можно ли обойтись sqlite ?

★★★★★

Ответ на: комментарий от Deleted

Тут главная подстава :) Когда я на это подписался, речь шла о консольной утилите. Потом захотели rest api, а теперь уже нужен сервер

Но допустим только последнее состояние

router ★★★★★ ()
Ответ на: комментарий от router

Возьми какой-нибудь питонячий планировщик задач и опрашивай железо с определенным интервалом, результат складывай в какой-нибудь глобальный объект. Не забудь добавить лок на него. Ну или просто создай отдельный поток и в нем опрашивай железо с определенным интервалом. В общем виде БД не нужна.

michey ★★★ ()
Ответ на: комментарий от router

Я подобное, с кешированием состояния, решал через json-файл. Кода выходит на 10-15 строчек и никаких дополнительных внешних зависимостей. Расписание обновления кеша - тут надо смотреть из задачи, или ос-планировщик, или же как-то завязываться на время последнего запроса к кешу.

Историю логично грузить во что-то уровня заббикс, если такое уже есть, конечно.

Deleted ()

Просто для кругозора: в чем прикол кроить на snmp запросах? Почему не использовать трапы?

*на правах наркомании - питонячий шедуллер складывающий все в dataframe с эпизодическим экспортом в csv, соотв-но при ребуте кэш либо чистится, либо подгружаются последние данные из файлика :)

Пока я не понимаю, как процесс сервера будет работать параллельно с flask'ом, даже если запускать без uwsgi

Из задачи не совсем очевидно чего ты хочешь на выходе. Опрашивать, складывать и отдавать через api? Ну тогда кажется что прямое взаимодействие им не нужно, достаточно БД. Если хочется напилить ещё ролевых моделей и прочих фишек, то все вроде бы укладывается в классическую фронтенд (flask) - backend (snmp траппер/опрашивалка) модель.

phoen ()
Последнее исправление: phoen (всего исправлений: 3)

Звучит как дикий велосипед. Почему не взять любой существующий коллектор graphite умеющий собирать snmp, и собственно graphite как REST API? Или prometheus и snmp exporter под него?

ei-grad ★★★★★ ()
Последнее исправление: ei-grad (всего исправлений: 1)

И клиентам по возможности отдавать из кэша, без опроса железа

Как ты описал тебе просто кеш нужен, можно просто в памяти хранить. Ну или там MemCached если хайлоад.

anonymous ()
Ответ на: комментарий от ei-grad

Звучит как дикий велосипед. Почему не взять любой существующий коллектор graphite умеющий собирать snmp, и собственно graphite как REST API?

А это не мониторинг - управление и визуализация.

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

router ★★★★★ ()

Всем спасибо, остановился на redis

подходит как для кэширования данных ( для передачи от сервера к rest api ), так и для организации очередей ( для работы нескольких потоков сервера над одним пулом задач )

router ★★★★★ ()