这篇文章主要介绍“怎么配置Prometheus文件列表”，在日常操作中，相信很多人在怎么配置Prometheus文件列表问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么配置Prometheus文件列表”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
Prometheus是继Kubernetes（k8s）之后，CNCF毕业的第二个开源项目，其来源于Google的Borgmon。本文从“监控”这件事说起，深入浅出Prometheus的架构原理、目标发现、指标模型、聚合查询等设计核心点。
一、前言
接触过各式各样的监控，开源的CAT、Zipkin、Pinpoint等等，并深度二次开发过；也接触过收费的听云系APM，对各类监控的亮点与局限有足够的了解。
去年10月我们快速落地了一套易用、灵活、有亮点的业务监控平台，其中使用到了Prometheus。从技术选型阶段，Prometheus以及它的生态就让我们印象深刻，今天就聊聊监控设计与Prometheus。
通常一个监控系统主要包含 采集（信息源：log、metrics）、上报（协议:http、tcp）、聚合、存储、可视化以及告警等等。其中采集上报主要是客户端的核心功能，一般有定期外围探测的（早期的Nagios、Zabbix）、AOP方式手动织入代码的（埋点）、字节码自动织入等方式（无埋点）。
二、什么是监控
一套产品化的，用来量化管理技术、业务的服务体系或解决方案。
这套产品主要解决两个问题（产品价值）：
技术：将系统的各种功能、状态等技术表现数据化、可视化，来保证技术体系的稳定、安全等。
业务：将各种业务表现数据化、可视化，以供分析、及时干预，保证业务高效开展。
三、监控的基础原则
事前监控：架构设计阶段务必需要考虑监控，而不是等到部署上线才去考虑
监控什么：全局视角，自顶（业务）向下。对于一般业务来讲，建议先监控离用户最近的地方，用户的良好体验是推动业务发展的动力，这也是最敏感、重要的地方。
对用户友好：监控服务易用，易接入，尽可能自动化
技术人员、业务人员的信息源、能够协助故障定位与解决
可视化：清晰的显示各类数据（各类图表展示），以及告警等信息记录
告警：
哪些问题需要通知？（如：需要人工干预的，有意义的）
通知谁？（如：一线系统负责人）
如何通知？（如：短信、电话、其他通信工具；信息清晰、准确、可操作）
多久通知一次？（如：5分钟）
何时停止通知以及何时升级到其他人？（如：已恢复正常；两个小时问题未恢复，升级通知到上级负责人）
四、Prometheus设计剖析
Prometheu聚焦于当下正在发生的各类数据，而不是追踪数周以前的数据，因为他们认为“大多数监控查询以及告警等都是一天内的数据”， Facebook相关论文也验证了这一点:85%的时序查询是26个小时之内的。
简单来概括,普罗米修斯是一个准实时监控系统,并自带时序数据能力。
