LINUX.ORG.RU

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

 


0

1

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

Сабж

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

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

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

★★★★★

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

Смотря что надо хранить - последнее значение (состояние) или историю за период.

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

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

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

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

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

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

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

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

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

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

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

У uwsgi есть встроенный крон который эмитит сигналы, uwsgi есть глобальные переменные.

Deleted
()

А что надо сделать то. Почему не использовать кеширование из nginx просто

pawnhearts ★★★★★
()

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

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

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

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

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

Можно. Мы так с бирж собираем данные, а потом из кэша отдаем.

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

Так сделай на фласке ручку... Пусть сервер опрашивает и шлет фласку значение. А фласк кидает в кэш. Ну и фласк отдает клиентам из кэши

dem ★★
()

Если я правильно понял, то тебе нужна очередь в Redis.

WitcherGeralt ★★
()

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

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

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

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

anonymous
()

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

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

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

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

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

router ★★★★★
() автор топика

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

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

router ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.