Всем привет! Световой день становится длиннее, а это значит, что теперь у нас есть больше времени на поиск полезных материалов про Kubernetes для вас. Встречайте новую рубрику #посмотрели_рассказали, в которой мы будем делиться обзорами полезных, на наш взгляд, видео о K8s.
Сегодня поговорим об интервью Александра Валялкина, CTO известного решения для мониторинга VictoriaMetrics, на котором шла речь о мониторинге Kubernetes.
Хайлайты интервью
➡️ Kubernetes популяризовал и демократизировал микросервисную архитектуру, что привело к взрыву количества метрик и телеметрии.
➡️ Установка трехнодового кластера по дефолту дает много метрик.
➡️ Добавление инструментов типа Prometheus дает доступ к дополнительным инструментам, например kube-state.
➡️ В итоге мониторинг трехнодового кластера может вылиться в десятки тысяч метрик.
➡️ С 2018 года количество метрик увеличилось в 3,5 раза.
Обо всем подробнее
Проблема: частые деплойменты в Kubernetes приводят к созданию новых подов с уникальными именами, и каждый под создает свой набор уникальных метрик. Это называется Pod Churn.
Важно проектировать мониторинг, исходя из чего-то более консистентного внутри жизненного цикла проекта. StatefulSets используют консистентные паттерны именования подов + номерной суффикс, все это остается статическим в пределах деплоймента.
Чтобы снизить нагрузку на мониторинг и его сложность, разработчикам на K8s нужно использовать стабильное именование.
Мониторинг, когда много деплойментов:
Logz.io использует в своих Helm-чартах (публично доступных на Гитхабе) курируемый список полезных метрик для Kubernetes, в том числе Managed-версий. Это помогает снизить затраты на планирование мониторинга. Но курируемые списки должны различаться для приложения, инфраструктуры и т. д.
Гистограммы сильно нагружают систему, и разработчики должны подумать дважды перед их использованием. Exponential bucket histograms хороши для измерения, но количество buckets может стать слишком большим. Если в Kubernetes много деплойментов, это может привести к разным конфигурациям с разной конфигурацией мониторинга.
Использование стандартных методов Discovery в CRD для деплойментов и параметров позволяет автоматически собирать метрики без кастомных конфигураций.
OpenTelemetry:
если нужно собирать только метрики, то лучше использовать проверенные простые методы (Prometheus);
если нужно собирать трейсы и логи, то OT может быть хорошим вариантом.
VictoriaMetrics:
Однако даже Prometheus перестал справляться с возрастающим количеством метрик, поэтому была разработана VictoriaMetrics. VictoriaMetrics — технология a-la Prometheus, совместимая с PromQL. Это Time Series database, написанная с нуля, со своим языком запросов, MetricsQL, агентом для сбора данных, обнаружения, скрейпинга и т. д. Успешно протестирована на 100 метриках в секунду, 24 часа, на кластере из 100 нод и с увеличением до 1000.
Если найдете суперинтересное видео, смело присылайте нам на почту [email protected], а мы посмотрим — расскажем.
#посмотрели_рассказали
Сегодня поговорим об интервью Александра Валялкина, CTO известного решения для мониторинга VictoriaMetrics, на котором шла речь о мониторинге Kubernetes.
Хайлайты интервью
➡️ Kubernetes популяризовал и демократизировал микросервисную архитектуру, что привело к взрыву количества метрик и телеметрии.
➡️ Установка трехнодового кластера по дефолту дает много метрик.
➡️ Добавление инструментов типа Prometheus дает доступ к дополнительным инструментам, например kube-state.
➡️ В итоге мониторинг трехнодового кластера может вылиться в десятки тысяч метрик.
➡️ С 2018 года количество метрик увеличилось в 3,5 раза.
Обо всем подробнее
Проблема: частые деплойменты в Kubernetes приводят к созданию новых подов с уникальными именами, и каждый под создает свой набор уникальных метрик. Это называется Pod Churn.
Важно проектировать мониторинг, исходя из чего-то более консистентного внутри жизненного цикла проекта. StatefulSets используют консистентные паттерны именования подов + номерной суффикс, все это остается статическим в пределах деплоймента.
Чтобы снизить нагрузку на мониторинг и его сложность, разработчикам на K8s нужно использовать стабильное именование.
Мониторинг, когда много деплойментов:
Logz.io использует в своих Helm-чартах (публично доступных на Гитхабе) курируемый список полезных метрик для Kubernetes, в том числе Managed-версий. Это помогает снизить затраты на планирование мониторинга. Но курируемые списки должны различаться для приложения, инфраструктуры и т. д.
Гистограммы сильно нагружают систему, и разработчики должны подумать дважды перед их использованием. Exponential bucket histograms хороши для измерения, но количество buckets может стать слишком большим. Если в Kubernetes много деплойментов, это может привести к разным конфигурациям с разной конфигурацией мониторинга.
Использование стандартных методов Discovery в CRD для деплойментов и параметров позволяет автоматически собирать метрики без кастомных конфигураций.
OpenTelemetry:
если нужно собирать только метрики, то лучше использовать проверенные простые методы (Prometheus);
если нужно собирать трейсы и логи, то OT может быть хорошим вариантом.
VictoriaMetrics:
Однако даже Prometheus перестал справляться с возрастающим количеством метрик, поэтому была разработана VictoriaMetrics. VictoriaMetrics — технология a-la Prometheus, совместимая с PromQL. Это Time Series database, написанная с нуля, со своим языком запросов, MetricsQL, агентом для сбора данных, обнаружения, скрейпинга и т. д. Успешно протестирована на 100 метриках в секунду, 24 часа, на кластере из 100 нод и с увеличением до 1000.
Если найдете суперинтересное видео, смело присылайте нам на почту [email protected], а мы посмотрим — расскажем.
#посмотрели_рассказали