都是星期五！ 朋友，今天，我们继续发布有关
DevOps实践和工具课程的一系列出版物，因为该课程新组中的课程将从下周开始。 因此，让我们开始吧！
监视很
容易 。 这是一个已知的事实。 提起Nagios，在远程系统上运行NRPE，在NRPE TCP端口5666上配置Nagios，然后进行监视。
它是如此简单以至于没有意思。 现在，您具有处理器时间，磁盘子系统和RAM的基本指标，这些指标在Nagios和NRPE中默认提供。 但是实际上，这并不是“监视”。 这仅仅是开始。
（通常，他们安装PNP4Nagios，RRDtool和Thruk，在Slack中设置通知，然后直接转到nagiosexchange，但现在放手吧）。
好的监视实际上是非常复杂的，您确实需要了解您正在监视的应用程序的内部。
监控困难吗？
根据定义，任何服务器，无论是Linux还是Windows，都将达到某种目的。 Apache，Samba，Tomcat，文件存储，LDAP-所有这些服务在一个或多个方面都差不多。 每个都有自己的功能，都有自己的特点。 当服务器处于负载状态时，有多种获取指标的方法，即KPI（关键性能指标），这对您来说很有趣。
Luke Chesser在Unsplash上拍摄的照片
（我希望将仪表板涂成霓虹蓝色的颜色-梦幻般地叹气-...嗯...）
提供服务的任何软件都必须具有收集指标的机制。 Apache有一个显示服务器
mod-status页面的
mod-status模块。 Nginx具有
stub_status 。 Tomcat具有显示关键指标的JMX或特殊的Web应用程序。 MySQL具有“显示全局状态”命令，等等。
那么，为什么开发人员不将这样的机制嵌入他们创建的应用程序中呢？
开发人员只这样做吗？
对嵌入指标的某种程度的冷漠不仅限于开发人员。 我在使用Tomcat开发应用程序的公司中工作，除了一般的Tomcat错误日志外，没有产生任何指标，没有服务活动日志。 一些开发人员会生成大量日志，这对系统管理员来说毫无意义，因为他们不愿意在凌晨3:15阅读这些日志。
Tim Gouw发表在Unsplash允许发布此类产品的系统工程师也应对这种情况负责。 很少有系统工程师有时间和精力来尝试从日志中获取有意义的指标，而没有这些指标的上下文以及根据应用程序活动来解释它们的能力。 除了诸如“当前（或将要很快）出现问题”之类的指标外，有些人不知道他们可以从中获得什么好处。
不仅在开发人员中，而且在系统工程师中，都应该对度量标准的想法发生改变。
对于不仅需要对关键事件做出响应，而且还需要确保没有事件发生的任何系统工程师，缺少指标通常是这样做的障碍。
但是，系统工程师通常不会深入研究代码，从而为公司赚钱。 他们需要领先的开发人员，他们必须了解系统工程师在发现问题，提高对性能问题的意识等方面的责任的重要性。
这件事
devop的心态描述了开发人员思维（dev）和开发（ops）的协同作用。 任何声称“从事开发活动”的公司应：
- 说出他们可能不做的事情（电影《公主新娘》中的模因暗示-“我不认为这意味着您的想法！”）
- 提升产品持续改进的地位。
如果您不知道产品当前的工作原理，就无法改进它，并且知道它已经得到了改进。 如果您不了解产品的工作原理，所依赖的服务，主要的难点和瓶颈，您将无法找到产品的工作方式。
除非您观察到潜在的瓶颈，否则在编写尸体剖析时不能遵循“五为什么”技术。 您无法在一个屏幕上收集所有内容来查看产品的工作原理或外观“正常且快乐”。
左移，左，我说，不，
对我而言，Devops的主要原则之一是“向左移”。 在这种情况下，向左转移表示在软件交付生命周期中向左转移执行系统工程师通常关心的功能的能力（
不是责任 ，而仅仅是能力），例如创建性能指标，更有效地使用日志等（软件交付生命周期）。
由NESS 由Makers在Unsplash上拍摄软件开发人员应该能够使用并了解公司用于监视其所有形式，指标，日志记录，监视界面的监视工具，最重要的是，
观察其产品在生产中的工作方式 。 您不能强迫开发人员花费时间和精力进行监视，直到他们可以看到指标并影响其外观，产品所有者在下一次简报会上如何展示其CTO等等。
简而言之
- 把马带到水里。 向开发人员展示他们可以避免多少问题，帮助他们为自己的应用程序确定正确的KPI和指标，从而减少产品所有者对CTO的吼叫。 将它们轻柔地，平静地暴露在光下。 如果无法解决问题，则贿赂，威胁和说服他们或产品所有者，以便从应用程序中快速获取这些指标，然后绘制图表。 这将是困难的，因为它不会被视为优先事项，并且将有许多创收项目正在产品路线图中等待实施。 因此，您将需要一个业务案例来证明在产品中实施监视所花费的时间和金钱是合理的。
- 帮助系统工程师获得充足的睡眠。 向他们表明，对任何产品使用发行发行清单都是不错的选择。 并且检查生产中的所有应用程序是否都包含指标，可以帮助您睡个好觉，让开发人员了解哪些有效，哪些无效。 但是，惹恼和烦扰任何开发人员，产品所有者和CTO的正确方法是将操纵杆推入车轮并抵抗。 如果您再等到最后一分钟，此行为将影响任何产品的发布日期，因此请再次左移并尽快将这些问题包括在项目计划中。 如有必要，请前往产品会议。 戴上假胡须和类似的东西，它永远不会失败。 报告您的问题，显示明显的好处，并进行宣教。
- 确保开发人员（dev）和操作人员（ops）都了解将产品指标移至红色区域的含义和后果。 不要将操作作为产品性能的唯一保护者；请确保开发人员也参与其中（#productsquads）。
- 日志是一件好事，但指标也是如此。 将它们结合起来，不要让您的原木变成巨大的徒劳无益的大火。 向开发人员说明并向他们展示为什么除了他们之外没有人会理解他们的日志，并告诉他们在凌晨3:15观看无用日志的感觉。
Marko Horvat在
Unsplash上
拍摄的照片
仅此而已。 新材料将于下周发布。 如果您想了解有关该课程的更多信息，我们邀请您参加
开放日 ，该
开放日将在星期一举行。 现在，传统上，我们一直在等待您的评论。