• prometheus06 grafana可视化


    grafana可视化

    Prometheus有一个内置的仪表板和图形界面。非常简单,通常适合查看指标和呈现单个图表。为了给Prometheus添加一个功能更全面的可视化界面,可以选择与开源的Grafana进行集成。Grafana接收来自不同数据源的数据,然后提供可视化仪表板。它支持多种数据源,例如Graphite、Elasticsearch和Prometheus。

    值得注意的是,Prometheus通常不用于长期数据保留,默认保存15天的时间序列数据。这意味着Prometheus更专注于监控问题,而不是其它可视化和仪表板系统。针对Prometheus时间序列数据的处理,更加实用的方式是使用表达式浏览器、绘制Prometheus UI内置图形以及构建适当的警报,而不是构建大量的仪表板。

    1.Grafana服务器安装

    1.二进制安装

    1.下载grafana

    去官网,点击grafana下载链接进行下载;也可以使用国内镜像站下载,比如清华源:rpm安装grafana

    2.执行如下命令进行安装

    wget https://dl.grafana.com/oss/release/grafana-8.2.3-1.x86_64.rpm
    sudo yum install grafana-8.2.3-1.x86_64.rpm -y
    

    3.设置服务开始自启,并启动服务

    systemctl enable grafana-server
    systemctl start grafana-server  
    
    默认启动的是3000端口,可以根据grafana官方文档:https://grafana.com/docs/grafana/latest/installation/rpm/ 修改默认端口,
    

    2.容器安装

    docker pull grafana/grafana
    docker run -d -p 8080:3000 --name grafana grafana/grafana:latest
    
    使用docker-cpmpose启动
    mkdir /datadrive/grafana-storage -pv
    vim docker-compose.yml
    version: '3'
    
    networks:
     monitor:
      driver: bridge
    
    services:
     grafana:
       image: grafana/grafana
       container_name: grafana
       hostname: grafana
       restart: always
       volumes:
         - /datadrive/grafana-storage:/var/lib/grafana
         - ./grafana.ini:/etc/grafana/grafana.ini
       ports:
         - "80:3000"
       networks:
         - monitor
       #user: '472'
    
    值得注意的是,grafana容器没有启动,查看容器日志发现/var/lib/grafana目录没有写入全写,刚好是我们挂载的数据卷目录/datadrive/grafana-storage,是root用户创建的,默认是0755,现在修改权限为满权限:
    chmod -R a+w /datadrive/
    然后重新启动,一切正常:
    docker-compose up -d
    
    grafana 浏览器页面默认登录 用户名和密码都是:admin
    

    服务发现

    对于指定的每个目标,在抓取配置中手动列出了它们的IP地址和端口。这种方法在主机较少时还行,但不适用于规模较大的集群,尤其不适用于使用容器和基于云的实例的动态集群,这些实例经常会出现变化、创建或销毁的情况。

    Prometheus通过使用服务发现解决了这个问题:通过自动化的机制来检测、分类和识别新的变更的目标。服务发现可以通过以下几种机制实现:

    • 从配置管理工具生成文件中接收目标列表。
    • 查询API以获取目标列表。
    • 使用DNS记录以返回目标列表。

    1.基于文件的服务发现

    这些文件时可以YAML或JSON格式,包含定义的目标列表,就像我们在静态配置中定义的一样。让我们将现有作业迁移到基于文件的服务发现开始。

    - job_name: node
      file_sd_configs: # sd:service discovery 
        - files:
           - targets/nodes/*.json
           refresh_intervar: 5m
    - job_name: docker
      file_sd_configs:
        - files:
           - targets/docker/*.json
           refresh_intervar: 5m
    

    [info]还有一个名为prometheus_sd_files_mtime_seconds的指标告诉你文件的上次更新时间。你可以监控这个指标识别数据过期问题。

    1.创建文件夹并创建相对应的文件

    cd /etc/prometheus/
    mkdir -p targets/{nodes,docker}
    touch targets/nodes/nodes.json
    touch targets/docker/daemons.json
    

    2.针对node.json和daemons.json文件分别填充以下内容

    $ cat node.json
    
    [{
        "targets":[
            "192.168.1.121:9100"
        ]
    }]
    
    $ cat daemons.json
    [{
        "targets":[
            "192.168.1.121:8080"
        ]
    }]
    

    3.其实也可以通过YAML格式实现,如下所示:

    - targets:
      - "192.168.1.121:8080"
    

    当然,也可以添加一些标签

    [{
        "targets":[
            "192.168.1.121:8080"
        ],
        "labels":{
            "datacenter": "nj"
        }
    }]
    

    在这里,我们向Docker守护进程目标添加了值为nj的标签datacenter。基于文件的服务发信啊会在重新标记阶段自动给每个目标添加一个元数据标签__meta_filepath,它包含配置目标的文件路径和文件名。

    4.接下来,在浏览器中输入 http://192.168.1.121:9090/service-discovery界面来查看,如果出现如下类似结果,证明没有问题。

    2.基于API的服务发现

    原生的服务发现集成在某些工具和平台上提供,它们内置支持Prometheus,这些服务发现插件使用工具和现有的数据存储或API来返回目标列表。

    当前可用的本机制服务发现插件包括以下平台:

    • Amazon EC2[1]

    • Azure[2]

    • Consul[3]

    • Google Compute Cloud[4]

    • Kubernetes[5]

    监控Kubernetes上运行的应用程序会用到Kubernetes的服务发现。

    3.基于DNS的服务发现

    如果基于文件的服务发现不适合你,或者你的源或服务不支持任何现有的服务发现工具,则可以选择基于DNS的服务发现。DNS服务发现允许你指定DNS条目列表,然后查询这些条目中的记录以发现目标列表。它依赖于A、AAAA或SRV DNS记录查询。

    [info] DNS记录由Prometheus服务器上本地定义的DNS服务器解析。例如Linux上的/etc/resolv.conf.

    dns服务发现作于如下所示:

    - job_name: webapp
      dns_sd_configs:
      - names: [ '_prometheus._tcp.example.com' ]
    

    定义一个名为webapp的新作业,并指定了一个dns_sd_configs块。在该块中,指定了names参数,其中包含要查询的DNS条目列表。

    默认情况下,Prometheus的DNS服务发现假定你会查询SRV或服务记录。服务记录是一种在DNS配置中定义服务的方法,服务通常由运行服务的一个或多个目标主机和端口组合组成。DNS SRV条目的格式如下:

    _service._proto.name. TTL IN SRV priority weight port target.
    

    其中service是要查询的服务的名称,proto是服务的协议,通常是TCP或UDP。。我们指定条目的名称,后面以”.“结尾,然后是记录的TTL(Time To Live)时间。IN是标准的DNS类(通常都会用IN)。我们指定目标主机的优先级(priority):较低的值具有较高的优先级。权重(weight)控制具有相同优先级的目标的偏好:优选较高的值。最后,我们指定服务运行的端口以及提供服务的主机的主机名,以”.“结尾。因此,对于Prometheus,我们可能会定义如下记录:

    _prometheus._tcp.example.com. 300 IN SRV 10 1 9100 webapp1.example.com.
    _prometheus._tcp.example.com. 300 IN SRV 10 1 9100 webapp2.example.com.
    _prometheus._tcp.example.com. 300 IN SRV 10 1 9100 webapp3.example.com.
    

    当Prometheus查询目标时,他会通过DNS服务器查找example.com域。然后,它将在该域中搜索名为prometheus.tcp.example.com的 SRV记录,并返回该条目中的服务记录。在该条目中由三条记录,因此我们会看到返回了三个目标。

    webapp1.example.com:9100
    webapp2.example.com:9100
    webapp3.example.com:9100
    

    我们还可以使用DNS服务发现来查询单个A或AAAA记录。为此,我们需要为抓取明确指定查询类型和端口。之所以需要指定端口,是因为A和AAAA记录只返回主机,而不是像SRV记录那样返回主机和端口组合。

    - job_name: webapp
    dns_sd_configs:
    - names: [ 'example.com' ]
      type: A
      port:9100
    

    这只会返回example.com域根目录下的所有A记录。如果想从特定的DNS条目返回记录,那么我们会使用:

    - job_name: 'webapp'
      dns_sd_configs:
      - names: [ 'exampe1.com' ]
        type: A
        port: 9090
    

    在这里,提取一个子域web.example.com的A记录解析,并在后面加上9100端口后缀。

  • 相关阅读:
    jQuery火箭图标返回顶部代码
    类库引用EF
    Html.DropDownList
    MVC validation
    MVC @functions
    MVC 扩展方法特点
    Class 实现IDisposing方法
    MVC两个必懂核心
    Asp.net 服务器Application,Session,Cookie,ViewState和Cache区别
    sqlserver log
  • 原文地址:https://www.cnblogs.com/zhangchaocoming/p/15553017.html
Copyright © 2020-2023  润新知