• [大数据] ES关闭索引流程源码解析 -- 7.5.1
  • [技术干货] MRS中的Elasticsearch是否支持存算分离
    MRS中的Elasticsearch是否支持存算分离
  • [生态对接] Kibana-oss 6.7.1对接 FusionInsight Elasticsearch6.7.1
    【功能模块】FusionInsight Elasticsearch 6.7.1Kibana 6.7.1linux系统为7.x x86【操作步骤&问题现象】1、按照https://bbs.huaweicloud.com/forum/thread-66788-1-1.html这篇文章的步骤,kibana连接es, 日志报错如下:{"type":"log","@timestamp":"2022-02-23T02:16:25Z","tags":["warning","elasticsearch","admin"],"pid":8726,"message":"Unable to revive connection: http://x.x.x.x:24100/"}2、打开浏览器,访问kibana,http://x.x.x.x:5601,报错如下:Kibana server is not ready yet【截图信息】有谁知道这个问题怎么解决吗?【日志信息】(可选,上传日志内容或者附件)
  • [技术干货] 还在用ES查日志吗,快看看石墨文档 Clickhouse 日志架构玩法
    1 背景石墨文档全部应用部署在Kubernetes上,每时每刻都会有大量的日志输出,我们之前主要使用SLS和ES作为日志存储。但是我们在使用这些组件的时候,发现了一些问题。成本问题:SLS个人觉得是一个非常优秀的产品,速度快,交互方便,但是SLS索引成本比较贵我们想减少SLS索引成本的时候,发现云厂商并不支持分析单个索引的成本,导致我们无法知道是哪些索引构建的不够合理ES使用的存储非常多,并且耗费大量的内存通用问题:如果业务是混合云架构,或者业务形态有SAAS和私有化两种方式,那么SLS并不能通用日志和链路,需要用两套云产品,不是很方便精确度问题:SLS存储的精度只能到秒,但我们实际日志精度到毫秒,如果日志里面有traceid,SLS中无法通过根据traceid信息,将日志根据毫秒时间做排序,不利于排查错误我们经过一番调研后,发现使用Clickhouse能够很好的解决以上问题,并且Clickhouse省存储空间,非常省钱,所以我们选择了Clickhouse方案存储日志。但当我们深入研究后,Clickhouse作为日志存储有许多落地的细节,但业界并没有很好阐述相关Clickhouse采集日志的整套流程,以及没有一款优秀的Clickhouse日志查询工具帮助分析日志,为此我们写了一套Clickhouse日志系统贡献给开源社区,并将Clickhouse的日志采集架构的经验做了总结。先上个Clickhouse日志查询界面,让大家感受下石墨最懂前端的后端程序员。2 架构原理图我们将日志系统分为四个部分:日志采集、日志传输、日志存储、日志管理。日志采集:LogCollector采用Daemonset方式部署,将宿主机日志目录挂载到LogCollector的容器内,LogCollector通过挂载的目录能够采集到应用日志、系统日志、K8S审计日志等日志传输:通过不同Logstore映射到Kafka中不同的Topic,将不同数据结构的日志做了分离日志存储:使用Clickhouse中的两种引擎数据表和物化视图日志管理:开源的Mogo系统,能够查询日志,设置日志索引,设置LogCollector配置,设置Clickhouse表,设置报警等以下我们按照这四大部分,阐述其中的架构原理3 日志采集3.1 采集方式Kubernetes容器内日志收集的方式通常有以下三种方案DaemonSet方式采集:在每个 node 节点上部署LogCollector,并将宿主机的目录挂载为容器的日志目录,LogCollector读取日志内容,采集到日志中心。网络方式采集:通过应用的日志 SDK,直接将日志内容采集到日志中心 。SideCar方式采集:在每个 pod 内部署LogCollector,LogCollector只读取这个 pod 内的日志内容,采集到日志中心。以下是三种采集方式的优缺点:DaemonSet方式    网络方式    SideCar方式采集日志类型    标准输出+文件    应用日志部署运维    一般,维护DaemonSet    低,维护配置文件日志分类存储    可通过容器/路径等映射    业务独立配置支持集群规模    取决于配置数    无限制适用场景    日志分类明确、功能较单一    性能要求极高的场景资源消耗    中    低我们主要采用DaemonSet方式和网络方式采集日志。DaemonSet方式用于ingress、应用日志的采集,网络方式用于大数据日志的采集。以下我们主要介绍下DeamonSet方式的采集方式。 ​3.2 日志输出从上面的介绍中可以看到,我们的DaemonSet会有两种方式采集日志类型,一种是标准输出,一种是文件。 引用元乙的描述:虽然使用 Stdout 打印日志是 Docker 官方推荐的方式,但大家需要注意:这个推荐是基于容器只作为简单应用的场景,实际的业务场景中我们还是建议大家尽可能使用文件的方式,主要的原因有以下几点:Stdout 性能问题,从应用输出 stdout 到服务端,中间会经过好几个流程(例如普遍使用的JSON LogDriver):应用 stdout -> DockerEngine -> LogDriver -> 序列化成 JSON -> 保存到文件 -> Agent 采集文件 -> 解析 JSON -> 上传服务端。整个流程相比文件的额外开销要多很多,在压测时,每秒 10 万行日志输出就会额外占用 DockerEngine 1 个 CPU 核;Stdout 不支持分类,即所有的输出都混在一个流中,无法像文件一样分类输出,通常一个应用中有 AccessLog、ErrorLog、InterfaceLog(调用外部接口的日志)、TraceLog 等,而这些日志的格式、用途不一,如果混在同一个流中将很难采集和分析;Stdout 只支持容器的主程序输出,如果是 daemon/fork 方式运行的程序将无法使用 stdout;文件的 Dump 方式支持各种策略,例如同步/异步写入、缓存大小、文件轮转策略、压缩策略、清除策略等,相对更加灵活。从这个描述中,我们可以看出在docker中输出文件在采集到日志中心是一个更好的实践。所有日志采集工具都支持采集文件日志方式,但是我们在配置日志采集规则的时候,发现开源的一些日志采集工具,例如fluentbit、filebeat在DaemonSet部署下采集文件日志是不支持追加例如pod、namespace、container_name、container_id等label信息,并且也无法通过这些label做些定制化的日志采集。agent类型    采集方式    daemonset部署    sidecar部署ilogtail    文件日志    能够追加label信息,能够根据label过滤采集    能够追加label信息,能够根据label过滤采集fluentbit    文件日志    无法追加label信息,无法根据label过滤采集    能够追加abel信息,能够根据label过滤采集filebeat    文件日志    无法追加label信息,无法根据label过滤采集    能够追加label信息,能够根据label过滤采集ilogtail    标准输出    能够追加label信息,能够根据label过滤采集    能够追加label信息,能够根据label过滤采集fluentbit    标准输出    能够追加label信息,能够根据label过滤采集    能够追加abel信息,能够根据label过滤采集filebeat    标准输出    能够追加label信息,能够根据label过滤采集    能够追加label信息,能够根据label过滤采集基于无法追加label信息的原因,我们暂时放弃了DeamonSet部署下文件日志采集方式,采用的是基于DeamonSet部署下标准输出的采集方式。 ​3.3 日志目录以下列举了日志目录的基本情况目录    描述    类型/var/log/containers    存放的是软链接,软链到/var/log/pods里的标准输出日志    ​标准输出/var/log/pods    存放标准输出日志    ​标准输出/var/log/kubernetes/    master存放Kubernetes 审计输出日志    标准输出/var/lib/docker/overlay2    存放应用日志文件信息    文件日志/var/run    获取docker.sock,用于docker通信    文件日志/var/lib/docker/containers    用于存储容器信息    两种都需要因为我们采集日志是使用的标准输出模式,所以根据上表我们的LogCollector只需要挂载/var/log,/var/lib/docker/containers两个目录。3.3.1 标准输出日志目录应用的标准输出日志存储在/var/log/containers目录下,​文件名是按照K8S日志规范生成的。这里以nginx-ingress的日志作为一个示例。我们通过ls /var/log/containers/ | grep nginx-ingress指令,可以看到nginx-ingress的文件名。  nginx-ingress-controller-mt2wx_kube-system_nginx-ingress-controller-be3741043eca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a.log ​我们参照K8S日志的规范:/var/log/containers/%{DATA:pod_name}_%{DATA:namespace}_%{GREEDYDATA:container_name}-%{DATA:container_id}.log。可以将nginx-ingress日志解析为:pod_name:nginx-ingress-controller-mt2wnamespace:kube-systemcontainer_name:nginx-ingress-controllercontainer_id:be3741043eca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a通过以上的日志解析信息,我们的LogCollector 就可以很方便的追加pod、namespace、container_name、container_id的信息。 ​3.3.2 容器信息目录应用的容器信息存储在/var/lib/docker/containers目录下,目录下的每一个文件夹为容器ID,我们可以通过cat config.v2.json获取应用的docker基本信息。3.4 LogCollector采集日志3.4.1 配置我们LogCollector采用的是fluent-bit,该工具是cncf旗下的,能够更好的与云原生相结合。通过Mogo系统可以选择Kubernetes集群,很方便的设置fluent-bit configmap的配置规则。3.4.2 数据结构​fluent-bit的默认采集数据结构@timestamp字段:string or float,用于记录采集日志的时间log字段:string,用于记录日志的完整内容Clickhouse如果使用@timestamp的时候,因为里面有@特殊字符,会处理的有问题。所以我们在处理fluent-bit的采集数据结构,会做一些映射关系,并且规定双下划线为Mogo系统日志索引,避免和业务日志的索引冲突。_time_字段:string or float,用于记录采集日志的时间_log_字段:string,用于记录日志的完整内容例如你的日志记录的是{"id":1},那么实际fluent-bit采集的日志会是{"_time_":"2022-01-15...","_log_":"{\"id\":1}" 该日志结构会直接写入到kafka中,Mogo系统会根据这两个字段_time_、_log_设置clickhouse中的数据表。3.4.3 采集如果我们要采集ingress日志,我们需要在input配置里,设置ingress的日志目录,fluent-bit会把ingress日志采集到内存里。然后我们在filter配置里,将log改写为_log_ 然后我们在ouput配置里,将追加的日志采集时间设置为_time_,设置好日志写入的kafka borkers和kafka topics,那么fluent-bit里内存的日志就会写入到kafka中日志写入到Kafka中_log_需要为json,如果你的应用写入的日志不是json,那么你就需要根据fluent-bit的parser文档,调整你的日志写入的数据结构:https://docs.fluentbit.io/manual/pipeline/filters/parser4 日志传输Kafka主要用于日志传输。上文说到我们使用fluent-bit采集日志的默认数据结构,在下图kafka工具中我们可以看到日志采集的内容。  在日志采集过程中,会由于不用业务日志字段不一致,解析方式是不一样的。所以我们在日志传输阶段,需要将不同数据结构的日志,创建不同的Clickhouse表,映射到Kafka不同的Topic。这里以ingress为例,那么我们在Clickhouse中需要创建一个ingress_stdout_stream的Kafka引擎表,然后映射到Kafka的ingress-stdout Topic里。5 日志存储我们会使用三种表,用于存储一种业务类型的日志。Kafka引擎表:将数据从Kafka采集到Clickhouse的ingress_stdout_stream数据表中create table logger.ingress_stdout_stream( _source_ String, _pod_name_ String, _namespace_ String, _node_name_ String, _container_name_ String, _cluster_ String, _log_agent_ String, _node_ip_ String, _time_ Float64, _log_ String)engine = Kafka SETTINGS kafka_broker_list = 'kafka:9092', kafka_topic_list = 'ingress-stdout', kafka_group_name = 'logger_ingress_stdout', kafka_format = 'JSONEachRow', kafka_num_consumers = 1;物化视图:将数据从ingress_stdout_stream数据表读取出来,_log_根据Mogo配置的索引,提取字段在写入到ingress_stdout结果表里CREATE MATERIALIZED VIEW logger.ingress_stdout_view TO logger.ingress_stdout ASSELECT    toDateTime(toInt64(_time_)) AS _time_second_,fromUnixTimestamp64Nano(toInt64(_time_*1000000000),'Asia/Shanghai') AS _time_nanosecond_, _pod_name_, _namespace_, _node_name_, _container_name_, _cluster_, _log_agent_, _node_ip_, _source_, _log_ AS _raw_log_,JSONExtractInt(_log_, 'status') AS status,JSONExtractString(_log_, 'url') AS url FROM logger.ingress_stdout_stream where 1=1;结果表:存储最终的数据create table logger.ingress_stdout( _time_second_ DateTime, _time_nanosecond_ DateTime64(9, 'Asia/Shanghai'), _source_ String, _cluster_ String, _log_agent_ String, _namespace_ String, _node_name_ String, _node_ip_ String, _container_name_ String, _pod_name_ String, _raw_log_ String, status Nullable(Int64), url Nullable(String),)engine = MergeTree PARTITION BY toYYYYMMDD(_time_second_)ORDER BY _time_second_TTL toDateTime(_time_second_) + INTERVAL 7 DAYSETTINGS index_granularity = 8192;6 总结流程日志会通过fluent-bit的规则采集到kafka,在这里我们会将日志采集到两个字段里_time_字段用于存储fluent-bit采集的时间_log_字段用于存放原始日志通过mogo,在clickhouse里设置了三个表app_stdout_stream: 将数据从Kafka采集到Clickhouse的Kafka引擎表app_stdout_view: 视图表用于存放mogo设置的索引规则app_stdout:根据app_stdout_view索引解析规则,消费app_stdout_stream里的数据,存放于app_stdout结果表中最后mogo的UI界面,根据app_stdout的数据,查询日志信息7 Mogo界面展示查询日志界面 设置日志采集配置界面以上文档描述是针对石墨Kubernetes的日志采集,想了解物理机采集日志方案的,可以在下文中找到《Mogo使用文档》的链接,运行docker-compose体验Mogo 全部流程,查询Clickhouse日志。限于篇幅有限,Mogo的日志报警功能,下次在讲解。 ​
  • [问题求助] 【香港启德项目】【ES功能】ES里有接近两万条数据,使用ES查询报错
    【功能模块】ES功能【操作步骤&问题现象】1、能效告警调用告警的ES搜索引擎,搜索引擎使用报错,开源ES默认查10000条数据,这查询的数据量也太小了啊2、当告警数据超过 了一万多条,我们这该如何处理,有什么好的处理方案吗?【截图信息】【日志信息】(可选,上传日志内容或者附件)顾庆耀/18068848554/guqingyao@chinasoftinc.com
  • [问题求助] 【香港启德项目】【ES功能】ES里有接近两万条数据,使用ES查询报错
    【功能模块】ES功能【操作步骤&问题现象】1、能效告警调用告警的ES搜索引擎,搜索引擎使用报错2、查询数据库太慢,能帮忙定位下是什么原因吗【截图信息】【日志信息】(可选,上传日志内容或者附件)顾庆耀/18068848554/guqingyao@chinasoftinc.com
  • [问题求助] FusionInsight安全模式ES使用java-transport-client认证问题
    springboot 使用 java-transport-client 读写 FusionInsight HD 6.5.1 安全模式 ES 6.7.1 ,刚启动服务时可以正常读写 ES ,但过一段时间后就报错,错误堆栈如下认证代码复制于样例已替换下面三个包,请问是否替换正确elasticsearch-transport-clientelasticsearchtransport
  • [问题求助] 【香港启德项目】【资产管理资产列表查询功能】通过资产编号查询ES中的数据,有的能查询出来,有的查询不出来
    【功能模块】【资产管理】【资产列表查询功能】【操作步骤&问题现象】1、资产管理中资产列表,有通过资产编号查询条件,从ES中进行查询,有的记录可以查询出来,有的查询不出,不添加资产编号的条件进行查询,都能查询出来2、查询asset101 就能够查询出来,查询NJJN-4F-222就查询不出来,希望拉会议帮忙解决【截图信息】【日志信息】(可选,上传日志内容或者附件)顾庆耀/18068848554/guqingyao@chinasoftinc.com
  • [技术干货] Logstash-OSS 7.16.2(解决Apache Log4j2漏洞)对接华为云CSS(ES 7.6.2)失败问题解决方案
    【背景】Logstash-OSS受Apache Log4j2远程代码影响:https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476,需要由7.10.1版本升级至解决问题版本7.16.2【问题】logstash.conf:output {  elasticsearch{    hosts => ["https://10.33.27.xxx:9200","https://10.33.27.xxy:9200","https://10.33.27.xxz:9200"]    user => "admin"    password => "xxxxx"    cacert => "xxxxx"    ilm_enabled => false    index => "xxxx-%{+YYYY.MM.dd}"    manage_template => true    template_overwrite => true    template_name => "xxxx_template"  }}华为云CSS服务版本为ElasticSearch 7.6.2版本,升级Logstash-OSS版本至7.16.2后,启动失败:[2021-12-27T09:44:20,042][ERROR][logstash.javapipeline][main]Pipelineerror{:pipeline_id=>"main",:exception=>#<LogStash::ConfigurationError:CouldnotconnecttoacompatibleversionofElasticsearch>,:backtrace=>["/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/outputs/Elasticsearch/http_client/pool.rb:247:in blockinhealthcheck!'","org/jruby/RubyHash.java:1415:in each'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/outputs/Elasticsearch/http_client/pool.rb:240:in healthcheck!'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-elasticsearch-11.2.3-java/lib/logstash/outputs/elasticsearch/http_client/pool.rb:374:in update_urls'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/outputs/Elasticsearch/http_client/pool.rb:89:in update_initial_urls'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-elasticsearch-11.2.3-java/lib/logstash/outputs/elasticsearch/http_client/pool.rb:83:in start'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/outputs/Elasticsearch/http_client.rb:359:in build_pool'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-elasticsearch-11.2.3-java/lib/logstash/outputs/elasticsearch/http_client.rb:63:in initialize'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/outputs/Elasticsearch/http_client_builder.rb:106:in create_http_client'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-elasticsearch-11.2.3-java/lib/logstash/outputs/elasticsearch/http_client_builder.rb:102:in build'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-Elasticsearch-11.2.3-java/lib/logstash/plugin_mixins/Elasticsearch/common.rb:34:in build_client'","/home/test/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-output-elasticsearch-11.2.3-java/lib/logstash/outputs/elasticsearch.rb:275:in register'","org/logstash/config/ir/compiler/OutputStrategyExt.java:131:in register'","org/logstash/config/ir/compiler/AbstractOutputDelegatorExt.java:68:in register'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:232:in blockinregister_plugins'","org/jruby/RubyArray.java:1821:in each'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:231:in register_plugins'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:589:in maybe_setup_out_plugins'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:244:in start_workers'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:189:in run'","/home/test/logstash/logstash-core/lib/logstash/java_pipeline.rb:141:in`blockinstart'"],"pipeline.sources"=>["/home/test/conf/logstash.conf"],:thread=>"#<Thread:0x3a3c3828run>"}[2021-12-27T09:44:20,053][INFO][logstash.javapipeline][main]Pipelineterminated{"pipeline.id"=>"main"}[2021-12-27T09:44:20,078][ERROR][logstash.agent]Failedtoexecuteaction{:id=>:main,:action_type=>LogStash::ConvergeResult::FailedAction,:message=>"Couldnotexecuteaction:PipelineAction::Create,action_result:false",:backtrace=>nil}[2021-12-27T09:44:20,188][INFO][logstash.runner]Logstashshutdown.[2021-12-27T09:44:20,201][FATAL][org.logstash.Logstash]Logstashstoppedprocessingbecauseofanerror:(SystemExit)exitorg.jruby.exceptions.SystemExit:(SystemExit)exitatorg.jruby.RubyKernel.exit(org/jruby/RubyKernel.java:747)~[jruby-complete-9.2.20.1.jar:?]atorg.jruby.RubyKernel.exit(org/jruby/RubyKernel.java:710)~[jruby-complete-9.2.20.1.jar:?]athome.test.logstash.lib.bootstrap.environment.(/home/test/logstash/lib/bootstrap/environment.rb:94)~[?:?]官方ReleaseNode:https://www.elastic.co/guide/en/logstash/7.16/logstash-7-13-0.html从7.11版本开始,ES不再提供ElasticSearch-OSS版本:https://github.com/logstash-plugins/logstash-output-elasticsearch/pull/1005Logstash-OSS从7.13.0开始,检查ES license,不再支持对接ElasticSearch-OSS版本,故Logstash-OSS升级至7.16.2后对接失败【解决方案】OpenSearch:https://opensearch.org/OpenSearch is a community-driven, open source search and analytics suite derived from Apache 2.0 licensed Elasticsearch 7.10.2 & Kibana 7.10.2. It consists of a search engine daemon, OpenSearch, and a visualization and user interface, OpenSearch Dashboards. OpenSearch enables people to easily ingest, secure, search, aggregate, view, and analyze data. These capabilities are popular for use cases such as application search, log analytics, and more. With OpenSearch people benefit from having an open source product they can use, modify, extend, monetize, and resell how they want. At the same time, OpenSearch will continue to provide a secure, high-quality search and analytics suite with a rich roadmap of new and innovative functionality.OpenSearch提供Logstash OSS with OpenSearch Ouput Plugin:https://opensearch.org/downloads.html对应Logstash-OSS官方版本+logstash plugin(logstash-output-opensearch:https://github.com/opensearch-project/logstash-output-opensearch)二次打包:https://github.com/opensearch-project/logstash-output-opensearch/blob/main/release/tar/generate-artifact.sh从OpenSearch官方下载:https://artifacts.opensearch.org/logstash/logstash-oss-with-opensearch-output-plugin-7.16.2-linux-x64.tar.gz,或者通过logstash-plugin安装logstash-ouput-opensearch插件。修改logstash.conf:output {  opensearch{    hosts => ["https://10.33.27.xxx:9200","https://10.33.27.xxy:9200","https://10.33.27.xxz:9200"]    user => "admin"    password => "xxxxx"    cacert => "xxxxx"    index => "xxxx-%{+YYYY.MM.dd}"    manage_template => true    template_overwrite => true    template_name => "xxxx_template"  }}启动成功:
  • [问题求助] arm架构的elasticsearch不支持X-Pack怎么设置密码认证访问
    【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [其他问题] 6.5.1版本的Elasticsearch 迁移到MRS8.1.2
    HD 6.5.1版本的Elasticsearch 数据如何才能迁移到MRS8.1.2 ?有什么迁移方案,及详细操作步骤?
  • [运维管理] HD 6.5.1.7 版本 es中oder排序用到的字段类型是整形,是不是会比较慢?
    【操作步骤&问题现象】es中oder排序用到的字段类型是整形,是不是会比较慢?
  • [运维管理] ES集群备份与恢复的问题
    集群环境是FusionInsight 6.5.1 请问备份ES集群的业务数据后,将ES集群删除后重新安装, 可否用这份备份的数据直接恢复数据到新的ES集群。ES的数据恢复有必须是当前集群的要求吗?
  • [环境搭建] ES搭建问题
    FunsionInsight HD6.5.1版本 请问在一个Manager下面可以安装两套ES集群吗?使用ES2ES工具可否在同一Manager下的两套ES集群间迁移数据?请华为的专家帮忙看看,谢谢。
  • [技术干货] 鲲鹏中利用Docker 安装 ES+Head+Kibana小实践
    基于Lucene的搜索服务器因为安装elasticsearch非常耗内存,所以在启动时加一些限制参数:--network somenetwork用来指定一个网络名,用于其他容器访问,如kibana-e #启动参数    ES_JAVA_OPTS="-Xms128m -Xmx512m"    #指定ES在这个容器中运行分配到的最小内存和最大内存docker pull elasticsearch:7.12.1 #创建网络 docker network create esnet docker run -d --name es --network esnet -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms128m -Xmx512m" elasticsearch:7.12.1创建好后查看一下基本情况docker ps docker stats测试一下访问是否正常(记得在安全组中打开对应端口规则)curl localhost:9200公网访问http://IP:9200/安装 kibana免费的开源可视化工具,注意与elasticsearch版本对应docker pull kibana:4.0.2#找到elasticsearch容器的IP,Networks->IPAddress docker inspect es#启动,es传入上一步查到的es地址 docker run -d --name kibana -p 5601:5601 -e "ELASTICSEARCH_URL=http://172.19.0.2:9200" kibana:4.0.2
总条数:146 到第
上滑加载中