Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 1 | // Copyright 2020 The Monogon Project Authors. |
| 2 | // |
| 3 | // SPDX-License-Identifier: Apache-2.0 |
| 4 | // |
| 5 | // Licensed under the Apache License, Version 2.0 (the "License"); |
| 6 | // you may not use this file except in compliance with the License. |
| 7 | // You may obtain a copy of the License at |
| 8 | // |
| 9 | // http://www.apache.org/licenses/LICENSE-2.0 |
| 10 | // |
| 11 | // Unless required by applicable law or agreed to in writing, software |
| 12 | // distributed under the License is distributed on an "AS IS" BASIS, |
| 13 | // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 14 | // See the License for the specific language governing permissions and |
| 15 | // limitations under the License. |
| 16 | |
| 17 | /* |
| 18 | Package logtree implements a tree-shaped logger for debug events. It provides log publishers (ie. Go code) with a |
Serge Bazanski | 12971d6 | 2020-11-17 12:12:58 +0100 | [diff] [blame^] | 19 | glog-like API and io.Writer API, with loggers placed in a hierarchical structure defined by a dot-delimited path |
| 20 | (called a DN, short for Distinguished Name). |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 21 | |
| 22 | tree.MustLeveledFor("foo.bar.baz").Warningf("Houston, we have a problem: %v", err) |
Serge Bazanski | 12971d6 | 2020-11-17 12:12:58 +0100 | [diff] [blame^] | 23 | fmt.Fprintf(tree.MustRawFor("foo.bar.baz"), "some\nunstructured\ndata\n") |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 24 | |
| 25 | Logs in this context are unstructured, operational and developer-centric human readable text messages presented as lines |
| 26 | of text to consumers, with some attached metadata. Logtree does not deal with 'structured' logs as some parts of the |
| 27 | industry do, and instead defers any machine-readable logs to either be handled by metrics systems like Prometheus or |
| 28 | event sourcing systems like Kafka. |
| 29 | |
| 30 | Tree Structure |
| 31 | |
Serge Bazanski | 06d65bc | 2020-09-24 10:51:59 +0200 | [diff] [blame] | 32 | As an example, consider an application that produces logs with the following DNs: |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 33 | |
| 34 | listener.http |
Serge Bazanski | 06d65bc | 2020-09-24 10:51:59 +0200 | [diff] [blame] | 35 | listener.grpc |
| 36 | svc |
| 37 | svc.cache |
| 38 | svc.cache.gc |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 39 | |
| 40 | This would correspond to a tree as follows: |
| 41 | |
| 42 | .------. |
| 43 | | "" | |
| 44 | | (root) | |
| 45 | '------' |
| 46 | .----------------' '------. |
| 47 | .--------------. .---------------. |
| 48 | | svc | | listener | |
| 49 | '--------------' '---------------' |
| 50 | | .----' '----. |
| 51 | .--------------. .---------------. .---------------. |
| 52 | | svc.cache | | listener.http | | listener.grpc | |
| 53 | '--------------' '---------------' '---------------' |
| 54 | | |
| 55 | .--------------. |
| 56 | | svc.cache.gc | |
| 57 | '--------------' |
| 58 | |
| 59 | In this setup, every DN acts as a separate logging target, each with its own retention policy and quota. Logging to a DN |
| 60 | under foo.bar does NOT automatically log to foo - all tree mechanisms are applied on log access by consumers. Loggers |
| 61 | are automatically created on first use, and importantly, can be created at any time, and will automatically be created |
| 62 | if a sub-DN is created that requires a parent DN to exist first. Note, for instance, that a `listener` logging node was |
| 63 | created even though the example application only logged to `listener.http` and `listener.grpc`. |
| 64 | |
| 65 | An implicit root node is always present in the tree, accessed by DN "" (an empty string). All other logger nodes are |
| 66 | children (or transitive children) of the root node. |
| 67 | |
| 68 | Log consumers (application code that reads the log and passes them on to operators, or ships them off for aggregation in |
| 69 | other systems) to select subtrees of logs for readout. In the example tree, a consumer could select to either read all |
| 70 | logs of the entire tree, just a single DN (like svc), or a subtree (like everything under listener, ie. messages emitted |
| 71 | to listener.http and listener.grpc). |
| 72 | |
Serge Bazanski | 12971d6 | 2020-11-17 12:12:58 +0100 | [diff] [blame^] | 73 | Leveled Log Producer API |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 74 | |
| 75 | As part of the glog-like logging API available to producers, the following metadata is attached to emitted logs in |
| 76 | addition to the DN of the logger to which the log entry was emitted: |
| 77 | |
| 78 | - timestamp at which the entry was emitted |
| 79 | - a severity level (one of FATAL, ERROR, WARN or INFO) |
| 80 | - a source of the message (file name and line number) |
| 81 | |
| 82 | In addition, the logger mechanism supports a variable verbosity level (so-called 'V-logging') that can be set at every |
| 83 | node of the tree. For more information about the producer-facing logging API, see the documentation of the LeveledLogger |
| 84 | interface, which is the main interface exposed to log producers. |
| 85 | |
Serge Bazanski | 12971d6 | 2020-11-17 12:12:58 +0100 | [diff] [blame^] | 86 | If the submitted message contains newlines, it will be split accordingly into a single log entry that contains multiple |
| 87 | string lines. This allows for log producers to submit long, multi-line messages that are guaranteed to be non-interleaved |
| 88 | with other entries, and allows for access API consumers to maintain semantic linking between multiple lines being emitted |
| 89 | as a single atomic entry. |
| 90 | |
| 91 | Raw Log Producer API |
| 92 | |
| 93 | In addition to leveled, glog-like logging, LogTree supports 'raw logging'. This is implemented as an io.Writer that will |
| 94 | split incoming bytes into newline-delimited lines, and log them into that logtree's DN. This mechanism is primarily |
| 95 | intended to support storage of unstructured log data from external processes - for example binaries running with redirected |
| 96 | stdout/stderr. |
| 97 | |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 98 | Log Access API |
| 99 | |
| 100 | The Log Access API is mostly exposed via a single function on the LogTree struct: Read. It allows access to log entries |
| 101 | that have been already buffered inside LogTree and to subscribe to receive future entries over a channel. As outlined |
| 102 | earlier, any access can specify whether it is just interested in a single logger (addressed by DN), or a subtree of |
| 103 | loggers. |
| 104 | |
| 105 | Due to the current implementation of the logtree, subtree accesses of backlogged data is significantly slower than |
| 106 | accessing data of just one DN, or the whole tree (as every subtree backlog access performs a scan on all logged data). |
| 107 | Thus, log consumers should be aware that it is much better to stream and buffer logs specific to some long-standing |
| 108 | logging request on their own, rather than repeatedly perform reads of a subtree backlog. |
| 109 | |
Serge Bazanski | 12971d6 | 2020-11-17 12:12:58 +0100 | [diff] [blame^] | 110 | The data returned from the log access API is a LogEntry, which itself can contain either a raw logging entry, or a leveled |
| 111 | logging entry. Helper functions are available on LogEntry that allow canonical string representations to be returned, for |
| 112 | easy use in consuming tools/interfaces. Alternatively, the consumer can itself access the internal raw/leveled entries and |
| 113 | print them according to their own preferred format. |
| 114 | |
Serge Bazanski | 5faa2fc | 2020-09-07 14:09:30 +0200 | [diff] [blame] | 115 | */ |
| 116 | package logtree |