Частота отправки активных алертов из Alertmanager определяется параметром repeat_interval в файле /etc/alertmanager/config.yml. У нас этот интервал задан в 15 минут, в результате чего в Slack каждые 15 минут приходят уведомления обо всех активных алертах в системе. Но некоторые алерты это такие себе “known issue”, когда о проблеме мы знаем, девелоперы её взяли в работу для… Читать далее »
Kubernetes HorizontalPodAutoscaler, как видно из названия, предназначен для автоматического скейлинга Kubernetes Pods в кластере, которые управляются ReplicationController, Deployment или ReplicaSet контроллерами, основываясь на их метриках потребления ресурсов – CPU, память и т.д. Кратко его рассматривали в посте Kubernetes: запуск metrics-server в AWS EKS для Kubernetes Pod AutoScaler, теперь разберёмся с доступными метриками. Для HPA доступны… Читать далее »
Сейчас в Prometehus мы собираем метрики из AWS CLoudWatch с помощью CloudWatch exporter от самого AWS, см. Prometheus: CloudWatch exporter — сбор метрик из AWS и графики в Grafana, однако, у него есть несколько недостатков: написан на Java, тяжёлый – грузит хост мониторнига не подтягивает теги использует GetMetricStatistics для получения метрик умеет собирать метрики только… Читать далее »
В продолжение поста Kubernetes: мониторинг с Prometheus, в котором мы настроили мониторинг вручную, и более-менее разобрались с тем, как оно всё внутри работает – теперь попробуем прикрутить Prometheus Operator из Helm-репозитория. Напомню, задача – поднять Prometheus и все необходимые експортёры в AWS Elastic Kubernetes Cluster, и с него через /federation передавать метрики на наш “центровой”… Читать далее »
Следующая задача – настроить мониторинг Kubernetes. Задача осложняется тем, что у нас есть целый набор ресурсов, которые требуется мониторить: инфраструктура – ЕС2 инстасы WokerNodes, их ЦПУ, память, сеть ключевые сервисы самого Kubernetes – состояние API сервера, etcd, scheduler состояние подов и контейнеров состояние деплойментов сбор метрик непосредственно с приложений Для мониторинга всего этого доступны следующие… Читать далее »
Задача – иметь перед глазами график в Grafana, который будет отображать расходы на AWS. Есть два варианта – использовать експортер от Prometheus – prom/cloudwatch-exporter, или самописный от nachomillangarcia – prometheus_aws_cost_exporter. Первый собирает метрики от AWS CloudWatch, в которые данные по биллингу поступают только на следующий день. Второй написан на Python, ходит к AWS API, получает… Читать далее »
Последний раз Loki для сбора и наблюдения за логами настраивал аж в феврале этого (см. Grafana Labs: Loki — сбор и просмотр логов), когда Loki была ещё в beta-версии. Сейчас возникли проблемы с исходящим трафиком (объём за два месяца вырос в 4 раза), никак не можем найти виновника. Как один из вариантов поиска этого самого… Читать далее »
Начали у нас на бекенде размножаться процессы. Причина сейчас не важна, интересно другое: захотелось собирать метрики по общему количеству процессов на хостах, но, внезапно – node-exporter такого не умеет: у него есть только метрики node_procs_running и node_procs_blocked, а хочется видеть количество процессов и в Sleep, и в Zombie. Используем вместо него process-exporter. Запускаем для проверки… Читать далее »
В дополнение к посту Prometheus: роутинг алертов в Alertmanager. Имеется конфиг с роутами. Задача – вырезать все алерты от Дев-а, и слать в “/dev/null”. Для этого – создаём пустой ресивер: … receivers: – name: ‘blackhole’ – name: ‘default’ slack_configs: – send_resolved: true title_link: ‘http://dev.monitor.example.world/prometheus/alerts’ title: ‘{{ if eq .Status “firing” }}:confused:{{ else }}:dancing_panda:{{ end }}… Читать далее »
После внедрения Loki на рабочем проекте – решил добавить его и себе. А заодно – добавить node_exporter и alertmanager, что бы получать уведомления, когда на разделах будет заканчиваться место. Обычно “Ссылки по теме” размещаю в конце поста, но тут стоит их добавить в начале. Для общего знакомства с Prometheus: Prometheus: мониторинг — введение, установка, запуск,… Читать далее »