если оно у тебя в одном датафрейме то будет работать норм и будет брать действтиельно первые по времени (должно) если в разных рет. полиси или в разных шардах - надо сначала сортировать всю пачку а потом из нее делать выборку
только на этом графике обрывы? на генетароре трафик мониторишь?
Нагрузка постоянна и без passing или каких-либо timeout. Это поведение системы. Ответы приходят с задержкой. Нет границы, где ответы приходят непрерывным потоком. Операция в этом случае одна и это вызов к API. По сложности она похожа на ping или приветствие. Эффект возникает при использовании некой шины, о которой никто ничего сказать не может, но она нужна. Без шины график непрерывен и выглядит нормально.
Мне вот характер графика говорит о том, что использование шины приводит к задержкам в ответах. Создаётся ощущение, что шина отправляет порциями, а не при получении. При этом пропускная способность шины низкая. И при увеличении интенсивности шина не справляется. Таким образом требуется отдельное исследование самой шины с целью выявления её характеристик и оптимальной конфигурации.
> SELECT "water_level","location" FROM "h2o_feet" LIMIT 3
а мне надо из строчки, содержащей 100 символов взять только первые 20 символов, что бы подсчитать количество строк, начинающихся с таких же 20 символов
а мне надо из строчки, содержащей 100 символов взять только первые 20 символов, что бы подсчитать количество строк, начинающихся с таких же 20 символов
а мне надо из строчки, содержащей 100 символов взять только первые 20 символов, что бы подсчитать количество строк, начинающихся с таких же 20 символов
Если использовать telegraf в качестве influxdb proxy, то он может на лету добавлять новые теги на основе имеющихся. И там можно использовать регулярные выражения как выше для Prometeus. И получится, что в БД будет нужный тег длиной 20 символов
а мне надо из строчки, содержащей 100 символов взять только первые 20 символов, что бы подсчитать количество строк, начинающихся с таких же 20 символов