Где Установить Prometheus Для Мониторинга Kubernetes

Я рассматриваю возможность использования Prometheus для мониторинга и анализа различных показателей моего кластера AWS EKS Kubernetes, работающего в Fargate, поскольку в настоящее время это, похоже, стандартный инструмент. Однако что меня действительно впечатлило, так это то, что установка самого Prometheus в тот же кластер k8s (в качестве еще одного работающего набора подов) — это нормально. Прав ли я или просто получил неправильное представление в результате своего исследования? Учитывая передовой опыт, не должен ли инструмент мониторинга находиться за пределами системы, которую вы на самом деле собираетесь контролировать? Кроме того, если я настрою несколько кластеров Kubernetes, не будет ли сложнее иметь одну установку Prometheus на каждый кластер? Можно ли настроить одну установку Prometheus и централизовать на ней все метрики кластеров k8s?

Тот же вопрос об установке Grafana... Должен ли он быть установлен внутри или снаружи кластера?

По другой теме, период хранения истории Prometheus по умолчанию установлен на 15 дней ( storage.tsdb.retention.time ). Even though cluster metrics insight should be useful for a short period of time so you can troubleshoot issues, I wonder if there may be scenarios in which a longer history period might help. Any comments on this matter?

Спасибо!

#kubernetes #мониторинг #прометей #графана #экс

Это скорее вопрос, основанный на мнении, но позвольте мне попытаться на него ответить.

установка самого Прометея в тот же кластер k8s (как еще один работающий набор подов) — это нормально. Я прав или просто в результате своих исследований получил неправильное представление?

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

Это правильная практика. Системы мониторинга обычно настраиваются для наблюдения за контролируемым объектом. (снаружи, заглядывая внутрь). Но с системами самовосстановления, такими как k8s, установка мониторинга внутри системы может быть выполнена с минимальными проблемами. Есть несколько случаев, на которые вам необходимо обратить внимание для обеспечения надлежащей стабильности.

• Поды удаляются: - Запустите Prometheus в режиме высокой доступности (минимум 2 реплики).
• чтобы не потерять данные. Поды заменены из-за нехватки ресурсов: - Добавить приоритетные классы
• чтобы предотвратить выселение формы модуля. Используйте постоянные тома: - Посмотритепривязка узла тома
• конфликт

. Также настройте период хранения данных, чтобы сделать

оптимизированное использование памяти.

Кластер падает. См. ниже.

Кроме того, если я настрою несколько кластеров Kubernetes, не будет ли сложнее иметь одну установку Prometheus на каждый кластер?

• Вовсе нет, если использовать комбинацию IaC (Terraform/Chef), управления конфигурациями (Ansible), CI/CD (Spinnaker), GitOps и диаграмм Helm. Настройка/поддержание экземпляров Prometheus на нескольких экземплярах не будет проблемой.
• Можно ли настроить одну установку Prometheus и централизовать на ней все метрики кластеров k8s?
• Несмотря на то, что Prometheus высоко оптимизирован, он не сможет обрабатывать все показатели, полученные от нескольких кластеров. Кроме того, Prometheus не масштабируется самостоятельно по горизонтали, поэтому ему потребуются огромные ресурсы. Централизация всех показателей в одном месте вызовет и другие проблемы.

Сетевое подключение/задержка: - Запуск централизованного Prometheus.

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

• потери/ложные оповещения из-за обрывов сети и задержек.
• Стоимость: - Запуск десятков экспортеров, отправляющих данные через Интернет.
• приведет к высоким затратам на Интернет для развертываний в облаке.

Управление кластером: - Вы можете столкнуться с проблемами с экспортером/работой.

конфигурация такого большого количества экспортеров. Это хороший выбор для запуска Prometheus на кластер. при этом вы можете хранить все данные локально до тех пор, пока не потребуется время. Grafana не потребляет много ресурсов, поэтому ее можно безопасно запускать внутри кластера. Однако он сталкивается с другим набором проблем: Управление пользователями/разрешениями: - Каждый локальный экземпляр должен быть поддерживаться отдельно, что является огромной задачей. Управление графиками: - То же, что и выше. L1/DevOps придется держать открытыми n вкладок, чтобы отслеживать ваши действия.

ниже.

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