对容器了解的不多。不过按现在主流的方式来说。好像prometheus对容器的监控更好一些。按我的理解我应该会用zabbix监控网络和主机性能， prometheus来主要针对容器监控。形成一个互补的监控方案...

nacos是注册中心，能否以此为接入点，通过nacos监控在nacos注册的各种服务？ 这个只是监控“状态” 。如果要以指标为切入点，传统的就用 prometheus 堆栈，流行的就用ebpf可观测框架

要确认各组件（k8s、容器、Prometheus、数据库）的时间和时区是否一致

排查思路简述如下:1 查看系统中应用进程的日志，分辨与抽取有效的报错或导致进程退出的信息，基本就可以解决90%的问题。2 查看node_exporter底层的资源状态及其系统日志与调用依赖组件的日志。定位之道在于过程中产生的痕迹抓取与分析，解决之道在于自信力！...

1、强大的数据模型：Prometheus中有一个内置的时间序列数据库（TSDB），采集到的所有监控数据都会以一种指标的形式存储在里面。除了储存了基本的名称外，还有描述每一个样本的标签。指标名称和一组标签是判定每一条时间序列的唯一标识，且它按照时间的前后顺序去保存一系列的样本值...

首先，这个是使用 Prometheus过程中遇到的一个问题，Prometheus 本身只支持单机部署，没有自带支持集群部署，也就不支持高可用以及水平扩容，在大规模场景下，最让人关心的问题是它的存储空间也受限于单机磁盘容量。磁盘容量决定了单个 Prometheus 所能存储的数据量，数据量大小又取决...

Prometheus有自带的WEBUI，但界面不是很好，granfana图形做的比较炫，常用来做监控大屏。

向厂商要开发api是正确方法，如果没有可以走snmp，或者cli，但都比较消耗设备控制器性能。然后开发接口对接p和展示的g

上述方案概括为：基本HA + 远程存储 + 联邦集群 该方案在我在一个项目上落地过，客户场景为：管理为省级-地市级，每个地市是独立的监控中心，统一汇报至省级prometheus，省级prometheus通过nginx做高可用，持久化数据使用influxdb来存储省级prometheus数据。      落地需注意如...

问的不是很完整（1）zabbix是完整的监控解决方案，但prometheus不是，prometheus仅仅是一个数据收集数据库，prometheus+alertmanager+grafana才算是（2）两者都不是很难，容器云中多用prometheus+grafana，虚拟机实体机多用zabbix（3）并不绝对，对于某些zabbix告诉，完全可以zabbix+脚本实现对容...