prometheus是采用TSDB（时序存储）来存储数据的

    prometheus本身是个时序存储系统，这个系统带了数据抓取器，所以也类似是个数据库，在db-engines.com 数据库网站中也是有排名的，带有存储引擎

    关系型数据库每次写入都有很大的性能消耗
    zabbix就是采用关系型数据库存储数据的，当量上来的时候就会产生性能瓶颈

    单个指标的参考价值不会特别大，需要将单个指标聚合起来，作统一分析

    监控系统：周期性采集
    监控系统一是怎么采集数据、采集哪些数据；二是采集到数据后，数据如何存储；三是把存储中的数据展示出来；四把异常的数据指标通知业务处理人员
    采集：采集器、被监控端：监控代理、应用程序自带仪表盘；黑盒监控；SNMP（监控网络设备）
    存储：SQL、NoSQL（k/v、document(文档存储)、colum(列式存储)、TSDB(时序存储)）
    额外：分析数据：DataOps、AIOps (根据采集过来的数据做聚合分析，大数据、人工智能那一套，超出监控范围了)
    展示：grafana 支持多种数据源
    报警(Alert)：告警通知，媒介：Email、短信、Wechat、Dingtalk、Slack

    db-engines.com/en/ranking 网站对各种数据库的采用指标做了排名

    国外一本书：《监控的艺术》

    常见的开源监控系统实现：
    Cacti（监控网络设备居多）、Nagios（告警能力强大）、zabbix
    Prometheus（有很好的服务发现能力，能动态纳入各个监控的对象，无需手动配置）CNCF项目
    OpenFalcon 小米的，但是创始人已经跳槽到滴滴了，维护不力
    夜莺，也是国产
    CAT，美团点评的

    Prometheus架构：
    short-lived jobs：短期监控任务
    Pushgateway：接收prometheus server不能直接拉取到的监控数据
    service discovery：服务发现
    Prometheus server：Retrieval、TSDB、HTTP server
    Alertmanager：告警管理器
    Prometheus web UI：告警展示

    prometheus创始人是Goole前员工，后来到SoundCloud去了，模仿Borg的监控系统Borgmon开发的，k8S就是基于Borg二次开发的
    2012年就开发研发了，2015年发布，2016.5 年加入CNCF

    时间序列数据统称为metric，并且有独创的指标格式，Prometheus格式，程序在版本迭代时都内置一个仪表盘
    一个程序要想被监控，一般有黑盒、白盒两种方式，白盒是指程序内建的指标，能够被采集的时候就直接暴露给监控系统使用，这种就是内建的仪表盘，或者内建的测量系统，现在很多程序在内建的仪表盘中的格式都是prometheus格式或者prometheus兼容的格式的
    Metric支持多维度标签，每个独立的标签组合都代表一个独立的时间序列（时间序列就是样本数据采集下来的结果），也会称为时序数据
    数据模型非常随意，不像mysql那样要定义好表、库之类的

    在对应的指标上添加一个标签就会生成一个时序数据

    内建时序数据的聚合、切割、切片功能
    支持双精度浮点型数据；prometheus所存的数据都是双精度浮点型数据，所以是不能存文本的，就是不能支持存储log日志，zabbix可以存日志，es也是可以的

    TSDB：时序存储

    自带数据抓取器，抓取过来后存储到内建的时序数据库中
    自带采集器，这个采集器有很灵活很高效的可配置能力，就是能对目标监控进行多维度的配置

    时序存储是为了监控而设置的
    默认存储保存的时间是有限的，默认一个月
    可以对接远程存储系统

    prometheus 完整名称应该是prometheus server，只是内置了数据抓取器、数据存储器的监控服务端，还需要其他组件
    监控系统的数据采集模型：
    Pull：拉数据，由监控系统主动联系被监控端，把数据拿过来 （你产生数据了，我过来拿）
    Push：推数据，被监控端主动联系监控系统，把数据推给监控端（我产生数据了，推送给你）
    两种方式各有优劣

    zabbix支持两个agent，其实就是pull 和 push

    prometheus架构组件：
    prometheus server：监控服务端
    Retrieval：内置的数据采集器，是基于http来实现的，即每一个被抓取的指标就得是http协议的，https的话就要配置证书，
    TSDB：内置的数据存储，时序存储，这个存储只是短暂的，需要长期存储还得对接远程存储，或者存储到磁盘上 HDD/SSD
    PromQL：内置数据处理语言
    HTTP server：服务端
    pushgateway：推送网关，有些短期任务或者批处理作业不能被prometheus server直接拉取数据，就会把数据先推送到pushgateway上，prometheus server再到pushgateway拉取数据
    Alertmanager：监控管理器
    prometheus web ui：自带的数据展示web，但是不够清晰，外接入grafana
    service discovery：服务发现机制，

    prometheus server 监控数据采集是基于pull模式的，就是是主动拉数据的，所以对server 端压力较大
    但也有一些是拉不到的，比如批处理作业，这时候就得需要别的组件协助了，叫作Pushgateway，推送网关，批处理作业先把数据推送到pushgateway上，然后prometheus server再到pushgateway上拉取
    prometheus server内置的TSDB存储数据只是短期的，需要长期存储的话需要对接远程存储系统，比如influencedb数据库
    prometheus server 还内置有自己独特的查询语言 PromQL，告警也是建立在这个QL实现的
    通过PromQL查询出现的数据展示出来，就这样一个web ui，用得上grafana
    prometheus server自己通过PromQL清楚一些数据异常，判断告警，但不能实现告警，这就还需要一个告警管理器，Alertmanager

    应用程序内置的仪表盘，就是内建了测量系统
    简单理解就是程序本身就
    export：指标暴露器，监控插件

    单向认证，要配置对方的ca
    双向认证，要配置客户端证书

    基于HTTP call，从配置文件中指定的网络端点（endpoint）上周期性获取指标数据
    网络端点即 ip：port/metrics

    linux内核没有自带的web服务器，prometheus抓取不来内核数据
    被抓取数据端得暴露http才行

    prometheus支持通过三种类型的途径从目标上“抓取（Scrape）”指标数据：（即让被抓取端暴露http或者支持prometheus）
    exporters：监控插件
    instrumentation：应用程序内建的测量系统
    pushgateway：推送网关
    无论哪种方式，prometheus server端一定是pull metrics的
    prometheus server —-> pull metrics —-> exporters
    prometheus server —-> pull metrics —-> instrumentation
    prometheus server —-> pull metrics —-> pushgateway <—- push metrics <—- batch jobs

    微服务下不部分的服务都是通过http或者https工作的，就比较符合了

    内存空间使用率

    指标类型 metric types
    prometheus使用4种方法来描述监视的指标
    counter：计数器
    gauge：仪表盘
    histogram：直方图，支持分位数统计
    summary：摘要，支持分位数统计

    作业 实例 targe

    promQL Prometheus Query Language
    key由指标名称和id组成

    PromQL支持两种向量 （向量就是带方向和大小的）
    即时向量：最近一次的时间戳上跟踪的数据指标 （即时—实时—最近一次时间）
    时间范围向量：指定时间范围内的所有时间戳上的数据指标

    Alerts
    抓取到异常值后，Prometheus支持通过“告警（Alert）”机制向用户发送反馈或告警，以触发用户能够即时采取应对措施

    官方下载：prometheus.io/download
    可以单独二进制安装
    也可以通过yaml部署到k8s中
    下载解压缩后查看目录内容
    prometheus 服务端目录
    promtool 客户端工具
    consoles 控制台
    consoles_libraries 控制台库
    直接启动：./prometheus
    查看启动端口：ss -tln
    服务端口：9090

    ip:9090 就是内置的web ui

    每个数据时序都有两个标签，instance 表示监控端点，job表示监控作业

    配置文件
    全局的
    数据采集时间间隔，默认1分钟采集一次

    scrape configs：抓取配置项

    定义targets有两种方式
    一是静态指定，static_configs,就直接配置targets
    二是动态发现，

    安装node-exporter
    ./node-exporter —help
    启动：./node-exporter
    访问ip:9100/metrics

    prometheus指标抓取的生命周期
    服务发现—配置—重新标记relabel_configs—指标数据抓取—重新标记mertic_relabel_configs

    prometheus可集成的服务发现机制
    基于文件的服务发现：仅仅略优于静态配置的服务发现方式，它依赖于任务
    基于DNS的服务发现
    基于API的服务发现：kubernetes、consul、Azure

    运维人员一定要把CMDB弄起来，即使只有几台服务器，有了CMDB，才能更好的进行项目、权限及各种配置管理

    grafana 端口 3000
    prometheus 端口 9000