{"id":13570132,"url":"https://github.com/autometrics-dev/autometrics-go","last_synced_at":"2025-08-20T16:31:20.999Z","repository":{"id":143371949,"uuid":"604076094","full_name":"autometrics-dev/autometrics-go","owner":"autometrics-dev","description":"Easily add metrics to your system -- and actually understand them using automatically customized Prometheus queries","archived":false,"fork":false,"pushed_at":"2024-01-25T12:33:57.000Z","size":643,"stargazers_count":143,"open_issues_count":9,"forks_count":9,"subscribers_count":3,"default_branch":"main","last_synced_at":"2024-12-10T02:20:22.543Z","etag":null,"topics":["go","golang","metrics","monitoring","observability","prometheus","telemetry","tracing"],"latest_commit_sha":null,"homepage":"https://autometrics.dev","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/autometrics-dev.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE-APACHE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-02-20T09:32:18.000Z","updated_at":"2024-11-28T23:55:57.000Z","dependencies_parsed_at":"2024-06-12T16:02:58.351Z","dependency_job_id":"2d4d49c5-4afb-4701-ae12-4e3221eca504","html_url":"https://github.com/autometrics-dev/autometrics-go","commit_stats":{"total_commits":62,"total_committers":7,"mean_commits":8.857142857142858,"dds":"0.32258064516129037","last_synced_commit":"c8417f17cbc21d88b8d6ebab3ff5191816b7d09e"},"previous_names":[],"tags_count":15,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/autometrics-dev%2Fautometrics-go","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/autometrics-dev%2Fautometrics-go/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/autometrics-dev%2Fautometrics-go/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/autometrics-dev%2Fautometrics-go/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/autometrics-dev","download_url":"https://codeload.github.com/autometrics-dev/autometrics-go/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":230438185,"owners_count":18225870,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["go","golang","metrics","monitoring","observability","prometheus","telemetry","tracing"],"created_at":"2024-08-01T14:00:48.623Z","updated_at":"2024-12-19T13:07:14.847Z","avatar_url":"https://github.com/autometrics-dev.png","language":"Go","funding_links":[],"categories":["Go"],"sub_categories":[],"readme":"![GitHub_headerImage](https://user-images.githubusercontent.com/3262610/221191767-73b8a8d9-9f8b-440e-8ab6-75cb3c82f2bc.png)\n\n[![Go Reference](https://pkg.go.dev/badge/github.com/autometrics-dev/autometrics-go.svg)](https://pkg.go.dev/github.com/autometrics-dev/autometrics-go)\n[![Discord Shield](https://discordapp.com/api/guilds/950489382626951178/widget.png?style=shield)](https://discord.gg/kHtwcH8As9)\n\nMetrics are a powerful and cost-efficient tool for understanding the health and\nperformance of your code in production, but it's hard to decide what metrics to\ntrack and even harder to write queries to understand the data.\n\nAutometrics is a [Go\nGenerator](https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processing_source)\nbundled with a library that instruments your functions with the most useful\nmetrics: request rate, error rate, and latency. It standardizes these metrics\nand then generates powerful Prometheus queries based on your function details to\nhelp you quickly identify and debug issues in production.\n\n## Benefits\n\n- ✨ `//autometrics:inst` directive adds useful metrics to any function, without you thinking about what metrics to collect\n- 💡 Generates powerful Prometheus queries to help quickly identify and debug issues in production\n- 🔗 Injects links to live Prometheus charts directly into each function's doc comments\n- [📊 Grafana dashboards](https://github.com/autometrics-dev/autometrics-shared#dashboards) work without configuration to visualize the performance of functions \u0026 [SLOs](https://docs.rs/autometrics/latest/autometrics/objectives/index.html)\n- 🔍 Correlates your code's version with metrics to help [identify commits](https://fiberplane.com/blog/autometrics-rs-0-4-spot-commits-that-introduce-errors-or-slow-down-your-application) that introduced errors or latency\n- 📏 Standardizes metrics across services and teams to improve debugging\n- ⚖️ Function-level metrics provide useful granularity without exploding cardinality\n\n## Advanced Features\n\n- [🚨 Define alerts](#generate-alerts-automatically) using SLO best practices directly in your source code\n- [📍 Attach exemplars](#exemplar-support) automatically to connect metrics with traces\n- [⚙️ Configurable](#opentelemetry-support) metric collection library\n  ([`opentelemetry`](https://pkg.go.dev/go.opentelemetry.io/otel) or\n  [`prometheus`](https://pkg.go.dev/github.com/prometheus/client_golang))\n\nSee [autometrics.dev](https://docs.autometrics.dev/) for more details on the ideas behind autometrics.\n\n## Example\n\n![Documentation comments of instrumented function is augmented with links](./assets/codium-screenshot-example.png)\n\nWhen alerting rules are added, code annotations make Prometheus trigger alerts\ndirectly from production usage:\n\n![a Slack bot is posting an alert directly in the channel](./assets/slack-alert-example.png)\n\nA fully working use-case and example of library usage is available in the\n[examples/web](./examples/web) subdirectory. You can build and run load on the\nexample server using:\n\n```console\ngit submodule update --init\ndocker compose -f docker-compose.prometheus-example.yaml up\n```\n\nAnd then explore the generated links by opening the [main\nfile](./examples/web/cmd/main.go) in your editor.\n\n# Quickstart\n\nThere is a one-time setup phase to prime the code for autometrics. Once this\nphase is accomplished, only calling `go generate` is necessary.\n\n### 1. Install the go generator.\n\nThe generator is the binary in cmd/autometrics, so the easiest way to get it is\nto install it through go:\n\n```console\ngo install github.com/autometrics-dev/autometrics-go/cmd/autometrics@latest\n```\n\n\u003cdetails\u003e\n\u003csummary\u003e Make sure your `$PATH` is set up\u003c/summary\u003e\nIn order to have `autometrics` visible then, make sure that the directory\n`$GOBIN` (or the default `$GOPATH/bin`) is in your `$PATH`:\n\n``` console\n$ echo \"$PATH\" | grep -q \"${GOBIN:-$GOPATH/bin}\" \u0026\u0026 echo \"GOBIN in PATH\" || echo \"GOBIN not in PATH, please add it\"\nGOBIN in PATH\n```\n\u003c/details\u003e\n\n### 2. Import the libraries and initialize the metrics\n\nIn the main entrypoint of your program, you need to both add package\n\n``` go\nimport (\n\t\"github.com/autometrics-dev/autometrics-go/prometheus/autometrics\"\n)\n```\n\nAnd then in your main function initialize the metrics\n\n``` go\n\tshutdown, err := autometrics.Init()\n\tif err != nil {\n\t\tlog.Fatalf(\"could not initialize autometrics: %s\", err)\n\t}\n\tdefer shutdown(nil)\n```\n\n`Init` takes optional arguments to customize the metrics. The main ones are `WithBranch`, \n`WithService`, `WithVersion`, and `WithCommit`; it will add relevant information on the\nmetrics for better intelligence:\n\n```go\n\tshutdown, err := autometrics.Init(\n\t\tautometrics.WithService(\"myApp\"),\n\t\tautometrics.WithVersion(\"0.4.0\"),\n\t)\n\tif err != nil {\n\t\tlog.Fatalf(\"could not initialize autometrics: %s\", err)\n\t}\n\tdefer shutdown(nil)\n```\n\nYou can use any string variable whose value is\ninjected at build time by `ldflags` for example, or use environment variables.\n\n\u003e **Note**\n\u003e Instead of hardcoding the service in the code, you can simply have environment variables set to fill the \"Service\" name.\n`AUTOMETRICS_SERVICE_NAME` will be used if set, otherwise `OTEL_SERVICE_NAME` will be attempted (so OpenTelemetry\ncompatibility comes out of the box).\n\n### 3. Add directives for each function you want to instrument\n\n#### 3a. The QUICKEST way\n\nIf you have [`am`](https://github.com/autometrics-dev/am) installed in version `0.6.0` or later, you can\nuse `am instrument single -e /vendor/ -l go .` to instrument everything (excluding a possible `/vendor` subdirectory)\n\n#### 3b. The VERY quick way\n\nUse find and sed to insert a `//go:generate` directive that will instrument all\nthe functions in all source files under the current directory:\n\n(Replace `gsed` with `sed` on linux; `gsed` is installed with `brew gsed`)\n\n``` bash\nfind . \\\n  -type d -name vendor -prune -or \\\n  -type f -name '*.go' \\\n  -print0 | xargs -0 gsed -i -e '/package/{a\\//go:generate autometrics --inst-all --no-doc' -e ':a;n;ba}'\n```\n\nYou can remove the `--no-doc` to get the full experience, but the generator will add a lot of comments if so.\n\n#### 3c. The slower quick way\n\nThis grants you more control over what gets instrumented, but it is longer\nto add.\n\n\u003e **Warning**\n\u003e You must both add the `//go:generate` directive, and one `//autometrics:inst`\ndirective per function you want to instrument\n\nOn top of each file you want to use Autometrics in, you need to have a `go generate` cookie:\n\n``` go\n//go:generate autometrics\n```\n\nThen instrumenting functions depend on their signature, expand the corresponding\nsubsection to see details:\n- if the function [returns an `error`](#for-error-returning-functions), or\n- if the function [is a `http.Handler`](#for-http-handler-functions).\n\nOnce it is done, you can call the [generator](#4-generate-the-documentation-and-instrumentation-code)\n\n##### For error-returning functions\n\n\u003cdetails\u003e\u003csummary\u003e\u003ci\u003eExpand to instrument error returning functions\u003c/i\u003e\u003c/summary\u003e\n\nGiven a starting function like:\n\n```go\nfunc AddUser(args any) error {\n        // Do stuff\n        return nil\n}\n```\n\nThe manual changes you need to do are:\n\n```patch\n+//autometrics:inst\n-func AddUser(args any) error {\n+func AddUser(args any) (err error) {\n        // Do stuff\n        return nil\n}\n```\n\nThe generated metrics will count a function as having failed if the `err` return value is non-nil.\n\n\u003e **Warning**\n\u003e If you want the generated metrics to contain the function success rate, you\n_must_ name the error return value. This is why we recommend to name the error\nvalue you return for the function you want to instrument.\n\u003c/details\u003e\n\n##### For HTTP handler functions\n\n\u003cdetails\u003e\u003csummary\u003e\u003ci\u003eExpand to instrument HTTP handlers functions\u003c/i\u003e\u003c/summary\u003e\n\nAutometrics comes with a middleware library for `net.http` handler functions.\n\n- Import the middleware library\n\n``` go\nimport \"github.com/autometrics-dev/autometrics-go/prometheus/midhttp\"\n```\n\n- Wrap your handlers in `Autometrics` handler\n\n``` patch\n\n\thttp.Handle(\n\t\t\"/path\", \n+\t\tmidhttp.Autometrics(\n-\t\thttp.HandlerFunc(routeHandler),\n+\t\t\thttp.HandlerFunc(routeHandler),\n+\t\t\t// Optional: override what is considered a success (default is 100-399)\n+\t\t\tautometrics.WithValidHttpCodes([]autometrics.ValidHttpRange{{Min: 200, Max: 299}}),\n+\t\t\t// Optional: Alerting rules\n+\t\t\tautometrics.WithSloName(\"API\"),\n+\t\t\tautometrics.WithAlertSuccess(90),\n+\t\t)\n\t)\n```\n\nThe generated metrics here will count a function as having failed if the return\ncode of the handler is bad (in the `4xx` and `5xx` ranges). The code snippet\nabove shows how to override the ranges of codes that should be considered as\nerrors for the metrics/monitoring.\n\n\u003e **Note**\n\u003e There is only middleware for `net/http` handlers for now, but support for other web frameworks will\ncome as needed/requested! Don't hesitate to create issues in the repository.\n\n\u003e **Warning**\n\u003e To properly report the function name in the metrics, the autometrics wrapper should be the innermost\nmiddleware in the stack.\n\u003c/details\u003e\n\n### 4. Generate the documentation and instrumentation code\n\nYou can now call `go generate`:\n\n```console\n$ go generate ./...\n```\n\nThe generator will augment your doc comment to add quick links to metrics (using\nthe Prometheus URL as base URL), and add a unique defer statement that will take\ncare of instrumenting your code.\n\n`autometrics --help` will show you all the different arguments that can control\nbehaviour through environment variables. The most important options are\n[changing the\ntarget](#make-generated-links-point-to-different-prometheus-instances) of\ngenerated links, or [disabling doc generation](#remove-the-documentation) to\nkeep only instrumentation\n\n### 5. Expose metrics outside\n\nThe last step now is to actually expose the generated metrics to the Prometheus instance.\n\nThe shortest way is to reuse `prometheus/promhttp` handler in your main entrypoint:\n\n``` go\nimport (\n\t\"github.com/autometrics-dev/autometrics-go/prometheus/autometrics\"\n\t\"github.com/prometheus/client_golang/prometheus/promhttp\"\n)\n\n\nfunc main() {\n\tshutdown, err := autometrics.Init(\n\t\tautometrics.WithVersion(\"0.4.0\"),\n\t\tautometrics.WithCommit(\"anySHA\"),\n\t\tautometrics.WithService(\"myApp\"),\n\t)\n\thttp.Handle(\"/metrics\", promhttp.Handler())\n}\n```\n\nThis is the shortest way to initialize and expose the metrics that autometrics will use\nin the generated code.\n\nA Prometheus server can be configured to poll the application, and the autometrics will be available! (See the [Web App example](./examples/web) for a simple, complete setup)\n\n### Run Prometheus locally to validate and preview the data\n\nYou can use the open source Autometrics CLI to run automatically configured Prometheus locally to see the metrics that will be registered by the change. See the [Autometrics CLI docs](https://docs.autometrics.dev/local-development#getting-started-with-am) for more information.\n\nor you can configure Prometheus manually:\n\n```yaml\nscrape_configs:\n  - job_name: my-app\n    metrics_path: /metrics # the endpoint you configured your metrics exporter on (usually /metrics)\n    static_configs:\n      - targets: ['localhost:\u003cPORT\u003e'] # The port your service is on\n    scrape_interval: 200ms\n    # For a real deployment, you would want the scrape interval to be\n    # longer but for testing, you want the data to show up quickly\n```\n\nYou can also check the documentation to find out about setting up Prometheus\n[locally](https://docs.autometrics.dev/configuring-prometheus/local), with\n[Fly.io](https://docs.autometrics.dev/configuring-prometheus/fly-io), or with\n[Kubernetes](https://docs.autometrics.dev/configuring-prometheus/kubernetes)\n\n---\n\n# Optional advanced features\n\n#### Generate alerts automatically\n\nChange the annotation of the function to automatically generate alerts for it:\n\n``` go\n//autometrics:inst --slo \"Api\" --success-target 90\nfunc AddUser(args any) (err error) {\n        // Do stuff\n        return nil\n}\n```\n\nThen **you need to add** the [bundled](./configs/shared/autometrics.rules.yml)\nrecording rules to your prometheus configuration.\n\nThe valid arguments for alert generation are:\n- `--slo` (*MANDATORY* for alert generation): name of the service for which the objective is relevant\n- `--success-rate` : target success rate of the function, between 0 and 100 (you\n  must name the `error` return value of the function for detection to work.)\n- `--latency-ms` : maximum latency allowed for the function, in milliseconds.\n- `--latency-target` : latency target for the threshold, between 0 and 100 (so X%\n  of calls must last less than `latency-ms` milliseconds). You must specify both\n  latency options, or none.\n  \n\u003e **Warning**\n\u003e The generator will error out if you use percentile targets that are not\nsupported by the bundled [Alerting rules file](./configs/shared/autometrics.rules.yml).\nSupport for custom target is planned but not present at the moment\n\n\n\u003e **Warning** \n\u003e You **MUST** have the `--latency-ms` values to match the values\n given in the buckets given in the `autometrics.Init` call. The values in the\n buckets are given in _seconds_. By default, the generator will error and tell\n you the valid default values if they don't match. If the default values in\n `autometrics.DefBuckets` do not match your use case, you can change the\n buckets in the init call, and add a `--custom-latency` argument to the\n `//go:generate` invocation.\n```patch\n-//go:generate autometrics\n+//go:generate autometrics --custom-latency\n```\n\n#### Exemplar support\n\nWhen using the Prometheus library for metrics collection, it automatically adds\ntrace and span information in the metrics as exemplars that can be queried with\nPrometheus, [if the server is configured\ncorrectly](https://prometheus.io/docs/prometheus/latest/feature_flags/#exemplars-storage)\n\n![A prometheus graph that shows exemplars on top of metrics](./assets/prometheus-exemplars.png)\n  \n#### OpenTelemetry Support\n\nAutometrics supports using OpenTelemetry with a prometheus exporter instead of using\nPrometheus to publish the metrics. The changes you need to make are:\n\n- change where the `autometrics` import points to\n```patch\nimport (\n-\t\"github.com/autometrics-dev/autometrics-go/prometheus/autometrics\"\n+\t\"github.com/autometrics-dev/autometrics-go/otel/autometrics\"\n)\n```\n- maybe change the call to `autometrics.Init` to the new signature: instead of a registry,\nthe `Init` function takes a meter name for the `otel_scope` label of the exported\nmetric. That means `autometrics` won't have a `WithRegistry` option anymore, but a \n`WithMeterName` instead.\n\n``` patch\n\tshutdown, err := autometrics.Init(\n-\t\tautometrics.WithRegistry(nil),\n+\t\tautometrics.WithMeterName(\"myApp/v2/prod\"),\n\t\tautometrics.WithVersion(\"2.1.37\"),\n\t\tautimetrics.WithCommit(\"anySHA\"),\n\t\tautometrics.WithService(\"myApp\"),\n\t)\n```\n\n- add the `--otel` flag to the `//go:generate` directive\n\n```patch\n-//go:generate autometrics\n+//go:generate autometrics --otel\n```\n\n#### Push-based workflows\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003ci\u003eWhy would I use a push-based workflow?\u003c/i\u003e\u003c/summary\u003e\n\nIf you have an auto-scaled service (with instances spinning up and down),\nmaintaining the configuration/discovery of instances on the Prometheus side of\nthings can be hard. Using a push-based workflow inverts the burden of\nconfiguration: all your instances generate a specific ID, and they just need to\npush metrics to a given URL. So the main advantages of a push-based workflow\nappear when the the set of machines producing metrics is dynamic:\n\n- Your Prometheus configuration does not need to be dynamic anymore, it's \"set\n  and forget\" again\n- No need to configure service discovery separately (which can be error-prone)\n\n\nIt can be summarized with one sentence. \u003cb\u003eThe monitoring stack\n(Prometheus/OpenTelemetry collector) does not need to know the infrastructure of\napplication deployment; nor does the application code need to know the\ninfrastructure of the monitoring stack. Decoupling prevents\nconfiguration-rot.\u003c/b\u003e\n\n\u003c/details\u003e\n\nIf you don't want to/cannot configure your Prometheus instance to scrape the\ninstrumented code, Autometrics provides a way to push metrics instead of relying\non a polling collection process.\n\n\u003e **Note**\n\u003e It is strongly advised to use the OpenTelemetry variant of Autometrics to support push-based metric\ncollection. Prometheus push gateways make aggregation of data across multiple sources harder.\n\n_How can I use a push-based workflow with Autometrics?_\n\nIf you have a Prometheus [push\ngateway](https://prometheus.io/docs/instrumenting/pushing/) or an OTLP\n[collector](https://opentelemetry.io/docs/collector/) setup with an accessible\nURL, then you can directly switch from metric polling to metric pushing by\npassing the push-related options to `autometrics.Init`:\n\n``` patch\n\tshutdown, err := autometrics.Init(\n\t\tautometrics.WithMeterName(\"myApp/v2/prod\"),\n\t\tautometrics.WithVersion(\"2.1.37\"),\n\t\tautometrics.WithService(\"myApp\"),\n+\t\t autometrics.WithPushCollectorURL(\"https://collector.example.com\"),\n+\t\t autometrics.WithPushJobName(\"instance_2\"),                         // You can leave the JobName out to let autometrics generate one\n+\t\t autometrics.WithPushPeriod(1 * time.Second),                       // Period is only relevant (and available) when using OpenTelemetry implementation\n+\t\t autometrics.WithPushTimeout(500 * time.Millisecond),               // Timeout is only relevant (and available) when using OpenTelementry implementation\n\t)\n```\n\n\u003e **Note**\n\u003e If you do not want to setup an OTLP collector or a Prometheus push-gateway yourself, you\ncan contact us so we can setup a managed instance of Prometheus for you. We will effectively\ngive you collector URLs, that will work with both OpenTelemetry and Prometheus; and can be \nvisualized easily with our explorer as well!\n\n#### Logging\n\nMonitoring/Observability must not crash the application.\n\nSo when Autometrics encounters\nerrors, instead of bubbling it up until the program stops, it will log the error and absorb it.\nTo leave choice in the logging implementation (depending on your application dependencies),\nAutometrics exposes a `Logger` interface you can implement and then inject in the `Init` call\nto have the logging you want.\n\nThe `Logger` interface is a subset of `slog.Logger` methods, so that most loggers can be used.\nAutometrics also provides 2 simple loggers out of the box:\n- `NoOpLogger`, which is the default logger and does nothing,\n- `PrintLogger` which uses `fmt.Print` to write logging messages on stdout.\n \nTo use the `PrintLogger` instead of the `NoOpLogger` for examble, you just have to change\nthe `Init` call:\n\n``` patch\n\tshutdown, err := autometrics.Init(\n\t\tautometrics.WithMeterName(\"myApp/v2/prod\"),\n\t\tautometrics.WithVersion(\"2.1.37\"),\n\t\tautometrics.WithService(\"myApp\"),\n+\t\t autometrics.WithLogger(autometrics.PrintLogger{}),\n\t)\n```\n\n#### Git hook\n\nAs autometrics is a Go generator that modifies the source code when run, it\nmight be interesting to set up `go generate ./...` to run in a git pre-commit\nhook so that you never forget to run it if you change the source code.\n\nIf you use a tool like [pre-commit](https://pre-commit.com/), see their\ndocumentation about how to add a hook that will run `go generate ./...`.\n\nOtherwise, a simple example has been added in the [configs folder](./configs/pre-commit)\nas an example. You can copy this file in your copy of your project's repository, within\n`.git/hooks` and make sure that the file is executable.\n\n## Tips and Tricks\n\n##### Make generated links point to different Prometheus instances\nBy default, the generated links will point to `localhost:9090`, which the default location\nof Prometheus when run locally.\n\nThe environment variable `AM_PROMETHEUS_URL` controls the base URL of the instance that\nis scraping the deployed version of your code. Having an environment variable means you\ncan change the generated links without touching your code. The default value, if absent,\nis `http://localhost:9090/`.\n\nYou can have any value here, the only adverse impact it can\nhave is that the links in the doc comment might lead nowhere useful.\n\n##### Remove the documentation\nBy default, autometrics will add a lot of documentation on each instrumented\nfunction. If you prefer not having the extra comments, but keep the\ninstrumentation only, you have multiple options:\n\n- To disable documentation **on a single function**, add the `--no-doc` argument to the `//autometrics:inst` directive:\n``` patch\n-//autometrics:inst\n+//autometrics:inst --no-doc\n```\n- To disable documentation **on a file**, add the `--no-doc` argument to the `//go:generate` directive:\n``` patch\n-//go:generate autometrics\n+//go:generate autometrics --no-doc\n```\n- To disable documentation **globally**, use the environment variable `AM_NO_DOCGEN`:\n``` console\n$ AM_NO_DOCGEN=true go generate ./...\n```\n\n##### Offboarding\n\nIf for some reason you want to stop using autometrics, the easiest way includes 3 steps.\n\nFirst is to use the environment variable `AM_RM_ALL` to remove all generated documentation\nand code:\n\n``` console\n$ AM_RM_ALL=true go generate ./...\n```\n\nSecond step is to use grep/your text-editor/your IDE of choice to remove all lines starting with\n`//go:generate autometrics` from your files so `go generate` will stop creating autometrics code.\n\nLast step is to use your text-editor IDE to remove remnants:\n- a \"go imports\" cleaner to remove the `autometrics` imports (or grep-ing again)\n- remove the `autometrics.Init` call from the main entrypoint of your code.\n\n# Contributing\n\nThe first version of the library has _not_ been written by Go experts. Any comment or\ncode suggestion as Pull Request is more than welcome!\n\nIssues, feature suggestions, and pull requests are very welcome!\n\nIf you are interested in getting involved:\n- Join the conversation on [Discord](https://discord.gg/9eqGEs56UB)\n- Ask questions and share ideas in the [Github Discussions](https://github.com/orgs/autometrics-dev/discussions)\n- Take a look at the overall [Autometrics Project Roadmap](https://github.com/orgs/autometrics-dev/projects/1)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fautometrics-dev%2Fautometrics-go","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fautometrics-dev%2Fautometrics-go","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fautometrics-dev%2Fautometrics-go/lists"}