Kubernetes Ingress 日志分析与监控的最佳实践
摘要: Ingress主要提供HTTP层(7层)路由功能,是目前K8s中HTTP/HTTPS服务的主流暴露方式。为简化广大用户对于Ingress日志分析与监控的门槛,阿里云容器服务和日志服务将Ingress日志打通,只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。
前言
目前Kubernetes(K8s)已经真正地占领了容器编排市场,是默认的云无关计算抽象,越来越多的企业开始将服务构建在K8s集群上。在K8s中,组件通过Service对外暴露服务,常见的包括NodePort、LoadBalancer、Ingress等。其中Ingress主要提供HTTP层(7层)路由功能,相比TCP(4层)的负载均衡具备非常多的优势(路由规则更加灵活、支持金丝雀、蓝绿、A/B Test发布模式、SSL支持、日志、监控、支持自定义扩展等),是目前K8s中HTTP/HTTPS服务的主流暴露方式。
Ingress简介
K8s中Ingress只是一种API资源的声明,具体的实现需要安装对应的Ingress Controller,由Ingress Controller接管Ingress定义,将流量转发到对应的Service。目前Ingress Controller的实现有非常多种(具体可以参考Ingress Controller官方文档),比较流行的有Nginx、Traefik、Istio、Kong等,在国内接受度最高的是Nginx Ingress Controller。
日志与监控
日志和监控是所有Ingress Controller都会提供的基础功能,日志一般包括访问日志(Access Log)、控制日志(Controller Log)和错误日志(Error Log),监控主要从日志以及Controller中提取部分Metric信息。这些数据中访问日志的量级最大、信息最多、价值也最高,一般7层的访问日志包括:URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等,对于Ingress Controller这种转发型的日志,还包括转发的Service名、Service响应时间等额外信息。从这些信息中,我们能够分析出非常多的信息,例如:
- 网站访问的PV、UV;
- 访问的地域分布、设备端分布;
- 网站访问的错误比例;
- 后端服务的响应延迟;
- 不同URL访问分布。
我们的开发、运维、运营、安全等人员可以基于这些信息完成各自的需求,例如:
- 新老版本发布前后的数据指标对比;
- 网站质量监控、集群状态监控;
- 恶意攻击检测、反作弊;
- 网站访问量统计、广告转化率统计。
然而手动搭建、运维一整套的Ingress日志分析与监控系统非常复杂,系统所需要的模块有:
- 部署日志采集Agent并配置采集、解析规则;
- 由于K8s集群中,访问量相对较大,因此需要搭建一个缓冲队列,例如Redis、Kafka等;
- 部署实时数据分析引擎,例如Elastic Search、clickhouse等;
- 部署可视化组件并搭建报表,例如grafana、kibana等;
- 部署告警模块并配置告警规则,例如ElastAlert、alertmanager等。
阿里云日志服务Ingress解决方案
为简化广大用户对于Ingress日志分析与监控的门槛,阿里云容器服务和日志服务将Ingress日志打通(官方文档),只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。
Ingress可视化分析
日志服务默认为Ingress创建5个报表,分别是:Ingress概览、Ingress访问中心、Ingress监控中心、Ingress蓝绿发布监控中心、Ingress异常检测中心。不同角色的人员可根据需求使用不同的报表,同时每个报表均提供筛选框用于筛选特定的Service、URL、状态码等。所有的报表均基于日志服务提供的基础可视化组件实现,可根据公司实际场景进行定制化调整。
Ingress概览
Ingress概览报表主要展示当前Ingress的整体状态,主要包括以下几类信息:
- 整体架构状态(1天),包括:PV、UV、流量、响应延迟、移动端占比、错误比例等;
- 网站实时状态(1分钟),包括:PV、UV、成功率、5XX比例、平均延迟、P95/P99延迟等;
- 用户请求类信息(1天),包括:1天/7天访问PV对比、访问地域分布、TOP访问省份/城市、移动端占比、Android/IOS占比等;
- TOPURL统计(1小时),包括:访问TOP10、延迟TOP10、5XX错误TOP10、404错误TOP10。
Ingress访问中心
Ingress访问中心主要侧重于用于访问请求相关的统计信息,一般用于运营分析,包括:当日UV/PV、UV/PV分布、UV/PV趋势、TOP访问省份/城市、TOP访问浏览器、TOP访问IP、移动端占比、Android/IOS占比等。
Ingress监控中心
Ingress监控中心主要侧重于网站实时监控数据,一般用于实时监控与告警,包括:请求成功率、错误比例、5XX比例、请求未转发比例、平均延迟、P95/P99/P9999延迟、状态码分布、Ingress压力分布、Service访问TOP10、Service错误TOP10、Service延迟TOP10、Service流量TOP10等。
Ingress蓝绿发布监控中心
Ingress蓝绿发布监控中心主要用于版本发布时的实时监控与对比(版本前后对比以及蓝绿版本当前对比),以便在服务发布时快速检测异常并进行回滚。在该报表中需要选择进行对比的蓝绿版本(ServiceA和ServiceB),报表将根据选择动态显示蓝绿版本相关指标,包括:PV、5XX比例、成功率、平均延迟、P95/P99/P9999延迟、流量等。
Ingress异常检测中心
Ingress异常检测中心基于日志服务提供的机器学习算法,通过多种时序分析算法从Ingress的指标中自动检测异常点,提高问题发现的效率。
实时监控与告警
Ingress作为K8s网站请求的主要入口,实时监控与告警是必不可少的Ops手段之一。在日志服务上,基于上述的报表,只需3个简单的步骤即可完成告警的创建。下述示例为Ingress配置5XX比例的告警,告警每5分钟执行一次,当5XX比例超过1%时触发。
除了通用的告警功能外,日志服务还额外支持:
- 多维度数据关联,即通过多组SQL结果交叉判断进行告警,增加告警准确度;
- 除支持短信、语音、通知中心、email外,还支持钉钉机器人通知、自定义WebHook扩展;
- 告警的记录也以日志的形式记录,可以实现对告警失败进行告警的双保险。
订阅报告
日志服务除支持通过告警方式通知外,还支持报表订阅功能,可使用该功能将报表定期渲染成图片并通过邮件、钉钉群等方式发送。例如每天早上10点向运营群中发送昨日网站访问情况、每周发送报告到邮件组中存档、新版本发布时每5分钟发送一次监控报表...
自定义分析
如果容器服务Kubernetes版提供的默认报表无法满足你的分析需求,可以直接使用日志服务SQL、仪表盘等功能进行自定义的分析和可视化。
尝鲜
为了让大家可以体验Kubernetes审计日志功能,我们特别开通了体验中心,大家可以通过 https://promotion.aliyun.com/ntms/act/logdoclist.html 进入,该页面提供了非常多和Kubernetes相关的报表。
参考文档
[1]https://www.aliyun.com/product/sls
[2]https://www.aliyun.com/product/kubernetes
[3]https://help.aliyun.com/document_detail/86532.html
[4]https://help.aliyun.com/document_detail/48162.html
[5]https://help.aliyun.com/document_detail/107758.html
[6]https://kubernetes.io/docs/concepts/services-networking/ingress/
[7]https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
本文作者:jessie筱姜
本文为云栖社区原创内容,未经允许不得转载。
Kubernetes Ingress 日志分析与监控的最佳实践的更多相关文章
- Kubernetes Ingress日志分析入门
本文主要介绍如何基于日志服务构建Kubernetes Ingress日志分析平台,并提供一些简单的动手实验方便大家快速了解日志服务相关功能. 部署Ingress日志方案 登录容器服务管理控制台. 将上 ...
- Ingress 访问日志分析与监控
阿里云Ingress除了提供外部可访问的 URL.负载均衡.SSL.基于名称的虚拟主机外,还支持将所有用户的HTTP请求日志记录到标准输出中.同时Ingress访问日志与阿里云日志服务打通,您可以使用 ...
- paip.前端加载时间分析之道优化最佳实践
paip.前端加载时间分析之道优化最佳实践 1.另存为 ,查看文件尺寸..和图片. 2.view the 另存为的htm静态的文件单个的加载,看时间...可以排除编程语言的问题and 数据库.. ## ...
- Bug预防体系(上千bug分析后总结的最佳实践)
Bug预防体系(上千bug分析后总结的最佳实践) 原创 2017-08-16俞美玲 光荣之路 吴老的<selenium webdriver 实战宝典>出版了! web常见产品问题及预防 ...
- paip.前端载入时间分析之道优化最佳实践
paip.前端载入时间分析之道优化最佳实践 1.另存为 ,查看文件尺寸..和图片. 2.view the 另存为的htm静态的文件单个的载入,看时间...能够排除编程语言的问题and 数据库.. ## ...
- SpringMVC源码分析和一些常用最佳实践
前言 本文分两部分,第一部分剖析SpringMVC的源代码,看看一个请求响应是如何处理,第二部分主要介绍一些使用中的最佳实践,这些best practices有些比较common,有些比较tricky ...
- Docker监控:最佳实践以及cAdvisor和Prometheus监控工具的对比
在DockerCon EU 2015上,Brian Christner阐述了“Docker监控”的概况,分享了这方面的最佳实践和Docker stats API的指南,并对比了三个流行的监控方案:cA ...
- Java日志体系(八)最佳实践
java常用日志框架关系 Log4j 2与Log4j 1发生了很大的变化,Log4j 2不兼容Log4j 1. Logback必须配合Slf4j使用.由于Logback和Slf4j是同一个作者,其兼容 ...
- 敏捷遇上UML-需求分析及软件设计最佳实践(郑州站 2014-6-7)
邀请函: 尊敬的阁下:我们将在郑州为您奉献高端知识大餐,当敏捷遇上UML,会发生怎样的化学作用呢?首席专家张老师将会为您分享需求分析及软件设计方面的最佳实践,帮助您掌握敏捷.UML及两者相结合的实 ...
随机推荐
- day19 作业
今日作业 1.什么是对象?什么是类? 对象:特征和技能的结合体 类:一系列对象 相同的特征和技能的结合体 2.绑定方法的有什么特点 对象调用类内部的函数 称之为绑定方法,特点: 不同的对象调用该绑定方 ...
- 谈谈数据库sql编写
本文主要给初学者关于关系数库的一个浮光掠影式的介绍,如果想深入理解,必须对于下文提到的每个内容单独深入学习! it-information technology的简称,中文是信息机技术,信息其实就是数 ...
- non-identifying and identifying
An identifying relationship means that the child table cannot be uniquely identified without the par ...
- 粗浅看 Tomcat系统架构分析
原文出处: 吴士龙 http://www.importnew.com/21112.html Tomcat的结构很复杂,但是Tomcat也非常的模块化,找到了Tomcat最核心的模块,就抓住了Tomca ...
- Leetcode106. Construct Binary Tree from Inorder and Postorder Traversal中序后续构造二叉树
根据一棵树的中序遍历与后序遍历构造二叉树. 注意: 你可以假设树中没有重复的元素. 例如,给出 中序遍历 inorder = [9,3,15,20,7] 后序遍历 postorder = [9,15, ...
- 常见问题:MongoDB基础知识
常见问题:MongoDB基础知识 ·MongoDB支持哪些平台? ·MongoDB作为托管服务提供吗? ·集合(collection)与表(table)有何不同? ·如何创建数据库(database) ...
- [原创]iFPGA-Cable FT2232H Xilinx / Altera / Lattice 三合一JTAG & UART调试器-详细使用说明
iFPGA-Cable调试器使用说明 全文分为6部分: 第0部分:实物.连线及其驱动安装说明 第1部分:Xilinx JTAG 第2部分:UART 第3部分:Altera JTAG 第4部分:Latt ...
- JS---案例:无刷新评论---属于创建对象的案例拿出来复习
案例:无刷新评论---属于创建对象的案例拿出来复习 创建行和单元格,添加到相应元素中,设置内容 createElement, appendChild,innerHTML <!DOCTYPE ht ...
- java验证码识别
首先参考了csdn大佬的文章,但是写的不全ImgUtils类没有给出代码,无法进行了 写不完整就是制造垃圾 不过这个大佬又说这个大佬的文章值得参考于是又查看这篇文章 有案例https://blog.c ...
- 超高频率问题之信息: Illegal access: this web application instance has been stopped already. Could not load . The eventual following stack trace is caused by an error thrown for debugging purposes as well as
出现频率非常高,目前还不确定具体是什么原因导致