标签：#logging

Short answer: record one structured completion event at the request boundary, emit separate events for every asynchronous notification attempt, and join them with a stable notification ID; middleware latency and status code alone cannot reconstruct a delivery failure. For a gaming notification service, the deciding constraint is time. An API response may say that a guild invite was accepted while the actual push attempt occurs seconds later, perhaps on another process. Treating those two facts as one log event produces a comforting dashboard and a weak incident record. The architecture decision is to preserve both boundaries, give each event a precise meaning, and ship them outside the request's success path. This is deliberately an evidence design, not a logging-library choice. Express and Pino can implement the request-side contract in Node.js, but changing a serializer does not repair a missing correlation key or an ambiguous definition of completion. Decision, invariants, and failure boundaries The request completion event answers a narrow question: what did this process observe at its HTTP boundary? It should carry a timestamp, severity, service and environment, request ID, normalized route, method, response status code, and elapsed duration. If the request creates or addresses a notification, add a notification ID that remains stable across the queue and delivery worker. Do not make raw request or response bodies part of the default schema; tokens, chat text, player identifiers, and device data have different retention and access requirements from operational metadata. The delivery attempt event answers a different question: what happened when a worker tried to deliver that notification? Its useful fields include the same notification ID, an attempt number, channel, destination class rather than raw destination, outcome, and a bounded error category. A retry is another attempt event, not an edit to an old record. That append-only shape matters because the inte

A practical checklist for confirming logs are collected, routed, stored, and reviewable Logs are useful only if they are available when the team needs them. In OCI, it is possible to enable service logs, route them through Connector Hub, and store them in Object Storage for later review. Connector Hub is also referenced in some Oracle material as Service Connector Hub. The setup can look simple on the surface. But from a delivery point of view, the important question is not whether the connector was created. The important question is: Can we prove that the logs are being collected, routed, stored, retained, and reviewed when needed? This article is written from a practical validation point of view. It uses a simple example: moving OCI Load Balancer logs from OCI Logging to Object Storage using Connector Hub. Scope note: this is an independent review and validation exercise. It is not a client implementation, and no production environment, customer data, or confidential information is referenced. All names, prefixes, and identifiers below are placeholders. Console labels, defaults, and behaviour can change between releases and regions, so every value should be confirmed in your own tenancy and current Oracle documentation. The goal is not to describe every possible logging design. The goal is to give a clear checklist that helps confirm the flow is working end to end. Why log retention needs validation Enabling a log is not the same as retaining a log. A team may be able to show that logging was switched on. That does not automatically prove that the data still exists for the period being questioned, that it landed where it was supposed to land, or that someone can retrieve and read it when needed. There is one detail worth stating early. There are two retention clocks, not one. Clock What it controls Where it is set Logging retention How long the log data stays inside OCI Logging On the individual log Object Storage lifecycle How long the exported copy stays in the

Short answer: give each browser fetch a request ID, carry it to the backend in a standard HTTP header, and emit that same ID in structured logs on both sides. Keep the pricing decision itself behind a flag with an explicit evaluation ID, so a rollback can be verified instead of guessed. The browser is the first audit surface Rolling out a new pricing rule in an edtech app sounds like a feature-flag task. Operationally, it is a tracing problem with money attached. A student sees a price in the browser, the frontend calls the checkout backend, and the backend evaluates a flag before writing an order. When those events cannot be joined, a rollback turns into a debate about which request produced which price. I've been paged for missed jobs and duplicate deliveries. The same failure pattern appears here: a dashboard says the system is healthy, but the individual request that matters is hard to reconstruct. A request ID doesn't prove that a price was correct. It makes the evidence joinable. The smallest useful contract is straightforward: The browser creates a non-secret request ID for each outbound fetch. The ID travels in X-Request-ID (or the equivalent header chosen by the team). The server validates or replaces malformed values, then logs the accepted value. Every log record for the request includes the ID, route, outcome, and duration. A separate flag-evaluation ID identifies the pricing decision and its rule version. Don't put a user email, token, or price in the request ID. It's a correlation key, not an authorization mechanism or a business record. How should frontend and backend logs correlate a browser fetch request ID? The browser and server need a shared boundary, not a shared logging library. For a JavaScript or Node.js application, the fetch wrapper should generate an ID before sending the request and attach it to the headers. The Node.js service should read that header at the HTTP edge, bind it to request context, and include it in every subsequent log eve

Short answer: compare a hosted app log search service, self-hosted Loki, and Elastic Cloud by the operational boundary each one creates. Low effort, data control, and search depth are different decision axes; the cheapest choice is the one that produces a trustworthy signal without making a small team operate a second product. That last sentence is the decision rule. A low invoice is not a useful bargain if the first incident reveals missing logs, duplicate alerts, or an index that nobody knows how to restore. The incident lesson: a log is not a health signal I've been paged for two different failures: a scheduled import that stopped producing results, and a job that delivered the same result twice. Both incidents had logs. Neither incident was solved by collecting more text. The invariant is simple: observability has to describe both activity and the absence of expected activity. An app log search system can help investigate an import after an alert fires. It cannot, by itself, prove that an import that should have run did not run. That missing event needs a heartbeat, a durable job record, or a metric with an explicit freshness deadline. For an edtech application importing course data, I would record the import name, run identifier, start and finish timestamps, outcome, item count, and an idempotency key. The alert should fire when the expected completion window passes, not whenever somebody happens to search a log stream. Duplicate deliveries should be visible as a repeated idempotency key, not mistaken for two successful business operations. Keep the signal narrow. The log search layer then answers the next question: what happened around the missed or duplicated run? That division keeps noisy search data from becoming the only source of truth for scheduled work. How should a small business compare self-hosted and hosted app log search? Compare the complete operating boundary, not the storage line item. A self-hosted Loki deployment gives the team direct control

Last month I moved my blog off a platform and onto a rented server, and instead of installing WordPress I finished something I had been building for it: Quire Ink , a blog engine that is one process and two SQLite files. No database server, no build pipeline, no cloud account anywhere in the path. bun src/index.ts That line is the whole deployment. Point nginx at the port and you have a blog. The part readers notice Opening a post costs about 114 KB , first visit, nothing cached. Of that, 67 KB is fonts I host myself and the JavaScript is 3.6 to 7.8 KB , written by hand. Third-party requests: zero . No CDN, no font host, no tracker. The numbers hold because the build enforces them. Every bundle has a size cap and the build fails if a feature crosses it, so nothing can quietly start costing every reader a little more forever. And the reading page is where most of the work went: Six palettes in light and dark, and four reading typefaces , all switchable by the reader, not just the owner. Fonts ship with Vietnamese and Central European accents included. Book mode : a fullscreen two-column reader on paper, with a drop cap and a page count. Not a filter over the page, a second typography. A five-ink highlighter . Write ==text== and it renders as an SVG stroke with chisel ends that breaks per line, pigments measured off a photograph of a real pen box. Readers can also keep their own highlights. 1.4 KB, and zero if unused. Math is MathML , drawn by the browser's own layout engine. No script, no stylesheet, no font file, so a post with a formula costs the reader nothing over one without. Code is highlighted on the server , 21 languages, so no highlighter ships to the browser. A fence that names no language gets a timid guess, so program output stays plain. Search answers as you type , a contents rail follows the post, and related posts, reading time and a progress bar are all there. The progress bar and the fade-in are pure CSS. The part I use every day The admin just went

Production-Grade Logging in Spring Boot: A Complete Guide to Logging Levels, Files, JSON Logs, Correlation IDs, and Best Practices Logging is one of the most important parts of a production backend system. When everything works, you may not think much about logs. But when production starts returning 500 errors at 2 AM, a customer reports that an API is failing, or a payment request behaves unexpectedly, logs become one of your most important debugging tools. Poor logging makes production debugging painful. Good logging helps you answer: What happened? When did it happen? Which user triggered it? Which request caused it? Which service handled it? How long did it take? What failed? Why did it fail? What should we investigate next? In this article, we will build a production-grade logging strategy for a Java Spring Boot application . 1. What Does Production-Grade Logging Mean? Production-grade logging is not simply: log . info ( "User created" ); Production logging should be: Structured Searchable Consistent Secure Configurable Environment-aware Correlated across requests Useful during debugging Suitable for monitoring and alerting A good logging architecture might look like this: Spring Boot Application | v Logback | +---- application.log | +---- error.log | +---- audit.log | +---- access.log | v Log Aggregation | +---- ELK +---- Grafana Loki +---- CloudWatch +---- Datadog +---- Splunk The goal is not to log everything. The goal is to log the right information at the right level . 2. Understanding Log Levels Spring Boot uses SLF4J as the logging abstraction and commonly uses Logback as the underlying logging implementation. The most common log levels are: TRACE DEBUG INFO WARN ERROR The order represents increasing severity. TRACE TRACE is the most detailed logging level. Example: log . trace ( "Entering calculateInvoice() with customerId={}" , customerId ); Use TRACE for very detailed diagnostic information. Usually: Production: OFF Development: Sometimes ON Debugging

Very few posts on this blog explain how to do something in software. On the blogs I ran before this one, and killed later, I wrote a lot more of that kind of content, because I needed it more back then. But I noticed that with AI, this need slowly went down for me too. At some point I asked myself why I don't go back to it, and how much sense that would even make. Just Ask Google I used to open Google, type my problem, and somehow find a solution close enough to what I needed. Now the numbers tell a different story. In 2026, less than a third of Google searches end with a click to any website. For the rest, AI Overviews already answer the question, so the user never leaves the search page. On queries where an AI Overview shows up, click rates sometimes drop as low as 17-20%. So which posts still get clicked? Not the "how do I do X" ones. Comparison posts and posts that share real experience get more clicks. The other type gets pulled out by AI and handed straight to the reader, without the blog in between. That's tiring, honestly. My writing gets picked up by AI before it even reaches my site, gets used, and my site gets no traffic from it. But does that actually matter? Is it worth quitting over? What Am I Even Writing? I sat down and went through my old posts, and a pattern showed up. I wasn't writing "how to use X." I was writing what happens when you actually use X in production, and what I learned from it. Turns out I was already doing the right thing for this era, without planning it. The first type is generic reference material. It's already in the docs, repeated in ten other blogs, and AI can summarize it faster than I ever could. The second type is something that happened to me. Which mistake I made, why I made it, how I noticed it. There's no documentation that can summarize that, because that experience only exists in me. Research backs this up too. AI isn't killing traffic, it's redistributing it. Clicks are dropping on generic, unbranded information que

How I shipped structured JSON logging + Prometheus metrics with zero new dependencies I almost added structlog and prometheus_client to my pyproject.toml . Then I read what they actually do. Both libraries are excellent. structlog is the right call when you have a 30-engineer team shipping 50 services. prometheus_client is the right call when you have five teams of consumers scraping different metrics. For a single-author Python project with one process and one user, both are over-engineered. The 80 lines of code I would have pulled in, I can write in 200. The result: zero new runtime dependencies, full control over the output, and a smaller pip install footprint for every user. Here is what I did instead. The minimum useful observability surface A small Python service needs four things, in order of importance: Every log line is one JSON object. (No parsing for downstream tools.) Every request has a trace id. Every log line in that request carries the same trace id. (So you can grep by id and see the whole story.) Every log line goes to stderr. (So journald , Docker, and kubectl logs all see it without any extra configuration.) Every metric is exposed in Prometheus text format at a stable URL. structlog gives you #1, #2, #3 with a lot of flexibility. prometheus_client gives you #4 with a lot of flexibility. Both are about 16 MB of transitive dependencies combined. For a service that runs in a single process and exports maybe 20 metric names, the libraries are doing more work than the project. The 80-line JsonFormatter The custom logging formatter is the simplest part. The whole thing is here: import json import logging from contextvars import ContextVar from datetime import datetime , timezone _trace_id_var : ContextVar [ str | None ] = ContextVar ( " trace_id " , default = None ) class JsonFormatter ( logging . Formatter ): def format ( self , record : logging . LogRecord ) -> str : payload = { " ts " : datetime . now ( tz = timezone . utc ). isoformat (), " level

Request logging: vì sao mỗi log line phải có request id, và structured log cứu debug thế nào khi có sự cố production Request logging không phải là in console.log('got a request') cho vui. Nó là dấu vết duy nhất còn lại khi một request đã đi qua service, đi qua vài downstream, gặp lỗi, và bị đóng socket. Nếu log không có gì để nối lại các dòng thuộc cùng một request — không có requestId , không có traceId — thì log của một service RPS trung bình biến thành một mớ text xen kẽ giữa hàng chục request đồng thời, và câu hỏi "request X đã đi tới đâu, fail ở service nào" trở thành không trả lời được. Structured log (mỗi dòng là một JSON object với field cố định) + một correlation id truyền qua toàn bộ pipeline chính là cái làm log có thể query được, thay vì grep mù. Hai framework Express và Fastify tiếp cận khác nhau: Fastify tích hợp pino sẵn và tự sinh req.id , Express phải tự dán qua pino-http hoặc middleware tay. Nhưng cả hai đều vỡ theo cùng một kiểu khi correlation id bị đứt giữa các service. Cơ chế hoạt động Ba miếng ghép: (1) một structured logger — thường là pino trong ecosystem Node vì nó ghi NDJSON và có async destination, (2) một cơ chế sinh/nhận requestId , (3) một cách propagate id đó qua async work và qua HTTP call sang service khác. pino là JSON logger tối giản: mỗi lời gọi logger.info({...}, 'message') xuất một dòng NDJSON ra một WritableStream (mặc định là stdout). Log level là số ( trace=10, debug=20, info=30, warn=40, error=50, fatal=60 , theo pino docs), và có child logger — logger.child({ reqId }) tạo một logger mới bind sẵn các field, mọi log line từ child đều có reqId mà không phải truyền tay. Với Fastify , chỉ cần logger: true là có pino và request logging tự động — Fastify sinh request.id (mặc định là monotonic counter, đổi được qua option genReqId ) và log một cặp dòng "incoming request" / "request completed" cho mỗi request. Trong handler, request.log là child logger đã bind reqId : import Fastify from ' fastify ' import crypto from ' node:crypto

WAL: vì sao Postgres bắt buộc ghi log trước data file, và lý do pg_wal/ đầy đĩa làm cluster ngừng nhận write WAL (Write-Ahead Log) là cơ chế durability lõi của Postgres: mọi thay đổi đối với heap, index, free-space map, visibility map đều phải được ghi xuống WAL và fsync trước khi data file tương ứng được phép flush ra đĩa . Nguyên tắc này, mô tả trong Postgres docs chương "Reliability and the Write-Ahead Log", là cái cho phép một transaction đã COMMIT thoả ACID-D dù OS crash hoặc mất điện ngay sau đó. Dev gặp WAL trong việc thật không phải vì cú pháp khó: gặp khi pg_wal/ đầy đĩa do một replication slot bị quên dọn, Postgres dừng nhận write với PANIC: could not write to file ... No space left on device , hoặc khi crash recovery sau OOM kéo mười mấy phút làm health check fail và load balancer cắt traffic. Cơ chế hoạt động Postgres không ghi thẳng vào data file mỗi khi có INSERT / UPDATE . Trang 8KB (heap page, index page) sống trong shared_buffers ; mỗi thay đổi tạo ra một WAL record mô tả delta đó (record type, relfilenode, block number, payload), append vào wal_buffers — một vùng shared memory nhỏ trước khi xuống đĩa. Tại thời điểm COMMIT , backend gọi XLogFlush() để write + fsync WAL tới hết byte chứa commit record; chỉ sau khi fsync trả về, Postgres mới ghi commit bit vào pg_xact và reply OK về client. Data page bẩn ở lại trong shared_buffers ; checkpointer sẽ flush chúng ra data file sau, không gắn với từng commit. WAL được tổ chức thành segment file kích thước cố định trong $PGDATA/pg_wal/ , mặc định 16MB mỗi segment (cấu hình lúc initdb --wal-segsize ). Vị trí trong WAL là LSN (Log Sequence Number) — số 64-bit, in dạng XXXX/XXXXXXXX , thực chất là byte offset từ đầu WAL của cluster. LSN tăng đơn điệu và là "đồng hồ" duy nhất Postgres tin cậy cho thứ tự ghi. -- Quan sát LSN tiến lên sau mỗi ghi SELECT pg_current_wal_lsn (); -- vd: 0/1A2B3C40 INSERT INTO t SELECT g FROM generate_series ( 1 , 1000 ) g ; SELECT pg_current_wal_lsn (); -- 0/1A2BE018 SELECT pg_wal_ls

I started a gaming guide blog six weeks ago. Twenty-one articles later, it's getting traffic from Google, I have four affiliate programs set up, and I have never written a single line of code. This is not a "how to make money blogging" post. This is a practical breakdown of the tools, the workflow, and the mistakes I made so you can skip them. The blog is yxgonglue.com. It covers PC and console game guides — GTA VI pre-order comparisons, VPN setups for gaming, cloud gaming platform rankings, extraction shooter loot guides. Niche stuff. The kind of content people search for when they have a specific problem. Here is the stack that runs it. THE STACK WordPress + Kadence Theme Hosted on a standard shared hosting plan. Kadence is a free WordPress theme that loads fast and does not fight you. No page builder. No Elementor. Just the block editor and Kadence blocks for tables and formatting. The biggest lesson here: your theme does not matter as much as your content structure. Pick something lightweight. Stop theme-shopping. Start writing. Yoast SEO The free version. It gives you a red/yellow/green score for each post based on keyphrase density, subheading distribution, link count, and meta length. Is it perfect? No. Is it a useful checklist for someone who does not do SEO for a living? Absolutely. One thing Yoast taught me the hard way: Custom HTML blocks are invisible to the plugin. If you paste your article into a Custom HTML block, Yoast reads zero words, zero links, zero headings. Everything turns red. Use the regular editor. If you need a table, use a table block. Keep it simple. Google Search Console This is where you see what people actually searched before they clicked your article. The gap between what you think people search for and what they actually search for is enormous. Search Console closes that gap. Submit every new post URL manually. It takes ten seconds. Do not wait for Google to discover your site on its own. THE CONTENT WORKFLOW One Article Per Day Tw

Let me confess something a little creepy. I have a habit of peeking at other people's dev posts. Not stealing the writing — relax. I run a tiny read-only job that fetches the public pages on dev.to, Zenn, and Qiita and counts only the boring parts: titles, post times, like counts. Who published what, at what hour, and how far it traveled. Then it tallies the lot. The reason is petty: my own posts weren't landing. The content is already in my hands — so I wanted to know how much the rest, the when and how you publish , actually moves the needle. By the numbers, not by gut. So I counted across three platforms. And the conditions that make a post fly turned out to be roughly mirror images between Japan (Zenn / Qiita) and the English-speaking world (dev.to). Here's the story. First, my most important disclaimer This post is full of numbers, so let me put up a guardrail before any of them. This is correlation, not causation . A result like "weekend posts don't do well" could mean the weekend itself is bad — or it could mean people who post on weekends are just dashing something off on the side. The data can't separate those. Please read it that way. Also, I only keep aggregate numbers I computed myself . I don't store or reuse anyone's article body (read-only GET, count the features, throw the page away). I peek, but only at the overall shape . Nobody gets singled out here. With that out of the way — four findings I enjoyed. 1. The best hour to publish is just your readers' time zone This one came out cleanest. On Qiita , posts published in the morning win (+32pt in the GOOD group). Midday is +14pt. Evening is -32pt, late night -14pt. Zenn likes midday too (+27pt). Late night is -15pt. dev.to is the exact opposite. Late night Japan time scores +7pt — Japanese evening is actually weak. The trick is obvious once you see it. dev.to's readers are English-speaking, mostly US. Late night in Japan is the US working day. Zenn and Qiita readers are in Japan, so the Japanese morni

Logging has a habit of ending up in the places you care about most. It starts as a few lines for visibility. Then those lines appear in request handling, market-data processing, matching loops, telemetry pipelines, and other code where predictable latency matters. At that point, a log statement is no longer just observability. It is work running on the same thread you are trying to keep fast. A line like this can look harmless: LOG_INFO ( logger , "order_id={} price={}" , order_id , price ); The important question is what happens before the caller continues . Does it evaluate expensive arguments? Format text? Copy buffers? Allocate? Contend with other producer threads? Wait for queue space? For many applications, those costs are acceptable. For latency-sensitive systems, they are part of the latency budget . spdlog is one of the best-known C++ logging libraries and a strong general-purpose choice. It is mature, easy to use, and has a broad feature set. Quill was designed for a narrower problem: How little work can a C++ logger leave on the caller thread while still producing rich, human-readable logs? That is the lens for this comparison. The interesting difference is not which library has more features. It is where each library chooses to spend work. At a Glance Area spdlog async Quill User-message formatting Producer thread Backend thread Producer handoff Shared thread-pool queue Per-thread SPSC queue Arguments for runtime-disabled levels Evaluated if the level was not compiled out Skipped by the macro-level runtime check Native synchronous mode Yes No Backend workers Configurable thread pool Single backend worker Primary focus General-purpose flexibility Low producer-side latency These differences do not make one library universally better. They make each library better suited to different workloads. Async Logging Is Not One Design "Async logging" often means "file I/O happens on another thread." That is useful, but it is not enough to describe the cost paid by t

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You open a use case that places an order. Near the top of the constructor, alongside the repositories and the payment gateway, sits a Psr\Log\LoggerInterface . The method body calls $this->logger->info(...) three times. It looks harmless. It is the most common way framework concerns leak back into a domain you spent weeks keeping clean. PSR-3 is a fine standard. Monolog is the default implementation in most PHP projects, and it earns that spot. The problem is not the library. The problem is where you point it. When LoggerInterface is a constructor argument in your application layer, your use case now depends on a package whose surface area you do not control, whose log levels you may not want, and whose context conventions are someone else's. The dependency arrow points the wrong way. What PSR-3 drags in Psr\Log\LoggerInterface is eight level methods plus a generic log() . The level taxonomy comes from RFC 5424 syslog: emergency , alert , critical , error , warning , notice , info , debug . That is a system-administration vocabulary. Your domain does not speak it. When a use case calls $this->logger->warning('payment retry') , you have to ask: is a retry a warning or a notice ? The answer is an infrastructure judgment call wearing a domain costume. The method signature also accepts an arbitrary array $context and a string|Stringable $message with {placeholder} interpolation. None of that is something your application code should be deciding. <?php declare ( strict_types = 1 ); namespace App\Application\Order ; use Psr\Log\LoggerInterface ; final readonly class PlaceOrder { public function __construct ( private OrderRepository $ord