首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >解密Prompt系列18. LLM Agent之只有智能体的世界

解密Prompt系列18. LLM Agent之只有智能体的世界

原创
作者头像
风雨中的小七
修改于 2023-10-27 12:25:06
修改于 2023-10-27 12:25:06
1.9K00
代码可运行
举报
运行总次数:0
代码可运行

重新回来聊Agent,前四章的LLM Agent,不论是和数据库和模型还是和搜索引擎交互,更多还是大模型和人之间的交互。这一章我们来唠唠只有大模型智能体的世界!分别介绍斯坦福小镇和Chatdev两篇论文。它们的共同特点是使用多个大模型智能体协同完成任务。

多智能相比单一智能体可能有以下的应用场景

  • 协同任务完成/创意生成:通过多智能体间的沟通,反思,校验,完成复杂任务,激发创意的小火花
  • 模拟世界:多智能体模拟社会环境,现实应用是游戏NPC,脑洞再大一点是不是可以用于社会学研究,因果推断,平行世界模拟??

生活番:Generative Agents

Generative Agents: Interactive Simulacra of Human Behavior https://github.com/joonspk-research/generative_agents

斯坦福小镇算是这几个月来看到的最有意思的大模型应用了,作者设计了虚拟的小镇环境,并在其中设计众多不同性格的虚拟智能体,完全基于LLM的生成能力,让众多AI们在小镇中开始了生活,思考和互动。

生活环境和经历塑造了每一个个体,AI也不例外,所以后面的介绍我们会围绕以下三个核心组件相关代码来展开

  • 沙盒环境: 描述AI们的生存环境,并让AI感知当前所处环境,并随AI行动更新环境状态
  • 智能体框架
    • 行为规划:智能体每一步行为的生成
    • 记忆流: 智能体历史记忆的存储

在以上组件的加持下,小镇中的智能体们会发生以下基础行为

  1. 智能体行为:智能体根据当前状态和历史经历,决定下一步是吃饭睡觉还是打豆豆
  2. 智能体互动:智能体间的互动通过交流或指令进行,当智能体处于同一环境中时可能会触发交流对话
  3. 智能体和环境交互:智能体行为会改变环境状态,例如智能体睡觉时,环境中床的状态就会变成“Occupied”。当然我们也可以直接修改环境状态
  4. 智能体规划:想要触发以上1和2的行为和互动,智能体肯定不能在小镇里随机游走。论文的实现是让智能每天都生成一天的Todo List,根据计划行动,并在行动中不断更新当日计划。
  5. 智能体自我思考:通过对历史经历的不断总结和反思得到更高级层次的自我思考,从而影响日常智能体的行为
  6. 其他衍生能力:信息在智能体之间传播,多智能体合作,etc

沙盒环境

这里我们把沙盒环境放到第一个部分,因为个人感觉如何定义环境,决定了

  • Perceive:智能体能接收到哪些环境信息
  • Action:智能体可以做出哪些行为,包括在当前位置行为,和位置移动
  • Influence: 行为可以对环境产生哪些影响
  • 地图(maze.py) 环境本身被抽象成一个二维矩阵,这类二维游戏地图也叫瓦片地图(Tiled Map)。地图上每一个瓦片,都是一个字典存储了该瓦片内的所有信息,以下信息中的events字段都是智能体可以感知,并影响的环境信息。
代码语言:python
代码运行次数:0
运行
AI代码解释
复制
self.tiles[9][58] = {'world': 'double studio', 
'sector': 'double studio', 'arena': 'bedroom 2', 
'game_object': 'bed', 
'spawning_location': 'bedroom-2-a', 
'collision': False,
'events': {('double studio:double studio:bedroom 2:bed', None, None)}} 

同时Maze还存储了一份倒排索引,也就是给定当前智能体当前的地址,需要返回在地图中对应的二维坐标,这样就可以规划智能体从当前位置到某个地点的行动路径。

代码语言:python
代码运行次数:0
运行
AI代码解释
复制
self.address_tiles['<spawn_loc>bedroom-2-a'] == {(58, 9)}
  1. 环境感知(perceive.py) 有了环境,再说下智能体如何感知环境。给定智能体当前在地图中的位置,智能体可以感知周围设定范围内所有瓦片中最新的事件。如果周围发生的事件太多,会先按照和智能体之间的距离排序,选择最近的N个。同时对于智能体之前未感知的事件,会加入到智能体的记忆流中。

记忆流

记忆流的设计算是论文的一大核心,分成以下两个部分

  • 记忆提取:其一是传统的RAG,也就是智能体的每一步行为都需要依赖智能体的历史记忆,如何抽取相关记忆是核心
  • 记忆存储:其二是智能体的记忆除了感知的环境,还包含哪些信息?
记忆提取(retrieve.py)

话接上面的环境感知部分,智能体感知到了周边的环境是第一步,第二步就是用感知到的信息,去召回智能体相关的历史记忆。这里被召回的记忆,除了之前感知的环境和事件,还有思考记忆,思考后面会讲到。召回除了使用embedding相似度召回之外, 记忆召回加入了另外两个打分维度时效性重要性

其中时效性打分是一个指数时间衰减模块,给久远的记忆降权,哈哈时效性打分是个宝,在很多场景下都是相似度的好伴侣,实际应用场景中RAG真的不止是一个Embedding模型就够用的。

重要性打分是基于大模型对每个记忆的重要程度进行打分。打分指令如下

最后在召回打分时,相似度,时效性,重要性进行等权加和,如下

记忆存储 (reflect.py)

智能体记忆流中存储的除了感知到的环境之外,论文还增加了一类很有趣的思考记忆。哈哈不由让我想起了工作中听到的一个梗"老板说不能只干活,你要多思考!!"

触发机制也很有insight,就是每个智能体会有一个重要性Counter,当近期智能体新观察到的各类事件的重要性打分之和超过某个阈值,就触发思考任务。哈哈今天你思考了么?没有的话来学习下智能是如何思考的,对打工人很有启发哟

  • 第一步定位问题??论文取了智能体近100条的记忆,通过指令让模型从中提N个问题。指令如下
代码语言:txt
AI代码解释
复制
Given only the information above, what are !<INPUT 1>! most salient high-level questions we can answer about the subjects grounded in the statements?
1)
  • 第二步反思问题??针对以上N个问题进行相关记忆的抽取,然后基于抽取记忆进行思考。这里允许召回的记忆本身是之前生成的思考,也就是基于思考再思考,基于反思再反思。从这里我真的看好智能体成为天选打工人......
代码语言:txt
AI代码解释
复制
What !<INPUT 1>! high-level insights can you infer from the above statements? (example format: insight (because of 1, 5, 3))
1.

最后生成的思考会存储入记忆流中,用于之后的行为规划或者再进一步的思考。

行为和规划

最后一个模块是行为规划(plan.py),也是最主要的模块,决定了智能体在每一个时间点要做什么,也是之智能体记忆流中的第三种记忆类型

除了基于当前状态去生成下一步行为之外,论文比较有意思的是先规划了智能体每一天的待办事项,然后在执行事项的过程中,进行随机应变。从而保证了智能体在更长时间轴上连续行为的连贯性,一致性,和逻辑关联。

长期规划:每日待办

智能体每日待办事项是通过自上而下的多步拆解,使用大模型指令生成的

第一步,冷启动,根据任务特点,生成智能体的作息时间,如下

第二步,生成小时级别的事项规划。这里并非一次生成所有事项,而是每次只基于智能体的所有静态描述,包括以上生成的生活作息,个人特点等等(下图),和上一个生成事项,来规划下一个事项。模型指令是1-shot,输出事项和事项持续的事件

第三步,是把小时级的事项规划进行事项拆解,拆分成5-分钟级别的待办事项。模型指令同样是1-shot,模板给出一个小时级别任务的拆分方式,让模型去依次对每个小时的事项进行拆解,模型指令中1-shot的部分格式如下:

代码语言:txt
AI代码解释
复制
Today is Saturday May 10. From 08:00am ~09:00am, Kelly is planning on having breakfast, from 09:00am ~ 12:00pm, Kelly is planning on working on the next day's kindergarten lesson plan, and from 12:00 ~ 13pm, Kelly is planning on taking a break. 
In 5 min increments, list the subtasks Kelly does when Kelly is working on the next day's kindergarten lesson plan from 09:00am ~ 12:00pm (total duration in minutes: 180):
1) Kelly is reviewing the kindergarten curriculum standards. (duration in minutes: 15, minutes left: 165)
2) Kelly is brainstorming ideas for the lesson. (duration in minutes: 30, minutes left: 135)
3) Kelly is creating the lesson plan. (duration in minutes: 30, minutes left: 105)
4) Kelly is creating materials for the lesson. (duration in minutes: 30, minutes left: 75)
5) Kelly is taking a break. (duration in minutes: 15, minutes left: 60)
6) Kelly is reviewing the lesson plan. (duration in minutes: 30, minutes left: 30)
7) Kelly is making final changes to the lesson plan. (duration in minutes: 15, minutes left: 15)
8) Kelly is printing the lesson plan. (duration in minutes: 10, minutes left: 5)
9) Kelly is putting the lesson plan in her bag. (duration in minutes: 5, minutes left: 0)

最终分钟级别的待办事项会作为智能体当日的主线行为,写入以上的记忆流中,在之后的每一次行为规划中,提醒智能体,当前时间要干点啥。

短期规划:随机应变

以当日长期行为规划为基础,智能体在按计划完成当日事项的过程中,会不时的感知周围环境。当出现新的观测事件时,智能体需要判断是否需要触发临时行为,并调整计划。这里主要分成两种临时行为:交流和行动。这两种行为的触发会基于智能体当前的状态,和大模型基于上文的指令输出,例如对于是否产生对话行为的判断

当智能体A,出现在当前智能体可以感知的环境范围内时,通过以上的环境感知模块,智能体的记忆流中会出现智能体A的当前行为。这时智能体会在记忆流中检索和智能体A相关的记忆,合并当前状态作为上文,使用大模型指令判断是否要发起和A的对话

如果判断需要发起对话,则触发对话模块进行交流,而交流是所有社会性行为产生的根本。

效果

主要模块基本就说这么多,技术评估就不多说了,在智能体行为上论文验证了当前框架会产生一定的社会效应,包括信息会在智能体之间传播,智能体之间会形成新的关系,以及智能体间会合作完成任务等等。

论文也讨论了当前框架的一些不足,包括如何在更长时间周期上泛化,如何避免智能体犯一些低级错误,例如躺上有人的床哈哈哈哈~

个人感觉还需要讨论的是如何在当前的记忆流中衍生成更高级的,抽象的思考,以及对世界的认知。这些认知是否有更高效,结构化的存储和召回方式。只依赖反思和记忆流的线性存储可能是不够的。

职场番:ChatDev

Communicative Agents for Software Development https://github.com/OpenBMB/ChatDev

哈哈如果说斯坦福小镇对标综艺桃花坞,那ChatDev就是对标令人心动的Offer。论文参考了斯坦福小镇的记忆流,CAMEL的任务导向型对话方案,通过智能体间对话协同完成特定软件开发任务

论文把软件开发流程,抽象成多个智能体的对话型任务。整个开发流程分成设计,编程,测试,文档编写四个大环节,每个环节又可以拆分成多个执行步骤,其中每个步骤都由两个角色的智能体通过对话合作来完成,如下

在进入主要流程前,让我们先完成准备工作。开发流程的准备工作需要定义三类配置文件,源码提供了默认的配置文件,用户可以根据自己的需求,选择覆盖部分配置。配置文件从Top to Bottom分别是

  1. ChatChainConfig:定义了整个任务链的所有步骤和执行顺序(phrase),以及所有参与的智能体角色

以默认配置为例,任务链包含以下步骤:DemandAnalysis -> LanguageChoose -> Coding -> CodeCompleteAll -> CodeReview -> Test -> EnvironmentDoc -> Manual

参与智能体角色包括:CEO,CFO, CPO, CCO, CTO, programmer,Reviewer,Tester等

  1. PhaseConfig:下钻到每个步骤,分别定义了每个步骤的prompt指令,以及参与的两个Agent角色。
  2. RoleConfig:下钻到每个角色,分别定义了每个角色的prompt指令

初始化配置文件后我们进入软件开发的四个主要流程~

Design

产品设计环节,负责把用户需求转化成项目方案,包括两个原子步骤:CEO和CPO进行需求分析和产品设计,CEO和CTO选择编程语言。考虑每个phase的实现其实是相似的,只不过参与智能体不同,以及phase对应的指令和多轮对话形式不同,这里我们只说CEO和CPO之间关于需求分析对话实现(role_play.py)

这里融合了CAMEL的Inception Prompting和斯坦福小镇的记忆流和自我反思来完成任务导向的对话。

  1. Role Assignment

首先初始化参与phase的两个智能体角色,并生成初始prompt(Inception Prompt)。包括用户需求(task_prompt),本阶段的任务描述(phase_prompt)和两个智能体的角色描述(role_prompt)。

基于初始指令,之后两个智能体会通过对话相互为对方生成指令,而人工参与的部分只有最初的角色描述和任务描述,所以叫初始指令。产品涉及环节的具体指令如下,需求分析阶段的任务指令使用了few-shot,给出不同的产品形态例如图片,文档,应用等实现方式,并明确了对话的两个智能体的讨论主题,以及终止讨论的条件,即确定产品形态

以下是论文附录给出的一个需求分析阶段的具体对话示例,不过对话终止符似乎变成了\<END>

  1. Memory Stream

老实说感觉这里的memoery stream和上面小镇中实现的memory stream关联似乎并不是很大。看代码实现,对话是直接使用上文对话history作为输入,只有当输入上文长度超长的时候,会保留Inception prompt和最近的N轮对话......难道是我漏看了代码,如果是请评论指出 >.<

  1. Self-Reflection

小镇中自我反思是为了产生更抽象,更高级的个人思考。而在这篇论文self-Reflection其实更像是会议总结模块,当多轮对话完成,但是并未出现对话停止\<END>符号,这时可以触发总结模块,把前面的多轮对话作为上文,来总结对话得到的结论,用于后续步骤的进行,如下

Coding

编程环节包括两个基本步骤:后端写代码,和前端设计交互界面。编程环节最大的难点就是如何避免模型幻觉,最大正度保证代码的正确性,以及在多轮对话中如何进行复杂长代码的编写和修改。这里同样我们只说下后端编写代码这一个步骤。

代码编写步骤的核心指令如下,CTO智能体给程序员智能体的指令是:以面向对象的编程语言python为基础,先给出核心类和方法。程序员智能体会按照指令以markdown为语法进行代码和注释的编写。之后代码编写环节会循环执行N次多轮对话,不断对代码进行更新优化。

在指令的基础上,为了优化复杂代码的编写效果,论文在代码编写环节引入了version control环节。在每一步代码编写完成后,会使用difflib对两版代码进行比对,并从记忆流中删除旧版本的代码,这样对话会永远基于最新的代码版本进行,对最新代码进行不断更新。

Testing

测试环节包括两个基本步骤:代码评审和测试环节。

评审环节,程序员智能体会给评审智能体指令,让其对代码进行检查,例如是否有未实现的类或方法,以及整个项目是否符合用户需求等等(角色指令如下图),并给出评审建议。其次程序员之智能体会基于以上建议对代码进行调整。

测试环节是基于代码执行后出现的bug进行修复。论文在这里引入了Thought Instruction,有点类似Decomposed Prompt的任务拆分。因为如果直接基于代码执行bug让大模型进行修复,问题可能过于复杂导致模型无法直接修复,或者产生幻觉。因此通过多轮对话引入一步任务拆分,先经过TestErrorSummary步骤对测试bug的位置和产生原因进行总结,再基于以上总结进行代码调整。

Documentation

文档生成环节就比较简单了,包括多个phase步骤,一个phase对应一类文档说明。这里使用了few-shot指令来引导智能体生成requirements.txt, README.MD等用户文档,以下是生成requirements.txt的指令示例

效果

效果上ChatDev从CAMEL编程相关的任务中随机抽了70个任务进行测试,任务平均代码量是131行代码,4个文件,3个上游依赖库,说明ChatDev整体生成的软件还是偏简单,小型,不涉及复杂的设计。具体效果大家可以直接去Chatdev的代码库里给的生成案例感受下。在这样的代码复杂度下,ChatDev最终代码的执行成功率在86% ,平均任务完成时间在7分钟左右,且调用成本相对较低。

除了以上提到了两个比较火爆的多智能体协同应用,还有很多相关应用和开源实现,这里就不一一介绍了,感兴趣的同学可以去自己试试看

  • AgentSims:国内开源的类似斯坦福小镇
  • AgentVerse:多模型交互环境
  • MetaGPT:覆盖软件公司全生命流程,例如产品经理等各个职业的AutoGPT
  • CAMEL:任务导向型,沟通式多智能体协同框架,Chatdev的基础

想看更全的大模型相关论文梳理·微调及预训练数据和框架·AIGC应用,移步Github >> DecryPrompt

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
搭建ELK日志分析平台并收集Nginx日志
一般我们需要进行日志分析场景:直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中,此方法效率低下,面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理,所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统,将所有节点上的日志统一收集,管理,访问。
子润先生
2021/07/08
1K0
Centos 7.3 简便搭建EFK日志分析
EFK 不是一个软件,而是一套解决方案。EFK 是三个开源软件的缩写,Elasticsearch,FileBeat,Kibana。其中 ELasticsearch 负责日志分析和存储,FileBeat 负责日志收集,Kibana 负责界面展示。它们之间互相配合使用,完美衔接,高效的满足了很多场合的应用,是目前主流的一种日志分析系统解决方案。 EFK 和 ELK 只有一个区别, 收集日志的组件由 Logstash 替换成了 FileBeat,因为 Filebeat 相对于 Logstash 来说有2个好处:
小手冰凉
2020/03/06
1.9K0
Centos 7.3 简便搭建EFK日志分析
kubernetes Filebeat+ELK日志收集监控方案
接收来自filebeat的数据,根据其中的tags进行分类,再添加index进行分类,例如nginx-access-%{+YYYY.MM.dd},在kibana中会根据这个index获取日志。
kubernetes中文社区
2019/06/24
3.2K0
kubernetes  Filebeat+ELK日志收集监控方案
ELK+FileBeat日志分析系统(正式环境nginx日志)
ElasticSearch、Logstash和Kibana 这里还用到一个插件那就是filebeat进行进行采集日志 添加filebeat插件现在已经是非常提倡的做法
全栈程序员站长
2021/06/08
5940
ELK+FileBeat日志分析系统(正式环境nginx日志)
elk+filebeat+grafana日志收集平台学习笔记
node1:elasticsearch6.4+filebeat node2:kibana6.4+grafana+filebeat node3:logstash+nginx+filebeat+Redis 由于es很消耗内存,所以我只把es单独运行在一个主机上,并设置主分片为1,副本分片为0,每周定时删除上周的索引数据
没有故事的陈师傅
2019/07/27
3.9K0
Elasticsearch Logstash Kibana Filebeat 搭建
ELK+Filebeat的流程应该是这样的:Filebeat->Logstash->(Elasticsearch<->Kibana)由我们自己的程序产生出日志,由Filebeat进行处理,将日志数据输出到Logstash中,Logstash再将数据输出到Elasticsearch中,Elasticsearch再与Kibana相结合展示给用户。
BUG弄潮儿
2020/06/15
1.7K0
Elasticsearch Logstash Kibana Filebeat 搭建
ELK实时日志管理-系统搭建
Filebeat轻量级的日志传输工具,可以读取系统、nignx、apache等logs文件,监控日志文件,传输数据到Elasticsearch或者Logstash,最后在Kibana中实现可视化。
WindCoder
2018/09/19
1.7K0
ELK实时日志管理-系统搭建
部署elk平台
说明 对于ELK部署使用而言,下面是一个再常见不过的架构了 Redis:接收用户日志的消息队列。 Logstash:做日志解析,统一成JSON输出给Elasticsearch。 Elasticsear
零月
2018/04/25
1.5K0
部署elk平台
EFK(Elasticsearch+Filebeat+Kibana)日志收集系统
Elasticsearch 是一个实时的、分布式的可扩展的搜索引擎,允许进行全文、结构化搜索,它通常用于索引和搜索大量日志数据,也可用于搜索许多不同类型的文档。
Java架构师必看
2021/06/10
20.2K2
EFK(Elasticsearch+Filebeat+Kibana)日志收集系统
kubernetes-平台日志收集ELK(十七)
使用ELK Stack收集Kubernetes平台中日志与可视化 K8S系统的组件日志 K8S Cluster里面部署的应用程序日志 日志系统: ELK安装 安装jdk [root@localhost
yuezhimi
2020/09/30
6290
ELK+filebeat采集java日志
此文章是我在生产环境下搭建ELK日志系统的记录,该日志系统主要是采集Java日志,开发人员能通过kibanaWeb页面查找相关主机的指定日志;对于Java日志,filebeat已做多行合并、过滤行处理,更精准的获取需要的日志信息,关于ELK系统的介绍,这里不再赘述。
肓己
2021/08/12
1.8K0
Docker 入门到实战教程(十二)ELK+Filebeat搭建日志分析系统
一般我们需要进行日志分析场景:直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中,此方法效率低下,面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理,所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统,将所有节点上的日志统一收集,管理,访问。
小东啊
2020/07/23
4.9K1
Docker 入门到实战教程(十二)ELK+Filebeat搭建日志分析系统
搭建ELK日志分析平台(下)—— 搭建kibana和logstash服务器
笔记内容:搭建ELK日志分析平台——搭建kibana和logstash服务器 笔记日期:2018-03-03
端碗吹水
2020/09/23
3.6K0
搭建ELK日志分析平台(下)—— 搭建kibana和logstash服务器
fliebeat+kafka的ELK日志分析平台(上)
当前结构,Filebeat部署在需要收集日志的机器上,收集日志,输出到zk+kakfa集群这个中间件中。logstash从kafka集群消费信息,并根据配置内容,进行格式转化和过滤,整理好的数据会发给elastic进行存储。elastic能对大容量的数据进行接近实时的存储、搜索和分析操作。最后由kibana提供web界面,调用elastic做数据分析,然后展示出来。
陈不成i
2021/07/05
5150
容器部署日志分析平台ELK7.10.1(Elasisearch+Filebeat+Redis+Logstash+Kibana)
  ELK日志分析系统是Logstash、Elastcsearch、Kibana开源软件的集合,对外是作为一个日志管理系统的开源方案,它可以从任何来源、任何格式进行日志搜索、分析与可视化展示。
非著名运维
2022/06/22
1.4K0
容器部署日志分析平台ELK7.10.1(Elasisearch+Filebeat+Redis+Logstash+Kibana)
搭建ELK日志分析系统
ELK Stack 是Elasticsearch、Logstash、Kiban三个开源软件的组合。在实时数据检索和分析场合,三者通常是配合共用,而且又都先后归于 Elastic.co 公司名下,故有此简称。 ELK Stack成为机器数据分析,或者说实时日志处理领域,开源界的第一选择。和传统的日志处理方案相比,ELK Stack 具有如下几个优点: • 处理方式灵活。Elasticsearch 是实时全文索引,不需要像 storm 那样预先编程才能使用; • 配置简易上手。Elasticsearch 全部采用 JSON 接口,Logstash 是 Ruby DSL 设计,都是目前业界最通用的配置语法设计; • 检索性能高效。虽然每次查询都是实时计算,但是优秀的设计和实现基本可以达到全天数据查询的秒级响应; • 集群线性扩展。不管是 Elasticsearch 集群还是 Logstash 集群都是可以线性扩展的; • 前端操作炫丽。Kibana 界面上,只需要点击鼠标,就可以完成搜索、聚合功能,生成炫丽的仪表板。 官网地址:https://www.elastic.co/cn/ 官网权威指南: https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html 安装指南: https://www.elastic.co/guide/en/elasticsearch/reference/6.x/rpm.html Elasticsearch是实时全文搜索和分析引擎,提供搜集、分析、存储数据三大功能;是一套开放REST和JAVA API等结构提供高效搜索功能,可扩展的分布式系统。它构建于Apache Lucene搜索引擎库之上。 Logstash是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志,包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志,这些来源包括 syslog、消息传递(例如 RabbitMQ)和JMX,它能够以多种方式输出数据,包括电子邮件、websockets和Elasticsearch。 Kibana是一个基于Web的图形界面,用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。它利用Elasticsearch的REST接口来检索数据,不仅允许用户创建他们自己的数据的定制仪表板视图,还允许他们以特殊的方式查询和过滤数据。
菲宇
2019/06/11
1.3K0
搭建ELK日志分析系统
CentOS7搭建ELK-6.2.3版本
ELK是ElasticSerach、Logstash、Kibana三款产品名称的首字母集合,用于日志的搜集和搜索,今天我们一起搭建和体验基于ELK的日志服务;
程序员欣宸
2022/05/09
5460
CentOS7搭建ELK-6.2.3版本
ELK日志监控分析系统的探索与实践(一):利用Filebeat监控Springboot日志
由于公司项目较多,所部署服务产生的日志也较多,以往查看服务器日志只能通过xshell、putty等SSH工具分别连接每台服务器,然后进入到各个服务器,执行Linux命令查看日志,这样可能会带来以下问题:
大刚测试开发实战
2022/11/14
3K1
ELK日志监控分析系统的探索与实践(一):利用Filebeat监控Springboot日志
ELK学习笔记之CentOS 7下ELK(6.2.4)++LogStash+Filebeat+Log4j日志集成环境搭建
现在的公司由于绝大部分项目都采用分布式架构,很早就采用ELK了,只不过最近因为额外的工作需要,仔细的研究了分布式系统中,怎么样的日志规范和架构才是合理和能够有效提高问题排查效率的。
Jetpropelledsnake21
2018/12/05
2.1K0
ELK学习笔记之CentOS 7下ELK(6.2.4)++LogStash+Filebeat+Log4j日志集成环境搭建
7000 字 | 20 图 | 一文带你搭建一套 ELK Stack 日志平台
最近在折腾 ELK 日志平台,它是 Elastic 公司推出的一整套日志收集、分析和展示的解决方案。
悟空聊架构
2022/05/13
9740
7000 字 | 20 图 | 一文带你搭建一套 ELK Stack 日志平台
推荐阅读
相关推荐
搭建ELK日志分析平台并收集Nginx日志
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档