kibana监控告警,kibana监控logstash

点我达分布式任务调度系统-DaJob

背景

随着互联网的发展，应用服务中的定时任务数量日益增加，常规的垂直应用架构已无法应对，分布式服务架构势在必行。同时，也迫切需要一个分布式任务调度系统来管理分布式服务中的定时任务。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，在该应用中的定时任务如果不多还好，但是一旦比较多，则意味着每次更改一个定时任务的执行时间，就需要重新部署一遍整个应用，导致整个应用停滞一段时间。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分为互不相干的几个应用来提升效率。此时，相应的任务也会被垂直拆分，每次更改任务带来的影响相应减少。

分布式服务架构

当垂直应用越来越多，应用之间可能会出现不可避免的交互，此时，将核心业务抽取出来，形成单独的服务，各式各样的服务逐渐形成稳定的服务中心，使得前端应用能更快地响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架是关键，同时，由于服务独立，则一般能做到定时任务独立的情况，因此，任务的更改对于整体系统的影响小之又小。

分布式任务调度

在分布式服务架构的基础上，由于独立业务的数量可能很多，此时如果定时任务单独在该服务中实现，很可能会出现难以管理的情况，且避免不了定时任务更改导致的业务重启，因此，一个独立的分布式任务调度系统是很必要的，可以用来全局统筹管理所有的定时任务，同时，将任务的配置单独抽离出来作为该分布式任务调度系统的功能，就能做到定时任务的更改不影响任何业务，也不影响整个系统。

架构设计

设计思想

以Dubbo核心，将调度单独抽象出来，成为一个调度中心，调度中心本身不承担实现任何业务逻辑，只是单纯依据调度配置来发起调度请求

将任务抽象成为ExecutorService，由任务执行者来实现具体的任务，并且负责接收调度请求并执行，这样设计可以将任务与调度中心完全解耦，提高整个系统的扩展性，方便接入

将调度中心对任务执行者的一些调用操作提取出来，形成一个单独的管理控制台，可以用来查看任务执行情况，同时该管理控制台通过H5实现，并提供对外Restful API，方便扩展与接入

通过各种中间件，实现一些必须的操作，例如告警，监控，日志收集统计等操作，完全对整个系统安全性，稳定性的保障

调度中心集群通过Zookeeper存储每个Schedular的一致性HashCode，以此来分配Job与Schedular之间的关系：新增的Job将会通过每个Schedular的一致性HashCode获取其对应的Job数，依据Job数的大小以及Schedular的相关属性来计算每个Schedular的权重，根据权重的大小来确定当前新增的Job应该被分配到哪个Schedular上。

当新增Schedular之后，该新增的Schedular的Job正常为0，因此，正常状态下，该新增的Schedular的权重会比较大。

同时，调度中心通过Zookeeper对Schedular实现主备切换，确保系统稳定性

系统组成

Schedular

基于Quartz实现调度，提供对执行者操作的接口，用于操作任务调度配置，调度触发等操作;自身不参与任务逻辑的实现，不会受限于任务

执行者

负责接收调度中心发起的调度请求，实现相应业务逻辑，完成任务执行，同时会对任务逻辑进行切面处理，记录相应日志并在任务结束后发送给调度中心

管理控制台

管理控制台负责展示任务状态，执行情况，任务执行日志等报表数据，同时可以通过管理控制台配置新增任务，操作任务的状态，暂停/恢复等;另外，提供对外Restful API与H5的接入

Dubbo Monitor

实时监控调度中心接口调用情况，统计调度频次，成功失败，QPS等，能通过这些报表数据来优化任务调度，优化系统

ELK

通过ELK（ElasticSearch+Logstash+Kibana）来收集调度中心以及各执行机的执行日志，并加以分析统计，形成报表，可以方便提供观察

Alarm

报警系统，通过Chronograf控制台配置告警规则，在出现问题时第一时间通过Kapacitor进行邮件与短信报警，可以有效提高错误提示的及时性并且降低错误发生到错误解决过程中消耗的时间，降低生产环境造成的损失，告警数据通过业务仪表盘获取。例如：可以配置线上机器的cpu当前使用率，设置阀值50%，策略为超过设置阀值时短信告警，此时当线上某台机器cpu超过50%时，即会发送短信告警

业务仪表盘

通过打点的方式，来实时收集接口监控数据，通过logstash传输到kafka，通过kafka再分发到jstorm进行处理，处理完之后再存储到influxdb，形成业务仪表盘，最后通过Grafana控制台产生监控报表

配置中心

整个系统各服务，通过配置中心统一管理相应配置，形成分布式配置管理机制，方便系统内各服务的配置一致性以及准确性

在配置完之后，就可以实现自己的任务逻辑了

接入之后，可以通过日志管理控制台线上实时查看任务执行状态

另外，由于有告警系统，在任务执行异常时，会产生告警邮件与短信，实时发送，告知任务接入者与相应研发人员

配置中心属性配置

特性

支持动态暂停/恢复任务

任务状态停止时，任务将不再被触发，若任务在执行过程中被暂停，则正在执行的任务不会被阻塞（由于任务执行结果状态中存在超时失败状态，因此如果点击暂停按钮时阻塞了当前正在执行的任务，会使当前任务的执行状态变为超时，不符合超时状态真正的意义），会延迟停止，即等到当前任务执行完再真正停止任务

调度中心基于Quartz实现，通过Zookeeper实现主备隔离，保证调度中心HA

当活跃节点宕机，冷备节点就会载入所有活跃节点中正在调度状态的任务，成为新的活跃节点，保证任务调度的准确执行

执行机支持集群部署，任务分布式执行，通过调度中心统一调度

执行机负载均衡，默认根据任务在某个执行机上的执行次数计算执行机调度权重，按照权重来选择本次任务调度分发给哪台执行机，实现负载均衡，可手动更改执行机选择策略

执行机集群方式,

failover,failfast,failsafe,failback,forking，默认为failover(故障切换)，调用失败时，重试其他服务器;failfast(快速失败)，只会发起一次调用，不会重试，失败立即报错;failsafe(失败安全)，出现异常时，直接忽略;failback(失败恢复)，调用失败时，定时重发，直到成功，重启会丢失; forking，并行调用多个执行机，只要一个成功即返回

分片任务，支持任务分片，通过参数发送给任务执行机，执行机可以通过判断参数来进行分片作业的开发，同时支持动态分片，以分片参数和执行机为纬度进行分片，支持动态扩容执行机以及分片参数

例如，某张订单表按照订单ID来进行简单纬度分片，且以取模3来进行分片，则可以设置三个分片参数，(0，1，2)，执行机在通过context拿到其中的一个分片参数之后可以对该分片参数做判断，来做具体的数据操作，例如当拿到的分片参数为0时，则对于0相应的分片做数据查询操作，依次类推

再例如，某张订单表按照订单ID和Status来进行二维分片，ID取模以3来进行分片，状态以成功，失败两种状态来进行分片，此时就可以设置6个分片参数，({‘id’:0,’status’:0},{‘id’:1,’status’:0},{‘id’:2,’status’:0},{‘id’:0,’status’:1},{‘id’:1,’status’:1},{‘id’:2,’status’:1}),执行机在通过context拿到其中的一个分片参数之后，就可以对其json参数进行判断，来实现分片操作

任务执行一致性，每次任务只会被一个执行机所执行;对于分片任务，在执行机集群部署时，一次任务调度将会广播触发对应集群中相应数量的执行器执行一次任务，同时传递分片参数，可根据分片参数开发分片任务。

当分片参数大于执行器数量时，将会按照执行器路由策略，使得当前分片任务的某个或者某几个执行机执行多个分片的任务

例如：当前分片任务分片参数为(a,b,c),当前任务执行机有3台(A,B,C)时，则会均匀随机得将分片参数发送给某一台执行机，且三台执行机一次只接收一个分片参数，做一次任务处理，即(a-A,b-B,c-C)|(a-A,b-C,c-B)|(a-B,b-A,c-C)|(a-B,b-C,c-A)|(a-C,b-A,c-B) |(a-C,b-B,c-A)；

当任务执行机只有2台(A,B)时，每次任务调度时，某台执行机会收到两个分片参数，并分别处理这两个分片参数,即(a-A,b-B,c-A)|(a-A,b-B,c-B)|(a-B,b-A,c-A)|(a-B,b-A,c-B)；

而当任务执行机大于分片参数个数，为4台(A,B,C,D)时，(a-A,b-B,c-C)|(a-A,b-C,c-D)|(a-A,b-D,c-B)| (a-B,b-C,c-D)|(a-B,b-D,c-A)|(a-B,b-A,c-C)|(a-C,b-A,c-B)|(a-C,b-B,c-D)| (a-C,b-D,c-A)|(a-D,b-A,c-B)|(a-D,b-B,c-C)|(a-D,b-C,c-A)，而统计下来，不管是执行机数目大于或者等于或者小于分片参数数目，被分发给执行机的分片参数始终是保持一致的（每台执行机接收到的总的分片参数是均匀的）

告警系统，系统接入内部告警系统，任务失败时支持邮件，短信，钉钉，电话等告警

弹性扩容缩容，调度中心将会实时探测任务执行机，因此一旦有执行机上线或者下线，都将会被探测到，而如果未被调度中心探测到，则可以进行手动探测执行机，而在探测到执行机之后，下次调度将会重新分配任务

任务依赖，支持配置任务依赖关系，当父任务在执行完成之后会自动触发子任务的执行例如：有两个任务，分别为A和B，而B的执行条件为确认A任务执行完，B才能执行，否则，B任务不执行，此时的依赖关系就是B任务依赖A任务，此时在A任务配置完之后，设置B任务为依赖任务，而依赖关系则是A；又例如有6个任务，分别是A1,A2,A3,A4,A5,B，而B任务的执行需要确保A1-5这5个任务都执行完，B任务才执行，此时，B的依赖关系就是B任务依赖于A1-5，此时在配置完A1-5这5个任务之后再设置B为依赖任务，依赖关系则是A1-5

支持运行时查看任务执行情况，任务数量，调用次数，执行器数量等统计信息异常执行恢复机制，有时会遇到不可控情况，即执行机在执行后的执行结果因为网络断开等不可控因素导致不能发送给调度中心，此时能通过异常执行恢复机制临时记录，在下次执行机正常启动时重试发送给调度中心调度手动触发手动执行，特殊需求下，可能会要求调度可以手动执行，例如调度任务失败之后可能需要手动执行一次调度来补偿

并行/串行策略，当定时时间远大于任务执行时间时，可以使用并行策略，任务异步调用执行，提高任务调度精确度;当任务执行时间可能大于定时时间，却需要任务按照某个定时规则定时调度时，可以使用串行策略，调度中心调度的当前任务的上一次触发，如果没有执行完，则当前执行机的下一次定时时间点时不会被触发，当且仅当任务执行结束，以防止某些持续性定时任务的时间不确定性导致异步触发时的数据混乱的情况发生，例如：某一任务的定时时间为10秒钟，但是任务本身可能会出现执行超过10秒的情况，而超过时，如果出现两个时间点的任务并行执行时会出现数据混乱的情况，此时就可以使用串行策略，确保当前执行机上一个任务未执行完，不会触发新的执行

支持调度接口数据监控，产生监控报表，便于观测。

总结

对于互联网公司来说，时间就是金钱，效率决定一切。本系统在接入到8月初将近3个月的时间内，表现不凡，调度了约100万次，给公司内部各服务实现任务调度提供了便利。

原文

日志实体类信息包括哪些内容？

日志实体类信息包括哪些内容？组件选择

选择组件，我们这边主要是从以下几个方面进行考量的：

组件对应的开源生态完整、活跃度高

对应的技术栈是我们所熟悉的，我们这边语言技术栈主要是Java、Go，如果组件语言是C、Ruby，应该就被排除了。

运维成本

易部署、性能好

1、Agent

一提到日志收集方案，大家第一个想到的肯定是ELK(Elasticsearch、Logstash、Kibana )，但Logstash依赖于JVM不管是性能还是简洁性，都不是日志收集agent的首选。

个人感觉一个好的agent应该是资源占用少，性能好，不依赖别的组件，可以独立部署。而Logstash明显不符合这几点要求，也许正是基于这些考虑elastic推出了Filebeat。

2、Collector、MQ

elasticsearch集群在部署的时候，一般都是提前估计好容量、机器、shard等信息，因为elasticsearch集群运行后，再水平拓展，比较麻烦，而我们这边由于业务及成本限制无法很好的预估容量，所以就结合公司实际要求：使用日志服务的业务方自带机器，也就是业务方会有独立的elasticsearch集群。

每个业务方都使用自己的elasticsearch集群，所以集群压力不会很大，从而Collector、MQ这两个组件对于我们的作用也就很小了。

3、ETL

因为Elasticsearch Ingest Node完全可以满足我们的解析需求，所以就没有必要再引入Logstash等相关组件了。

到这里，基本可以看出我们的架构如下：

?

架构合适的，就是最好的。

三、业务需求

我们这边收集日志应对的场景主要是：文本日志、docker日志、k8s日志，恰恰这些EFK全家桶都支持。

我们希望日志收集产品可以满足以下几个需求：

按照项目、应用、实例维度检索日志并支持搜索关键字高亮（因为大家检索日志的时候，肯定是检索某个应用、某个实例的日志）

支持检索出某条想要的日志后，可以查看上下文（查看该日志所在日志文件的前后多少条）

支持日志下载（目前支持两种场景：搜索结果下载、上下文下载；支持两种方式：在线下载、离线下载）

支持Elasticsearch Query String查询

支持自动化批量部署、卸载Filebeat，部署、卸载过程可视化

单实例支持多elasticsearch集群

支持文本日志、docker日志、k8s日志并能与将日志与其业务意义对应上。（即不管是哪种日志形式、来源，最终都需要与业务意义上的项目、应用、实例对应起来，因为对于日志的使用者来说，查询日志的出发点肯定是查询某个项目、某个应用（可以不选）、某个实例（可以不选）、某段时间的日志。）

四、具体实现

基于需求及EFK套件，梳理我们场景中特有的东西：

docker日志的场景比较单一，都是通过之前一个产品A发布部署的，其docker命名规则比较统一，可以通过截取docker.container.name来获取应用名字；同时在部署的时候，可以知道部署目标机器的ip，这样就可以通过应用+ip来作为实例名称。

k8s场景也比较统一，都是通过之前一个产品B发布部署的，其pod命名规则比较统一，可以通过截取kubernetes.pod.name来获取应用名字（但需要通过namespaces关联到tenant，再通过tenant与项目一一对应）；k8s中的pod.name就是唯一的，以此来作为实例名称即可。

文本日志：因为文本日志主要的场景是已经裸机部署的应用，这种场景下，不存在应用自动迁移的情况，所以文本日志的应用名称、实例名称可以在部署的时候打上标签即可。

具体规则及解析见下图（实例部分处理暂未标注）：

?

其实，我们不太推荐写日志到文本文件中，使用标准输出就好。

到这里可以发现我们选择Filebeat来作为日志的收集端，Elasticsearch来存储日志并提供检索能力。

那么，日志的清洗在哪里做呢？

日志的清洗一般有两种方式：

先把日志收集到kafka，再通过Logstash消费kafka的数据，来清洗数据

直接通过Elasticsearch的[Ingest Node]来清洗数据，因为Ingest Node也支持Grok表达式

对于，我们的场景而言，我们需要清洗数据的要求比较简单，主要是应用、实例名称的截取还有文本日志中日志时间的处理（@timestamp重置，时区处理），所以我们选择了方案2。

其实，选择方案二还有个原因就是：系统在满足需求的同时，尽量保持简单，减少依赖的组件。

在我们的方案中，并没有提供Kibana 的界面直接给用户用，而是我们自己根据公司业务独立开发的。

前端界面为什么不采用Kibana，而需要自己开发？

1、kibana对于业务开发人员有一定的学习成本

2、kibana界面没有很好的将日志内容与业务意义关联起来（界面选择总比一次次的输入要好，这也是我们将日志的项目、应用、实例等业务信息解析出来的原因）

3、log-search支持Query String，因此对于熟悉kibana的开发人员来说，在我们自己开发的前端界面检索效果是一样的。

log-search提供的功能可以参见github：log-search

如果日志需要清洗的比较多，可以采用方案1，或者先不清洗，先把数据落到Elasticsearch，然后在查询的时候，进行处理。比如在我们的场景中，可以先把日志落到Elasticsearch中，然后在需要检索应用名称的时候，通过代码来处理并获取app名字。

五、监控、告警

其实基于日志可以做很多事情，比如：

基于日志做监控（Google Dapper）

基于日志做告警

基于日志做Machine Learning

具体思路，可以参见下图：

?

前提：能要求使用方，按照某种规则打印日志。

监控发展：监控基本就是先打通链路trace，然后再在上报信息或者日志信息中，加强业务方面标识，即给监控添加业务维度方面的视角。

六、其它

1、DaemonSet

以DaemonSet方式部署Filebeat来收集日志，其实收集也是宿主机/var/lib/docker/containers目录下的日志。

Running Filebeat on Kubernetes

2、Sidecar

一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。

莫名想起了istio。

Filebeat可以以sidecar模式来进行容器日志的收集，也就是filebeat和具体的服务容器部署在同一个pod内，指定收集日志的路径或文件，即可将日志发送到指定位置或Elasticsearch这类的搜索引擎。

每个pod内部署filebeat的模式，好处是和具体的应用服务低耦合，可扩展性强，不过需要在yaml进行额外配置。

3、业界案例分享

InfoQ运维大会日志处理专题演讲干货合集

曹林华-沪江网日志平台化之路

黎吾平-日志分析场景下的搜索引擎改进

林冰玉-QA 与Ops通力打造反脆弱的软件系统

周辉-新思路打造移动端个案综合日志分析系统

个人微信公众号：

?

作者：jiankunking 出处：

展开全文

APM：ELK 与 Prometheus

同为监控应用的两个平台，Prometheus和ELK的对比： ELK和Prometheus的对比 Prometheus ELK 轻量、部署相对简单 较重，组件较多，部署起来较麻烦 使用灵活，需要使用者会灵活运用 上手较为简单 适用于短期使用，比如SIT测试 适用于长久稳定地运行 ...

APP打开

Linux下常见的日志文件名

Linux常见的日志文件名： /var/log/cron 工作调度 /var/log/dmesg 内核检测过程中产生的信息 /var/log/lastlog 检测所有账号登陆信息 /var/log/maillog或/var/log/mail/* 邮件 /var/log/messages 记录系统发生的所有错误信息 /var/log/secure 涉及账号密码信息 /var/log/w...

APP打开

评论(23)

?写评论

?

码工?邢美玲?码龄4年

?

哇啊1年前

?

刘佳欢--hannah?码龄5年

?

谢谢分享1年前

?衣舞晨风??码龄10年??

回复刘佳欢--hannah:愿能对你有所帮助

1年前

?

xudc?码龄10年

?

学习了1年前

?

mortredly?码龄1年

?

很优秀啊1年前

?

LaLaLa_OvO?码龄10年

?

我现在每次去生产环境下载tomcat里的log文件分析，感觉好麻烦???，感谢博主提供的思路，虽然一下子没太懂，但是研究下应该可以理解的1年前

?

码哥?Think—Coder??码龄3年

?

厉害1年前

?

fightsyj?码龄4年

?

优秀1年前

?

叄拾叄画生?码龄2年

?

不错1年前

?

qq_45010093?码龄1年

?

我要下载码1年前

?衣舞晨风??码龄10年??

回复qq_45010093:？？？

1年前

?

码农?凉快-Eric?码龄3年

?

日志很重要，在下需努力！1年前

去APP查看全部评论?

SpringBoot控制台彩色输出

#控制台彩色输出 spring: output: ansi: enabled: ALWAYS SpringBoot控制台彩色输出

APP打开

分布式系统中的日志落地经验总结

@分布式系统中的日志落地经验总结 在过去的2年多的时间里，随着在公司推进容器云，陆陆续续的和日志打了不少交道，在这里做一个总结： 为什么需要日志 日志如何接收与存储 日志如何收集 日志收集客户端分析 日志的标准化 日志报警 日志归档 其他问题 为什么需要日志 日志的作用我觉得有三点： 故障排错 数据分析 业务审计 1，关于故障排错，当线上发生异常，查看应用的错误日志、堆栈信息、代理层的访问...

APP打开

关于日志的那些事儿 - 樱木天亥 - CSDN博客

写这篇文章是源于耗子叔在左耳听风专栏的群里发布了命题作文「关于日志的那些事儿」,正好可以去查阅资料,学习了解一下日志方面的知识。 什么是日志 首先,什么是...

关于日志的那些事儿_xiemanR的专栏-CSDN博客

关于日志的那些事儿 日志的作用 1.审计 商业分析:比如从日志中提取用户行为(比如,一个点击事件流)并结合用户的其他详情(比如,最终购买行为)来生成报告或者推荐相关...

如何打一手好Log

如果项目上过线的话，那你一定知道Log是多么重要。 为什么说Log重要呢？因为上线项目不允许你调试，你只能通过Log来分析问题。这时打一手好Log的重要性绝不亚于写一手好代码。项目出问题时，你要能拿出Log证明自己负责的部分没有问题，如果是自己的问题，要从Log里快速找出错误原因。如果没有从Log里找出错误原因，那一定是一件很悲催的事情，特别是在bug不容易重现的情况下。那简直...

APP打开

关于日志那些事

关于日志那些事 对于现在的应用程序来说，日志的重要性是不言而喻的。很难想象没有任何日志记录功能的应用程序运行在生产环境中。日志所能提供的功能是多种多样的，包括记录程序运行时产生的错误信息、状态信息、调试信息和执行时间信息等。在生产环境中，日志是查找问题来源的重要依据。本文从日志的定义、作用、分类、级别等角度介绍日志。 什么是日志 日志是用来保存系统发生的事件信息和各种对象执行的操作信息的管理对象...

APP打开

关于日志的那些事儿 - weixin_34416754的博客 - CSDN博客

写这篇文章是源于耗子叔在左耳听风专栏的群里发布了命题作文「关于日志的那些事儿」,正好可以去查阅资料,学习了解一下日志方面的知识。 什么是日志 首先,什么是...

Filebeat 收集日志的那些事儿_360技术-CSDN博客

点击蓝字关注我们最近因为云原生日志收集的需要,我们打算使用Filebeat作为容器日志收集工具,并对其进行二次开发,因此笔者将谈谈 Filebeat 收集日志的那些事儿。本文不...

一起来学 SpringBoot 2.x | 第三篇：SpringBoot 日志配置

点击上方“芋道源码”，选择“置顶公众号”技术文章第一时间送达！源码精品专栏 精尽 Dubbo 原理与源码专栏( 已经完成 69+ 篇，预计总共 75+ 篇 )中文详细注释...

APP打开

写日志的那些事儿

2019独角兽企业重金招聘Python工程师标准 ...

APP打开

Filebeat 收集日志的那些事儿_weixin_48726650的博客-CSDN博客

Filebeat 收集日志的那些事儿 1前言 开源日志收集组件众多,之所以选择Filebeat,主要基于以下几点: 功能上能满足我们的需求:收集磁盘日志文件,发送到Kafka集群;支持多行...

Filebeat 收集日志的那些事儿_HULK一线技术杂谈-CSDN博客

女主宣言最近因为云原生日志收集的需要,我们打算使用Filebeat作为容器日志收集工具,并对其进行二次开发,因此笔者将谈谈 Filebeat 收集日志的那些事儿。本文不涉及过...

日志记录的作用和方法 java

程序中记录日志一般有两个目的：Troubleshooting和显示程序运行状态。好的日志记录方式可以提供我们足够多定位问题的依据。日志记录大家都会认为简单，但如何通过日志可以高效定位问题并不是简单的事情。这里列举下面三个方面的内容，辅以代码示例，总结如何写好日志，希望对他人有所启发和帮助： 怎样记日志可以方便Troubleshooting程序运行状态可以记哪些应该避免怎样的日志方

APP打开

JB的ARTS之旅-关于日志的那些事

前言 很多小伙伴看到标题，可能会有疑问，什么叫ARTS？，这里答疑一下： 这是来自于左耳朵耗子专栏的一个活动，详情请来到某乎了解； 而ARTS实际意义是： 1.Algorithm：每周至少做一个 leetcode 的算法题 2.Review：阅读并点评至少一篇英文技术文章 3.Tip：学习至少一个技术技巧 4.Share：分享一篇有观点和思考的技术文章 复制代码 因精力有限，暂时只能挑一个完成，希...

APP打开

运维的那些事儿 - 狂生小白的博客 - CSDN博客

十二、应用系统日志 这里边可分析的东西就多了, 不过...人工智能那些事儿0.目录那些有意思的事儿那些数学的...关于思维导图的那些事 阅读数 529 前言:经过米老...

?写评论

?

23

?

9

?

82

?

分享

APP内打

服务器数量比较少，怎么运维比较好？

运维人员的工作每天基本上都是在检查问题，枯燥但又重要， 要是你的某一个环节出现问题并没有及时发现问题，对于企业来说损失可能非常大，基本上运维人每天的工作我罗列了下，有这几种：

1、负责服务器的硬件配置、软件安装、机房上下架等技术维护工作

2、负责虚拟化技术产品物理机配置、管理和日常运行监控和维护

3、负责独立主机或虚拟应用产品的开通使用、日常维护、故障诊断和排除

4、提供独立主机或虚拟应用客户产品操作和应用方面的技术支持

5、监视分管的服务器，及时发现问题，并积极解决问题

现在信息化数字时代，单靠人工去检查出现错误几率会很大，而且有的运维人还不只管理两台服务器，像我们公司的运维每人至少要管理30台服务器，这样子单靠人工运维耗费的人工成本和时间是非常大的，所以还是推荐你用运维工具吧，比如云帮手（）

1.支持跨云商批量管理服务器

2.兼容性强大，兼容市面基本所有的云商云主机，兼容操作系统；

3.操作简单，可视化界面预览资源、一键修复、一键部署；

4. 可以远程登录云主机FTP桌面，处理云主机上的文件；

5.监控和资源还有告警功能，这个是挺好的，不用盯着看；

6.系统修复功能，这个是挺实用也比较必须的；

7.免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬。

你好，很高兴回答你这个问题。从运维的角度来讲，服务器的数量少并不意味着我们的运维工作就非常轻松，相反我们更应该重视此阶段的工作。

我们可以从以下几方面来开展我们的运维工作：

1.应用服务器

我们可以从当前服务器中找出 至少2个节点装Vsphere虚拟化，建立一个数据中心、集群 ；如果你的服务器有多网卡和SCSI，还可以做一些更高级的应用，如vmotion、负载均衡、高可用等。当虚拟机或服务器故障，可以 实现故障自动转移，有效的避免了单节点的故障，提供服务器的容错率 。

我们可以在新建的虚拟机部署Web、API等各种应用，而且 虚拟机可以在vCenter图形化界面下统一管理 。这一般是中小公司的在服务器方面的解决方案。

当然，我们对docker比较熟悉，可以使用一套docker解决方案，这比Vsphere更能节省一部分资源。当然这个需要的技能要求也比较高，需要我们不断积累。

2.数据库服务器

数据库服务器在此我们单独拿出来，是因为数据库对服务器性能、磁盘IO要求比较高，不太建议使用虚拟机，当然这需要根据业务的实际情况来做选择。 数据库我们需要通过一主一从、一主二从的方式实现高可用，来避免数据库单点问 题，我们还可以选择合适的proxy来进行读写分离、读负载均衡等。另外还要考虑数据的本地备份、异地备份，来确保数据可恢复。

3.系统监控

当我们在应用服务器和数据库服务器上线一套系统后， 我们需要通过监控掌握从服务器硬件、基础状态、应用、数据库等从下到上的运行状态 ，以便我们能够对告警及时做出响应。考虑到报警的及时性，我们需要监控接入多种报警渠道，如微信、钉钉、邮件、短信等。监控的目的是发现问题、解决访问，因此我们需要踏实的做好这一步，才能为我们的业务保驾护航。

好了，其实不管服务器多少，我们都需要扎实的把基础打好，这样才能以不变应万变面对各种情形。希望我的回答能够帮到你。

题主没有详细说明具体应用系统的功能，比如是否单一的Web服务？有没有微服务、分布式、集群化扩展的潜在需求？

通常来说，建议使用云服务自动化运维。云服务已经成为IT技术的核心基础设施，充分利用云服务带来的弹性和分布式优势，赋能自动化运维。

一，自动构建系统

如果需要构建应用，那么就建议配置使用CI/CD持续化集成和自动化部署，比如常用的Jenkins，配置Git代码提交时触发构建，然后自动部署。

二，日志收集处理系统

1，ELK是常见的日志收集管理系统，包括ElasticSearch, LogStash, Kibana三个服务，架构示意图如下：

2，在ELK系统中，Kibana是一个图形化展示工具，配置查询条件，运维人员随时可以搜索指定日志信息，分析处理故障。

三，服务监控

1，云监控CloudMonitor

主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。

比如配置CPU使用率到达80%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。

2，应用监控

以监控宝为例，配置服务地址，选择分布在不同地区和运营商的监测点。当监测点不能正常调用配置的服务地址时，将收到警告信息，可以选择邮件、短信、电话等通知方式。

四，潜在的系统扩展需求

1，是否集群化部署？需要AutoScaling自动伸缩吗？

小型化和集群化并不冲突。如果采用集群化部署，可以配置触发条件，满足时自动增加或者释放服务器资源。比如当CPU使用率达到75%或者内存占用率达到75%时，根据配置好的服务器和数量，自动触发。

2，是否使用Docker容器技术？

Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用，结合Docker-compose资源编排，快速实现自动部署更新，不再需要常用的Jenkins构建服务器。

机器数比较小的话，你可以用云的服务器，这样可以节省好多钱。找一个专门的运维，还不如让开发自己来搞，因为机器少运维他也应付得过来。现在都在搞云计算了，把你的机器放上阿里云或者腾讯云，你自己维护好很多，包括网络贷款都很容易扩容。上面这个我说到的只是说建议你如果你已经是自己的机器了。我建议你从我下面所说的来搞。

认为的整个过程的话一般分为三个阶段，第一的话是手工阶段，什么东西都是手工搞。

第2个阶段就是脚本阶段了，本来手工搞的东西全部脚本化。

第3个阶段就是平台化了，平台化了之后，所有东西都在页面上完成系统完成，不需要人工来干预，甚至不用运维来搞。

有一些人说既然认为就是最后的一个阶段，但是这个很不成熟。所以我就不说了。

针对你这个机器数少的，你可以手工认为，或者说用脚本认为都没问题。

在合适的阶段做合适的事情就是最好的。所以我建议你手工运维或者脚本运维。

我们项目用的 wgcloud运维监控系统 ，它前身是开源项目，后来推出的商业版，也有免费版

wgcloud运行很稳定，性能很好，部署和上手容易

wgcloud支持主机各种指标监控(cpu状态/温度，内存状态，磁盘容量/IO，硬盘smart监控，系统负载，网卡流量，硬件系统信息等)，数据可视化，进程应用监控，大屏可视化，服务接口检测，DOCKER监控，自动生成网络拓扑图，端口监控，日志文件监控，web SSH（堡垒机），指令下发执行，告警信息推送（邮件钉钉微信短信等）

可以装虚拟机代替，在同一个局域网情况下

找服务商外包服务，或者网上托管也不贵收费

服务器数量比较少，比如10台服务器，基本可以不设置运维岗位了，后端开发人员 或者架构师就能搞定。

我就是那种曾经在创业的小公司待过的开发人员，开发，运维我都干了。

但是想想如何更科学更高效的运维还是很有必要的。

运维的目的

软件系统的运行时环境：即公司的业务产线，靠它创造业务价值，这个是最核心的功能诉求。

实时监控系统: 任何时候都要对当前公司的产线的压力一清二楚，有问题功能随时解决，有性能问题及时扩容或者回收资源

降低服务器成本：在业务萎缩的情况下，准确评估哪些资源可以回收，降低服务器的支出

这个是当时我认为的运维的三个主要目的。

运维方案

开发半路出家，当时采用的是shell+python+ansible+jekins+elk的方式

首先，我会及时的更新业务产线的物理架构图，根据架构图来规划服务器的资源使用。

比如多少个web服务，数据库多少，zk,kafka,redis集群怎么分布。

集群部署一般是放在多个服务器上的，这个时候ansible就派上用场了。

jekins主要用来自动发布更新程序已经做定时回收磁盘的任务。

elk主要用来做应用的日志系统和监控告警； 可以通过看板随时知道产线的请求数量和并发数量；

以上的运维方案适用于小公司。运维工程师看到了可以补充

搞个zabbix刷

数量少。如果配置好可以虚拟化。然后跑容器

kibana是什么工具

Kibana是一个免费且开放的用户界面，能够让您对Elasticsearch数据进行可视化，并让您在Elastic Stack 中进行导航。

Kibana的使用场景

实时监控通过 histogram面板，配合不同条件的多个 queries可以对一个事件走很多个维度组合出不同的时间序列走势。

时间序列数据是最常见的监控报警了。

问题分析关于 elk 的用途，可以参照其对应的商业产品 splunk 的场景;

使用 Splunk 的意义在于使信息收集和处理智能化。而其操作智能化表现在搜索通过下钻数据排查问题，通过分析根本原因来解决问题;

实时可见性可以将对系统的检测和警报结合在一起，便于跟踪SLA和性能问题;

历史分析可以从中找出趋势和历史模式，行为基线和阈值，生成一致性报告。

Kibana的作用

| 可视化和分析

Kibana 让您能够自由地选择如何呈现自己的数据。不过借助 Kibana 的交互式可视化，您可以先从一个问题出发，看看能够从中发现些什么。

| 简单直观地构建可视化

拖放字段并查看即时预览，看着您的数据在眼前渐具雏形。柱状图看起来会好一些吗?

Kibana Lens 中的智能建议能够基于您所选的字段，指导您制作可视化，让您最有效地展示数据。

发现有趣的趋势，并在此基础上迸发出另一个想法?

没有问题。随时更换数据源进行即兴分析，从而轻松地凭借直觉创建出仪表板，并进行持续监测，而且还是免费且开放的。

| 定制

通过 Kibana 中的 Canvas，发挥无限创意

不受条条框框的限制。

通过徽标、颜色和能够突出贵公司品牌特色的设计元素将自己的品牌和风格融入到数据中，讲述独属于您的故事。

Canvas 是 Kibana 中一项免费且开放的功能，能够让您基于实时数据发挥无限创意，而且还支持 SQL。

| 管理

用于数据采集等操作的堆栈管理

有了 Kibana，命令行不再是管理安全设置、监测堆栈、采集和汇总数据或配置其他 Elastic Stack 功能的唯一途径。

与此同时，得益于我们出色的 API，用户可以通过可视化UI，轻松管理 Elastic Stack 并确保其安全性，这种方式更加直观，也能让更多的人上手使用。

| 可直接应用于用例

没错!在这里就能处理日志、指标等数据。

有时您只想对某个文件进行 tail 操作。您可能希望跟踪自己网站的运行状态，或者您可能希望查看分布式痕迹。

通过 Kibana 内置应用，例如 Logs、Infrastructure、APM、Uptime 以及其他应用，无需离开 Kibana，便能轻松完成这一切。

ES告警之ElastAlert入门教程(容器部署)

????????我们部署的版本是此篇文章发布时ElastAlert（V0.2.1）、ElastAlert server（3.0.0-beta.0） 、elastalert-kibana-plugin（1.1.0）的最新版本。es和kibana的版本是7.2.0。ES和kibana部署不是本篇的重点，这里不做介绍。

????????入正题之前得先说下ES，Elasticsearch 是一个分布式、可扩展、实时的搜索与数据分析引擎。 它能从项目一开始就赋予你的数据以搜索、分析和探索的能力。我们容器服务的日志现在大多数都入到了qbus，然后可以用es消费，通过kibana方便的查看日志。但是负责es的同事和我们都没有支持日志告警，目前是一个短板。X-Pack提供了报警组件Alert，但是这个功能是需要付费，ElastAlert能够完美替代Alert提供的所有功能。ElastAlert目前有6k+star，维护较好很受欢迎，使用python编写，V0.2.0以后使用python3，python2不再维护，以致在虚机物理机部署的坑很多，最终也是以容器的方式成功搭建。因为公司es之后要升级到7.2版本，ElastAlertV0.2.1（最新版本）才对es7支持的很好，elastalert-kibana-plugin最新版本才支持kibana7。

elastalert-kibana-plugin对ES6.3开始提供支持，公司目前使用的是ES6.2，之后要升级到ES7，所以ElastAlert用V0.2.1，ElastAlert server 3.0.0-beta.0,elastalert-kibana-plugin 1.1.0。

????????ElastAlert V0.2.1需要python3，目前我们使用linux内核都会默认装python2，安装python3后，使用混合环境安装ElastAlert 很多依赖装不成功，亦或装成功后模块有找不到，所以最终打算使用docker multi stage build方式构建ElastAlert server镜像，以容器的方式启动。

????????官网上提供了ElastAlert server镜像构建方式，但很久不维护，还是使用python2构建的老的版本。我们需要重新构建。

通过docker logs elastalert -f 查看日之日，如果报错，指定告警级别为dubug查看错误信息

kibana插件如下：

custom_frequency是启服务之前创建的配置文件，test和test2是通过kibana dashboard创建。用户可以通过“创建”-“测试”-“保存”这一流程新建alert rules 和我们的hulk容器上的自定义告警流程差不多

Spring Boot教程第22篇：整合elk，搭建实时日志平台

这篇文章主要介绍springboot整合elk.

elk 简介

elk下载安装

elk下载地址：

建议在 linux上运行，elk在windows上支持得不好，另外需要jdk1.8 的支持，需要提前安装好jdk.

下载完之后： 安装，以logstash为栗子：

配置、启动 Elasticsearch

打开Elasticsearch的配置文件：

修改配置:

network.host=localhost

network.port=9200

它默认就是这个配置，没有特殊要求，在本地不需要修改。

启动Elasticsearch

启动成功，访问localhost:9200,网页显示：

配置、启动 logstash

在 logstash的主目录下：

修改 log4j_to_es.conf 如下：

input {

log4j {

mode = "server"

host = "localhost"

port = 4560

}

}

filter {

#Only matched data are send to output.

}

output {

elasticsearch {

action = "index" #The operation on ES

hosts = "localhost:9200" #ElasticSearch host, can be array.

index = "applog" #The index to write data to.

}

}

修改完配置后启动：

./bin/logstash -f config/log4j_to_es.conf

终端显示如下：

访问localhost:9600

证明logstash启动成功。

配置、启动kibana

到kibana的安装目录：

默认配置即可。

访问localhost:5601，网页显示：

证明启动成功。

创建springboot工程

起步依赖如下：

log4j的配置，／src/resources/log4j.properties如下：

log4j.rootLogger=INFO,console

# for package com.demo.elk, log would be sent to socket appender.

log4j.logger.com.forezp=DEBUG, socket

# appender socket

log4j.appender.socket=org.apache.log4j.net.SocketAppender

log4j.appender.socket.Port=4560

log4j.appender.socket.RemoteHost=localhost

log4j.appender.socket.layout=org.apache.log4j.PatternLayout

log4j.appender.socket.layout.ConversionPattern=%d [%-5p] [%l] %m%n

log4j.appender.socket.ReconnectionDelay=10000

# appender console

log4j.appender.console=org.apache.log4j.ConsoleAppender

log4j.appender.console.target=System.out

log4j.appender.console.layout=org.apache.log4j.PatternLayout

log4j.appender.console.layout.ConversionPattern=%d [%-5p] [%l] %m%n

打印log测试：

在kibana 实时监控日志

打开localhost:5601:

Management=index pattrns=add new:

点击discovery: