Indexation ES

[ASRLO (ROCKS)]

Bonjour,

J'utilise la suite ELK qui va reçoit ses données via un syslog.

J'ai récemment coupé mon cluster ES de 2 nœuds pour finalement n'avoir qu'un seul noeud.

Suite à cela, la volumétrie de mes index sur kibana/ES ne correspond plus à la volumétrie située sur mon syslog sur lequel je récupère les données.

J'ai tenté plusieurs solutions, mais cela n'a pas fonctionné.

Pouvez-vous me venir en aide ?

[ahmed_charafouddine]

Bonjour,

Peut-on voir le setting de ton indexe ?

GET _cat/indices?v

Dans le cas où tes shards n'etaient pas repliqué, possible que le données soient stockées au node 2, celui que tu as stopped.

Ahmed

[ASRLO (ROCKS)]

Bonjour, Oui

Voici le résultat de la command:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open linux-2022.08.30 JH0xDrM0SNirRDIq1EgyNA 1 0 27431 0 15.7mb 15.7mb
green open photocopieur-2022.08.29 -HWsD7PMTMGjb56NRPq4Fg 1 0 14 0 121kb 121kb
green open linux-2022.08.31 JuKxRDqHTVW11jXrB7EU2g 1 0 17675 0 10.7mb 10.7mb
green open .kibana-event-log-7.9.1-000022 8eBMhHWmTR2z9h8mE1WG2Q 1 0 0 0 208b 208b
green open paloalto-2022.08.30 WJg41SEfTvap7tL0xlKG0A 1 0 1774758 0 1.6gb 1.6gb
green open paloalto-2022.08.31 J7SFDnalRm-g2bStlOuqIg 1 0 1023382 0 1.3gb 1.3gb
green open wazuh-alerts-2022.08.29 hr87Eiv9QlGHs4r6e7yASQ 1 0 1712 0 966.9kb 966.9kb
green open .kibana-event-log-7.9.1-000021 pO9MAPjQ0S8wYyumw-3Lg 1 0 0 0 208b 208b
green open .kibana-event-log-7.9.1-000024 jwTha4m4TpSh7B6EtD2RvA 1 0 2 0 10.9kb 10.9kb
green open .kibana-event-log-7.9.1-000023 rvotHORyShm7ItI18rrPNQ 1 0 0 0 208b 208b
green open windows-2022.08.29 57uMYRLkQ26qyYY8p4gQxA 1 0 1533982 0 3.7gb 3.7gb
green open .items-default-000001 t8jAIdk2R8efE-NjMRkbSA 1 0 0 0 208b 208b
green open windows-2022.08.31 tnTxqx4mSUawSwACdkT-A 1 0 1040075 0 2.5gb 2.5gb
green open avaya-2022.08.31 rVl3YMTFS_yEs4bIcul8tw 1 0 1134 0 290.7kb 290.7kb
green open avaya-2022.08.30 AadrpUsKSWi4Hn5VgktJ8Q 1 0 1773 0 349.1kb 349.1kb
green open dcsec-2022.08.29 shRpjAalTK-eecUYL9Gz8Q 1 0 375300 0 798.2mb 798.2mb
green open windows-2022.08.30 7glVPnoUTrWgVXDorjYE7Q 1 0 1614208 0 3.8gb 3.8gb
green open .apm-custom-link ufhrRDdeQS6pXIux3Yq0GA 1 0 0 0 208b 208b
green open .kibana_task_manager_1 wiNM186QS06CD0y51_4nhw 1 0 6 1045 252.9kb 252.9kb
green open wazuh-alerts-2022.08.30 F0za7gG4TuSYv78eLUxauw 1 0 1785 0 1mb 1mb
green open esep-2022.08.29 RgjS7QiNTXCDHzC04KnBJQ 1 0 124 0 176.2kb 176.2kb
green open reverseproxy-2022.08.29 SEH8fGd9Qv-ts39GdB2rWA 1 0 966556 0 187.9mb 187.9mb
green open srvfich-2022.08.29 f90BXhkTSdK7NiSEJYZ0Ag 1 0 49736 0 119.8mb 119.8mb
green open esep-2022.08.31 YpWpl4DMSbW-ENfeeapZAw 1 0 136 0 261.4kb 261.4kb
green open dcsec-2022.08.31 FTztBzPTRHi8g5e3gRcXeA 1 0 379529 0 1gb 1gb
green open dcsec-2022.08.30 ZInjETmeTfWDD67y9zAxCg 1 0 446457 0 932.7mb 932.7mb
green open .lists-default-000001 jlnI_KVLShaDDudReUkKBg 1 0 0 0 208b 208b
green open .apm-agent-configuration vKSL8PyzRVyEcRE9z-3m1Q 1 0 0 0 208b 208b
green open photocopieur-2022.08.31 twxhdxpJTYuCAXzrESBDcQ 1 0 5 0 48.1kb 48.1kb
green open avaya-2022.08.29 9-yaEOH8S_GDPUrts_tf6Q 1 0 6017 0 986.1kb 986.1kb
green open wazuh-alerts-2022.08.31 08AAUHpqSYOgW7C6C-9mXw 1 0 1587 0 1.7mb 1.7mb
green open photocopieur-2022.08.30 lAPI6qBuQwKITbH5wTuaOQ 1 0 13 0 120.4kb 120.4kb
green open esep-2022.08.30 l5XwSwdlQ8KJ_gpBWEANyg 1 0 268 0 360.1kb 360.1kb
green open .kibana_2 9i9bg1-jQs2Qpdjx5mvyQA 1 0 1075 9 10.7mb 10.7mb
green open .kibana_1 yhF6v27ZRy2dPc9blcDxOg 1 0 11 2 10.4mb 10.4mb
green open .kibana_4 oDonsyAYTYSYIiay6lfQBw 1 0 48481 12298 25.3mb 25.3mb
green open .kibana_3 PdI3wzkLT_C3wZ-7Cb-S8A 1 0 1268 3 10.7mb 10.7mb
green open .security-7 EQTornEjRgqijTZsVWWwlg 1 0 52 0 125.3kb 125.3kb
green open paloalto-2022.08.29 RluZZAbGRg27axssRsoJFw 1 0 1984707 0 2.4gb 2.4gb
green open srvfich-2022.08.30 gkKuM4eeT3yG2rKWSe8vzg 1 0 44527 0 105mb 105mb
green open reverseproxy-2022.08.31 ms_92TPpR9qiSElSqmCeDA 1 0 518471 0 107.1mb 107.1mb
green open srvfich-2022.08.31 JMWLLWkeQjeyD1vHPs7yiQ 1 0 32626 0 81.1mb 81.1mb
green open reverseproxy-2022.08.30 qHSYPFShQo2K9cibbSjUCg 1 0 973262 0 194mb 194mb
green open kibana_sample_data_logs JKgnASDXTCeK-CNCFoalqg 1 0 14074 0 11.5mb 11.5mb
green open metrics-index_pattern_placeholder F7tpOaJgRLSoYYn6x7yhAg 1 0 0 0 208b 208b
green open linux-2022.08.29 X0qUp2YjQju9Bc9HyaYPcg 1 0 35993 0 17.4mb 17.4mb
green open .async-search 3s2XdqupQmOpFuBdCB4cHA 1 0 0 0 4.5kb 4.5kb

Chaque jour un nouvel index est crée. Les shards devrait être positionner sur l'unique noeud a ce moment la non ?

Merci de votre réponse

[ahmed_charafouddine]

Par défaut, à partir de la version 7.15 je crois, chaque indexe à 1 shard primary et 0 replicat.

Au départ si tu as lancé ton cluster à 2 nodes, les indexes seront repartis sur les deux nodes. Maintenant, si tes indexes n'ont pas été répliqués et si l'indexe est localisé au node qui est indisponible alors tes données seront également indisponible.

Pour éviter cela, ça serait bien de mettre le replicat à 1 pour tes indexes.

[ahmed_charafouddine]

attention = Qui dit replicat dit utilisation stockage