九五至尊娱乐

当前位置: > 517888老品牌 >

APMCon 2017|58集团龚诚:构树立体化的监控系统-58团体监控实

发布时间:2018-01-10
APMCon 2017|58集团龚诚:构建平面化的监控体系-58集团监控实践

原题目:APMCon 2017|58集团龚诚:构建平面化的监控体系-58集团监控实践

APMCon 2017|58集团龚诚:构树立体化的监控系统-58集团监控实际

【转载】 作者:转载 

【文章简介】 

APMCon 2017|58集团龚诚:构建平面化的监控体系-58集团监控实践 ... ......  

中国应用性能管理行业盛宴-2017中国应用性能管理大会(简称APMCon 2017)于8月10日至11日在北京新云南皇冠沐日酒店盛大召开。本届APMCon是由听云、极客邦和InfoQ结合主办,作为国内APM范畴最具影响力的技术大会,本次大会以“驱动应用架构优化与翻新”为主题,努力于推进APM在海内的生长与开展。

58集团技术工程平台群高级技术司理-龚诚于APMCon 2017智能运维专场宣布了题为《构建破体化的监控体系-58集团监控实践》的演讲,现场解读了如何将运维数据停止量化和可视化,以及58集团在监控方面如何快速的构建起平面化的监控体系。

以下为演讲实录:

龚诚:首先欢送大家,我明天报告的标题是“构建平面化的监控体系-58集团监控实践”,主要讲一下我们58集团是如安在最近一年多时间内,从监控做的不是很好的状态,开展成为相对来说比较完美的状态的。

我们的监控任务实在可以划分为四个阶段:第一阶段,如何快速取得监控收益,最开端的时分监控的情况不是很好,所以要快速的完成基本的监控功能;第二阶段,构建平面化的监控体系,各个端、各个层面的监控都要比较完全和完善;第三阶段,提升监控系统用户体验,基本的功能都有了,怎样能让大家用的更爽呢,就是要提升用户体验;第四阶段,智能化监控和发送告警。

那么,我们为什么要做监控?监控的定位和目的是什么呢?

l 监控系统是线上效劳的守护神,是我们整个网站稳定性的一个重要的保证。

l 监控系统是技术人员的眼睛,帮助我们快速发现异常和排查这些毛病。

l 监控系统可以对运维的数据停止量化和可视化,便于对网站停止优化。

58团体监控体系的开展经由了如下多少个阶段:

一、如何快速失掉监控收益

这里先说下这些监控的痛点,我们最后面临的也是这些成绩:

l 监控系统数量非常多。由于各类汗青原因招致每个机房的网络运维、系统运维、应用运维、各个研发部门都有各自的监控系统。

l 告警数量非常多。天天运维人员可能要接收几百条的短信告警,这么大的告警数量对运维人员形成很多干扰。

l 告警覆盖度不敷,很多毛病发明不了。

l 监控添加起来非常繁琐,操作步调过于复杂。

l 难以帮助定位毛病,不能经过告警信息和监控数据快速定位毛病。

l 监控系统运转情况未知,没有运营数据的分析。

根据这些痛点我们整顿了一下对于监控的需求,主要分为两点:

1、监控业务模型

l 针对集群停止监控。晚期的很多开源监控系统是效劳器级别的监控,我们担任运维58集团上司的很多网站,包括58同城、赶集网、中华英才网、安居客、转转等网站,我们的效劳器数量是非常多的,为了管理方便,一定要以集群维度停止监控的管理。

l 支持模板和模板的继承。这么多效劳器的监控调整起来是很费事的,所以我们要求监控的模型一定要针对集群停止管理。监控战略绑定在集群层面上,不需要绑定到某一个机器,调零件器的时分可以不需要调整监控模板,极大的简化了监控信息的维护。

l 模板中包含多条监控战略。对于监控肯定有很多共同的需求,可以把这些需求都写在通用的模板里,然后用集群自己特性化的模板继承共用的父模板,这样既完成了大家共同的需求,每团体也不需要反复配置,也可以添加自己效劳特别的监控战略,这样很好的统筹了通用性和特性化。

l 支持告警组。在一个公司里总会有人员的变革,为了方便告警管理,可以将告警发送给告警组,告警组里可以配置用户,用户可以随时停止调剂,无效增加了监控的维护代价。

2、对监控系统的请求

l 高稳定性和散布式系统。监控系统是用来保证网站稳定性的,所以它本身的稳定性就必需要高,且存在很强的容错才能。

l 机能强盛,支持横向可扩大,无性能瓶颈。当我们的效劳器数量和业务范围增加的时分,可以简单经过横向扩展各模块的方式完成容量的提升,不需要对系统停止大规模的升级改革。

l 单个模块逻辑简略,方便二次开发。为了更好的支撑我们的业务,任何一个监控系统都需要根据我们自己的业务需求做一些定制化的开辟,那么它的二次开发能否方便就十分重要了。

基于后面提到的这几点,为了增加整个监控系统的开发周期,我们以现在业界比较风行的open-falcon为基础停止二次开发。

在第一阶段的任务中,首先我们将监控切换到open-falcon,它处理了以下三个主要成绩:

l 处理部分效劳器无监控的成绩,把很多套监控整合为一套,把一切系统层的监控、应用层的监控、网络层的监控完整整合起来,保证了效劳器级此外监控覆盖率。

l 处理告警发送数量过多的成绩,主要从两个方面:open-falcon自身就有比较好的告警数量控制的机制,可以支持定义告警最多发送次数,对异常做告警分级,对不同的告警以不同的方式来发送;也会针对不同重要性的异常停止判定,初期只针对最核心的集群发告警。

l 处理了告警接受人的成绩。在老的系统里,良多告警吸收人因为营业的变化,职员的变化曾经不是很正确了,这一块我们也从新停止了梳理和设置装备摆设。

其次,我们开发了“快速添加监控”的功能。在满足根本监控需求后,技术人员对于每个集群会有更多更特性化的监控需求。大家用过open-falcon可能有些领会,功能非常壮大,但是添加监控的流程还是很复杂的。首先要创建一个集群,然后在集群里绑定一些效劳器,再创建一个监控模板,然后在模板里创建很多监控战略,再创立一个告警组,告警组里加告警接收人,再把监控模板跟告警组关联起来,最后把集群和模板关联起来。基本上要经过十几个操作才干把一个集群的监控添加好,这个过程是比较复杂的,也是轻易犯错的。所以我们开发了快速添加监控的功能,很好的处理了上述成绩:

l 便于技术人员疾速添加监控,晋升了易用性和监控添加效力。

l 在一个页面增添集群名、机械列表、监控战略、告警接收人即实现告警增加。

l 可以自界说集群、监控模板、告警接收人。

l 对关键的集群都添加了系统层和应用层的监控,保证了关键效劳的稳定性。

接上去,我们完成了对集群自动添加监控。如果依靠大批的技术人员依附人工来添加监控功能的话,必定带来很多任务量,并且监控的覆盖度也无法保障,所以接上去做了自动的添加系统监控。具体做法如下:

l 从CMDB同步信息,为各集群主动添加基础监控。

l 一切集群的模板继续公共的系统监控模板。我们会根据独特的需求收拾一个公共的模板,基础的监控战略都配置在这个公共模板中,每个集群的监控模板都继承该公共模板。

l 告警信息发送给各集群对应的运维和研发担任人。

l 从自动部署系统同步端标语添加端口监控。

l 可自定义监控目标。在本集群的监控模板中可以添加很多自定义的监控目标,比如效劳QPS、订单量、用户量等只有能采集到的目标都可以停止监控。

另外我们在增强功能、提升易用性方面也做了很多任务,对于监控来说最关键的无非是以下几点:

l 监控配置:便利添加常用监控。

l 数据检查:便于检查监控数据、监控视图、监控墙。

l 告警检查:提供了多种告警的接收方式包括邮件、微信、短信和语音。

l 异常检查:方便检查以后有哪些异常,以及我接收告警的异常有哪些,这个功能方便大家倏地的晓得我担任的系统能否有成绩。

下面这些任务做好了之后,在监控方面曾经基础上可能满意大师的需要,为了让系统起到更年夜的感化,也更新了辅助文档帮助大家更好的应用咱们的系统,别的也会在公司的技巧开放日,以及去各个部分宣讲我们的监控系统。

二、构建平面化的监控体系

经过上图我们可以看到网站的通用架构。首先在机房内部有域名解析,它会让静态请求直接到机房停止访问,静态请求到CDN访问,机房外部有网络出口以及四层和七层的负载均衡设备,再到nginx和业务集群上。刚才做的监控任务主要在集群或许效劳器维度,对于整个用户端、机房出口端及四层、七层负载均衡设备上做的相对比较少,我们这个阶段就是主要完成这些任务。

纵向构建平面化的监控体制

上图右侧是集群和效劳器维度的监控,自底向上是网络层、效劳器层、系统层、应用层和业务层监控。对于收集层监控我们最关心的是网络装备有没有宕机、资源使用率和流量能否正常,以及内网和专线的效劳品质等;在效劳器层关怀机器能否宕机、能否无奈登岸或许能否有硬件毛病;系统层重要存眷资本使用率,例如CPU、内存、磁盘、网络等目标;应用层与运用顺序愈加相关了,比如端口、过程、接口状况、效劳QPS等一切与利用层顺序相关的目标都可以在这里停止监控;业务层是与具体的某项业务愈加相关了,比如说我是电商类型的网站,那么对于订单量、买卖量就会无比关注。

横向构建平面化的监控体系

再来看横向的监控,后面我们提到了比较粗略的通用网站架构图,我们把这些信息稍微细化一些,从左到右,首先是在机房内部对域名的解析。由于用户处于一个比较复杂的公网环境当中,所以用户访问过程中会碰到很多如DNS劫持、链路劫持等成绩,招致无法访问正常。对于CDN节点来说,也会出现一些跨运营商或许跨区域调度形成的访问速度较慢成绩。对于我们机房的网络出口,VIP能否正常也是需要我们监控的。在四层负载平衡设备上我们比较关心流量的变化,在七层负载均衡效劳上比较关心域名、集群维度的错误率(状态码)、呼应时间等目标的变化。再往右看,业务集群的监控跟纵向监控愈加相关了,关注集群和效劳器的维度。

基于上述的分析,我们在用户端监控对于一些重点页面的关键目标停止了监控,包括页面的首屏时间、全体加载时间、可用性等。这些目标能够赞助我们比较好的描写网站的用户休会是怎样样的。对于DNS劫持、链路劫持、页面访问较慢、访问错误等都停止了监控。

在机房网络出口端,首先会对VIP能否存活做监控,也会在业务层上针对关键页面或许关键接口从机房出口VIP长进行探测,这样可以比较明白的知道整个集群效劳所提供的效劳状态是如何的。因为是直接从机房网络出口停止探测的,所以它不会遭到公网效劳质量的影响,能够比较片面的评价从流量接入端到后端业务集群的效劳质量。另外也会对集群中的每台效劳器做页面和接口的监控,便于发现部分效劳器的异常。

在流量接入真个网络设备上可以监控流质变化,以及能否遭到攻打。另内在Nginx上可以针对域名维度、集群维度停止监控,评估域名和集群的可用性和呼应时间。

在业务端集群,监控的维度是针对于单机和集群的。单机的监控更像刚才提到的纵向监控,从网络层、效劳器层、系统层始终往上,还有针对效劳器的页面和接口监控。针对集群,一方面有经过机房的网络出口做的页面监控和接口监控,另一方面也会经过Nginx上的一些流量的变化看后端业务集群的运转状态,看它全体的可用性和呼应时间。

所以简单的总结一下,构建平面化的监控体系是从纵向和横向两个维度来完成的。

平面化监控体系构建完之后还要在监控的核心功能高低工夫,比如监控的添加、数据的检查、监控数据视图、告警检查、提供更好的功能以方便我们快速发现毛病、排查毛病、处理毛病。另外,我们也做了很多运营质量评价方面的任务,我们以为监控要做的一项比较重要的任务是使整个网站的运转信息通明化,原来没有监控的时分整个网站像一个黑盒子,哪个地方运转的好或不好、哪个处所是瓶颈我们都不清楚,经过监控系统可以把它由黑盒子变为白盒子,每部分的运转情况都清清晰楚,这样就知道哪部分出现的异常更多,哪部分是性能瓶颈,需要实时停止优化。我们运营质量评价分红了三个档次:

l 业务集群:在Nginx上看整个业务集群的效劳质量怎样样。

l 机房网络出口端:看流量经过TGW,Nginx和业务集群的整个进程的效劳质量。

l 用户端:以用户视角在公网情况看效劳的质量。

三、提升监控系统的用户体验

监控的基本功能都可用后,完善的用户体验就成了我们的重要目标。刚才也提到了open-falcon本身添加监控是比较复杂的,我们发现用户在使用的时分也会感到比较迷惑,添加监控、管理监控总会出现一些错误的情况,怎样办呢?

简化监控业务模子

之条件到过,open-falcon的监控模型是绝对比较庞杂的,如下图所示:

所以我们就对监控的业务模型停止了简化,一切监控的配置项都是与效劳树的节点也就是集群停止关系,集群是我们从CMDB里同步过去的,集群会关联效劳器列表,集群也会关联独一的监控模板,这个监控模板会继承公共的监控模板,就是说一些通用的监控项都曾经在外面设置好了。另外我们把之前关联在监控模板上的告警接收人直接关联到集群上,这样的话对于一个集群的监控只要要关注这三点:效劳器的列表、监控的模板和告警接收人。只要这三部分信息都设置准确了,那么这个监控的添加确定是没有成绩的,这样既满意了我们的需求又极大下降了复杂性。简化后的监控业务模型如下:

Web页面框架和效劳树模型

我们在监控系统Web界面的展示上提供了基于效劳树的展示模型。所谓效劳示范型是将公司全部集团上司的事业群、业务线、集群按照一个树型的构造停止组织。当你想操作某一个业务线或许某个集群的时分,取舍效劳树里这个节点就可以对它停止操作了。

另外我们的监控系统除了包含开源的open-falcon之外还有很多自研的系统,这么多系统怎样样更好的停止整合呢?若何统一全体的用户体验、页面的作风以及交互方式呢?如果上述方面统一的话,在用户看来进修的价格就会很小、易用性就会很好。所以,我们使用了一个统一的web框架,用户操作的时分,起首经过效劳树节点选择一个操作规模,然后经过菜单选择使用的功能,页面中就可以展示相关的业务信息了。如许就可以把用户使用监控系统的交互方式统一了。我们也对自研的监控相关联统做了整合,包括Nginx业务流量的监控、网络的监控、用户端监控、IDC出口以及运营质量数据等。

我们根据简化的监控业务模型开发了一套web的页面,如下图所示:

这个页面展示的是同一的web框架和效劳树模型:左侧是树型的结构,根节点是58集团,上面是各个事业群,再下一级节点是业务线,再下一级节点是集群;页面下面是一排菜单,每一项是一个一级菜单,当把鼠标放上去的时分会看到二、三级菜单。在左侧的效劳树上挑选效劳树节点相称于选择了一个业务的范畴,也就是要操作的是这块业务;在下面的菜单当选择某个菜单就是选择某个功能,两者都选中后,右侧就会显示出相关的业务页面,用户就可以完成相关的数据检查和治理操作了。

监控信息的管理

刚才提到过,管理监控需要关注三部分信息:

l 告警接收人:这里可以看到配置了哪些告警组,包括出现异常时发送告警的告警组,以及告警升级后的告警组。

l 监控模板和监控战略:经过这里可以看到,集群对应的模板是继承了一个公共的父模板,在父模板里定义了一些像残余磁盘空间、系统的负载、能否宕机等这些最基础、最重要的监控。另外,在这个集群的监控模板中可以根据它的需要去添加一些特性化的监控战略。

l 效劳器的列表:在效劳树外面搜寻某一个集群,效劳树上天然会把包括关健词的集群显示出来,选中这个集群直接可以看到这个集群的效劳器列表。当集群中的效劳器列表产生变化的时分,可以在这里增加机器或许删除机器,并且可以看到某台机器是不是被其余集群共用。

上述的信息对每个集群来说都自动添加了监控,只要保护好了每个集群的上述信息,就能够正常的告警了,经过这种方式极大的降低了监控的维护代价。

告警发送战略优化

我们在本来open-falcon的基本之上做的一点改良。我们对告警停止了分级,而且供给了多种方法发送告警,包含:邮件、微信、短信、语音,不同主要水平的告警采取不同的方式停止告诉。

open-falcon在异常告警的发送次数把持上做的仍是比拟好的,它可以节制发送告警的最屡次数,比方设置告警发送次数最多为3次,当告警发了3次之后就不会再发了,直到从异常中恢复了才发一条恢复畸形的告警。我们来看一个场景,假如前3条告警因为运营商成绩不收到或许担任人事先正在忙什么事把这个告警忘却了,这个异常要连续几天甚至几十天,那么对网站稳固性有很大的要挟,所以我们增添了告警进级和告警提供功效。

好比说我们设置的持续3次异常的时分再告警,两次告警时间距离5分钟,最多告警3次。我们结合上图看一下,蓝色的线是时间轴,底下的数字代表时光,绿色代表数据正常的点,白色代表数据异常的点,在前3分钟连续3次涌现了异常,所以它收回了第一条黄色的告警,5分钟之后发送了第二条,又过了5分钟又发送了第三条告警。按照之前的战略,这个告警如果不去向理的话,可能将来几天甚至几十天都不会发任何告警,我们这里增长了一个战略,在最后一条告警发送完之后30分钟后如果异常还存在则会把告警升级,且使用更显明的方式提醒用户。另外如果说这个毛病持续时间超越一天了,之后的每一天我们也会给再发告警提示一次。

以后异样信息的检查

以后异常信息的检查也是监控系统中非常重要的一项功能,下图就是该功能的页面,这里可以经过效劳树选择一个业务范围,选择检查整个公司的异常或许只检查某个业务线或许集群的异常。右侧还有“我的告警”选项,选中这个选项会看到一切与“我”相关的告警和异常,页面还可以根据设置自动刷新,这个功能对于运维值班和做系统巡检长短常有效的。

这个页面是展示确当前处于异常状态的告警,当它从异常状态恢复到正常之后这个信息就自动消散了。另内在这里也可以很方便的停止搜索,比如根据告警条件、异常类型甚至告警接收人停止搜索。

如下页面展示了比来的告警事情有哪些:

这个页面把每个告警事情作为一个圆圈展示出来,圆圈越大阐明告警级别越高,色彩越深代表告警次数越多,而且把鼠标放到某个圆圈上的时分能够看到某一个告警的概况。因为效劳有可能依附于一些存储效劳或依赖于他人的接口,所以当出现异常的时分,可以下去看一看是不是跟你相关的效劳在这个时间邻近也出现了异常,有可能因为它的异常惹起我们效劳的异常。

监控数据检查

监控数据的检查也是异常重要的一个功能,毛病时对异常起因停止排查、做完系统优化后比较后果、规划系统容量等操作都会用到这个功能。

用户操作界面如下图所示:

用户在使用该功能的时分,首先在左侧效劳树里选择事业群、业务线或许集群,在右侧会显示出来它对应节点下的机器列表,而且在下面可以对IP形式停止必定的搜索,经过右侧的常用目标选项可以快速选择我们平常常用的监控目标,比如概略、CPU、磁盘、IO等,这样就能够很方便的经过几回点击的方式看到一些罕见的视图。当然高等搜索可以满足愈加特性化的需求。点击看图按纽就能够看到相关的监控数据。

当然这些监控数据可能不仅是明天看一下,有可能平常任务傍边会经常检查的一些视图,可以在这外面点击生成视图按纽,天生视图并且收藏起来。那么下次直接在“我收藏的视图”中就可以快捷检查监控视图了,我生成的视图也可以被其他用户收藏和检查。

监控墙

我们把中心数据放到监控墙中展示,可以很方便的看到网站运转中最重要的一些数据。

容量管理

经过监控系统采集的效劳器的数据和业务相关的数据,也可以针对不同的容量、负载模型停止计算,得出每个集群、每个业务线相干的负载指数,经过雷达图可以展示各个分项目标,可以很好的计划容量,也可以在调配效劳器的时分无效的掌握效劳器本钱。

运营质量评价

在运营质量评价方面,我们可以针对业务集群维度、机房IDC出口维度、用户端维度停止评价。这个页面展示了集群的关键目标,可以看到某事业群上面的多个集群的呼应时间。

我的监控

对于大家平常常用的功能,都可以在这个菜单内找到,比如我收藏的视图、我担任的异常、我订阅的告警、我的集群和我的模板等。如下是拜访监控系统首页后默许展示的“我珍藏的视图”页面:

四、智能化的监控和告警信息

告警信息的兼并

l 同效劳器告警兼并。我们可以对统一个效劳器的告警停止兼并,因为如果一个效劳器宕机的话这个机器上肯定有其他的告警,只需要告知用户这个效劳器宕机就可以了。

l 同集群告警兼并。由于用户流量特殊大或许顺序出现某个bug,这个集群当中每一台效劳器都会出现告警,如果同时发几十条告警也是一种烦扰,所以我们对同一个集群的告警停止了兼并,直接发送一条告警。

l 同网段的宕机兼并告警。由于某个交换机出现了异常,肯定有同网络上的机器出现了大量的丢包告警新闻,其实这些告警兼并起来就可以推断出某个交流机网络设备出现了成绩。

l 同根因的告警兼并。当监控的笼罩度比较高的时分,对每一个层级城市有监控,如果一个集群呈现成绩就会在许多层级的监控诉警表现出来,这些成绩都是可以停止兼并的。

告警信息优化

l 提供更多的告警方式:对异常告警停止分级,增加语音告警和微信告警。

l 告警信息丰盛化:在微信告警中,可以展示更丰硕的信息。除文字外增加了很多监控目标相关的图片,能够直不雅看出异常数据的变化趋向。另外也增加很多链接,可以快速的经过点击这些链接修正相关配相信息。

l 异常的根因分析:需要我们逐步构建起运维的常识库揣度出来异常的本源原因。

新的监控战略

l 数据的同比环比监控:可停止趋向异常变更的告警跟数据对照展现。

l 数据的异常变化率监控:连续一段时间内数据出现突增和突降。

l 集群中异常机器比例监控:集群中超越一定比例的机器有成绩才发告警。

l 组合前提的告警:多个监控目标都知足条件则告警。

l 容量监控:猜测行将达到容量水位则告警。

毛病自愈

l 效劳器宕机自动处理:如果效劳器宕机,自动重启效劳器;如果效劳器出现硬件毛病可以经过效劳器的机型、对网络的需求等信息自动分装备机。

l 磁盘空间缺乏自动处理:经过一些告警事情触发自动删除一些预约义目次的文件。

l 负载降低自动扩容:当集群负载降低,到达警惕值后自动挪用安排管理系统和云平台,自动对系统做扩容。

l 流量自动调剂:当某个机房或网段出现成绩时,操作TGW和Nginx停止流量调度。

我今天性享的内容就是这些,感谢大家!

QA:

成绩:Nginx的日志监控是怎样做的?

龚诚:使用ELK将Nginx日记实时传输和盘算,再把数据及时灌到open-falcon里,经过open-falcon做数据展示和告警。当初正在从ELK迁徙到storm。

成绩:对症结业务的要害接口,这些接口监控是在Nginx日志里分析还是要求接口做的?

龚诚:两方面都有,我们会实时候析nginx日志,也会实时对接口发送恳求停止监测。

成绩:监控DNS劫持和用户翻开页面体验好欠好的监控是怎样做的?

龚诚:经过听云在全国各区域各经营商的探针采集数据,而后将原始数据拉回来本人做剖析,再停止数据展示和告警。

成绩:我想问怎样做紧缩告警,由于我们的日志有可能发生大量的error,如果1分钟内有100个A错误、1个B错误,又有100个C错误,幻想的状态是收到三条告警。现在我们是经过一个case来断定次数的,但是这个次数没有做智能压缩的,只能是一分钟收到几多条就压缩为一条,然而不克不及把不同的错误分级别收回来,你这一块是怎样做的?

龚诚:这个是具体完成层面上的事件,告警能够按照不同业务需求停止完成,须要详细成绩详细分析。方才你说的情形是依据错误的类型对告警数目停止兼并,你可以每分钟对这些错误的数据依照错误类型停止兼并,失掉A毛病100次、B错误1次、C过错100次,然后将这3个信息使用不同的监控目标推给监控系统,对不同的目标设置分歧的告警战略和级别,就可以完成对不同错误类型做告警分级。

成绩:是我们自己研发回是用第三方比较好,因为开源东西包括小米的还是其它都完成不了。

龚诚:要把自己的需乞降开源系统较好的结合起来,开源监控系统完成的都是通用的模型和功能,自己的业务要抉择一个好的方式和开源系统联合起来。跟自己业务和需求相关的部门,要自己控制这局部逻辑,把数据处置成尺度格局后,再推给监控系统,使用开源的系统来处理。

上一篇:没有了

下一篇:没有了

相关文章