다음과 같은 설정이 있습니다.
여러 작업자를 생성하고 계산을 수행 한 후 계산이 완료된 후 종료합니다.
따라서 매번 작업을 실행하는 다른 인스턴스가 될 수 있으므로 각 호스트마다 고유 한 로그 파일이 생겨 엄청난 파일 목록이 생성됩니다.
좋은 습관입니까? 그렇지 않은 경우이 특정 사용 사례에서 작업 처리를 로깅하는 더 좋은 방법은 무엇입니까?
추신 : 저의 인프라는 서버리스입니다. 그래서 지금은 (AWS) CloudWatch에 로그인하고 있습니다. 그러나 가능한 한 서버리스 설정에 적합한 AWS와 독립적으로 질문에 대답하십시오.
답변:
"서버리스"는 대부분 비교적 간단한 마이크로 서비스, 일반적으로 REST 프런트 엔드에 자동으로 연결된 작은 웹앱 또는 단일 기능을 가지고 있음을 의미합니다. 보다 전통적인 웹 서비스에 사용하는 것과 동일한 개념이 적용됩니다. 일반적으로 일부 원격 syslog 및 ElasticSearch 작성자가 혼합되어 있습니다.
네트워크 또는 원격 syslog는 오랫동안 사용되어 왔으며 그 주위에는 상당히 강력한 도구 세트가 있습니다. 중앙 syslog 서버를 실행해야하지만 프로토콜은 매우 간단하고 모든 언어에 로그를 보내는 데 사용할 수있는 순수한 클라이언트 라이브러리가 있습니다. 원격 syslog의 일반적인 문제점 중 하나는 전통적으로 UDP를 기반으로한다는 것입니다. 이는로드가 많은 경우 일부 로그 메시지가 손실 될 수 있음을 의미합니다. 이것은 캐스케이드 과부하를 피하는 데 도움이되는 좋은 일이지만 알고 있어야합니다. 일부 최신 syslog 데몬은 TCP 기반 프로토콜을 지원하지만 클라이언트 지원은 덜 통일되어 있으므로 조사하십시오.
최신이지만 매우 인기있는 것은 ElasticSearch에 로그인하는 것입니다. 이는 Kibana 대시 보드 및 Logstash Takelit (종종 ELK, ElasticSearch + Logstash + Kibana)로 인해 유용합니다. Amazon은 호스팅 된 ElasticSearch 옵션도 제공하므로 시작하기가 더 쉽습니다. ES는 비교적 간단한 REST API를 사용하므로 HTTP 클라이언트가있는 모든 언어 (읽기 : 모든 언어)는 ES에 로깅해도 문제가 없지만 시스템이 부분적으로 중단 된 경우 네트워크 작동을 차단하는 데주의해야합니다 (예 : 앱이 성공하지 못하고 사용자 요청 서비스를 중단하는 로깅 호출에 멈출 수 없습니다).
요즘에는 복잡한 로그 분배 시스템에서 Kafka 데이터베이스 / 큐 / 원하는 통화를 넥서스 포인트로 많이 사용하지만 더 복잡한 로깅 토폴로지는 상상력에만 국한됩니다. .
"서버리스"측면에서는 일반적으로 이러한 시스템을 네트워크 수준에서 직접 통합하여 로컬 파일에 기록하지 않고 서비스 / 기능에서 직접 syslog 또는 ES로 로그 데이터를 전송하려고합니다. 로컬 디버깅 및 개발에도 적용됩니다).
이 답변은 확장 성 고려 사항에 대한 것입니다. 작업자 수가 많거나 여러 명으로 동시에 로그를 빠르게 생성 할 수있는 경우.
예, 여러 로그 파일을 동시에 사용하는 것이 좋습니다.
여러 작업자의 단일 로그 파일 로그를 실시간으로 결합하려고하면 문제가 발생합니다.
샤딩 로그 파일 (동시에 여러 개의 로그 파일을 사용)은 자체적으로 확장 가능한 고성능 중앙 로깅 서비스를 제공하는 일부 호스팅 제공 업체에서 사용하는 기술입니다. 예를 들어, 로그를 파일로 내보낼 때 Google의 StackDriver 로깅 은 여러 개의 분할 된 로그 파일을 생성합니다. 에서 Google 클라우드 저장소에서 로그 항목 :
이 때 로그를 내보내 클라우드 스토리지 버킷, 스택 드라이버 로깅은 버킷에 파일 세트를 작성합니다. 파일은 로그 유형 및 날짜별로 디렉토리 계층 구조로 구성됩니다. 로그 유형은 간단한 이름 또는와 같은
syslog복합 이름 일 수appengine.googleapis.com/request_log있습니다. 이러한 로그가라는 버킷에 저장된 경우my-gcs-bucket디렉토리는 다음 예제와 같이 이름이 지정됩니다.my-gcs-bucket/syslog/YYYY/MM/DD/ my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/단일 버킷에는 여러 로그 유형의 로그가 포함될 수 있습니다.
리프 디렉토리 (
DD/)에는 여러 파일이 있으며 각 파일에는 파일 이름에 지정된 기간 동안 내 보낸 로그 항목이 있습니다. 파일이 샤딩되고 이름이 샤드 번호Sn또는An(n = 0, 1, 2, ...)로 끝납니다 . 예를 들어, 다음에 저장 될 수있는 두 개의 파일이 있습니다directory my-gcs-bucket/syslog/2015/01/13/.08:00:00_08:59:59_S0.json 08:00:00_08:59:59_S1.json이 두 파일에는
syslog0800 UTC를 시작하는 시간 동안 모든 인스턴스에 대한 로그 항목이 포함되어 있습니다 . 모든 로그 항목을 가져 오려면 각 기간 (이 경우 파일 샤드 0 및 1)에 대한 모든 샤드를 읽어야합니다. 기록 된 파일 샤드 수는 로그 항목의 볼륨에 따라 각 기간마다 변경 될 수 있습니다.
이러한 고성능 로깅 서비스는 파일에 대한 로깅 대안을 제공 할 수 있으므로 관심있는 경우 로그 파일 관리를 완전히 피할 수 있습니다.
마지막으로 실시간 로그 파일 병합이 여러 로그 파일을 요구하지 않는 경우 오프라인 로그 관리에 도움이 될 수 있습니다.