Со временем в проекте пришли к тому, что пора бы записывать все инциденты, влияющие на работу сервисов и приложний. Раньше вели документ в Confluence, который заполняли руками – но решение так себе, ибо 90% инцидентов просто решали без добавления записей о них. Захотелось как-то навести порядок, ввести более адекватный Incidents Management (IcM), и вообще автоматизировать… Читать далее »
Частота отправки активных алертов из 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 раза), никак не можем найти виновника. Как один из вариантов поиска этого самого… Читать далее »
При использовании AWS VPC DNS периодически сталкиваемся с ошибками вида “php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution“. Единственный совет от тех. поддержки AWS заключался в установке dnsmasq в роли кеширующего сервиса, но он уже давно установлен – а проблема раз в несколько месяцев проявляется снова. Хотя пост не о том, но из возможных причин… Читать далее »
Начали у нас на бекенде размножаться процессы. Причина сейчас не важна, интересно другое: захотелось собирать метрики по общему количеству процессов на хостах, но, внезапно – node-exporter такого не умеет: у него есть только метрики node_procs_running и node_procs_blocked, а хочется видеть количество процессов и в Sleep, и в Zombie. Используем вместо него process-exporter. Запускаем для проверки… Читать далее »