github.com/mongodb/grip@v0.0.0-20240213223901-f906268d82b9/README.rst (about) 1 ======================================================= 2 ``grip`` -- A Go Library for Logging and Error Handling 3 ======================================================= 4 5 ``grip`` isn't any thing special, but it does a few pretty great 6 things: 7 8 #. Provide a common logging interface with support for multiple 9 logging backends including syslog, systemd's journal, slack, xmpp, 10 a JSON logging system, and others. 11 12 #. Provides some simple methods for handling errors, particularly when 13 you want to accumulate and then return errors. 14 15 #. Provides tools for collecting structured logging information. 16 17 *You just get a grip, folks.* 18 19 Use 20 --- 21 22 Download: 23 24 :: 25 26 go get -u github.com/mongodb/grip 27 28 Import: 29 30 :: 31 32 import "github.com/mongodb/grip" 33 34 Components 35 ---------- 36 37 Output Formats 38 ~~~~~~~~~~~~~~ 39 40 Grip supports a number of different logging output backends: 41 42 - systemd's journal (linux-only) 43 - syslog (unix-only) 44 - writing messages to standard output. (default) 45 - writing messages to a file. 46 - sending messages to a slack's channel 47 - sending messages to a user via XMPP (jabber.) 48 49 The default logger interface has methods to switch the backend to 50 the standard output (native; default), and file-based loggers. The 51 SetSender() and CloneSender() methods allow to replace the sender 52 implementation in your logger. 53 54 See the documentation of the `Sender interface 55 <https://godoc.org/github.com/mongodb/grip/send#Sender>`_ for more 56 information on building new senders. 57 58 Logging 59 ~~~~~~~ 60 61 Provides a fully featured level-based logging system with multiple 62 backends (e.g. send.Sender). By default logging messages are printed 63 to standard output, but backends exists for many possible targets. The 64 interface for logging is provided by the Journaler interface. 65 66 By default ``grip.std`` defines a standard global instances 67 that you can use with a set of ``grip.<Level>`` functions, or you can 68 create your own ``Journaler`` instance and embed it in your own 69 structures and packages. 70 71 Defined helpers exist for the following levels/actions: 72 73 - ``Debug`` 74 - ``Info`` 75 - ``Notice`` 76 - ``Warning`` 77 - ``Error`` 78 - ``Critical`` 79 - ``Alert`` 80 - ``Emergency`` 81 - ``EmergencyPanic`` 82 - ``EmergencyFatal`` 83 84 Helpers ending with ``Panic`` call ``panic()`` after logging the message 85 message, and helpers ending with ``Fatal`` call ``os.Exit(1)`` after 86 logging the message. These are primarily for handling errors in your 87 main() function and should be used sparingly, if at all, elsewhere. 88 89 ``Journaler`` instances have a notion of "default" log levels and 90 thresholds, which provide the basis for verbosity control and sane 91 default behavior. The default level defines the priority/level of any 92 message with an invalid priority specified. The threshold level, 93 defines the minimum priority or level that ``grip`` sends to the 94 logging system. It's not possible to suppress the highest log level, 95 ``Emergency`` messages will always log. 96 97 ``Journaler`` objects have the following, additional methods (also 98 available as functions in the ``grip`` package to manage the global 99 standard logger instance.): 100 101 - ``SetName(<string>)`` to reset the name of the logger. ``grip`` 102 attempts to set this to the name of your program for the standard 103 logger. 104 105 - ``SetDefault(<level int>)`` change the default log level. Levels are 106 values between ``0`` and ``7``, where lower numbers are *more* 107 severe. ``grip`` does *not* forbid configurations where default 108 levels are *below* the configured threshold. 109 110 - ``SetThreshold(<level int>)`` Change the lowest log level that the 111 ``grip`` will transmit to the logging mechanism (either ``systemd`` 112 ``journald`` or Go's standard logging.) Log messages with lower 113 levels are not captured and ignored. 114 115 The ``Journaler.InvertFallback`` flag (bool) switches a ``Journaler`` 116 instance to prefer the standard logging mechanism rather than 117 ``systemd``. 118 119 By default: 120 121 - the log level uses the "Notice" level (``5``) 122 123 - the minimum threshold for logging is the "Info" level (``6``) 124 (suppressing only debug.) 125 126 - fallback logging writes to standard output. 127 128 Collector for "Continue on Error" Semantics 129 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 130 131 If you want to do something other than just swallow errors, but don't 132 need to hard abort, the ``MultiCatcher`` object makes this pattern 133 swell, a la: 134 135 :: 136 137 func doStuff(dirname string) (error) { 138 files, err := ioutil.ReadDir(dirname) 139 if err != nil { 140 // should abort here because we shouldn't continue. 141 return err 142 } 143 144 catcher := grip.NewCatcher() 145 for _, f := range files { 146 err = doStuffToFile(f.Name()) 147 catcher.Add(err) 148 } 149 150 return catcher.Resolve() 151 } 152 153 154 Simple Error Catching 155 ~~~~~~~~~~~~~~~~~~~~~ 156 157 Use ``grip.Catch(<err>)`` to check and print error messages. 158 159 There are also helper functions on ``Journaler`` objects that check 160 and log error messages using either the default (global) ``Journaler`` 161 instance, or as a method on specific ``Journaler`` instances, at all 162 levels: 163 164 - ``CatchDebug`` 165 - ``CatchInfo`` 166 - ``CatchNotice`` 167 - ``CatchWarning`` 168 - ``CatchError`` 169 - ``CatchCritical`` 170 - ``CatchAlert`` 171 - ``CatchEmergency`` 172 - ``CatchEmergencyPanic`` 173 - ``CatchEmergencyFatal`` 174 175 Conditional Logging 176 ~~~~~~~~~~~~~~~~~~~ 177 178 ``grip`` incldues support for conditional logging, so that you can 179 only log a message in certain situations, by adding a Boolean argument 180 to the logging call. Use this to implement "log sometimes" messages to 181 minimize verbosity without complicating the calling code around the 182 logging. 183 184 These methods have a ``<Level>When<>`` format. For 185 example: ``AlertWhen``, ``AlertWhenln``, ``AlertWhenf``. 186 187 Composed Logging 188 ~~~~~~~~~~~~~~~~ 189 190 If the production of the log message is resource intensive or 191 complicated, you may wish to use a "composed logging," which delays 192 the generation of the log message from the logging call site to the 193 message propagation, to avoid generating the log message unless 194 neccessary. Rather than passing the log message as a string, pass the 195 logging function an instance of a type that implements the 196 ``MessageComposer`` interface: :: 197 198 type MessageComposer interface { 199 String() string 200 Raw() interface{} 201 Loggable() bool 202 Priority() level.Priority 203 SetPriority(level.Priority) error 204 } 205 206 Composed logging may be useful for some debugging logging that depends 207 on additional database, API queries, or data serialization. Composers 208 are also the mechanism through which the ``Catch<>`` methods are 209 implemented, 210 211 Grip uses composers internally, but you can pass composers directly to 212 any of the basic logging method (e.g. ``Info()``, ``Debug()``) for 213 composed logging. 214 215 Grip includes a number of message types, including those that collect 216 system information, process information, stacktraces, or simple 217 user-specified structured information.