일지 수집 에 대한 생각

머리말
저 는 회사 의 nginx 로그 수집 을 담당 해 왔 습 니 다. 현재 매일 pv 수 는 10 억 등급 이 고 대략 1T (* 2 기본 elasticsearch 5 분 2 던 전) 가 저장 되 지 않 습 니 다. 처음에 nginx 로그 도 점점 수집 되 었 기 때 문 입 니 다. 처음 하 는 문제 도 많 기 때문에 우리 의 ELK 플랫폼 이 성숙 되 기 를 기다 리 고 응용 로 그 를 받 으 려 고 합 니 다.
당면 한 문제
현재 로그 통 증 을 개발 하고 있다 면 온라인 인 스 턴 스 가 많은 애플 리 케 이 션 입 니 다. 한두 개 만 있 으 면 서버 에 로그 인하 여 로 그 를 보 는 것 도 좋 습 니 다.그러나 일부 응용 라인 에는 30 여 개의 인 스 턴 스 가 있 는데 문제 가 있 으 면 우리 에 게 ansible 이라는 도 구 를 대량으로 찾 아 보 는 것 도 효과 가 없 지만 그런 상황 도 비교적 적다.로 그 를 수집 하면 제 가 계산 해 봤 습 니 다. 만약 에 모두 수집 하면 매일 5T 정도 걸 릴 것 입 니 다. 아마 더 많 을 것 입 니 다. 주로 온라인 로그 의 종류 도 많 고 양 도 많 습 니 다. 우 리 는 인 스 턴 스 를 사용 하여 하루 에 20G 의 로 그 를 칠 수 있 습 니 다. 그리고 하루 에 200 여 G 의 오류 로 그 를 잘못 보고 해서 수집 하면 문제 가 될 것 같 습 니 다.
초기의 사고
처음에 다른 회사 에서 새로 입사 한 동료 에 게 물 어 봤 습 니 다. 어떤 이 는 응용 프로그램 에서 호출 된 로그 만 수집 할 수 있다 고 했 습 니 다. 일반적으로 문제 가 발생 하 는 것 은 응용 프로그램 에서 호출 된 문제 이기 때 문 입 니 다. 응용 프로그램 에서 호출 된 문제 가 발견 되 지 않 으 면 로그 인 을 통 해 로 그 를 볼 수 있 습 니 다.사실 원가 효 익 으로 분석 하면 괜 찮 지만 로 그 를 작성 해 야 한 다 는 것 은 로그 가 가치 가 있다 는 것 을 설명 하고 볼 필요 가 있다. 그리고 elasticsearch 의 전문 검색 이 정말 좋 습 니 다. 로 그 를 개발 하 는 체험 은 높 은 향상 을 얻 을 수 있 습 니 다.과 다 하 지 는 않 습 니 다. 정말 큰 비용 이 들 것 같 습 니 다. 그리고 현재 개발 과 우리 의 운영 피드백 이 없 기 때문에 로 그 를 보 는 것 이 아 픕 니 다. 그래서 늦게 하지 않 았 습 니 다.또 하나의 중요 한 이 유 는 로그 형식 을 사용 하 는 문제 입 니 다. 저 는 Pinterest 가 공유 에서 언급 한 로그 형식 요구 에 경향 이 있 습 니 다.

       ，          
     JSON•             

id: string // mandatory; globally unique to identify a log record. It can be a structure with timestamp.
timestamp: date // mandatory; when the log records are created.
service: string // uniquely identify a service which generates the log record.
project: string // or organization so that we can teams can be associated with
host: string // name of the host creating the log
env: string // deployment env
stage: string // deployment stage
version: string // git commit number
tags: { } // labels consisting of key value pair assuming both key and values are strings for expansion by clients. This can include locale or organization and so on.
payload_encoding: string // can be either string, JSON, base64 encoded binary format and so on. string by default
payload : // mandatory

위의 로그 규범, 내 생각 은 timestamp 가 time ios 8601 의 형식 보다 가 독성 이 높다 는 것 이다.그러나 이런 것 을 규범화 시 키 는 것 은 모두 가 하기 전에 잘 미 루 었 다. 일단 시스템 이 오랫동안 운행 되면 그들 에 게 고치 라 고 해라. 이 어 려 운 일 을 한 사람 은 모두 알 고 있다.(나 는 유명인 의 명언 이 비슷 하 다 는 뜻 으로 기억한다. 우 리 는 개선 하 는 것 을 좋아 하고 변 하 는 것 을 좋아 하지 않 는 다)
전환점
지난번 에 구조 진경 을 보고 그 선 리 기 가 로그 수집 에 관 한 것 을 보 았 을 때 눈 에 띄 는 느낌 이 들 었 습 니 다. 몇 마디 말 을 잘 한 것 같 습 니 다.
로 그 는 대가 가 있다 는 것 을 명심 해 야 한다. 이것 은 추가 데 이 터 를 유지 하 는 비용 뿐만 아니 라 사물 처리 응답 시간의 대가 도 포함한다.로그 의 원 가 를 주의해 야 합 니 다. 로 그 를 얼마나 기록 하 든 데 이 터 를 얼마나 저장 하 든 원가 효율 에 맞 는 결정 을 내 려 야 합 니 다.
그리고 일지 와 는 관계 가 크 지 않 지만 이 장의 마지막 충고 입 니 다. 저 는 공감 합 니 다.
모든 기술 을 도입 하려 면 다른 기능 이 필요 하 다. 비록 업무 중 에 적당 한 도 구 를 사용 하 는 것 이 중요 하지만 전문 화 를 지나치게 강조 하지 말고 적당 한 기능 깊이 로 지원 하지 말 아야 한다.
이것 을 본 후에 저 는 양 이 많은 문제 에 대한 응용 로 그 를 점차적으로 수집 하여 우리 가 모두 얼마나 많은 비용 을 지불해 야 하 는 지 볼 수 있다 고 생각 합 니 다.원가 효율 분석 을 잘 하고 일 지 를 점차 수집 하기 만 한다 면 나 는 일이 생각 보다 그렇게 어렵 지 않 을 것 이 라 고 생각한다.
그리고 기업 의 IT 구조 전환 의 길 을 본 적 이 있다. 알 리 바 바 중국 과 대만 의 전략 사상 과 구조 실전 이라는 책의 제7 장 을 본 후에 응용 로 그 는 일부분 만 수집 할 수 있 고 문 제 를 발견 할 수 있 으 며 서버 의 io 스트레스 를 줄 일 수 있다 는 것 을 알 게 되 었 다.
새로운 발상
바로 응용 로그 가 전부 수집 되 지 않 는 방안 에 대해 예전 에 thoughtwork 의 기술 레이더 에 적 힌 적 이 있 습 니 다. 현재 마이크로 서비스 가 유행 하 는 환경 에서 응용 로그 수집 은 큰 도전 입 니 다. 일부분 만 수집 하면 중요 한 정 보 를 잃 어 버 릴 수도 있 습 니 다. log level per request 는 고려 할 수 있 지만 이런 방안 은저 는 구 글 에서 자 료 를 많이 검색 하지 못 하고 통제 하기 어렵 고 업계 에서 도 성숙 한 해결 방안 이 없 을 것 입 니 다.일부 로그 만 수집 합 니 다.
또 하 나 는 권력과 책임 의 문제 입 니 다. 로 그 를 개발 하 는 경우 가 많 습 니 다. 온라인 에 문제 가 있어 서 찾 을 수 없 기 때문에 더 자세 한 로 그 를 필요 로 합 니 다. 그러나 이렇게 되면 온라인 로 그 는 증가 하고 감소 하지 않 습 니 다. 그들 은 문 제 를 해결 하 는 일 만 맡 기 때 문 입 니 다. 온라인 서버 의 io 압력, 로그 저장 비용 등 이 모두 우리 에 게 있 습 니 다.이것 이 권력과 책임 의 불 균형 이 라 고 생각 합 니 다. 개발 이 로그 증가 의 이익 뿐만 아니 라 로그 증가 의 폐 해 를 감당 할 수 있 는 방법 이 있다 면 상황 이 많이 개선 되 었 을 것 이 라 고 생각 합 니 다.이 문제 에 대해 사실은 이 왕 이 운 유 초 선생님 의 글 을 볼 수 있 습 니 다.