Мониторинг может оказаться дорогим делом из-за огромных объемов данных, которые необходимо обрабатывать. В этой статье вы узнаете о лучших способах хранения и обработки метрик мониторинга для снижения расходов и о том, как VictoriaMetrics может в этом помочь.

(cм. вторую статью из этой серии — Как снизить расходы на мониторинг: более разумный подход к данным.)

Меня зовут Валентина, я отвечаю за качество low-code платформы Efftech.Factory в компании Effective Technologies. В этой серии публикаций я честно расскажу о практиках нагрузочного тестирования (НТ), которые мы внедрили у себя. Будет признание реальных ошибок, настоящий процесс НТ и попытки его автоматизации. Те, кто предпочитает видео, могут посмотреть моё выступление на Spring QA Meetup 2024, благодаря которому появился этот текст. 

Почему я против жанра Success Story? 

В историях успеха нет места для тех глупых и болезненных ошибок, которые мы в действительности совершаем. Success Stories маловероятны. Каждая такая история — это лишь узкая тропинка, которая при определенных условиях может привести вас к победе… В остальных случаях может и не повезти!)

Другое дело — «Failure Stories». Это ситуации, которые вызывают понимающую улыбку и позволяют задуматься, как не допустить подобных ошибок у себя в проекте.

Ошибаться — это нормально. На ошибках учатся) Поэтому я хочу поделиться с вами опытом совершённых мной ошибок.

Helm — один из самых популярных пакетных менеджеров для Kubernetes. Познакомиться с ним полезно любому DevOps-инженеру и всем, кто сталкивается с задачами деплоя приложений. Эта статья — первый из двух материалов, которые можно вместе можно рассматривать как краткое, но достаточно полное введение в Helm.

В статье мы расскажем, что за утилита k8sgpt, как её поставить, какие есть полезные опции и как подключить к ней AI. Также покажем, какого уровня диагностику можно провести с помощью этого инструмента и на какие ответы чат-бота можно рассчитывать.

Поздравляем! Вам удалось убедить ваше начальство в миграции приложений на микросервисную архитектуру с использованием контейнеров и Kubernetes.

Вы очень довольны и все идет по плану. Вы создаете свой первый кластер Kubernetes (у всех основных облачных провайдеров: Azure, AWS и GCP, — есть простые решения для провиженинга управляемого или неуправляемого Kubernetes), разрабатываете первое контейнерное приложение и развертываете его в кластере. Это было легко, не так ли?

Через некоторое время вы понимаете, что все становится немного сложнее: вам нужно развернуть в кластере несколько приложений, поэтому вам нужен Ingress Controller. Далее вы хотите мониторить нагрузку, поэтому вы начинаете искать решения для этого и, к счастью, находите Prometheus. Разворачиваете его, добавляете Grafana и все!

Позже вы начинаете задаваться вопросом: "Почему Prometheus работает только с одной репликой"? Что произойдет в случае рестарта контейнера? Что будет при простом обновлении версии? Как долго Prometheus может хранить метрики? Что если кластер развалится? Нужен ли еще один кластер для HA и DR? Как мне получить единое представление метрик со всех серверов Prometheus? 

Что ж, продолжайте читать, умные люди уже разобрались с этими вопросами.

Всем привет! Меня зовут Роза и я MLOps-инженер в Купере. Под катом расскажу, как построить CI/CD-пайплайн для ML-приложений с нуля, поэтапно и без боли. Ну почти :)

Раньше очень часто работа DS-инженера заканчивалась на подготовке кода модели в Jupyter-ноутбуке, а дальше его подхватывали команды разработки и доводили до продакшена. У такого подхода есть минусы. Например, если произойдёт инцидент, непонятно кто ответственен за сервис  — команда разработки или авторы ML-модели?

К счастью, культура разработки меняется: теперь ML-инженер — это специалист, который разрабатывает свой ML-сервис на всем пути от общения с бизнесом до продакшена. Этот подход хорошо описывает принцип «you build it, you run it»: кто построил модель, тот её и запускает. Как раз в этом здорово помогает CI/CD.

Разберём как при помощи VictoriaMetrics замониторить kubernetes. Откуда собирать метрики и как автоматически обнаруживать новые цели. Черная магия релейблинга и как она работает. Аннотации для мониторинга приложений и что делать когда их гибкости не хватает

За короткое время Prometheus стал одним из самых популярных средств для мониторинга. Благодаря, в том числе, и высокой скорости своей работы. Его локальное хранилище отлично подходит для краткосрочного хранения метрик и работы с ними. Иногда хочется хранить метрики распределённо месяцы и годы, автоматически разрежая старые данные, но не меняя интерфейса работы с ними.

Как раз об этом расшифровка доклада Алексей Палажченко на RootConf 2018. В докладе: Prometheus, Local Storage TSDB, Remote Storage Prometheus, PromQL, TSDB, Сlickhouse, PromHouse, немного InfluxDB.

Кому интересно, прошу под кат.

Все об использовании шаблонов в Airflow с примерами кода. Продолжение серии публикаций astronomer.io

Поскольку Airflow — это на 100% код, знание основ Python - это все, что нужно, чтобы начать писать DAG. Однако написание эффективных, безопасных и масштабируемых DAG требует учета некоторых моментов, специфичных для Airflow. В этом разделе мы рассмотрим некоторые передовые методы разработки DAG, которые максимально используют возможности Airflow.

В целом, большинство лучших практик, которые мы здесь рассматриваем, относятся к одной из двух категорий:

Операторы являются основными строительными блоками DAG Airflow. Это классы, которые содержат логику выполнения единичной работы.

Вы можете использовать операторы в Airflow, создав их экземпляры в задачах. Задача определяет работу, выполняемую оператором в контексте DAG.

Чтобы просмотреть и выполнить поиск по всем доступным операторам в Airflow, посетите Astronomer Registry. Ниже приведены примеры операторов, которые часто используются в проектах Airflow.

Полное руководство по созданию DAG в Apache Airflow DAG, позволяющих создать конвейер данных из разных источников, запускаемый в определенные периоды времени с заданной логикой. Первая часть. Источник: DAGs: The Definitive Guide от astronomer.io

Добро пожаловать в полное руководство по Apache Airflow DAG, представленное командой Astronomer. Эта электронная книга охватывает все, что вам нужно знать для работы с DAG, от строительных блоков, из которых они состоят, до рекомендаций по их написанию, динамической генерации, тестированию, отладке и многому другому. Это руководство, написанное практикующими для практикующих.

Kubernetes Nginx Ingress: перенаправление трафика с использованием аннотаций

Перенаправляйте HTTP-трафик или переписывайте URL-адреса с помощью входных аннотаций Kubernetes и Nginx ingress controller. В этой статье объясняется использование аннотаций и их влияние на результирующий файл конфигурации nginx.conf.

В этой статье мы рассмотрим тонкости сетевого взаимодействия Kubernetes и углубимся в фундаментальные принципы и механизмы, которые управляют связью между подами.