В пості Prometheus: запуск Pushgateway у Kubernetes з Helm та Terraform писав про те, як для Prometheus додати Pushgateway, який дозволяє використовувати Push-модель замість Pull, тобто – експортер може відправити метрики прямо в базу замість того, щоб чекати, коли до нього прийде сам Prometheus або VMAgent. У VictoriaMetrics з цим набагато простіше, бо ніякого Pushgateway… Читати далі »
Отже, маємо Loki, встановленую з чарту у simple-scale mode, див. Grafana Loki: архітектура та запуск в Kubernetes з AWS S3 storage та boltdb-shipper. Працює Loki все в AWS Elastic Kubernetes Service, встановлено з Loki Helm chart, в ролі long-term store використовуємо AWS S3, а для роботи з індексами Loki – BoltDB Shipper. У Loki в… Читати далі »
Зараз маємо VictoriaMetrics + Grafana на звичайному EC2-інстансі, запущені з Docker Compose – то був Proof of Concept, прийшов час запускати “по-дорослому” – в Kubernetes, і всі конфіги вже винести в GitHub. У VictoriaMetrics є чарти під кожен компонент, див. Victoria Metrics Helm Charts, і є чарти для запуску VictoriaMetrics Operator та victoria-metrics-k8s-stack – аналог… Читати далі »
Давно і багато чув про VictoriaMetrics, і нарешті настав час, коли її можна спробувати. Отже, в двох словах – VictoriaMetrics це “Prometheus на стероідах”, і повністю з ним сумісна – може використовувати його файли конфігурації, експортери, PromQL тощо. Тож як для людини, яка завжди користувалась Prometheus, перше питання – в чьому різниця? Єдине, що пам’ятаю,… Читати далі »
Прийшла досить цікава задачка – побудувати в Grafana дашборду, в якій би відображався статус процессу розробки, а саме – перформанс, тобто ефективність наших DevOps-процесів. Потрібно це тому, что ми намагаємось побудувати “true continuous deployment”, щоб код автоматично потрапляв у Production, і нам важливо бачити як саме проходить процес розробки. Загалом для оцінки ефективності процессу розробки… Читати далі »
Маємо на проекті багато AWS Lambda функцій, з яких девелопери хочуть мати можливість відправляти метрики до нашого Prometheus, щоб додати власних алертів та графіків у Grafana. Для цього у функціях використовується бібліотека Prometheus, яка дозволяє ці метрики створювати (див. Prometheus: створення Custom Prometheus Exporter на Python), але ж ми не маємо змоги нормально отримати ці… Читати далі »
Отже, продовжуємо нашу подорож з міграцією GitLab до себе в Kubernetes. Див. попередні частини: GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3 GitLab: міграція даних з GitLab cloud та процес backup-restore у self-hosted версії в Kubernetes В цілому – все працює, і… Читати далі »
У Прометеуса є багато готових до використання експортерів, але інколи може з’явитися потреба у зборі своїх власних метрик. Для цього Прометеус надає клієнтські бібліотеки, які можемо використати для генерації метрик з потрібними лейблами. Експортер можна включити прямо в код вашого додатку, або можна запускати окремим сервісом, який буде звертатися до якогось вашого сервісу і отримувати… Читати далі »
Про blackbox-exporter я вже колись писав, див. Prometheus: Alertmanager и blackbox-exporter – проверка срока действия SSL и нотификация в Slack, але там було чисто про моніторинг SSL-сертіфікатів, та й було то давно, та й сетапилось все без Кубернетісу та Хельму. Цього разу трохи детальніше про його сетап і можливості. Отже, blackbox-exporter – це експортер, який… Читати далі »
Отже, Друід ми запустили – див. Apache Druid: огляд, запуск в Kubernetes та моніторинг з Prometheus. Поки що в дефолтному вигляді, тобто в ролі сторейджа для метаданих використовується локальна база Apache Derby. Далі будемо переключати Друід на PostgreSQL, ще згодом – прибирати звідти ZooKeeper. Ну а для початку – запустимо кластер PostgreSQL в Kubernetes, додамо… Читати далі »