# log management The process of collecting, aggregating, processing, storing, and retaining log events generated by applications, infrastructure, and services. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## CISA's Logging Reference Architecture for OMB M-26-14: What federal agencies should do next DevFeed: [CISA's Logging Reference Architecture for OMB M-26-14: What federal agencies should do next]() Original publisher: [Read original article]() Author: Woody Walton Published: 2026-09-16T00:00:00Z Content type: article Language: en Sources: [Elastic Blog - Elasticsearch, Kibana, and ELK Stack]() Topics: [cisa](), [Logging](), [cybersecurity and infrastructure security agency](), [log management](), [Architecture & Design](), [implementation](), [audit](), [Security]() Tags: [architecture](), [audit](), [cisa](), [cybersecurity-and-infrastructure-security-agency](), [cybersecurity-open-source-standards-log-management-government](), [government](), [implementation](), [logging](), [logs](), [public-sector](), [security]() ### AI overview This Elastic blog explains CISA's Logging Reference Architecture for OMB M-26-14 and the actions federal civilian executive branch agencies must take. It highlights planning and maturity deadlines, recommends assessing existing capabilities and documenting gaps, and discusses storage tiers, retrieval, immutability, and audit requirements. ### Source excerpt Now that CISA has released its Logging Reference Architecture (LRA) for OMB M-26-14, federal agencies tasked to complete their logging plans. In this blog, we walk you through the most important aspects of the LRA guidance. ## Transform and route security logs to Microsoft Sentinel tables using Observability Pipelines DevFeed: [Transform and route security logs to Microsoft Sentinel tables using Observability Pipelines]() Original publisher: [Read original article]() Author: Zara Boddula; Danielle Park Published: 2026-09-16T00:00:00Z Content type: tutorial Language: en Sources: [Datadog | The Monitor blog]() Topics: [observability pipelines](), [SIEM, Security](), [Security](), [log management](), [Microsoft]() Tags: [azure](), [cisco-meraki](), [devsecops](), [fortigate](), [log-management](), [logs](), [observability-pipelines](), [pipelines](), [security](), [siem](), [telemetry](), [threat-detection]() ### AI overview Datadog's Observability Pipelines Packs transform firewall, VPN, and network detection logs into Microsoft Sentinel table schemas before ingestion. The post describes Packs for Palo Alto Networks, Fortinet, Cisco ASA, Cisco Meraki, and ExtraHop, including filtering and noise reduction to help control Sentinel ingest volume while retaining visibility. ### Source excerpt Learn how Observability Pipelines Packs map security logs to Microsoft Sentinel schemas and help control downstream ingest volume. ## AuthKit vs Better Auth for B2B SaaS DevFeed: [AuthKit vs Better Auth for B2B SaaS]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-14T00:00:00Z Content type: comparison Language: en Sources: [WorkOS Blog]() Topics: [Software as a service](), [Single sign-on (SSO)](), [Security](), [log management](), [threat detection](), [Frameworks](), [MFA](), [Passkeys]() Tags: [auth](), [comparison](), [enterprise](), [logs](), [mfa](), [saas](), [security](), [threat-detection](), [vercel]() ### AI overview This comparison examines AuthKit and Better Auth as platforms for B2B SaaS products selling to enterprise IT buyers. It argues that both now provide core capabilities such as SSO, SCIM, and audit logs, so the meaningful differences are provider coverage, where user lifecycle management begins, and contractual responsibility. The article also describes Better Auth's hosted infrastructure, dashboard, SIEM drain, self-service provisioning, and threat detection features, while noting its convergence with AuthKit on enterprise requirements. ### Source excerpt Both ship SSO, SCIM and audit logs now. The comparison that decides enterprise deals has moved to the long tail: provider coverage, where user lifecycle actually starts, and who is contractually on the hook. ## Customize Amazon API Gateway destinations for execution logs DevFeed: [Customize Amazon API Gateway destinations for execution logs]() Original publisher: [Read original article]() Author: Giedrius Praspaliauskas Published: 2026-09-09T22:35:42Z Content type: tutorial Language: en Sources: [AWS Compute Blog]() Topics: [Amazon API Gateway](), [Amazon CloudWatch Logs](), [log management](), [Amazon S3](), [SIEM, Security, Observability]() Tags: [amazon-api-gateway](), [amazon-cloudwatch-logs](), [amazon-s3](), [announcements](), [intermediate-200](), [logs](), [observability](), [rest-api]() ### AI overview This tutorial explains how to route Amazon API Gateway REST API execution logs to CloudWatch Logs, Amazon S3, or Amazon Data Firehose. It contrasts execution logs with access logs and describes their use for diagnosing authorization, validation, integration, mapping, and error-handling behavior. ### Source excerpt Amazon API Gateway execution logs help you trace request processing step by step through your REST API stages. They capture authorization results, integration latency, mapping template output, and error details that are otherwise invisible at the API surface. When a production request fails in a way the access log cannot explain, the execution log is [...] ## MCP Logging in Spring AI DevFeed: [MCP Logging in Spring AI]() Original publisher: [Read original article]() Author: Burak Gökmen Published: 2026-09-06T23:19:21Z Content type: tutorial Language: en Sources: [Baeldung]() Topics: [Model Context Protocol](), [log management](), [AI Development](), [Remote Procedure Call (RPC)](), [telemetry]() Tags: [logging](), [mcp](), [mcp-server](), [opentelemetry](), [popular](), [rpc](), [spring](), [spring-ai](), [spring-ai-mcp-popular](), [spring-boot](), [tutorial]() ### AI overview A tutorial on MCP logging in Spring AI, covering server-to-client log notifications, client-controlled severity levels, and migration guidance following the feature's deprecation. ### Source excerpt Learn about MCP logging in Spring AI, both in an MCP server and a client. The post MCP Logging in Spring AI first appeared on Baeldung. ## Quiz: Understanding the Python Traceback DevFeed: [Quiz: Understanding the Python Traceback]() Original publisher: [Read original article]() Author: Real Python Published: 2026-09-06T12:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Python](), [Exception](), [log management]() Tags: [examples](), [exception](), [logging](), [python]() ### AI overview An interactive 12-question quiz that tests understanding of Python tracebacks, including how to read them from the bottom up, interpret their parts, recognize common exceptions, and log tracebacks while handling exceptions. ### Source excerpt Check your understanding of Python tracebacks. Practice reading the error message line, recognizing common exceptions, and logging a traceback. ## Astro 7.3 DevFeed: [Astro 7.3]() Original publisher: [Read original article]() Author: Matthew Phillips Published: 2026-09-03T00:00:00Z Content type: release Language: en Sources: [The Astro Blog]() Topics: [Server](), [log management](), [Caching](), [Command-line interface]() Tags: [astro](), [cache](), [cli](), [cloudflare](), [logging](), [release](), [servers]() ### AI overview Astro 7.3 adds support for multiple preview servers, routes runtime logging to custom image services and cache providers, and introduces a Cloudflare helper for custom worker entrypoints. ### Source excerpt Astro 7.3 adds an --ignore-lock flag for astro preview, passes Astro's runtime logger into custom image services and cache providers, and ships a finalize() helper for Cloudflare custom worker entrypoints. ## Respond to security threats faster with Tines and Observability Pipelines DevFeed: [Respond to security threats faster with Tines and Observability Pipelines]() Original publisher: [Read original article]() Author: Zara Boddula Published: 2026-08-31T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [Security](), [observability](), [Automation](), [log management](), [Orchestration](), [API]() Tags: [accelerate](), [api](), [automation](), [devsecops](), [logs](), [observability-pipelines](), [orchestration](), [real-time](), [reduce](), [security](), [workflows]() ### AI overview Tines and Datadog Observability Pipelines automate security-log processing by standardizing and routing logs, updating pipelines through APIs and reference tables, and applying current context in real time. The integration helps reduce alert noise, identify access-control gaps and suspicious activity, and accelerate threat investigations. ### Source excerpt Learn how Tines workflows can update Datadog Observability Pipelines to prioritize threats, reduce alert noise, and accelerate investigations. ## How to start the AI-accelerated defense DevFeed: [How to start the AI-accelerated defense]() Original publisher: [Read original article]() Author: info@1password.com (Wade Wells) Published: 2026-08-27T00:00:00Z Content type: article Language: en Sources: [Blog on 1Password Blog]() Topics: [Artificial Intelligence](), [Detection engineering](), [Prompt Engineering](), [Large Language Model](), [log management](), [Security]() Tags: [ai](), [ai-adoption](), [documentation](), [engineering](), [llm](), [logging](), [onboarding](), [security](), [validation](), [workflow]() ### AI overview This article explains how a security team began adopting AI for detection engineering by supplying the documentation and workflow context that AI systems lack. It covers an AI Detection Engineering stack involving logging pipelines, log onboarding, detection validation, threat modeling, and detection logic, and shows why better context produces more reliable results than relying on prompts or increasingly powerful models. ### Source excerpt Early on in the AI adoption boom, I gained a reputation for just throwing everything at it to see what would stick. That wasn't the most effective strategy, and my token usage was crazy high. There are a ton of talks and posts on all the cool ways you can use AI for detection engineering, but I didn't see any that showed you where to begin. So, this isn't another blog about why you need to use AI in your defensive workflows. It seems most people understand why we need that. My focus is to show how our team got started and realized that providing AI with the necessary context is key to detection engineering successfully adopting AI. This is not just about building detection logic, but that is one of the goals. This foundation helps create the AI Detection Engineering stack: logging pipelines, log onboarding, detection validation, threat modeling, and more. An LLM does not know your stack, so out of the box it has limited value in a security review. In our experience, reliable results depend less on the fanciest model and more on the documentation and context around the workflow. If a human reads your log inventory and still has to ask three people what the ingestion method is, your agent does too. Why cold prompting fails When we first started using AI tooling, we realized prompts alone could get stuff done, but the output was inconsistent. Fields were missed, assumptions were made, and some detection logic was wrong. We saw it write queries that would not work in our SIEM. Usually these were around wildcards. The playbooks it wrote were generic, the tuning was poor, and some detections were just bad. With enough re-prompting, the output would improve, but it always required some massaging. The effort invested in the agent inputs had a noticeable impact on the quality of the outputs. TL;DR: garbage in, garbage out. Where our context came from At the start, this was just internal documentation we built to make our own lives easier. It started with new-hire materials a ## nixos-telemetry: A NixOS flake for opt-in observability pipelines DevFeed: [nixos-telemetry: A NixOS flake for opt-in observability pipelines]() Original publisher: [Read original article]() Author: palo Published: 2026-08-23T08:27:36Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [telemetry](), [OpenTelemetry](), [Tooling](), [log management](), [Prometheus](), [Grafana](), [Grafana Alloy]() Tags: [announcements](), [collector](), [config](), [grafana](), [grafana-alloy](), [loki](), [opentelemetry](), [prometheus](), [telemetry]() ### AI overview A discussion introduces nixos-telemetry, a NixOS flake that uses an OpenTelemetry collector to connect opt-in scrapers, storage, and visualization components. It supports local stacks, remote forwarding, and fan-out to multiple sinks through a unified option tree. ### Source excerpt Hi everyone, I'd like to share nixos-telemetry, a NixOS flake that makes setting up observability in your infrastructure easy. An OpenTelemetry collector sits at the center of each machine. Scrapers, storage, and visualization are all opt-in. You enable what you need; the collector wires the pipeline together automatically. Why? Wiring up telemetry in NixOS today means gluing together Telegraf, Prometheus, Loki, Grafana, Alloy, each with its own config format, ports, and inter-service dependencies. nixos-telemetry puts all of that behind a single telemetry.* option tree: Turn on the system with telemetry.enable = true. Every app is opt-in. Nothing starts that you didn't ask for. The collector starts automatically once a complete pipeline exists, a matching source and sink for the same signal type. No sink? It waits. Forward to a remote collector, run a full local stack, or both. Fan-out to multiple sinks is supported. What it looks like Full local stack on one machine: { telemetry.enable = true; telemetry.telegraf.enable = true; # host metrics telemetry.alloy.enable = true; # journald logs telemetry.prometheus.enable = true; # metrics storage telemetry.loki.enable = true; # logs storage telemetry.grafana.enable = true; # visualization (datasources auto-provisioned) } Forward to a remote collector: # machine 1 { telemetry.enable = true; telemetry.telegraf.enable = true; telemetry.opentelemetry.exporter.endpoints.remote = "100.64.0.1:4317"; } # machine 2 { telemetry.enable = true; telemetry.opentelemetry.receiver.endpoint = "0.0.0.0:4317"; } Full option reference: OPTIONS.md Thanks! Regarding Discourse LLM Policy : I must disclose that substantial parts of this project are llm generated. And because I coppied parts of the README in this post, substantial parts of this announcmement too. 27 posts - 7 participants Read full topic ## AWS Network Firewall now supports rule hit count DevFeed: [AWS Network Firewall now supports rule hit count]() Original publisher: [Read original article]() Author: Preetkumar Shah Published: 2026-08-20T18:40:20Z Content type: article Language: en Sources: [AWS Security Blog]() Topics: [Firewall](), [Amazon Web Services](), [Amazon CloudWatch Logs](), [Network](), [Security](), [Amazon S3](), [log management](), [Incident response]() Tags: [amazon-cloudwatch](), [amazon-cloudwatch-logs](), [amazon-s3](), [announcements](), [aws](), [aws-network-firewall](), [compliance](), [firewall](), [incident](), [incident-response](), [intermediate-200](), [logs](), [network](), [s3](), [security](), [security-blog](), [security-identity-compliance](), [storage]() ### AI overview AWS Network Firewall now provides rule hit counts for stateful rules, using alert-log data to show how often rules match network traffic. The feature helps teams identify unused rules, support incident response, and demonstrate security-control effectiveness for compliance. ### Source excerpt As firewall rule sets grow in complexity, security teams face a common challenge: manual log analysis is used to determine which rules are actively matching traffic and which are consuming capacity without being triggered. This lack of visibility creates operational and compliance gaps. Organizations with governance policies that require removal of dormant rules after a [...] ## Shopify powers observability for global-scale commerce with ClickHouse DevFeed: [Shopify powers observability for global-scale commerce with ClickHouse]() Original publisher: [Read original article]() Author: ClickHouse Published: 2026-08-20T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [observability](), [Shopify](), [telemetry](), [data](), [log management](), [Databases](), [Kubernetes](), [Cloud](), [Go](), [Ruby](), [TypeScript]() Tags: [clickhouse](), [cloud](), [data](), [databases](), [events](), [go](), [infrastructure](), [kubernetes](), [logs](), [metrics](), [observability](), [ruby](), [scale](), [shopify](), [telemetry](), [traces](), [transactions](), [typescript]() ### AI overview Shopify built Observe, a unified observability platform on ClickHouse, to consolidate metrics, logs, traces, and exceptions. The platform delivers up to 30x faster queries, ingests about 100 million events per second at peak, and keeps telemetry queryable in under a minute while improving cost predictability. ### Source excerpt Shopify unified global-scale observability on ClickHouse, achieving up to 30x faster queries while ingesting 100 million events per second at peak. ## What's New with Monitoring in PostgreSQL 19 DevFeed: [What's New with Monitoring in PostgreSQL 19]() Original publisher: [Read original article]() Author: Gülçin Yıldırım Jelínek Published: 2026-08-18T14:31:36Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [Monitoring](), [PostgreSQL](), [observability](), [log management](), [Deadlock]() Tags: [blog](), [logging](), [logs](), [monitoring](), [observability](), [postgres](), [postgresql]() ### AI overview An overview of PostgreSQL 19 monitoring and observability improvements, including default lock-contention logging, per-process log verbosity, and separate logging controls for autovacuum ANALYZE operations. The article notes that PostgreSQL 19 is still in beta and that details may change before the final release. ### Source excerpt What's New with Monitoring in PostgreSQL 19 ## Query Neon backend logs DevFeed: [Query Neon backend logs]() Original publisher: [Read original article]() Author: Andre Landgraf Published: 2026-08-18T12:00:00Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Back end](), [observability](), [log management](), [Command-line interface](), [MCP Server](), [Serverless](), [Server](), [Node.js](), [Amazon S3](), [SDKs]() Tags: [api](), [backend](), [cli](), [logs](), [mcp-server](), [node](), [observability](), [product](), [s3](), [tool]() ### AI overview Neon adds branch-scoped access to backend logs from Neon Functions and Object Storage outside the Console. The logs can be queried through the CLI, MCP server, Logs API, SDK, or Loki endpoints, with filters and raw LogQL support. ### Source excerpt We keep expanding our backend observability - the most recent addition: you can now query backend logs outside the Console! neon logs reads what Neon Functions and Object Storage emit on a branch, with filters for source, severity, and message text. ## Observability best practices for Lambda durable functions DevFeed: [Observability best practices for Lambda durable functions]() Original publisher: [Read original article]() Author: D Surya Sai Published: 2026-08-14T12:49:49Z Content type: tutorial Language: en Sources: [AWS Compute Blog]() Topics: [AWS Lambda](), [observability](), [Monitoring](), [log management](), [tracing](), [Instrumentation](), [debugging](), [Amazon API Gateway](), [stripe](), [Serverless]() Tags: [advanced-300](), [amazon-api-gateway](), [aws](), [aws-lambda](), [debugging](), [instrumentation](), [logging](), [metrics](), [monitoring](), [observability](), [payment](), [payment-processing](), [payments](), [serverless](), [technical-how-to](), [tracing]() ### AI overview This tutorial presents an observability pattern for AWS Lambda durable functions using a Stripe payment-processing workflow. It covers durable-function metrics, custom business metrics, alarms, structured logging, AWS X-Ray tracing, instrumentation across suspension boundaries, and end-to-end debugging of callback timeouts. ### Source excerpt Learn observability best practices for AWS Lambda durable functions, including CloudWatch metrics, custom alarms, structured logging, and X-Ray tracing for debugging callback timeouts end-to-end. ## ClickStack and Hud bring runtime intelligence to AI-powered development DevFeed: [ClickStack and Hud bring runtime intelligence to AI-powered development]() Original publisher: [Read original article]() Author: May Walter, Hud.io Published: 2026-08-13T12:53:04Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [AI-assisted coding](), [observability](), [Model Context Protocol](), [OpenTelemetry](), [telemetry](), [Artificial Intelligence](), [Instrumentation](), [Deployment](), [Incident response](), [distributed-systems](), [clickhouse](), [log management]() Tags: [agents](), [ai](), [clickhouse](), [code](), [coding](), [deployment](), [developers](), [development](), [distributed-systems](), [engineering](), [incident](), [incident-response](), [infrastructure](), [instrumentation](), [integration](), [mcp](), [metrics](), [monitoring](), [observability](), [open]() ### AI overview ClickHouse and Hud announce an integration that combines ClickStack service-level observability with Hud's function-level runtime context for AI-assisted software development. Shared trace IDs and MCP servers help coding agents assess risky changes before deployment, monitor releases, and investigate incidents using production context. ### Source excerpt ClickStack and Hud now share trace IDs, pairing service-level observability with function-level runtime forensics so coding agents can assess risky changes before they ship, catch regressions right after deploy, and fix them with real production context. ## Centralize cross-account Amazon ECS telemetry with an ADOT gateway DevFeed: [Centralize cross-account Amazon ECS telemetry with an ADOT gateway]() Original publisher: [Read original article]() Author: Rahul Kumar Published: 2026-08-06T16:13:46Z Content type: tutorial Language: en Sources: [Containers]() Topics: [Amazon Elastic Container Service](), [telemetry](), [OpenTelemetry](), [SIEM, Security, Observability](), [Amazon CloudWatch](), [Amazon Web Services](), [Windows](), [.NET Framework](), [Traces](), [log management](), [Amazon Elastic Kubernetes Service]() Tags: [amazon-cloudwatch](), [amazon-eks](), [amazon-elastic-container-service](), [amazon-elastic-kubernetes-service](), [aws](), [intermediate-200](), [logs](), [metrics](), [net-framework](), [observability](), [opentelemetry](), [technical-how-to](), [telemetry](), [traces](), [windows]() ### AI overview This tutorial presents a centralized AWS Distro for OpenTelemetry gateway for collecting telemetry from Amazon ECS workloads across multiple AWS accounts. It replaces per-task sidecars, supports Windows .NET Framework tasks, receives OTLP over private connectivity, and exports traces to AWS X-Ray plus metrics and logs to Amazon CloudWatch. ### Source excerpt Running an OpenTelemetry collector as a sidecar in every Amazon ECS task does not scale across a multi-account estate, and it cannot run at all on Windows. Learn how to replace per-task sidecars with a single centralized ADOT gateway that ingests OTLP from workloads across accounts and exports traces to AWS X-Ray and metrics and logs to Amazon CloudWatch. ## osmo-remsim - osmo-remsim 1.2.0 released DevFeed: [osmo-remsim - osmo-remsim 1.2.0 released]() Original publisher: [Read original article]() Author: lynxis Published: 2026-08-05T16:54:21Z Content type: release Language: en Sources: [Open Source Mobile Communications: News]() Topics: [bug](), [Concurrency](), [log management]() Tags: [bug](), [bug-fixes](), [client](), [crash](), [csv](), [deadlock](), [debug](), [issue](), [logging](), [mutex](), [tracker]() ### AI overview osmo-remsim 1.2.0 is a release containing stability and bug fixes across bankd, remsim-client, remsim-bankd, and related ASN.1 and logging code. The fixes address invalid CSV and TPDU handling, crashes, memory leaks, race conditions, signal handling, slot mapping, byte order, and a logging mutex deadlock. ### Source excerpt 1.2.0 contains stability fixes and bug fixes. [ Alexander Couzens ] * bankd: csv: fix crash on invalid lines * bankd: csv: fail on invalid csv lines * rspro_server: don't access the msg on error cases * rspro_util: asn1 decode: fix memleak when decoding fails * asn1: ber_decoder: disable stack size check on ctx = NULL * asn1: move asn_debug into librspro * Remove unconditional assignment of asn_debug = 0 * rspro_server: use correct byte order in log message "Bankd IP/Port changed to : [ Andreas Eversberg ] * Fix: Remove slot mapping at bankd when client disconnects * Fix: Prevent race conditions when accessing slotmap in bankd * Fix: Prevent bankd from exiting upon SIGPIPE * Fix unhandled (un)mapping events [ Harald Welte ] * remsim-client: Don't attempt to pass on illegal TPDU length * remsim-bankd: Don't pass on illegal TPDUs of illegal length * bankd: Avoid osmocom logging mutex deadlock in signal handling ## Extending Amazon ECS Express Mode to Build an Optimal Container Environment DevFeed: [Extending Amazon ECS Express Mode to Build an Optimal Container Environment]() Original publisher: [Read original article]() Author: Koichiro Okimura Published: 2026-08-04T15:57:59Z Content type: article Language: en Sources: [Containers]() Topics: [Amazon Elastic Container Service](), [Containers](), [Amazon Web Services](), [Deployment](), [log management](), [configuration](), [networking](), [Security]() Tags: [amazon-elastic-container-service](), [aws](), [containers](), [deployment](), [how-to](), [intermediate-200](), [logging](), [logs](), [network](), [security](), [technical-how-to]() ### AI overview This AWS article explains how to extend Amazon ECS Express Mode beyond its default container deployment configuration. It presents hands-on examples for enabling ECS Exec, adding scheduled scaling, and routing logs through a FireLens sidecar with a custom task definition. ### Source excerpt Amazon ECS Express Mode gives you load balancing, scaling, logging, and networking out of the box. Learn how to extend an Express Mode service beyond its defaults with three hands-on examples: turning on ECS Exec, adding a scheduled scaling policy, and adding a FireLens log router as a sidecar container. ## How Jump Trading uses ClickHouse with Iceberg for analytics DevFeed: [How Jump Trading uses ClickHouse with Iceberg for analytics]() Original publisher: [Read original article]() Author: ClickHouse Published: 2026-07-30T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Apache Iceberg](), [log management](), [data](), [Latency](), [Open Source](), [real-time](), [Database]() Tags: [analytics](), [apache](), [apache-iceberg](), [business](), [clickhouse](), [data](), [database](), [industry](), [latency](), [logging](), [logs](), [low-latency](), [observability](), [open](), [open-source](), [performance](), [real-time](), [scale](), [technology](), [trading]() ### AI overview Jump Trading uses a self-managed ClickHouse platform to capture and analyze petabyte-scale financial trading logs. The platform ingests hundreds of terabytes daily with a sub-20-second p99 and supports real-time analytics across hundreds of billions of events. To support large-scale batch reporting and research without affecting the real-time cluster, Jump added a parallel Apache Iceberg pipeline. ### Source excerpt Jump Trading captures petabyte-scale financial trading logs on a self-managed ClickHouse platform, where zero data loss and low latency are critical requirements. ## Proper logging in PHP with PSR-3 DevFeed: [Proper logging in PHP with PSR-3]() Original publisher: [Read original article]() Published: 2026-07-28T00:00:00Z Content type: article Language: en Sources: [Marco Pivetta]() Topics: [PHP](), [Logging](), [Exception](), [log management](), [Monitoring]() Tags: [article](), [code](), [errors](), [exception](), [how-to](), [logging](), [monitoring](), [php]() ### AI overview This article explains practical PHP logging with PSR-3. It focuses on passing exceptions through the logger context, allowing the logger to render exception details, defining exception types for business-specific failures, and logging enough information to understand software behavior in production. It also warns that logging and exceptions can impose CPU, memory, and I/O overhead. ### Source excerpt Who is this article for? This post is for people that do day-by-day busywork coding, and for team leads that want to direct their peers towards better logging practices. Note that this article comes from my regular need to present these exact points to different people, multiple times a year, in multiple teams, in multiple companies. Also, we will not talk about how to configure a PSR-3 logger, but rather how to use one. Handling errors properly Error/exception handling is the main use-case for logging. When logging exceptions, please pass the Throwable instance to the 'exception' context key. try { // logic here } catch (SomeException $failed) { $this->logger->error('Something went wrong', [ 'exception' => $failed, ]); } Avoid cluttering the logger call with data deriving from the exception: it's not the logger call-site's job, and you are just repeating work. I often see unnecessary code like: try { // logic here } catch (SomeException $failed) { $this->logger->error('Something went wrong', [ // first mistake: we forgot 'exception' 'previous' => $failed->getPrevious(), // let the logger do this! 'line' => $failed->getLine(), // already part of the stack trace 'error' => $failed->getMessage(), // also always rendered 'error_type' => $failed::class, // done by the logger, usually ]); } The logger itself must instead be configured (and usually already is configured) to render: the exception ::class the exception message and code (codes are not really relevant any more, in this century) the stack trace previous exceptions additional exception fields Your responsibility is to instead pass context information that the logger can't infer on its own. What if my code fails gracefully, and does not raise an exception? if (is_wrong($something)) { $this->logger->warn('Something went wrong', ['something' => $something]); } For business-specific failures that deserve a type, we can upcast them to a Throwable anyway: if (is_wrong($something)) { $this->logger->warn('Something wen ## How to add Datadog logging to a Webflow Cloud app that already uses Sentry DevFeed: [How to add Datadog logging to a Webflow Cloud app that already uses Sentry]() Original publisher: [Read original article]() Author: Ismail Ajagbe Published: 2026-07-26T00:00:00Z Content type: tutorial Language: en Sources: [Webflow Blog]() Topics: [webflow](), [Cloudflare Workers](), [log management](), [Next.js](), [error tracking](), [observability](), [API](), [Node.js]() Tags: [cloudflare-workers](), [development](), [error-tracking](), [guides](), [how-to](), [http](), [logs](), [next-js](), [node-js](), [observability](), [tools](), [webflow]() ### AI overview Guide to adding Datadog structured logging to a Webflow Cloud Next.js app that already uses Sentry. It explains how Sentry captures exceptions and stack traces while Datadog collects operational logs through its HTTP log intake API, since the Datadog APM SDK does not run on Cloudflare Workers. ### Source excerpt Add Datadog log collection to a Webflow Cloud app that already reports to Sentry, using a fetch-based logger utility in your Route Handlers. ## Recover the Ceph Monitor Store Using OSDs DevFeed: [Recover the Ceph Monitor Store Using OSDs]() Original publisher: [Read original article]() Author: Eugen Block, crossposted by Anthony D'Atri Published: 2026-07-04T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [ceph](), [monitor](), [Script](), [Containers](), [log management]() Tags: [blog](), [blog-post](), [ceph](), [containers](), [en-article](), [en-blog-post](), [how-to](), [logging](), [logs](), [mon](), [monitor](), [recovery]() ### AI overview This blog post presents a general procedure for recovering a failed Ceph Monitor store by collecting osdmaps from existing OSDs, with additional considerations for cephadm-managed container deployments. It automates osdmap collection and basic logging while leaving the store rebuild and client authentication steps for careful manual inspection. The procedure applies only to non-encrypted OSDs, and the article emphasizes the importance of backing up dmcrypt/LUKS keys and reviewing host logs. ### Source excerpt Introduction ¶ A few weeks ago I helped a Ceph user to recover his broken cluster (see this thread). Basically, after his Monitors stopped working he re-deployed a new cluster with the same Ceph FSID and attached the existing OSDs to the re-deployed hosts. But it's not that easy to re-activate those OSDs because the new Monitors don't have the old osdmap, hence they don't know anything about the existing OSDs. So how did we fix that? This scenario can be considered a total Monitor store failure. There's a documented procedure in the upstream docs, unfortunately it's written for non-cephadm clusters and doesn't contain many details about subsequent steps. When Ceph daemons run within containers there are more things to consider. So I decided to write this blog post and add some more details to the procedure, targeting mainly clusters managed by cephadm. But the recovery procedure doesn't specifically require cephadm-specific commands, so it can be considered as a general guideline how to recover from a Monitor store loss, just with some extra details about cephadm deployments. This procedure only works for non-encrypted OSDs. If you are using dmcrypt (LUKS) OSDs, make sure you have a backup of the keys, otherwise your data is lost forever! But there is some development, a user in Slack pointed me to this PR which adds a backup mechanism for Monitors, probably available in the upcoming Umbrella release. Note that the PR also contains this statement: Monitor backups complement, but do not replace, the existing Monitor recovery procedures The procedure covered by said docs is already written in script form, so I used that as a template and extended it for cephadm usage and included some very basic logging. It collects the osdmaps from all OSDs and contains the necessary considerations regarding containers. I decided to automate only the osdmap collection, not all required steps of the store rebuild procedure (e. g. Monitor store rebuild, client auth, etc.) because the r ## Preparing for OMB M-26-14: How Datadog supports federal logging maturity DevFeed: [Preparing for OMB M-26-14: How Datadog supports federal logging maturity]() Original publisher: [Read original article]() Author: Chris Leffler; Sophie Wang Published: 2026-06-29T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [SIEM, Security, Observability](), [log management](), [Monitoring](), [threat detection](), [incident](), [Incident response](), [observability](), [Security](), [Security Operations Center](), [Resilience](), [Cybersecurity]() Tags: [bits-ai](), [cloud-siem](), [compliance](), [cybersecurity](), [fedramp](), [govcloud](), [incident-response](), [log-management](), [logging](), [monitoring](), [observability](), [resilience](), [security](), [security-operations-center](), [soc](), [systems](), [telemetry](), [threat-detection](), [workflow-automation]() ### AI overview This article explains how OMB Memorandum M-26-14 changes federal logging guidance from prescriptive requirements to a risk- and maturity-based model. It describes continuous event monitoring and threat hunting, investigation, response, and forensics, including centralized security telemetry, visibility across IT, OT, and IoT environments, threat detection, searchable and retrievable logs, cross-source correlation, incident response, and forensic analysis. It also presents Datadog as a unified observability and security platform for helping agencies meet these requirements. ### Source excerpt Learn how Datadog helps federal agencies prepare for OMB M-26-14 by providing centralized telemetry data, threat detection, and automated incident response. [Next page]()