黄金信号(Golden Signals)最初是谷歌在站点可靠性工程(SRE)实践的背景下引入的，由谷歌软件工程师Dave Rensin和Kevin Smathers在2016年O 'Reilly Velocity Conference上的一次演讲中提出，其背后的想法是提供一组关键性能指标(KPI)，用于测量和监控复杂分布式系统的运行状况。
引入黄金信号是为了帮助SRE团队关注系统可靠性和性能方面真正重要的东西。黄金信号不依赖于难以解释的大量指标和告警，而是提供一组简单且易于理解的指标，用于快速评估系统健康状况。
自从这一概念提出以来，黄金信号已在SRE社区中得到广泛采用，并被认为是监控和管理分布式系统运行状况的最佳实践。虽然最初黄金信号专注于延迟、流量、错误和饱和指标，但一些组织已经调整了这个概念，引入了特定于其系统和用例的附加指标。不过，通过一组KPI来度量和监控系统健康的核心思想仍然是黄金信号概念的核心。
黄金信号是SRE用来衡量其系统健康状况的一组四个关键指标，包括:
延迟
Prometheus查询histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="fastapi-app"}[5m])) by (le, method, endpoint))通过直方图指标(histogram metric)度量来检测FastAPI应用程序HTTP请求的P95延迟。
该查询计算过去5分钟内http_request_duration_seconds_bucket度量值(表示落入特定延迟桶的请求数量)的速率总和，并按延迟(le)、HTTP方法和端点分组。然后，histogram_quantile函数使用这些值计算每个HTTP方法和端点组合的P95延迟。
流量
Prometheus查询rate(http_requests_total{job="fastapi-app"}[$__rate_interval])通过计数器指标(counter metric)度量FastAPI应用程序每秒HTTP请求的速率。
该查询使用rate函数来计算http_requests_total计数器指标的每秒增长率，计算向FastAPI应用程序发出的HTTP请求总数。job="fastapi-app"标签选择器过滤度量数据，使其只包含来自FastAPI的数据。
$__rate_interval变量是模板变量，表示计算速率的持续时间，该变量值由用户在Prometheus查询界面中设置，用于确定计算速率的时间范围。
例如，如果用户将$__rate_interval设置为5m，查询将计算过去5分钟内HTTP请求的每秒速率。此查询可用于监控FastAPI应用程序的流量，并识别请求量随时间变化的模式或异常情况。
错误数
Prometheus查询http_requests_total {endpoint="/generate_error"， http_status="500"}检索web应用程序的"/generate_error"端点的HTTP请求并且HTTP状态码为500(内部服务器错误)的数量。
该查询使用http_requests_total计数器指标，计算向web应用程序发出的HTTP请求总数。查询通过指定endpoint="/generate_error"标签选择器过滤度量数据，使其只包括对"/generate_error"端点的请求。此外，查询通过指定http_status="500"标签选择器过滤数据，只包括HTTP状态码为500的请求。
通过运行这个查询，可以深入了解web应用中错误发生率，以及哪些端点容易出错。这些信息可以帮助识别和修复应用中的问题，提高可靠性，并确保为用户提供更好的体验。
饱和度
Prometheus查询clamp_max(active_requests{job="fastapi-app"} / 10, 1)用于计算活动请求与最大并发请求数的比率，并将该比率的值限制为不超过1。
该查询使用active_requests度量(gauge)指标检索FastAPI应用程序中的当前活动请求数。job="fastapi-app"标签选择器过滤度量数据，使其只包含来自FastAPI的数据。
然后，查询将活动请求数除以10，表示系统可以处理的最大并发请求数。然后使用clamp_max函数将该比率的值限制为不超过1。这意味着，如果活动请求与最大并发请求数之比大于1，则查询将返回值1。
通过这个查询，可以监控系统饱和情况，并确定系统何时因请求而过载。如果活动请求与最大并发请求数之比接近1，可能需要扩容系统以处理增加的请求。此查询可以帮助我们确保系统在高负载下仍可保持可靠和高性能。
因为黄金信号使SRE们可以清楚了解系统的运行情况，因此非常重要。通过测量和监控这些关键指标，SRE可以快速识别问题，并在问题变得严重之前采取纠正措施，即使这么做增加了系统复杂性，也可以有助于确保系统的可靠性、可伸缩性和高性能。
黄金信号可以通过几种方式来提高系统可靠性:
了解如何在实践中实现这些指标也很重要。实现黄金信号的一种方法是使用内置对其支持的监控工具和库，比如Prometheus。在下面代码示例中，Python FastAPI应用程序通过Prometheus来实现黄金信号。
from fastapi import FastAPI, Request, HTTPException, Responsefrom prometheus_client import Counter, Gauge, Histogram, generate_latest, CONTENT_TYPE_LATESTfrom starlette.responses import StreamingResponseimport timeapp = FastAPI()# Define Prometheus metricshttp_requests_total = Counter( "http_requests_total", "Total number of HTTP requests", ["method", "endpoint", "http_status"])http_request_duration_seconds = Histogram( "http_request_duration_seconds", "HTTP request duration in seconds", ["method", "endpoint"])http_request_size_bytes = Histogram( "http_request_size_bytes", "HTTP request size in bytes", ["method", "endpoint"])http_response_size_bytes = Histogram( "http_response_size_bytes", "HTTP response size in bytes", ["method", "endpoint"])active_requests = Gauge( "active_requests", "Number of active requests")error_counter = Counter( "error_counter", "Total number of HTTP errors", ["method", "endpoint", "http_status"])@app.middleware("http")async def record_request_start_time(request: Request, call_next): request.state.start_time = time.time() response = await call_next(request) return response@app.middleware("http")async def record_request_end_time(request: Request, call_next): response = await call_next(request) latency = time.time() - request.state.start_time http_request_duration_seconds.labels( request.method, request.url.path ).observe(latency) http_request_size_bytes.labels( request.method, request.url.path ).observe(request.headers.get("Content-Length", 0)) if isinstance(response, StreamingResponse): response_size = 0 else: response_size = len(response.content) http_response_size_bytes.labels( request.method, request.url.path ).observe(response_size) http_requests_total.labels( request.method, request.url.path, response.status_code ).inc() return response@app.middleware("http")async def increment_counter(request: Request, call_next): active_requests.inc() response = await call_next(request) active_requests.dec() return response@app.middleware("http")async def log_saturation(request: Request, call_next): max_concurrent_requests = 10 # set the maximum number of concurrent requests saturation_ratio = active_requests._value._value / max_concurrent_requests print(f"Saturation: {saturation_ratio}") return await call_next(request)@app.middleware("http")async def increment_error_counter(request: Request, call_next): try: response = await call_next(request) return response except HTTPException as e: error_counter.labels( request.method, request.url.path, e.status_code ).inc() print(f"Incremented error counter for {request.method} {request.url.path} {e.status_code}") raise e@app.get("/")async def root(): return {"message": "Hello, World!"}@app.get("/generate_traffic")async def generate_traffic(): for i in range(100): response = await root() print(response) return {"message": "Generated traffic successfully."}@app.get("/generate_error")async def generate_error(): raise HTTPException(status_code=500, detail="Generated an error.")@app.get("/metrics")async def metrics(): return Response(cnotallow=generate_latest(), media_type=CONTENT_TYPE_LATEST)requirements.txt:
anyio==3.6.2click==8.1.3fastapi==0.92.0h11==0.14.0idna==3.4prometheus-client==0.16.0pydantic==1.10.5sniffio==1.3.0starlette==0.25.0typing_extensinotallow==4.5.0uvicorn==0.20.0使用Prometheus在FastAPI应用程序中实现了黄金信号后，可能希望将其部署到Kubernetes集群中，以确保可伸缩性和高可用性。下面的Kubernetes清单文件可以用来部署FastAPI应用程序和Grafana仪表板:
fastapi-app.yaml
# @formatapiVersion: apps/v1kind: Deploymentmetadata: name: fastapi-appspec: selector: matchLabels: app: fastapi-app replicas: 2 template: metadata: labels: app: fastapi-app annotations: prometheus.io/scrape: "true" prometheus.io/path: "/" prometheus.io/port: "80" spec: containers: - name: fastapi-app image: rtiwariops/fastapi-app:v1 ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: fastapi-appspec: selector: app: fastapi-app ports: - name: http protocol: TCP port: 80 targetPort: 80grafana.yaml
# @formatapiVersion: apps/v1kind: Deploymentmetadata: name: grafanaspec: selector: matchLabels: app: grafana replicas: 1 template: metadata: labels: app: grafana spec: containers: - name: grafana image: grafana/grafana:latest ports: - containerPort: 3000---apiVersion: v1kind: Servicemetadata: name: grafanaspec: selector: app: grafana ports: - name: http protocol: TCP port: 3000 targetPort: 3000prometheus.yaml
apiVersion: v1kind: Servicemetadata: name: prometheusspec: selector: app: prometheus ports: - name: web port: 9090 targetPort: 9090---apiVersion: apps/v1kind: Deploymentmetadata: name: prometheusspec: selector: matchLabels: app: prometheus replicas: 1 template: metadata: labels: app: prometheus spec: containers: - name: prometheus image: prom/prometheus:v2.28.1 ports: - name: web containerPort: 9090 command: - "/bin/prometheus" args: - "--config.file=/etc/prometheus/prometheus.yml" volumeMounts: - name: config-volume mountPath: /etc/prometheus volumes: - name: config-volume configMap: name: prometheus-config总之，黄金信号是SRE工具箱中的关键工具。通过测量和监控延迟、流量、错误和饱和度指标，即使面对日益增加的复杂性和需求，SRE也可以确保其系统保持可靠、可扩展和高性能。
完整代码示例: https://github.com/PolyCloudNative/Golden-Rule-Demo
[1]Four Golden Signals Of Monitoring: Site Reliability Engineering (SRE) Metrics: https://umeey.medium.com/four-golden-signals-of-monitoring-site-reliability-engineering-sre-metrics-64031dbe268
本文链接：http://www.28at.com/showinfo-26-34674-0.html站点可靠性工程SRE最佳实践 -- 黄金监控信号
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 浅析VR视频传输方案
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
