JJSwiftLog

In the development of this library, we need to set a goal for it, the log library for us to solve the problem, why we need a log library to assist our development, and what is the value of the log library, I summarized the following points:

  • Debugging development

In the development stage, important information is output to assist development to help locate information quickly and improve the efficiency of finding problems. At the same time, important information should be displayed

  • Troubleshoot online problems

Logs record information about important paths and error information. Besides debugging, logs are effective means to rectify faults

  • Record important Information

Each service records important information to the log library. The log library can be saved to the desired location for viewing and analysis

The problem

Log library issues to be aware of:

  • I/O and CPU usage problems, as much as possible to reduce the impact on the system, so that access parties have no concerns about this

  • Performance problems, as a log library does not want to affect the overall app fluency, can quickly deal with all situations, this is the basic requirements of the log library

  • Stability, which is also a basic requirement of log libraries

  • Security, local storage or network storage needs to be aware of issues, to ensure that information is not leaked and tampered with

Architecture location and redundancy design

Log should be one of the most basic library, should be at the bottom of the library, for the bottom, and business services, from it should be at the bottom level, except, of course, if some of the library can’t rely on special cases, because of the following will be referred to the security and network, my understanding is that this may take us through redundancy design to solve the problem of relying on, to ensure that the logging library cohesion, Keeping external coupling to a minimum and making it feel lightweight to access, but functional when used, is my design principle for logging libraries.

Note a few details of the architecture diagram:

  1. Domain Log with dotted lines (domain-specific Log/ function-specific Log). This is optional
  2. Platform at the bottom allows for the possibility that logging may need to be cross-platform to further improve performance

Log performance

  • NSLOG

ASL, send logs through client Connection, Device Console AND the Debugger Console

  • os_log

Available only after iOS 10, it provides a variety of log levels. You need to import OS, Device Console AND the Debugger Console

  • Swift of print

It is only displayed on the Debug Console, and the principle is still shown to the terminal through the wrapped API and the final call to Putchar

  • stdout, stderr

Due to UNIX’s file-as-a-file nature, any process has one input and two outputs, stdout and stderr, which correspond to the log level and are generally used for Console

  • TTY

You can output logs to the terminal device

For now, it’s all about completing the Console and File functions. When considering performance, one needs to understand the rationale behind each selection so that you can accurately assess how much space there is. I consider the following factors when evaluating:

  1. Realization principle of technology selection
  2. The level of technology selection
  3. Compatibility and history issues

Console

Finally, STdout and STderr are selected to realize the output to the terminal. Stdout itself is bound with application, and is realized by UNIX C function with Buffer function, so it is finally selected to display to the terminal

(File)

The document mainly focuses on two schemes:

  • FILE

This is a C-level API. The operation mode is relatively primitive and the performance is higher than the encapsulated API. Moreover, the feature of this scenario is small file storage, so this API is relatively suitable

  • MMAP

This scheme can be used when MMAP has higher requirements on performance, but it has relatively high requirements on users. I will not expand on this, but I will describe it in detail here

Log library stability

The reason why this point is mentioned is that it is used frequently and in many scenarios, so the log library has high stability requirements, and users cannot accept the possibility of bugs. Therefore, we need to ensure our stability and put forward relatively high requirements. How do we do it at ordinary times:

  1. The architectural design is reviewed by the core developers
  2. PR code needs to be reviewed by at least two senior developers
  3. UnitTest is required to gradually improve coverage
  4. The larger adjustments are published through the grayscale of the business side

Log security

Security is relative, not absolute

Both persistence and network storage need to pay attention to data security issues. Conventional solutions are as follows:

  • Symmetric encryption (DES, 3DES, DESX, Blowfish, IDEA, RC4, RC5, RC6, AES). DES. DES)

  • Asymmetric encryption (RSA, Elgamal, Knapsack algorithm, Rabin, D-H, ECC)

Through the above means, information needs to be restored by Key when it is stored and transmitted. Each company attaches different importance to this, so this part can be realized according to its own actual situation. However, it is strongly suggested that it should be encrypted to ensure the security of data

Description of The Extension

The following part has not been implemented yet, but it does not affect our discussion and learning of technology, so the following part is to record my understanding and learning of these functions. If it needs to be implemented later, it is only a process of coding, and there is no need to spend time on research, and the latest knowledge may also need to be updated. The principle is basically the same with minor differences.

Log sharding (extended)

Log fragmentation is required because all recorded logs need to be restored during the persistence process. Therefore, logs need to be stored according to a certain fragmentation policy and then restored according to the established rules.

The rule for generating log files is as follows: Time + device fingerprint +(optional user Id)

Sharding is based on:

  • The file size
  • The interval at which files are generated

This is a general condition and can be defined flexibly according to its own business characteristics. There is no uniform rule for this.

Log retrieval (extended)

The scenario of log retrieval solution is that the client misses the window to upload logs and needs to obtain user logs at any time, which needs to use the long connection technology to assist to achieve the purpose. If the company does not have it, the SDK similar to aurora can be used instead.

You can obtain logs by:

  • Report when the App starts
  • Upload according to the rules after the App starts
  • Passive upload via Push

For iOS, there is a problem that needs to be solved. If the App is in the killed or suspended state, it needs to obtain the user log. There are two solutions that are not perfect:

  1. App has background permission to keep App always active
  2. Notification Service Extension, which allows log sharing, can be used for uploading, and it needs to be in silent state, all prerequisite is the user agrees to receive the Notification

Github.com/jezzmemo/JJ…

reference

Github.com/DaveWoodCom…

SwiftyBeaver

Github.com/emaloney/Cl…

Swift print