swift log
Swift Log 1.6.1
Lo primero es lo primero: este es el comienzo de un proyecto de código abierto impulsado por la comunidad que busca activamente contribuciones, ya sea código, documentación o ideas. Además de contribuir al propio SwiftLog , existe otra gran brecha en este momento: SwiftLog es un paquete API que intenta establecer una API común que el ecosistema pueda usar. Para que el registro realmente funcione para cargas de trabajo del mundo real, necesitamos servidores de registro compatibles con SwiftLog que luego conserven los mensajes de registro en archivos, los muestren en colores más bonitos en el terminal o los envíen a Splunk o ELK.
Lo que SwiftLog ofrece hoy se puede encontrar en los documentos de la API.
Si tiene una aplicación Swift del lado del servidor, o tal vez una aplicación/biblioteca multiplataforma (por ejemplo, Linux y macOS), y desea iniciar sesión, creemos que apuntar a este paquete de API de registro es una gran idea. A continuación encontrará todo lo que necesita saber para comenzar.
SwiftLog está diseñado para Swift 5.8 y versiones posteriores. Para depender del paquete API de registro, debe declarar su dependencia en su Package.swift :
. package ( url : " https://github.com/apple/swift-log.git " , from : " 1.0.0 " ) , y a su aplicación/biblioteca de destino, agregue "Logging" a sus dependencies , por ejemplo, así:
. 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 proporciona un inicio de sesión de consola muy básico listo para usar mediante StreamLogHandler . Es posible cambiar la salida predeterminada a stderr así:
LoggingSystem . bootstrap ( StreamLogHandler . standardError ) StreamLogHandler es principalmente una conveniencia y no proporciona ninguna personalización sustancial. Los mantenedores de bibliotecas que deseen crear sus propios servidores de registro para la integración y el consumo deben implementar el protocolo LogHandler directamente como se establece en la sección "Sobre la implementación de un servidor de registro".
Para obtener más información, consulte la documentación de la API.
Puede elegir uno de los siguientes backends para consumir sus registros. Si está interesado en implementar uno, consulte la sección "Consideraciones de implementación" a continuación que explica cómo hacerlo. Lista de bibliotecas compatibles con SwiftLog API existentes:
| Repositorio | Descripción del controlador |
|---|---|
| Kitura/HelioLogger | un backend de registro ampliamente utilizado en el ecosistema de Kitura |
| ianpartridge/swift-log- syslog | un servidor syslog |
| Adorkable/swift-log- formato-y-pipe | un backend que permite la personalización del formato de salida y el destino resultante |
| chrisaljoudi/swift-log- oslog | un backend de registro unificado OSLog para usar en plataformas Apple. Nota importante: recomendamos usar os_log directamente como se describe aquí. Usar os_log a través de swift-log usando este backend será menos eficiente y también impedirá especificar la privacidad del mensaje. El backend siempre usa %{public}@ como cadena de formato y convierte con entusiasmo todas las interpolaciones de cadenas en cadenas. Esto tiene dos inconvenientes: 1. Los componentes estáticos de la interpolación de cadenas serían copiados con entusiasmo por el sistema de registro unificado, lo que resultaría en una pérdida de rendimiento. 2. Hace que todos los mensajes sean públicos, lo que cambia la política de privacidad predeterminada de os_log y no permite especificar la privacidad detallada de las secciones del mensaje. En un trabajo separado en curso, las API de Swift para os_log se están mejorando y alineando estrechamente con las API de Swift-log. Referencias: Unificación de niveles de registro, Hacer que os_log acepte interpolaciones de cadenas mediante interpretación en tiempo de compilación. |
| Brainfinance/StackdriverLogging | un backend de registro JSON estructurado para usar en Google Cloud Platform con el agente de registro Stackdriver |
| DnV1eX/GoogleCloudLogging | una biblioteca del lado del cliente para registrar eventos de aplicaciones en Google Cloud a través de REST API v2. |
| kit de vapor/consola | un registrador al terminal actual o salida estándar con salida estilizada (ANSI). El registrador predeterminado para todas las aplicaciones de Vapor |
| neallester/prueba-de-registro-swift | proporciona acceso a mensajes de registro para su uso en afirmaciones (dentro de los objetivos de prueba) |
| wlisac/swift-log-slack | un backend de registro que envía mensajes de registro críticos a Slack |
| NSHipster/swift-log-github-acciones | un backend de registro que traduce mensajes de registro en comandos de flujo de trabajo para GitHub Actions. |
| stevapple/swift-log-telegrama | un backend de registro que envía mensajes de registro a cualquier chat de Telegram (inspirado y bifurcado de wlisac/swift-log-slack) |
| jagreenwood/swift-log-datadog | un backend de registro que envía mensajes de registro al servicio de administración de registros de Datadog |
| google/SwiftLogFireCloud | un backend de registro para el registro de series temporales que envía los registros como archivos planos a Firebase Cloud Storage. |
| crspybits/archivo-de-registro-swift | un registrador de archivos local simple (usando Foundation FileManager ) |
| chuleta de sushi/cachorro | un backend de registro que admite múltiples transportes (consola, archivos, syslog, etc.) y tiene la función de formato y rotación de registros de archivos |
| ShivaHuang/swift-log-SwiftyBeaver | un backend de registro para imprimir registros en color en la consola/archivo Xcode, o enviar registros cifrados a la plataforma SwiftyBeaver. |
| Apodini/alce-registro veloz | un backend de registro que formatea, almacena en caché y envía datos de registro a elastic/logstash |
| binarioscraping/swift-log-supabase | un backend de registro que envía entradas de registro a Supabase. |
| kiliankoe/swift-log-matriz | un backend de registro para enviar registros directamente a una sala Matrix |
| DiscordBM/DiscordLogger | una implementación de registro de Discord para enviar sus registros a un canal de Discord de una manera atractiva y con muchas opciones de configuración, incluida la capacidad de enviar solo algunos niveles de registro importantes, como warning / error / critical . |
| CacaoLeñador | un marco de registro rápido y simple, pero potente y flexible para macOS, iOS, tvOS y watchOS, que incluye un backend de registro para swift-log. |
| rwbutler/swift-log-ecs | un backend de registro para iniciar sesión en formato de registro ECS. Compatible con Vapor y permite encadenar múltiples LogHandlers. |
| ShipBook/swift-log -shipbook | un backend de registro que envía entradas de registro a Shipbook: Shipbook le brinda el poder de recopilar, buscar y analizar de forma remota sus registros de usuario y excepciones en la nube, por usuario y sesión. |
| ¿Tu biblioteca? | ¡Ponte en contacto! |
Me alegra que hayas preguntado. Creemos que para el ecosistema Swift on Server, es crucial tener una API de registro que cualquiera pueda adoptar para que una multitud de bibliotecas de diferentes partes puedan iniciar sesión en un destino compartido. Más concretamente, esto significa que creemos que todos los mensajes de registro de todas las bibliotecas terminan en el mismo archivo, base de datos, instancia de Elastic Stack/Splunk o lo que usted elija.
Sin embargo, en el mundo real, hay muchas opiniones sobre cómo debería comportarse exactamente un sistema de registro, cómo debería formatearse un mensaje de registro y dónde y cómo debería persistir. Creemos que no es factible esperar a que un paquete de registro admita todo lo que necesita una implementación específica y al mismo tiempo sea lo suficientemente fácil de usar y mantenga su rendimiento. Por eso decidimos reducir el problema a la mitad:
Este paquete solo proporciona la API de registro en sí y, por lo tanto, SwiftLog es un "paquete de API de registro". SwiftLog (usando LoggingSystem.bootstrap ) se puede configurar para elegir cualquier implementación de backend de registro compatible. De esta manera, los paquetes pueden adoptar la API y la aplicación puede elegir cualquier implementación de backend de registro compatible sin requerir ningún cambio en ninguna de las bibliotecas.
Solo para completar: este paquete API en realidad incluye una implementación de backend de registro demasiado simplista y no configurable que simplemente escribe todos los mensajes de registro en stdout . La razón para incluir esta implementación de backend de registro demasiado simplista es mejorar la experiencia de uso por primera vez. Supongamos que inicia un proyecto y prueba SwiftLog por primera vez, es mucho mejor ver algo que inició sesión en stdout en un formato simplista en lugar de que no suceda nada en absoluto. Para cualquier aplicación del mundo real, recomendamos configurar otra implementación de backend de registro que registre en el estilo que desee.
Los Logger se utilizan para emitir mensajes de registro y, por lo tanto, son el tipo más importante en SwiftLog , por lo que su uso debe ser lo más simple posible. Por lo general, se utilizan para emitir mensajes de registro en un determinado nivel de registro. Por ejemplo:
// logging an informational message
logger . info ( " Hello World! " )
// ouch, something went wrong
logger . error ( " Houston, we have a problem: ( problem ) " )Se admiten los siguientes niveles de registro:
tracedebuginfonoticewarningerrorcritical El nivel de registro de un registrador determinado se puede cambiar, pero el cambio solo afectará al registrador específico en el que lo cambió. Se podría decir que Logger es un tipo de valor con respecto al nivel de registro.
Los metadatos de registro son metadatos que se pueden adjuntar a los registradores para agregar información que es crucial al depurar un problema. En los servidores, el ejemplo habitual es adjuntar un UUID de solicitud a un registrador que luego estará presente en todos los mensajes de registro registrados con ese registrador. Ejemplo:
var logger = logger
logger [ metadataKey : " request-uuid " ] = " ( UUID ( ) ) "
logger . info ( " hello world " )imprimirá
2019-03-13T18:30:02+0000 info: request-uuid=F8633013-3DD8-481C-9256-B296E43443ED hello world
con la implementación de backend de registro predeterminada que se incluye con SwiftLog . No hace falta decir que el formato está completamente definido por el servidor de registro que elija.
LogHandler )Nota: Si no desea implementar un backend de registro personalizado, todo lo que se incluye en esta sección probablemente no sea muy relevante, así que no dude en omitirla.
Para convertirse en un backend de registro compatible que todos los consumidores SwiftLog puedan usar, debe hacer dos cosas: 1) implementar un tipo (generalmente una struct ) que implemente LogHandler , un protocolo proporcionado por SwiftLog y 2) indicarle SwiftLog que use su implementación de backend de registro. .
Un LogHandler o una implementación de backend de registro es cualquier cosa que se ajuste al siguiente protocolo
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 }
} Instruir SwiftLog para que use su backend de registro como el que debe usar toda la aplicación (incluidas todas las bibliotecas) es muy simple:
LoggingSystem . bootstrap ( MyLogHandler . init ) LogHandler controla la mayor parte del sistema de registro:
LogHandler Los LogHandler controlan las dos piezas cruciales de la configuración Logger , a saber:
logger.logLevel )logger[metadataKey:] y logger.metadata ) Sin embargo, para que el sistema funcione, es importante que LogHandler trate la configuración como tipos de valores . Esto significa que LogHandler s deben ser struct s y un cambio en el nivel de registro o en los metadatos de registro solo debería afectar al mismo LogHandler en el que se cambió.
Sin embargo, en casos especiales, es aceptable que un LogHandler proporcione alguna anulación del nivel de registro global que pueda afectar a todos LogHandler creados.
LogHandler s Los LogHandler no controlan si un mensaje debe registrarse o no. Logger solo invocará la función log de LogHandler si Logger determina que se debe emitir un mensaje de registro dado el nivel de registro configurado.
Un Logger lleva una label (inmutable) y cada mensaje de registro lleva un parámetro source (desde SwiftLog 1.3.0). La etiqueta del Logger identifica al creador del Logger . Si está utilizando el registro estructurado preservando metadatos en varios módulos, la label del Logger no es una buena forma de identificar de dónde se originó un mensaje de registro, ya que identifica al creador de un Logger que a menudo se pasa entre bibliotecas para preservar los metadatos y similares.
Si desea filtrar todos los mensajes de registro que se originan en un determinado subsistema, filtre por source , cuyo valor predeterminado es el módulo que emite el mensaje de registro.
Consulte SECURITY.md para conocer el proceso de seguridad de SwiftLog.
Esta API de registro fue diseñada con los contribuyentes de la comunidad Swift on Server y aprobada por el SSWG (Grupo de trabajo de Swift Server) para el "nivel de zona de pruebas" del proceso de incubación del SSWG.
