@Winrey 嗯，这是一个比较大的问题，目前大家是通过一个手动 refresh button 来解决的，通过 js 定时 refresh 也可以解决部分问题。

@Themyth 通过 AskRewind ，需要加入一下 wait list ，不过现在好像秒过

https://kevinchen.co/blog/rewind-ai-app-teardown/ 找到一篇解析 Rewind 技术方面的文章

@xarthur 从使用下来看压缩比极高，官方的说法是大部分人每个月 14G ，压缩应该在内存中就完成了，所以写入应该不太多；对于我个人来说，可以降低对大脑的负担，不用怕一些事情忘记了； Rewind 官方给出得到 Common Case 如下：

追溯步骤：如果你对上周的分析数据和今天的不匹配感到困惑，只需倒回你的电脑，找出你做了什么不同的事情。

追踪错误原因：你可以通过回溯时间，找出软件中出现意外行为的原因。

再也不用担心在会议中走神：曾经被叫到并需要参考刚刚展示的东西吗？现在你可以倒回时间，轻松找到你需要的信息。

自信地关闭你的标签页：停止无限期地保持数百个标签页打开，以防你以后需要它们。有了 Rewind ，你可以在任何时候轻松回到任何已关闭的标签页。

唤醒你的记忆：如果你被打断或被拉离你的电脑，你可以使用 Rewind 来唤醒你的记忆，回到你的工作状态。

不再担心崩溃：Rewind 是你所有信息的安全网。如果你不小心关闭了你正在写的文章，或者你的调查表格在句子中间崩溃，你可以轻松回到你在屏幕上看到的任何东西。

@dimlau 目前是可以搜索的，配置 Additional Language Support 就支持中文了。

🐮 楼主说的日志场景 stern 可以搞定

去医院看看吧，当时我也以为自己是神经性耳鸣，没想到是油性耳朵耳屎太多了，在医院洗了两次耳朵听力恢复正常。

可以尝试一下在 Pod 运行的时候尝试去宿主机直接 docker restart <container>，看下容器是否能够正常重启，Docker 的版本是多少啊 @zhoudaiyu 可以加个微信探讨一下 YW55aXNhbGlu

可以尝试看看 Terminating 状态中的 Pod 的 meta.finalizers 字段的内容和所在宿主机的 kubelet 日志排查下

去年七月入了 i9+32G 版本的 16，感觉很亏，每天 cpu 90 度以上 + 风扇嗡嗡嗡，性能吧除了编译和虚拟机也感觉不出来。

感觉需要买热搜，不然热度上不去呀。

@Themyth #13 电脑直接拨号好像没这个问题，就是桥接需要这么操作，不桥接没这问题。

1. 打开 ER-X 的管理页面
2. Dashboard -> Interfaces -> 配置 PPPOE 接口(类型为 pppoe) -> 修改 MTU 为 1442 保存重新拨号

@Themyth @Aether

解决了，好像是 mtu 问题，我把 er-x pppoe 接口的 mtu 改成 1400 好像就好了。 @yding @xenme @et5494

@Kastner #1 我下行速率 1000M，桥接模式没法加速的，不要求 1000M，有个 500 也行啊

楼主你开了精品网之后，国内的网速还正常么，我用 VIP1 拨号后，SpeedTest 国内只能到 100M+

Prometheus, Zabbix 之类的方案都行，就是抓取周期为 1s 频率太高，这里的难点在于你的数据要存储多久。

Zabbix 的问题在于后端 数据通过 MySQL 存储，数据库是一个很大的瓶颈，横向扩展只能通过类似 Sharding 的方案来做。
Prometheus 支持的插件比较多，大部分中间件都能覆盖，而且 TSDB 的性能很强劲，性能应该不是问题，但集群方案得借助第三方方案类似 Thanos, Cortex 来解决，并且对内存的要求很高 (默认 2 小时内的数据都放在内存里，如果 1s 一次采集，数据量太大了)，如果要做的话，你这种需求可能要用 hasmod + thanos 才能搞定。

ELK (MetricBit) 的方案也是可以的，扩展性很强，但是你这种时间粒度和规模的要求，索引会很大，并且 Elasticsearch 本身的维护成本也很高。

主要的难点不是 2000 台机器，同样是 2000 台机器，15/30 秒抓取一次 1s 的抓取频率，会让数据规模翻几十倍。