정말 극혐한다 windows
사용자 로그를 온디멘드 환경(=자체구축)에선 볼륨을 이용해 로그 파일을 읽거나 삭제하고 있다.
나의 경우 아이맥을 사용하고 있는데 분명 잘 되었던 fleutnd가 프론트엔드 개발자 분 컴퓨터에 안된다는 말을 듣고 가보니 정말 로그 파일이 생성되지 않았다 😱
황급히 옆 자리에 앉으신 다른 분 자리에서 해보니 거긴 또 됐다.
차이점은 프론트엔드 개발자 분 컴퓨터 환경은 윈도우였고 옆 자리 분은 나와 같은 맥이었다.
다른 윈도우 환경에서 해보니 역시나 되지 않았다.
이번 이슈의 원인이 윈도우로 판명된 순간이었다.
windows에선 volume 권한 오류가 있다고?
윈도우 환경에서만 그러는거 오케이
근데 원인은 뭘까 하고 fluentd 로그를 뒤지니
failed to flush the buffer. retry_times=0 next_retry_time=2023-08-28 02:28:18 +0000 chunk="603f24aaee6f3026c3b781882f90dc36" error_class=Errno::EACCES error="Permission denied @ rb_sysopen - /fluentd/log/${tag}.log”
이런 오류가 나왔다.
여기에 주목할 부분은 Permission denied 다.
구글에 치기만 해도 '액세스 거부 오류'로 나온다.
docker에서 액세스 거부 오류가 나오는 이유는 voluem 권한이 문제가 생겨서 그런거다.
즉, fluentd가 voluem으로 파일을 생성하고 싶지만 권한이 없으니 쓰기를 못하는거다.
fluentd:
build: .
image: my-fluentd:latest
volumes:
# - ./fluentd/log:/fluentd/log
- ./fluentd/conf:/fluentd/etc
ports:
- 24224:24224
- 24224:24224/udp
restart: always실제로 볼륨을 주석 처리되니 로그 파일이 잘 생성되었다.
나의 경우 볼륨을 이용해 다른 MSA 서비스에서 조회하고 삭제해야 했기 때문에 볼륨을 뺄 수 없었다.
해결방법 - user: "0"
갓비트에도 물어봤지만 제대로 된 해결방법을 알려주지 않아 열심히 fluentd 깃허브를 찾아본 결과 첫번째 찾은 방법이 있었다.
그것 바로 ENV FLUENT_UID 0 이었다.
하지만 나는 이 방법으로 해결하지 못했다.
fluentd:
build: .
image: my-fluentd:latest
user: "0"
volumes:
- ./fluentd/log:/fluentd/log
- ./fluentd/conf:/fluentd/etc
ports:
- 24224:24224
- 24224:24224/udp
restart: always그러다가 발견하게 바로 user: "0"이다.
이러면 컨테이너를 실행할 때 사용하는 사용자의 ID를 0으로 하여 해당 컨테이너가 root 사용자 권한으로 실행하도록 한다.
아직 안 끝난 오류 😭
정말 한 번에 되면 좋을까.
다시 fluetnd를 올려보니 새로운 오류가 나왔다.
[error]: #0 failed to purge buffer chunk chunk_id="6040a44f84144703d5cb40ec0cb169fc" error_class=Errno::ENOENT error=#<Errno::ENOENT: No such file or directory @ apply2files - /fluentd/log/buffer/${tag}.q6040a44f84144703d5cb40ec0cb169fc.buffer.meta>
no such file or directroy라는 문구가 나왔다.
<match **>
@type file
path /fluentd/log/${tag}
append true
<buffer tag>
path /fluentd/log/buffer/${tag}.*.buffer
chunk_limit_size 2m
flush_mode interval
flush_interval 10s
</buffer>
<format>
@type single_value
message_key log
</format>
</match>fluentd.conf에서 output에 해당하는 코드를 보도록 하자.
문제점은 없다.
웃긴 점은 buffer 파일은 잘 생기지만 설정한 값인 10초가 지나도 로그 파일로 만들어지지 않는다.
정말 별별 짓 다해봤다.
그럼에도 로그 파일이 생기지 않아 이러려고 개발자 했나 라는 생각을 할 때 단비와 같은 글을 발견했다.
여기에서 이 사람은 buffer의 type을 memory를 해줬다.
혹시 싶어서 저 코드 그대로 사용하니 잘 됐다!
왜 해결된거지?
해결된건 기쁘지만 "왜" 해결 되었는지 아는 것도 중요하다.
우선 buffer에서 type을 지정해주지 않으면 file이 디폴트 값이다.
즉, 난 그동안 @type이 file로 되어 있었던 것이다.
그렇다면 type이 file인거랑 memory인거랑 뭐가 다를까?
| type | file | memory |
| 저장 장소 | 버퍼 데이터가 디스크에 파일로 저장 | 버퍼 데이터가 메모리에 저장 |
| 장점 | 시스템 장애 발생 시 데이터 보존 | 디스크 I/O 부하가 줄어들어 성능 향상 |
| 단점 | 디스크 I/O에 의존하기 때문에 성능 떨어짐 | 장애 발생 시 데이터 손실 위험 존재 |
즉, file의 경우 시스템 장애가 발생해도 데이터가 buffer 파일에 쌓이기 때문에 데이터를 살릴 수 있다.
하지만 memory는 buffer 파일에 쌓이지 않고 메모리에 저장되었다가 로그 파일로 빠지기 때문에 시스템 장애가 발생하면 데이터 손실이 있다.
fluentd 공식 문서에 자세히는 적혀 있지 않지만 그래도 궁금하다면 buffer 플러그인 쪽을 보면 된다.
https://docs.fluentd.org/buffer/memory
memory - Fluentd
The memory buffer plugin provides a fast buffer implementation. It uses memory to store buffer chunks. When Fluentd is shut down, buffered logs that cannot be written quickly are deleted.
docs.fluentd.org
우리 회사의 경우 사용자 로그는 type을 memory를 해도 상관없다고 결정되어 @type을 memory로 바꿨다.
하지만 회사 로그의 경우엔 type을 memory를 하면 데이터 유실 때문에 추천하지 못할 것 같다.
참고로 user: "0" 지우면 다시 권한 오류라고 하니깐 유념하도록 하자.
fin.
댓글