SRE & Devops & Architect

背景

公司前一段对业务线上的nginx做了整理，重点就是对nginx上负载均衡器的后端节点做健康检查。目前，nginx对后端节点健康检查的方式主要有3种，这里列出：

公司业务线上对后端节点的健康检查是通过nginx_upstream_check_module模块做的，这里我将分别介绍这三种实现方式以及之间的差异性。

目的

为什么要做日志分析平台？

随着业务量的增长，每天业务服务器将会产生上亿条的日志，单个日志文件达几个GB，这时我们发现用Linux自带工具，cat grep awk 分析越来越力不从心了，而且除了服务器日志，还有程序报错日志，分布在不同的服务器，查阅繁琐。

待解决的痛点:

1、大量不同种类的日志成为了运维人员的负担，不方便管理;

2、单个日志文件巨大，无法使用常用的文本工具分析，检索困难;

3、日志分布在多台不同的服务器上，业务一旦出现故障，需要一台台查看日志。

为了解决以上困扰: 接下来我们要一步步构建这个日志分析平台，架构图如下:

使用 python-gitlab 模块来调用gitlab的API来管理和操作gitlab。

参考

官方文档

目的

对常用的git命令进行汇总和注释，在使用时如需查询可更高效的查询到。

介绍

Pipeline，简而言之，就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。

Pipeline是Jenkins2.X的最核心的特性，帮助Jenkins实现从CI到CD与DevOps的转变。Pipeline是一组插件，让Jenkins可以实现持续交付管道的落地和实施。

持续交付管道（CD Pipeline）是将软件从版本控制阶段到交付给用户或客户的完整过程的自动化表现。软件的每一次更改（提交到源代码管理系统）都要经过一个复杂的过程才能被发布。

Pipeline提供了一组可扩展的工具，通过Pipeline Domain Specific Language（DSL）syntax可以达到Pipeline as Code（Jenkinsfile存储在项目的源代码库）的目的。

目的

根据自己多年的工作经历和经验，对日常中的细节技巧和用法进行归纳和总结。

持续更新中…

简介：

Dig是一个在类Unix命令行模式下查询DNS包括NS记录，A记录，MX记录等相关信息的工具。由于一直缺失
Dig man page文档，本文就权当一个dig使用向导吧。Dig的源码是ISC BIND大包的一部分，但是大多编译和安装Bind的文档都不把它包括在内，但是在linux系统下，它通常是某个包的一部分，在Gentoo下是bind-tools，在Redhat/Fedora下是 bind-utils，或者在Debian下是 dnsutils。
如果你要查找Bind的配置相关的信息，请详读参考文档。

看懂默认输出：最简单最常见的查询是查询一台主机，但是默认情况下，Dig的输出信息很详细。你可能不需要所有的输出，但是它确实值得知道。

目的

linux下文件有3个时间的，分别是atime,mtime,ctime。有些博友对这3个时间还是比较迷茫和困惑的，我整理了下，写下来希望对博友们有所帮助。

背景

在nginx中配置proxy_pass时，当在后面的url上加不加/，区别是如此的大呢。

如加上了/，相当于是绝对根路径，则nginx不会把location中匹配的路径部分代理走;

如果没有加/，则会把匹配的路径部分也给代理走。

介绍

zabbix支持的主要监控方式：

​ zabbix主要Agent，Trapper，SNMP，JMX，IPMI这几种监控方式，本文章主要通过监控理论和实际操作测试等方式来简单介绍这几种方式的监控原理和优缺点等 。下面对几种监控方式的监控原理进行介绍：