IT运维自动化的前景如何?

IT运维自动化的前景如何?,第1张

2020年IT运维市场前景分析

2019年10月29日,第一财经刊发了关于《工信部:加强5G、人工智能、工业互联网、物联网等新型基础设施建设》一文,其中指出,推动新型IT基础设施建设。加强5G、人工智能、工业互联网、物联网等新型IT基础设施建设,扩大高速率、大容量、低延时网络覆盖范围,鼓励企业通过内网改造升级实现人、机、物互联,为企业提供有力的信息网络支撑,让企业IT基础设施成为企业发展之路上的护航者。由此可以看出,国家对企业IT基础设施建设的重视之深,而我们IT运维人员将是这次IT基础设施建设的主力军。

IT运维是企业项目开发后保证业务系统正常运行的必备工作之一,如何满足企业对在线业务系统高可靠、低延时、大容量、零故障等要求或在终端用户无感知情况下处理运维过程中存在的各种各样的突发性问题,是IT运维人员必会的技能,但是如此优秀的IT运维人员几乎一将难求。

既然,IT运维人员对于国家相关部门大力支持的IT基础设施建议那么重要,那么我们IT运维人员都需要拥有哪些能力或IT运维工作内容有哪些呢?

1、IT基础设施运维自动化

由于企业要求IT基础设施能够做到高可靠、低延时、大容量、零故障等,那就需要IT运维人员对底层硬件设备进行用心维护,硬件不出故障才能保证上层业务系统的稳定、高效地运行。

2、IT基础设施之上在线业务系统上线

企业在线业务系统是企业对内或对外提供服务的重要途径,IT运维人员在业务系统开发后,能够准确及时上线业务系统是对其业务能力的重要考核标准之一。

3、IT基础设施及在线业务系统监控自动化

对企业IT基础设施及在线业务系统进行有效监控,能够IT运维人员及时获知硬件或业务系统状态,以此判断硬件或业务系统有效服务能力,对硬件或业务系统故障做到即时反馈,即时处理,不影响企业对内或对外提供服务。

4、IT基础设施及在线业务系统日志处理自动化

对企业IT基础设施及IT在线业务系统进行日志处理(收集、分析、监控、趋势图展示等),获知硬件使用或业务系统中用户行为,以此预测下一周期内硬件或业务系统资源可用情况,及时应对用户访问波峰。

5、在线业务系统发布自动化

使用业界先进工具实现在线业务系统代码发布自动化,打破传统IT运维 "领域隔离",实现真正的一键式发布业务系统,加快系统部署速度,实现用户无感知升级或回滚 *** 作等。

6、IT基础设施平台升级

传统的企业IT基础设施平台对企业在线业务系统需要底层硬件平台的高响应、高可靠、大容量等能力反应不及时或不彻底的情况时有发生,这就需要我们IT运维人员能够对传统的企业IT基础设施平台进行升级,把传统的企业IT基础设施平台升级为云平台,由云平台的高响应、高速度、低延时、大容量等能力为业务系统稳定运维保驾护航。

7、在线业务系统迁移至云平台

传统的企业IT基础设施平台升级为云平台后,需要IT运维人员能够把运行在传统的企业IT基础设施平台之上的业务系统迁移至云平台。

8、云平台运行维护(升级)

云平台运行过程中,需要IT运维人才时刻进行监控、对于云平台突发情况进行处理。

9、IT运维自动化系统开发

由于企业IT基础设施运维过程中,涉及多业务、多场景、多平台等,IT运维人员在运维过程中亟需一套本企业的IT运维管理系统,但是由于每家企业的IT基础设施异样性,导致市场上无法采购标准化系统进行应用,大多数情况下由本企业IT运维人员根据企业自身情况进行开发。

10、业务系统海量数据分析及展示

企业在运营过程中产生大量的业务类数据,并且此类数据对于生产、运营等有利于决策,因此IT运维人员需要对企业内部或行业内的数据进行收集、分析、展示等,最终为企业运营提供决策参考依据。

以上为我们为罗列的IT运维人员能力要求或工作内容,下面我们再来了解一下2020年IT运维市场规模,2020年有越来越多的企业开始拥抱互联网,借助互联网开展“无接触”式业务,特别是在2020年初“新冠”疫情的影响下,公司为了生存开启了全员在线办公及业务全天侯在线处理等,这也就为企业打开了企业在线常态化;让更多的工作借助互联网完成,据权威机构公布称:"这一切将产生约100万相关技术开发岗位及约10万IT运维岗位,至2024年,IT运维行业市场容量将呈现出逐年增长态势,到2024年IT运维管理行业市场规模将达到38328亿元。"

2020年IT运维行业技术展望

企业对于IT运维人员要求越来越“T型”化,其中包含更深层次的专业化,自动化以及智能化,因此在2020年全球大多数的企业都在以行业标杆(例如:谷歌、亚马逊、阿里等)为榜样,着力发展企业自身的如下方向:

1、云计算

云服务器是由云服务厂商提供的性能卓越、稳定可靠、d性扩展的IaaS(Infrastructure as a Service)级别云计算服务。云服务器免去了采购IT硬件的前期准备,让企业像使用水、电、天然气等公共资源一样便捷、高效地使用服务器,实现计算资源的即开即用和d性伸缩。

2、DevOps

DevOps使企业项目开发者与企业项目开发后IT运维人员、测试人员、产品经理、客户等直接发生了连接关系,让项目各方能够进行更好地结合,把以住只关注自身业务转移到整个交付过程,甚至关注到最终服务上,DevOps已经成熟,其在2020年将成为每一位IT运维人员必备技能之一。

3、AIOps

IT运维内容没有变,但是IT运维方式在发生改变,AIOps将为我们IT运维人员“解放”双手,让我们可以花费更少的时间在IT基础设施及IT业务系统监控、日志、安全等工作上,把业务重心投放到企业IT基础设施及IT业务系统发展、运营、服务决策上。

4、SaaS

SaaS(Software-as-a-Service)是企业提供应用、开发、IT运维等全套服务的一种形式,由于其不再需要用户有任何IT基础设施的投入,可以大大降低企业IT成本,获得更优质的服务。

5、边缘计算

随着5G技术大面积应用,更多的边缘设备需要对接到云平台,并享受近十年云计算行业发展的红利,但是如果生硬地把物联网设备与云计算平台对接,将会为云计算平台带来非常大的数据量的同时,也会影响到物联网边缘设备的数据处理能力,因此我们可以考虑把云计算技术向边缘设备进行延伸,这就是我们所说的边缘计算,IT运维人员将主导边缘计算的成云能力。

6、Serverless

ServerLess,为一种无服务模式,目的让企业不再关注IT基础设施,由IT运维人员提供IT基础设施后,多企业可以共享同一IT基础设施平台,企业可以摊销更多IT基础设施成本。

2020年黑马程序员IT运维工程师学习路线图

1、Linux *** 作系统基本功

Linux系统安装、配置,基本命令,VIM编辑器,Linux自有服务,权限管理,YUM包管理,开源项目上线部署。

2、Linux系统服务

网络基础(重点难点TCP/UDP)、sshd服务(scp/rsync)、文件共享服务(ftp/nfs/samba)、DNS域名服务、LAMP编译安装、rsyslog、Linux分区+LVM逻辑卷+(软硬RAID)

3、Shell、MySQL

Shell脚本编程、MySQL从入门到精通(DBA方向)

4、商城系统上线部署

Nginx概述、LNMP环境搭建、MySQL读写分离、LB负载均衡(Nginx/LVS/HAProxy)、NoSQL(Memcached、Redis、MongoDB)、存储、企业级商城系统架构实战。

5、配置自动化

配置自动化(Ansible/SaltStack)、监控(Zabbix/Promethus)、日志分析(ELK、KafKa)、CI/CD(Git、GitLab、Jenkins)

6、运维安全与调优

运维安全(防火墙、CA认证、)

应用软件调优(Web应用调优)

系统调优(系统+内核)

7、运维云计算

Hadoop、KVM虚拟化、公有云运维(阿里云)、私有云运维(OpenStack)、Docker容器、Kubernetes(K8S)容器编排工具

8、Python运维开发方向

Python运维基础、Python面向对象、Django框架、Python CMDB项目开发

附件为2020版黑马程序员Linux云计算+运维开发学习路线图:

ELK-bledom
1、
这是最简单的一种ELK架构方式。优点是搭建简单,易于上手。缺点是Logstash耗资源较大,运行占用CPU和内存高。另外没有消息队列缓存,存在数据丢失隐患。
此架构由Logstash分布于各个节点上搜集相关日志、数据,并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩存储并提供多种API供用户查询, *** 作。用户亦可以更直观的通过配置Kibana Web方便的对日志查询,并根据数据生成报表。
2、
此种架构引入了消息队列机制,位于各个节点上的Logstash Agent先将数据/日志传递给Kafka(或者Redis),并将队列中消息或数据间接传递给Logstash,Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka(或者Redis),所以即使远端Logstash server因故障停止运行,数据将会先被存储下来,从而避免数据丢失。

Kibana4简单使用
<center>
# ELK日志系统使用说明 #
</center>
k3与k4的对比
![](>本文讲解如何通过一套开源日志存储和检索系统 ELK 构建 MySQL 慢日志收集及分析平台。

ELK、EFK 简介
想必你对 ELK、EFK 都不陌生,它们有一个共同的组件:Elasticsearch(简称ES),它是一个实时的全文搜索和分析引擎,可以提供日志数据的收集、分析、存储 3 大功能。另外一个组件 Kibana 是这套检索系统中的 Web 图形化界面系统,可视化展示在 Elasticsearch 的日志数据和结果。

ELF/EFK 工具集中还有 l 和 F 这两个名称的缩写,这两个缩写代表的工具根据不同的架构和使用方式而定。

L 通常是 Logstash 组件,它是一个用来搜集、分析、过滤日志的工具 。

F 代表 Beats 工具(它是一个轻量级的日志采集器),Beats 家族有 6 个成员,Filebeat 工具,它是一个用于在客户端收集日志的轻量级管理工具。

F 也可以代表工具 fluentd,它是这套架构里面常用的日志收集、处理转发的工具。

那么它们(Logstash VS Beats VS fluentd)有什么样的区别呢?Beats 里面是一个工具集,其中包含了 Filebeat 这样一个针对性的日志收集工具。Logstash 除了做日志的收集以外,还可以提供分析和过滤功能,所以它的功能会更加的强大。

Beats 和 fluentd 有一个共同的特点,就是轻量级,没有 Logstash 功能全面。但如果比较注重日志收集性能,Beats 里面的 Filebeat 和 fluentd 这两个工具会更有优势。

Kafka 是 ELK 和 EFK 里面一个附加的关键组件(缩写 K),它主要是在支持高并发的日志收集系统里面提供分布式的消息队列服务。
ELK 的优势

在此之前,先介绍 ELK 日志分析会有一些什么样的优势?主要有 3 点:

1、它是一套开源、完整的日志检索分析系统,包含收集、存储、分析、检索工具。我们不需要去开发一些额外的组件去完成这套功能,因为它默认的开源方式就提供了一整套组件,只要组合起来,就可以完成从日志收集、检索、存储、到整个展示的完整解决方案了。

2、支持可视化的数据浏览。运维人员只要在控制台里选择想关注的某一段时间内的数据,就可以查看相应的报表,非常快捷和方便。

3、它能广泛的支持一些架构平台,比如我们现在讲到的 K8s 或者是云原生的微服务架构。

Kafka 作为日志消息队列,客户端通过 Filebeat 收集数据(日志)后将其先存入 Kafka,然后由 Logstash 提取并消费,这套架构的好处是:当我们有海量日志同步情况下,直接存入服务端 ES 很难直接应承接海量流量,所以 Kafka 会进行临时性的存取和缓冲,再由 Logstash 进行提取、过滤,通过 Logstash 以后,再把满足条件的日志数据存入 ES。

ES 不再是以单实例的方部署,而是采用集群架构,考虑 Kafka 的集群模式, Logstash 也使用集群模式。

我们会看到这套架构稍微庞大,大中型的企业往往存储海量数据(上百 T 或 P 级)运维日志、或者是系统日志、业务日志。

完成ELK服务搭建后,首先我需要开启的是 MySQL 的慢查询配置,那么通过 set global slow_query_log=‘ON‘,这样就可以开启慢查询日志,还需要设置好慢查询日志标准是大于 1 秒的,那么同样是 set global long_query_time 大于或等于 1,它的意思是大于 1 秒的查询语句,才会认为是慢查询,并且做日志的记录。

那么另外还要设置慢查询日志的位置,通过 set global slow_query_log = 日志文件路径,这里设置到 filebeat 配置监听的路径下,就完成了慢查询日志的路径设置。

配置完成以后,需要在 MySQL 终端上,模拟执行一条执行时间较长的语句,比如执行 select sleep(5),这样就会模拟执行一条查询语句,并且会让它休眠 5 秒。接下来我们看到服务端窗口的 MySQL 这条 sleep 语句已经执行完毕了,同时我们可以再打开 filebeat 的推送窗口,发现这里产生了一条推送日志,表示成功地把这条日志推送给了 ES。

那么接下来我们就可以通过浏览器打开 Kibana 的管理后台,从界面里来看一看检索日志的记录和一些可视化展示的图表,我们可以点击界面上的 Discover 按钮,同时选择好对应的时间周期,然后可以增加一个 filter 过滤器,过滤器里面敲入对应的关键字来进行索引。

这里我敲入的是 slowquery 这个关键字,就会匹配出对应的可以检索的项目,点击想要查询的对应项目,展示出想检索的某一个时间周期内对应的一些日志记录,以及它的图表是什么样子的,同时在下方会有对应的 MySQL 的日志信息打印出来,通过 Kibana 这样的可视化界面就能够看到的相关信息了。

21 日志的采集灵活性是我们选择日志采集方案更看重的因素,所以logstash属于首先方案, 它可以兼顾多种不同系统和应用类型等因素的差异,从源头上进行一些初步的日志预处理。 logstash唯一的小缺憾是它的不轻便, 因为它是使用jruby开发并跑在java虚拟机上的agent, 当然啦,同时也是优点,即各种平台上都可以用。 22 日志的汇总与过滤 kafka在我们挖财已经属于核心的中间件服务, 所以, 日志的汇总自然而然会倾向于使用kafka。日志的过滤和处理因为需求的多样性,可以直接对接订阅kafka, 然后根据各自的需求进行日志的定制处理, 比如过滤和监控应用日志的异常,即使通过zabbix进行预警; 或者数据仓库方面在原始日志的基础上进行清洗和转换,然后加载到新的数据源中; 23 日志的存储原始的日志存储我们采用ElasticSearch, 即ELK技术栈中E的原本用途,遵循ELK技术栈中各个方案之间的通用规范, 比如日志如索引采用logstash与kibana之间约定的index pattern。日志的衍生数据则日志使用各方根据需求自行选择。 24 日志的分析与查询 ELK技术栈中的Kibana已经可以很好的满足这一需求,这里我们不折腾。 3 需要解决哪些技术问题?因为我们在ELK技术栈的处理链路上插入了一些扩展点,所以,有些问题需要解决和澄清 31 logstash与kafka的对接 ELK技术栈中, Logstash和Elastic Search是通过logstash的elasticsearch或者elasticsearch_>之前阿里的 tailfile 有许多坑,包括对软连接支持度不够,可能会有意想不到的后果,不保证采集数据完整性。比如有某些 情况下(Checkpoint 文件损毁) 重启采集进程后会重复读取历史已采集数据打爆服务器 Load。所以,要更好地使用 Filebeat,我们需要了解 Filebeat 哪些事儿我搞不定 , 哪些事儿我无法承诺 。官方文档是一个非常好的参考: Frequently Asked Questions 。

不建议使用 Filebeat 从网络 Volumes 读取日志文件。 尽可能在主机上安装 Filebeat 并从那里直接发送日志文件。 从网络Volumes 读取文件(尤其是在Windows上)可能会产生意外的副作用。 例如,更改的文件标识符可能导致 Filebeat 再次从头读取日志文件。

这可能是因为 Filebeat 配置不正确或无法将事件发送到 output,解决方案:

/filebeat -c configyml -e -d ""

下面说说 ignore_older 这个配置:

如果启用此选项,Filebeat 将忽略在指定时间跨度之前修改的任何文件。 如果我们将日志文件保留很长时间,那么配置 ignore_older 尤其有用。 例如,如果要启动 Filebeat ,但只想发送最新文件和自上周以来的文件,则可以配置此选项。我们可以使用时间字符串,如 2h(2小时)和 5m(5分钟)。 默认值为 0 ,禁用该设置。 注释掉配置与将其设置为0具有相同的效果。

配置项 close_inactive 表示在 harvester 读取某文件最后一行日志之后,持续时间内某文件没有再写入日志,Filebeat 将关闭文件句柄,默认是 5m。

Filebeat 会持续保持着句柄,以便以便它可以近乎实时地读取新的日志行。如果 Filebeat 正在收集大量文件,则打开的文件数可能会成为问题。在大多数环境中,活动更新的文件数较少。应相应设置 close_inactive 配置选项以关闭不再活动的文件。

还有其他配置选项可以用来关闭文件处理程序,但是所有这些配置选项都应该仔细使用,因为它们可能有副作用。选项是:

close_renamed
close_removed
close_eof
close_timeout
harvester_limit
close_renamed 和 close_removed 选项在 Windows 上可用于解决与 log rotate 相关的问题。请参阅 the section called “Open file handlers cause issues with Windows file rotation 。 close_eof 选项在包含大量文件且只有很少 entries 的环境中很有用。 close_timeout 选项在允许数据丢失且必须对文件句柄关闭非常重视的情况下非常有用。有关更多详细信息,请参阅 Filebeat Prospectors Configuration 。

在使用任何配置选项之前,请确保阅读了这些配置选项的文档。

Filebeat保持每个文件的状态,并将状态保持在 registry_file 中。 Filebeat 重新启动时,文件状态用于继续在先前位置读取文件。 如果每天生成大量的新文件,则 文registry_file 件可能会增长得太大。 要减小 registry_file 的大小,有两个可用的配置选项: clean_removed 和 clean_inactive 。

对于不再 touch 并需要 ignore 的旧文件,建议使用 clean_inactive 。 对于已经从磁盘删除的旧文件,则使用 clean_removed 选项。

在 Linux 文件系统上,Filebeat 使用 inode 和 device 来标识文件。当文件从磁盘中删除时,可以将 inode 分配给一个新文件。在涉及文件轮换的用例中,如果旧文件被删除,并且之后立即创建新文件,则新文件可以具有与被移除的文件完全相同的 inode。在这种情况下,Filebeat 假定新文件与旧文件相同,并尝试在旧 offset 继续读取,这是不正确的。

默认情况下,永远不会从 registry_file 中删除。要解决 inode 复用问题,建议使用 clean_ 选项,特别是 clean_inactive ,以删除非活动文件的状态。例如,如果文件每 24 小时轮换一次,并且轮转的文件不再更新,可以将 ignore_older 设置为48小时,将 clean_inactive 设置为72小时。

对于从磁盘中删除的文件,可以使用 clean_removed 。请注意,每当在扫描期间找不到文件时, clean_removed 会从 registry_file 清除文件状态。如果文件稍后再次显示,则将从头重新发送。

Filebeat 可能被配置为太频繁地扫描文件。 检查 filebeatyml 配置文件中 scan_frequency 的设置。 将 scan_frequency 设置为小于1秒可能导致 Filebeat 扫描磁盘过于频繁。

如果最近执行了 loads 或解析自定义结构化日志的 *** 作,则可能需要刷新索引以使字段在 Kibana 中可用。 要刷新索引,请使用刷新API。 例如:

Filebeat 使用换行符来检测事件的结束。 如果行被递增地添加到正在收集的文件,则最后一行之后需要换行符,否则Filebeat 将不会读取文件的最后一行。

如果需要限制带宽使用,建议在 *** 作系统上配置网络堆栈以执行带宽限制。

例如,以下 Linux 命令通过在端口 5044 上对 TCP 连接设置 50 kbps 的限制来限制 Filebeat 和 Logstash 之间的连接:

使用OS工具执行带宽限制可以更好地控制策略。 例如,可以使用 *** 作系统工具在白天限制带宽,但不能在夜间限制。 或者,可以保留带宽未封顶,但为流量分配低优先级。

以下是一些常见的错误和解决方法:

x509: cannot validate certificate for <IP address> because it doesn’t contain any IP SANs

这是因为证书仅对 Subject filed 中显示的 hostname 有效。要解决此问题,请尝试以下解决方案:

getsockopt: no route to host
这不是SSL问题。这是一个网络问题。确保两个主机可以通信。

getsockopt:connection refused
这不是SSL问题。确保 Logstash 正在运行,并且没有防火墙阻止流量。

No connection could be made because the target machine actively refused it
防火墙拒绝连接。检查防火墙是否阻止客户端,网络或目标主机上的流量。

恢复被删数据方法:

输入指令,curl-XPOST >

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。

Elasticsearch是用Java语言开发的,并作为Apache许可条款下的开放源码发布,是一种流行的企业级搜索引擎。

Elasticsearch用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。官方客户端在Java、NET(C#)、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。

根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr,也是基于Lucene。

软件简介:

Elasticsearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸缩性,能使数据在生产环境变得更有价值。

Elasticsearch 的实现原理主要分为以下几个步骤,首先用户将数据提交到Elasticsearch 数据库中,再通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据,当用户搜索数据时候,再根据权重将结果排名,打分,再将返回结果呈现给用户。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/dianzi/13225629.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-06-23
下一篇 2023-06-23

发表评论

登录后才能评论

评论列表(0条)