swift log
Swift Log 1.6.1
가장 먼저 해야 할 일: 이는 코드, 문서 또는 아이디어 등 적극적으로 기여를 추구하는 커뮤니티 중심 오픈 소스 프로젝트의 시작입니다. SwiftLog 자체에 기여하는 것 외에도 현재 또 다른 큰 격차가 있습니다. SwiftLog 는 생태계가 사용할 수 있는 공통 API를 구축하려는 API 패키지 입니다. 실제 워크로드에서 로깅이 실제로 작동하도록 하려면 로그 메시지를 파일에 유지하거나 터미널에서 더 멋진 색상으로 렌더링하거나 Splunk 또는 ELK로 보내는 SwiftLog 호환 로깅 백엔드가 필요합니다.
현재 SwiftLog 제공하는 내용은 API 문서에서 확인할 수 있습니다.
서버 측 Swift 애플리케이션 또는 크로스 플랫폼(예: Linux 및 macOS) 앱/라이브러리가 있고 로그를 작성하려는 경우 이 로깅 API 패키지를 대상으로 하는 것이 좋은 아이디어라고 생각합니다. 아래에서 시작하기 위해 알아야 할 모든 정보를 확인할 수 있습니다.
SwiftLog Swift 5.8 이상용으로 설계되었습니다. 로깅 API 패키지에 의존하려면 Package.swift 에서 종속성을 선언해야 합니다.
. package ( url : " https://github.com/apple/swift-log.git " , from : " 1.0.0 " ) , 애플리케이션/라이브러리 대상에 다음과 같이 dependencies 에 "Logging" 추가합니다.
. target ( name : " BestExampleApp " , dependencies : [
. product ( name : " Logging " , package : " swift-log " )
] , // 1) let's import the logging API package
import Logging
// 2) we need to create a logger, the label works similarly to a DispatchQueue label
let logger = Logger ( label : " com.example.BestExampleApp.main " )
// 3) we're now ready to use it
logger . info ( " Hello World! " ) 2019-03-13T15:46:38+0000 info: Hello World!
Logger 동작 SwiftLog StreamLogHandler 를 통해 기본적으로 매우 기본적인 콘솔 로깅을 제공합니다. 다음과 같이 기본 출력을 stderr 로 전환할 수 있습니다.
LoggingSystem . bootstrap ( StreamLogHandler . standardError ) StreamLogHandler 는 주로 편의를 위한 것이며 실질적인 사용자 정의를 제공하지 않습니다. 통합 및 소비를 위해 자체 로깅 백엔드를 구축하려는 라이브러리 관리자는 "로깅 백엔드 구현" 섹션에 설명된 대로 LogHandler 프로토콜을 직접 구현해야 합니다.
자세한 내용은 API 설명서를 확인하세요.
다음 백엔드 중 하나를 선택하여 로그를 사용할 수 있습니다. 구현에 관심이 있는 경우 구현 방법을 설명하는 아래의 "구현 고려 사항" 섹션을 참조하세요. 기존 SwiftLog API 호환 라이브러리 목록:
| 저장소 | 핸들러 설명 |
|---|---|
| Kitura/헬륨로거 | Kitura 생태계에서 널리 사용되는 로깅 백엔드 |
| ianpartridge/swift-log- syslog | syslog 백엔드 |
| Adorkable/swift-log- 형식 및 파이프 | 출력 형식과 결과 대상을 사용자 정의할 수 있는 백엔드 |
| chrisaljoudi/swift-log- oslog | Apple 플랫폼에서 사용하기 위한 OSLog 통합 로깅 백엔드. 중요 참고 사항: 여기에 설명된 대로 os_log를 직접 사용하는 것이 좋습니다. 이 백엔드를 사용하여 Swift-log를 통해 os_log를 사용하면 효율성이 떨어지며 메시지의 개인 정보 보호를 지정하지 못하게 됩니다. 백엔드는 항상 %{public}@ 형식 문자열로 사용하고 모든 문자열 보간을 문자열로 변환합니다. 여기에는 두 가지 단점이 있습니다. 1. 문자열 보간의 정적 구성 요소가 통합 로깅 시스템에 의해 열심히 복사되어 성능이 저하됩니다. 2. 모든 메시지를 공개합니다. 이는 os_log의 기본 개인 정보 보호 정책을 변경하고 메시지 섹션의 세분화된 개인 정보 보호 지정을 허용하지 않습니다. 별도의 진행 중인 작업에서 os_log용 Swift API가 개선되고 있으며 Swift-log API와 밀접하게 일치하도록 만들어졌습니다. 참고 자료: 로깅 수준 통합, os_log가 컴파일 타임 해석을 사용하여 문자열 보간을 허용하도록 만들기. |
| Brainfinance/StackdriverLogging | Stackdriver Logging 에이전트와 함께 Google Cloud Platform에서 사용할 수 있는 구조화된 JSON 로깅 백엔드 |
| DnV1eX/GoogleCloudLogging | REST API v2를 통해 Google Cloud에 애플리케이션 이벤트를 로깅하기 위한 클라이언트 측 라이브러리입니다. |
| 증기/콘솔 키트 | 현재 터미널에 대한 로거 또는 양식화된(ANSI) 출력이 있는 stdout. 모든 Vapor 애플리케이션의 기본 로거 |
| Neallester/swift-log-testing | (테스트 대상 내에서) 어설션에 사용할 로그 메시지에 대한 액세스를 제공합니다. |
| wlisac/swift-log-slack | Slack에 중요한 로그 메시지를 보내는 로깅 백엔드 |
| NSHipster/swift-log-github-actions | 로깅 메시지를 GitHub Actions용 워크플로 명령으로 변환하는 로깅 백엔드입니다. |
| stevapple/swift-log-텔레그램 | 모든 Telegram 채팅에 로그 메시지를 보내는 로깅 백엔드(wlisac/swift-log-slack에서 영감을 얻어 분기됨) |
| jagreenwood/swift-log-datadog | Datadog 로그 관리 서비스에 로그 메시지를 보내는 로깅 백엔드 |
| 구글/SwiftLogFireCloud | 로그를 플랫 파일로 Firebase Cloud Storage에 푸시하는 시계열 로깅을 위한 로깅 백엔드입니다. |
| crspybits/swift-log-파일 | 간단한 로컬 파일 로거 ( Foundation FileManager 사용) |
| 초밥초밥/강아지 | 다중 전송(콘솔, 파일, syslog 등)을 지원하고 포맷팅 및 파일 로그 회전 기능을 갖춘 로깅 백엔드 |
| ShivaHuang/swift-log-SwiftyBeaver | Xcode 콘솔/파일에 컬러 로깅을 인쇄하거나 SwiftyBeaver 플랫폼에 암호화된 로깅을 보내기 위한 로깅 백엔드. |
| Apodini/swift-log-elk | 로그 데이터를 포맷하고, 캐시하고, Elastic/logstash로 보내는 로깅 백엔드 |
| 바이너리 스크래핑/swift-log-supabase | 로그 항목을 Supabase로 보내는 로깅 백엔드. |
| 킬리안코에/swift-log-matrix | 로그를 Matrix 룸으로 직접 전송하기 위한 로깅 백엔드 |
| DiscordBM/DiscordLogger | warning / error / critical 와 같은 몇 가지 중요한 로그 수준만 보내는 기능을 포함하여 다양한 구성 옵션을 사용하여 멋진 방식으로 Discord 채널에 로그를 보내는 Discord 로깅 구현입니다. |
| 코코아나무꾼 | macOS, iOS, tvOS 및 watchOS를 위한 빠르고 간단하면서도 강력하고 유연한 로깅 프레임워크입니다. 여기에는 Swift-log용 로깅 백엔드가 포함되어 있습니다. |
| rwbutler/swift-log-ecs | ECS 로그 형식으로 로그인하기 위한 로깅 백엔드. Vapor과 호환되며 여러 LogHandler를 연결할 수 있습니다. |
| ShipBook/swift-log -shipbook | Shipbook에 로그 항목을 보내는 로깅 백엔드 - Shipbook은 사용자별 및 세션별로 클라우드에서 사용자 로그 및 예외를 원격으로 수집, 검색 및 분석할 수 있는 기능을 제공합니다. |
| 당신의 도서관? | 연락하세요! |
물어봐서 다행이에요. 우리는 Swift on Server 에코시스템의 경우, 누구나 채택할 수 있는 로깅 API를 보유하여 다양한 당사자의 수많은 라이브러리가 모두 공유 대상에 로깅할 수 있도록 하는 것이 중요하다고 믿습니다. 보다 구체적으로 이는 모든 라이브러리의 모든 로그 메시지가 동일한 파일, 데이터베이스, Elastic Stack/Splunk 인스턴스 또는 귀하가 선택할 수 있는 모든 것에 있다고 믿는다는 것을 의미합니다.
그러나 실제 세계에서는 로깅 시스템이 정확히 어떻게 작동해야 하는지, 로그 메시지의 형식은 무엇인지, 메시지가 어디에/어떻게 유지되어야 하는지에 대한 의견이 너무 많습니다. 우리는 하나의 로깅 패키지가 특정 배포에 필요한 모든 것을 지원하면서도 사용하기 쉽고 성능을 유지할 때까지 기다리는 것은 불가능하다고 생각합니다. 이것이 바로 우리가 문제를 절반으로 줄이기로 결정한 이유입니다.
이 패키지는 로깅 API 자체만 제공하므로 SwiftLog '로깅 API 패키지'입니다. 호환 가능한 로깅 백엔드 구현을 선택하도록 SwiftLog ( LoggingSystem.bootstrap 사용)를 구성할 수 있습니다. 이러한 방식으로 패키지는 API를 채택할 수 있으며 애플리케이션은 라이브러리를 변경할 필요 없이 호환 가능한 로깅 백엔드 구현을 선택할 수 있습니다.
완전성을 기하기 위해: 이 API 패키지에는 실제로 모든 로그 메시지를 stdout 에 쓰는 지나치게 단순하고 구성할 수 없는 로깅 백엔드 구현이 포함되어 있습니다. 이렇게 지나치게 단순한 로깅 백엔드 구현을 포함하는 이유는 최초 사용 경험을 개선하기 위한 것입니다. 프로젝트를 시작하고 처음으로 SwiftLog 시험해본다고 가정해 보겠습니다. 아무 일도 일어나지 않는 것보다 기록한 내용이 단순한 형식으로 stdout 에 나타나는 것이 훨씬 더 좋습니다. 실제 애플리케이션의 경우 원하는 스타일로 로그인하는 다른 로깅 백엔드 구현을 구성하는 것이 좋습니다.
Logger 는 로그 메시지를 내보내는 데 사용되므로 SwiftLog 에서 가장 중요한 유형이므로 사용은 최대한 간단해야 합니다. 가장 일반적으로 특정 로그 수준에서 로그 메시지를 내보내는 데 사용됩니다. 예를 들어:
// logging an informational message
logger . info ( " Hello World! " )
// ouch, something went wrong
logger . error ( " Houston, we have a problem: ( problem ) " )다음 로그 수준이 지원됩니다.
tracedebuginfonoticewarningerrorcritical 특정 로거의 로그 수준은 변경될 수 있지만 변경 사항은 변경한 특정 로거에만 영향을 미칩니다. Logger 는 로그 수준에 관한 값 유형 이라고 할 수 있습니다.
로깅 메타데이터는 문제를 디버깅할 때 중요한 정보를 추가하기 위해 로거에 연결할 수 있는 메타데이터입니다. 서버에서 일반적인 예는 요청 UUID를 로거에 첨부한 다음 해당 로거에 기록된 모든 로그 메시지에 표시되는 것입니다. 예:
var logger = logger
logger [ metadataKey : " request-uuid " ] = " ( UUID ( ) ) "
logger . info ( " hello world " )인쇄할 것이다
2019-03-13T18:30:02+0000 info: request-uuid=F8633013-3DD8-481C-9256-B296E43443ED hello world
SwiftLog 와 함께 제공되는 기본 로깅 백엔드 구현을 사용합니다. 말할 필요도 없이 형식은 선택한 로깅 백엔드에 의해 완전히 정의됩니다.
LogHandler )참고: 사용자 정의 로깅 백엔드를 구현하고 싶지 않은 경우 이 섹션의 모든 내용은 그다지 관련성이 없을 수 있으므로 건너뛰어도 됩니다.
모든 SwiftLog 소비자가 사용할 수 있는 호환 가능한 로깅 백엔드가 되려면 다음 두 가지 작업을 수행해야 합니다. 1) SwiftLog 에서 제공하는 프로토콜인 LogHandler 구현하는 유형(일반적으로 struct )을 구현하고 2) SwiftLog 에 로깅 백엔드 구현을 사용하도록 지시합니다. .
LogHandler 또는 로깅 백엔드 구현은 다음 프로토콜을 준수하는 모든 것입니다.
public protocol LogHandler {
func log ( level : Logger . Level , message : Logger . Message , metadata : Logger . Metadata ? , source : String , file : String , function : String , line : UInt )
subscript ( metadataKey _ : String ) -> Logger . Metadata . Value ? { get set }
var metadata : Logger . Metadata { get set }
var logLevel : Logger . Level { get set }
} 전체 애플리케이션(모든 라이브러리 포함)이 사용해야 하는 로깅 백엔드를 SwiftLog 에 사용하도록 지시하는 것은 매우 간단합니다.
LoggingSystem . bootstrap ( MyLogHandler . init ) LogHandler 는 로깅 시스템의 대부분을 제어합니다.
LogHandler 의 제어를 받음 LogHandler 는 Logger 구성의 두 가지 중요한 부분, 즉 다음을 제어합니다.
logger.logLevel 속성)logger[metadataKey:] 및 logger.metadata ) 그러나 시스템이 작동하려면 LogHandler 구성을 값 유형 으로 처리하는 것이 중요합니다. 즉, LogHandler 는 struct 여야 하며 로그 수준 또는 로깅 메타데이터의 변경은 변경된 LogHandler 에만 영향을 미쳐야 합니다.
그러나 특별한 경우에는 LogHandler 가 생성된 모든 LogHandler 에 영향을 미칠 수 있는 전역 로그 수준 재정의를 제공하는 것이 허용됩니다.
LogHandler 의 제어를 받지 않음 LogHandler 는 메시지를 기록할지 여부를 제어하지 않습니다. Logger 구성된 로그 수준에 따라 로그 메시지를 내보내야 한다고 Logger 결정한 경우에만 LogHandler 의 log 기능을 호출합니다.
Logger (불변) label 전달하고 각 로그 메시지는 source 매개변수를 전달합니다(SwiftLog 1.3.0부터). Logger 의 레이블은 Logger 의 작성자를 식별합니다. 여러 모듈에 걸쳐 메타데이터를 보존하여 구조화된 로깅을 사용하는 경우 Logger 의 label 메타데이터를 보존하기 위해 라이브러리 간에 자주 전달되는 Logger 의 작성자를 식별하므로 로그 메시지가 어디서 왔는지 식별하는 좋은 방법이 아닙니다. 같은.
특정 하위 시스템에서 발생하는 모든 로그 메시지를 필터링하려면 로그 메시지를 내보내는 모듈을 기본값으로 하는 source 별로 필터링하세요.
SwiftLog의 보안 프로세스는 SECURITY.md를 참조하세요.
이 로깅 API는 Swift on Server 커뮤니티의 기여자들과 함께 설계되었으며 SSWG(Swift Server Work Group)에서 SSWG 인큐베이션 프로세스의 '샌드박스 수준'으로 승인되었습니다.
