@Nadao 唉, 没办法, 我们国家技术就这样, 不等能怎样呢, 美国在不断扩大检测规模, 我们都是有症状了要个人去医院主动检查, 还不准确

国内有道云比较符合你的需求，界面和操作属于习惯吧，只能适应下

这是啥工具？

我也是，我觉得上面几位没法理解你，或者说没法理解我们这样的情况

国内的检测不准，还是等美国的第七代吧，快又准

买个工程机刷？

哇，以更新，谢谢

估计在记录直接访问 github 的 ip ？(~_~;)

和 lz 情况相似，在用 flask

是全国都不好过吧

@phantomzz 好的，多谢

@derek80 @phantomzz 你好, 使用黏性会话解决了数据一致的问题, grafana 请求的时候始终会去访问其中一台 prometheus, 但有两个问题

1. grafana 上所有图表都会去这台 prom 上查询, 但如果出现大查询, 负载都在这台 prom 上, 内存占用很高, 会出现 OOM 危险
2. grafana 的所有查询请求都是以 grafana server 的 cookie 为准, 而用户是通过 grafana server 间接的请求, 因此 cookie 始终只有一个, 所有用户的查询都会发往一台 prom, 这也很危险...

请问你们是否遇到类似的问题, 我搜索了相关的情况, 但都没有比较好的解决方案, 目前做了限制查询量来防止比较大的查询导致的 OOM

PS: 我目前还不太想使用 thanos

@luozic 类里没有去重, 默认传入的是唯一的, 不过似乎应该加上, 多谢提醒

@ipwx 有道理, 我想想看, 主要我需要对不同的 tag 匹配, 不知道这样全统计会不会不灵活, 因为有的 tag 类型的不需要某些数据, 有的又需要, 不过我没多少数据, 这样全统计好像也没什么大问题

`-> Dict[str, int]` 你代码里的这个是什么意思

谢谢各位
@ipwx
@Orenoid
我试试这个 getattr 方法, 应该是我想要的, 这个类里的方法有 self 操作, 必须是实例方法

@ipwx 因为并不是全都需要统计, 有的只需要其中的一个, 有的需要多个

@phantomzz 可是官方文档并不建议使用 prometheus 本地存储，而且我们之前使用也遇到了不少问题，才买了阿里的 influxdb，但是有读写限制，用的也难受