Поддержу коллегу по п.3 — связка "*beat > logstash > elasticsearch" в 2022 свою актуальность совсем и полностью исчерпала. А именно Logstash — неудобный в эксплуатации, ресурсоемкий, ограниченный в отладке. Было бы круто и полезно новичкам, на кого очевидно и рассчитана статья, даже исходя из заголовка, увидеть примеры про актуальный и практичный Ingest Pipelines на удобной связке "*beat > elasticsearch" или перспективные Data Streams.
Ну и оставлю это тут как идею для дальнейшего углубления в изучение централизованной работы с лога и на базе продуктов Elastic Stack.
ИМХО…
Flannel в режиме host-gw однозначный победитель в организации оверлейной сети — просто, быстро, понятно. А функции Network Policy и шифрование это вообще не про CNI, Service Mesh с этим справляется намного функциональней.
И дополню что исходный CoreOS тоже жив, только название в Kinvolk дали ему новое — Flatcar Linux.
И если жизнь в CoreOS уже налажена, то перейти на Flatcar можно плановым апдейтом ОС.
Автору спасибо за новость об ещё одном легковесном дистрибутиве. Идея ОС для контейнеров явно набирает обороты.
Приветствую!
Не рассматривали вариантов добавить в свою реализацию Immutable Infrastructure еще и Immutable OS: Flatcar Linux или Fedore CoreOS?
Можно избавиться от слоя готовки образов, а этап provision описать как конфиг для ОС(ignition) с изолированным запуском любого софта в виде контейнера. Процесс обновления в этих ОС так же реализован путем «перезагрузил и получил новый релиз». Если что-то пошло не так, 1-ой командой и перезагрузкой можно откатиться.
Благодарю за краткое содержание VictoriaMetrics Wiki, уже знаком на практике, но наверняка кому-то пригодиться для быстрого старта.
Продублирую ссылку на всю историю багов из прошлого комментария, так как она похоже осталась незамеченной.
Активная разработка VictoriaMetrics ведется около года, примерно с мая-июня 2019, а зарегистрированных issue с лейблом «bug» больше 100. При этом продукт ничего нового не реализует, просто копирует и пересматривается подход в уже существующем Prometheus, а так же некие слои интеграции с другими TSDB.
Вот именно эта статистика пока и не очень двигает на уверенность что продукт «готов».
И да, согласен major-релиз в правилах SemVer 2.0 именно про новый функционал. Но акценты как раз был указан в «дождись SP1».
У VictoriaMetrics «некий SP1» я пока не наблюдаю. А вот как раз минорные релизы от версии к версии лишь добавляют все новый и новый функционал и потому надеюсь что они как-то зафиксируют фичи достигнув major-релиза и сосредоточатся на стабильности продукта.
В любом случае к людям, которые пишут Open Source, расходуя на это личное время, огромнейший респект всегда.
Первое что смущает именно архитектурно — это размазывание мониторинга по множеству сервисов. По мне, так мониторинг должен быть максимально надежным. А проще всего обеспечивать надежную работу сервиса(Prometheus) когда минимум компонентов.
Если пройтись именно по issue, то особенно печалят:
И подобных багов достаточно много. Те что я привел свежие, а если смотреть всю историю багов, то появляются мысли о «сырости» продукта.
Анализируя все что описал, желание использовать VictoriaMetrics не пропадает, но как и с MS продуктами, вышел релиз, дождись SP1 и можно использовать, я бы подождал следующего major-релиза.
Централизованное решение:
метрики все равно выпуливает прометей, так что отправная точка где то рядом с ним. У нас это кластер кубернетес, рядом в том же неймспейсе и этот сервис.
Вынесение функционала в 3 место:
А где должна быть логика? Статик конфиг в Прометее? Автодисковери для обычных вм у него нет.
Централизованное оно, потому что вся основная логика поиска и регистрации сервиса сконцентрирована в одном месте — в дополнительном сервисе. Без него или в случае ошибки, он встанет, что есть дополнительная точка отказа.
consul-service — это распределенная регистрация сервисов в Consul. Там где описан запуск сервиса, там же описана и его регистрация в Consul, без разнесения по нескольким сервисов.
p.s. Не ради рекламы, а ради сравнение подходов.
Предварительное добавление сервиса для сканирования сети вручную:
Не совсем так. Я добавляю подсеть. Дальше он сам ищет экспортеры в подсети и сам добавляет их в kv консула.
Подсети заводятся руками и каждый новый сервис(автор все считает их все exporters, но не все сервисы отдают метрики в prometheus через exporter, многие сами умеют это), заводятся отдельно и руками. Потом руками нужно их скрестить.
Приостановка и удаление вручную:
Останавливать ничего не требуется. Удаляешь сервис из консула — удаляется ендпоинт в Прометее.
Вручную, в виде дополнительного действия.
А еще:
— `LDAP_HOST` и `LDAP_BASE_DN` обязательные и без них не запуститься или не пустить в сервис. А как же админская учётка для гарантированного доступа.
— Смутил пример на скринах. Объявляется поиск node_exporter в подсети что именована как openshift. OpenShift — это K8S. В K8S node_exporter — это DaemonSetи и ни что иное. Про DaemonSet, а точнее дочерний pod, Prometheus узнает от kube-apiserver.
Либо я не до конца понимаю этот пример.
Федерация — не самый оптимальный механизм агрегирования метрик.
Federation очень удобное и нативное решение, позволяющее горизонтально размазывать нагрузку на Prometheus, и в хранении и в выполнении запросов. Это же и можно считать базовым решением горизонтального масштабирования.
А вот насчёт внешних хранилищ, по имеющимся issue они сырые и есть ещё "детские болячки".
Присматриваемся к VictoriaMetrics, развивается отлично, но в архитектуре есть вещи которые смущают.
Есть ли у кросс-мониторинга какие-то скрытые плюсы?
Так как это Prometheus, то это не просто мониторинг, это сбор метрик. Инстансы перекрёстно собирают друг с друга метрики и анализ этих метрик превентивный. Prometheus и сам с себя может метрики собирать, но это как минимум странно и точно не надежно, в случае "ресурсного шторма".
В Prometheus вариант масштабирования только 1 — вертикальный. Пока ему хватает RAM и CPU всё OK. За резервирование отвечает сброс данных в write-ahead-log (WAL). Поэтому если инстанс упадет, то на старте перечитает все с HDD.
А вот дальше самое инстересное – Prometheus очень любит RAM и CPU, так устроена его TSDB. Про это много в интернете написано.
Вопрос насчет того сколько он мониторит нод ставится неправильно. Prometheus собирается метрики с сервисов и так как делает это pull-моделью получается заодно мониторинг. Именно от количества метрик зависит насколько Prometheus будет загружен. Сервис может аккуратно отдавать 20-30 полезных и нужных метрик, а может 100-500 (Spring Boot Actuator) строк среди которых нужные только 20-30, но заберет по-умолчанию Prometheus все что есть в `/metrics`. Так что нагрузка на Prometheus зависит от большого количества факторов.
Теперь как сделал я – размазал нагрузку по нескольким Prometheus, а если точно по 2 в каждом окружении dev, test, prod. По 1-му в каждом Kubernetes кластере, который собирает метрики только того что живет в K8S(на CephFS) и еще по одному «инфраструктурному» Prometheus, который через Federation смотрит на Prometheus в K8S. Дополнительно все «инфраструктурные» Prometheus смотрят на `/metrics` друг на друга и обеспечивают кросс-мониторинг.
Grafana работает только с «инфраструктурными» Prometheus, а Federation позволяет при этом видеть и то что в K8S. А так же в Grafana заведены панели отвечающие за кросс-мониторинг всех инстансов Prometheus и если что то упадет, о проблеме становится известно.
Спасибо за изъявление своей мысли.
Такого рода комментарий был самым ожидаемым при написании статьи. Я описал именно опытное решение, которое позволило в минимум телодвижений организовать удобный service discovery в Prometheus — «20% усилий дают 80% результата».
У меня сохраняется уверенность что такое же «местечковое» применение Consul было и есть не только у меня в инфраструктуре — когда Consul запускается чтобы решить конкретную задачу, типо кластеризации Traefik. В итоге этот же инстанс легко обрел дополнительный функционал в роли service discovery для Prometheus.
Пока статью писал задумался — почему бы и в правду не попробовать Consul на всю катушку. И сейчас анализирую рентабельность его применения.
Поддержу коллегу по п.3 — связка "*beat > logstash > elasticsearch" в 2022 свою актуальность совсем и полностью исчерпала. А именно Logstash — неудобный в эксплуатации, ресурсоемкий, ограниченный в отладке. Было бы круто и полезно новичкам, на кого очевидно и рассчитана статья, даже исходя из заголовка, увидеть примеры про актуальный и практичный Ingest Pipelines на удобной связке "*beat > elasticsearch" или перспективные Data Streams.
Ну и оставлю это тут как идею для дальнейшего углубления в изучение централизованной работы с лога и на базе продуктов Elastic Stack.
ИМХО…
Flannel в режиме host-gw однозначный победитель в организации оверлейной сети — просто, быстро, понятно. А функции Network Policy и шифрование это вообще не про CNI, Service Mesh с этим справляется намного функциональней.
И дополню что исходный CoreOS тоже жив, только название в Kinvolk дали ему новое — Flatcar Linux.
И если жизнь в CoreOS уже налажена, то перейти на Flatcar можно плановым апдейтом ОС.
Автору спасибо за новость об ещё одном легковесном дистрибутиве. Идея ОС для контейнеров явно набирает обороты.
Не рассматривали вариантов добавить в свою реализацию Immutable Infrastructure еще и Immutable OS: Flatcar Linux или Fedore CoreOS?
Можно избавиться от слоя готовки образов, а этап provision описать как конфиг для ОС(ignition) с изолированным запуском любого софта в виде контейнера. Процесс обновления в этих ОС так же реализован путем «перезагрузил и получил новый релиз». Если что-то пошло не так, 1-ой командой и перезагрузкой можно откатиться.
Продублирую ссылку на всю историю багов из прошлого комментария, так как она похоже осталась незамеченной.
Активная разработка VictoriaMetrics ведется около года, примерно с мая-июня 2019, а зарегистрированных issue с лейблом «bug» больше 100. При этом продукт ничего нового не реализует, просто копирует и пересматривается подход в уже существующем Prometheus, а так же некие слои интеграции с другими TSDB.
Вот именно эта статистика пока и не очень двигает на уверенность что продукт «готов».
И да, согласен major-релиз в правилах SemVer 2.0 именно про новый функционал. Но акценты как раз был указан в «дождись SP1».
У VictoriaMetrics «некий SP1» я пока не наблюдаю. А вот как раз минорные релизы от версии к версии лишь добавляют все новый и новый функционал и потому надеюсь что они как-то зафиксируют фичи достигнув major-релиза и сосредоточатся на стабильности продукта.
В любом случае к людям, которые пишут Open Source, расходуя на это личное время, огромнейший респект всегда.
Если пройтись именно по issue, то особенно печалят:
И подобных багов достаточно много. Те что я привел свежие, а если смотреть всю историю багов, то появляются мысли о «сырости» продукта.
Анализируя все что описал, желание использовать VictoriaMetrics не пропадает, но как и с MS продуктами, вышел релиз, дождись SP1 и можно использовать, я бы подождал следующего major-релиза.
Централизованное оно, потому что вся основная логика поиска и регистрации сервиса сконцентрирована в одном месте — в дополнительном сервисе. Без него или в случае ошибки, он встанет, что есть дополнительная точка отказа.
consul-service — это распределенная регистрация сервисов в Consul. Там где описан запуск сервиса, там же описана и его регистрация в Consul, без разнесения по нескольким сервисов.
p.s. Не ради рекламы, а ради сравнение подходов.
Подсети заводятся руками и каждый новый сервис(автор все считает их все exporters, но не все сервисы отдают метрики в prometheus через exporter, многие сами умеют это), заводятся отдельно и руками. Потом руками нужно их скрестить.
Вручную, в виде дополнительного действия.
А еще:
— `LDAP_HOST` и `LDAP_BASE_DN` обязательные и без них не запуститься или не пустить в сервис. А как же админская учётка для гарантированного доступа.
— Смутил пример на скринах. Объявляется поиск node_exporter в подсети что именована как openshift. OpenShift — это K8S. В K8S node_exporter — это DaemonSetи и ни что иное. Про DaemonSet, а точнее дочерний pod, Prometheus узнает от kube-apiserver.
Либо я не до конца понимаю этот пример.
Уверен что со своей nevidanniu/promenad задачей справляется, но…
Посмотрел. Интересное решение, но моим требованиям автоматизации совсем не отвечает и скорее даже противоречит:
Очень напомнило решения из начала 2000. Тогда очень любили сканировать сеть считая это автоматизацией.
Federation очень удобное и нативное решение, позволяющее горизонтально размазывать нагрузку на Prometheus, и в хранении и в выполнении запросов. Это же и можно считать базовым решением горизонтального масштабирования.
А вот насчёт внешних хранилищ, по имеющимся issue они сырые и есть ещё "детские болячки".
Присматриваемся к VictoriaMetrics, развивается отлично, но в архитектуре есть вещи которые смущают.
Так как это Prometheus, то это не просто мониторинг, это сбор метрик. Инстансы перекрёстно собирают друг с друга метрики и анализ этих метрик превентивный. Prometheus и сам с себя может метрики собирать, но это как минимум странно и точно не надежно, в случае "ресурсного шторма".
А вот дальше самое инстересное – Prometheus очень любит RAM и CPU, так устроена его TSDB. Про это много в интернете написано.
Вопрос насчет того сколько он мониторит нод ставится неправильно. Prometheus собирается метрики с сервисов и так как делает это pull-моделью получается заодно мониторинг. Именно от количества метрик зависит насколько Prometheus будет загружен. Сервис может аккуратно отдавать 20-30 полезных и нужных метрик, а может 100-500 (Spring Boot Actuator) строк среди которых нужные только 20-30, но заберет по-умолчанию Prometheus все что есть в `/metrics`. Так что нагрузка на Prometheus зависит от большого количества факторов.
Теперь как сделал я – размазал нагрузку по нескольким Prometheus, а если точно по 2 в каждом окружении dev, test, prod. По 1-му в каждом Kubernetes кластере, который собирает метрики только того что живет в K8S(на CephFS) и еще по одному «инфраструктурному» Prometheus, который через Federation смотрит на Prometheus в K8S. Дополнительно все «инфраструктурные» Prometheus смотрят на `/metrics` друг на друга и обеспечивают кросс-мониторинг.
Grafana работает только с «инфраструктурными» Prometheus, а Federation позволяет при этом видеть и то что в K8S. А так же в Grafana заведены панели отвечающие за кросс-мониторинг всех инстансов Prometheus и если что то упадет, о проблеме становится известно.
Такого рода комментарий был самым ожидаемым при написании статьи. Я описал именно опытное решение, которое позволило в минимум телодвижений организовать удобный service discovery в Prometheus — «20% усилий дают 80% результата».
У меня сохраняется уверенность что такое же «местечковое» применение Consul было и есть не только у меня в инфраструктуре — когда Consul запускается чтобы решить конкретную задачу, типо кластеризации Traefik. В итоге этот же инстанс легко обрел дополнительный функционал в роли service discovery для Prometheus.
Пока статью писал задумался — почему бы и в правду не попробовать Consul на всю катушку. И сейчас анализирую рентабельность его применения.