"В 3.10 от рхел есть все что нужно" и так далее

4.17.0-1.el6.elrepo.x86_64

"В 3.10 от рхел есть все что нужно" и так далее

ну чо чо. всё что им нужно есть да

темболее что рхел 8 непонятно где

темболее что рхел 8 непонятно где

скорее всего в октябре ноябре

не раньше

пофиг когда 8.0 надо ждать 8.1

А есть те, кто Amazon Linux юзают?

Так и думал)

и вообще https://www.slideshare.net/ThomasGraf5/accelerating-envoy-and-istio-with-cilium-and-the-linux-kernel

Many Linux distributions including CoreOS, Debian, Docker's LinuxKit, Fedora, and Ubuntu already ship kernel versions >= 4.8.x. You can check your Linux kernel version by running uname -a. If you are not yet running a recent enough kernel, check the Documentation of your Linux distribution on how to run Linux kernel 4.9.x or later.

А есть те, кто Amazon Linux юзают?

@aws_ru

Мне просто интересно было) Я его поставил и снес

на ЕС

А openstack на "пощупать" можно на одном серваке развернуть?

Many Linux distributions including CoreOS, Debian, Docker's LinuxKit, Fedora, and Ubuntu already ship kernel versions >= 4.8.x. You can check your Linux kernel version by running uname -a. If you are not yet running a recent enough kernel, check the Documentation of your Linux distribution on how to run Linux kernel 4.9.x or later.

и? )

К тому что ML kernel хватит...

и вообще https://www.slideshare.net/ThomasGraf5/accelerating-envoy-and-istio-with-cilium-and-the-linux-kernel

вообще глядя на это кажется будто бы смысл в том что бы избвится от инкапсуляций и срезать углы.

и весь смысл движняка тупо убрать заложенную в протокол гибкость. в стиле "а давайте тут добавим if-ик"

может это конечно и не плохо. но чот не инновационно :)

вообще глядя на это кажется будто бы смысл в том что бы избвится от инкапсуляций и срезать углы.

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

мне это чем-то напоминает mpls p

да есть такие ассоциации

выглядит будето признание что ip оверинженернут

а разве нет?

господа, хочу странного. какую нить учитывалку хостов с учетом того что они мало связанны друг с другом

https://github.com/digitalocean/netbox

https://github.com/digitalocean/netbox

Да я тоже к нему пришёл

Да я тоже к нему пришёл

Ещё бы к нему пуш бейсед управление какой нить

Список пакетов там пнуть

выглядит будето признание что ip оверинженернут

В первую очередь фаерволы и прочее подобное очень уж общее и поэтому медленное

Чем дальше в лес, тем ближе вот то что в докладе к мейнстриму

Ещё бы к нему пуш бейсед управление какой нить

Солт?

Не. Зо разные.

Пацаны, два вопроса: 1. Кто-то юзал columnstore от мариидб под time series? Настолько эта хуйня вообще рабочая? 2. Redis+rejson модуль насколько хорош для быстрой работы с ним?

The average salary of a DevOps engineer is about $140,000 per year in Silicon Valley area which is 20% higher than the salary of a software engineer.

https://www.udemy.com/kubernetes-from-a-devops-kubernetes-guru/

шикарный наброс.

А openstack на "пощупать" можно на одном серваке развернуть?

можно

чего бы и нет?

может это конечно и не плохо. но чот не инновационно :)

зато обёртка красивая

Пацаны, два вопроса: 1. Кто-то юзал columnstore от мариидб под time series? Настолько эта хуйня вообще рабочая? 2. Redis+rejson модуль насколько хорош для быстрой работы с ним?

1 - не очень понятно зачем вообще

сейчас довольно много TSDB на любой вкус

чего бы и нет?

Есть роль энсибла?)

список докладов не внушает оптимизм

клевые доклады. говорю как член программного комитета )

клевые доклады. говорю как член программного комитета )

Клевость - понятие относительное же

клевые с точки зрения программного комитета ) что логично

клевые с точки зрения программного комитета ) что логично

Ну вот не факт что вам клево будет клево людям :)

Тут вопрос репутации комитета и его составляющих

кому и кобыла невеста, короче говоря

https://www.udemy.com/kubernetes-from-a-devops-kubernetes-guru/

эх, очередно пересказ доки

Сорри за оффтоп, но в чатах по питон молчат. Вопрос про peewee и join. А именно какого хера, он засовывает данные join в глубину. Типа post.posttext.posttitle.title. Могу скинуть доп инфу, если есть смысл

Model.Model.Model.field

Есть роль энсибла?)

Если ты внимательный, то опенстек ставиться за рабочий день спокойно)

Если ты внимательный, то опенстек ставиться за рабочий день спокойно)

Не хочу рабочий день тратить же

Не хочу рабочий день тратить же

А что хочешь? Потыкать веб морду? Ну тогда проще купить виртуалку

Потыкать стек и терраформом подергать

А prometheus + pushgateway ничего так выглядят для метрик. Сижу тыкаю.

Мне даже больше Datadog понравилось. Потому что можно self hosted сделать.

Спасибо тому, кто посоветовал.

а кто вам посоветовал pushgateway ?

а кто вам посоветовал pushgateway ?

Так. Советовали конечно только prometheus. Pushgateway я уже сам догуглил. Нормальная в целом штука? Production ready?

с пушгейтвеем нет

они сами считают ее костылем и не рекомендуют

они сами считают ее костылем и не рекомендуют

А какой тогда некостыльный способ трекать метрики из приложения?

пром должен сам ходить в приложение и забирать оные

ERROR: S client not available

у него нативная пул модель. не пуш.

у него нативная пул модель. не пуш.

а разве не лучше из приложение по юникс сокету метрики передавать в экспортёр, а тот чтобы уже в пром?

у меня на wmi экспортёре вроде нормально метрики отодражались таким образом, правда там не через юникс сокеты, а через винсокеты

а разве не лучше из приложение по юникс сокету метрики передавать в экспортёр, а тот чтобы уже в пром?

нет не лучше.

с пуш моделью у мониторинга много вопросов. самый не простой это как понять что новых метрик нету это значит всё плохо или тот хост который отсылает не может достучаться до прома

с пуш моделью у мониторинга много вопросов. самый не простой это как понять что новых метрик нету это значит всё плохо или тот хост который отсылает не может достучаться до прома

Как минимум)

Пуш модель нормально подходит для метрик бизнес логики приложения. Нет?

да я просто очевидный пример привёл

Пуш модель нормально подходит для метрик бизнес логики приложения. Нет?

нет

короче тут спора на неделю

в вашем случае подходит - юзайте.

с пуш моделью у мониторинга много вопросов. самый не простой это как понять что новых метрик нету это значит всё плохо или тот хост который отсылает не может достучаться до прома

?тогда не оч понимаю, ну вот у меня приложение микросервисное, я смог добиться своего, и на каждое действие на каждую фунецию я имею метрику, с временем удачно неудачно и тп, у меня есть wmi экспортёр, на ноде, это получается надо будет переписывать экспортёр фулл?

?тогда не оч понимаю, ну вот у меня приложение микросервисное, я смог добиться своего, и на каждое действие на каждую фунецию я имею метрику, с временем удачно неудачно и тп, у меня есть wmi экспортёр, на ноде, это получается надо будет переписывать экспортёр фулл?

буквы есть. смысла за буквами не вижу

короче тут спора на неделю

Ладно, я лично спорить не буду. Мне интересен нормальный метод трекинга метрик бизнес логики, а не pushgateway, который как оказалось костылен.

нормальный метод это добавление каждого инстанса приложения в пром для мониторинга

буквы есть. смысла за буквами не вижу

в код сделаны метрики, их либо забирать по http можно либо по винсокету передавать в экспортёр

в код приложения

и сбор метрик непосредственно с каждого инстанса

в код сделаны метрики, их либо забирать по http можно либо по винсокету передавать в экспортёр

забирать по http это вариант который предлагет пром

https://www.influxdata.com/blog/monitoring-with-push-vs-pull-influxdb-adds-pull-support-with-kapacitor/

парни которые топят за пуш

https://www.robustperception.io/its-easy-to-convert-pull-to-push/

вариант от прома

просто далеко не всегда есть возможность по http забирать

иногда клиент даёт 1 порт по tcp и всё

нормальный метод это добавление каждого инстанса приложения в пром для мониторинга

Ок. Тогда со стороны приложения я это вижу как-то так: 1. Хреначим метрики в Redis. Counter, gauge, и так далее. 2. Мутим endpoint, в который будет стучаться prometheus. 3. Смотрим dashboard prometheus'а со всеми этими метриками. Говно-идея?

Ну ставь внутри сети

просто далеко не всегда есть возможность по http забирать

поэтому вопрос мониторинга в кажом случае надо решать индивидуально

Ок. Тогда со стороны приложения я это вижу как-то так: 1. Хреначим метрики в Redis. Counter, gauge, и так далее. 2. Мутим endpoint, в который будет стучаться prometheus. 3. Смотрим dashboard prometheus'а со всеми этими метриками. Говно-идея?

идея как идея. не лучше не хуже остальных

ссылки выше для размышлений

идея как идея. не лучше не хуже остальных

Спасибо! Примерно теперь понял вектор работы.