... этой зимы. Сегодня разберем, как эволюционирует система алертинга в Grafana 12.4.0, что меняется после обновлений API в GitHub Actions, почему масштабирование etcd остаётся критическим фактором в Kubernetes.
⏺Grafana 12.4.0 и прозрачное управление алертами
Выкатили релиз версии 12.4.0, в которую внесли изменения в Grafana Alerting, политики RBAC и datasource-стек. В обновлении представили политики routing (policy selector, вкладки конфигурации, навигация), импорт конфигураций через Wizard первой итерации. Из важного – добавили метки алертов в аннотации, улучшили тестирование receiver’ов (в сторону Kubernetes-style API), а также исправили неточности во временных расчетах. В версии 12.4.0 оптимизировали преобразование regex в label matchers для Prometheus, ввели поддержку
serverless для Elasticsearch и переменных в Query editor для PostgreSQL и MySQL. Работа с метриками и логами стала более предсказуемой. Ознакомиться с релизом – здесь. ⏺Что нового в GitHub Actions?
Внесли обновления в API workflow dispatch: теперь при ручном запуске вы получаете идентификатор и ссылки на созданный run. Благодаря параметру
return_run_details вам возвращаются метаданные workflow_id, run API URL и workflow URL. Эта функция также поддерживается в GitHub CLI, начиная с версии v2.87.0. Представленные обновления значительно облегчили автоматизацию, больше никакого кастомного трекинга :) Подробнее – тут и в GitHub Actions documentation.⏺Что меняется с etcd при масштабировании в Kubernetes?
Если вы годами разворачиваете кластеры Kubernetes и всё еще не задумались о etcd – статья от Learnkube для вас. В Kubernetes только API-сервер напрямую взаимодействует с etcd. Планировщик, менеджер контроллеров, kubelet, kubectl и ваши операторы взаимодействуют с Kubernetes через API-сервер. Так, etcd в статье назвали частным бэкэндом. Etcd предоставляет строгую согласованность (strong consistency) через Raft, но имеет ограничения в масштабируемости. Зачем мониторить размер БД, нагрузку watch и поведение API-сервера – тут.
⏺На портале DBI Service выкатили RAG-серию из двух статей.
В первой части сосредоточились на версионировании эбмеддингов и событийно-ориентированной архитектуре. Вместо полной переиндексации эмбеддингов Адриан Обернессер рекомендует использовать событийно-ориентированный (event-driven) подход для ИИ workflow: обновляйте только то, что меняется. Так, вы экономите деньги и снижаете нагрузку. В статье рассматриваются PostgreSQL, pgvector, Apache Flink и Debezium – но подход применим к любому векторному стеку. Всего представлено 3 уровня практических решений, под задачи проектов разной сложности. Читайте здесь.
Во второй части подборки Адриан Обернессер демонстрирует внедрение версионирования эмбедингов на примере реальной базы данных Википедии из репозитория
pgvector_RAG_search_lab : 25 000 статей, триггеры, OpenAI API calls, реальные числа. Обязательно к прочтению для всех, кто хочет разобраться, как выглядят решения SKIP и EMBED на базе данных, как SELECT FOR UPDATE SKIP LOCKED работает c concurrent worker-ами и что интересного в отчёте об актуальности данных на практике. Рассмотреть – здесь. Весь код – в лабе.#devops #opensource #postgresql #новостнаяподборка