2025-2-24 0224面试

比较好的监控是怎样的 prometheus grafana alertmanager 考虑存储大规模 2000台机器考虑告警延迟考虑长期储存考虑监控业务的全面性准确性告警实时性 #

在你的场景中，涉及到大规模的监控部署，2000台机器、长时间的存储、实时告警等多个方面。要构建一个高效、可靠的监控系统，你可以基于 Prometheus、Grafana 和 Alertmanager 这些工具进行设计，但需要优化配置，以满足大规模、低延迟、高可用、长时间存储等需求。

1. Prometheus 架构设计 #

水平扩展：单个 Prometheus 实例无法支撑大规模的数据采集和存储，因此需要考虑水平扩展。可以使用多个 Prometheus 实例分担不同的监控目标（例如，按区域或按机器类型分配 Prometheus 实例）。也可以使用 Prometheus Federation（联邦）来将多个 Prometheus 实例的指标数据汇聚到一个主 Prometheus 实例中。
存储优化：Prometheus 本身的存储是针对短期数据存储优化的，支持时序数据的压缩。但对于长期存储，Prometheus 并不适合将数据保留很长时间。可以使用 Thanos 或 Cortex 来为 Prometheus 提供分布式存储，支持长期数据保留。这样可以跨多个 Prometheus 实例集中存储数据，进行长时间查询。
数据分片：如果你的监控数据量非常大（如 2000 台机器），你可以通过数据分片（sharding）来分散负载，减少单个 Prometheus 实例的压力。Thanos 和 Cortex 都支持这种分片模型。

2. Grafana 可视化 #

仪表盘设计：Grafana 适用于展示大规模监控数据。你可以设计多个针对不同层级的仪表盘，例如：硬件监控、应用性能监控、网络流量等。Grafana 允许将数据按需聚合或细分，以帮助从不同维度监控业务指标。
分布式查询：通过 Thanos 或 Cortex 等分布式存储系统，Grafana 可以访问跨多个 Prometheus 实例的数据，呈现完整的监控视图。
查询性能优化：随着监控系统规模的扩大，Grafana 查询的数据量增大。你需要优化 Prometheus 的查询性能，避免低效的查询（如不加时间范围的查询），或者使用预计算的聚合数据来减轻查询负担。

3. Alertmanager 告警管理 #

告警延迟：为了确保告警的实时性，Prometheus 的抓取周期（默认 15 秒）需要优化。如果告警的延迟非常关键，可能需要缩短抓取周期或者增加更多 Prometheus 实例，分担告警流量。
告警策略设计：针对大规模的监控系统，告警的去重和抑制非常重要，避免过多无效告警。可以根据告警的严重性、关联性进行聚合，避免“告警风暴”。Alertmanager 可以进行告警的抑制和分组，减少重复告警。
通知渠道：Alertmanager 可以与 Slack、邮件、Webhook 等通知渠道集成，根据告警级别不同，选择不同的通知方式（例如，严重告警通过短信，轻微告警通过邮件）。
告警灵敏度：在大规模系统中，容易产生很多低优先级的告警。可以通过设置 Prometheus 的告警规则，精细化告警条件，确保告警的准确性和有效性。

4. 存储与长期数据保留 #

长期存储解决方案
：Prometheus 默认的数据存储只适合短期使用。对于长期存储，可以引入
Thanos
或
Cortex
，这些工具可以将数据长期存储，并且提供跨 Prometheus 实例的查询功能。
- Thanos：Thanos 提供了一种基于对象存储的分布式存储解决方案，可以将数据从本地存储推送到云端或分布式对象存储（如 AWS S3），并且支持数据的压缩与索引。
- Cortex：Cortex 是另一个用于分布式时序数据存储的开源项目，它提供水平扩展、长期存储等特性，适合大规模监控部署。
Cold Storage：对于不经常访问的数据，可以将较老的时序数据存储到 Cold Storage 中，减少对存储性能的影响。

5. 业务全面性和准确性 #

指标覆盖全面：确保监控覆盖所有业务的关键指标，除了常规的硬件、网络、应用性能指标外，还要考虑业务指标（如用户行为、支付订单量等）。可以使用 Prometheus Exporter 来收集更多应用特定的指标。
PromQL 查询优化：为了确保监控数据的准确性和高效性，使用 PromQL 时需要优化查询，避免过度聚合和计算。例如，可以使用汇总（rate、avg）等函数在 Prometheus 采集数据时进行计算，减少数据量，提高查询效率。

6. 监控系统的高可用性 #

Prometheus 高可用性：可以通过 Prometheus HA 部署多个 Prometheus 实例来保证高可用性。例如，主 Prometheus 实例失效时，副本可以接管工作。
Alertmanager 高可用性：Alertmanager 也需要做高可用部署，可以通过 Alertmanager 集群 来实现。
冗余存储：通过 Thanos 或 Cortex 等解决方案提供冗余存储，以确保数据不丢失。

总结 #

对于大规模监控系统（如 2000 台机器），你需要：

分布式 Prometheus 架构：使用多个 Prometheus 实例，并结合 Thanos 或 Cortex 等分布式存储解决方案进行长期数据存储。
高效的告警策略：优化告警规则，使用告警去重和抑制，确保告警的实时性和准确性。
灵活的可视化设计：使用 Grafana 来设计分层、灵活的仪表盘，确保监控的全面性。
优化存储和查询：通过压缩、分片、冷存储等手段降低存储成本并提高查询性能。

通过这些优化，你可以确保监控系统不仅能够处理大规模的环境，还能保证告警和数据查询的实时性和准确性。你有具体的部署需求或技术栈细节吗？

数据库的高可用的设计 #

数据库的高可用性设计是确保数据库服务在出现故障时，能够自动恢复并保持最小的停机时间，以确保系统的连续性和可靠性。为了实现高可用性，通常会涉及到数据复制、故障转移、负载均衡、备份策略等多个方面。

下面是几种常见的数据库高可用设计方案：

1. 主从复制 (Master-Slave Replication) #

主从复制是数据库高可用性的经典设计，主数据库处理写操作，从数据库负责读取操作。这种设计可以通过从数据库来分担读取负载，同时在主数据库故障时，能够将从数据库提升为新的主数据库。

特点： #

主数据库：负责处理所有写操作。
从数据库：通过同步复制，接收主数据库的变更，处理读取操作。
故障转移：如果主数据库不可用，从数据库可以通过自动或手动的方式提升为主数据库。

缺点： #

主从复制通常是异步的，这意味着如果主数据库发生故障，从数据库可能会丢失一些未同步的数据。

实现： #

MySQL 和 PostgreSQL 都支持主从复制。
MySQL Group Replication 或 PostgreSQL Streaming Replication 可提供更强的复制和故障转移能力。

2. 双主复制 (Master-Master Replication) #

双主复制通过让两个数据库实例互相作为主数据库来实现高可用性。这种方案允许数据库之间相互复制，且两个数据库都可以进行写操作。

特点： #

双主复制使得两个数据库实例可以同时进行读写操作。
当一个数据库实例发生故障时，另一个实例仍然可以提供服务。
比主从复制的负载分担能力更强。

缺点： #

数据冲突：如果两个主数据库同时进行写操作，可能会发生数据冲突。需要通过解决冲突的机制（如版本控制或冲突解决策略）来避免这种情况。
相较于主从复制，双主复制的实现更复杂，特别是在数据库的写冲突管理上。

实现： #

MySQL 的 Group Replication 或 Galera Cluster。
PostgreSQL 使用 Bucardo 或 PgPool-II。

3. 数据库集群 (Database Clustering) #

数据库集群将多个数据库节点组成一个集群，通常集群中的每个节点都有相同的数据副本，并通过一致性协议来保证数据的一致性。集群模式通常能提供更高的可用性和更强的数据冗余能力。

特点： #

集群中的每个节点都存储数据副本，并具有读写能力。
提供自动故障转移和负载均衡。
数据一致性通常使用分布式协议（如 Paxos 或 Raft）来确保。

实现： #

MySQL Cluster：基于 NDB (Network Database) 存储引擎，支持高可用性、自动分区和自动故障转移。
PostgreSQL：通过 Citus 扩展实现分布式数据库集群。
Cassandra 和 MongoDB：本身是分布式数据库，原生支持高可用性和分布式存储。

4. 故障转移与负载均衡 (Failover and Load Balancing) #

故障转移是指在主数据库节点发生故障时，自动切换到一个备份数据库（从数据库或复制节点），保持服务可用。而负载均衡则用于在多个数据库节点之间分配读写请求。

实现： #

故障转移管理工具：例如 MHA (Master High Availability) 或 Orchestrator，可以用于自动监控数据库实例，发生故障时自动将流量切换到健康的节点。
负载均衡器：可以使用负载均衡器（如 HAProxy、ProxySQL 或 PgBouncer）来将请求分配到多个数据库实例，从而实现负载均衡。

5. 同步与异步复制 #

同步复制：所有数据库节点都保持一致性，所有写操作必须在所有节点上成功才能完成。这种方法提供更强的一致性，但会影响性能，特别是在远程节点时延较大的情况下。
异步复制：主数据库先提交写操作，数据随后异步同步到从节点。这种方法更注重性能，能够提高系统吞吐量，但在主数据库故障时可能会丢失一些未同步的数据。

实现： #

MySQL 支持同步复制（通过 GTID 或 Semi-Synchronous Replication）。
PostgreSQL 支持流式复制，可以通过配置不同的同步复制策略来实现。

6. 备份与恢复 (Backup and Restore) #

定期备份数据库是确保数据安全和可恢复性的基础。数据库的高可用性不仅仅依赖于实时的故障转移，还需要有健全的备份策略。

特点： #

定期备份数据。
增量备份：只备份发生变化的数据，减少备份时间和存储空间。
异地备份：将备份存储到不同地理位置，以防止由于自然灾害等因素导致的数据丢失。

实现： #

使用数据库的内建工具，如 mysqldump、pg_dump、Percona XtraBackup 等，结合脚本定期备份。
数据备份需要确保备份文件的存储与恢复高效性，尽量避免因备份过程导致的性能瓶颈。

7. 云原生数据库高可用设计 #

如果部署在云环境中（如 AWS、Azure 或 Google Cloud），云平台通常提供数据库的高可用性功能，如自动备份、自动故障转移、多区域部署等。

特点： #

自动故障转移：云平台可提供跨可用区的自动故障转移。
分布式存储：数据可以分布在多个区域，提高容灾能力。
弹性扩展：根据负载需求自动扩展计算和存储资源。

实现： #

Amazon RDS 和 Aurora：提供数据库自动备份、故障转移和多区域部署功能。
Google Cloud SQL 和 Azure Database：提供高可用性和自动扩展功能。

总结：高可用数据库设计的考虑要点 #

冗余和数据复制：通过主从、双主或集群复制来保证数据的冗余。
故障转移与恢复：自动化故障转移机制，最小化系统的停机时间。
负载均衡：通过负载均衡器分担读写请求，提高吞吐量。
备份策略：定期备份数据库，并确保可以在灾难发生时快速恢复。
监控和告警：实时监控数据库健康状态，设置合理的告警策略，确保在出现故障时能够及时响应。

你是否有特定的数据库类型或架构部署需求，或者是否涉及到云平台或自建环境的高可用设计？这样可以更有针对性地给出建议。

业务监控怎么做的？ #

业务监控是确保业务系统（无论是网站、应用还是其他类型的服务）健康、稳定、可靠的关键环节。它不仅关注系统层面的性能指标（如 CPU、内存、网络带宽等），还关注业务本身的指标，如用户行为、订单量、收入、转化率等。有效的业务监控帮助团队及时发现问题、分析瓶颈、优化流程，并做出更好的决策。

业务监控设计的关键步骤： #

定义关键业务指标 (KPI)
选择合适的监控工具
设置告警与响应机制
实时监控与数据分析
监控系统的维护与优化

1. 定义关键业务指标 (KPI) #

首先，确定需要监控的业务指标是关键步骤。不同的业务场景，监控的指标也会有所不同。以下是一些常见的业务监控指标：

常见业务监控指标： #

用户相关指标
：
- 活跃用户数 (DAU/MAU)：日活跃用户数和月活跃用户数，反映用户参与度。
- 用户留存率：例如第1天、第7天、第30天的留存率，衡量用户粘性。
- 用户转化率：如从注册到购买的转化率，帮助分析用户行为路径。
业务行为指标
：
- 订单量、销售额：直接衡量业务收入。
- 用户行为路径：用户从浏览、加入购物车到最终购买的转化路径。
- 支付成功率：反映支付环节的顺畅度。
系统健康指标
：
- 响应时间：业务接口或页面的响应时间，过长可能影响用户体验。
- 错误率：如HTTP 5xx 错误，API 错误，监控是否存在服务故障。
- 系统负载：监控服务器、数据库的负载情况，防止过载。

业务指标示例： #

电商平台：订单量、购物车放弃率、支付成功率、转化率、退款率。
SaaS 平台：用户注册数、付费用户数、功能使用频率、续费率。
社交平台：用户活跃度、评论数、分享数。

2. 选择合适的监控工具 #

为了有效地监控业务，你可以选择合适的监控工具。根据需求，监控工具可以分为 系统层级监控 和 业务层级监控。

系统层级监控工具： #

Prometheus + Grafana：用于监控系统性能指标（如 CPU 使用率、内存、硬盘、网络流量等）并将其可视化，提供详细的图表和报警功能。
Datadog：综合性能监控工具，支持云、容器、应用程序等的全栈监控，适合大规模微服务环境。
Zabbix、Nagios：传统的监控工具，用于监控主机、网络设备、应用程序等。

业务层级监控工具： #

Google Analytics、Mixpanel、Amplitude：这些工具可以帮助你收集用户行为数据，分析用户的使用模式、转化率、留存等业务数据。
Prometheus + 自定义 Metrics Exporter：通过将业务指标暴露为 Prometheus 监控的形式，可以对业务指标进行自定义监控和告警设置。
Elasticsearch + Kibana (ELK Stack)：用于日志分析，可以挖掘出用户行为数据、业务异常等信息。
Grafana + InfluxDB：适合高频率的时序数据监控，常用于监控业务系统的实时数据。

3. 设置告警与响应机制 #

业务监控的核心之一是告警系统，确保你能够及时发现问题并采取行动。告警设计不仅仅要监控系统崩溃或性能瓶颈，还要能够对业务异常做出反应。

告警策略： #

阈值告警：当某个指标超过或低于预定的阈值时触发告警。例如，订单量异常波动、支付成功率过低、错误率过高等。
趋势告警：监控指标的增长趋势或衰退趋势，例如用户活跃度下降、订单数量连续数小时下降等。
异常检测：一些先进的监控系统（如 Datadog、Prometheus）可以根据历史数据和模式分析，自动发现异常变化，自动触发告警。

告警渠道： #

Slack、微信、钉钉：将告警信息推送到团队沟通工具，确保团队可以及时响应。
邮件、短信、电话：对于严重故障，可能需要通过电话、短信等方式告知相关人员。
自动化响应：通过集成自动化工具（如 Runbook），在发生常见问题时可以自动触发修复流程。

4. 实时监控与数据分析 #

实时监控是确保业务持续健康运营的核心。除了实时监控的核心业务指标外，还需要综合分析，识别潜在的问题。

关键实时数据： #

数据仪表盘：在 Grafana、Datadog 或 Kibana 上创建实时仪表盘，展示核心业务指标（如活跃用户、转化率、订单量等）。
追踪用户行为：集成用户行为分析工具，如 Google Analytics、Mixpanel，监控用户在系统中的路径和关键行为，识别潜在的用户流失或问题区域。

数据分析： #

回归分析：基于历史数据分析出业务的季节性变化、周期性波动，预测未来的趋势和需求。
A/B 测试：在业务上做出更改时（例如修改用户界面、调整流程等），可以使用 A/B 测试来验证新变化是否提高了业务指标。

5. 监控系统的维护与优化 #

随着业务的发展和系统的变化，业务监控也需要不断地维护和优化。定期评估和调整监控策略是非常重要的。

维护工作： #

定期回顾监控指标：确保业务监控覆盖了所有重要的业务指标，及时更新和优化监控内容。
优化告警设置：告警的频率和内容需要根据实际情况进行调整，避免“告警疲劳”，同时确保高优先级告警不会被遗漏。
性能优化：优化监控系统的性能，避免监控本身对生产环境造成额外的压力。

高效的报警管理： #

告警去重和合并：避免相同问题引发多个告警。使用合并、去重等策略，将相似的告警合并为一个事件进行处理。

总结 #

业务监控的核心目标是确保业务运行的健康和可持续性。有效的业务监控不仅帮助你确保系统正常运作，还能帮助你识别潜在的业务瓶颈、改进用户体验、优化业务流程。设计业务监控时，要：

确定并定义关键业务指标（KPI）。
使用合适的工具收集和分析业务数据。
配置实时监控和告警系统，确保能够快速响应。
定期优化监控和告警策略，确保监控系统高效稳定。

如果你有特定的业务场景或者需要更详细的实现建议，我可以提供更具体的指导！

业务pod告警规则设计和例子 #

在 Kubernetes 环境中，使用 Prometheus 和 Alertmanager 结合 Pod 监控和告警是非常常见的做法。以下是一些设计业务 Pod 的告警规则的常见场景，以及具体的告警规则示例。

1. 监控指标 #

首先，确保你已经在 Kubernetes 中通过 Prometheus Operator 或者 Kube-Prometheus 等工具集成了 Prometheus 监控，并能够收集到以下指标：

Pod CPU 使用率：container_cpu_usage_seconds_total
Pod 内存使用率：container_memory_usage_bytes
Pod 网络流量：container_network_receive_bytes_total、container_network_transmit_bytes_total
Pod 磁盘 I/O：container_fs_usage_bytes
Pod 重启次数：kube_pod_container_status_restarts_total
Pod 状态：kube_pod_status_phase（如 Pending、Running、Succeeded、Failed 等）
Pod 健康检查：kube_pod_container_status_ready

2. 常见告警规则设计 #

业务 Pod 的告警规则需要涵盖以下几个方面：

a. 资源使用告警（CPU、内存等） #

这些告警规则主要是帮助你及时发现资源瓶颈或者不正常的资源消耗。过高的 CPU 或内存使用率可能会导致 Pod 变慢或者重启。

CPU 使用率告警：

- alert: PodHighCPUUsage
  expr: rate(container_cpu_usage_seconds_total{container!="",pod=~".*"}[5m]) > 0.9
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} is using too much CPU ({{ $value }} cores)"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is consuming too much CPU."

说明： 这个规则表示如果 Pod 的 CPU 使用率超过 90%（1 核 CPU），并且持续时间达到 1 分钟，则触发告警。

内存使用率告警：

- alert: PodHighMemoryUsage
  expr: container_memory_usage_bytes{container!="",pod=~".*"} / container_spec_memory_limit_bytes{container!="",pod=~".*"} > 0.9
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} is using too much memory ({{ $value }} bytes)"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is consuming too much memory."

说明： 如果 Pod 的内存使用超过 90%（container_spec_memory_limit_bytes），并且持续时间超过 1 分钟，则触发告警。

b. Pod 重启次数告警 #

Pod 重启次数过多通常表示应用程序存在不稳定性。你可以使用此告警规则检测 Pod 重启情况。

- alert: PodRestartingTooManyTimes
  expr: kube_pod_container_status_restarts_total{container!="",pod=~".*"} > 5
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} has restarted more than 5 times in the last 5 minutes"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has restarted {{ $value }} times in the last 5 minutes."

说明： 如果某个 Pod 在 5 分钟内重启次数超过 5 次，则触发告警。

c. Pod 健康检查失败告警 #

如果 Pod 无法通过健康检查，通常是应用程序出现问题。这类告警可以帮助你及时发现应用不健康的状态。

- alert: PodUnhealthy
  expr: kube_pod_container_status_ready{container!="",pod=~".*"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} is not ready"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has failed the readiness check for more than 2 minutes."

说明： 如果 Pod 在 2 分钟内无法通过准备就绪检查（container_status_ready == 0），则触发告警。

d. Pod 启动延迟告警 #

如果 Pod 启动时间过长，可能是应用或环境存在问题。通过监控 Pod 的启动时间，可以提前发现潜在问题。

- alert: PodStartupDelay
  expr: time() - kube_pod_start_time{pod=~".*"} > 600
  labels:
    severity: high
  annotations:
    summary: "Pod {{ $labels.pod }} is taking too long to start"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has not started within 10 minutes."

说明： 如果 Pod 启动时间超过 10 分钟，则触发告警。

e. Pod 状态异常告警 #

Pod 的状态异常（如进入 CrashLoopBackOff、Pending 等）也需要进行监控。这些告警有助于检测 Pods 是否发生了故障或无法调度。

- alert: PodStatusFailed
  expr: kube_pod_status_phase{phase="Failed",pod=~".*"} > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Pod {{ $labels.pod }} has failed"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has been in the Failed state for more than 5 minutes."

说明： 如果 Pod 处于 Failed 状态超过 5 分钟，则触发告警。

f. 网络流量告警 #

监控 Pod 的网络流量（入站和出站流量）可以帮助你识别潜在的网络瓶颈或滥用。

- alert: PodHighNetworkUsage
  expr: (rate(container_network_receive_bytes_total{pod=~".*"}[5m]) + rate(container_network_transmit_bytes_total{pod=~".*"}[5m])) > 100000000
  for: 5m
  labels:
    severity: medium
  annotations:
    summary: "Pod {{ $labels.pod }} is using too much network bandwidth"
    description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is using more than 100 MB of network bandwidth in the last 5 minutes."

说明： 如果某个 Pod 在过去 5 分钟内的网络流量超过 100 MB，则触发告警。

3. 告警规则设置中的注意事项 #

for 参数：防止瞬时的波动导致频繁触发告警。通常会设置一定的时间阈值，只有当条件持续一段时间时才会触发告警。
severity 标签：根据不同的告警严重性（如 critical、warning、info 等）来分配优先级，有助于团队更好地响应告警。
告警延迟和去重：避免同一问题频繁发送告警，通过告警去重、合并等机制减少告警噪音。

4. 告警通知与响应 #

Alertmanager：可以将这些告警集成到 Alertmanager 中，并根据告警的严重性将告警通过 Slack、邮件、钉钉等渠道通知给相关团队。
自动化响应：例如，可以设置自动化的脚本，触发某些操作来解决常见问题（如重新启动 Pod，或者重新调度 Pod 到健康节点）。

总结 #

业务 Pod 的告警规则设计需要根据业务需求来定制，关注应用的稳定性、性能瓶颈以及潜在的故障。通过合理的告警规则，可以确保及时发现问题并采取必要的修复措施，提高业务系统的可用性和稳定性。

还有吗？比如黑盒探针检测借口探活 #

当然，除了直接监控资源使用、Pod 重启等指标，**黑盒探针（Black-box Probing）和接口健康检查（Endpoint Health Checks）**也是业务监控和告警中非常重要的一部分，尤其是在微服务架构中，确保每个服务或组件是否健康、正常运行。

1. 黑盒探针（Black-box Probing） #

黑盒探针是从外部检测应用服务的健康状况，而不需要访问服务内部的状态。常见的黑盒探针通常是通过 HTTP 请求、TCP 连接或者其他协议来模拟用户请求，确认服务是否能够正常响应。这种方式特别适用于无法直接访问内部状态的场景。

a. HTTP 探针（HTTP Probe） #

通常应用程序会暴露一个 HTTP 健康检查接口（例如 /health 或 /status），黑盒探针可以通过定期访问该接口来检测服务的健康状况。

健康检查规则示例：

- alert: HTTPHealthCheckFailed
  expr: http_requests_total{job="your-service", status="5xx"} > 10
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Your service has returned 5xx errors more than 10 times in the last 5 minutes"
    description: "The health check endpoint for your service has failed and returned 5xx errors."

说明： 如果健康检查的 HTTP 请求在 5 分钟内返回了超过 10 次的 5xx 错误，说明服务出现了问题，触发告警。

b. TCP 探针 #

如果你的应用服务不提供 HTTP 接口，你可以通过 TCP 探针进行监控，验证服务端口是否可用。这通常适用于数据库、消息队列等服务。

TCP 探针示例：

- alert: TCPConnectionFailed
  expr: increase(tcp_connections_failed_total{job="your-service", port="your-port"}[5m]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "TCP connection to your service failed"
    description: "There have been failed TCP connections to your service on port {{ $labels.port }} in the last 5 minutes."

说明： 如果在 5 分钟内某个服务的 TCP 连接失败次数大于 0 次，触发告警。

c. DNS 查询探针 #

你还可以通过 DNS 查询来检测域名解析的健康状况，尤其在使用云服务或容器化服务时，可能需要确保 DNS 服务能够正确解析。

DNS 探针示例：

- alert: DNSResolutionFailed
  expr: increase(dns_lookup_failure_total{job="your-dns-probe"}[5m]) > 0
  for: 5m
  labels:
    severity: high
  annotations:
    summary: "DNS resolution failure detected"
    description: "DNS resolution failure detected for domain {{ $labels.domain }}."

说明： 如果某个 DNS 查询在过去 5 分钟内失败，触发告警。

2. 接口健康检查（Endpoint Health Check） #

接口健康检查是在应用服务中定义的专门的健康检查端点，这些端点暴露了服务自身的一些基本健康状态和资源依赖状态。例如，数据库连接、缓存系统、外部 API 的连接状态等。通过定期访问这些健康检查端点，可以确保业务的各项依赖是否正常。

a. Web 服务健康检查端点 #

应用程序通常会暴露一个 HTTP 服务健康检查端点（如 /healthz），用于返回服务是否健康。这些端点通常会检查数据库连接、队列服务、外部依赖等。

接口健康检查告警规则：

- alert: WebServiceHealthCheckFailed
  expr: kube_pod_container_status_restarts_total{container="your-container", pod=~"your-service-pod.*", container="your-container"} > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Health check failed for web service"
    description: "The web service has failed the health check for more than 5 minutes."

说明： 如果 Web 服务的健康检查端点无法访问，且服务重启次数增加，触发告警。

b. 外部 API 接口健康检查 #

如果你的业务依赖外部的 API 服务，监控这些外部 API 的可用性也是非常重要的。你可以为外部 API 设置接口探活，并监控它们的响应时间和返回码。

外部 API 健康检查规则：

- alert: ExternalAPIHealthCheckFailed
  expr: http_requests_total{job="external-api", status="5xx"} > 5
  for: 5m
  labels:
    severity: high
  annotations:
    summary: "External API returned 5xx error"
    description: "The external API is returning 5xx errors, which may affect your service."

说明： 如果外部 API 接口在 5 分钟内返回超过 5 次的 5xx 错误，说明外部 API 服务异常，触发告警。

c. 数据库连接健康检查 #

如果应用依赖数据库，数据库的健康检查也非常重要。通过检查数据库的连接池状态、查询响应时间等，可以确保数据库服务正常。

数据库连接健康检查规则：

- alert: DatabaseConnectionFailed
  expr: rate(database_connection_failures_total{database="your-database"}[5m]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Database connection failed"
    description: "There have been failed connections to your database in the last 5 minutes."

说明： 如果数据库连接失败的次数超过了设定的阈值（这里是 5 次），并且持续超过 5 分钟，则触发告警。

3. 健康检查和探针常见的设计考虑 #

探针的频率和延迟：不要过于频繁地发送健康检查请求，这样可能会导致额外的负担，尤其在负载较大的生产环境中。通常每 30 秒到 1 分钟进行一次探测。
探针的可靠性：确保健康检查端点返回的状态能够真实反映服务健康。如果你的健康检查端点依赖其他资源（如数据库），则健康检查的定义需要特别小心，避免因外部依赖故障而错误地判定服务不健康。
状态码的配置：健康检查通常会返回 HTTP 状态码（如 200 表示正常，500 表示异常）。可以根据不同的错误码设置不同级别的告警。

4. 综合应用健康检查与告警 #

通常情况下，可以将多种健康检查结合起来，形成多层次的监控：

黑盒探针：检测服务本身是否可访问。
接口健康检查：检查服务内部依赖的各个组件（如数据库、缓存等）是否健康。
应用日志监控：通过分析日志进一步验证服务的业务健康性。

总结： #

黑盒探针和接口健康检查是微服务架构中非常重要的监控手段，能够帮助你检测服务是否能正常对外提供功能，及时发现服务中断、依赖故障等问题。通过合理设计健康检查端点和探针规则，并结合告警系统，可以及时响应系统故障、提高业务系统的可靠性和可用性。

外部的流量进入到k8s集群内部的过程 #

外部流量进入 Kubernetes 集群的过程涉及多个组件和配置，主要依赖于 Kubernetes 的Ingress、Service、Ingress Controller 等功能。这些组件共同工作，将外部流量引导到集群内部的合适服务。以下是一个完整的外部流量进入 Kubernetes 集群的流程：

1. 外部流量的入口： #

外部流量通常是从外部世界（例如用户的浏览器、客户端应用等）通过互联网发送的 HTTP/HTTPS 请求。这些流量需要通过特定的入口进入 Kubernetes 集群。

a. 外部访问的入口点 #

在 Kubernetes 中，外部流量通常会通过以下几种方式进入集群：

LoadBalancer：在云环境中使用负载均衡器（例如 AWS ELB、Azure Load Balancer、GCP Load Balancer）暴露服务。
Ingress Controller：通过 Ingress 控制器将流量路由到内部服务。
NodePort：通过 Kubernetes 集群节点的 IP 和端口暴露服务，通常用于调试或小规模应用。
ClusterIP：通过内网服务，通常与其他集群内部组件通信，较少用于外部访问。

2. 通过 LoadBalancer（云环境） #

在云环境中，通常使用 LoadBalancer 类型的 Service 将外部流量引导到集群内部的服务。

流程： #

用户请求：外部流量（如 HTTP 请求）通过 DNS 或 IP 地址访问集群。
云负载均衡器：请求首先到达云负载均衡器（如 AWS ELB）。此负载均衡器将流量转发到 Kubernetes 集群中的节点。
Kubernetes NodePort：负载均衡器会将流量转发到 Kubernetes 集群的每个节点上的某个端口（NodePort）。NodePort 是 Kubernetes 服务的一部分，它为每个节点开放一个固定端口，将流量转发到相应的 Pod。
Pod 选择与转发：NodePort 服务将流量路由到相应的 Pod 上，最终到达应用。

3. 通过 Ingress（HTTP/HTTPS 路由） #

Ingress 是 Kubernetes 中一种高效的流量路由机制，能够将外部 HTTP/HTTPS 请求根据规则路由到集群内部的服务。Ingress 控制器处理所有的流量路由和规则。

流程： #

用户请求：外部用户通过浏览器或客户端发送 HTTP 或 HTTPS 请求到集群外部的 Ingress Controller（通常通过域名，如 www.example.com）。
Ingress Controller
：Ingress Controller 是一个负责接受外部 HTTP/HTTPS 请求并根据 Ingress 资源定义的规则进行路由的组件。Ingress Controller 通常由 NGINX、Traefik 等开源工具实现。
- 例如，NGINX Ingress Controller 作为反向代理，接收外部请求。
路由规则匹配
：Ingress Controller 根据配置的 Ingress 规则来决定将流量转发到哪个服务。这些规则可以基于路径、主机名等进行路由，例如：
- 请求 /api/* 可能被路由到 api-service 服务。
- 请求 /web/* 可能被路由到 web-service 服务。
服务转发：Ingress Controller 将流量转发到 Kubernetes 内部的相应服务（Service）。这些服务会将请求进一步转发到后端的 Pod。

4. Ingress 资源配置 #

Ingress 是 Kubernetes 中的一个 API 资源，它定义了如何路由外部 HTTP(S) 流量到集群内的服务。Ingress 资源通常需要结合 Ingress Controller 使用。

Ingress 资源配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

说明：

host: myapp.example.com 表示该规则适用于域名 myapp.example.com。
请求路径为 /api 会被转发到 api-service 服务的 80 端口。
请求路径为 /web 会被转发到 web-service 服务的 80 端口。

5. Ingress Controller 配置与实现 #

Ingress Controller 是实现 Ingress 资源规则的实际组件，它负责接收流量并根据 Ingress 资源的定义进行路由。常见的 Ingress Controller 有：

NGINX Ingress Controller：一个常用的、功能强大的 Ingress Controller。
Traefik：一个动态反向代理，支持自动发现服务并创建路由规则。
HAProxy：另一种流行的反向代理和负载均衡器。

Ingress Controller 一般通过一个 LoadBalancer 或 NodePort 类型的 Service 将外部流量引入 Kubernetes 集群内部。

例如，使用 NGINX Ingress Controller： #

安装 NGINX Ingress Controller：通常使用 Helm 来安装。
配置 Ingress 资源：为每个需要暴露的服务配置 Ingress 资源，并为它们配置路由规则。
外部流量进入：外部请求通过配置好的域名进入 LoadBalancer 或 NodePort，最终通过 Ingress Controller 路由到内部服务。

6. NodePort #

在一些非生产环境或小规模集群中，NodePort 也是一个常见的将外部流量引导到集群内部的方式。

流程： #

用户请求：外部请求会通过集群节点的公共 IP 和 NodePort（例如 30000 端口）访问。
集群节点接收流量：每个 Kubernetes 节点都会在指定的 NodePort 上开放端口，接收到流量后，它会将流量转发到集群内部的 Service。
服务转发到 Pod：服务通过 Kubernetes 的 Service 机制，将流量路由到相应的 Pod。

NodePort 示例： #

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30000

说明：

NodePort 类型的 Service 会在所有节点的 30000 端口上监听流量，并将流量转发到目标端口（这里是 8080）。

7. 总结： #

外部流量进入 Kubernetes 集群的过程通常涉及以下步骤：

流量入口：外部流量通过负载均衡器、Ingress 或 NodePort 进入 Kubernetes 集群。
Ingress Controller：Ingress Controller 接收 HTTP/HTTPS 请求，并根据定义的路由规则（在 Ingress 资源中配置）将流量转发到合适的 Service。
Service 路由到 Pod：Kubernetes Service 负责根据选择器将流量分发到后端的 Pod。

这种多层的架构提供了强大的路由能力，灵活的负载均衡和自动化的流量管理，使得 Kubernetes 在处理大规模、分布式系统的流量时非常高效。

反问面试官问啥 #

在面试中，反问面试官不仅能帮助你更好地了解公司和职位，也能展示出你对该职位的兴趣和职业规划的思考。以下是一些适合在面试时反问面试官的问题，可以根据面试的具体内容进行选择：

1. 关于公司文化和团队氛围 #

“贵公司最看重团队合作的哪一方面？你能描述一下团队的工作氛围吗？” 这个问题能帮助你了解公司文化、团队合作的方式以及公司是否注重个人成长和支持团队协作。
“公司有哪些方式支持员工的成长和职业发展？” 这问题能帮助你了解公司是否提供培训、晋升机会、以及支持员工技能提升的资源。

2. 关于职位本身和日常工作 #

“这个职位的日常工作内容和挑战主要有哪些？” 通过这个问题，你可以了解具体工作职责是否符合你的预期。
“这个岗位对一个新人来说，最大的挑战通常是什么？” 这样的问题可以让你了解入职初期的挑战，帮助你做出更好的准备。
“对于这个岗位，团队的优先目标是什么？在接下来的几个月内，团队最关注的事情会是什么？” 你可以了解团队当前的目标和未来计划，从而判断你是否能在这个团队中发挥重要作用。

3. 关于项目和技术 #

“目前团队正在进行的最大项目是什么？我在这个岗位上的工作会如何参与其中？” 这个问题能够帮助你理解你未来会参与哪些项目，团队的工作重点是什么。
“团队目前使用的技术栈是怎样的？未来是否有技术更新或升级的计划？” 了解技术栈能帮助你评估是否符合你的技术背景，以及团队的技术发展方向。
“这个岗位在跨部门协作中扮演什么角色？是否会和其他团队密切合作？” 如果这个岗位涉及到跨团队合作，了解这些细节能帮助你更好地适应工作环境。

4. 关于公司前景和行业 #

“公司在未来几年的战略目标是什么？如何看待行业的变化与发展？” 这个问题能帮助你了解公司对未来的规划，是否具备良好的发展前景，及公司如何应对行业变化。
“你如何看待公司在未来几年内的增长潜力和挑战？” 这个问题能帮助你判断公司是否在行业中有竞争力，以及未来可能面临的挑战。

5. 关于领导和管理风格 #

“您能描述一下您的管理风格吗？” 通过了解面试官的管理风格，你可以判断你是否适应他们的工作方式和沟通模式。
“在您的团队中，成功的员工通常具备哪些特质？” 这个问题可以帮助你了解团队对员工的期望，以及哪些行为和表现会被视为成功。

6. 关于工作与生活的平衡 #

“公司如何支持员工保持良好的工作与生活平衡？” 如果你重视工作与生活的平衡，这个问题能够帮助你了解公司的工作强度和弹性。
“公司对远程工作或灵活办公的政策是什么？” 这个问题特别适合现在工作环境发生变化的公司，尤其在疫情后，很多公司开始提供更灵活的工作安排。

7. 关于绩效评估与反馈 #

“公司如何进行员工绩效评估？有没有定期的反馈机制？” 这个问题可以让你了解公司是否有明确的绩效评估标准，以及你如何获得反馈和成长。
“在过去的员工中，成功晋升的典型案例是怎样的？” 这个问题可以帮助你了解公司晋升机制和员工的职业发展轨迹。

8. 关于公司的一些具体问题 #

“公司最近有没有在技术或业务上做出过重要的变动或调整？” 通过这个问题，你可以了解公司最近的变化或新的战略，帮助你评估公司是否在进行转型或升级。
“公司如何处理技术债务或解决技术挑战？是否有相关的改进计划？” 如果你对技术深度比较感兴趣，这个问题能帮助你了解公司如何应对技术上的难题，是否有计划去优化现有的系统。

9. 关于后续流程 #

“接下来的面试流程是什么样的？” 通过了解后续的面试流程，你可以做好准备，了解是否还需要技术测试、团队面试等。
“您认为我在这次面试中有哪些方面表现得特别好或需要改进的地方？” 这个问题可以帮助你得到即时反馈，同时也能显示出你对自我改进的积极态度。

小贴士： #

根据面试进展提问：有时面试官会在面试过程中主动提供公司情况或者职位的相关信息。如果在某些方面已经了解，可以避免重复提问，而是根据对方提供的信息做深入反问。
提问要有重点：选择你真正感兴趣的领域提问，而不是仅仅为了提问而提问，这样能够让面试官感受到你的诚意。
避免问薪资福利问题：虽然薪资福利是非常重要的，但在第一次面试中，过早提及这些话题可能让面试官觉得你对职位的兴趣不够强烈。可以等到面试后期或面试官主动提出时再谈。

通过精心准备和有针对性的反问，你可以更好地展现自己的兴趣和能力，同时也能帮助你做出是否接受该职位的决策。

高可用做么做？多AZ?跨机房容灾，跨地域容灾，双平面容灾 #

在设计高可用（High Availability, HA）架构时，目的是确保在面对硬件故障、网络中断、数据中心宕机等意外事件时，系统仍然能够保持连续服务，不会影响用户的正常使用。不同的高可用策略有不同的实现方式，下面我们会介绍一些常见的高可用设计方法，包括多可用区（Multi-AZ）、跨机房容灾、跨地域容灾以及双平面容灾等。

1. 多可用区（Multi-AZ）高可用架构 #

多可用区是指将应用和服务部署在同一地域的多个独立的可用区（Availability Zone，AZ）中。可用区是云提供商（如 AWS、GCP、Azure 等）提供的多个物理隔离的区域，它们在同一个地理区域内，但物理上完全独立，因此可以承受局部的硬件或网络故障。

关键点： #

负载均衡：使用负载均衡器（如 AWS Elastic Load Balancer，Azure Load Balancer）将请求分发到不同可用区的实例。
跨 AZ 数据同步：例如，使用数据库的主从复制、分布式存储等，确保数据在不同 AZ 之间同步。
冗余和备份：部署冗余实例，确保即使某个 AZ 故障，其他 AZ 中的实例可以继续提供服务。

示例： #

Web 应用：在多可用区中部署 Web 应用实例，通过负载均衡器将流量分发到各个实例上。
数据库：数据库采用主从复制或集群方式，数据实时同步到多个 AZ。

优点： #

高可用性：保证单个 AZ 故障时，其他 AZ 能继续提供服务。
成本较低：相比于跨地域和跨机房，成本较为经济。

缺点： #

单地域故障：如果整个地域发生灾难（如地域级别的故障），可能无法提供服务。

2. 跨机房容灾 #

跨机房容灾是指将应用和数据部署在不同的物理机房内，通常是同一个城市或区域内的多个机房。每个机房可以看作是一个独立的灾难域，机房之间通过专用的网络连接，保障数据和服务的高可用性。

关键点： #

异地备份和同步：各个机房之间需要通过专用网络或者公网进行数据同步和备份，常见的技术有主从复制、分布式数据库、对象存储同步等。
故障切换：在一个机房发生故障时，应用可以自动切换到另一个机房。通常，使用DNS 切换或负载均衡器来实现。

示例： #

Web 应用：在不同的机房部署 Web 服务，当一个机房出现故障时，流量可以切换到另一个机房的服务实例。
数据库：使用数据库的跨机房复制，确保数据实时同步，机房间的数据一致性。

优点： #

容灾能力强：即使某个机房发生灾难，其他机房可以接管服务。
灵活性：可以根据需求扩展至更多机房。

缺点： #

成本高：跨机房的网络和存储同步成本较高。
网络延迟：不同机房间的延迟可能较大，尤其是跨区域或跨城市的情况下。

3. 跨地域容灾（Cross-Region Disaster Recovery） #

跨地域容灾是指将系统的多个副本分布在不同的地理区域，通常是不同的城市或国家。这样可以有效应对某个地区发生灾难（如自然灾害、大规模网络中断等）导致的故障。

关键点： #

数据同步和备份：使用跨地域的数据库复制、文件存储同步、数据备份等手段确保数据在不同区域间的高可用。
自动故障切换：通过 DNS 或负载均衡器等技术，在灾难发生时，自动将流量引导到健康的区域。
低延迟访问：通过智能路由和流量引导，确保用户的请求能够尽可能地被就近的地域处理，减少延迟。

示例： #

Web 应用：通过跨地域的负载均衡器和流量路由，将流量分发到不同区域的服务实例。
数据库：使用跨地域的数据库同步和灾难恢复策略，保证主数据中心失效时，数据不会丢失，且能在备份地区恢复。

优点： #

地域灾难容忍：能够应对大范围的地理灾难，保证全局服务的可用性。
用户体验优化：将用户请求路由到最近的地域，减少延迟，提高性能。

缺点： #

成本高：跨地域的数据同步、备份以及负载均衡的成本较高。
延迟问题：跨地域的数据同步可能会受到网络延迟和带宽限制的影响。

4. 双平面容灾（Dual-plane Disaster Recovery） #

双平面容灾通常指的是在同一应用系统中实现两个独立的运维平面，一个负责生产环境，另一个负责灾难恢复环境。生产环境和灾难恢复环境之间存在完全的隔离和自动化切换机制，以确保高可用性。

关键点： #

双活架构：两个环境通常是双活的，即两个平面都能承载流量。通过负载均衡或者 DNS 切换，在发生故障时实现平滑切换。
自动化切换：当生产环境出现问题时，灾难恢复环境可以无缝接管业务，确保业务不中断。
数据同步：生产环境和灾难恢复环境之间需要实时同步数据，确保切换时数据一致性。

示例： #

Web 服务：两个平面分别部署在不同的可用区、不同的机房或不同的地域中，保证任意一方出现故障时，另一方可以继续服务。
数据库同步：生产数据库和灾难恢复数据库保持同步，灾难恢复数据库在平时处于冷备状态，发生故障时启用。

优点： #

无缝切换：当发生灾难时，切换平面几乎没有中断。
高可靠性：确保服务的零停机时间，能够承受硬件故障、区域灾难等。

缺点： #

实现复杂：双平面架构需要较高的自动化水平和技术能力来维持两边环境的一致性和同步。
成本高：保持两个独立且活跃的平面需要较高的基础设施和运维成本。

总结 #

高可用架构设计需要根据具体的需求、预算、容灾目标以及服务重要性来决定。以下是几种常见的高可用策略的总结：

多可用区（Multi-AZ）：适用于单地域内的高可用架构，通过多个 AZ 部署服务，保证单个 AZ 故障时，其他 AZ 仍然可以提供服务。
跨机房容灾：适用于同一地区内的多个机房，通过机房间的数据同步和冗余部署，确保一个机房宕机时业务不受影响。
跨地域容灾：适用于应对大规模地域灾难，能够在不同地理位置的灾难恢复环境中保证服务的持续性。
双平面容灾：适用于需要零停机时间的业务，通过双活架构保证在任一平面发生故障时，另一平面能够无缝接管服务。

每种策略都有不同的优缺点，可以根据公司的具体需求进行选择和结合，打造灵活可靠的高可用架构。

你遇到的棘手的问题？怎么解决的？ #

单master改造为3master，3etcd

单master改造

比较好的监控是怎样的 prometheus grafana alertmanager 考虑存储 大规模 2000台机器 考虑告警延迟 考虑长期储存 考虑监控业务的全面性 准确性 告警实时性 #

1. Prometheus 架构设计 #

2. Grafana 可视化 #

3. Alertmanager 告警管理 #

4. 存储与长期数据保留 #

5. 业务全面性和准确性 #

6. 监控系统的高可用性 #

总结 #

数据库的高可用的设计 #

1. 主从复制 (Master-Slave Replication) #

特点： #

缺点： #

实现： #

2. 双主复制 (Master-Master Replication) #

特点： #

缺点： #

实现： #

3. 数据库集群 (Database Clustering) #

特点： #

实现： #

4. 故障转移与负载均衡 (Failover and Load Balancing) #

实现： #

5. 同步与异步复制 #

实现： #

6. 备份与恢复 (Backup and Restore) #

特点： #

实现： #

7. 云原生数据库高可用设计 #

特点： #

实现： #

总结：高可用数据库设计的考虑要点 #

业务监控怎么做的？ #

业务监控设计的关键步骤： #

1. 定义关键业务指标 (KPI) #

常见业务监控指标： #

业务指标示例： #

2. 选择合适的监控工具 #

系统层级监控工具： #

业务层级监控工具： #

3. 设置告警与响应机制 #

告警策略： #

告警渠道： #

4. 实时监控与数据分析 #

关键实时数据： #

数据分析： #

5. 监控系统的维护与优化 #

维护工作： #

高效的报警管理： #

总结 #

业务pod告警规则设计和例子 #

1. 监控指标 #

2. 常见告警规则设计 #

a. 资源使用告警（CPU、内存等） #

b. Pod 重启次数告警 #

c. Pod 健康检查失败告警 #

d. Pod 启动延迟告警 #

e. Pod 状态异常告警 #

f. 网络流量告警 #

3. 告警规则设置中的注意事项 #

4. 告警通知与响应 #

总结 #

还有吗？比如黑盒探针检测 借口探活 #

1. 黑盒探针（Black-box Probing） #

a. HTTP 探针（HTTP Probe） #

b. TCP 探针 #

c. DNS 查询探针 #

2. 接口健康检查（Endpoint Health Check） #

a. Web 服务健康检查端点 #

b. 外部 API 接口健康检查 #

c. 数据库连接健康检查 #

3. 健康检查和探针常见的设计考虑 #

4. 综合应用健康检查与告警 #

总结： #

外部的流量进入到k8s集群内部的过程 #

1. 外部流量的入口： #

a. 外部访问的入口点 #

2. 通过 LoadBalancer（云环境） #

流程： #

3. 通过 Ingress（HTTP/HTTPS 路由） #

流程： #

比较好的监控是怎样的 prometheus grafana alertmanager 考虑存储大规模 2000台机器考虑告警延迟考虑长期储存考虑监控业务的全面性准确性告警实时性 #

还有吗？比如黑盒探针检测借口探活 #

反问面试官问啥 #