Tomcat启动流程
Tomcat组件1. Connector组件12new Connector(String protocol) ProtocolHandler.creater(String protocol, boolean apr) return new org.apache.coyote.http11.Http11NioProtocol();
容器内构建镜像的几种方式
背景在云原生趋势下，用容器的方式来进行软件产品交付越来越普通，对于云原生的DevOps，它的CICD环境完全运行在容器中，镜像的构建也是在容器中完成的。而我们不仅要考虑如何在容器中成功构建镜像，也需要考虑如何以更安全的方式来构建容器镜像。
容器内构建镜像的方式容器中构建镜像一般分为两种：
在Docker容器中运行Docker,依赖Docker Daemon
Kaniko -K8s中构建镜像，不依赖Docker Daemon
在Docker容器中运行Docker这两种方式，一种需要root权限，一种需要privileged特权，从安全角度来看是有风险的。特别是在K8S多租户的场景下，这种方式不能被接受。同时当一台机器上同时运行多个docker build流水线时，因为这批流水线用的是宿主机上同一个docker进程，会出现阻塞的情况。
通过挂载docker.sock运行docker：需要root权限
通过挂载docker.sock运行docker，使用默认Unix套接字docker.sock作为卷的情况下运行docker 。缺点：只有root权限才能访问docker daemon进程 ...
Kubernetes集群部署
Kubernetes集群部署
1、配置kubernetes源镜像库123456789cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF
2、安装docker、kubelet、kubectl、kubeadm1yum install -y docker-ce kubectl-1.20.6 kubelet-1.20.6 kubeadm-1.20.6
3. Master节点初始化(Worker节点跳过 ...
Prometheus最佳实践(二)——代码埋点
Prometheus 代码埋点（Instrumentation）最佳实践本文档来自 Prometheus 官方文档 - Instrumentation，提供在应用程序和服务中进行指标埋点的指导原则和具体建议。
一、总体原则
“埋点一切”：每个库、子系统和服务都应至少包含几个基础指标，以反映其运行状态。
埋点应内置于代码中：在使用指标的同一文件中实例化指标对象，便于从告警 → 控制台 → 代码快速定位问题。
日志与指标联动：每有一行日志输出，就应有一个对应的计数器（counter）。这有助于量化错误频率和持续时间。
二、按服务类型分类的埋点策略1. 在线服务型（Online-serving）
用户或系统期待立即响应（如 HTTP 服务、数据库）。
关键指标：
请求总数（requests_total）
错误数（errors_total，按错误类型打标签）
延迟（使用 Histogram 或 Summary）
正在处理的请求数（Gauge，in_flight_requests）
建议：
客户端与服务端均需埋点，便于对比排查问题。
统一在请求结束时计数（便于与错误、延迟对齐）。
...
Prometheus最佳实践(六)——Pushgateway
Prometheus Pushgateway 使用指南与最佳实践（中文总结）本文档来自 Prometheus 官方文档 - When to use the Pushgateway，核心观点是：Pushgateway 仅适用于极少数特定场景，不应作为常规指标采集手段。盲目使用会带来严重问题。
一、Pushgateway 是什么？
一个中间代理服务，允许无法被 Prometheus 主动拉取（scrape）的作业主动推送（push）指标。
详细机制见 Pushing metrics。
二、为什么不推荐常规使用？1. 破坏 Prometheus 的拉取模型优势
❌ 失去自动健康监控：Prometheus 通过 up 指标判断目标是否存活。Pushgateway 本身始终“up”，即使原始作业已崩溃。
❌ 生命周期错位：
Pushgateway 永不自动删除已推送的指标序列（time series），即使原始作业已终止或重命名。
结果：陈旧指标长期存在，污染监控数据。
对比：拉取模式下，实例消失 → 指标自动消失。
2. 架构风险
❌ 单点故障 & 性能瓶颈：多个作业通 ...
Prometheus最佳实践(四)——告警
Prometheus 告警（Alerting）最佳实践（中文总结）本文档来自 Prometheus 官方文档 - Alerting，核心思想源自 Google 工程师 Rob Ewaschuk 的《My Philosophy on Alerting》，强调简洁、有效、可操作的告警设计。
一、核心原则1. 告警应基于“症状”，而非“原因”
✅ 告警用户可见的问题：如高延迟、错误率上升、服务不可用。
❌ 避免告警底层原因：如磁盘快满、CPU 使用率高（除非已直接影响用户体验）。
好处：减少噪音，聚焦真正需要响应的问题。
2. 告警必须可操作
每个告警都应有明确的值班人员可执行的动作。
如果收到告警后“什么也做不了”或“只需等待自动恢复”，就不该触发页面通知（Pager）。
3. 保持告警数量极少
只保留那些真正需要人工干预的告警。
目标：每天最多几条有效告警，避免“告警疲劳”。
二、告警层级策略1. 分层告警（只在关键点告警）
延迟（Latency）：
仅在最靠近用户的层级告警（如 API 网关）。
若底层组件变慢但整体用户体验未受损，则不告警。
错误率（Error Rate ...
Prometheus最佳实践(五)——记录规则
Prometheus 记录规则（Recording Rules）最佳实践（中文总结）本文档来自 Prometheus 官方文档 - Recording Rules，重点在于如何为记录规则设计清晰、一致且可维护的命名方案，以提升可读性并避免逻辑错误。
一、记录规则命名规范记录规则的名称应遵循以下通用格式：
1level:metric:operations
各部分含义：
level：表示聚合级别，即输出指标中保留的标签维度。示例：instance_path、path、job
metric：原始指标名称，应保持不变，仅在使用 rate()/irate() 处理计数器时移除 _total 后缀。示例：requests（源自 requests_total）
operations：按从新到旧顺序列出对指标执行的操作。示例：rate5m、ratio_rate5m、mean5m
✅ 好处：一眼看出规则含义，错误计算会显得“格格不入”。
二、操作命名约定
场景
操作名
说明
使用 rate() 或 irate()
rate5m、irate1m 等
包含时间窗口
多个相 ...
Prometheus最佳实践(一)——指标命名
Prometheus 指标命名最佳实践本文档来自 Prometheus 官方文档 - Metric and label naming，虽非强制要求，但提供了指标（metric）和标签（label）命名的风格指南与最佳实践。
一、指标名称（Metric Names）命名规则
字符合法性：必须符合 Prometheus 数据模型中对合法字符的要求。
前缀（命名空间）：
应包含一个与指标所属领域相关的单字应用前缀（也称 namespace）。
对于特定应用的指标，通常直接使用应用名作为前缀。
示例：
prometheus_notifications_total（Prometheus 服务器特有）
process_cpu_seconds_total（多个客户端库通用）
http_request_duration_seconds（所有 HTTP 请求通用）
单位一致性：
一个指标只能有一种单位（不能混用秒和毫秒、字节和千字节等）。
应使用基本单位（base units），例如：
时间：秒（seconds）
存储：字节（bytes）
长度：米（meters）
温度：摄氏度（cel ...
Prometheus最佳实践(三)——Histogram与Summary
Prometheus直方图（Histograms）与摘要（Summaries）使用指南本文档来自 Prometheus 官方文档 - Histograms and summaries，旨在帮助用户在直方图（Histogram）和摘要（Summary）之间做出合理选择，并正确配置和使用它们。
⚠️ 注意：本文档撰写于 原生直方图（Native Histograms） 成为稳定功能之前（该特性自 v2.40 起实验性引入），未来内容将更新以涵盖新特性。
一、核心概念
Histogram 和 Summary 都用于采样观测值（如请求延迟、响应大小）。
两者均自动暴露：
_count：观测次数（本质是 Counter）
_sum：观测值总和（通常也是 Counter，除非观测值可为负）
可通过以下表达式计算平均值（过去 5 分钟）：
1rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])
二、Histogram vs Summary：关键区别
...
Prometheus最佳实践(七)——远程写入
Prometheus 远程写入（Remote Write）调优指南（中文总结）本文档来自 Prometheus 官方文档 - Remote write tuning，旨在帮助用户根据实际需求优化远程写入（Remote Write）的性能与资源使用。Prometheus 默认配置适用于大多数场景，但在高负载、慢速后端或资源受限环境下，需进行针对性调优。
一、远程写入工作原理
每个远程写入目标会启动一个队列系统，从 WAL（Write-Ahead Log） 读取样本。
数据流：WAL → 多个分片（shard）的内存队列 → 并行发送到远程端点
关键特性：
若某分片队列满，整个 WAL 读取将被阻塞，影响所有分片。
失败请求会自动重试，数据最多保留 2 小时；超过则随 WAL 压缩而丢失。
Prometheus 会
动态调整分片数量
（
1shards
），基于：
样本摄入速率
待发送样本积压量
单次发送耗时
二、资源影响
资源
影响说明
内存
⬆️ 显著增加（通常 +25%） • 系列 ID 到标签的缓存（高 churn 会剧增内存） • 每个分片队 ...