대부분의 로그 파일이 이진 형식이 아닌 일반 텍스트를 사용하는 이유는 무엇입니까?

로깅은 필요하지만 (상대적으로) 거의 사용되지 않는 것입니다. 따라서 스토리지 측면에서 훨씬 더 컴팩트하게 만들 수 있습니다.

예를 들어 정수로 표시 할 수있는 ip, 날짜, 시간 및 기타 데이터와 같이 가장 일반적으로 기록되는 데이터는 텍스트로 저장됩니다.

로깅이 이진 데이터로 저장된 경우 많은 공간을 보존 할 수 있으므로 회전이 적고 디스크 수명이 늘어날 수 있습니다 (특히 쓰기가 제한된 SSD의 경우).

어떤 사람들은 그것이 실제로 중요하지 않은 사소한 문제라고 말할 수도 있지만 그러한 메커니즘을 구축하는 데 필요한 노력을 고려하면 말이되지 않습니다. 누구든지 여가 시간에 이틀 동안 이것을 만들 수 있습니다. 왜 사람들은 이것을하지 않습니까?

systemd유명한 로그 파일을 이진 형식으로 저장합니다. 내가 들었던 주요 문제는 다음과 같습니다.

1. 로그가 손상된 경우 전문 도구가 필요하므로 복구하기가 어렵습니다.
2. 이 같은 표준 도구를 사용할 수 없습니다, 그래서 그들은 사람이 읽을 수없는 vi, grep, tail등이 그것들을 분석하기를

이진 형식 (내 지식으로)을 사용하는 주된 이유는 인덱스 등을 만드는 것이 더 쉽다고 간주했기 때문입니다.

디스크 공간의 이점은 실제로는 상대적으로 작고 감소한다고 주장합니다. 대량의 로깅을 저장하려면 롤링 된 로그를 압축하는 것이 실제로 매우 효율적입니다.

균형 잡히면 툴링과 친숙 함의 이점은 대부분의 경우 텍스트 로깅 측면에서 잘못 될 수 있습니다.

대부분의 로그 파일이 이진 형식이 아닌 일반 텍스트를 사용하는 이유는 무엇입니까?

유닉스 철학 위키피디아 기사 에서 "텍스트"라는 단어를 검색 하십시오. 예를 들어 다음과 같은 문장을 찾을 수 있습니다.

Bell Labs CSRC (컴퓨터 과학 연구 센터) 책임자이자 Unix 파이프의 발명가 인 McIlroy는 Unix 철학을 다음과 같이 요약했습니다. [10]

이것이 유닉스 철학입니다. 한 가지 일을하고 잘하는 프로그램을 작성하십시오. 함께 일할 프로그램을 작성하십시오. 범용 인터페이스이므로 텍스트 스트림을 처리하는 프로그램을 작성하십시오.

예를 들어, Unix Philosophy의 기초 에서

구성 규칙 : 다른 프로그램과 연결될 프로그램을 설계하십시오.

어떤 프로그램도 서로 통신 할 수 없으면 지나치게 복잡한 모놀리스를 프로그래밍하는 것을 피하기가 어렵습니다.

유닉스 전통은 간단한 텍스트, 스트림 지향, 장치 독립적 형식을 읽고 쓰는 프로그램 작성을 강력히 권장합니다. 클래식 유닉스에서는 가능한 많은 프로그램이 간단한 필터로 작성되어 입력시 간단한 텍스트 스트림을 가져 와서 출력시 다른 간단한 텍스트 스트림으로 처리합니다.

널리 알려진 신화에도 불구하고이 관행은 유닉스 프로그래머가 그래픽 사용자 인터페이스를 싫어하기 때문에 선호되지 않습니다. 간단한 텍스트 스트림을 허용하고 방출하는 프로그램을 작성하지 않으면 프로그램을 함께 연결하기가 훨씬 어렵 기 때문입니다.

메시지는 객체 지향 설정의 객체에 대한 것처럼 텍스트 스트림은 Unix 도구에 있습니다. 텍스트 스트림 인터페이스의 단순성은 도구의 캡슐화를 강제합니다. 원격 프로 시저 호출과 같은보다 정교한 프로세스 간 통신 형식은 서로의 내부와 너무 많은 프로그램을 포함하는 경향이 있습니다.

누구든지 여가 시간에 이틀 동안 이것을 만들 수 있습니다. 왜 사람들은 이것을하지 않습니까?

이진으로 로그 파일을 저장하는 것은 시작일뿐입니다. 그런 다음 도구를 작성하여 다음을 수행해야합니다.

• 전체 로그 파일 표시 ( edit)
• 로그의 시작을 읽지 않고 로그의 끝을 표시합니다 ( tail -f)
• 파일에서 물건 검색 ( grep)
• 선택 / 재미있는 항목 만 표시하도록 필터 (임의로 복잡한 필터 표현 사용)
• 로그 파일 디코더 소프트웨어가없는 다른 사람에게 로그를 전자 메일로 보내기
• 로그 파일의 조각을 복사하여 붙여 넣기
• 프로그램 (로그 파일을 생성 함)이 여전히 개발 및 디버깅되는 동안 로그 파일을 읽습니다.
• 고객 사이트에 배포되어 실행중인 이전 버전의 소프트웨어에서 로그 파일을 읽습니다.

분명히 소프트웨어는 바이너리 파일 형식 (예 : 관계형 데이터베이스)도 사용할 수 있고 사용하지만 로그 파일에 대해서는 가치가 없습니다 ( YAGNI 의미).

여기에는 논쟁의 여지가 많은 추측이 있습니다.

로깅은 내가 가진 모든 작업에서 없어서는 안될 부분이었습니다. 응용 프로그램 상태에 대한 가시성을 원한다면 필수적입니다. 그것이 "프린지"사용인지 의심합니다. 내가 참여한 대부분의 조직은 로그를 매우 중요하게 생각합니다.

로그를 이진으로 저장하면 로그를 읽기 전에 디코딩해야합니다. 텍스트 로그는 단순하고 사용하기 쉽다는 장점이 있습니다. 이진 경로를 고려하고 있다면 로그를 데이터베이스에 저장하여 로그를 조사하고 통계적으로 분석 할 수 있습니다.

SSD는 오늘날 HDD보다 신뢰성이 높으며 많은 쓰기에 대한 논란은 대체로 무의미합니다. 정말로 걱정된다면 로그를 일반 HDD에 저장하십시오.

로그 파일은 심각한 응용 프로그램의 중요한 부분입니다. 앱의 로깅이 양호하면 어떤 주요 이벤트가 언제 발생했는지 확인할 수 있습니다. 어떤 오류가 발생했는지; 일반적으로 문제에 대해 듣고 응용 프로그램의 내장 진단 (웹 콘솔을 열거 나 JMX와 같은 진단 도구를 사용)을 확인한 다음 검사를 수행하는 것이 일반적입니다 로그 파일.

텍스트가 아닌 형식을 사용하는 경우 즉시 장애물이 발생합니다. 이진 로그를 어떻게 읽습니까? 프로덕션 서버에없는 로그 읽기 도구를 사용하십시오! 아니면, 그러나, 우리는 새로운 분야를 추가했고 이것은 오래된 독자입니다. 우리는 이것을 테스트하지 않았습니까? 예, 그러나 아무도 여기에 배포하지 않았습니다. 한편, 사용자가 핑을하면서 화면이 밝아지기 시작합니다.

아니면 이것이 앱이 아니지만 지원하고 있으며 다른 시스템과 WTF라는 것을 알고 있다고 생각하십니까? 로그는 이진 형식입니까? 좋아, 위키 페이지를 읽기 시작하고 어디에서 시작합니까? 이제 로컬 컴퓨터로 복사했지만 손상 되었습니까? 비 이진 전송을 수행 했습니까? 아니면 로그 읽기 도구가 엉망입니까?

요컨대, 텍스트 읽기 도구는 크로스 플랫폼과 어디에나 있으며, 로그는 오래 지속되기도하며 서둘러 읽을 필요가 있습니다 . 이진 형식을 발명하면 잘 이해되고 사용하기 쉬운 도구로 가득한 세상에서 벗어날 수 있습니다. 필요할 때 심각한 기능 손실.

대부분의 로깅 환경은 타협을합니다. 현재 로그를 읽고 읽을 수 있도록 유지하고 이전 로그를 압축합니다. 즉, 바이너리 형식으로 로그 메시지가 줄어들지 않기 때문에 압축의 이점을 얻을 수 있습니다. 동시에 덜 사용 하고 grep 등을 사용할 수 있습니다 .

그렇다면 바이너리를 사용하면 어떤 이점이 있습니까? 소량의 공간 효율성-점점 더 중요하지 않습니다. 글이 적거나 적습니까? 글쎄, 실제로-쓰기 수는 디스크 커밋 수와 관련이 있으므로 로그 라인이 디스크 블록 크기보다 훨씬 작 으면 SSD는 계속해서 새로운 블록을 할당합니다. 따라서 바이너리는 다음과 같은 경우에 적합한 선택입니다.

• 방대한 양의 구조화 된 데이터를 쓰고 있습니다
• 로그는 특히 빠르게 만들어야합니다
• "지원 조건"에서 분석 할 필요가 없습니다.

그러나 이것은 응용 프로그램 로깅처럼 들리지 않습니다. 이들은 출력 파일 또는 활동 레코드입니다. 그것들을 파일에 넣는 것은 아마도 데이터베이스에 파일을 쓰는 것에서 한 걸음 떨어져있을 것입니다.

편집하다

여기서는 "프로그램 로그"(로깅 프레임 워크 별)와 "레코드"(액세스 로그, 로그인 레코드 등) 사이에 일반적인 혼동이 있다고 생각합니다. 나는 그 질문이 후자와 가장 밀접하게 관련되어 있다고 생각하며,이 경우 문제는 잘 정의되어 있지 않다. 메시지 레코드 또는 활동 로그는 컴팩트 한 형식이어야합니다. 특히 문제 해결이 아니라 잘 정의되고 분석에 사용될 수 있기 때문입니다. 이를 수행하는 도구로 tcpdump는 Unix 시스템 모니터가 sar있습니다. 반면에 프로그램 로그는 훨씬 임시적인 경향이 있습니다.

다소 이진 로그의 예는 Windows 이벤트 로그입니다. 프로 측에서는 로그 메시지를 거의 무료로 사용하여 실질적으로 비용이 들지 않을 수 있습니다.

경고 : 최근 90 초 동안 foobars 큐가 517 개 증가했습니다. 이것이 하루에 한 번 발생하면 걱정할 것이 없습니다. 더 자주 또는 연속적으로 발생하는 경우 foobar 응용 프로그램에서 사용할 수있는 RAM의 양을 확인하십시오. 그러나 이벤트 12345와 함께 발생하면 사용되지 않는 데이터베이스를 사용하는 것 같으며 데이터 손실을 방지하기 위해 + 1-555-12345로 지원을 요청하는 것이 좋습니다.

이 메시지의 주요 부분은 응용 프로그램과 함께 설치된 리소스로 한 번만 존재합니다. 그러나이 자원이 올바르게 설치되지 않은 경우 (예를 들어, 더 이상 사용되지 않는 메시지를 지원하지 않는 최신 버전이 설치 되었기 때문에) 이벤트 로그에 표시되는 내용은 단순한 메시지 용 표준 메시지입니다.

던노, "517"과 "90"

더 이상 어떤 식 으로든 도움이되지 않습니다.

텍스트와 이진 중에서 선택하기 전에 묻고 싶은 두 가지 주요 질문은 다음과 같습니다.

• 내 청중은 누구입니까?
• 어떤 내용을 전달해야합니까?

일반적인 의견은 로그 메시지의 대상이 사람이라는 것입니다. 로그 크롤링 스크립트가 많이 있기 때문에 이것은 완벽한 가정은 아니지만 일반적입니다. 이 경우, 사람이 편한 매체로 정보를 전달하는 것이 합리적입니다. 텍스트는이 매체라는 오랜 전통을 가지고 있습니다.

내용의 경우 이진 로그의 형식이 올바르게 정의되어 있어야 합니다. 다른 사람들이 해당 로그에서 작동하는 소프트웨어를 작성할 수 있도록 형식을 충분히 정의해야합니다. 일부 로그는 상당히 체계적으로 구성되어 있습니다 (질문에는 몇 가지가 나와 있습니다). 다른 로그는 잘 정의되지 않은 자연어 형식으로 컨텐츠를 전달할 수 있어야합니다. 이러한 자연어 사례는 이진 형식과 일치하지 않습니다.

바이너리로 잘 설명 된 로그의 경우 선택해야합니다. 텍스트는 모든 사람에게 적용되므로 종종 기본 선택으로 표시됩니다. 결과를 텍스트로 기록하면 사람들이 로그로 작업 할 수 있습니다. 수천 번 입증되었습니다. 이진 파일은 더 까다 롭습니다. 결과적으로 개발자는 모든 사람들이 그 동작을 알기 때문에 단순히 텍스트를 출력 할 수 있습니다.

TL; DR : 크기는 중요하지 않지만 사용 편의성은 중요합니다.

우선, 단기 로그 저장소에 대한 텍스트 및 이진 형식의 각 장점을 비교하는 것이 중요한 문제이지만 실제로 크기는 중요하지 않습니다. 이에 대한 두 가지 이유는 다음과 같습니다.

1. 로그는 중복성이 매우 높아서 압축률이 매우 높습니다. 제 경험상 원본 파일 크기의 5 % 이하인 압축 된 로그 파일을 보는 것은 드문 일이 아닙니다. 따라서 텍스트 또는 이진 형식을 사용하면 로그의 장기 저장에 영향을 미치지 않아야합니다.

2. 어떤 형식을 선택하든 로그 파일을 압축하여 장기 저장소 플랫폼으로 보내는 "로그 파일 싱크"를 구현하지 않으면 로그가 서버 디스크를 빠르게 채 웁니다. 이진 형식을 사용하면이 속도가 약간 느려질 수 있지만 요소 10만큼 변경해도 그다지 중요하지 않습니다.

텍스트 대 이진 로그 형식

유닉스 시스템의 약속은 grep , sort , join , sed 및 awk 와 같이 줄로 구조화 된 텍스트 파일에 대해 작업하는 표준 도구 세트를 사용하는 것을 배우면 모든 작업을 수행하는 프로토 타입을 신속하게 조립하는 데 사용할 수 있다는 것입니다 느리고 조잡하지만 우리는 원합니다. 프로토 타입이 유용성을 입증하면 실제로 엔지니어링 된 소프트웨어로 변환하여 성능을 얻거나 다른 유용한 기능을 추가 할 수 있습니다. 이것은 적어도 제 이해에서 유닉스 철학의 본질입니다.

다시 말해서, 처리 및 분석을 수행해야 할 가능성이 있다면 오늘날까지 파악할 수 없으며, 누가이 분석을 구현해야하는지 모를 경우 프로토 타입을 사용해야하는 단계와 텍스트 형식을 사용해야합니다. 로그가 최적 일 것입니다. 잘 식별 된 소량의 처리를 반복적으로 수행해야하는 경우,이 분석을 수행하기 위해 다년생 소프트웨어 시스템을 엔지니어링해야하는 상황에 있으며 관계형 데이터베이스와 같은 로그의 이진 또는 구조화 된 형식은 다음과 같습니다. 최적.

(몇 시간 전에 나는 이것에 관한 블로그 게시물을 썼습니다 .)

로그 파일은 모든 유형의 텍스트 편집기를 사용하거나 콘솔 명령을 통해 내용을 표시하여 쉽게 읽을 수 있기 때문에 텍스트 형식입니다.

그러나 많은 데이터가있는 경우 일부 로그 파일은 이진 형식입니다. 예를 들어, 내가 작업중인 제품은 최대 15000 개의 레코드를 저장합니다. 최소한의 공간에 레코드를 저장하기 위해 이진으로 저장됩니다. 그러나 레코드를 보거나 사용할 수있는 형식 (예 : 스프레드 시트)으로 변환하려면 특수 응용 프로그램을 작성해야합니다.

요약하면 모든 로그 파일이 텍스트 형식 인 것은 아닙니다. 텍스트 형식은 컨텐츠를보기 위해 사용자 정의 도구가 필요하지 않다는 이점이 있습니다. 많은 데이터가있는 경우 파일은 이진 형식 일 수 있습니다 . 이진 형식은 데이터를 읽고 사람이 읽을 수있는 형식으로 표시하려면 (사용자 정의) 응용 프로그램이 필요합니다. 더 많은 데이터를 이진 형식으로 묶을 수 있습니다. 텍스트 형식을 사용할지 이진 형식을 사용할지 여부는 데이터 양과 내용을 쉽게 볼 수있는 방법에 따라 결정됩니다.

런타임 중에 출력 채널을 사용할 수없는 내장 시스템에서 응용 프로그램은 로깅으로 인한 속도 적중을 감당할 수 없거나 로깅으로 인해 기록하려는 효과를 변경하거나 숨길 수 있습니다. 이진 데이터를 배열이나 링 버퍼에 채우고 테스트 실행이 끝날 때 printf () 시키거나 원시 덤프하고 해석기를 작성하여 읽을 수있는 것으로 인쇄합니다. 어느 쪽이든, 나는 읽을 수있는 데이터로 끝내고 싶습니다.

리소스가 많은 시스템에서 최적화 할 필요가없는 것을 최적화하기위한 체계를 개발해야하는 이유는 무엇입니까?

로그 파일은 문제 디버깅을 돕기위한 것입니다. 일반적으로 하드 드라이브 공간은 엔지니어링 시간보다 훨씬 저렴합니다. 텍스트 작업을위한 많은 도구 (예 :)가 있기 때문에 로그 파일에는 텍스트가 사용됩니다 tail -f. HTTP조차도 일반 텍스트를 사용합니다 ( http 텍스트 대신 바이너리를 보내지 않는 이유 도 참조하십시오 ).

또한 일반 텍스트 로깅 시스템을 개발하고 작동하는지 확인하고, 오류가 발생하면 디버깅하기 쉬우 며, 시스템이 고장 나서 로그의 일부가 손상된 경우 유용한 정보를 쉽게 복구 할 수 있습니다.

손상된 텍스트 파일은 손상된 부분을 여전히 읽을 수 있습니다. 손상된 바이너리 파일은 복원 가능할 수도 있지만 그렇지 않을 수도 있습니다. 복원 가능하더라도 더 많은 작업이 필요합니다. 또 다른 이유는 이진 로깅 형식으로 인해 "일시 수정"(일명 "모든 수정 중 가장 영구적 인 수정")을 신속하게 생성 할 때 로깅 솔루션이 더 빨리 생성 될 수있는 것 대신 사용되는 경우가 적기 때문입니다.

우리는 소프트웨어의 견고성을 달성하고 유지하기위한 단위 테스트를 신뢰합니다. (대부분의 코드는 헤드리스 서버에서 실행됩니다. 로그 파일의 작업 후 분석이 핵심 전략입니다.) 구현의 거의 모든 클래스는 로깅을 수행합니다. 단위 테스트의 중요한 부분은 단위 테스트에 사용되는 '모의'로거를 사용하는 것입니다. 단위 테스트는 모의 로거를 만들어 테스트중인 항목에 제공합니다. 그런 다음 (유용한 / 적절한 경우) 기록 된 내용 (특히 오류 및 경고)을 분석합니다. 텍스트 기반 로그 형식을 사용하면 '실제'로그에서 수행되는 분석과 같은 이유로 훨씬 쉽게이 작업을 수행 할 수 있습니다. 신속하게 사용하고 적용 할 수있는 더 많은 도구가 있습니다.

역사적으로 Logs는 공식적이고 손으로 쓴 일련의 사건 기록이었습니다. 기계가 이벤트를 기록 할 수있게되었을 때, 이들은 텔레타이프 프린터와 같은 하드 카피 출력 장치에 기록되어 영구적 인 순차 기록을 생성했지만 텍스트 만 처리하고 때로는 벨을 울릴 수있었습니다.

메인 프레임 시절에, 우리는 맞춤 설계된 이진 로그 형식을 사용했습니다. 주된 이유는 공간을 절약하기위한 것이 아니라 오래된 항목을 새로운 항목으로 덮어 써서 로그가 유한 공간을 차지하기를 원했기 때문입니다. 우리가 원했던 마지막 것은 디스크가 가득 찼기 때문에 발생하는 문제를 진단 할 수 없었습니다.

이제 나는 여전히 순환 로그 파일이라는 아이디어를 좋아하며 운영 체제가 그러한 짐승을 제공한다면 망설이지 않고 사용할 것입니다. 그러나 바이너리는 나쁜 생각이었습니다. 중요한 문제를 해결할 때 로그 파일을 해독하기위한 올바른 명령을 찾는 데 시간을 낭비하지 않아도됩니다.