June 23, 2026

The inside scoop on alerting changes in Kubernetes Monitoring

Grafana Cloud's Kubernetes Monitoring có hai hệ thống cảnh báo riêng biệt: cảnh báo quản lý bởi data source (Mimir/Prometheus) và cảnh báo quản lý bởi Grafana. Việc cài đặt lại app sẽ tự động chuyển quy tắc cảnh báo sang hệ thống Grafana, có thể làm gián đoạn các tuyến thông báo đã cấu hình trong Alertmanager. Bài viết hướng dẫn cách nhận diện hệ thống cảnh báo đang sử dụng, nguyên nhân ngừng hoạt động sau khi cài đặt lại, và các phương pháp tốt nhất như sử dụng nút Update thay vì cài đặt lại, sao lưu quy tắc tùy chỉnh trước khi nâng cấp, và lưu ý rằng cảnh báo quản lý bởi data source (Prometheus/Loki) sẽ ngừng hoạt động từ tháng 4/2026.

Lập trình viên cần đọc bài này để tránh mất hiệu suất cảnh báo trong Kubernetes khi tái cài đặt Grafana Cloud, vì nó có thể phá hủy cấu hình thông báo hiện có và cảnh báo cũ sẽ chuyển sang hệ thống quản lý mới, gây mất liên lạc với các hệ thống cảnh báo bên ngoài.

A revamped way to create and manage alerts across all your telemetry

Last9 đã tái thiết hệ thống cảnh báo từ đầu, với trình chỉnh sửa mới hợp nhất việc tạo cảnh báo cho metrics và logs, hỗ trợ PromQL/LogQL cùng Builder không code, cùng chế độ xem trước trực tiếp. Bản cập nhật bổ sung trang Rules mới, Alert Monitor, cài đặt cảnh báo theo nhóm, khả năng kiểm tra kênh thông báo trước khi triển khai, cùng cải tiến dashboard (tải CSV, panel markdown, hỗ trợ Terraform) và sửa lỗi trên mobile SDK.

Lập trình viên nên đọc bài này vì giải pháp mới của Last9 giúp tối ưu hóa quản lý cảnh báo từ dữ liệu telemetry một cách hiệu quả hơn, với công cụ trực quan và tích hợp no-code, giúp phát triển và kiểm soát quy trình theo dõi lỗi và cảnh báo nhanh chóng hơn.

Mastering Secure CI/CD for ECS with GitHub Actions

Bài viết hướng dẫn xây dựng quy trình CI/CD an toàn cho ECS trên Fargate bằng GitHub Actions, cải tiến vận hành như hợp nhất workflow, dùng commit hash làm tag ảnh container, quản lý định nghĩa task và service với ecspresso. Ngoài ra, bài cũng đề cập đến biện pháp bảo mật như AssumeRole không dùng key với OpenID Connect, quét lỗ hổng bằng Trivy và Dockle, cùng multi-stage build để giảm bề mặt tấn công.

Lập trình viên cần đọc bài này để tìm hiểu cách xây dựng và tối ưu hóa một chu trình CI/CD an toàn trên AWS ECS Fargate bằng GitHub Actions, từ việc quản lý mã nguồn đến bảo mật container và giảm diện tích tấn công.

How to migrate feature flags without breaking production

Feature flag migrations often stall due to three core challenges: evaluation logic parity between systems, configuration synchronization during the migration window, and confirming cutover safety. Running two systems in parallel is safe and enables incremental migration. The recommended approach starts with auditing flags into zombie, short-lived, and long-lived categories, then redirecting all new flags to the new system, letting short-lived flags expire naturally, and carefully cutting over long-lived flags. To verify parity before cutover, teams can use a wrapper function that evaluates both systems asynchronously and logs discrepancies, or use OpenFeature's ComparisonStrategy for shadow mode evaluation. Mismatch metrics should be tracked on a dashboard showing evaluation counts, mismatch rate trends, and timestamps. A brief configuration freeze of 24–48 hours before cutover ensures the validated state matches production.

Using Evaluation Frameworks with Agent Observability

Datadog Agent Observability now supports running DeepEval and Pydantic Evals evaluation frameworks natively within Datadog Experiments, eliminating the need to rewrite existing evaluators or adopt proprietary metric definitions. The integration lets teams define datasets, configure existing evaluators without modification, and run experiments that automatically link eval scores to production traces, token usage, and latency data. Teams can also run evaluations continuously on sampled production traffic rather than only as a pre-deployment CI gate, enabling real-time quality regression detection across the full development and deployment lifecycle.

Tsuga raises $35m to keep AI-era observability inside the customer’s own cloud

Paris-based startup Tsuga has raised a $35m Series A led by Singular, bringing its total funding to ~$45m just six months after emerging from stealth. Founded by two ex-Datadog engineers, Tsuga challenges the traditional observability model by deploying inside the customer's own cloud rather than ingesting telemetry into a vendor-controlled environment. This eliminates per-byte pricing — a growing pain as AI agent workloads generate massive telemetry volumes — and keeps sensitive data within the customer's security and regulatory perimeter. The platform offers automated root-cause analysis on unsampled data, an MCP server, and a CLI for building custom agents. A Databricks partnership allows routing observability data directly into Databricks for further analysis. Early customers include Le Monde, Camunda, and Black Forest Labs, with several million dollars in ARR and six-figure average contract values reported.

Building Jaeger’s ClickHouse backend: 8.6× compression on 10 million spans

Jaeger v2.18.0 introduces ClickHouse as a storage backend for distributed traces. A Jaeger maintainer explains the architectural decisions behind the implementation, including schema design choices for the primary key (sorted by service_name, name, start_time rather than trace_id), typed attribute storage using ClickHouse Nested columns, and materialized views for fast service/operation lookups. Benchmarks on 10 million spans across a single-node deployment show 8.6× compression (reducing ~6 GiB to ~722 MiB), ingestion throughput above 50k spans/sec, trace retrieval averaging ~100ms, and most search queries completing under 50ms. The feature is available in alpha and leverages ClickHouse's columnar OLAP architecture to handle high-throughput append-only writes and fast analytical aggregations without a separate metrics pipeline.