https://jenkins-zh.cn/tags/software-engineering/ Recent content in Software Engineering on Jenkins 中文社区 Hugo -- gohugo.io zh-CN Wed, 01 Jul 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-01-monitoring-linux-logs-with-kibana-and-rsyslog/ Wed, 01 Jul 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/07/2020-07-01-monitoring-linux-logs-with-kibana-and-rsyslog/ 如果你是一名系统管理员，或者是一名好奇的软件开发工程师，那么你很有可能在平常挖掘日志信息的时候找到一些很有价值的信息。 有时你或许想监控虚拟机的 SSH 指令。 有时你或许想查看下你的应用程序服务器在某一天某一个特定的时间出现了什么样的错误信息。 或者你为了想一探究竟到底是谁停了你的一个虚拟机的 systemd 服务。 如果你想从这几个地方了解的话，或许你来对地方了。 在这篇文章当中，我们将会构建一个完整的日志监控流水线，使用 ELK 堆栈（ElasticSearch、Logstash、和 Kibana）和 Rsyslog 作为一个强力的系统日志服务器。 在开始动手之前，让我们先快速的考虑下技术因素，让我们讨论下为什么我们使用 Kibana 监控 Linux 日志。 Ⅰ-为什么你需要监控 Linux 日志？ 监控 Linux 日志是非常关键的，而且每一名 DevOps 工程师都需要知道怎样做。理由如下: 你可以通过日志得到实时可视化的反馈: 这或许是众多日志监控理由中最关键的一个，你可以构建一些有意义的可视化视图（例如表格，饼状图，图表或者柱状图）来为你的日志赋予一些意义。 你可以汇总这些信息来构建高级以及复杂的仪表盘: 有时一个原始数据是不够的，你或许想加上一些其他的日志或者将它们与其他日志比较从而了解一个整体的变化趋势。一个具有表达式处理功能的可视化平台可以让你这样操作这些信息。 你可以快速过滤一个特定的术语或者是一个给定的时间段: 如果你只对 SSH 日志感兴趣，你可以为其构建一个指定的仪表盘。 以一种快捷和优雅的方式，日志是可导航的: 我知道从日志文件中无止尽的日志信息中抓取信息的痛苦。我宁愿有一个平台来专门做这件事。 Ⅱ- 你将会学习到什么 这篇入门文章你将会学习到下面的一些知识: 日志在 Linux 系统是如何处理的（Ubuntu 或 Debian）以及什么是 rsyslog。 怎样安装 ELK 堆栈（*ElasticSearch 7.2，LogStash 和 Kibana*）以及这些工具是用来做什么的。 怎样配置 rsyslog 从而将日志转发到 Logstash。 怎样配置 Logstash 从而获取日志以及 ElasticSearch 存储。 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/ Wed, 03 Jun 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/ 无论你是否是一名 Linux 系统管理员或是一名 DevOps 工程师，你都会在监控服务器性能指标的时候花费很长时间。 有时候实例运行非常慢但是哪里出的问题却没有任何线索。 有一些不响应的实例会阻止你在这些实例上执行类似 top 或者 htop 的远程命令。 服务器有一个瓶颈存在，但是你并不能简单快速的找到问题所在。 如果我们有一个完整的仪表盘可以帮助我们跟踪整体性能以及独立的进程该怎么操作？ 可以在该链接中实时查看: http://grafana.devconnected.com/d/nZMDMoiZk/grafana-top?orgId=1&refresh=5s 这篇入门文章旨在如何为 Linux 系统管理员创建一个完整的监控仪表盘 该仪表盘会展示完全可定制并且可扩展到分布式架构的多个实例的不同面板。 你将会学到什么 在即将踏入技术旅途之前，让我们快速看下通过阅读这篇文章你将学到哪些东西: 了解在 Unix 系统性能监控方面的最新技术； 怎样安装最新版本的 Prometheus v2.9.2、Pushgateway v0.8.0 以及 Grafana v6.2； 构建一个简单的 bash 脚本用来导出指标项到 Pushgateway； 构建一个完整的 Grafana 仪表盘包括最新的面板例如 ‘Gauge’ 和 ‘Bar Gauge’。 额外内容: 集成 ad-hoc 过滤器跟踪单个进程或实例。 现在我们大体浏览了一下我们将要学习哪些东西，并且没有进一步的要求，让我们介绍一些当前 Unix 系统中目前已有的内容。 Unix 进程监控基础 当提到 Unix 系统进程监控的时候，在你脑海中出现的有好几个选项。 最流行的或许就是 ‘top’ 了。 这个命令在系统管理员中间被广泛使用当系统出现性能瓶颈或许是第一条执行的命令（如果你可以访问它当然就是第一条！） top 命令可读性已经是非常好了，但是仍有一条命令比 top 命令可读性更好：htop。 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/ Mon, 01 Jun 2020 00:00:00 +0000 https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/ 我经常不得不说的 DevOps 神话之一就是 DevOps 完全是关于自动化和工具的。尽管二者是达到 DevOps 目标的基本要素（ DevOps 的目标是为了更快更安全地交付更有价值成果而优化从创意到价值实现的过程），但在 DevOps 的发展初期，Damon Edwards 和 John Willis 提出了 CALMS 这一缩写词来帮助解释有关 DevOps 的问题，其中字母 C 表示的文化也是一个重要元素。该想法得到了 Gartner 一篇文章的支持。该文章提到研究表明有 50％的受访者表示人的问题（与流程、技术和信息的问题相对）是目前采用 DevOps 原理和实践的最大障碍。我对自己客户的观察也支持这一想法，我的客户说文化是他们当下面临的最困难的挑战。 客户从一开始就这么说。大约七年前，当我们启动 Ranger4 的 DevOps 业务时，我们以为正在构建的是一个围绕软件和工具的业务。我们之前做么做过，并且这样做也是作为技术人员的合理选择。我们惊讶于客户一遍又一遍地问我们该如何改变文化。我们习惯于谈论技术；情感和感觉这些“软性”的东西是在饮水机旁闲谈的内容，或者用英式术语，说是酒吧里的话题。但是，当我们立即开始帮助客户后就迅速弄清了，文化可以被量化并文化生成的东西可以被确定。显而易见，文化本质上是行为，这很关键，因为我们意识到，可以使用一种在想到改变文化时常常令人感到莫名其妙的方式来影响行为，而文化这种模糊、多面的东西是很难理解的。 帮助组织采用 DevOps 原则意味着我们必须支持组织变革的推动者和领导者，帮助训练大量人力的大脑来理解和实践新的工作方式，从以项目为中心过渡到以产品、自治、价值流或链式思考以及跨职能、渐进式方法的重要转变。 工作做的越多，就越能意识到改变行为是核心，而其关键在于了解驱动行为的因素：我们的大脑。在过去的几年中，我发现神经科学在帮助组织变革上提供了大量指导。由于这是一门科学，是由数据驱动的，所以我们可以信任它。 关于我们都拥有的大脑的一些事实包括： 重 3 磅（体重的 2％） 使用人体内 20％的血液和氧气 干重的 60％是脂肪（那是相当多的） 100,000 英里的血管 2％的脱水时会影响认知能力 每分钟有一公升的血液流过大脑 人类的大脑与体重的比例是最大的 包含 860 亿个神经元 重要提示：如果您想了解更多有关大脑不同部位的信息，可以使用 Wellcome Trust 的交互式 3D 模型 AMAZE 。 关于神经元的一些事实： 它们使用电信号和化学信号相互沟通 神经元通过轴突链接产生神经回路 不同的回路执行不同的任务 一个神经元每秒可以传输 1,000 次神经冲动 大脑中有 10,000 种特定类型的神经元 脑信息以每小时 268 英里的速度传播 学习和不学习( unlearning ) 无一例外，我们客户都将努力从瀑布式过渡到敏捷作为业务和技术挑战核心。他们认识到自己正受到数字化的干扰。如果想要生存，能够蓬勃发展那更好，那么他们就需要在吞吐量和稳定性方面都能做得更好。但是，如果组织中的所有人（无论是 200 人还是 20,000 人）都接受过以项目为导向的工作方式的培训，资金也是以项目为导向，系统随着自身的发展而变成紧密耦合的整体，组织结构被孤立，组织中有负责变革咨询和发布管理团队，组织的工作被外包，技术发展滞后，那么组织中的人将很难改变自己的行为。实际上他们必须忘记（ unlearn ）多年甚至几十年已经学习到并坚信的东西。