Logging · Monitoring
Logging / Monitoring
What is logging?
- Logging = recording what happened
- Monitoring = real-time watching
- Early problem detection
Once logging and monitoring take hold, the very language used to handle outages changes. A report like 'the service seems off since this morning' becomes 'since 10:12, payment API response time rose from 0.8 to 4.6 seconds and the error rate climbed from 0.3% to 7%.' With meetings that start from numbers instead of guesses, dev, infrastructure, and customer service act while looking at the same screen, and the customer center can give an estimated recovery time instead of 'we're looking into it.' The metric executives watch also shifts to time to detection rather than the number of outages.
In practice, teams distinguish three kinds of data. Logs are records of individual events (a failed order, a denied authentication); metrics are numbers aggregated by the minute (CPU 70%, error rate 2%); and traces show where 3 seconds were spent as a single request passed through five services. Looking at all three together is called observability. Logs are recorded at levels such as DEBUG, INFO, WARN, and ERROR, and alert criteria should be not 'is the server alive?' but 'are customers feeling the impact?' That is why a condition like 'payment error rate above 5% for 5 minutes straight' works. It also pays to set retention periods up front, such as 30 days for detailed logs and 13 months for summary metrics, so you balance cost against traceability by design.
The most common misstep is 'let's just collect everything first.' Storage costs balloon by millions of won a month, and when an outage hits there are so many logs that search breaks down, so people end up logging into servers and running tail commands by hand. Alerts are the same. An alarm that fires 200 times a day goes unopened within three days, and a state where real outage signals are buried in noise is more dangerous than having no alerts at all. There are also plenty of cases where resident registration numbers or card numbers were logged as-is, turning an operational failure into a personal-data breach. Sensitive-data masking rules must be set on day one of logging design, before choosing any tools.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”It has long been a basic practice in system operations, and as cloud and microservice complexity has grown, integrated logging and monitoring (observability) has become essential.
Let's look at a hypothetical case. Company A sells groceries online in the Seoul metropolitan area, with 180 employees and annual revenue of about KRW 90 billion (≈ US$67,335,000). Right before the cutoff for dawn-delivery orders, between 10 and 11 p.m., 40–50 payment-failure inquiries came in every day, yet the dev team's answer was always 'restarting the server fixes it.' Three months passed without finding the cause.
- The CTO stopped digging through logs by logging into servers directly and had a request ID attached to the order, payment, and delivery APIs, with everything collected in one place. His whole instruction was: "Let's see on one screen who got stuck, when, and where."
- Manager Kim, who leads infrastructure, trimmed the dashboard to four panels: error rate, p95 response time, payment queue, and DB connections. Within the first week, a graph showing DB connections hitting the cap of 100 at 10:20 every night jumped out.
- They set up a Slack alert for 'payment error rate above 5% for 5 minutes straight,' and 60 alerts poured in on day one. Only after adjusting the threshold and scope twice, cutting it to 3 a day, did the team start opening them.
- Following the trace data, the team found that a single inventory-lookup query was taking 2.8 seconds. The backend lead added an index and cut it to 0.3 seconds, and also raised the connection pool from 100 to 250.
- Two months later, checkout-failure inquiries fell from 45 a day to 4, and the time to detect an outage dropped from an average of 40 minutes to 3. Recovery time also shrank from 2 hours to 25 minutes, so the support team cut its overnight on-call staff from 2 people to 1.