react-hook-eslint 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,1238 @@
1
+ # Transports
2
+
3
+ Pino transports can be used for both transmitting and transforming log output.
4
+
5
+ The way Pino generates logs:
6
+
7
+ 1. Reduces the impact of logging on an application to the absolute minimum.
8
+ 2. Gives greater flexibility in how logs are processed and stored.
9
+
10
+ It is recommended that any log transformation or transmission is performed either
11
+ in a separate thread or a separate process.
12
+
13
+ Before Pino v7 transports would ideally operate in a separate process - these are
14
+ now referred to as [Legacy Transports](#legacy-transports).
15
+
16
+ From Pino v7 and upwards transports can also operate inside a [Worker Thread][worker-thread]
17
+ and can be used or configured via the options object passed to `pino` on initialization.
18
+ In this case the transports would always operate asynchronously (unless `options.sync` is set to `true` in transport options), and logs would be
19
+ flushed as quickly as possible (there is nothing to do).
20
+
21
+ [worker-thread]: https://nodejs.org/dist/latest-v14.x/docs/api/worker_threads.html
22
+
23
+ ## v7+ Transports
24
+
25
+ A transport is a module that exports a default function that returns a writable stream:
26
+
27
+ ```js
28
+ import { createWriteStream } from 'node:fs'
29
+
30
+ export default (options) => {
31
+ return createWriteStream(options.destination)
32
+ }
33
+ ```
34
+
35
+ Let's imagine the above defines our "transport" as the file `my-transport.mjs`
36
+ (ESM files are supported even if the project is written in CJS).
37
+
38
+ We would set up our transport by creating a transport stream with `pino.transport`
39
+ and passing it to the `pino` function:
40
+
41
+ ```js
42
+ const pino = require('pino')
43
+ const transport = pino.transport({
44
+ target: '/absolute/path/to/my-transport.mjs'
45
+ })
46
+ pino(transport)
47
+ ```
48
+
49
+ The transport code will be executed in a separate worker thread. The main thread
50
+ will write logs to the worker thread, which will write them to the stream returned
51
+ from the function exported from the transport file/module.
52
+
53
+ The exported function can also be async. If we use an async function we can throw early
54
+ if the transform could not be opened. As an example:
55
+
56
+ ```js
57
+ import fs from 'node:fs'
58
+ import { once } from 'events'
59
+ export default async (options) => {
60
+ const stream = fs.createWriteStream(options.destination)
61
+ await once(stream, 'open')
62
+ return stream
63
+ }
64
+ ```
65
+
66
+ While initializing the stream we're able to use `await` to perform asynchronous operations. In this
67
+ case, waiting for the write streams `open` event.
68
+
69
+ Let's imagine the above was published to npm with the module name `some-file-transport`.
70
+
71
+ The `options.destination` value can be set when creating the transport stream with `pino.transport` like so:
72
+
73
+ ```js
74
+ const pino = require('pino')
75
+ const transport = pino.transport({
76
+ target: 'some-file-transport',
77
+ options: { destination: '/dev/null' }
78
+ })
79
+ pino(transport)
80
+ ```
81
+
82
+ Note here we've specified a module by package rather than by relative path. The options object we provide
83
+ is serialized and injected into the transport worker thread, then passed to the module's exported function.
84
+ This means that the options object can only contain types that are supported by the
85
+ [Structured Clone Algorithm][sca] which is used to (de)serialize objects between threads.
86
+
87
+ What if we wanted to use both transports, but send only error logs to `my-transport.mjs` while
88
+ sending all logs to `some-file-transport`? We can use the `pino.transport` function's `level` option:
89
+
90
+ ```js
91
+ const pino = require('pino')
92
+ const transport = pino.transport({
93
+ targets: [
94
+ { target: '/absolute/path/to/my-transport.mjs', level: 'error' },
95
+ { target: 'some-file-transport', options: { destination: '/dev/null' }}
96
+ ]
97
+ })
98
+ pino(transport)
99
+ ```
100
+
101
+ If we're using custom levels, they should be passed in when using more than one transport.
102
+ ```js
103
+ const pino = require('pino')
104
+ const transport = pino.transport({
105
+ targets: [
106
+ { target: '/absolute/path/to/my-transport.mjs', level: 'error' },
107
+ { target: 'some-file-transport', options: { destination: '/dev/null' }
108
+ ],
109
+ levels: { foo: 35 }
110
+ })
111
+ pino(transport)
112
+ ```
113
+
114
+ It is also possible to use the `dedupe` option to send logs only to the stream with the higher level.
115
+ ```js
116
+ const pino = require('pino')
117
+ const transport = pino.transport({
118
+ targets: [
119
+ { target: '/absolute/path/to/my-transport.mjs', level: 'error' },
120
+ { target: 'some-file-transport', options: { destination: '/dev/null' }
121
+ ],
122
+ dedupe: true
123
+ })
124
+ pino(transport)
125
+ ```
126
+
127
+ To make pino log synchronously, pass `sync: true` to transport options.
128
+ ```js
129
+ const pino = require('pino')
130
+ const transport = pino.transport({
131
+ targets: [
132
+ { target: '/absolute/path/to/my-transport.mjs', level: 'error' },
133
+ ],
134
+ dedupe: true,
135
+ sync: true,
136
+ });
137
+ pino(transport);
138
+ ```
139
+
140
+ For more details on `pino.transport` see the [API docs for `pino.transport`][pino-transport].
141
+
142
+ [pino-transport]: /docs/api.md#pino-transport
143
+ [sca]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
144
+
145
+ <a id="writing"></a>
146
+ ### Writing a Transport
147
+
148
+ The module [pino-abstract-transport](https://github.com/pinojs/pino-abstract-transport) provides
149
+ a simple utility to parse each line. Its usage is highly recommended.
150
+
151
+ You can see an example using an async iterator with ESM:
152
+
153
+ ```js
154
+ import build from 'pino-abstract-transport'
155
+ import SonicBoom from 'sonic-boom'
156
+ import { once } from 'events'
157
+
158
+ export default async function (opts) {
159
+ // SonicBoom is necessary to avoid loops with the main thread.
160
+ // It is the same of pino.destination().
161
+ const destination = new SonicBoom({ dest: opts.destination || 1, sync: false })
162
+ await once(destination, 'ready')
163
+
164
+ return build(async function (source) {
165
+ for await (let obj of source) {
166
+ const toDrain = !destination.write(obj.msg.toUpperCase() + '\n')
167
+ // This block will handle backpressure
168
+ if (toDrain) {
169
+ await once(destination, 'drain')
170
+ }
171
+ }
172
+ }, {
173
+ async close (err) {
174
+ destination.end()
175
+ await once(destination, 'close')
176
+ }
177
+ })
178
+ }
179
+ ```
180
+
181
+ or using Node.js streams and CommonJS:
182
+
183
+ ```js
184
+ 'use strict'
185
+
186
+ const build = require('pino-abstract-transport')
187
+ const SonicBoom = require('sonic-boom')
188
+
189
+ module.exports = function (opts) {
190
+ const destination = new SonicBoom({ dest: opts.destination || 1, sync: false })
191
+ return build(function (source) {
192
+ source.pipe(destination)
193
+ }, {
194
+ close (err, cb) {
195
+ destination.end()
196
+ destination.on('close', cb.bind(null, err))
197
+ }
198
+ })
199
+ }
200
+ ```
201
+
202
+ (It is possible to use the async iterators with CommonJS and streams with ESM.)
203
+
204
+ To consume async iterators in batches, consider using the [hwp](https://github.com/mcollina/hwp) library.
205
+
206
+ The `close()` function is needed to make sure that the stream is closed and flushed when its
207
+ callback is called or the returned promise resolves. Otherwise, log lines will be lost.
208
+
209
+ ### Writing to a custom transport & stdout
210
+
211
+ In case you want to both use a custom transport, and output the log entries with default processing to STDOUT, you can use 'pino/file' transport configured with `destination: 1`:
212
+
213
+ ```js
214
+ const transports = [
215
+ {
216
+ target: 'pino/file',
217
+ options: { destination: 1 } // this writes to STDOUT
218
+ },
219
+ {
220
+ target: 'my-custom-transport',
221
+ options: { someParameter: true }
222
+ }
223
+ ]
224
+
225
+ const logger = pino(pino.transport({ targets: transports }))
226
+ ```
227
+
228
+ ### Creating a transport pipeline
229
+
230
+ As an example, the following transport returns a `Transform` stream:
231
+
232
+ ```js
233
+ import build from 'pino-abstract-transport'
234
+ import { pipeline, Transform } from 'node:stream'
235
+ export default async function (options) {
236
+ return build(function (source) {
237
+ const myTransportStream = new Transform({
238
+ // Make sure autoDestroy is set,
239
+ // this is needed in Node v12 or when using the
240
+ // readable-stream module.
241
+ autoDestroy: true,
242
+
243
+ objectMode: true,
244
+ transform (chunk, enc, cb) {
245
+
246
+ // modifies the payload somehow
247
+ chunk.service = 'pino'
248
+
249
+ // stringify the payload again
250
+ this.push(`${JSON.stringify(chunk)}\n`)
251
+ cb()
252
+ }
253
+ })
254
+ pipeline(source, myTransportStream, () => {})
255
+ return myTransportStream
256
+ }, {
257
+ // This is needed to be able to pipeline transports.
258
+ enablePipelining: true
259
+ })
260
+ }
261
+ ```
262
+
263
+ Then you can pipeline them with:
264
+
265
+ ```js
266
+ import pino from 'pino'
267
+
268
+ const logger = pino({
269
+ transport: {
270
+ pipeline: [{
271
+ target: './my-transform.js'
272
+ }, {
273
+ // Use target: 'pino/file' with STDOUT descriptor 1 to write
274
+ // logs without any change.
275
+ target: 'pino/file',
276
+ options: { destination: 1 }
277
+ }]
278
+ }
279
+ })
280
+
281
+ logger.info('hello world')
282
+ ```
283
+
284
+ __NOTE: there is no "default" destination for a pipeline but
285
+ a terminating target, i.e. a `Writable` stream.__
286
+
287
+ ### TypeScript compatibility
288
+
289
+ Pino provides basic support for transports written in TypeScript.
290
+
291
+ Ideally, they should be transpiled to ensure maximum compatibility, but sometimes
292
+ you might want to use tools such as TS-Node, to execute your TypeScript
293
+ code without having to go through an explicit transpilation step.
294
+
295
+ You can use your TypeScript code without explicit transpilation, but there are
296
+ some known caveats:
297
+ - For "pure" TypeScript code, ES imports are still not supported (ES imports are
298
+ supported once the code is transpiled).
299
+ - Only TS-Node is supported for now, there's no TSM support.
300
+ - Running transports TypeScript code on TS-Node seems to be problematic on
301
+ Windows systems, there's no official support for that yet.
302
+
303
+ ### Notable transports
304
+
305
+ #### `pino/file`
306
+
307
+ The `pino/file` transport routes logs to a file (or file descriptor).
308
+
309
+ The `options.destination` property may be set to specify the desired file destination.
310
+
311
+ ```js
312
+ const pino = require('pino')
313
+ const transport = pino.transport({
314
+ target: 'pino/file',
315
+ options: { destination: '/path/to/file' }
316
+ })
317
+ pino(transport)
318
+ ```
319
+
320
+ By default, the `pino/file` transport assumes the directory of the destination file exists. If it does not exist, the transport will throw an error when it attempts to open the file for writing. The `mkdir` option may be set to `true` to configure the transport to create the directory, if it does not exist, before opening the file for writing.
321
+
322
+ ```js
323
+ const pino = require('pino')
324
+ const transport = pino.transport({
325
+ target: 'pino/file',
326
+ options: { destination: '/path/to/file', mkdir: true }
327
+ })
328
+ pino(transport)
329
+ ```
330
+
331
+ By default, the `pino/file` transport appends to the destination file if it exists. The `append` option may be set to `false` to configure the transport to truncate the file upon opening it for writing.
332
+
333
+ ```js
334
+ const pino = require('pino')
335
+ const transport = pino.transport({
336
+ target: 'pino/file',
337
+ options: { destination: '/path/to/file', append: false }
338
+ })
339
+ pino(transport)
340
+ ```
341
+
342
+ The `options.destination` property may also be a number to represent a file descriptor. Typically this would be `1` to write to STDOUT or `2` to write to STDERR. If `options.destination` is not set, it defaults to `1` which means logs will be written to STDOUT. If `options.destination` is a string integer, e.g. `'1'`, it will be coerced to a number and used as a file descriptor. If this is not desired, provide a full path, e.g. `/tmp/1`.
343
+
344
+ The difference between using the `pino/file` transport builtin and using `pino.destination` is that `pino.destination` runs in the main thread, whereas `pino/file` sets up `pino.destination` in a worker thread.
345
+
346
+ #### `pino-pretty`
347
+
348
+ The [`pino-pretty`][pino-pretty] transport prettifies logs.
349
+
350
+ By default the `pino-pretty` builtin logs to STDOUT.
351
+
352
+ The `options.destination` property may be set to log pretty logs to a file descriptor or file. The following would send the prettified logs to STDERR:
353
+
354
+ ```js
355
+ const pino = require('pino')
356
+ const transport = pino.transport({
357
+ target: 'pino-pretty',
358
+ options: { destination: 1 } // use 2 for stderr
359
+ })
360
+ pino(transport)
361
+ ```
362
+
363
+ ### Asynchronous startup
364
+
365
+ The new transports boot asynchronously and calling `process.exit()` before the transport
366
+ starts will cause logs to not be delivered.
367
+
368
+ ```js
369
+ const pino = require('pino')
370
+ const transport = pino.transport({
371
+ targets: [
372
+ { target: '/absolute/path/to/my-transport.mjs', level: 'error' },
373
+ { target: 'some-file-transport', options: { destination: '/dev/null' } }
374
+ ]
375
+ })
376
+ const logger = pino(transport)
377
+
378
+ logger.info('hello')
379
+
380
+ // If logs are printed before the transport is ready when process.exit(0) is called,
381
+ // they will be lost.
382
+ transport.on('ready', function () {
383
+ process.exit(0)
384
+ })
385
+ ```
386
+
387
+ ## Legacy Transports
388
+
389
+ A legacy Pino "transport" is a supplementary tool that consumes Pino logs.
390
+
391
+ Consider the following example for creating a transport:
392
+
393
+ ```js
394
+ const { pipeline, Writable } = require('node:stream')
395
+ const split = require('split2')
396
+
397
+ const myTransportStream = new Writable({
398
+ write (chunk, enc, cb) {
399
+ // apply a transform and send to STDOUT
400
+ console.log(chunk.toString().toUpperCase())
401
+ cb()
402
+ }
403
+ })
404
+
405
+ pipeline(process.stdin, split(JSON.parse), myTransportStream)
406
+ ```
407
+
408
+ The above defines our "transport" as the file `my-transport-process.js`.
409
+
410
+ Logs can now be consumed using shell piping:
411
+
412
+ ```sh
413
+ node my-app-which-logs-stuff-to-stdout.js | node my-transport-process.js
414
+ ```
415
+
416
+ Ideally, a transport should consume logs in a separate process to the application,
417
+ Using transports in the same process causes unnecessary load and slows down
418
+ Node's single-threaded event loop.
419
+
420
+ ## Known Transports
421
+
422
+ PRs to this document are welcome for any new transports!
423
+
424
+ ### Pino v7+ Compatible
425
+
426
+ + [@axiomhq/pino](#@axiomhq/pino)
427
+ + [@logtail/pino](#@logtail/pino)
428
+ + [@macfja/pino-fingers-crossed](#macfja-pino-fingers-crossed)
429
+ + [@openobserve/pino-openobserve](#pino-openobserve)
430
+ + [pino-airbrake-transport](#pino-airbrake-transport)
431
+ + [pino-axiom](#pino-axiom)
432
+ + [pino-datadog-transport](#pino-datadog-transport)
433
+ + [pino-discord-webhook](#pino-discord-webhook)
434
+ + [pino-elasticsearch](#pino-elasticsearch)
435
+ + [pino-hana](#pino-hana)
436
+ + [pino-logfmt](#pino-logfmt)
437
+ + [pino-loki](#pino-loki)
438
+ + [pino-opentelemetry-transport](#pino-opentelemetry-transport)
439
+ + [pino-pretty](#pino-pretty)
440
+ + [pino-seq-transport](#pino-seq-transport)
441
+ + [pino-sentry-transport](#pino-sentry-transport)
442
+ + [pino-slack-webhook](#pino-slack-webhook)
443
+ + [pino-telegram-webhook](#pino-telegram-webhook)
444
+ + [pino-yc-transport](#pino-yc-transport)
445
+
446
+ ### Legacy
447
+
448
+ + [pino-applicationinsights](#pino-applicationinsights)
449
+ + [pino-azuretable](#pino-azuretable)
450
+ + [pino-cloudwatch](#pino-cloudwatch)
451
+ + [pino-couch](#pino-couch)
452
+ + [pino-datadog](#pino-datadog)
453
+ + [pino-gelf](#pino-gelf)
454
+ + [pino-http-send](#pino-http-send)
455
+ + [pino-kafka](#pino-kafka)
456
+ + [pino-logdna](#pino-logdna)
457
+ + [pino-logflare](#pino-logflare)
458
+ + [pino-loki](#pino-loki)
459
+ + [pino-mq](#pino-mq)
460
+ + [pino-mysql](#pino-mysql)
461
+ + [pino-papertrail](#pino-papertrail)
462
+ + [pino-pg](#pino-pg)
463
+ + [pino-redis](#pino-redis)
464
+ + [pino-sentry](#pino-sentry)
465
+ + [pino-seq](#pino-seq)
466
+ + [pino-socket](#pino-socket)
467
+ + [pino-stackdriver](#pino-stackdriver)
468
+ + [pino-syslog](#pino-syslog)
469
+ + [pino-websocket](#pino-websocket)
470
+
471
+
472
+ <a id="@axiomhq/pino"></a>
473
+ ### @axiomhq/pino
474
+
475
+ [@axiomhq/pino](https://www.npmjs.com/package/@axiomhq/pino) is the official [Axiom](https://axiom.co/) transport for Pino, using [axiom-js](https://github.com/axiomhq/axiom-js).
476
+
477
+ ```javascript
478
+ import pino from 'pino';
479
+
480
+ const logger = pino(
481
+ { level: 'info' },
482
+ pino.transport({
483
+ target: '@axiomhq/pino',
484
+ options: {
485
+ dataset: process.env.AXIOM_DATASET,
486
+ token: process.env.AXIOM_TOKEN,
487
+ },
488
+ }),
489
+ );
490
+ ```
491
+
492
+ then you can use the logger as usual:
493
+
494
+ ```js
495
+ logger.info('Hello from pino!');
496
+ ```
497
+
498
+ For further examples, head over to the [examples](https://github.com/axiomhq/axiom-js/tree/main/examples/pino) directory.
499
+
500
+ <a id="@logtail/pino"></a>
501
+ ### @logtail/pino
502
+
503
+ The [@logtail/pino](https://www.npmjs.com/package/@logtail/pino) NPM package is a transport that forwards logs to [Logtail](https://logtail.com) by [Better Stack](https://betterstack.com).
504
+
505
+ [Quick start guide ⇗](https://betterstack.com/docs/logs/javascript/pino)
506
+
507
+ <a id="macfja-pino-fingers-crossed"></a>
508
+ ### @macfja/pino-fingers-crossed
509
+
510
+ [@macfja/pino-fingers-crossed](https://github.com/MacFJA/js-pino-fingers-crossed) is a Pino v7+ transport that holds logs until a log level is reached, allowing to only have logs when it matters.
511
+
512
+ ```js
513
+ const pino = require('pino');
514
+ const { default: fingersCrossed, enable } = require('@macfja/pino-fingers-crossed')
515
+
516
+ const logger = pino(fingersCrossed());
517
+
518
+ logger.info('Will appear immedialty')
519
+ logger.error('Will appear immedialty')
520
+
521
+ logger.setBindings({ [enable]: 50 })
522
+ logger.info('Will NOT appear immedialty')
523
+ logger.info('Will NOT appear immedialty')
524
+ logger.error('Will appear immedialty as well as the 2 previous messages') // error log are level 50
525
+ logger.info('Will NOT appear')
526
+ logger.info({ [enable]: false }, 'Will appear immedialty')
527
+ logger.info('Will NOT appear')
528
+ ```
529
+ <a id="pino-openobserve"></a>
530
+ ### @openobserve/pino-openobserve
531
+
532
+ [@openobserve/pino-openobserve](https://github.com/openobserve/pino-openobserve) is a
533
+ Pino v7+ transport that will send logs to an
534
+ [OpenObserve](https://openobserve.ai) instance.
535
+
536
+ ```
537
+ const pino = require('pino');
538
+ const OpenobserveTransport = require('@openobserve/pino-openobserve');
539
+
540
+ const logger = pino({
541
+ level: 'info',
542
+ transport: {
543
+ target: OpenobserveTransport,
544
+ options: {
545
+ url: 'https://your-openobserve-server.com',
546
+ organization: 'your-organization',
547
+ streamName: 'your-stream',
548
+ auth: {
549
+ username: 'your-username',
550
+ password: 'your-password',
551
+ },
552
+ },
553
+ },
554
+ });
555
+ ```
556
+
557
+ For full documentation check the [README](https://github.com/openobserve/pino-openobserve).
558
+
559
+ <a id="pino-airbrake-transport"></a>
560
+ ### pino-airbrake-transport
561
+
562
+ [pino-airbrake-transport][pino-airbrake-transport] is a Pino v7+ compatible transport to forward log events to [Airbrake][Airbrake]
563
+ from a dedicated worker:
564
+
565
+ ```js
566
+ const pino = require('pino')
567
+ const transport = pino.transport({
568
+ target: 'pino-airbrake-transport',
569
+ options: {
570
+ airbrake: {
571
+ projectId: 1,
572
+ projectKey: "REPLACE_ME",
573
+ environment: "production",
574
+ // additional options for airbrake
575
+ performanceStats: false,
576
+ },
577
+ },
578
+ level: "error", // minimum log level that should be sent to airbrake
579
+ })
580
+ pino(transport)
581
+ ```
582
+
583
+ [pino-airbrake-transport]: https://github.com/enricodeleo/pino-airbrake-transport
584
+ [Airbrake]: https://airbrake.io/
585
+
586
+ <a id="pino-applicationinsights"></a>
587
+ ### pino-applicationinsights
588
+ The [pino-applicationinsights](https://www.npmjs.com/package/pino-applicationinsights) module is a transport that will forward logs to [Azure Application Insights](https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview).
589
+
590
+ Given an application `foo` that logs via pino, you would use `pino-applicationinsights` like so:
591
+
592
+ ``` sh
593
+ $ node foo | pino-applicationinsights --key blablabla
594
+ ```
595
+
596
+ For full documentation of command line switches read [README](https://github.com/ovhemert/pino-applicationinsights#readme)
597
+
598
+ <a id="pino-axiom"></a>
599
+ ### pino-axiom
600
+
601
+ [pino-axiom](https://www.npmjs.com/package/pino-axiom) is a transport that will forward logs to [Axiom](https://axiom.co).
602
+
603
+ ```javascript
604
+ const pino = require('pino')
605
+ const transport = pino.transport({
606
+ target: 'pino-axiom',
607
+ options: {
608
+ orgId: 'YOUR-ORG-ID',
609
+ token: 'YOUR-TOKEN',
610
+ dataset: 'YOUR-DATASET',
611
+ },
612
+ })
613
+ pino(transport)
614
+ ```
615
+
616
+ <a id="pino-azuretable"></a>
617
+ ### pino-azuretable
618
+ The [pino-azuretable](https://www.npmjs.com/package/pino-azuretable) module is a transport that will forward logs to the [Azure Table Storage](https://azure.microsoft.com/en-us/services/storage/tables/).
619
+
620
+ Given an application `foo` that logs via pino, you would use `pino-azuretable` like so:
621
+
622
+ ``` sh
623
+ $ node foo | pino-azuretable --account storageaccount --key blablabla
624
+ ```
625
+
626
+ For full documentation of command line switches read [README](https://github.com/ovhemert/pino-azuretable#readme)
627
+
628
+ <a id="pino-cloudwatch"></a>
629
+ ### pino-cloudwatch
630
+
631
+ [pino-cloudwatch][pino-cloudwatch] is a transport that buffers and forwards logs to [Amazon CloudWatch][].
632
+
633
+ ```sh
634
+ $ node app.js | pino-cloudwatch --group my-log-group
635
+ ```
636
+
637
+ [pino-cloudwatch]: https://github.com/dbhowell/pino-cloudwatch
638
+ [Amazon CloudWatch]: https://aws.amazon.com/cloudwatch/
639
+
640
+ <a id="pino-couch"></a>
641
+ ### pino-couch
642
+
643
+ [pino-couch][pino-couch] uploads each log line as a [CouchDB][CouchDB] document.
644
+
645
+ ```sh
646
+ $ node app.js | pino-couch -U https://couch-server -d mylogs
647
+ ```
648
+
649
+ [pino-couch]: https://github.com/IBM/pino-couch
650
+ [CouchDB]: https://couchdb.apache.org
651
+
652
+ <a id="pino-datadog"></a>
653
+ ### pino-datadog
654
+ The [pino-datadog](https://www.npmjs.com/package/pino-datadog) module is a transport that will forward logs to [DataDog](https://www.datadoghq.com/) through its API.
655
+
656
+ Given an application `foo` that logs via pino, you would use `pino-datadog` like so:
657
+
658
+ ``` sh
659
+ $ node foo | pino-datadog --key blablabla
660
+ ```
661
+
662
+ For full documentation of command line switches read [README](https://github.com/ovhemert/pino-datadog#readme)
663
+
664
+ <a id="pino-datadog-transport"></a>
665
+ ### pino-datadog-transport
666
+
667
+ [pino-datadog-transport][pino-datadog-transport] is a Pino v7+ compatible transport to forward log events to [Datadog][Datadog]
668
+ from a dedicated worker:
669
+
670
+ ```js
671
+ const pino = require('pino')
672
+ const transport = pino.transport({
673
+ target: 'pino-datadog-transport',
674
+ options: {
675
+ ddClientConf: {
676
+ authMethods: {
677
+ apiKeyAuth: <your datadog API key>
678
+ }
679
+ },
680
+ },
681
+ level: "error", // minimum log level that should be sent to datadog
682
+ })
683
+ pino(transport)
684
+ ```
685
+
686
+ [pino-datadog-transport]: https://github.com/theogravity/datadog-transports
687
+ [Datadog]: https://www.datadoghq.com/
688
+
689
+ #### Logstash
690
+
691
+ The [pino-socket][pino-socket] module can also be used to upload logs to
692
+ [Logstash][logstash] via:
693
+
694
+ ```
695
+ $ node app.js | pino-socket -a 127.0.0.1 -p 5000 -m tcp
696
+ ```
697
+
698
+ Assuming logstash is running on the same host and configured as
699
+ follows:
700
+
701
+ ```
702
+ input {
703
+ tcp {
704
+ port => 5000
705
+ }
706
+ }
707
+
708
+ filter {
709
+ json {
710
+ source => "message"
711
+ }
712
+ }
713
+
714
+ output {
715
+ elasticsearch {
716
+ hosts => "127.0.0.1:9200"
717
+ }
718
+ }
719
+ ```
720
+
721
+ See <https://www.elastic.co/guide/en/kibana/current/setup.html> to learn
722
+ how to setup [Kibana][kibana].
723
+
724
+ For Docker users, see
725
+ https://github.com/deviantony/docker-elk to setup an ELK stack.
726
+
727
+ <a id="pino-discord-webhook"></a>
728
+ ### pino-discord-webhook
729
+
730
+ [pino-discord-webhook](https://github.com/fabulousgk/pino-discord-webhook) is a Pino v7+ compatible transport to forward log events to a [Discord](http://discord.com) webhook from a dedicated worker.
731
+
732
+ ```js
733
+ import pino from 'pino'
734
+
735
+ const logger = pino({
736
+ transport: {
737
+ target: 'pino-discord-webhook',
738
+ options: {
739
+ webhookUrl: 'https://discord.com/api/webhooks/xxxx/xxxx',
740
+ }
741
+ }
742
+ })
743
+ ```
744
+
745
+ <a id="pino-elasticsearch"></a>
746
+ ### pino-elasticsearch
747
+
748
+ [pino-elasticsearch][pino-elasticsearch] uploads the log lines in bulk
749
+ to [Elasticsearch][elasticsearch], to be displayed in [Kibana][kibana].
750
+
751
+ It is extremely simple to use and setup
752
+
753
+ ```sh
754
+ $ node app.js | pino-elasticsearch
755
+ ```
756
+
757
+ Assuming Elasticsearch is running on localhost.
758
+
759
+ To connect to an external Elasticsearch instance (recommended for production):
760
+
761
+ * Check that `network.host` is defined in the `elasticsearch.yml` configuration file. See [Elasticsearch Network Settings documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html#common-network-settings) for more details.
762
+ * Launch:
763
+
764
+ ```sh
765
+ $ node app.js | pino-elasticsearch --node http://192.168.1.42:9200
766
+ ```
767
+
768
+ Assuming Elasticsearch is running on `192.168.1.42`.
769
+
770
+ To connect to AWS Elasticsearch:
771
+
772
+ ```sh
773
+ $ node app.js | pino-elasticsearch --node https://es-url.us-east-1.es.amazonaws.com --es-version 6
774
+ ```
775
+
776
+ Then [create an index pattern](https://www.elastic.co/guide/en/kibana/current/setup.html) on `'pino'` (the default index key for `pino-elasticsearch`) on the Kibana instance.
777
+
778
+ [pino-elasticsearch]: https://github.com/pinojs/pino-elasticsearch
779
+ [elasticsearch]: https://www.elastic.co/products/elasticsearch
780
+ [kibana]: https://www.elastic.co/products/kibana
781
+
782
+ <a id="pino-gelf"></a>
783
+ ### pino-gelf
784
+
785
+ Pino GELF ([pino-gelf]) is a transport for the Pino logger. Pino GELF receives Pino logs from stdin and transforms them into [GELF format][gelf] before sending them to a remote [Graylog server][graylog] via UDP.
786
+
787
+ ```sh
788
+ $ node your-app.js | pino-gelf log
789
+ ```
790
+
791
+ [pino-gelf]: https://github.com/pinojs/pino-gelf
792
+ [gelf]: https://docs.graylog.org/en/2.1/pages/gelf.html
793
+ [graylog]: https://www.graylog.org/
794
+
795
+ <a id="pino-hana"></a>
796
+ ### pino-hana
797
+ [pino-hana](https://github.com/HiImGiovi/pino-hana) is a Pino v7+ transport that save pino logs to a SAP HANA database.
798
+ ```js
799
+ const pino = require('pino')
800
+ const logger = pino({
801
+ transport: {
802
+ target: 'pino-hana',
803
+ options: {
804
+ connectionOptions: {
805
+ host: <hana db host>,
806
+ port: <hana db port>,
807
+ user: <hana db user>,
808
+ password: <hana db password>,
809
+ },
810
+ schema: <schema of the table in which you want to save the logs>,
811
+ table: <table in which you want to save the logs>,
812
+ },
813
+ },
814
+ })
815
+
816
+ logger.info('hi') // this log will be saved into SAP HANA
817
+ ```
818
+ For more detailed information about its usage please check the official [documentation](https://github.com/HiImGiovi/pino-hana#readme).
819
+
820
+ <a id="pino-http-send"></a>
821
+ ### pino-http-send
822
+
823
+ [pino-http-send](https://npmjs.com/package/pino-http-send) is a configurable and low overhead
824
+ transport that will batch logs and send to a specified URL.
825
+
826
+ ```console
827
+ $ node app.js | pino-http-send -u http://localhost:8080/logs
828
+ ```
829
+
830
+ <a id="pino-kafka"></a>
831
+ ### pino-kafka
832
+
833
+ [pino-kafka](https://github.com/ayZagen/pino-kafka) transport to send logs to [Apache Kafka](https://kafka.apache.org/).
834
+
835
+ ```sh
836
+ $ node index.js | pino-kafka -b 10.10.10.5:9200 -d mytopic
837
+ ```
838
+
839
+ <a id="pino-logdna"></a>
840
+ ### pino-logdna
841
+
842
+ [pino-logdna](https://github.com/logdna/pino-logdna) transport to send logs to [LogDNA](https://logdna.com).
843
+
844
+ ```sh
845
+ $ node index.js | pino-logdna --key YOUR_INGESTION_KEY
846
+ ```
847
+
848
+ Tags and other metadata can be included using the available command line options. See the [pino-logdna README](https://github.com/logdna/pino-logdna#options) for a full list.
849
+
850
+ <a id="pino-logflare"></a>
851
+ ### pino-logflare
852
+
853
+ [pino-logflare](https://github.com/Logflare/pino-logflare) transport to send logs to a [Logflare](https://logflare.app) `source`.
854
+
855
+ ```sh
856
+ $ node index.js | pino-logflare --key YOUR_KEY --source YOUR_SOURCE
857
+ ```
858
+
859
+ <a id="pino-logfmt"></a>
860
+ ### pino-logfmt
861
+
862
+ [pino-logfmt](https://github.com/botflux/pino-logfmt) is a Pino v7+ transport that formats logs into [logfmt](https://brandur.org/logfmt). This transport can output the formatted logs to stdout or file.
863
+
864
+ ```js
865
+ import pino from 'pino'
866
+
867
+ const logger = pino({
868
+ transport: {
869
+ target: 'pino-logfmt'
870
+ }
871
+ })
872
+ ```
873
+
874
+ <a id="pino-loki"></a>
875
+ ### pino-loki
876
+ pino-loki is a transport that will forwards logs into [Grafana Loki](https://grafana.com/oss/loki/).
877
+ Can be used in CLI version in a separate process or in a dedicated worker:
878
+
879
+ CLI :
880
+ ```console
881
+ node app.js | pino-loki --hostname localhost:3100 --labels='{ "application": "my-application"}' --user my-username --password my-password
882
+ ```
883
+
884
+ Worker :
885
+ ```js
886
+ const pino = require('pino')
887
+ const transport = pino.transport({
888
+ target: 'pino-loki',
889
+ options: { host: 'localhost:3100' }
890
+ })
891
+ pino(transport)
892
+ ```
893
+
894
+ For full documentation and configuration, see the [README](https://github.com/Julien-R44/pino-loki).
895
+
896
+ <a id="pino-mq"></a>
897
+ ### pino-mq
898
+
899
+ The `pino-mq` transport will take all messages received on `process.stdin` and send them over a message bus using JSON serialization.
900
+
901
+ This is useful for:
902
+
903
+ * moving backpressure from application to broker
904
+ * transforming messages pressure to another component
905
+
906
+ ```
907
+ node app.js | pino-mq -u "amqp://guest:guest@localhost/" -q "pino-logs"
908
+ ```
909
+
910
+ Alternatively, a configuration file can be used:
911
+
912
+ ```
913
+ node app.js | pino-mq -c pino-mq.json
914
+ ```
915
+
916
+ A base configuration file can be initialized with:
917
+
918
+ ```
919
+ pino-mq -g
920
+ ```
921
+
922
+ For full documentation of command line switches and configuration see [the `pino-mq` README](https://github.com/itavy/pino-mq#readme)
923
+
924
+ <a id="pino-mysql"></a>
925
+ ### pino-mysql
926
+
927
+ [pino-mysql][pino-mysql] loads pino logs into [MySQL][MySQL] and [MariaDB][MariaDB].
928
+
929
+ ```sh
930
+ $ node app.js | pino-mysql -c db-configuration.json
931
+ ```
932
+
933
+ `pino-mysql` can extract and save log fields into corresponding database fields
934
+ and/or save the entire log stream as a [JSON Data Type][JSONDT].
935
+
936
+ For full documentation and command line switches read the [README][pino-mysql].
937
+
938
+ [pino-mysql]: https://www.npmjs.com/package/pino-mysql
939
+ [MySQL]: https://www.mysql.com/
940
+ [MariaDB]: https://mariadb.org/
941
+ [JSONDT]: https://dev.mysql.com/doc/refman/8.0/en/json.html
942
+
943
+ <a id="pino-opentelemetry-transport"></a>
944
+ ### pino-opentelemetry-transport
945
+
946
+ [pino-opentelemetry-transport](https://www.npmjs.com/package/pino-opentelemetry-transport) is a transport that will forward logs to an [OpenTelemetry log collector](https://opentelemetry.io/docs/collector/) using [OpenTelemetry JS instrumentation](https://opentelemetry.io/docs/instrumentation/js/).
947
+
948
+ ```javascript
949
+ const pino = require('pino')
950
+
951
+ const transport = pino.transport({
952
+ target: 'pino-opentelemetry-transport',
953
+ options: {
954
+ resourceAttributes: {
955
+ 'service.name': 'test-service',
956
+ 'service.version': '1.0.0'
957
+ }
958
+ }
959
+ })
960
+
961
+ pino(transport)
962
+ ```
963
+
964
+ Documentation on running a minimal example is available in the [README](https://github.com/Vunovati/pino-opentelemetry-transport#minimalistic-example).
965
+
966
+ <a id="pino-papertrail"></a>
967
+ ### pino-papertrail
968
+ pino-papertrail is a transport that will forward logs to the [papertrail](https://papertrailapp.com) log service through an UDPv4 socket.
969
+
970
+ Given an application `foo` that logs via pino, and a papertrail destination that collects logs on port UDP `12345` on address `bar.papertrailapp.com`, you would use `pino-papertrail`
971
+ like so:
972
+
973
+ ```
974
+ node yourapp.js | pino-papertrail --host bar.papertrailapp.com --port 12345 --appname foo
975
+ ```
976
+
977
+
978
+ for full documentation of command line switches read [README](https://github.com/ovhemert/pino-papertrail#readme)
979
+
980
+ <a id="pino-pg"></a>
981
+ ### pino-pg
982
+ [pino-pg](https://www.npmjs.com/package/pino-pg) stores logs into PostgreSQL.
983
+ Full documentation in the [README](https://github.com/Xstoudi/pino-pg).
984
+
985
+ <a id="pino-redis"></a>
986
+ ### pino-redis
987
+
988
+ [pino-redis][pino-redis] loads pino logs into [Redis][Redis].
989
+
990
+ ```sh
991
+ $ node app.js | pino-redis -U redis://username:password@localhost:6379
992
+ ```
993
+
994
+ [pino-redis]: https://github.com/buianhthang/pino-redis
995
+ [Redis]: https://redis.io/
996
+
997
+ <a id="pino-sentry"></a>
998
+ ### pino-sentry
999
+
1000
+ [pino-sentry][pino-sentry] loads pino logs into [Sentry][Sentry].
1001
+
1002
+ ```sh
1003
+ $ node app.js | pino-sentry --dsn=https://******@sentry.io/12345
1004
+ ```
1005
+
1006
+ For full documentation of command line switches see the [pino-sentry README](https://github.com/aandrewww/pino-sentry/blob/master/README.md).
1007
+
1008
+ [pino-sentry]: https://www.npmjs.com/package/pino-sentry
1009
+ [Sentry]: https://sentry.io/
1010
+
1011
+ <a id="pino-sentry-transport"></a>
1012
+ ### pino-sentry-transport
1013
+
1014
+ [pino-sentry-transport][pino-sentry-transport] is a Pino v7+ compatible transport to forward log events to [Sentry][Sentry]
1015
+ from a dedicated worker:
1016
+
1017
+ ```js
1018
+ const pino = require('pino')
1019
+ const transport = pino.transport({
1020
+ target: 'pino-sentry-transport',
1021
+ options: {
1022
+ sentry: {
1023
+ dsn: 'https://******@sentry.io/12345',
1024
+ }
1025
+ }
1026
+ })
1027
+ pino(transport)
1028
+ ```
1029
+
1030
+ [pino-sentry-transport]: https://github.com/tomer-yechiel/pino-sentry-transport
1031
+ [Sentry]: https://sentry.io/
1032
+
1033
+ <a id="pino-seq"></a>
1034
+ ### pino-seq
1035
+
1036
+ [pino-seq][pino-seq] supports both out-of-process and in-process log forwarding to [Seq][Seq].
1037
+
1038
+ ```sh
1039
+ $ node app.js | pino-seq --serverUrl http://localhost:5341 --apiKey 1234567890 --property applicationName=MyNodeApp
1040
+ ```
1041
+
1042
+ [pino-seq]: https://www.npmjs.com/package/pino-seq
1043
+ [Seq]: https://datalust.co/seq
1044
+
1045
+ <a id="pino-seq-transport"></a>
1046
+ ### pino-seq-transport
1047
+
1048
+ [pino-seq-transport][pino-seq-transport] is a Pino v7+ compatible transport to forward log events to [Seq][Seq]
1049
+ from a dedicated worker:
1050
+
1051
+ ```js
1052
+ const pino = require('pino')
1053
+ const transport = pino.transport({
1054
+ target: '@autotelic/pino-seq-transport',
1055
+ options: { serverUrl: 'http://localhost:5341' }
1056
+ })
1057
+ pino(transport)
1058
+ ```
1059
+
1060
+ [pino-seq-transport]: https://github.com/autotelic/pino-seq-transport
1061
+ [Seq]: https://datalust.co/seq
1062
+
1063
+ <a id="pino-slack-webhook"></a>
1064
+ ### pino-slack-webhook
1065
+
1066
+ [pino-slack-webhook][pino-slack-webhook] is a Pino v7+ compatible transport to forward log events to [Slack][Slack]
1067
+ from a dedicated worker:
1068
+
1069
+ ```js
1070
+ const pino = require('pino')
1071
+ const transport = pino.transport({
1072
+ target: '@youngkiu/pino-slack-webhook',
1073
+ options: {
1074
+ webhookUrl: 'https://hooks.slack.com/services/xxx/xxx/xxx',
1075
+ channel: '#pino-log',
1076
+ username: 'webhookbot',
1077
+ icon_emoji: ':ghost:'
1078
+ }
1079
+ })
1080
+ pino(transport)
1081
+ ```
1082
+
1083
+ [pino-slack-webhook]: https://github.com/youngkiu/pino-slack-webhook
1084
+ [Slack]: https://slack.com/
1085
+
1086
+ [pino-pretty]: https://github.com/pinojs/pino-pretty
1087
+
1088
+ For full documentation of command line switches read the [README](https://github.com/abeai/pino-websocket#readme).
1089
+
1090
+ <a id="pino-socket"></a>
1091
+ ### pino-socket
1092
+
1093
+ [pino-socket][pino-socket] is a transport that will forward logs to an IPv4
1094
+ UDP or TCP socket.
1095
+
1096
+ As an example, use `socat` to fake a listener:
1097
+
1098
+ ```sh
1099
+ $ socat -v udp4-recvfrom:6000,fork exec:'/bin/cat'
1100
+ ```
1101
+
1102
+ Then run an application that uses `pino` for logging:
1103
+
1104
+ ```sh
1105
+ $ node app.js | pino-socket -p 6000
1106
+ ```
1107
+
1108
+ Logs from the application should be observed on both consoles.
1109
+
1110
+ [pino-socket]: https://www.npmjs.com/package/pino-socket
1111
+
1112
+ <a id="pino-stackdriver"></a>
1113
+ ### pino-stackdriver
1114
+ The [pino-stackdriver](https://www.npmjs.com/package/pino-stackdriver) module is a transport that will forward logs to the [Google Stackdriver](https://cloud.google.com/logging/) log service through its API.
1115
+
1116
+ Given an application `foo` that logs via pino, a stackdriver log project `bar`, and credentials in the file `/credentials.json`, you would use `pino-stackdriver`
1117
+ like so:
1118
+
1119
+ ``` sh
1120
+ $ node foo | pino-stackdriver --project bar --credentials /credentials.json
1121
+ ```
1122
+
1123
+ For full documentation of command line switches read [README](https://github.com/ovhemert/pino-stackdriver#readme)
1124
+
1125
+ <a id="pino-syslog"></a>
1126
+ ### pino-syslog
1127
+
1128
+ [pino-syslog][pino-syslog] is a transforming transport that converts
1129
+ `pino` NDJSON logs to [RFC3164][rfc3164] compatible log messages. The `pino-syslog` module does not
1130
+ forward the logs anywhere, it merely re-writes the messages to `stdout`. But
1131
+ when used in combination with `pino-socket` the log messages can be relayed to a syslog server:
1132
+
1133
+ ```sh
1134
+ $ node app.js | pino-syslog | pino-socket -a syslog.example.com
1135
+ ```
1136
+
1137
+ Example output for the "hello world" log:
1138
+
1139
+ ```
1140
+ <134>Apr 1 16:44:58 MacBook-Pro-3 none[94473]: {"pid":94473,"hostname":"MacBook-Pro-3","level":30,"msg":"hello world","time":1459529098958}
1141
+ ```
1142
+
1143
+ [pino-syslog]: https://www.npmjs.com/package/pino-syslog
1144
+ [rfc3164]: https://tools.ietf.org/html/rfc3164
1145
+ [logstash]: https://www.elastic.co/products/logstash
1146
+
1147
+ <a id="pino-telegram-webhook"></a>
1148
+ ### pino-telegram-webhook
1149
+
1150
+ [pino-telegram-webhook](https://github.com/Jhon-Mosk/pino-telegram-webhook) is a Pino v7+ transport for sending messages to [Telegram](https://telegram.org/).
1151
+
1152
+ ```js
1153
+ const pino = require('pino');
1154
+
1155
+ const logger = pino({
1156
+ transport: {
1157
+ target: 'pino-telegram-webhook',
1158
+ level: 'error',
1159
+ options: {
1160
+ chatId: -1234567890,
1161
+ botToken: "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11",
1162
+ extra: {
1163
+ parse_mode: "HTML",
1164
+ },
1165
+ },
1166
+ },
1167
+ })
1168
+
1169
+ logger.error('<b>test log!</b>');
1170
+ ```
1171
+
1172
+ The `extra` parameter is optional. Parameters that the method [`sendMessage`](https://core.telegram.org/bots/api#sendmessage) supports can be passed to it.
1173
+
1174
+ <a id="pino-websocket"></a>
1175
+ ### pino-websocket
1176
+
1177
+ [pino-websocket](https://www.npmjs.com/package/@abeai/pino-websocket) is a transport that will forward each log line to a websocket server.
1178
+
1179
+ ```sh
1180
+ $ node app.js | pino-websocket -a my-websocket-server.example.com -p 3004
1181
+ ```
1182
+
1183
+ For full documentation of command line switches read the [README](https://github.com/abeai/pino-websocket#readme).
1184
+
1185
+ <a id="pino-yc-transport"></a>
1186
+ ### pino-yc-transport
1187
+
1188
+ [pino-yc-transport](https://github.com/Jhon-Mosk/pino-yc-transport) is a Pino v7+ transport for writing to [Yandex Cloud Logging](https://yandex.cloud/ru/services/logging) from serveless functions or containers.
1189
+
1190
+ ```js
1191
+ const pino = require("pino");
1192
+
1193
+ const config = {
1194
+ level: "debug",
1195
+ transport: {
1196
+ target: "pino-yc-transport",
1197
+ },
1198
+ };
1199
+
1200
+ const logger = pino(config);
1201
+
1202
+ logger.debug("some message")
1203
+ logger.debug({ foo: "bar" });
1204
+ logger.debug("some message %o, %s", { foo: "bar" }, "baz");
1205
+ logger.info("info");
1206
+ logger.warn("warn");
1207
+ logger.error("error");
1208
+ logger.error(new Error("error"));
1209
+ logger.fatal("fatal");
1210
+ ```
1211
+
1212
+ <a id="communication-between-pino-and-transport"></a>
1213
+ ## Communication between Pino and Transports
1214
+ Here we discuss some technical details of how Pino communicates with its [worker threads](https://nodejs.org/api/worker_threads.html).
1215
+
1216
+ Pino uses [`thread-stream`](https://github.com/pinojs/thread-stream) to create a stream for transports.
1217
+ When we create a stream with `thread-stream`, `thread-stream` spawns a [worker](https://github.com/pinojs/thread-stream/blob/f19ac8dbd602837d2851e17fbc7dfc5bbc51083f/index.js#L50-L60) (an independent JavaScript execution thread).
1218
+
1219
+ ### Error messages
1220
+ How are error messages propagated from a transport worker to Pino?
1221
+
1222
+ Let's assume we have a transport with an error listener:
1223
+ ```js
1224
+ // index.js
1225
+ const transport = pino.transport({
1226
+ target: './transport.js'
1227
+ })
1228
+
1229
+ transport.on('error', err => {
1230
+ console.error('error caught', err)
1231
+ })
1232
+
1233
+ const log = pino(transport)
1234
+ ```
1235
+
1236
+ When our worker emits an error event, the worker has listeners for it: [error](https://github.com/pinojs/thread-stream/blob/f19ac8dbd602837d2851e17fbc7dfc5bbc51083f/lib/worker.js#L59-L70) and [unhandledRejection](https://github.com/pinojs/thread-stream/blob/f19ac8dbd602837d2851e17fbc7dfc5bbc51083f/lib/worker.js#L135-L141). These listeners send the error message to the main thread where Pino is present.
1237
+
1238
+ When Pino receives the error message, it further [emits](https://github.com/pinojs/thread-stream/blob/f19ac8dbd602837d2851e17fbc7dfc5bbc51083f/index.js#L349) the error message. Finally, the error message arrives at our `index.js` and is caught by our error listener.