硬核：值得尝试的DevOps兵器库

DevOps一直是近年来大热话题之一。不过，许多组织时常会困惑于DevOps自动化给整个基础架构所带来的复杂性。并且，它们经常不知道该选择使用哪些DevOps工具。

在业界，有一些可用于监控的集成式DevOps工具集。它们不但可以提高系统的可视性和整体性能，而且能够在保障组织生产力的基础上，建立和谐的跨职能部门协作关系。在DevOps理念中，正确的工具集不仅仅是其中所包含的工具本身，还是用于开发与定义产品、服务、及场景的文化、规则与实践。

在本文中，我们将为您开启一个“兵器库”，并向您介绍各种常用的DevOps工具。它们可以被用于监控DevOps生态系统，并帮助开发和运营团队实现有效地协同工作。

一、DevOps监控工具

通过良好的监控平台，您可以监控到目标基础架构、以及应用程序的性能。无论是在本地、还是在云端、甚至是在容器化的环境里，只要您能够正确地使用监控工具，就能够全面了解并掌握每一个Kubernetes、物联网设备、乃至各种裸机系统的实时状态。

对DevOps的好处：

有效的监控工具可以提高系统的整体性能和生产率，进而有助于减少（甚至消除）服务中断的时间。您可以事先充分地计划好各种升级、以及新的项目，从而更好地分配现有的时间与资源。您可以在迭代的过程中，以及缺陷产品对用户产生影响之前，就及时地检测出各种潜在的问题、并寻求解决方案。

工具：

Sensu（https://docs.sensu.io/sensu-go/latest/） – 一款灵活、且支持可扩展的遥测（telemetry）方案，和服务健康性检查工具。它可以被用于监控服务器、容器、服务、应用程序、功能、以及连接设备等方面。

Prometheus（https://prometheus.io/docs/introduction/overview/） – 它带有内置的数据库，能够依靠pull方法来收集各类信息。

Nagios（https://www.nagios.org/about/overview/） – 虽然是一款传统的监控工具，但是它在运营与监控方面提供了各种新的实践方式。

资源链接：

Nagios服务检索（https://blog.sensu.io/the-story-of-nagios-plugin-support-in-sensu），如何在Sensu中实现重用

Prometheus在监测Kubernetes方面的利与弊（https://blog.sensu.io/monitoring-kubernetes-docker-part-2-prometheus）

如何自动化您的监控工作流（https://blog.sensu.io/workflow-automation-for-monitoring）

二、DevOps配置管理工具

用户能够通过配置管理工具，来实现目标系统配置和部署的自动化；通过实施所需的配置，来修复各种实际环境中的配置偏差。通过将基础架构建模成为各种代码，用户可以将软件交付的各项实践（如版本控制、自动化测试、以及持续交付），应用到基础架构和应用程序之中。

对DevOps的好处：

众所周知，传统的手动执行方式，给运维人员带来了重复且易错的工作负担。DevOps自动化则提高了整体的部署效率。通过可预测和可扩展的实现方式，开发与生产环境能够得到标准化的配置、软件产品才能够确保得到交叉性的测试。通过削减snowflake算法服务器的运行时间，您将能够更快速、更可靠地部署各种软件。

工具：

Ansible（https://docs.ansible.com/） – 该工具由Python所编写，无需代理，用户可采用命令式（而非声明式）的方法。

Chef（https://docs.chef.io/） – 该工具由Ruby所编写，同样依赖于命令式的配置管理方法。

Puppet（https://puppet.com/docs） – 该工具用到了特定域的语言、以及代理/主机的架构。不过它依赖的是声明性的配置管理方法。

资源链接：

简述如何使用Chef来管理自动化基础架构（https://blog.sensu.io/chef-automation-for-infrastructure-management）

将基础设施即代码应用到测试和监控中（https://blog.sensu.io/infrastructure-as-code-testing-and-monitoring）

三、DevOps报警工具

对于软件系统而言，我们时常希望报警工具不但能够提供可操作的报警信息，并且需要能够通过定制来适应系统的复杂性。通过定制，报警系统既要保持足够的敏感性，以全面捕获系统中的各种中断事件，又不可过于敏感，推送海量的报警信息给运维人员，以至于他们熟视无睹、或漏掉关键的事故。

对DevOps的好处：

有了报警工具，开发人员就可以和运维人员一起协商需要报警的各种策略，包括：如何确定需要通知的对象，如何跟踪问题和处置结果，以及如何确定修复的优先级。

工具：

PagerDuty（https://www.pagerduty.com/） – 这是一个候召职务（On-call）的管理平台，能够提供事件情况、故障分析、以及自动响应等附加组件。

ServiceNow（https://www.servicenow.com/） – 该工具能够利用ITSM的自动化工作流，提供客户服务和业务流程。

Slack（https://dzone.com/articles/7-essential-slack-integrations-developers-should-k） – 该平台允许用户将报警整合到同一个群聊与协作的平台中。

资源链接：

如何使用Sensu来处理应用向Slack发送的报警（https://docs.sensu.io/sensu-go/latest/guides/send-slack-alerts/）

如何使用Sensu过滤器来减少报警的数量（https://docs.sensu.io/sensu-go/latest/guides/reduce-alert-fatigue/）

由Sensu社区维护人员编写的缓解过度报警指南（https://sensu.io/resources/whitepaper/alert-fatigue-guide/）

四、指标存储

一旦您实现了自动配置管理、监控与报警，您就会持续获得大量的数据信息。那么，您又该如何安全地存储它们，以供后续分析呢？显然，您需要拥有一个存储系统，来实现汇总系统运能，学习用户行为，改进服务级别，以及控制安全风险等。

对DevOps的好处：

在DevOps中，以数据为驱动的决策，能够促进团队的持续学习和服务的持续改进。因此，通过从指标中获得的洞察力，您可以为业务的各个层面提供决策，提高现有的SLA能力，满足客户的期望，并为新的战略投资提供依据。

工具：

InfluxDB（https://docs.influxdata.com/influxdb/v1.7/） – 这是一个适合于长期数据存储的时序数据库。

Splunk（https://docs.splunk.com/Documentation） – 可通过使用带有搜索引擎的数据库模型，来存储和查询数据。

AWS（https://docs.aws.amazon.com/index.html?nc2=h_ql_doc） – 能够支持广泛的存储目的，包括：关系数据库、非关系数据库、用于分析的数据仓库、时序数据库，用于存储事务的分帐数据库等。

资源链接：

如何创建Sensu的InfluxDB管道（https://docs.sensu.io/sensu-go/latest/getting-started/prometheus-metrics/#install-sensu-influxdb-handler）

使用InfluxDB和Grafana检查输出指标的提取（https://blog.sensu.io/check-output-metric-extraction-with-influxdb-grafana）

五、DevOps可视化工具

可视化工具可谓上述DevOps工具链在监控领域的合适选择：您可以将所有的数据都组合到一起，通过对其进行排序和可视化，最终将其显示到定制的仪表板上。

对DevOps的好处：

通过提供上下文与相关释义，可视化工具允许用户随时跟踪各种变更和改进，并为管理层提供实时的视图，以协助战略指导与决策。其自定义的选项则能够让团队成员轻松地设计和共享自己当前的仪表板。

工具：

Grafana（https://grafana.com/docs/） – 该工具可以在包括Graphite、InfluxDB和Elasticsearch在内的各种不同的数据存储上被使用。

资源链接：

一个结合Sensu、InfluxDB和Grafana的用例（https://blog.sensu.io/how-to-measure-every-api-call-in-your-go-app）

如何使用Grafana来可视化各项指标（https://docs.sensu.io/sensu-go/latest/getting-started/prometheus-metrics/#visualize-metrics-with-grafana）

后续工作：评估您的DevOps工具

DevOps给您带来的是从软件产品流程、开发观念、乃至协同文化上的转变。我们不应简单地进行“堆积木”式的工具套用，而应当将它们合理地运用到持续的监控生态系统之中。无论您现在处于DevOps进程中的哪个阶段，请最好重新评估一下当前正在使用的工具。通过搜索和发现当前监控用例的不足之处，您可以按需进行微调。