@@ -93,11 +93,16 @@ import (
93
93
And then in your main function initialize the metrics
94
94
95
95
``` go
96
- autometrics.Init (
96
+ shutdown , err := autometrics.Init (
97
97
nil ,
98
98
autometrics.DefBuckets ,
99
99
autometrics.BuildInfo {Version: " 0.4.0" , Commit : " anySHA" , Branch : " " , Service : " myApp" },
100
+ nil ,
100
101
)
102
+ if err != nil {
103
+ log.Fatalf (" could not initialize autometrics: %s " , err)
104
+ }
105
+ defer shutdown (nil )
101
106
```
102
107
103
108
Everything in ` BuildInfo ` is optional. It will add relevant information on the
@@ -237,10 +242,11 @@ import (
237
242
238
243
239
244
func main () {
240
- autometrics.Init (
245
+ shutdown , err := autometrics.Init (
241
246
nil ,
242
247
autometrics.DefBuckets ,
243
248
autometrics.BuildInfo {Version: " 0.4.0" , Commit: " anySHA" , Branch: " " , Service: " myApp" },
249
+ nil ,
244
250
)
245
251
http.Handle (" /metrics" , promhttp.Handler ())
246
252
}
@@ -346,11 +352,12 @@ the `Init` function takes a meter name for the `otel_scope` label of the exporte
346
352
metric. You can use the name of the application or its version for example
347
353
348
354
``` patch
349
- autometrics.Init(
355
+ shutdown, err := autometrics.Init(
350
356
- nil,
351
357
+ "myApp/v2/prod",
352
358
autometrics.DefBuckets,
353
359
autometrics.BuildInfo{ Version: "2.1.37", Commit: "anySHA", Branch: "", Service: "myApp" },
360
+ nil,
354
361
)
355
362
```
356
363
@@ -361,6 +368,68 @@ metric. You can use the name of the application or its version for example
361
368
+ //go:generate autometrics --otel
362
369
```
363
370
371
+ #### Push-based workflows
372
+
373
+ <details >
374
+ <summary ><i >Why would I use a push-based workflow?</i ></summary >
375
+
376
+ If you have an auto-scaled service (with instances spinning up and down),
377
+ maintaining the configuration/discovery of instances on the Prometheus side of
378
+ things can be hard. Using a push-based workflow inverts the burden of
379
+ configuration: all your instances generate a specific ID, and they just need to
380
+ push metrics to a given URL. So the main advantages of a push-based workflow
381
+ appear when the the set of machines producing metrics is dynamic:
382
+
383
+ - Your Prometheus configuration does not need to be dynamic anymore, it's "set
384
+ and forget" again
385
+ - No need to configure service discovery separately (which can be error-prone)
386
+
387
+
388
+ It can be summarized with one sentence. <b >The monitoring stack
389
+ (Prometheus/OpenTelemetry collector) does not need to know the infrastructure of
390
+ application deployment; nor does the application code need to know the
391
+ infrastructure of the monitoring stack. Decoupling prevents
392
+ configuration-rot.</b >
393
+
394
+ </details >
395
+
396
+ If you don't want to/cannot configure your Prometheus instance to scrape the
397
+ instrumented code, Autometrics provides a way to push metrics instead of relying
398
+ on a polling collection process.
399
+
400
+ > ** Note**
401
+ > It is strongly advised to use the OpenTelemetry variant of Autometrics to support push-based metric
402
+ collection. Prometheus push gateways make aggregation of data across multiple sources harder.
403
+
404
+ _ How can I use a push-based workflow with Autometrics?_
405
+
406
+ If you have a Prometheus [ push
407
+ gateway] ( https://prometheus.io/docs/instrumenting/pushing/ ) or an OTLP
408
+ [ collector] ( https://opentelemetry.io/docs/collector/ ) setup with an accessible
409
+ URL, then you can directly switch from metric polling to metric pushing by
410
+ passing a non ` nil ` argument to ` autometrics.Init ` for the ` pushConfiguration ` :
411
+
412
+ ``` patch
413
+ shutdown, err := autometrics.Init(
414
+ "myApp/v2/prod",
415
+ autometrics.DefBuckets,
416
+ autometrics.BuildInfo{ Version: "2.1.37", Commit: "anySHA", Branch: "", Service: "myApp" },
417
+ - nil,
418
+ + &autometrics.PushConfiguration{
419
+ + CollectorURL: "https://collector.example.com",
420
+ + JobName: "instance_2", // You can leave the JobName out to let autometrics generate one
421
+ + Period: 1 * time.Second, // Period is only relevant when using OpenTelemetry implementation
422
+ + Timeout: 500 * time.Millisecond, // Timeout is only relevant when using OpenTelementry implementation
423
+ + },
424
+ )
425
+ ```
426
+
427
+ > ** Note**
428
+ > If you do not want to setup an OTLP collector or a Prometheus push-gateway yourself, you
429
+ can contact us so we can setup a managed instance of Prometheus for you. We will effectively
430
+ give you collector URLs, that will work with both OpenTelemetry and Prometheus; and can be
431
+ visualized easily with our explorer as well!
432
+
364
433
#### Git hook
365
434
366
435
As autometrics is a Go generator that modifies the source code when run, it
0 commit comments