Из вашего списка задач MCS решает только две:
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Остальное это каждодневная рутинная работа команды разработки.
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
В MCS файлы наши уже теряли…
Ещё в статье написано, что вы данные храните в Kubernetes, можно поконкретнее, где именно? Как вы решили задачу с контролем физического местонахождения данных?
Не, не понимаю.
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Не понимаю чем два человека на Full-time занимались.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Читаю и у меня, что-то не сходится, вопросы возникают.
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Плюс нам не нравилось то, во сколько нам обходится его содержание на bare metal
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
Например, одной из первых задач стало вписать Ingress-контроллеры Kubernetes в сетевую инфраструктуру нашей организации
А и такая есть? :)
Не знал… десктоп клиент просто работает без нареканий пока
Видел только потуги сделать web-интерфейс к скайпу на outlook.com, но он не работал.
Skype версии 8 сделан на Electron?!
Аплодисменты!
Это их лучшая версия за 10 лет! Без шуток, я не любил скайп до этой версии.
На стареньком Core 2 Duo работает без лагов, хотя старые версии постоянно зависали и делали что-то непонятное.
С аудио оборудованием работает прекрасно! Раньше каждый запуск был мукой с выбором и проверкой гарнитуры :)
Судя по статье (оригинал предлагаемых изменений не смотрел), это уже не VUE, а что-то другое просто :)
Vue.js действительно прекрасен простотой вхождения, однозначностью и стабильной работой.
Странный перечень вопросов для выбора технических решений на стадии MVP. Да и далее вы кажется просто взяли то, что знали сами :)
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
Или вам надо сделать Веб-сервер, в котором каждому вашему скрипту будет соответствовать URL и отдавать в формате prometheus метрики.
Или объединить запуск всех скриптов и отдавать один большой список метрик.
The metrics pushed are exactly the same as you would present for scraping in a permanently running program. If you need distributed counting, you could either use the actual statsd in combination with the Prometheus statsd exporter, or have a look at Weavework's aggregation gateway.
Это я и в json файл могу складывать всё, а потом в prometheus отдавать :)
Наворачивать statsd и писать клиента python и тестировать как себя ведёт Weavework's gateway даже не стал :) У них клиент JS только.
Для python вроде как решили эту проблему со сбором и агрегацией и передачей в prometheus метрик github.com/prometheus/client_python… но там решение на уровне одного сервера, метрики каждого процесса кладутся в отдельный файл, потом при pull они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
Про минусы жалко как обычно не пишут, с минусами все сталкиваются когда уже втянулись :)
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
Хорошо это всё, но косметикой отдаёт.
Но самое главное чего нехватает сейчас, так это ручного задания платформы. Надо нам win-сервером управлять с linux-сервера…
Path это умеет? :)
— апгрейдов kubernetes (MCS это сами делают)
— интеграции kubernetes с корпоративными сервисами (это просто отпадает по сути)
Остальное это каждодневная рутинная работа команды разработки.
А SLA MCS будет соблюдать до тех пор, пока у них не случится авария, как и все остальные хостинги :)
В MCS файлы наши уже теряли…
Костыли чем заменить?
Neo4j вы как предлагаете воткнуть?
Всего 10 серверов, не так много, программисты штатные вполне с ними могут совладать :)
Вы всё о трудоемких интеграциях в вашу сеть пишете, а задачи решаемые вроде как вокруг обсчёта данных крутятся.
Не понимаю чем два человека на Full-time занимались.
В MCS вам сделали возможность использования IP-адресов из корпоративной сети?
И MCS сделали вам интеграцию в вашу копоративную сеть?
Компания молодая, хотим Kubernetes, но на «своём» сервере его поддерживать дорого, а в облаке получилось дешевле.
Это сколько?
Не понимаю с какими сложностями в поддержке вы столкнулись «на своём» железе, чуть подробнее? Что вы разрабатывали?
Какой у вас объём данных? Пол часа на копирование всех данных между датацентрами, это достаточно быстро.
Какие у вас потребности в RAM и CPU?
А с переездом в облако задача просто отпала?
Обычная CMS, коих много на разных стеках.
А ORM от Telerik мозг не выносит?
Не знал… десктоп клиент просто работает без нареканий пока
Видел только потуги сделать web-интерфейс к скайпу на outlook.com, но он не работал.
www.codepicky.com/hacking-electron-restyle-skype
Аплодисменты!
Это их лучшая версия за 10 лет! Без шуток, я не любил скайп до этой версии.
На стареньком Core 2 Duo работает без лагов, хотя старые версии постоянно зависали и делали что-то непонятное.
С аудио оборудованием работает прекрасно! Раньше каждый запуск был мукой с выбором и проверкой гарнитуры :)
Vue.js действительно прекрасен простотой вхождения, однозначностью и стабильной работой.
И я так понимаю эти вопросы с обратным приоритетом? Выбор ОС кажется менее приоритетное, чем выбор стека технологий по наличию достаточного количества специалистов?
И сразу хочется узнать, какие из критериев оказались полезные, а какие нет?
Вот выбор бинарного протокола на MVP вам помог?
Авральная работа запоем, поддержка директоров и пользователей это прекрасно, но напишите сразу как этого стоило избежать :)
Или объединить запуск всех скриптов и отдавать один большой список метрик.
Это я и в json файл могу складывать всё, а потом в prometheus отдавать :)
Наворачивать statsd и писать клиента python и тестировать как себя ведёт Weavework's gateway даже не стал :) У них клиент JS только.
Для python вроде как решили эту проблему со сбором и агрегацией и передачей в prometheus метрик github.com/prometheus/client_python… но там решение на уровне одного сервера, метрики каждого процесса кладутся в отдельный файл, потом при pull они агрегируются. Но там потом заморочки с очисткой этой директории в «нужные моменты», отслеживание какой процесс умер и его метрики уже можно удалить…
И потом всёравно на двух серверах уже это не будет работать, а потребность такая есть.
Из-за pull модели опроса, prometheus не очень подходит для отслеживания метрик «быстрых» процессов, которые успевают начаться и звершиться между опросами метрик, а это почти все задачи обработки HTTP запросов.
Тут начинаются пляски с промежуточными агрегаторами метрик, которые принимают push, а потом отдают их через pull в prometheus… только полноценных нету, и ещё они должны уметь метрики «складывать» если это гистограммы, gauge и т.д.
За серверами следить с помощью prometheus однозначно «ДА», свободное дисковое пространство, свободная память и другие подобные метрики всегда можно получить прямо тут, но если ваши метрики нельзя посчитать в любую произвольную секунду, то тут уже надо думать :)
Тут тонкий момент, «сервис» получивший 404 это сборщик prometheus, но сколько 404 он пропустит прежде чем он всё же встретит плавающий 404?
Неоднозначна штука.
Круто! Но зачем они это сделали!? :)
Кстати жалею, что я узнал когда-то о for… else ..., конструкция оказалась удобной на практике и я начал её применять! Но читать потом этот код…
Пойду начну список того «что нельзя делать» у нас на проектах :)
Но самое главное чего нехватает сейчас, так это ручного задания платформы. Надо нам win-сервером управлять с linux-сервера…
Path это умеет? :)