Linux, cloud, bảo mật, automation và góc nhìn production cho người làm hạ tầng.
Các lỗ hổng Xen Hypervisor mới được công bố có thể cho phép một máy ảo độc hại đọc hoặc ghi bộ nhớ của máy ảo khác, phá vỡ ranh giới cô lập quan trọng của hạ tầng ảo hóa. Quản trị viên Xen cần đối chiếu advisory chính thức, phiên bản hypervisor và lịch bảo trì để vá host theo mức độ phơi nhiễm.
Red Hat trình bày cách Lightwell vừa backport bản sửa dependency cho nhánh sản phẩm vừa đưa thay đổi trở lại upstream, nhằm giảm chênh lệch giữa bản doanh nghiệp và cộng đồng. Đội quản lý bản vá nên theo dõi nguồn gốc patch, vòng đời backport và khả năng xung đột khi upstream phát hành bản mới.
AWS công bố S3 Tables có thể thực hiện quy trình di chuyển được quản lý cho bảng Apache Hive sang Apache Iceberg, giảm phần việc thủ công khi hiện đại hóa data lake. Đội dữ liệu cần kiểm tra schema, partition, quyền IAM và chi phí trước khi chuyển workload production.
GitHub phát hành CodeQL 2.27.4 với các điều chỉnh độ chính xác của phân tích và metadata cho truy vấn. Bản cập nhật tác động trực tiếp tới pipeline code scanning dùng CodeQL. Đội AppSec nên xác nhận phiên bản CodeQL trong CI, chạy lại bộ truy vấn trên repository mẫu và theo dõi thay đổi cảnh báo.
Canonical thông báo đã có bản sửa cho CVE-2026-109518 trong APT. Lỗ hổng liên quan chuỗi tin cậy khi tải và xác minh gói, vì vậy máy Ubuntu và Debian tương thích cần được ưu tiên đánh giá. Quản trị viên cần cập nhật gói APT từ kho chính thức, kiểm tra proxy/mirror trung gian và xác nhận phiên bản sau vá.
Cloudflare công bố bộ khả năng mới giúp tổ chức nhìn thấy agent cá nhân, đặt điều khoản sử dụng và kiểm soát cách chúng truy cập tài nguyên. Cập nhật nhắm tới bài toán quản trị agent trong môi trường doanh nghiệp. Đội nền tảng cần rà soát chính sách truy cập, nhật ký hoạt động và phạm vi dữ liệu mà agent cá nhân có thể sử dụng.
The Hacker News vừa công bố thông tin mới với tiêu đề “CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades”. Thông báo được phát hành ngày Wed, 04 Nov 2026 và liên quan trực tiếp tới các đội vận hành hạ tầng, bảo mật hoặc nền tảng phát triển. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a security flaw in WordPress Core to the Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The high-severity vulnerability, tracked as CVE-2026-119977 (CVSS score: 8.1), is a case of Time-of-check Time-of-use (TOCTOU) race condition that could be exploited to achieve arbitrary code
Elastic Blog vừa công bố thông tin mới với tiêu đề “Elastic Stack 9.5.6 released”. Thông báo được phát hành ngày Mon, 02 Nov 2026 và liên quan trực tiếp tới các đội vận hành hạ tầng, bảo mật hoặc nền tảng phát triển. Version 9.5.6 of the Elastic Stack was released today. We recommend you upgrade to this latest version . We recommend 9.5.6 over the previous versions 9.5.5 For details of the issues that have been fixed and a full list of changes for each product in this version, please refer to the release notes . These releases contain security fixes. For details, refer to the Elastic Security Advisories at https://discuss.elastic.co/c/announcements/security-announcements/31 .
Grafana Blog vừa công bố thông tin mới với tiêu đề “Trace linkage: connect the dots between your app traces and database queries”. Thông báo được phát hành ngày Tue, 03 Nov 2026 và liên quan trực tiếp tới các đội vận hành hạ tầng, bảo mật hoặc nền tảng phát triển. When an application request slows down, a trace can show a database call. Finding the database query behind it can be tedious, requiring you to switch between traces and database telemetry, as well as match timestamps or query text by hand. In Grafana Cloud, the Database Observability app already provides a window into all of your database telemetry, including query samples, performance history, and explain plan. But what if you could jump from that database call in the trace straight to its query details? OpenTelemetry database semantic conventions stabilized last year, giving us all a dependable shared language for describing database operations. That foundation has opened the door for what we call trace linkage , now Generally Available in Database Observability! What is trace linkage? With trace linkage, we try to provide a connection between OpenTelemetry-instrumented applications and database telemetry collected with Alloy . In other words, when you give us these previously-disjoint puzzle pieces, we’ll do our best to provide you as much supporting information between these two elements as we can. And we'll do it without making you tediously piece together timestamps and logs. From a database span in a trace, you’ll see a link on the query text. Clicking from there, the app searches for a connection between your database query and our opinionated view of your most relevant data in the Database Observability app. You can explore sampled query execution data or check out the query’s historical performance, alongside that query’s related schema and explain plan. This connection builds on the database attributes your OpenTelemetry instrumentation already emits. Grafana Cloud Traces , powered by Tempo, retain those attributes, and trace linkage uses the query text, database system, and database name to connect a database span to its supporting query context in Database Observability. We support the stable conventions like db.query.text and its legacy equivalent db.statement , so existing instrumentation can continue to benefit as teams adopt the stable conventions. How does it work? The initial idea for trace linkage came from this question: What shared context could connect application instrumentation with telemetry collected from the database? The answer was to leverage trace context: the trace ID and span ID. On one side we have an application trace with spans representing a query execution. On the Database Observability side, we are collecting telemetry from the database concerning query executions. As long as the telemetry we collect contains the same trace ID and span ID, we can make a link between the application trace and Database Observability. This led us to sqlcommenter , an open source project donated to the OpenTelemetry community. Its idea is (delightfully) simple: let the SQL statement carry a piece of trace context with it in a comment. With trace context propagation enabled, sqlcommenter injects the application’s trace ID and span ID into a comment at the end of the SQL statement. This is done at the level of an individual query execution, so this is like a shared thread that allows us to follow from a trace span to a specific query execution. We then search the trace ID and span ID in the logs that we generated in the Database Observability Alloy component: our component extracts traceparent from the SQL comment and includes it in query sample logs. Going beyond a traceparent match However, having sqlcommenter enabled doesn’t guarantee that Alloy captured the particular SQL execution. That can depend on how short-lived a query may be or how often Alloy polls the database. Even if you are ready to use sqlcommenter, not every database engine is supported, and it can come with downsides for database caches. This means that you might have traces for which we can’t find a query sample in Database Observability, at least not with sqlcommenter exclusively. We can go beyond sqlcommenter-based matching by using the query statement itself. When we can’t find an exact match, we look for matching query text in the telemetry collected by Alloy. That sounds straightforward, but the same query can look different on each side. OpenTelemetry instrumentation doesn’t always record statements in the same way: depending on the language and instrumentation used, literal values may be preserved or masked, and parameter placeholders can take different forms. Meanwhile, database engines apply their own normalization to the query text that Alloy collects. We account for these differences, along with formatting and comments, to find a match. Even when we can’t point you to the exact execution, you can still explore the samples and historical performance we’ve gathered for that query! This lets us make a meaningful link between your traces and Database Observability, even without sqlcommenter. Start with query text matching, then use sqlcommenter to match trace and span IDs exactly Trace linkage can be a great tool for quickly connecting your database and application telemetry, so we're excited for you to try it today. If your application is already instrumented as an OpenTelemetry SDK that sends traces to Grafana Cloud and you’ve already set up Database Observability , then read our docs about setting up trace linkage to help you get started. If Database Observability has collected a query and the database span already includes its text in db.query.text or the legacy db.statement , chances are trace linkage can already match the span to that query without further application instrumentation. Once you’ve tried query text matching, you can optionally go beyond and match a trace to a specific query execution with the use of sqlcommenter, as this blog discussed extensively. This improves match precision; exact matches remain best-effort because Alloy may not sample that execution. And if you aren't sure where to start, ask Grafana Assistant for help, using natural language.
Grafana Labs đưa OpenTelemetry engine vào Grafana Alloy dưới dạng Public Preview, cho phép thử nghiệm pipeline telemetry dựa trên thành phần OTel trong collector của hãng. Đội observability nên thử trên staging, so sánh tài nguyên và độ tương thích cấu hình trước khi cân nhắc production.
Red Hat Blog vừa công bố thông tin mới với tiêu đề “Announcing Fedora 45”. Thông báo được phát hành ngày Tue, 03 Nov 2026 và liên quan trực tiếp tới các đội vận hành hạ tầng, bảo mật hoặc nền tảng phát triển. Today, the Fedora Project is excited to announce the general availability of Fedora Linux 45, the latest version of the free and open source operating system. Learn more about the new and updated features of Fedora 45 below and don't forget to make sure your system is fully up to date before upgrading from a previous release.General highlightsEnforced RPM signature checking: Fedora 45 switches the default package verification mode in RPM 6.1 to enforcing signature checking by default. Moving to upstream RPM default behavior, packages require a verified signature to install unless explicitly ov
Ưu tiên bối cảnh cho DevOps, SRE, quản trị máy chủ và bảo mật.
Nhìn nhanh việc cần kiểm tra: version, cấu hình, backup, monitoring, rủi ro.
Mỗi bài giữ nguồn gốc để người đọc đối chiếu và đọc sâu hơn.
