zoukankan      html  css  js  c++  java
  • ElasticSearch配置

    设置JVM:
    修改jmv.options配置文件,位置在config/jvm.options
     
    以 - 开头的,被视为独立于JVM版本而应用的JVM选项                                                          -Xmx2g
    以数字开头, :后接 - 的行,被视为仅在JVM版本与该数字匹配时才适用的JVM选项             8 : -Xmx2g
    以数字开头,- 后接 : - 的行,被视为JVM选项,仅当JVM版本大于或等于该数字时才适用    8 - : - Xmx2g
    以数字开头, - 后接数字, 再跟 - 的行,被视为JVM选项,仅当JVM版本在两个数字范围内时才适用    8 - 9 : - Xmx2g
    其他所有行均被拒绝
     
    安全设置:
    ·某些设置是敏感的,仅依靠文件系统权限来保护其值是不够的。Elasticsearch提供了密钥库和用于管理密钥库中设置的elasticsearch-keystore工具。
    ·这些设置与elasticsearch.yml配置文件中的常规设置一样,需要在集群的每个节点上指定。当前,所有安全设置都是特定于节点的设置,在每个节点上必须具有相同的值。
    ·仅在重新启动Elasticsearch之后,对密钥库的所有修改才会生效。
    ·Elasticsearch密钥库当前仅提供混淆。将来将添加密码保护。
     
    bin/elasticsearch-keystore
    创建keystore
    create
    参数编辑
    add <setting>
    将设置添加到密钥库。默认情况下,系统会提示您输入设置的值。
    add-file <setting> <path>
    将文件添加到密钥库。
    -h, --help
    返回所有命令参数。
    list
    列出密钥库中的设置。
    remove <setting>
    从密钥库中删除设置。
    -s, --silent
    显示最小输出。
    --stdin
    与add参数一起使用时,可以通过标准输入(stdin)传递设置值。请参阅将设置添加到密钥库。
    upgrade
    升级密钥库的内部格式。
    -v, --verbose
    显示详细输出。
     
    bin/elasticsearch-keystore create  在elasticsearch.keystore文件旁边创建一个elasticsearch.yml 文件
    bin/elasticsearch-keystore list
    bin/elasticsearch-keystore add the.setting.name.to.set
    cat /file/containing/setting/value | bin/elasticsearch-keystore add --stdin the.setting.name.to.set
    bin/elasticsearch-keystore add-file the.setting.name.to.set /path/example-file.json
    bin/elasticsearch-keystore remove the.setting.name.to.remove
    bin/elasticsearch-keystore upgrade
     
    对密钥库内容的更改不会自动应用于正在运行的Elasticsearch节点。重新读取设置需要重新启动节点。但是,某些安全设置被标记为 可重载。可以重新读取此类设置并将其应用到正在运行的节点上。
    所有安全设置(可重新加载或不可重新加载)的值在所有群集节点上必须相同。进行所需的安全设置更改后,使用以下bin/elasticsearch-keystore add命令,调用:  curl -X POST "localhost:9200/_nodes/reload_secure_settings?pretty"
    该API在每个群集节点上解密并重新读取整个密钥库,但仅应用可重载的安全设置。直到下一次重新启动,对其他设置的更改才会生效。调用返回后,重新加载已完成,这意味着依赖于这些设置的所有内部数据结构均已更改。从头开始,所有设置看起来都应该具有新值。
    更改多个可重新加载的安全设置时,请在每个群集节点上修改所有这些设置,然后发出reload_secure_settings呼叫,而不是在每次修改后重新加载。
     
    日志配置:
    Elasticsearch使用Log4j 2进行日志记录。可以使用log4j2.properties文件配置Log4j 2。Elasticsearch公开三个属性${sys:es.logs.base_path}, ${sys:es.logs.cluster_name}以及${sys:es.logs.node_name}可以在配置文件中引用,以确定日志文件的位置。该属性${sys:es.logs.base_path}将解析为日志目录, ${sys:es.logs.cluster_name}将解析为群集名称(在默认配置中用作日志文件名的前缀), ${sys:es.logs.node_name}并将解析为节点名称(如果显式设置了节点名称)。
    例如,如果你的日志目录(path.logs)是/var/log/elasticsearch和您的群集名为production然后${sys:es.logs.base_path}将解析/var/log/elasticsearch和 ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}.log 将解析/var/log/elasticsearch/production.log。
    #配置RollingFile附加器
    appender.rolling.type = RollingFile
    appender.rolling.name = rolling
    #登录到 /var/log/elasticsearch/production_server.json
    appender.rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_server.json
    #使用JSON布局
    appender.rolling.layout.type = ESJsonLayout
    #type_name是标记中type字段的标志ESJsonLayout。解析日志时,可以使用它更轻松地区分不同类型的日志
    appender.rolling.layout.type_name = server
    #将日志滚动到/var/log/elasticsearch/production-yyyy-MM-dd-i.json; 日志将在每卷上压缩并i递增
    appender.rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}-%d{yyyy-MM-dd}-%i.json.gz
    appender.rolling.policies.type = Policies
    #使用基于时间的滚动策略
    appender.rolling.policies.time.type = TimeBasedTriggeringPolicy
    #每天滚动日志
    appender.rolling.policies.time.interval = 1
    #在天数边界上对齐滚动(而不是每24小时滚动一次)
    appender.rolling.policies.time.modulate = true
    #使用基于大小的滚动策略
    appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
    #256 MB后滚动日志
    appender.rolling.policies.size.size = 256MB
    appender.rolling.strategy.type = DefaultRolloverStrategy
    appender.rolling.strategy.fileIndex = nomax
    #滚动日志时使用删除操作
    appender.rolling.strategy.action.type = Delete
    appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
    #仅删除与文件模式匹配的日志
    appender.rolling.strategy.action.condition.type = IfFileName
    #模式是仅删除主日志
    appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-*
    #仅当我们累积了太多压缩日志时才删除
    appender.rolling.strategy.action.condition.nested_condition.type = IfAccumulatedFileSize
    #压缩日志的大小条件为2 GB
    appender.rolling.strategy.action.condition.nested_condition.exceeds = 2GB
    可以在appender .rolling中将.gz替换为.zip。filePattern使用zip格式压缩已滚动的日志。如果您删除了.gz扩展名,那么日志在滚动时将不会被压缩
     
    如果希望将日志文件保留指定的一段时间,可以使用带有删除操作的滚动策略
    #配置DefaultRolloverStrategy
    appender.rolling.strategy.type = DefaultRolloverStrategy
    #配置处理滚动的删除操作
    appender.rolling.strategy.action.type = Delete
    #到Elasticsearch日志的基本路径
    appender.rolling.strategy.action.basepath = ${sys:es.logs.base_path}
    #处理滚动时应用的条件
    appender.rolling.strategy.action.condition.type = IfFileName
    #从匹配glob ${sys: .logs.cluster_name}-*的基本路径中删除文件;这是日志文件被滚动到的glob;只需要删除滚动的Elasticsearch日志,而不需要删除弃用和慢速日志
    appender.rolling.strategy.action.condition.glob = ${sys:es.logs.cluster_name}-*
    #用于匹配glob的文件的嵌套条件
    appender.rolling.strategy.action.condition.nested_condition.type = IfLastModified
    #将日志保留7天
    appender.rolling.strategy.action.condition.nested_condition.age = 7D
     
    配置日志记录级别
    有四种配置日志记录级别的方法,每种方法都有适合使用的情况。
    1. 通过命令行:(-E <name of logging hierarchy>=<level>例如, -E logger.org.elasticsearch.transport=trace)。当您临时调试单个节点上的问题(例如,启动问题或开发过程中)时,这是最合适的。
    2. 通过elasticsearch.yml:(<name of logging hierarchy>: <level>例如, logger.org.elasticsearch.transport: trace)。当您临时调试问题但未通过命令行(例如,通过服务)启动Elasticsearch或希望更永久地调整日志记录级别时,这是最合适的。
    3. 通过集群设置:
    PUT /_cluster/settings
    {
      "transient": {
        "<name of logging hierarchy>": "<level>"
      }}
     
    4.通过log4j2.properties:
    logger.<unique_identifier>.name = <name of logging hierarchy>
    logger.<unique_identifier>.level = <level>
     
    启用审核日志记录:
    记录与安全性有关的事件,例如身份验证失败和连接被拒绝,以监视群集中的可疑活动。审计日志还可以在发生攻击时提供法证证据
    在elasticsearch.yml中设置xpack.security.audit.enabled为true
    启用审核日志记录后,安全事件将持久保存到<clustername>_audit.json主机文件系统上(每个节点上)的专用文件中
     
    跨集群复制:
     
    索引生命周期管理:
    集群级别设置:
    xpack.ilm.enabled    禁用任何ILM REST API端点和功能。默认为true
    indices.lifecycle.poll_interval    索引生命周期管理检查符合策略标准的索引的频率。默认为10m
    indices.lifecycle.history_index_enabled    是否启用ILM的历史索引。如果启用,ILM会将作为ILM策略一部分而采取的操作的历史记录到ilm-history-* 索引中。默认为true。
     
    索引级别设置:
    index.lifecycle.name
    用于管理索引的策略的名称。
    index.lifecycle.rollover_alias
    索引翻转时要更新的索引别名。在使用包含过渡操作的策略时指定。当索引翻转时,别名将更新以反映该索引不再是写索引。有关过渡的更多信息,请参见配置过渡。
    index.lifecycle.parse_origination_date
    当配置为true原始日期时,将从索引名称中解析。索引格式必须与模式匹配^.*-{date_format}-\d+,其中date_formatis yyyy.MM.dd和结尾数字是可选的(经过翻转的索引通常会与完整格式匹配,例如 logs-2016.10.31-000002)。如果索引名称与模式不匹配,则索引创建将失败。
    index.lifecycle.origination_date
    将用于计算其相变的索引寿命的时间戳。这使用户可以创建包含旧数据的索引,并使用旧数据的原始创建日期来计算索引使用期限。必须为长(Unix纪元)值。
     
    创建生命周期策略:
    使用ILM自动进行滚动和时间序列索引管理:
    1. 创建定义适当阶段和操作的生命周期策略。
    2. 创建一个索引模板,将策略应用于每个新索引。
    3. 引导索引作为初始写索引。
    4. 验证索引是否 按预期在生命周期阶段中移动。
     
    创建生命周期策略编辑:
    生命周期策略指定索引生命周期中的各个阶段以及每个阶段要执行的操作。生命周期最多可以有四个阶段: hot,warm,cold,和delete。
    可以通过Kibana Management UI定义和管理策略,该UI调用ILM 放置策略 API来根据您指定的选项创建策略。
    例如,可以定义一个timeseries_policy具有两个阶段的:
    * 一个hot阶段,用于定义过渡操作,以指定索引达到max_size50 GB或max_age30天时将进行翻转。
    * 一个delete阶段,设置min_age为在过渡90天后删除索引。请注意,该值是相对于过渡时间而不是索引创建时间的。
    curl -X PUT "localhost:9200/_ilm/policy/datastream_policy?pretty" -H 'Content-Type: application/json' -d'
    {
      "policy": {
        "phases": {
          "hot": {                      
            "actions": {
              "rollover": {
                "max_size": "50GB",     
                "max_age": "30d"
              }
            }
          },
          "delete": {
            "min_age": "90d",           
            "actions": {
              "delete": {}              
            }
          }
        }
      }
    }
    '
    1.该min_age默认为0ms,所以新指数进入hot立即阶段。
    2.rollover满足任何一个条件时触发动作。
    3.delete过渡后90天将索引移入阶段。
    4.delete当索引进入删除阶段时触发操作。
    索引生命周期管理可以执行的操作的完整列表:  https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-actions.html
     
    创建索引模板以应用生命周期策略编辑:
    要在过渡时将生命周期策略自动应用于新的写索引,请在索引模板中指定用于创建新索引的策略。
    例如,可以创建一个timeseries_template应用于名称与timeseries-*索引模式匹配的新索引。
    要启用自动翻转,该模板配置两个ILM设置:
    * index.lifecycle.name 指定生命周期策略的名称,以应用于与索引模式匹配的新索引。
    * index.lifecycle.rollover_alias 指定在触发索引的过渡操作时要过渡的索引别名。
    可以使用Kibana创建模板向导来添加模板。该向导调用放置模板API,以使用指定的选项创建模板。
    curl -X PUT "localhost:9200/_template/datastream_template?pretty" -H 'Content-Type: application/json' -d'
    {
      "index_patterns": ["datastream-*"],                 
      "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 1,
        "index.lifecycle.name": "datastream_policy",      
        "index.lifecycle.rollover_alias": "datastream"    
      }
    }
    '
     
    1.如果模板名称以开头,则将其应用于新索引datastream-。
    2.应用于每个新索引的生命周期策略的名称。
    3.用于引用这些索引的别名的名称。使用过渡操作的策略是必需的。
     
    引导初始时间序列索引编辑:
    要开始,您需要引导一个初始索引,并将其指定为索引模板中指定的过渡别名的写索引。该索引的名称必须与模板的索引模式匹配,并以数字结尾。过渡时,此值将递增以生成新索引的名称。
    例如,以下请求创建一个名为的索引,datastream-000001 并使其成为datastream别名的写索引
    curl -X PUT "localhost:9200/datastream-000001?pretty" -H 'Content-Type: application/json' -d'
    {
      "aliases": {
        "datastream": {
          "is_write_index": true
        }
      }
    }
    '
    当满足过渡条件时,将执行以下rollover操作:
    * 创建一个名为的新索引datastream-000002。这与datastream-*模式匹配,因此from datastream_template中的设置将应用于新索引。
    * 将新索引指定为写索引,并使引导索引为只读。
    每当满足过渡条件时,都会重复此过程。您可以datastream_policy使用datastream别名搜索由管理的所有索引。写操作被路由到当前的写索引
     
  • 相关阅读:
    ROS配置C++14环境
    ubantu查看环境变量
    C++指向函数的指针
    ubantu删除文件(夹)
    ROS环境搭建
    vmware workstation pro 安装ubantu虚拟机
    Win7下删除Ubuntu启动项
    ubantu16.04
    ubantu卸载软件
    github之克隆
  • 原文地址:https://www.cnblogs.com/gqymy/p/12891228.html
Copyright © 2011-2022 走看看