강의 내용에서 사용자 요청, 응답에 관한 부분은 trace로그로 보관한다고 들었습니다. 또한 로그 레벨을 나누는 이유가 보기 편하라는 이유를 들었는데요 보통 개발환경에서 로그레벨을 파일별로 나누나요?app-trace.logapp-info.logapp-error.log이런식으로 나누고 trace로그를 7일만 보관할 경우 app-trace.log가 7일이 지나면 삭제한다는 방식으로 파일을 나눠서 보관하는지 궁금합니다. 추가로,다른 질문에 app.log, security.log 이런식으로 파일을 분할하지만 강사님 기준 법적 기준 로그 제외 파일을 하나로 묶는게 좋다고 추천하셨는데요그럼 trace로그도 하나로 묶어서 보관하는지, 묶는경우 삭제가 안되니까 나눠서 보관하는지요?

안녕하세요 학습 목적으로 블로그에 강의내용을 정리하고 있는데 혹시 기재해도 될까요?

안녕하세요! 강사님강의 잘 듣고있습니다. 몇가지 궁금한게 있어서 질문드려요.로그를 내용에 따라, Logger 분리를 하는 방법 (Access.log, app.log, security.log, error.log 등등) 도 있는 것으로 알고 있는데요. 실무 API 서버경우에도 이렇게 로그레벨 이외에 Logger 분리를 하는 방법을 많이 사용하시는지 궁금합니다.1번과 연관된 질문으로, 복잡한 실무 ELK 환경에서는 어플리케이션 로그의 경우, 한가지 로그에 몰아서 하는 방식을 많이 사용하는지, 각각 로거로 분리하고 elasticsearch index도 분리하는 방식을 많이 사용하는지 궁금합니다. 

안녕하세요, 강사님. 우선 강의 잘 듣고 있습니다!실무에서는 어떤 식으로 로그 관리가 진행되는지 궁금합니다.개인적으로 trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는지 궁금합니다. 보관 기간을 3~7일 정도로 짧게 해서 저장한다고 하면 어차피 금방 제거되는 로그를 수집하는 이유가 있을지 의문이 들어서요!debug 레벨 로그는 분석이 필요할 때만 그 때 그 때 심고 필요가 없어지면 지우는 게 맞을까요? 보통은 trace 레벨 로그를 더 많이 쓰는지도 궁금합니다. 감사합니다 :) 

안녕하세요 강사님. 이번에 강의를 복습하면서 한가지 궁금증이 생겨서 질문을 남기게 되었습니다. 섹션 5의 로그 레벨을 기준으로 알람 설정하려면? 강의를 보면 엘라스틱 서치로 직접 http 요청을 보낸 후 받은 응답을 기준으로 알람 설정을 하도록 설명을 해주시는데요 요즘 시각화 툴 (Ex. 그라파나) 들은 Alert 같은 기능들이 있어서, 해당 기능들을 사용하면 간단하게 노코드로도 알람 설정이 가능한 것 같던데 키바나는 해당 기능이 따로 없는 걸까요? 그래서 엘라스틱 서치 기준으로 알람 설정 하는 방법을 알려주신 걸까요? 좋은 강의 잘 봤습니다!!

저는 컴터 사양이 꽤나 좋아서 인지? 항상 표준출력이 더 빠르더군요.알아보니 로깅 프레임워크가 느린 이유에는 대략 이런 이유들이 있네요.로그 출력에 여러 과정을 거침. Logger → Appender → Encoder → Layout → OutputStream레벨 설정에 의한 필터링로그 포맷팅 처리분명 표준출력이 synchronized에 의해서 멀티 스레드 환경에서 취약한건 맞으나 현재 테스트에서는 그 부분이 로깅 프레임워크의 처리 과정보다는 빨랐던 것 같습니다.테스트 환경 변경그래서 테스트 환경을 바꿔서 테스트 해보았습니다.멀티스레드 환경. 스레드 10개. 각 스레드별 100000번 출력package kr.co.shortenurlservice.log; import lombok.extern.slf4j.Slf4j; import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; @Slf4j public class SoutVsAsyncLoggingTest { private static final int THREAD_COUNT = 10; private static final int LOG_COUNT = 100_000; public static void main(String[] args) throws InterruptedException { // 1. System.out.println() 테스트 long sysoutTime = runTest(i -> System.out.println("[SYSOUT][" + Thread.currentThread().getName() + "] " + i) ); // 2. log.info() (AsyncAppender + Console) 테스트 long asyncLogTime = runTest(i -> log.info("[LOGGER][{}] {}", Thread.currentThread().getName(), i) ); // 결과 출력 Thread.sleep(5000); System.out.printf("System.out: %,d ms%n", sysoutTime); System.out.printf("Async log : %,d ms%n", asyncLogTime); } private static long runTest(StringConsumer task) throws InterruptedException { long start = System.currentTimeMillis(); ExecutorService executor = Executors.newFixedThreadPool(THREAD_COUNT); CountDownLatch latch = new CountDownLatch(THREAD_COUNT); for (int t = 0; t < THREAD_COUNT; t++) { executor.submit(() -> { for (int i = 0; i < LOG_COUNT; i++) { task.accept(i); } latch.countDown(); }); } latch.await(); executor.shutdown(); long end = System.currentTimeMillis(); return end - start; } @FunctionalInterface interface StringConsumer { void accept(int value); } } 또한 test/resources/logback.xml 설정으로 포맷을 날짜 같은것 제외하고 표준출력과 똑같이 맞춰주고 AsyncAppender를 통해 멀티 스레드 환경에서 차별점이 있도록 비동기 Appender를 추가해줌.<configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%msg%n</pattern> </encoder> </appender> <appender name="ASYNC_CONSOLE" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="CONSOLE"/> <queueSize>10240</queueSize> </appender> <root level="info"> <appender-ref ref="ASYNC_CONSOLE"/> </root> </configuration>이렇게 하니까 표준출력보다 빠르더군요.꼭 성능문제뿐 아니라 로그 관리체계 자체가 로깅 프레임워크가 넘사이기 때문에 안쓸 비교불가겠지만..성능적으로 보더라도 실무 환경이라면 메시지 출력 전후로 비즈니스 로직들이 있기 때문에 임계영역을 통해 스레드를 대시시키는 표준출력을 사용하는것보다는 로깅 프레임워크가 더욱 성능적으로 이점이 있을 것 같습니다.

 gpt에 질문을 해도 명확한 답이 안나와서 질문드립니다. 현재 2가지 장점으로 getStackTrace를 사용한다고 이해했습니다.printStackTrace를 사용하면 콘솔 출력이므로 로그 관리가 어렵다getStackTrace를 사용하면 속도 측면에서 이점이 있다. 속도가 조금 느리더라도 로그 관리를 위해서 getStackTrace를 사용한다고 말해야할까요? 아니면 다른 이유가 있어서 getStackTrace의 속도가 느린걸까요?

안녕하세요! 예외와 로그 강의 보던 중에 궁금한 점이 생겨 질문드립니다.  체크드 예외와 언체크드 예외 설명 과정에서, 컴파일 단계에서 발생하는 것은 예외가 아니라 문법 오류로 인한 에러라고 말씀해주셨습니다. 제가 이해하고 있는 에러 정의는프로그램에서 복구할 수 없는 심각한 문제입니다.  단순 문법 오류를 에러라고 이해해도되는건지 궁금하여 질문 남겨봅니다..! 감사합니다

https://www.inflearn.com/community/questions/902500/%EB%A1%9C%EA%B7%B8%EA%B0%80-%EA%B0%91%EC%9E%90%EA%B8%B0-%EC%95%88%EB%82%98%EC%98%B5%EB%8B%88%EB%8B%A4-%E3%85%A0%E3%85%A0%E3%85%A0%E3%85%A0?srsltid=AfmBOook52IISu7bmU4fnBg_VQjvllLx-upX39l0oGCQGBiI0os3q-Vb위 링크와 동일한 방식을 시도하다 궁금증이 생겨 질문드립니다. [문제상황]스프링 핵심 원리 - 기본편의 스프링으로 전환하기 강의 5분 35초의 로그가 출력이 안되어 인터넷 검색을 하다 위 링크를 발견했습니다. (강의 자료에 추가해주신 내용도 확인했구요.)logback.xml을 추가해서 문제를 해결했으나 처음에 문제 원인을 기본 로깅 레벨이 INFO로 설정되어있다고 판단해 application.properties에 아래와 같이 설정했습니다.logging.level.root=DEBUG logging.level.org.springframework=DEBUG위와 같이 설정했음에도 DEBUG 로그가 정상적으로 출력되지 않았습니다. [질문]application.properties에 위와 같이 설정했음에도 DEBUG 로그가 출력되지 않은 이유가 궁금합니다. (Logback.xml 적용하기 전에 설정했습니다.)logback.xml이 적용되는 원리와 application.properties의 설정이 적용되는 원리가 다른가요? 두 방법의 차이가 궁금합니다.==========AI 답변보고 추가로 남겨둡니다.제 질문의 의도는 '왜 application.properties'를 설정했을때 debug로그가 출력되지 않았느냐 입니다.!1. application.properties 설정을 적용할 때 logback.xml은 작성되지 않았습니다. 즉 logback.xml이 우선 적용되는 되는 것은 원인이 아닙니다.2. logback.xml의 역할은 이미 인터넷을 통해 학습해 알고 있습니다. (세부 설정이 가능하다는 등)3. logback.xml로 설정하는 것과 application.properties로 설정하는것이 세부 설정이 가능한 것 외에는 차이가 없다면 차이점에 대해서는 설명해주시지 않으셔도 됩니다. 다만 요지는 application.properties만 설정했을때 왜 debug로그가 출력되지 않았는지 궁금합니다. 제가 설정을 잘못한거였는지, 오타가 있었는지 등등 application.properties에서 logging.level=DEBUG 설정했을때는 왜 선생님 코드와 동일하게 DEBUG 로그가 출력되지 않았는지 궁금합니다.

맥북 M1 시리즈 사용하고 있는데, 강의에서의 docker 이미지 다운로드 및 컨테이너 실행 시 문제가 발생하고 있습니다(이미지 다운로드는 문제없으나, 컨테이너 실행시 문제 발생). 플랫폼 관련 옵션이 추가적으로 필요합니다.--platform linux/amd64 강의 자료보면 각각 Elasticsearch, Logstash 따로 작성되어 있는데 yml 하나로 제공되어도 좋을 것으로 보입니다.version: "3.8" services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.10.0 container_name: elasticsearch platform: linux/amd64 ports: - "9200:9200" environment: - discovery.type=single-node - xpack.security.enabled=false - xpack.security.http.ssl.enabled=false networks: - elastic-network logstash: image: docker.elastic.co/logstash/logstash:8.10.0 container_name: logstash platform: linux/amd64 ports: - "5044:5044" - "9600:9600" volumes: - ../logstash.conf:/usr/share/logstash/pipeline/logstash.conf # logstash.conf 경로 수정 필요 networks: - elastic-network networks: elastic-network: driver: bridge

모니터링 또는 메트릭 수집에는 Push 또는 Pull 모델이 있다고 들었습니다.이 두 방식의 차이점이나 도구들에 대한 부분도 나오는지 궁금합니다!

안녕하세요. 강의 잘 듣고 있습니다. 강의에서 spring filter를 이용해서 controller 에서 들어온요청정보들에 대한 log를 찍는걸 보여주셨는데요.혹시 url 들어온 파라미터는 로그에 찍지않는지 궁금합니다. 그리고 요청마다 body가 안들어오는 경우가 있고, 파라미터만 들어온다던지 경우의 수가 다양할거같은데.. 이럴 때는 필터를 어떤식으로 구성해야하는지 궁금합니다.

output { elasticsearch { hosts => ["http://elasticsearch:9200"] index => "application-logs-%{+YYYY.MM.dd}" } }위에 있는 설정 대로라면 yellow open application .. << 이게 localhost9200에 나타나야하는데 안뜨고 하단의 에러가 나옵니다.14:24:25,530 |-WARN in net.logstash.logback.appender.LogstashTcpSocketAppender[LOGSTASH] - Log destination localhost/<unresolved>:5044: Waiting 29951ms before attempting reconnection. 해결할려고 시도한 방법은 hosts의 url을 ip를 주소로 같게 해서 시도해보았으나 안되었습니다.  

구글에 쳐보니 예외가 터지면 printstacktrace()는 지양하고 getStackTrace() 를 사용하라는데의견이 궁금합니다 !

logstash 가 elasticsearch로 전달 할때.. 에러가 나는것 같은데Log destination localhost/<unresolved>:5044: Waiting 29992ms before attempting reconnection. 이런에러가 납니다. 혹시 원인을 알수 있을까요?

강의 잘 보고 있습니다. 혹시 강의 자료는 제공되지 않나요?

1. E05 강의 질문입니다. logback-default.xml 파일 확인하고 있는데요, 관련되서, 파일을 한번 볼수 있을까해서요, github들어가서 확인 해봤었는데 해당 파일이 없는것 같아서요 혹시 가지고 계신다면 보거나, github에 업로드 가능 할까요? 로그 최소한으로 제한 하는 부분이 궁금합니다.  2. E08 강의에 대한 질문 입니다. 스웨거 BoardType을 enum 형태로 해서, 테스트시, 스웨거 화면에서 selectbox로 BoardType을 선택 할 수 있도록 강의 내에서 나온 것 같습니다. 중간 BoardController 수정 부분이 편집 된것 같은데요..  관련부분을 알수 있을까요.. 아니면 참고 할만한 사이트 알수 있을까요? 어떤 식으로 변경 된건지.. 궁금합니다..  아니면, swagger 참고 사이트라도 알려주시면