grafana告警状态（Grafana监控）

本文目录一览：

• 1、Prometheus

• 2、想转岗坐运维，想问下服务器运维工作内容都有哪些啊？

• 3、Grafana功能菜单介绍(第五篇)

• 4、点我达分布式任务调度系统-DaJob

• 5、(4) -- Jaeger, Prometheus, Kiali, GRAFANA使用指引

• 6、Prometheus的工作原理是什么？

Prometheus

Prometheus是一个开源系统监控和报警工具包，具有活跃的生态系统。是一个多维数据模型，其中的时间序列数据由指标名称和键/值对识别。它不依赖分布式存储，单个服务器节点是自治的。通过一个中间网关支持推送时间序列，可以通过服务发现或静态配置来发现目标，支持多种模式的图表和仪表盘制作。

Prometheus具体架构图如下：

Prometheus 直接或通过中介推送网关从检测的作业中抓取指标，用于短期作业。 它将所有抓取的样本存储在本地，并对这些数据运行规则，以从现有数据聚合和记录新的时间序列或生成警报。 Grafana 或其他 API 使用者可用于可视化收集的数据。

--config.file="prometheus.yml" Prometheus配置文件路径。

--web.listen-address="0.0.0.0:9090" 用于监听UI、API和遥测的地址。

--web.config.file="" [EXPERIMENTAL] 可以启用TLS或认证的配置文件的路径。

--web.read-timeout=5m 超时读取请求和关闭空闲连接之前的最大持续时间。

--web.max-connections=512 最大同时连接数。

--web.external-url=URL 外部可访问Prometheus所在的URL（例如，如果Prometheus通过反向代理提供服务）。用于生成返回到Prometheus本身的相对和绝对链接。如果URL有路径部分，它将用于为Prometheus服务的所有HTTP端点添加前缀。如果省略，将自动派生相关的URL组件。

--web.route-prefix=path Web端点的内部路线的前缀。默认为-web.external-url的路径。

--web.user-assets=path 静态资源目录的路径，位于 /user。

--web.enable-lifecycle 通过HTTP请求启用关闭和重新加载。

--web.enable-admin-api 启用管理控制行动的API端点。

--web.console.templates="consoles" 控制台模板目录的路径，位于/consoles。

--web.console.libraries="console_libraries" 控制台库目录的路径。

--storage.tsdb.path="data/" 指标存储的基本路径。仅用于server模式。

--storage.tsdb.retention.time = 样本在储存中保留多长时间。设置此标志后，它会覆盖“storage.tsdb.retention”。如果此标志、“storage.tsdb.retention”或“storage.tsdb.retention.size”均未设置，则保留时间默认为15d。支持的单位：y、w、d、h、m、s、ms。仅用于server模式。

--storage.tsdb.retention.size = 块存储的最大字节数。需要一个单位，支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。仅用于server模式。

--storage.tsdb.no-lockfile 不在数据目录中创建锁文件。仅用于server模式。

--storage.tsdb.allow-overlapping-blocks 允许重叠块，从而启用垂直压缩和垂直查询合并。仅用于服务器模式。

--storage.agent.path="data-agent/" 指标存储的基本路径。仅用于agent模式。

--storage.agent.wal-compression 压缩代理WAL。仅用于agent模式。

--storage.agent.retention.min-time= 当WAL被截断时，样本在被强行删除之前的最小年龄，仅用于agent模式。

--storage.agent.retention.max-time= 当WAL被截断时，样本在被强行删除之前的最大年龄，仅用于agent模式。

--storage.agent.no-lockfile 不在数据目录中创建锁文件。仅用于agent模式。

--storage.remote.flush-deadline=duration 在关闭或重新加载配置时等待刷新样本的时间。

--storage.remote.read-sample-limit=5e7 在单个查询中通过远程读取接口返回的最大样本总数。 0 表示没有限制。对于流式响应类型，将忽略此限制。仅用于server模式。

--storage.remote.read-concurrent-limit=10 并发远程读取调用的最大数量。 0 表示没有限制。仅用于server模式。

--rules.alert.for-outage-tolerance=1h 为恢复“for”警报状态而容忍Prometheus中断的最长时间。仅用于server模式。

--rules.alert.for-grace-period=10m 警报和恢复“for”状态之间的最短持续时间。这仅适用于配置的“for”时间大于宽限期的警报。仅用于server模式。

--rules.alert.resend-delay=1m 在向 Alertmanager 重新发送警报之前等待的最短时间。仅用于server模式。

--alertmanager.notification-queue-capacity=10000 等待Alertmanager通知的队列容量。仅用于server模式。

--query.lookback-delta=5m 在表达式评估和联合期间，检索指标的最长回溯持续时间。仅用于server模式。

--query.timeout=2m 查询在中止之前可能需要的最长时间。仅用于server模式。

--query.max-concurrency=20 并发执行的最大查询数。仅用于server模式。

--query.max-samples=50000000 单个查询可以加载到内存中的最大样本数。请注意，如果查询尝试将比这更多的样本加载到内存中，查询将失败，因此这也限制了查询可以返回的样本数量。仅用于server模式。

--enable-feature= 逗号分隔的要启用的功能名称。有效选项：agent、exemplar-storage、expand-external-labels、memory-snapshot-on-shutdown、promql-at-modifier、promql-negative-offset、remote-write-receiver。extra-scrape-metrics、new-service-discovery-manager。

--log.level=info 只记录给定严重程度或以上的信息。其中之一：[debug, info, warn, error]。

--log.format=logfmt 日志信息的输出格式。其中之一：[logfmt, json]。

通用占位符定义如下：

全局配置区域：

scrape_config部分指定了一组描述如何抓取它们的目标和参数，目标可以通过static_configs参数静态配置或使用支持的服务发现机制之一动态发现。

Prometheus自身支持basic验证和TLS（将来可能会改变），也可以通过nginx开启basic验证。

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

Prometheus UI提供了快速验证PromQL以及临时可视化支持的能力，而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板（Dashboard）。这时用户可以考虑使用第三方的可视化工具如Grafana，Grafana是一个开源的可视化平台，并且提供了对Prometheus的完整支持。

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

Alertmanager 处理客户端应用程序（例如 Prometheus 服务器）发送的警报。 它负责对它们进行重复数据删除、分组和路由到正确的接收器集成，例如Email、PagerDuty 或 OpsGenie。 它还负责警报的静音和抑制。

报警全家桶

想转岗坐运维，想问下服务器运维工作内容都有哪些啊？

目前就职的岗位就是Linux运维工程师。

现在的公司基本都上云了，有用阿里云的，Azure，AWS的，所以对这些云供应商提供的服务要熟悉。如ECS、CDN、OSS等。

工作内容大体就是：

公司项目环境的部署上线（测、正服）

上线后要做好监控告警（Zabbix、Grafana等）

做好服务器安全（软件升级、防火墙配置、Jumpserver跳板机等）

做好数据安全（数据库主从、数据定时备份等）

开发运维脚本（Shell、Python等）

配合开发处理项目应用问题

运维最主要就是保证项目服务7*24安全稳定运行，再者优化自己的工作流程，尽量做到自动化，解放我们的双手，才能去做其它更有意义的事情（如提升自己的专业技能）。

Grafana功能菜单介绍(第五篇)

在使用Grafana展示数据前，我们先来熟悉Grafana的各个功能菜单的用途。为方便记忆，现将菜单栏各项功能编号为1-11，如下图所示。

①Grafana的logo，即当前页为Grafana的Home page，在任何页面点击Grafana的logo，都会跳到Home Page。

② 新建按钮，用于创建Dashboard、文件夹、以及导入外部（社区）Dashboard。

③ 用于查看或管理Dashboard，包括Home、Manage、Playlists、Snapshots功能。

④ Explore（探索），主要用于快速编写查询语句，来查询数据源中的数据。这样我们就可以先专注于查询迭代， 直到有一个有效的查询，然后再考虑放到仪表盘中。

⑤ 告警设置，可以设置邮件、短信、钉钉等Webhook告警。

⑥ 设置，包括配置Data Sources（数据源）、Users（邀请用户）、Teams(创建团队)、Plugins(插件查找)、Preferences（偏好设置）、API Keys（API 密钥）

⑦管理设置，包括Users（用户创建）、Org（组织创建）、Settings（设置参数查看）、Stats（Grafana 本身状态信息统计）、Upgrade（Grafana 软件升级）

⑧用户设置，包括Preferences（偏好设置）、Change Password（修改密码）、Sign out（退出）

⑨帮助，包括帮助文档、社区链接等。

⑩ Dashboard设置，包括设置Dashboard名称、描述、所在文件夹、时区、是否允许编辑、自动刷新间隔、注释、变量、增加Dashboard链接、Dashboard的Json文件等。

⑪ 循环视图模式，在该模式下，Grafana的侧边菜单栏（sidebar）将被隐藏。

熟悉了Grafana的各个功能菜单后，接下来将使用Graph Panel来创建我们的第一个Dashboard。

总结：做任何事贵在循序渐进和持之以恒。

点我达分布式任务调度系统-DaJob

背景

随着互联网的发展，应用服务中的定时任务数量日益增加，常规的垂直应用架构已无法应对，分布式服务架构势在必行。同时，也迫切需要一个分布式任务调度系统来管理分布式服务中的定时任务。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，在该应用中的定时任务如果不多还好，但是一旦比较多，则意味着每次更改一个定时任务的执行时间，就需要重新部署一遍整个应用，导致整个应用停滞一段时间。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分为互不相干的几个应用来提升效率。此时，相应的任务也会被垂直拆分，每次更改任务带来的影响相应减少。

分布式服务架构

当垂直应用越来越多，应用之间可能会出现不可避免的交互，此时，将核心业务抽取出来，形成单独的服务，各式各样的服务逐渐形成稳定的服务中心，使得前端应用能更快地响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键，同时，由于服务独立，则一般能做到定时任务独立的情况，因此，任务的更改对于整体系统的影响小之又小。

分布式任务调度

在分布式服务架构的基础上，由于独立业务的数量可能很多，此时如果定时任务单独在该服务中实现，很可能会出现难以管理的情况，且避免不了定时任务更改导致的业务重启，因此，一个独立的分布式任务调度系统是很必要的，可以用来全局统筹管理所有的定时任务，同时，将任务的配置单独抽离出来作为该分布式任务调度系统的功能，就能做到定时任务的更改不影响任何业务，也不影响整个系统。

架构设计

设计思想

以Dubbo核心，将调度单独抽象出来，成为一个调度中心，调度中心本身不承担实现任何业务逻辑，只是单纯依据调度配置来发起调度请求

将任务抽象成为ExecutorService，由任务执行者来实现具体的任务，并且负责接收调度请求并执行，这样设计可以将任务与调度中心完全解耦，提高整个系统的扩展性，方便接入

将调度中心对任务执行者的一些调用操作提取出来，形成一个单独的管理控制台，可以用来查看任务执行情况，同时该管理控制台通过H5实现，并提供对外Restful API，方便扩展与接入

通过各种中间件，实现一些必须的操作，例如告警，监控，日志收集统计等操作，完全对整个系统安全性，稳定性的保障

调度中心集群通过Zookeeper存储每个Schedular的一致性HashCode，以此来分配Job与Schedular之间的关系：新增的Job将会通过每个Schedular的一致性HashCode获取其对应的Job数，依据Job数的大小以及Schedular的相关属性来计算每个Schedular的权重，根据权重的大小来确定当前新增的Job应该被分配到哪个Schedular上。

当新增Schedular之后，该新增的Schedular的Job正常为0，因此，正常状态下，该新增的Schedular的权重会比较大。

同时，调度中心通过Zookeeper对Schedular实现主备切换，确保系统稳定性

系统组成

Schedular

基于Quartz实现调度，提供对执行者操作的接口，用于操作任务调度配置，调度触发等操作;自身不参与任务逻辑的实现，不会受限于任务

执行者

负责接收调度中心发起的调度请求，实现相应业务逻辑，完成任务执行，同时会对任务逻辑进行切面处理，记录相应日志并在任务结束后发送给调度中心

管理控制台

管理控制台负责展示任务状态，执行情况，任务执行日志等报表数据，同时可以通过管理控制台配置新增任务，操作任务的状态，暂停/恢复等;另外，提供对外Restful API与H5的接入

Dubbo Monitor

实时监控调度中心接口调用情况，统计调度频次，成功失败，QPS等，能通过这些报表数据来优化任务调度，优化系统

ELK

通过ELK（ElasticSearch+Logstash+Kibana）来收集调度中心以及各执行机的执行日志，并加以分析统计，形成报表，可以方便提供观察

Alarm

报警系统，通过Chronograf控制台配置告警规则，在出现问题时第一时间通过Kapacitor进行邮件与短信报警，可以有效提高错误提示的及时性并且降低错误发生到错误解决过程中消耗的时间，降低生产环境造成的损失，告警数据通过业务仪表盘获取。例如：可以配置线上机器的cpu当前使用率，设置阀值50%，策略为超过设置阀值时短信告警，此时当线上某台机器cpu超过50%时，即会发送短信告警

业务仪表盘

通过打点的方式，来实时收集接口监控数据，通过logstash传输到kafka，通过kafka再分发到jstorm进行处理，处理完之后再存储到influxdb，形成业务仪表盘，最后通过Grafana控制台产生监控报表

配置中心

整个系统各服务，通过配置中心统一管理相应配置，形成分布式配置管理机制，方便系统内各服务的配置一致性以及准确性

在配置完之后，就可以实现自己的任务逻辑了

接入之后，可以通过日志管理控制台线上实时查看任务执行状态

另外，由于有告警系统，在任务执行异常时，会产生告警邮件与短信，实时发送，告知任务接入者与相应研发人员

配置中心属性配置

特性

支持动态暂停/恢复任务

任务状态停止时，任务将不再被触发，若任务在执行过程中被暂停，则正在执行的任务不会被阻塞（由于任务执行结果状态中存在超时失败状态，因此如果点击暂停按钮时阻塞了当前正在执行的任务，会使当前任务的执行状态变为超时，不符合超时状态真正的意义），会延迟停止，即等到当前任务执行完再真正停止任务

调度中心基于Quartz实现，通过Zookeeper实现主备隔离，保证调度中心HA

当活跃节点宕机，冷备节点就会载入所有活跃节点中正在调度状态的任务，成为新的活跃节点，保证任务调度的准确执行

执行机支持集群部署，任务分布式执行，通过调度中心统一调度

执行机负载均衡，默认根据任务在某个执行机上的执行次数计算执行机调度权重，按照权重来选择本次任务调度分发给哪台执行机，实现负载均衡，可手动更改执行机选择策略

执行机集群方式,

failover,failfast,failsafe,failback,forking，默认为failover(故障切换)，调用失败时，重试其他服务器;failfast(快速失败)，只会发起一次调用，不会重试，失败立即报错;failsafe(失败安全)，出现异常时，直接忽略;failback(失败恢复)，调用失败时，定时重发，直到成功，重启会丢失; forking，并行调用多个执行机，只要一个成功即返回

分片任务，支持任务分片，通过参数发送给任务执行机，执行机可以通过判断参数来进行分片作业的开发，同时支持动态分片，以分片参数和执行机为纬度进行分片，支持动态扩容执行机以及分片参数

例如，某张订单表按照订单ID来进行简单纬度分片，且以取模3来进行分片，则可以设置三个分片参数，(0，1，2)，执行机在通过context拿到其中的一个分片参数之后可以对该分片参数做判断，来做具体的数据操作，例如当拿到的分片参数为0时，则对于0相应的分片做数据查询操作，依次类推

再例如，某张订单表按照订单ID和Status来进行二维分片，ID取模以3来进行分片，状态以成功，失败两种状态来进行分片，此时就可以设置6个分片参数，({‘id’:0,’status’:0},{‘id’:1,’status’:0},{‘id’:2,’status’:0},{‘id’:0,’status’:1},{‘id’:1,’status’:1},{‘id’:2,’status’:1}),执行机在通过context拿到其中的一个分片参数之后，就可以对其json参数进行判断，来实现分片操作

任务执行一致性，每次任务只会被一个执行机所执行;对于分片任务，在执行机集群部署时，一次任务调度将会广播触发对应集群中相应数量的执行器执行一次任务，同时传递分片参数，可根据分片参数开发分片任务。

当分片参数大于执行器数量时，将会按照执行器路由策略，使得当前分片任务的某个或者某几个执行机执行多个分片的任务

例如：当前分片任务分片参数为(a,b,c),当前任务执行机有3台(A,B,C)时，则会均匀随机得将分片参数发送给某一台执行机，且三台执行机一次只接收一个分片参数，做一次任务处理，即(a-A,b-B,c-C)|(a-A,b-C,c-B)|(a-B,b-A,c-C)|(a-B,b-C,c-A)|(a-C,b-A,c-B) |(a-C,b-B,c-A)；

当任务执行机只有2台(A,B)时，每次任务调度时，某台执行机会收到两个分片参数，并分别处理这两个分片参数,即(a-A,b-B,c-A)|(a-A,b-B,c-B)|(a-B,b-A,c-A)|(a-B,b-A,c-B)；

而当任务执行机大于分片参数个数，为4台(A,B,C,D)时，(a-A,b-B,c-C)|(a-A,b-C,c-D)|(a-A,b-D,c-B)| (a-B,b-C,c-D)|(a-B,b-D,c-A)|(a-B,b-A,c-C)|(a-C,b-A,c-B)|(a-C,b-B,c-D)| (a-C,b-D,c-A)|(a-D,b-A,c-B)|(a-D,b-B,c-C)|(a-D,b-C,c-A)，而统计下来，不管是执行机数目大于或者等于或者小于分片参数数目，被分发给执行机的分片参数始终是保持一致的（每台执行机接收到的总的分片参数是均匀的）

告警系统，系统接入内部告警系统，任务失败时支持邮件，短信，钉钉，电话等告警

弹性扩容缩容，调度中心将会实时探测任务执行机，因此一旦有执行机上线或者下线，都将会被探测到，而如果未被调度中心探测到，则可以进行手动探测执行机，而在探测到执行机之后，下次调度将会重新分配任务

任务依赖，支持配置任务依赖关系，当父任务在执行完成之后会自动触发子任务的执行例如：有两个任务，分别为A和B，而B的执行条件为确认A任务执行完，B才能执行，否则，B任务不执行，此时的依赖关系就是B任务依赖A任务，此时在A任务配置完之后，设置B任务为依赖任务，而依赖关系则是A；又例如有6个任务，分别是A1,A2,A3,A4,A5,B，而B任务的执行需要确保A1-5这5个任务都执行完，B任务才执行，此时，B的依赖关系就是B任务依赖于A1-5，此时在配置完A1-5这5个任务之后再设置B为依赖任务，依赖关系则是A1-5

支持运行时查看任务执行情况，任务数量，调用次数，执行器数量等统计信息异常执行恢复机制，有时会遇到不可控情况，即执行机在执行后的执行结果因为网络断开等不可控因素导致不能发送给调度中心，此时能通过异常执行恢复机制临时记录，在下次执行机正常启动时重试发送给调度中心调度手动触发手动执行，特殊需求下，可能会要求调度可以手动执行，例如调度任务失败之后可能需要手动执行一次调度来补偿

并行/串行策略，当定时时间远大于任务执行时间时，可以使用并行策略，任务异步调用执行，提高任务调度精确度;当任务执行时间可能大于定时时间，却需要任务按照某个定时规则定时调度时，可以使用串行策略，调度中心调度的当前任务的上一次触发，如果没有执行完，则当前执行机的下一次定时时间点时不会被触发，当且仅当任务执行结束，以防止某些持续性定时任务的时间不确定性导致异步触发时的数据混乱的情况发生，例如：某一任务的定时时间为10秒钟，但是任务本身可能会出现执行超过10秒的情况，而超过时，如果出现两个时间点的任务并行执行时会出现数据混乱的情况，此时就可以使用串行策略，确保当前执行机上一个任务未执行完，不会触发新的执行

支持调度接口数据监控，产生监控报表，便于观测。

总结

对于互联网公司来说，时间就是金钱，效率决定一切。本系统在接入到8月初将近3个月的时间内，表现不凡，调度了约100万次，给公司内部各服务实现任务调度提供了便利。

原文

(4) -- Jaeger, Prometheus, Kiali, GRAFANA使用指引

官方文档：

Jaeger是一个开源的分布式跟踪系统。您可以使用jaeger来监控和排查基于微服务的分布式系统的故障。使用jaeger，您可以执行跟踪组成应用程序的各种微服务执行请求的路径。默认情况下，jaeger是作为 Service Mesh 的一部分安装的。

1.1.1 部署了bookinfo应用程序后，通过访问并刷新页面几次来生成一些访问痕迹。

1.1.2 将jaeger的路径设置到环境变量

1.1.3 从浏览器访问jaeger

1.1.4 在Jaeger仪表板的左侧窗格中，从Service菜单中选择“productpage”，然后单击窗格底部的“Find Traces”按钮。将显示跟踪列表，如下图所示：

1.1.5 单击列表中的某个跟踪以打开该跟踪的详细视图。如果单击顶部（最新）跟踪，你将看到与`/productpage相对应的详细信息。

上一图中的跟踪由几个嵌套的span组成，每个span对应于一个bookinfo服务调用，所有这些都是响应 /productpage 请求而执行的。总体处理时间为2.62s， details service 花费3.56ms， reviews service 花费2.6s， ratings service 花费5.32ms，对远程服务的每一个调用都由客户端和服务端的span表示。例如，详细信息客户端范围标记为productpage details.myproject.svc.cluster.local:9080。嵌套在它下面的span，标记为details details.myproject.svc.cluster.local:9080，对应于请求的服务器处理。跟踪还显示对istio策略的调用，该策略反映了istio所做的授权检查。

Prometheus是一个开源的服务监控工具。Prometheus以指定的时间间隔从配置的目标收集metrics，评估规则表达式，显示结果，并在观察到某些条件为真时触发警报。Grafana或其他API Consumer被用于可视化展示收集到的数据。

2.1.1 验证prometheus服务是否正在集群中运行。

2.1.2 通过访问bookinfo应用程序生成网络流量：

2.1.3 将Prometheus访问路径写入环境变量

2.1.4 打开浏览器访问 {PROMETHEUS_URL}

2.1.5 在Expression字段中，输入istio_request_duration_seconds_count，然后单击Execute按钮。将看到类似下图：

2.1.6 你可以使用选择器缩小查询范围。例如，istio_request_duration_seconds_count_destination_workload=“reviews-v2”仅显示具有匹配destination_workload标签的计数器。有关使用查询的更多信息，请参阅 Prometheus文档 。

2.1.7 要列出所有可用的Prometheus Metrics，请运行以下命令

Kiali运行于Isito之上，用于可视化服务网格拓扑，以提供对断路器、请求速率等功能的可见性。Kiali提供了从Application到Service和Workload的不同层次的Service Mesh组件的可见性。Kiali实时提供了namespace的交互式图形化界面。Kiali可以在多个层次（Application、versions、workloads）上显示所选图形节点或边缘的上下文和图表信息。

3.1.1 访问Kiali控制台的路径已经存在。运行以下命令获取路由和Kiali Url

3.1.2 可以看到这样的结果：

3.1.3 在浏览器访问Kiali {KIALI_URL}

登录后，会看到OVERVIEW PAGE，该页面提供了系统中各个namespace的运行状况的快照。

3.3.1 单击左侧导航中的“Graph”。Graph page显示一个包含所有微服务的图形，这些微服务由通过它们之间的请求连接。在这个页面上，您可以看到服务是如何交互的。

3.3.2 从namespace菜单中，选择BookInfo。现在，图表只显示BookInfo应用程序中的服务。

3.3.3 单击左下角的“Legend”。Kiali显示一个包含图形图例的窗口。

3.3.4 将鼠标悬停在ProductPage节点上，将高亮显示该节点的传入和传出流量。

3.3.5 单击ProductPage节点，页面右侧显示ProductPage的详细信息。

3.4.1 单击左侧导航中的“Services”链接。在Services Page上，您可以查看集群中运行的所有Service的列表以及有关这些Service的其他信息，例如运行状况和请求错误率。

3.4.2 将鼠标hover在任何服务的运行状况图标上，以查看有关该服务的运行状况信息。当服务处于联机状态并且响应请求时没有错误，则认为它是健康的。

3.4.3 单击“Reviews ”服务查看其详细信息。请注意，此服务有三个不同的版本。

3.4.4 单击其中一个服务的名称以查看有关该服务的其他详细信息。

3.5.1 单击左侧导航中的istio config链接。在此页面上，您可以看到当前运行的所有配置，如Circuit Breakers, Destination Rules, Fault Injection, Gateways, Routes, Route Rules, and Virtual Services.

3.5.2 单击其中一个配置以查看其他附加信息。

单击左侧导航中的Distributed Tracing链接。在这个页面上，您可以看到Jaeger提供的跟踪数据。

Grafana是一个开源工具，用于创建监控、metrics分析、并提供可视化的dashboard。您可以使用grafana查询metrics、可视化metrics、告警，无论它们存储在graphite、elasticsearch、opentsdb、prometheus或infloxdb。Istio通过Prometheus和Grafana进行监控。

本节演示如何设置和使用Istio仪表板来监视Service Mesh的流量。你需要安装grafana istio插件，并使用基于Web的界面查看Service Mesh流量数据。

4.1.1 查询并设置Granfa的route到环境变量

4.1.2 打开浏览器访问Grafana， {GRAFANA_URL}

4.1.3 在左上角的菜单中，选择istio mesh dashboard以查看istio mesh metrics。

4.1.4 通过访问bookinfo应用程序生成一些流量：

dashboard反映通过Service Mesh的流量，类似于下图：

4.1.5 要查看Service的详细指标，请单击“Services”列中的服务名称。dashboard类似于下图：

4.1.6 要切换到workloads dashboard，请单击左上角菜单上的Isito Workload Dashboard。看到类似下图：

Prometheus的工作原理是什么？

Prometheus 最开始是由 SoundCloud 开发的开源监控告警系统，是 Google BorgMon 监控系统的开源版本。在 2016 年，Prometheus 加入 CNCF，成为继 Kubernetes 之后第二个被 CNCF 托管的项目。随着 Kubernetes 在容器编排领头羊地位的确立，Prometheus 也成为 Kubernetes 容器监控的标配。

监控系统的总体架构大多是类似的，都有数据采集、数据处理存储、告警动作触发和告警，以及对监控数据的展示。下面是 Prometheus 的架构：

Prometheus Server 负责定时从 Prometheus 采集端 Pull(拉) 监控数据。Prometheus 采集端可以是实现了 /metrics 接口的服务，可以是从第三方服务导出监控数据的 exporter，也可以是存放短生命周期服务监控数据的 Pushgateway。相比大多数采用 Push(推) 监控数据的方式，Pull 使得 Promethues Server 与被采集端的耦合度更低，Prometheus Server 更容易实现水平拓展。对于采集的监控数据，Prometheus Server 使用内置时序数据库 TSDB 进行存储。同时也会使用这些监控数据进行告警规则的计算，产生的告警将会通过 Prometheus 另一个独立的组件 Alertmanager 进行发送。Alertmanager 提供了十分灵活的告警方式，并且支持高可用部署。对于采集到的监控数据，可以通过 Prometheus 自身提供的 Web UI 进行查询，也可以使用 Grafana 进行展示。