Look back to the basic tool: Logging (Proofing Software Behaviors and Troubleshooting)

Agenda:

Failure Problem
Anti-failure tools
System logging
Logging design
Logging Consideration
Effective Logging
Sum up
Q&A session

Transcript

1. LOGGING Proofing Software Behaviors and Troubleshooting @Egit Look back to the basic tool:
2. Agenda • Failure Problem • Anti-failure tools • System logging • Logging design • Logging Consideration • Sum up • Q&A session
3. Failure Problem?
5. • No one get alert 🚨 • No one noticed 🚥 • No auto recover ⛑ • Hard to rescue 🧯
6. Anti-failure tools?
7. Anti-failure tools? System logging ?
8. ? Anti-failure tools? Metrics, Monitoring, Log ? Paradox
9. Anti-failure tools? Metrics, Monitoring, Log Record and evaluate Key Performance Indicator (KPI) Score, time, rates, count, availability, ...
10. Anti-failure tools? Metrics, Monitoring, Log Aggregate and analyze For SLA. Fire alerts or call automated solutions. Track Stack, business needs, focus, insight, reporting
11. ? Anti-failure tools? Metrics, Monitoring, Log ? Paradox
15. • Is production code is expected on right way? 🏞 • Your code, your responsibility 󰣤 • When your code at failure state?🔥 • What your reaction?
19. Logging Design? What’s that!
20. Logging Design Why? • good logging architecture, save the day during a production issue • The use of logging is vital to both developers and operators
21. Logging Design Why? • finding exceptions like finding a needle in a haystack. • where relevant information about the state • complex & distributed == difficult to understand & fix • More logs make us comfortable, give us observability.
22. Logging Design Why? • Excessive logging can affect system performance — and add cost to store petabytes of log files.
23. Logging Consideration
24. Efficiency Too much logs = noise, too less = blank Policy Customer privacy, secret data
25. Log⎯⎯⎯⎯Throw Log for internal investigation, Throw for customer insight Performance runOnNonBlockingFlow, don’t logging other logs, crash when logging, productivity
26. Effective Logging • Structured formatting • Think of how to make searching ultra-easy • Sharing with external services • Upgrade the goals and best practice
27. • Switchable severity level • Configurable content (e.g. : logging.config) : Or data, privacy with few or without code-changes • Logging big content: Without effort, complex rule, memory footprint, Performance culprit. • Deadlock & defect after logging-changes • Log freshness: old logs may misleading and not relevant • Dynamic Log
28. Static vs Dynamic Log Should you logs every single line of “Hello World” program?
29. Log Content with Contextual data • Severity (fatal, error, warning; standard RFC-4524) • Transaction (stepN, trackN, commit, abort, check-point) • Flow (time, uuid, audit-trail) • Resource (content, parameter, cpu, memory, storage, net)
30. Writing Tips: • What should the severity level be (verbose, debug, information, warning, error, or fatal)? • Where exactly should that line go? At the beginning of the method? At the end? In the "catch" of a "try/catch" block? • Exactly what information should I log?
31. log Sum up, as can be seen
32. log
33. When you locate a problem, think how you can detect it automatically next time 󰥄
34. Developers should work closely with operators (devops) in order to find a good balance of logging verbosity and observability. 🍻
35. Links • https://en.wikipedia.org/wiki/Instrumentation_(computer_programming) • https://en.wikipedia.org/wiki/Aspect-oriented_programminghttps://www.appdynamics. com/resources/reports/gartner-magic-quadrant-apm • https://www.loggly.com/blog/30-best-practices-logging-scale/ • https://geshan.com.np/blog/2015/08/importance-of-logging-in-your-applications/ • https://logging.apache.org/log4j/2.x/index.html • https://www.elastic.co/blog/elastic-security-recognized-in-gartner-magic-quadrant-for- siem
36. Thank you Any Q&A ? 💬