Подскажите, как так получилось, что часть текста полностью соответствует части текста из статьи Управление памятью в Linux? Да, это перевод, но неужели Вы перевели точь-в-точь как я и даже допустили опечатку точь-в-точь, как у меня (см. «Система страница»)?
Звучит действительно странно. Именно поэтому pod (модуль) сознательно оставлен как под (устоявшийся эвфемизм), а Ingress и вовсе сохранен в оригинале. Однако во всем хороша мера. Если совсем не переводить термины, то получится просто статья на английском языке. Мне кажется, что выходом является компромисс – большинство терминов переведены, а оригинальный текст указан в скобках
В качестве конвейера для набора мидлов выглядит хорошо, для специалистов более высокого уровня не подойдет, там потребуется больше креатива и вообще желание кандидата подобное задание выполнять
Да, тут либо агрессивная стратегия с расчетом на то, что память всем процессам не понадобится разом, либо осторожная с полным обеспечением виртуальной памяти физической :)
Очень схематично для себя вижу картину следующим образом: виртуальная память является абстракцией для безопасности, упрощения и оптимизации работы с физической памятью. Пример оптимизации автор приводит в статье (переиспользование физической памяти несколькими процессами). Таким образом, приложения прекрасно работают с виртуальной памятью и в случае отключенного swap с той лишь разницей, что страницы никуда не будут выгружаться.
Все верно. VM в контексте вопроса как раз и есть аналог второго экземпляра Prometheus в вашем сценарии, который с точки зрения потребления ресурсов эффективнее
Основы мониторинга в понимании разных людей должны содержать разную информацию. Необходимость, понятие и краткий обзор существующих систем – вот что является основами по-моему субъективному мнению (которое не обязательно должно совпадать с Вашим)
Статья изначально не подавалась как сравнительная. Различные системы мониторинга перечислены для понимания общей картины. Нет и не может быть универсального обоснования в вакууме в пользу Prometheus (как и в пользу любой другой системы)
Это забавно, но в концепции Prometheus «замониторить какую-нибудь программу» действительно означает развернуть экспортер :) В статье есть упоминание, где подобный экспортер найти, дальше достаточно открыть ReadMe. Можно написать и свой экспортер, что совсем не сложно по официальной документации
Зачем делать репозиторий для каждого проекта, неужели нельзя сложить все в один? Иногда реализовать экспортер, который будет отдавать метрики по разным подсистемам, все же можно и даже разумно, но объединять метрики по хосту, контейнерам и проверке доступности точек входа по tcp/http – странное предложение. Возможно я не понял сарказм :(
Верно. Остается только дополнить, что статья останавливается на минимальном наборе сервисов, которые можно потрогать вживую, и понимании, как дальше разворачивать необходимые экспортеры и добавлять дашборды
Эмоции – двигатель прогресса
Мне больше импонирует термин monkeyops. И все же команды и файлы не понадерганы из Интернета, не стоит настолько упрощать. Крутым специалистом себя не считаю :)
Как минимум благодаря дедубликации данных можно хранить меньшее число точек во временных рядах. Например, Prometheus собирает значения от экспортера каждые 15 секунд и на отрезке последних нескольких недель это оправданно. Однако на глубине в год такая точность уже не требуется – и VictoriaMetrics позволяет хранить только значения за каждые 60 секунд с помощью опции -dedup.minScrapeInterval=60s. Тогда горячие данные можно смотреть от источника данных Prometheus, а холодные – от VM.
Спасибо за важное замечание! Мне остается только добавить, что разработчик действительно не рекомендует запускать node_exporter в контейнере:
The node_exporter is designed to monitor the host system. It's not recommended to deploy it as a Docker container because it requires access to the host system.
«Во Франции незаконно называть свинью Наполеоном, но меня не остановить» :)
Разумеется, запускать node-exporter (равно как и все остальные компоненты) в контейнере вовсе не обязательно. Это лишь пример, иллюстрация одного из вариантов :)
Изоляция процессов в контейнерах осуществляется благодаря двумя механизмами ядра Linux – пространствам имен (namespaces) и контрольным группам (cgroups). Мы частично нарушили изоляцию файловой системы, но остальные пространства все еще работают, как и контрольные группы.
Еще один плюс (возможно очень субъективный) – все программное обеспечение распространяется через образы. Это банально удобно
Запуск контейнеров под пользователями без прав root и управление контейнерами пользователями без прав root – существенно разные вещи
Docker требуется сервис, Podman работает без него (минус единая точка отказа)
Docker использует Container Runtime runc, Podman использует crun
Однако совершенно верно, что с точки зрения рядового пользователя разницы особой нет. Podman изначально разрабатывали так, чтобы внешне он ничем (практически) не отличался
P.S. Я не топлю за Podman, но вижу его применение оправданным в дистрибутивах с сильным влиянием RedHat :)
Спасибо за дополнение! Честно говоря не пользовался этим GUI на практике. Что-то похожее видел в Docker Desktop, когда устанавливал его при подготовке статьи. А так в основном только CLI под рукой
Как понимаю, речь идет о переходе с Linux Containers на Docker или Podman. По-моему это как раз тот случай, когда лучше изучить, чем не изучать – цинично, но в будущее технологий под эгидой OCI я верю больше :)
Для меня главное практическое преимущество – возможность не думать лишний раз. На каждом из десятков и сотен серверов есть удобный механизм – systemd юниты, который управляет зависимостями, заботится о восстановлении при сбоях, позволяет смотреть конфигурации и управлять всем необходимым ПО единообразно. В целом, думаю, можно обойтись и без systemd, особенно в небольших средах и проектах – дело вкуса
Любопытный специалист продолжит изучение технологии, посмотрит на другие решения и (очень надеюсь) углубится в практику. Выше же представлен всего лишь обзорный материал для понимания нескольких начальных тезисов :)
Из относительно свежих книг приходит на ум только «Linux: от новичка к профессионалу» Д. Колисниченко. Очень хорошие (пусть и немного устаревшие) на мой вкус курсы по LPIC есть у Кирилла Семаева (выложены на Youtube). А дальше уже погружаться только через обильную практику, чтение скучных мануалов и узконаправленных статей :)
Подскажите, как так получилось, что часть текста полностью соответствует части текста из статьи Управление памятью в Linux? Да, это перевод, но неужели Вы перевели точь-в-точь как я и даже допустили опечатку точь-в-точь, как у меня (см. «Система страница»)?
Звучит действительно странно. Именно поэтому pod (модуль) сознательно оставлен как под (устоявшийся эвфемизм), а Ingress и вовсе сохранен в оригинале. Однако во всем хороша мера. Если совсем не переводить термины, то получится просто статья на английском языке. Мне кажется, что выходом является компромисс – большинство терминов переведены, а оригинальный текст указан в скобках
В качестве конвейера для набора мидлов выглядит хорошо, для специалистов более высокого уровня не подойдет, там потребуется больше креатива и вообще желание кандидата подобное задание выполнять
Так точно!
Спасибо, интересное исследование
Да, тут либо агрессивная стратегия с расчетом на то, что память всем процессам не понадобится разом, либо осторожная с полным обеспечением виртуальной памяти физической :)
Корректное замечание, спасибо!
Очень схематично для себя вижу картину следующим образом: виртуальная память является абстракцией для безопасности, упрощения и оптимизации работы с физической памятью. Пример оптимизации автор приводит в статье (переиспользование физической памяти несколькими процессами). Таким образом, приложения прекрасно работают с виртуальной памятью и в случае отключенного swap с той лишь разницей, что страницы никуда не будут выгружаться.
Буду рад конструктивным уточнениям и дополнениям
Все верно. VM в контексте вопроса как раз и есть аналог второго экземпляра Prometheus в вашем сценарии, который с точки зрения потребления ресурсов эффективнее
MRTG в статье был изначально. По поводу Cacti были сомнения, добавил сейчас
Основы мониторинга в понимании разных людей должны содержать разную информацию. Необходимость, понятие и краткий обзор существующих систем – вот что является основами по-моему субъективному мнению (которое не обязательно должно совпадать с Вашим)
Статья изначально не подавалась как сравнительная. Различные системы мониторинга перечислены для понимания общей картины. Нет и не может быть универсального обоснования в вакууме в пользу Prometheus (как и в пользу любой другой системы)
Это забавно, но в концепции Prometheus «замониторить какую-нибудь программу» действительно означает развернуть экспортер :) В статье есть упоминание, где подобный экспортер найти, дальше достаточно открыть ReadMe. Можно написать и свой экспортер, что совсем не сложно по официальной документации
Зачем делать репозиторий для каждого проекта, неужели нельзя сложить все в один? Иногда реализовать экспортер, который будет отдавать метрики по разным подсистемам, все же можно и даже разумно, но объединять метрики по хосту, контейнерам и проверке доступности точек входа по tcp/http – странное предложение. Возможно я не понял сарказм :(
Верно. Остается только дополнить, что статья останавливается на минимальном наборе сервисов, которые можно потрогать вживую, и понимании, как дальше разворачивать необходимые экспортеры и добавлять дашборды
Эмоции – двигатель прогресса
Мне больше импонирует термин monkeyops. И все же команды и файлы не понадерганы из Интернета, не стоит настолько упрощать. Крутым специалистом себя не считаю :)
Как минимум благодаря дедубликации данных можно хранить меньшее число точек во временных рядах. Например, Prometheus собирает значения от экспортера каждые 15 секунд и на отрезке последних нескольких недель это оправданно. Однако на глубине в год такая точность уже не требуется – и VictoriaMetrics позволяет хранить только значения за каждые 60 секунд с помощью опции -dedup.minScrapeInterval=60s. Тогда горячие данные можно смотреть от источника данных Prometheus, а холодные – от VM.
Также есть интересная статья Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter, которая наглядно сравнивает потребление ресурсов
На практике это может это может выглядеть так (набор экспортеров очень пестрый, от того же node до mongodb и кастомных):
Prometheus – хранение данных 21 день, БД ~90 ГБ
VictoriaMetrics – хранение данных 365 дней, БД ~270 ГБ
Спасибо за важное замечание! Мне остается только добавить, что разработчик действительно не рекомендует запускать node_exporter в контейнере:
«Во Франции незаконно называть свинью Наполеоном, но меня не остановить» :)
Разумеется, запускать node-exporter (равно как и все остальные компоненты) в контейнере вовсе не обязательно. Это лишь пример, иллюстрация одного из вариантов :)
Изоляция процессов в контейнерах осуществляется благодаря двумя механизмами ядра Linux – пространствам имен (namespaces) и контрольным группам (cgroups). Мы частично нарушили изоляцию файловой системы, но остальные пространства все еще работают, как и контрольные группы.
Еще один плюс (возможно очень субъективный) – все программное обеспечение распространяется через образы. Это банально удобно
Несколько различий все же есть:
Запуск контейнеров под пользователями без прав root и управление контейнерами пользователями без прав root – существенно разные вещи
Docker требуется сервис, Podman работает без него (минус единая точка отказа)
Docker использует Container Runtime runc, Podman использует crun
Однако совершенно верно, что с точки зрения рядового пользователя разницы особой нет. Podman изначально разрабатывали так, чтобы внешне он ничем (практически) не отличался
P.S. Я не топлю за Podman, но вижу его применение оправданным в дистрибутивах с сильным влиянием RedHat :)
Спасибо за дополнение! Честно говоря не пользовался этим GUI на практике. Что-то похожее видел в Docker Desktop, когда устанавливал его при подготовке статьи. А так в основном только CLI под рукой
Как понимаю, речь идет о переходе с Linux Containers на Docker или Podman. По-моему это как раз тот случай, когда лучше изучить, чем не изучать – цинично, но в будущее технологий под эгидой OCI я верю больше :)
Для меня главное практическое преимущество – возможность не думать лишний раз. На каждом из десятков и сотен серверов есть удобный механизм – systemd юниты, который управляет зависимостями, заботится о восстановлении при сбоях, позволяет смотреть конфигурации и управлять всем необходимым ПО единообразно. В целом, думаю, можно обойтись и без systemd, особенно в небольших средах и проектах – дело вкуса
На мой взгляд обе эти темы однозначно заслуживают отдельных статей, особенно безопасность :) К счастью кое-что уже есть:
Сети Docker изнутри: как Docker использует iptables и интерфейсы Linux
Безопасность для Docker-контейнеров
Часто забываемые правила безопасности Docker: заметки энтузиаста ИБ
Любопытный специалист продолжит изучение технологии, посмотрит на другие решения и (очень надеюсь) углубится в практику. Выше же представлен всего лишь обзорный материал для понимания нескольких начальных тезисов :)
Из относительно свежих книг приходит на ум только «Linux: от новичка к профессионалу» Д. Колисниченко. Очень хорошие (пусть и немного устаревшие) на мой вкус курсы по LPIC есть у Кирилла Семаева (выложены на Youtube). А дальше уже погружаться только через обильную практику, чтение скучных мануалов и узконаправленных статей :)