豆瓣
扫码直接下载
读过 Prometheus: Up & Running
* You should try to follow the metric name practices, in particular, avoiding the _count, _sum, _total, _bucket and _info suffixes unless the time series is part of a metric that is meant to contain such a time series. * if a metric is a counter, don't forget to add the _total suffix. * Where practical you should try to provide units for your metrics, and at the very least try to ensure that units are in the metric name... Seconds and bytes are always prefered. * Labels should create a partition across a metric, and if you take a sum or average across a metric should be meaningful. * As with direct instrumentation, you should not apply a label such as env="prod" to all metrics coming from your exporter, as that's what target labels are for . * It's best to expose raw metrics to Prometheus, rather than doing calculations on the application side. * You should plan on running one exporter per application instance, and fetch metrics synchronously for each scrape without any caching. * Just as Prometheus adds a scrape_duration_seconds metric when performing a scrape, you may also add a myexporter_scrape_duration_seconds metric for how long it takes your exporter to pull the data from its application. * It can make sense for you to add direct instrumentation to exporters, in addition to the custom collectors that provide their core functionality. For example, the CloudWatch exporter has a cloudwatch_requests_total counter tracking the number of API calls it makes.. But this is usually only something that you will see with Blackbox/SNMP-style exporters.