DO MY BEST

CGI 란

서버와 애플리케이션 간에 데이터를 주고받는 이 프로세스 또는 규칙을 공통 게이트웨이 인터페이스(CGI)라고 한다. 동적인 컨텐츠를 생성할 수 있는 프로그램을 갈망하는 사람들의 요구로 인해 만들어진 규약이다.

CGI 작동 방식

프로세스기반으로 동작한다. 즉 매 요청마다 프로세스를 새로 시작하는 방식이다.

이로 인해 요청 수가 많아 지면 서버에 많은 프로세스가 생성되고,요청을 처리 후 종료 된다. 그래서 요청 수가 많아지면 서버에 부담을 준다.

FastCGI 의 탄생

이를 보완하기 위해 FastCGI와 같은 대안이 나왔다.

개선점은 매 요청 프로세스를 생성하지 않고 프로세스를 재사용할 수 있게 했다.

그래서 FastCGI 부터는 프로세스 풀이 생김.

IPC 최적화로 인해 멀티스레드와 멀티프로세스 지원이 가능해짐

결과적으로, FastCGI의 프로세스 풀 개념은 CGI가 겪던 성능 문제를 크게 개선해주었다. 이후의 다른 웹 애플리케이션 인터페이스들이 이러한 개념을 적용하면서 더 발전하게 됨.

참고

- https://kldp.org/node/73386

- https://jongminlee0.github.io/2020/10/10/cgivsservlet/

- https://www.geeksforgeeks.org/difference-between-java-servlet-and-cgi/

- https://www.javatpoint.com/difference-between-java-servlets-and-cgi

서버 로그를 그라파나에 보여지게 하려는데, 에러가 나를 몇시간 동안 괴롭혔다.

해당 에러를 해석 해보자면 연결은 됐지만 라벨을 받지 못했으니 Loki, Promtail 설정을 잘해봐라. 라는 뜻으로 이해했다.

처음에는 Docker compose 파일에 다음과 같이 Promtail 컨테이너를 세팅했다.

문제는 Promtail 설정이 담긴 promtail-config.yml 파일명이었다. 하이픈을 제거해서 promtail.yml로 변경하니 됐다.

다음과 같은 에러가 나와 고생좀 했다.

github.com/prometheus/prometheus/promql.NewActiveQueryTracker({0x3053abc, 0x5}, 0x14, {0x39f12e0, 0xc000099400})
	/app/promql/query_logger.go:121 +0x3cd
main.main()
	/app/cmd/prometheus/main.go:597 +0x6713
ts=2024-10-13T13:46:01.358Z caller=main.go:491 level=info msg="No time or size retention was set so using the default time retention" duration=15d
ts=2024-10-13T13:46:01.358Z caller=main.go:535 level=info msg="Starting Prometheus Server" mode=server version="(version=2.37.6, branch=HEAD, revision=8ade24a23af6be0f35414d6e8ce09598446c29a2)"
ts=2024-10-13T13:46:01.358Z caller=main.go:540 level=info build_context="(go=go1.19.6, user=root@5f96027a7c3e, date=20230220-09:36:40)"
ts=2024-10-13T13:46:01.358Z caller=main.go:541 level=info host_details="(Linux 6.5.0-28-generic #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr  4 14:39:20 UTC 2 x86_64 40ea8565bbf0 (none))"
ts=2024-10-13T13:46:01.358Z caller=main.go:542 level=info fd_limits="(soft=1048576, hard=1048576)"
ts=2024-10-13T13:46:01.359Z caller=main.go:543 level=info vm_limits="(soft=unlimited, hard=unlimited)"
ts=2024-10-13T13:46:01.359Z caller=query_logger.go:113 level=error component=activeQueryTracker msg="Failed to create directory for logging active queries"
ts=2024-10-13T13:46:01.359Z caller=query_logger.go:91 level=error component=activeQueryTracker msg="Error opening query log file" file=/prometheus/data/queries.active err="open data/queries.active: no such file or directory"
panic: Unable to create mmap-ed active query log

goroutine 1 [running]:
github.com/prometheus/prometheus/promql.NewActiveQueryTracker({0x3053abc, 0x5}, 0x14, {0x39f12e0, 0xc0004b9540})
	/app/promql/query_logger.go:121 +0x3cd
main.main()
	/app/cmd/prometheus/main.go:597 +0x6713

Prometheus가 /prometheus/data/queries.active 파일을 생성하려고 할 때 권한이 부족하다는 문제인 것 같았다. 그래서 찾다가 다음링크를 참고해서 해결했다.

https://github.com/prometheus/prometheus/issues/5976#issuecomment-535455952

이 설정은 호스트의 파일 시스템과 컨테이너 간 권한 문제를 해결하는 방법이다. 특히 공유된 볼륨에서 컨테이너 내부에서 파일을 작성하고 수정할 때 발생할 수 있는 충돌을 방지한다. UID 1000:1000로 실행하면 호스트의 동일한 사용자 권한을 가진 것처럼 컨테이너가 동작하게 되어, 파일 시스템에 접근할 때 권한 문제가 없어진다.