1.从指标到洞察力的原理源码源码普罗米修斯
2.prometheus各个exporter安装
3.通过transmittable-thread-local源码理解线程池线程本地变量传递的原理
4.基于Prometheus + Grafana搭建IT监控报警最佳实践(2)
5.小公司也可以0成本构建统一的告警管理体系
6.2020-08-25

从指标到洞察力的普罗米修斯

       从指标到洞察力的普罗米修斯详解

       普罗米修斯作为领先的开源监控解决方案，旨在从用户指标和告警需求出发，分析提供强大的原理源码源码支持。在云原生时代，分析它尤其适用于解决指标埋点和异常监控问题，原理源码源码如服务稳定性监控和故障预测分析（Unknow-Unknow）等。分析锋彩直播 源码

       起源于SoundCloud的原理源码源码普罗米修斯，自年开源以来，分析由Google BorgMon监控系统演变而来，原理源码源码现已成为CNCF的分析重要项目。它具备强大的原理源码源码多维度指标监控告警能力，通过其架构，分析我们可以从发现服务、原理源码源码采集数据到分析告警，分析一目了然。原理源码源码

       架构方面，Prometheus涉及服务发现、数据采集、监控分析等环节，涉及术语如指标、收集器、监控黄金信号和指标类型（Counter、Gauge、Histogram、Summary）。通过一个简单的入门示例，我们可以了解如何安装、配置和使用Prometheus来监控自身指标。

       安装后，我们可以通过访问Dashboard，监控指标查询，学习PromQL进行数据查询和可视化。完善的比特狗系统源码Prometheus帮助我们快速定位问题，支持指标驱动开发（MDD），在开发过程中就规划好监控埋点，以便于尽早发现和解决问题。

       然而，尽管功能强大，使用普罗米修斯时还需注意其适用范围和注意事项。想要深入了解，可以通过《中间件源码》公众号进一步交流。

prometheus各个exporter安装

       在监控系统中，Prometheus是一个强大的开源监控解决方案，它依赖于各种exporter来收集服务的指标。以下是关于如何在您的系统上安装几个关键exporter的步骤：

       首先，对于基础的系统监控，node_exporter是一个必备工具。它能够收集关于系统资源使用情况的数据，如CPU、内存、磁盘和网络信息。安装过程通常是通过包管理器（如apt或yum）或者从GitHub克隆源代码后编译安装。

       对于数据库监控，Mysqld_exporter专门用于MySQL服务器，可以展示数据库的运行状态和性能指标。安装时，您需要从Prometheus的官方GitHub存储库下载适配器，然后按照文档指示配置和启动。

       对于内存数据库Redis，可以使用Redis_exporter来监控其内存使用、命令执行情况等。安装方法与Mysqld_exporter类似，只需针对Redis进行配置即可。

       对于Java应用的监控，jvm_exporter是融源码头电子一个很好的选择，它能从Java虚拟机（JVM）中提取性能数据。安装时，需要确保它与您的JVM版本兼容，并正确配置JMX连接。

       对于Web服务器监控，特别是使用Nginx的环境，可以考虑安装nginx-vts-exporter。这个模块允许Prometheus直接从Nginx的VTS模块获取日志和性能数据，方便对Nginx性能进行深入监控。

       安装完成后，别忘了在Prometheus配置文件中添加对应的exporter，以确保数据的采集。每个exporter的配置都需要根据您的具体环境进行调整，以确保数据的准确性和完整性。

通过transmittable-thread-local源码理解线程池线程本地变量传递的原理

       最近几周，我投入了大量的时间和精力，完成了UCloud服务和中间件迁移至阿里云的工作，因此没有空闲时间撰写文章。不过，回忆起很早之前对ThreadLocal源码的分析，其中提到了ThreadLocal存在向预先创建的线程中传递变量的局限性。恰好，我的一位前同事，HSBC的技术大牛，提到了团队引入了transmittable-thread-local（TTL）来解决此问题。借此机会，我深入分析了TTL源码，本文将全面分析ThreadLocal和InheritableThreadLocal的局限性，并深入探讨TTL整套框架的实现。如有对线程池和ThreadLocal不熟悉的读者，建议先阅读相关前置文章，本篇文章行文较为干硬，多国语言源码字数接近5万字，希望读者耐心阅读。

       在Java中，没有直接的API允许子线程获取父线程的实例。获取父线程实例通常需要通过静态本地方法Thread#currentThread()。同样，为了在子线程中传递共享变量，也常采用类似的方法。然而，这种方式会导致硬编码问题，限制了方法的复用性和灵活性。为了解决这一问题，线程本地变量Thread Local应运而生，其基本原理是通过线程实例访问ThreadLocal.ThreadLocalMap来实现变量的存储与传递。

       ThreadLocal与InheritableThreadLocal之间的区别主要在于控制ThreadLocal.ThreadLocalMap的创建时机和线程实例中对应的属性获取方式。通过分析源码，可以清楚地看到它们之间的联系与区别。对于不熟悉概念的读者，可以尝试通过自定义实现来理解其中的原理与关系。

       ThreadLocal和InheritableThreadLocal的最大局限性在于无法为预先创建的线程实例传递变量。泛线程池Executor体系、TimerTask和ForkJoinPool等通常会预先创建线程，因此无法在这些场景中使用ThreadLocal和InheritableThreadLocal来传递变量。

       TTL提供了更灵活的解决方案，它通过委托机制（代理模式）实现了变量的传递。委托可以基于Micrometer统计任务执行时间并上报至Prometheus，然后通过Grafana进行监控展示。此外，TTL通过字节码增强技术（使用ASM或Javassist等工具）实现了类加载时期替换Runnable、Callable等接口的实现，从而实现了无感知的增强功能。TTL还使用了模板方法模式来实现核心逻辑。神马app源码修改

       TTL框架的核心类TransmittableThreadLocal继承自InheritableThreadLocal，通过全局静态变量holder来管理所有TransmittableThreadLocal实例。holder实际上是一个InheritableThreadLocal，用于存储所有线程本地变量的映射，实现变量的全局共享。disableIgnoreNullValueSemantics属性的设置可以影响NULL值的处理方式，影响TTL实例的行为。

       发射器Transmitter是TransmittableThreadLocal的一个公有静态类，提供传输TransmittableThreadLocal实例和注册当前线程变量至其他线程的功能。通过Transmitter的静态方法，可以实现捕获、重放和复原线程本地变量的功能。

       TTL通过TtlRunnable类实现了任务的封装，确保在执行任务时能够捕获和传递线程本地变量。在任务执行前后，通过capture和restore方法捕获和重放变量，实现异步执行时上下文的传递。

       启用TTL的Agent模块需要通过Java启动参数添加javaagent来激活字节码增强功能。TTL通过Instrumentation回调激发ClassFileTransformer，实现目标类的字节码增强，从而在执行任务时自动完成上下文的捕捉和传递。

       TTL框架提供了一种高效、灵活的方式来解决线程池中线程复用时上下文传递的问题。通过委托机制和字节码增强技术，TTL实现了无入侵地提供线程本地变量传递功能。如果您在业务代码中遇到异步执行时上下文传递的问题，TTL库是一个值得考虑的解决方案。

基于Prometheus + Grafana搭建IT监控报警最佳实践(2)

       见字如面，大家好，我是小斐。延续前文，本文将深入探讨Prometheus和Grafana的监控体系。

       首先，我们需要打开Prometheus和Grafana进行操作，访问地址分别为：...:/ 和 ...:/。

       以node_exporter数据采集器为例，先确保其已安装于需要监控的主机。若要获取...主机的状态数据，需在该主机安装node_exporter采集器。

       在prometheus.yml中添加需要抓取的目标源信息，具体操作为：在scrape_configs下添加job_name，指定静态目标，添加...:目标。

       配置文件配置完成后，由于是静态的，需要重新加载配置文件，重启Prometheus以生效。

       在targets中查看是否已抓取到目标，根据上图可见，...的主机节点数据已抓取到。在Prometheus中验证数据正确性，点击mand first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。

       templates： 告警模板目录，可以不编写模板，有默认模板

            Subject: '{ { template "email.default.subject" . }}'

            html: '{ { template "email.default.html" . }}'

       route：报警的分发设置

            group_by：分组

            group_wait: 分组等待时间

            group_interval: 5m 每组时间间隔

            repeat_interval: m 重复间隔

            receiver: 接收方式，请注意！这里的名字要对应下面receivers中的任何一个名字，不然会报错，这里其实就是选择方式，有邮箱，企业微信，wehook，victorops等等

       receivers：接受方式汇总，即告警方式汇总

        例子：

        receivers:

        - name:'default-receiver' 

        email_configs:

        - to:'whiiip@.com'    

          html: '{ { template "alert.html" . }}'    

          headers: { Subject: "[WARN] 报警邮件test"}

       inhibit_rules:   æŠ‘制规则

        当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。

        包括源匹配和目标匹配

        alertmanager官方是这样说的

        Inhibition

        Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.

        Example:  An alert is firing that informs that an entire cluster is not reachable. Alertmanager can be configured to mute all other alerts concerning this cluster if that particular alert is firing. This prevents notifications for hundreds or thousands of firing alerts that are unrelated to the actual issue.

        Inhibitions are configured through the Alertmanager's configuration file.

        当存在与另一组匹配器匹配的警报（源）时，禁止规则会使与一组匹配器匹配的警报（目标）静音。目标警报和源警报的equal列表中的标签名称都必须具有相同的标签值。

        在语义上，缺少标签和带有空值的标签是同一件事。因此，如果equal源警报和目标警报都缺少列出的所有标签名称，则将应用禁止规则。

        为了防止警报禁止自身，与规则的目标和源端 都 匹配的警报不能被警报（包括其本身）为真来禁止。但是，我们建议选择目标匹配器和源匹配器，以使警报永远不会同时匹配双方。这很容易进行推理，并且不会触发此特殊情况。

        接着是规则rules

       ä¸è§£é‡Šäº†ï¼Œè‡ªå·±ç ”究官方文档

       alertmanager的非容器安装方式是

         wget /prometheus/alertmanager/releases/download/v0..0/alertmanager-0..0.linux-amd.tar.gz

        tar xf alertmanager-0..0.linux-amd.tar.gz

       mv alertmanager-0..0.linux-amd /usr/local/alertmanager

       vim /usr/lib/systemd/system/alertmanager.service

       [Unit]

       Description=alertmanager

        Documentation=/prometheus/alertmanager

        After=network.target

        [Service]

        Type=simple

        User=root

        ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

        Restart=on-failure

        [Install]

        WantedBy=multi-user.target

        Alertmanager 安装目录下默认有 alertmanager.yml 配置文件，可以创建新的配置文件，在启动时指定即可。

        其余方式和上面一样

        接着是Prometheus，我之前的博客里有写了容器安装和非容器安装的方法，自己去翻阅

        然后是在prometheus.yml里修改相关配置

        首先去掉alertmanager的注释，改成IP加你设置的端口号，默认是

       æŽ¥ç€åœ¨rule_files: 下面写下规则文件的绝对路径，可以是具体文件名，也可以是*，也可以分几级文件，*默认是全部匹配

       æŽ¥ç€æ˜¯è¢«ç›‘控项的设置，这里设置完成可以在Prometheus网页里的targets里看得到

        请注意，这里设置的参数名字要和rule规则中设置的参数名字一模一样，否则你的prometheus服务会无法启动，然后报错

        如果不在特定的job下设置scrape_interval（优先级高于全局）,则默认采用gobal下的scrape_interval

       æœ€åŽæ¨¡æ‹ŸèŠ‚点掉线，手动关闭node-exporter或者Cadvisor

        docker stop node-exporter 或者容器ID

        docker stop cadvisor æˆ–者容器ID

        或者把up{ { job='prometheus'}} == 1 设置成1，反向设置，不用关掉服务，就可以看看告警成不成功

       è¯´æ˜Žä¸€ä¸‹ Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

        Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。

        Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。

        Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

       æ²¡æœ‰é…ç½®å‘Šè­¦æ¨¡æ¿æ—¶çš„默认告警格式是这样的

       èŠ‚点恢复后邮件告知是这样的

       å†™äº†æ¨¡æ¿åŽæ˜¯è¿™æ ·çš„

       è¿˜è¦é‡æ–°æ˜ å°„模板文件夹路径到alertmanager容器里的相对路径，然后重启alertmanager，当然，如果目录下没有模板文件，则不显示

       å‘Šè­¦æ¨¡æ¿

       åœ¨alertmanager.yml中修改相关设置

        重启alertmanager

        docker restart alertmanager

        最终效果不是很好

Opentelemetry和Prometheus的remote-write-receiver的实验

       实验目标：探索并实践Opentelemetry和Prometheus的集成，利用Prometheus的远程写功能与Opentelemetry的collector相结合，实现指标的主动推送，并通过Prometheus进行可视化管理。

       实验环境：需要准备一个运行的Prometheus实例，以及一个Opentelemetry的collector。具体配置和部署步骤需参照实验环境部分。

       实验过程：首先，配置Prometheus以抓取本地指标，通过修改Prometheus配置文件并启动windows_exporter实现本地指标的生成与输出。接着，配置和启动Opentelemetry的collector，确保其支持与Prometheus的远程写功能。在这一阶段，需要根据源代码（例如：wuqingtao/opentelemetry_demo/otel-collector-config.yaml）进行相应的调整。最后，通过执行指标生成命令（源代码来自：wuqingtao/opentelemetry_demo/app），确保指标能够被正确生成并主动推送至Prometheus。

       可视化面板：在Prometheus中设置抓取目标，通常为运行的Prometheus实例。配置完成后，访问Prometheus控制面板，通过采集器面板查看并管理指标。同时，利用Prometheus的可视化功能，对主动写入的指标进行分析与监控。

       实验结果：借助Prometheus的远程写功能和Opentelemetry的collector，实现了指标的主动推送至Prometheus。这一集成使得实时监控和分析数据成为可能，进一步强化了监控系统的能力，提升了数据处理效率。

如何在prometheus产生告警时自动执行某个脚本文件

       在使用prometheus进行监控时，为了在产生告警时实现自动化操作，如执行特定脚本文件，可以结合webhook功能实现这一需求。webhook提供了一种将告警事件转换为可执行操作的机制，本文将详细介绍如何配置webhook，以及如何通过执行脚本文件自动处理告警信息。

       在prometheus和alertmanager的体系中，告警机制主要通过规则配置文件（rule.yaml）来定义告警条件。当监控到指标值异常时，alertmanager将向指定的webhook发送告警信息。通过配置webhook，我们可以在接收到告警信息的同时，触发自定义脚本执行，实现更精细化的告警处理。

       为了搭建webhook服务，可以访问其官方GitHub仓库（github.com/adnanh/webhook）获取相关文档。对于Ubuntu系列的环境，可以通过apt命令轻松安装webhook服务；其他操作系统环境下，需要通过编译源码的方式安装webhook，并确保服务在端口监听。

       搭建webhook服务后，通过编辑配置文件，配置webhook的访问路径和相关参数。在配置完成后，重启服务以确保配置生效。通过访问http://{ webhook_ip}:{ port}/hooks/{ webhook_id}（默认端口为）的URL，可以验证webhook是否正常工作。在接收到告警信息后，webhook将执行预先配置的脚本文件（如/root/test.sh），并记录执行结果，确保脚本执行的可靠性和可追踪性。

       为了扩展webhook的功能，可以修改其默认端口以适应不同环境需求。通过调整webhook服务的配置文件，添加端口参数，例如将端口更改为，确保服务重启后端口变更生效。

       为了实现特定告警内容的自动化处理，如将Ceph状态异常时的健康详细信息发送到企业微信机器人，可以整合prometheus、alertmanager和webhook。在配置prometheus告警规则和alertmanager告警接收时，确保两者能够无缝对接。通过编写自定义脚本（如/root/trigger.sh），在接收到告警信息时执行特定操作，例如执行命令获取详细信息并发送至企业微信机器人。

       在执行过程中，模拟业务故障（如停止Ceph的osd服务）可以验证告警机制的正确性和脚本执行的有效性。通过检查企业微信机器人收到的消息，确保告警内容准确无误，并且在故障恢复时也能收到相应的恢复告警。

       通过上述配置和实践，webhook不仅简化了告警处理流程，还提供了高度定制化的解决方案，使得在接收到告警时可以执行一系列自动化操作。这不仅提高了问题响应的效率，还增强了监控系统的灵活性和实用性。

Prometheus TSDB源码解析，Index索引存储格式分析

       Prometheus TSDB的Index索引存储格式详解

       Prometheus在数据存储过程中，当Head中的时间范围达到一定阈值时，会将数据归档到Block中，以保持高效查询性能。这个过程涉及Compact操作，具体实现见tsdb/db.go的Compact方法。整个系统结构包括多个文件，如G2KPG4ZND4WA3GZYB和ULID标识的Block，其中包含时间范围内的样本数据，chunk和index文件组织了这些数据。

       Index文件是关键，它详细记录了Series的索引信息。首先，TOC（目录）部分包含文件中Symbol Table、Series、Label Indices等的索引位置，固定长度字节，便于快速定位。Symbol Table存储Series中的标签值对，按照升序排序，包含每个标签值的长度、索引以及CRC校验。

       Series部分描述了每个Series对Chunk的引用，包括系列长度、标签对数量、标签值索引引用、chunk位置信息以及元数据，采用差分编码节省空间。Label Indices记录每个标签名下的所有值，同样按照索引存储，便于快速查找。Postings则记录每个标签值对对应的所有系列引用。

       Label Offset Table用于记录标签值在Label Index中的位置，而Postings Offset Table则记录每个键值对对应的Postings索引。这些结构共同构成了Prometheus查询的核心索引，理解它们对于理解查询流程至关重要。

       本文深入剖析了Prometheus的源码和文档，揭示了Index文件的详细结构，接下来将深入讲解查询流程和Block中Chunk的格式。后续内容将更加详细地揭示Prometheus如何利用这些结构实现高效的数据检索。