sl容器云时代监控和仪表板实践

在云和容器云时代，衡量一个服务的成功与否不再是你怎么构建一个完美的产品，而是持续的服务能力。怎么定义这个能力呢？根据ITIL标准，有客户定义质量和性能服务水平协议 (SLA)，为了持续了解目前在线服务的SLA，需要部署监控以跟踪它，确保满足SLA的要求。说到监控可能大家都熟悉基本的监控项目（比如zabbix）和一些接口质量的监控（nagios） ,但是这些对SLA来说是不足的。为了监控SLA，我们需要想要创建监控仪表板，通过可视化收集的一些日志和指标并了解产品的行为。本文虫虫就给大家说说如何创建一个监控SLA的仪表板，仪表盘应该添加哪些指标。

文章插图
常见误区
所有指标一个仪表板：一张图像对应一个指标，在一个仪表板中添加1000个小图表。所以，根本没法看到（查到）需要的指标或趋势。
指标图表/面板之间没有相关性或流程：仪表板的凝聚力无关紧要。从任何级别和层以任何顺序绘制指标。迫使团队花时间在仪表板上扫描相距很远的相关指标面板。
不要聚合指标：在每个面板上为每个进程/服务器/服务实例绘制一条单独的线。是否有100个服务实例报告响应时间？在响应时间面板上绘制100行。
在同一面板中混合来自不同级别的指标：在同一面板中混合基础设施和应用程序级别的指标。在同一面板中绘制服务实例计数和响应时间。绘制同一面板中的进程数和错误率。
没有变量，没有深入研究：没有提供任何可变参数或向下钻取选项来选择和查看特定客户端/服务/环境的指标。假设仪表板将被克隆，并且在每个新克隆中硬编码任何此类选择。
无概览仪表板：为每个指标级别创建单独的仪表板。为每个组件创建一个单独的仪表板。让团队浏览3个仪表板，需要在心里将业务与应用程序联系起来，再到基础设施指标，以确定整体系统健康状况。
正解：自顶向下，从概览开始

文章插图
概览仪表板：构建仪表板以快速概览系统的健康状况。提供一个胜过一切的顶部面板，显示指示系统性能（或正在跟踪的内容）的最高级别指标。看一眼那个面板就可以知道系统是否正常。
监控项：检测代码以公开有意义的指标，实现快速地评估当前行为。公开有关运行状况、性能、负载或服务质量的指标。用监控系统来收集这些指标并随着时间的推移捕捉行为趋势和模式。使用这些趋势和模式作为系统/应用程序改进的基础。
日志：使用日志记录来帮助追踪问题的根源。当生产问题发生时，重要的是要有足够的日志记录来快速追踪其根本原因。如果可以在生产组件上启用按需信息/调试级别信息而无需更改代码和/或发布，会有所帮助。
自上而下的结构：按行和列构建仪表板面板。从顶部行的最高级别指标开始，并在添加其他行时降低指标级别。例如，影响业务的指标将位于顶部面板行中，然后应用程序指标和基础设施将位于最后。
每个组件的列：如果可能，为每个组件或处理阶段保留一列面板。在同一行的单独水平排列的面板中为每个组件/阶段绘制相同的度量。如果系统有问题，应该第一眼看到仪表板。然后，应该会看到哪个组件/处理阶段有问题。最后，应该会看到问题的根源。
左右结构：当从左到右导航仪表板时，如果可能，面板应根据系统中的数据流绘制指标。应该能够快速确定数据流中存在问题的位置。
可变参数和向下钻取：提供的选项限制指标，特别是客户端，服务或环境的显示，使用可变参数和向下钻取的菜单选项。当问题仅出现在单个客户端或服务上时，这非常有用，并使工程师在调试时能够专注于它们。