@plko345 就是 prometheus，thanos 只是 prometheus 的 query 层，初期我们调研了很多时间序列数据库，influxdb(集群收费),TimescaleDB, FiloDB，cortex

苹果有版本验证通道，比如你要升级 12.4.1，要求这个版本的接口没有关闭，可以通过验证才可以升级。一般来说 ios 新版本一稳定就把就版本验证通道关闭了

随机放货的，以前做过这方面的小买卖。。。用监控软件监控的

还是直营店 24 期免息爽啊

很简单的 100 行不到，能不能实现这样，然后这样，然后这样，最后这样，哎你这个跑起来还是有点问题。

可以买一个无线移动电源，既可以在家用也可以带出门

美国官网 catalina 写的是 Available in October

@plko345 不是很理解你们的场景，但是有个思路是用 client-go 写一个脚本执行器，让它去调用比如 python 脚本，约定好脚本输出，由脚本执行器解析为 prometheus metrics，这样每次定义新型的 metrics 只需要写脚本就可以了。

@plko345 官方提供的 client lib 已经非常方便了,我们自己写的 exporter 也都是基于 client-java 和 client-go，基本我们用的中间件，官方和社区都已经提供了 prometheus metrics。

另外集群肯定是需要的，cluster 模式还是 sentinel 模式要看你们自己架构

redisson 可以解决你这个问题，本质是发布订阅，注册一个监听器，自己实现监听事件的具体业务就可以了

java 是提供了对 epoll 的封装，在 NIO 中，但是 NIO 编程复杂且成本高，所以我们都是用 netty 多一些，从 spring5 开始，异步响应式编程也开始成为主流，比如 Spring WebFlux。

@676529483 不认同，devops 对开发的要求还是比较高的，做出的支撑 /运维平台如果够好，能够帮助运维迅速定位问题，通过高度自动化的工具，运维人员简单操作就可以解决问题，甚至可以做到故障自愈，运维经验再丰富，也只有一双手而已，别忘了我们写代码本身就是让计算机为我们服务。
@polebug 《 SRE：Google 运维解密》这本书可以看下，里面主要是 DEVOPS 和运维的一些指导思想，我认为对你应该会有帮助

@polebug 我是做监控这块的，但不属于运维，我们做支撑平台，logging,metrics,tracing,监控三大领域先关注下，分别对应的轮子体系学习一下，logging elk, metrics 传统的 zabbix,如果上容器了就 Prometheus, 调用链 jaeger zipkin 这些，然后自动化运维，saltstack，告警，规模大的话可能还要用到一些其他的大数据组件比如 ck,flink 做一些大规模聚合，流式计算。以上仅限我个人理解

能否每天做一次 snapshot ？