ELK系统一分配析Nginx日志并对数据进行可视化体现

利用 ELK系统分析Nginx日志并对数据进行可视化展示,elknginx

作者:飞走不可

利用NextCloud配置私有云,nextcloud私有云

80%时间在灭火,普通工程师如何摆脱重复劳动?,80%灭火

阿里妹导读:自从无人化运维离我们有多远?阿里智能化运帷平台深度揭秘文章发布以来,就引来了众多运维从业者的关注,大家不禁思考,无人化运维离我们有多远?我们如何成为运维领域的专家,不被淘汰?阿里巴巴运维中台技术专家宋意,整合了阿里云效2.0运维产品StarOps,与你分享如何利用工具把人从日常重复工作中解脱出来,向专业垂直领域纵深发展,逐步成长为领域专家。

从传统运维OD分离转型到新型运维DevOps,不是简单把运维丢给开发就可以了,需要先把运维的工作工具化,实现开发可以利用工具自助完成,DevOps强依赖运维工具的支持。工具的落地也不是一蹴而就的,需要结合企业实际情况逐步建设,第一步先完成标准化,如Java类应用一套标准、PHP类应用一套标准,标准化之后才能使用工具自动化,智能化的核心是数据,自动化沉淀了数据才能做智能化,三步需要逐一实现。

StarOps

云效2.0涵盖项目协作域、研发域、测试域、运维域,为企业提供一站式研发协同服务。其中运维域由StarOps负责。StarOps定位一站式运维平台,资源、配置、部署、监控、运行,覆盖应用运维完整生命周期,具备基于混合云的应用运维无人值守解决方案以及自动化、数据化、智能化应用运维解决方案。阿里在运维领域沉淀多年的专家经验和能力全部集成于此,目标是通过平台使用户直接拥有运维专家的能力。

产品体系由八部分构成:CMDB、发布、监控、堡垒机、主机运维、故障管理、运维大屏、运维通道。不管公有云、专有云还是两者的混合云,通过运维通道屏蔽底层环境差异,实现上层应用运维统一管控。

运维通道

运维管控通道是服务器自动化运维的基础,所有操作最终都需要落地到服务器上执行,可以细分为三块:

  1. 命令通道:向服务器下发命令并执行,如ssh $ip $cmd
  2. 文件通道:把文件分发到服务器上,如scp/rsync/wget
    3. 数据通道:解决数据上行问题,如在脚本或命令执行完成后回调一个地址上报结果。

在服务器规模较小时,用上面提到的方法一般可以满足需求,不过随着规模的增涨,对安全、效率、稳定都会提出更严格的要求。用SSH通道时需要打通一台机器到所有服务器的认证,如果这台机器被黑客拿下向所有机器下发rm -rf,后果可想而知。

阿里自研的运维通道支持百万级规模服务器管控,支持二层/三层架构与容灾部署,1分钟可以操作50万台服务器,在内部每天有上亿次的调用,安全方面全链路加密签名、支持账号级别的命令映射,Agent经过淘宝、天猫、支付宝、阿里云等阿里生产环境业务真实验证,稳定性、安全性可以得到有效保证。运维通道与CMDB可以形成联动,实现数据的自动采集,保证CMDB数据的准确性与一致性。

CMDB

CMDB是运维的元数据中心,拥有绝对权威性,一个公司只能有一份。保存的数据有两个特点:被大部分运维场景依赖、相对静态一次维护多次消费,在阿里内部实践中数据归为两大类:

第一类:资源信息

传统资源有服务器、网络设备、IP段等,每种资源又有很多属性,如服务器的属性:SN、IP、主机名、OS、机房、机架、CPU、内存等,对于一台物理机而言SN、CPU、内存基本是永远不变的,OS可以随时重装,搬迁后机房信息也会变掉。使用云后资源类型又有OSS、RDS、SLB等,云资源的生产、销毁等管理操作也会集成进来。属性的变更应当通过外部系统或流程自动化触发,如OS信息应由装机系统维护更新、机房信息只能通过搬迁流程修改。

第二类:业务拓扑

也叫产品线,体现的是业务组织方式,例:BU/事业部->业务架构域->产品->应用,可以一级也可以多级,根据业务规模灵活调整。应用也有非常多的属性,像状态、等级、owner、开发负责人、运维负责人、代码库、开发语言等。多级时最上级一般与组织架构对应,增加子节点需要上一级审批。

CMDB保存着完整的资源与业务拓扑信息,通过资源与业务的关系,可以清晰了解各个业务使用的资源信息,资源属性信息再开放到其它系统消费,当拥有完善的基础信息后,基于场景的运维将会非常方便,例:

  1. 把服务器监控项配置在产品或应用上,新增服务器将默认拥有监控。
  2. 通过业务拓扑中的应用开发负责人判断谁有权限进行发布。
  3. 服务器默认为运维负责人授权,其它人登录需要运维审批。

发布

互联网时代产品迭代速度直接决定产品竞争力,最近有机会接触一些传统企业,运维几乎都是贴身为开发服务,发布按开发写好的文档一步一步操作,只是作为操作工毫无价值与成就感可言。

几年前在支付宝的时候发布也很痛苦,发布窗口提前几个月规划好,基本一个月一次,发布日当天一大早到公司,确认系统owner到位后开始发布,每个应用做完beta发布都要群里吼声,由owner确认后才能继续发,最怕发到一半出意外回滚,因为应用之间有先后依赖回滚就是整个链路,从早发到晚是常态,真心体力活。

从一月一次到一周一次,再到现在几乎开发随时想发就发(核心系统还是要控制发布节奏),发布系统与业务系统一起持续完善优化才有的今天,随时可以发使得业务需求可以快速上线,线上缺陷能够得到及时修复,有效提升交付效率。

发布模式有很多,如蓝绿发布、滚动发布、灰度发布等,这里不再对名词做解释,采用哪种模式与公司实际情况有直接关系,但不管哪种模式背后解决的问题都是不要出故障,即使有也要将影响控制在最小。

目前大部分发布工具解决的是把应用包发到线上的问题,不要出故障基本靠人为登机器查日志或者看监控。不过人工检查难免会遗漏,或者有时候过于自信觉得改动小肯定不会有问题,最终可能还是产生了故障。所以我们目前正在做无人值守发布。当一台机器发布完成后自动关联分析监控数据,包括基础监控(cpu/mem/load)、应用监控(jvm)、中间件监控、业务监控,如果检测到明显异常则直接拦截停止发布,在监控项足够完善、数据足够准确情况下无人值守发布完全可以做到人工零介入,提交代码自动测试、自动发布,相信这一天很快就会到来。

阿里的发布系统在内部能够支撑日均10万发布量,可灵活定义发布流程满足个性化部署需求, java、nodejs、python、php等多种技术栈的自动化发布我们都能够支持,通过无人值守、发布自愈等智能化发布部署能力保证代码变更安全,有效降低线上故障。

监控

监控作为线上运行的“眼睛”,能帮助业务快速发现问题、定位问题、分析问题、解决问题,为线上系统可用率提供有力保障,通过利用率数据的分析,帮助业务精准控制运维成本。

支付宝在2010年监控采用的开源软件nagios cacti,随着业务的不断扩张服务器越来越多,监控项调度延迟越来越严重,调高检测频率、换最高配物理机、把多台nagios组成集群、对nagios深度调优等还是无法支撑业务的发展,加上开源软件对应用以及业务监控的缺失,所以最后不得不走上自研的道路。

阿里的监控规模早已达到千万量级的监控项,PB级的监控数据,亿级的报警通知,基于数据挖掘、机器学习等技术的智能化监控将会越来越重要。监控系统是一整套海量日志实时分析解决方案,以日志、REST 接口、Shell 脚本等作为数据采集来源,提供设备、应用、业务等各种视角的监控能力,利用文件传输、流式计算、分布式文件存储、数据可视化、数据建模等技术,提供实时、智能、可定制、多视角、全方位的监控体系。主要优势:

1. 全方位实时监控:提供设备、应用、业务等各种视角的监控能力,关键指标秒级、普通指标分钟级,高可靠、高时效、低延迟。
2. 灵活的报警规则:可根据业务特征、时间段、重要程度等维度设置报警规则,实现不误报、不漏报。

  1. 管理简单:分钟级万台设备的监控部署能力,故障自动恢复,集群可伸缩。
    4. 自定义便捷配置:丰富的自定义产品配置功能,便捷、高效的完成产品配置、报警配置。
  2. 可视化:丰富的可视化 Dashboard,帮助您定制个性化的监控大盘。
    6. 低资源占用:在完成大量监控数据可靠传输的同时,保证对宿主机的CPU、内存等资源极低占用率。

主机运维

服务器单机操作、批量操作、系统配置的管理,我们把服务器日常运维操作全部集中在此,功能包括:

1. WEB终端:独创WEB终端可嵌入任何Portal,多种安全加密机制实现免SSH一键登录服务器,提升日常运维效率。
2. 文件分发:月均10亿次分发量,服务稳定性99.9999%;具备断点续传、动态压缩、智能IO流控等超强能力;同时在容器镜像层级预热,超大文件分发,窄带、跨洋、远距离传输方面具备世界级竞争力。
3. 定时任务:最小粒度支持秒级且支持随机,避免同一时间集中执行影响业务。支持按集群配置定时任务,新扩容服务器默认自动添加。
4. 插件平台:统一管控服务器的通用运维脚本及Agent,支持自动安装、自动升级、进程守护。

堡垒机

堡垒机是进入生产环境的第一道屏障,阿里自主研发的专业级堡垒机系统,实现了集中访问控制、多因子验证、边界管控、操作实时记录、过程录屏、容灾容错、高危审计、命令阻断等功能,实现对人员操作过程的全面跟踪、控制、记录、回放;符合安全审计,合规,政审,认证等要求,广泛应用于阿里集团各业务生产管理(含阿里云、蚂蚁金服)。产品特点:

1. 专业级堡垒机,满足访问集中管控,运维操作命令记录、过程录屏,高危命令识别与拦截阻断等,满足对于生产网用户操作行为监测与审计需求。
2. 软件部署简单灵活,无硬件依赖,达5000人同时在线高承载,超强合规保障,符合美国上市企业SOX404审计要求和ISO27001信息安全认证要求。

故障管理

IT变更与事件管理,与运维平台天然打通,监控异常事件可一键转工单跟进,主要功能:

1. 事件:支撑客户、内部反馈线上业务异常,技术支持跟踪、处理、解决的流程支持和管理。

  1. 故障:线上故障进行记录、通报,并记录review内容及改进措施。
  2. 问题:故障Action或需要长期解决的问题跟踪,可以与评审流程联动。

运维大屏

综合CMDB、监控等数据,为企业提供定制可视化大屏服务,以大屏的方式在指挥中心展示业务运行状态,辅助指挥决策,大屏也是运维自动化效果展示的最佳窗口。

点击文末“阅读原文”,可了解更多“云效”信息。在日常工作中,你有哪些工具或方法,可减少重复劳动、提升效率?欢迎在留言区一起交流~

你可能还喜欢

点击下方图片即可阅读

阿里工程师的买房装修记

双11备战核武器:全链路压测

阿里又开源了一项自研核心技术!

关注「阿里技术」

把握前沿技术脉搏

一、写在前面

结合之前写的一篇文章:Centos7 之安装Logstash ELK stack 日志管理系统,上篇文章主要讲了监控软件的作用以及部署方法。而这篇文章介绍的是单独监控nginx 日志分析再进行可视化图形展示,并在用户前端使用nginx 来代理kibana的请求响应,访问权限方面暂时使用HTTP 基本认证加密用户登录。(关于elk权限控制,我所了解的还有一种方式-Shield),等以后有时间了去搞下。下面开始正文吧。。。

注意:环境默认和上一篇大致一样,默认安装好了E、L、K、3个软件即可。当然了,还有必需的java环境JDK

开始之前,请允许我插入一张图,来自线上我的测试图:(如果有需要的童鞋,可以私信我,我可以把登录帐号给你。。)

备注:由于阿里云主机已经删除,无法提供试看了哈。

nginx日志文件其中一行:

218.75.177.193 - - [03/Sep/2016:03:34:06  0800] "POST /newRelease/everyoneLearnAjax HTTP/1.1" 200 370 "http://www.xxxxx.com/" 
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36" "36.22.6.130"

nginx 服务器日志的log_format格式:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

利用NextCloud配置私有云

  • 利用NextCloud配置私有云
    • 安装MariaDB
    • 为NextCloud创建数据库和用户
    • 安装PHP和相关模块
    • 下载NextCloud
    • 安装配置Nginx
    • 完成安装

NextCloud () 是开源云盘服务器,此处利用 LEMP 搭建 NextCloud 运行环境-MariaDB, PHP-FPM 和 Nginx (Ubuntu 16.04)

二、配置logstash

1.修改配置文件,/etc/logstash/conf.d下。创建一个新的配置文件,内容如下:

 View Code

文件内容大致解释:

Logstash 分为 Input、Output、Filter、Codec 等多种plugins。
Input:数据的输入源也支持多种插件,如elk官网的beats、file、graphite、http、kafka、redis、exec等等等、、、
Output:数据的输出目的也支持多种插件,如本文的elasticsearch,当然这可能也是最常用的一种输出。以及exec、stdout终端、graphite、http、zabbix、nagios、redmine等等、、、
Filter:使用过滤器根据日志事件的特征,对数据事件进行处理过滤后,在输出。支持grok、date、geoip、mutate、ruby、json、kv、csv、checksum、dns、drop、xml等等、、
Codec:编码插件,改变事件数据的表示方式,它可以作为对输入或输出运行该过滤。和其它产品结合,如rubydebug、graphite、fluent、nmap等等。
具体以上插件的细节可以去官网,介绍的挺详细的。下面说下该篇中的配置文件的含义:

来源:飞走不可-原文http://www.cnblogs.com/hanyifeng/p/5857875.html

input段:
file:使用file 作为输入源
path: 日志的路径,支持/var/log*.log,及[ “/var/log/messages”, “/var/log/*.log” ] 格式
start_position: 从文件的开始读取事件。另外还有end参数
ignore_older: 忽略早于24小时(默认值86400)的日志,设为0,即关闭该功能,以防止文件中的事件由于是早期的被logstash所忽略。

filter段:
grok:数据结构化转换工具
match:匹配条件格式,将nginx日志作为message变量,并应用grok条件NGINXACCESS进行转换
geoip:该过滤器从geoip中匹配ip字段,显示该ip的地理位置
source:ip来源字段,这里我们选择的是日志文件中的最后一个字段,如果你的是默认的nginx日志,选择第一个字段即可(注:这里写的字段是/opt/logstash/patterns/nginx 里面定义转换后的)
target:指定插入的logstash字断目标存储为geoip
database:geoip数据库的存放路径
add_field: 增加的字段,坐标经度
add_field: 增加的字段,坐标纬度
mutate: 数据的修改、删除、类型转换
convert: 将坐标转为float类型
convert: http的响应代码字段转换成 int
convert: http的传输字节转换成int
replace: 替换一个字段
remove_field: 移除message 的内容,因为数据已经过滤了一份,这里不必在用到该字段了。不然会相当于存两份
date: 时间处理,该插件很实用,主要是用你日志文件中事件的事件来对timestamp进行转换,导入老的数据必备!在这里曾让我困惑了很久哦。别再掉坑了
match:匹配到timestamp字段后,修改格式为dd/MMM/yyyy:HH:mm:ss Z
mutate:数据修改
remove_field: 移除timestamp字段。

output段:
elasticsearch:输出到es中
host: es的主机ip+端口或者es 的FQDN+端口
index: 为日志创建索引logstash-nginx-access-*,这里也就是kibana那里添加索引时的名称

2.创建logstash配置文件之后,我们还要去建立grok使用的表达式,因为logstash 的配置文件里定义的使用转换格式语法,先去logstash的安装目录,默认安装位置:/opt/logstash/下,在该位置创建一个目录patterns:

[email protected] ~]# mkdir -pv /opt/logstash/patterns
mkdir: created directory ‘/opt/logstash/patterns’

在该目录下创建格式文件,内容如下:

[[email protected] ~]# cat /opt/logstash/patterns/nginx
NGUSERNAME [a-zA-Z.@- _%] 
NGUSER %{NGUSERNAME}
NGINXACCESS %{IPORHOST:clientip} - %{NOTSPACE:remote_user} [%{HTTPDATE:timestamp}] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest})" %{NUMBER:response} (?:%{NUMBER:bytes}|-) %{QS:referrer} %{QS:agent} "%{IPV4:http_x_forwarded_for}"

注:该格式的最后有一个http_x_forwarded_for,因为我们日志是启用了cdn代理的。日志的第一段都是cdn的,最后一段才是真正客户的ip。

需要分析的nginx日志路径不在默认的位置,所以我根据logstash 的配置,建个目录先,并将日志文件拷贝进去:

[[email protected] ~]# mkdir -pv /data/nginx-logs/
[[email protected] ~]# ll /data/nginx-logs/
total 123476
-rw-r--r-- 1 nginx adm  126430102 Sep  9 16:02 access.log

3.然后就是logstash中配置的GeoIP的数据库解析ip了,这里是用了开源的ip数据源,用来分析客户端的ip归属地。官网在这里:MAXMIND

先把库下载到本地:

[[email protected] ~]# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

解压到当前路径,并将它移动到上述我们配置的路径下,当然其它路径也是可以的,不过logstash 的配置文件也需要更改,如下:

[[email protected] ~]# gzip -d GeoLiteCity.dat.gz
[[email protected] ~]# mv GeoLiteCity.dat /etc/logstash/.

测试下logstash 的配置文件吧,使用它自带的命令去测试,如下:

[[email protected] ~]# /opt/logstash/bin/logstash -t -f /etc/logstash/conf.d/nginx_access.conf
Configuration OK

注:-t -f 参数顺序不能乱,格式就是定死的,-f 后面要跟配置文件;还有就是该测试只能测试语法,标点符号。如果逻辑上有错误的话,还是能启动的。这里就需要在正式启动运行时,多关注日志文件,位置:/var/log/logstash/logstash.log

1. 安装MariaDB

Ubuntu 16.04 安装 MariaDB

更新升级系统:

$ sudo apt update
$ sudo apt upgrade

安装MariaDB:

$ sudo apt install mariadb-server

启动MariaDB服务:

$ sudo systemctl start mysql

查看状态:

$ sudo systemctl status mysql

执行初始化安全脚本,默认root密码为空,设置root密码和其他选项:

$ sudo mysql_secure_installation

本文由ca88手机版登录发布于亚洲城官网,转载请注明出处:ELK系统一分配析Nginx日志并对数据进行可视化体现

TAG标签: ca88手机版登录
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。