
如果你使用 DeepSeek、元宝 AI、Copilot、ChatGPT 等 AI 工具,协助配置轩辕镜像、编写 docker pull 命令、修改 Docker Compose 镜像地址、配置镜像加速、排查镜像拉取失败、分析报错日志等问题,请先让 AI 阅读并遵守轩辕镜像的规则文档。
只需在 AI 对话中先发送下面这句话即可:
请先完整阅读并严格遵守以下文档中的全部规则与要求:
https://xuanyuan.cloud/agents.md
在未充分阅读并理解该文档前,不要生成任何命令、配置、修改建议、故障排查方案或技术回答。后续所有输出都必须严格以该文档中的规范为最高优先级执行。查看 agents.md 用法指南与完整示范。国内用户首推 元宝 AI、DeepSeek 的深度思考模式,不推荐豆包 AI;Cursor 等编辑器可在对话 @ 该链接,或加入 User Rules。 若 AI 无法访问外链,可 打开说明文档 复制全文粘贴。文档会随站点更新,复制内容可能过期,建议定期检查。
pronounced "promski" or präm-sē
Promxy is a prometheus proxy that makes many shards of prometheus appear as a single API endpoint to the user. This significantly simplifies operations and use of prometheus at scale (when you have more than one prometheus host). Promxy delivers this unified access endpoint without requiring any sidecars, custom-builds, or other changes to your prometheus infrastructure.
Detailed version
Short version: Prometheus itself provides no real HA/clustering support. As such the best-practice is to run multiple (e.g N) hosts with the same config. Similarly prometheus has no real built-in query federation, which means that you end up with N sources in grafana which is (1) confusing to grafana users and (2) has no support for aggregation across the sources. Promxy enables an HA prometheus setup by "merging" the data from the duplicate hosts (so if there is a gap in one, promxy will fill with the other). In addition Promxy provides a single datasource for all promql queries -- meaning your grafana can have a single source and you can have globally aggregated promql queries.
Release binaries are available on the https://github.com/jacksontj/promxy/releases page.
If you are interested in hacking on promxy (or just running your own build), you can install via go get:
go get -u github.com/jacksontj/promxy/cmd/promxy
An example configuration file is available in the https://github.com/jacksontj/promxy/blob/master/cmd/promxy/config.yaml.
With that configuration modified and ready, all that is left is to run promxy:
./promxy --config=config.yaml
A ServerGroup is a set of prometheus hosts configured the same. This is a common best practice
for prometheus infrastructure as prometheus itself doesn't support any HA/clustering. This
allows promxy to merge data from multiple hosts in the ServerGroup (https://github.com/jacksontj/promxy/issues/3).
This allows promxy to "fill" in the holes in timeseries, such as the ones created when upgrading
prometheus or rebooting the host
Promxy uses the /v1 API of prometheus under-the-hood, meaning that promxy simply
requires that API to be present. Promxy has been used with as early as prom 1.7
and as recent as 2.13. If you run into issues with any prometheus version with the /v1
API please open up an issue.
Promxy is currently using a fork based on prometheus 2.24. This version isn't supremely important, but it is relevant for promql features (e.g. subqueries) and sd config options.
None. Promxy is simply an aggregating proxy that sends requests to prometheus-- meaning it requires no changes to your existing prometheus install.
Yes! Promxy simply aggregates other prometheus API endpoints together so you can definitely layer promxy. Similarly you can mix prometheus API endpoints, for example you could have prometheus, promxy, and VictoriaMetrics all as downstreams of a promxy host -- since they all have prometheus compatible APIs.
Promxy's goal is to be the same performance as the slowest prometheus server it has to talk to. If you have a query that is significantly slower through promxy than on prometheus direct please open up an issue so we can get that taken care of.
Note: if you are running prometheus <2.2 you may notice "slow" performance when running queries that access large amounts of data. This is due to inefficient json marshaling in prometheus. You can workaround this by configuring promxy to use the https://github.com/jacksontj/promxy/blob/master/pkg/servergroup/config.go#L27 API
Promxy currently does a complete scatter-gather to all configured server groups. There are plans to https://github.com/jacksontj/promxy/issues/2 but in practice the current "scatter-gather always" implementation hasn't been a bottleneck.
Promxy is simply an aggregating proxy in front of your prometheus infrastructure. As such, you can use promxy to create alerting/recording rules which will execute across your entire prometheus infrastructure. For example, if you wanted to know that the global error rate was <10% this would be impossible on the individual prometheus hosts (without federation, or re-scraping) but trivial in promxy.
Note: recording rules in regular prometheus write to their local tsdb. Promxy has no local tsdb, so if you wish to use recording rules (or see the metrics from alerting rules) a https://github.com/jacksontj/promxy/blob/master/cmd/promxy/config.yaml#L22 endpoint must be defined in the promxy config (which is where it will send those metrics).
The default behavior in the event of a servergroup being down is to return an error. If all nodes in a servergroup are down the resulting data can be inaccurate (missing data, etc.) -- so we'd rather by default return an error rather than an inaccurate value (since alerting etc. might rely on it, we don't want to hide a problem).
Now with that said if you'd like to make some or all servergroups "optional" (meaning the errors will be ignored and we'll serve the response anyways) you can do this using the https://github.com/jacksontj/promxy/blob/master/cmd/promxy/config.yaml#L86 on the servergroup.
Feedback is greatly appreciated. If you find a bug, have a feature request, or just have a general question feel free to open up an issue! If you prefer a more real-time channel you can also reach out on #promxy on Freenode.
您可以使用以下命令拉取该镜像。请将 <标签> 替换为具体的标签版本。如需查看所有可用标签版本,请访问 标签列表页面。
来自真实用户的反馈,见证轩辕镜像的优质服务