Index загвар ба index set-ийг Security Data Lake-д хэрхэн удирдах вэ?

Security Data Lake хайлт, шинжилгээний ажиллагааг хурдан, нөөц бага зарцуулахаар нэг буюу хэд хэдэн index-ийн багцыг автоматаар удирддаг.

Өөр өөр mapping, analyzer, replication тохиргоо-той index-үүдийг удирдахын тулд Security Data Lake нь эдгээр бүх тохиргоог нэгтгэсэн index set-ийг ашигладаг. Index-ийн анхдагч тохиргооны загвар үүсгэх талаар Index Set Templates хэсгээс үзнэ үү.

Index Set

Index set бүр Security Data Lake-д хайлтын backend-ийн index-үүдийг үүсгэх, удирдах, бөглөх, мөн таны шаардлагад нийцүүлэн index-ийн rotation (шинэчлэн солилт) болон өгөгдөл хадгалалтыг зохицуулахад шаардлагатай тохиргоог агуулна.

Security Data Lake нь index set бүрт index alias хөтөлдөг бөгөөд энэ нь тухайн index set-ийн одоогийн бичих боломжтой (write-active) index-ийг үргэлж заана. Тохируулсан rotation шалгуур (баримтын тоо, index-ийн хэмжээ эсвэл index-ийн нас) хангагдтал шинэ мессежүүд яг нэг index руу бичигдэнэ.

Фон дээр ажилладаг даалгавар index set-ийн rotation шалгуур хангагдсан эсэхийг тасралтгүй шалгадаг бөгөөд хангагдвал шинэ index үүсгэж бэлтгэнэ. Index бэлэн болмогц index alias автоматаар түүн рүү шилжинэ. Иймээс Security Data Lake-ийн бүх node одоогийн write-active index аль нь болохыг мэдэхгүйгээр alias руу мессеж бичиж чадна.

Бараг бүх унших үйлдэл тодорхой хугацааны завсартай хийгддэг. Security Data Lake мессежийг хайлтын backend руу дарааллаар бичдэг тул index бүр ямар хугацааг хамарч байгаа тухай мэдээллийг хадгалж чадна. Хугацааны завсар өгөгдсөн үед хайх index-үүдийн жагсаалтыг түүгээр сонгоно. Хугацааны завсар өгөөгүй бол бүх мэдэгдэж буй index-үүдээс хайна.

Index болон мессежийг устгах

Security Data Lake-ийн нэг index set-д удирдах index-ийн дээд тоог тохируулах тохиргоо бий.

Тохируулсан хадгалалтын стратегиас хамааран index-ийн дээд тоонд хүрмэгц тухайн index set-ийн хамгийн хуучин index-үүд автоматаар хаагдах, устгагдах эсвэл экспортлогдоно.

Устгалтыг Security Data Lake-ийн leader node фон дээрх thread-ээр гүйцэтгэдэг бөгөөд index-ийн тоог тохируулсан дээд тоотой тасралтгүй харьцуулж байдаг:

INFO : org.graylog2.indexer.rotation.strategies.AbstractRotationStrategy - Deflector index <graylog_95> should be rotated, Pointing deflector to new index now!
INFO : org.graylog2.indexer.MongoIndexSet - Cycling from <graylog_95> to <graylog_96>.
INFO : org.graylog2.indexer.MongoIndexSet - Creating target index <graylog_96>.
INFO : org.graylog2.indexer.indices.Indices - Created Graylog index template "graylog-internal" in Elasticsearch.
INFO : org.graylog2.indexer.MongoIndexSet - Waiting for allocation of index <graylog_96>.
INFO : org.graylog2.indexer.MongoIndexSet - Index <graylog_96> has been successfully allocated.
INFO : org.graylog2.indexer.MongoIndexSet - Pointing index alias <graylog_deflector> to new index <graylog_96>.
INFO : org.graylog2.system.jobs.SystemJobManager - Submitted SystemJob <f1018ae0-dcaa-11e6-97c3-6c4008b8fc28> [org.graylog2.indexer.indices.jobs.SetIndexReadOnlyAndCalculateRangeJob]
INFO : org.graylog2.indexer.MongoIndexSet - Successfully pointed index alias <graylog_deflector> to index <graylog_96>.

Index Set-ийн тохиргоо

Index set нь Security Data Lake мессежийг хайлтын backend кластерт хэрхэн хадгалахтай холбоотой олон сонголттой. Эдгээр set-ийг System > Indices руу орж, Indices & Index Sets хуудаснаас удирдна.

Шинэ set үүсгэхийн тулд хуудасны баруун дээд булангийн Create index set товчийг дарна. Дараа нь index set үүсгэхийн тулд дараах талбаруудыг бөглөнө:

• Title: Index set-ийн тайлбарлах нэр.
• Description: Index set-ийн хүнд зориулсан тайлбар.
• Index prefix: Index set-ийн удирддаг хайлтын backend index-үүдийн давтагдахгүй угтвар. Угтвар үсэг эсвэл тоогоор эхэлж, зөвхөн үсэг, тоо, _, -, + агуулж болно. Index alias-ийн нэр үүний дагуу бий болно, жишээ нь угтвар нь bitdefender бол bitdefender_deflector болно.
• Analyzer: (анхдагч: standard) Index set-д зориулсан хайлтын backend-ийн analyzer.
• Index shards: (анхдагч: 1) Нэг index-д ашиглах хайлтын backend shard-ын тоо.
• Index replicas: (анхдагч: 0) Нэг index-д ашиглах хайлтын backend replica-ийн тоо.
• Max. number of segments: (анхдагч: 1) Index optimization (force merge)-ийн дараа хайлтын backend index бүрт байх segment-ийн дээд тоо. (Дэлгэрэнгүйг Segment Merging-ээс үзнэ үү.)
• Disable index optimization after rotation: Index rotation-ий дараах хайлтын backend-ийн index optimization (force merge)-ийг идэвхгүй болгоно. Optimization явагдах үед хайлтын backend кластерийн гүйцэтгэлд ноцтой асуудал гарсан тохиолдолд л үүнийг идэвхжүүлнэ.
• Field type refresh interval: Идэвхтэй write index-ийн талбарын төрлийн мэдээллийг хэр давтамжтай шинэчлэхийг секунд эсвэл минутаар тодорхойлно.

Index Rotation-ий тохиргоо

Мөн энэ index set-ийн rotation стратегийг тодорхойлно. Анхдагчаар Rotation & Retention хэсэгт Data Tiering сонгогдсон бөгөөд энэ нь зөвлөмж болгосон сонголт юм. Энэ аргын талаар болон тохиргооны төрлүүдийн дэлгэрэнгүйг Data Tiering хэсгээс үзнэ үү.

Index Retention-ий тохиргоо

Index set-ийн хадгалалтын стратегиа сонгоно:

• Archive: Index-ийг хаах эсвэл устгахын өмнө автоматаар архивлана.
• Delete: Нөөцийн хэрэглээг багасгахын тулд хайлтын backend дахь index-үүдийг устгана.

Засвар үйлчилгээ

Index Range-ийг синхрон байлгах

Шинэ index үүсмэгц Security Data Lake index range-ийг автоматаар тооцоолно.

Хэрэв index-ийн хугацааны завсрын хадгалсан metadata синхронгүй болбол Security Data Lake вэб интерфэйсээр танд мэдэгдэнэ. Index гараар устгагдсан эсвэл аль хэдийн «closed» болсон index-үүдийн мессеж хасагдсан үед ийм зүйл гарч болно.

Систем хугацааны завсрын бүх мэдээллийг дахин үүсгэхийг санал болгоно.

Index-ийг гараар устгасны дараа эсвэл синхрончлолын асуудал үүсгэж болох бусад өөрчлөлт хийсний дараа энэ мэдээллийг өөрөө хялбархан дахин үүсгэж болно:

$ curl -XPOST http://127.0.0.1:9000/api/system/indices/ranges/rebuild

Энэ нь system job эхлүүлнэ:

INFO : org.graylog2.indexer.ranges.RebuildIndexRangesJob - Recalculating index ranges.
INFO : org.graylog2.system.jobs.SystemJobManager - Submitted SystemJob <9b64a9d0-dcac-11e6-97c3-6c4008b8fc28> [org.graylog2.indexer.ranges.RebuildIndexRangesJob]
INFO : org.graylog2.indexer.ranges.RebuildIndexRangesJob - Recalculating index ranges for index set Default index set (graylog2_*): 5 indices affected.
INFO : org.graylog2.indexer.ranges.MongoIndexRangeService - Calculated range of [graylog_96] in [7ms].
INFO : org.graylog2.indexer.ranges.RebuildIndexRangesJob - Created ranges for index graylog_96: MongoIndexRange{id=null, indexName=graylog_96, begin=2017-01-17T11:49:02.529Z, end=2017-01-17T12:00:01.492Z, calculatedAt=2017-01-17T12:00:58.097Z, calculationDuration=7, streamIds=[000000000000000000000001]}[...]
INFO : org.graylog2.indexer.ranges.RebuildIndexRangesJob - Done calculating index ranges for 5 indices. Took 44ms.
INFO : org.graylog2.system.jobs.SystemJobManager - SystemJob <9b64a9d0-dcac-11e6-97c3-6c4008b8fc28> [org.graylog2.indexer.ranges.RebuildIndexRangesJob] finished in 46ms.

Идэвхтэй write index-ийг гараар rotation хийх

Заримдаа сүүлийн index-ийн тохируулсан rotation шалгуур хангагдахыг хүлээлгүй идэвхтэй write index-ийг гараар rotation хийх хэрэг гардаг, жишээ нь index mapping эсвэл index бүрийн shard-ын тоог өөрчилсөн үед.

Үүнийг Security Data Lake leader node-ын REST API руу HTTP хүсэлт илгээх эсвэл вэб интерфэйсээр хийж болно:

$ curl -XPOST https://***.gravityzone.bitdefender.com/api/system/deflector/cycle

Гараар rotation хийхэд дараахтай төстэй лог үүснэ:

INFO : org.graylog2.rest.resources.system.DeflectorResource - Cycling deflector for index set <58501f0b4a133077ecd134d9>. Reason: REST request.
INFO : org.graylog2.indexer.MongoIndexSet - Cycling from <graylog_97> to <graylog_98>.
INFO : org.graylog2.indexer.MongoIndexSet - Creating target index <graylog_98>.
INFO : org.graylog2.indexer.indices.Indices - Created Graylog index template "graylog-internal" in Elasticsearch.
INFO : org.graylog2.indexer.MongoIndexSet - Waiting for allocation of index <graylog_98>.
INFO : org.graylog2.indexer.MongoIndexSet - Index <graylog_98> has been successfully allocated.
INFO : org.graylog2.indexer.MongoIndexSet - Pointing index alias <graylog_deflector> to new index <graylog_98>.
INFO : org.graylog2.system.jobs.SystemJobManager - Submitted SystemJob <024aac80-dcad-11e6-97c3-6c4008b8fc28> [org.graylog2.indexer.indices.jobs.SetIndexReadOnlyAndCalculateRangeJob]
INFO : org.graylog2.indexer.MongoIndexSet - Successfully pointed index alias <graylog_deflector> to index <graylog_98>.
INFO : org.graylog2.indexer.retention.strategies.AbstractIndexCountBasedRetentionStrategy - Number of indices (5) higher than limit (4). Running retention for 1 index.
INFO : org.graylog2.indexer.retention.strategies.AbstractIndexCountBasedRetentionStrategy - Running retention strategy [org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy] for index <graylog_94>
INFO : org.graylog2.indexer.retention.strategies.DeletionRetentionStrategy - Finished index retention strategy [delete] for index <graylog_94> in 23ms.

Data Tiering

Security Data Lake нь index set-ийн өгөгдлийг түвшин (tier) болгон хадгалах, удирдах боломж олгодог. Index set тохируулахдаа өгөгдөл хадгалах шаардлагадаа тулгуурлан tier-ийн шинж чанарыг тогтооно. Ингэснээр хадгалах сангаа гүйцэтгэл болон зардлын хувьд үр дүнтэй ашиглана.

Энэ хэсэгт Security Data Lake Data Tiering-ийг хэрхэн хэрэгжүүлдэг, index set-дээ үр дүнтэй бодлого тогтооход юу мэдэх ёстойг тайлбарлана.

Data Tiering-ийг яагаад ашиглах вэ?

Security Data Lake Data Tiering-д tier бүр ижил аргаар боловсруулах шаардлагатай өгөгдлийн хадгалалтын сан болдог. Өгөгдлийн tier гэдгийг хадгалалт, удирдлагын ижил шаардлагатай өгөгдлийн түвшин гэж ойлгож болно. Өгөгдлийг ашиглах давтамж, шаардагдах хайлтын гүйцэтгэлээр нь бүлэглэнэ. Tier бүр хадгалалт, хандалтын өөрийн шалгууртай тул өгөгдлөө хамгийн тохиромжтой tier рүү шилжүүлж болно.

Data Tiering нь хадгалалтын зардлыг бууруулахад тусална, учир нь ховор ашиглагдах өгөгдлийг хямд tier-д хадгалж болно. Жишээ нь зөвхөн дагаж мөрдөх (compliance) шалгалтад хадгалах өгөгдлийг өндөр гүйцэтгэлгүй, тиймээс хямд tier-д хадгалж болно. Илүү үнэтэй, өндөр гүйцэтгэлтэй tier-ийг сүүлийн үеийн, байнга хайгддаг өгөгдөлд нөөцөлнө.

Өгөгдлийг tier-үүдэд дараах үндэслэлээр ангилж болно:

• гүйцэтгэлийн шаардлага
• ашиглалтын давтамж
• зардлын үр ашиг

Өөрөө удирддаг (self-managed) суулгацад Data Tiering-ийг зардал багатай хадгалалтын арга болгон зөвлөж байна. Data Tiering нь өгөгдөл хадгалах гурван түвшинтэй: hot tier, warm tier болон архив. Эдгээрийг доор тус тусад нь тайлбарлав.

Hot Tier

Data stream-ийн нэг хэсэг болох шинэ index автоматаар hot tier-д оногдоно. Tiering-ийн хувьд hot tier нь хадгалалтад ашигладаг хайлтын backend кластерийг хэлэх бөгөөд бүх ирж буй өгөгдлийн анхдагч байршил юм. Hot tier-ийн өгөгдөлд хандах, хайх нь хялбар боловч түүнийг ажиллуулахад нөөц хуваарилах шаардлагатай тул үйл ажиллагааны зардал ерөнхийдөө өндөр байдаг.

Warm Tier

Warm tier-ийн өгөгдөл хайх боломжтой боловч хайлтын гүйцэтгэл hot tier-ээс доогуур байна. Warm tier-ийн өгөгдөл index set-д шууд биш, searchable snapshot-д хадгалагдана. Warm tier-д хайлт хийхэд систем энэ сэргээгдсэн давхаргаас өгөгдлийг хайлтын backend кластерт ачаална. Warm tier нь сүүлийн долоо хоногуудын лог зэрэг байнга хандах шаардлагагүй өгөгдөлд тохиромжтой.

Searchable snapshot index нь repository-оос уншдаг бөгөөд сэргээх үед бүх өгөгдлийг кластерт татаж авдаггүй. Энэ нь warm tier-ийг зардал багатай хадгалалтын шийдэл болгодог. Snapshot-ууд warm storage repository-д хадгалагдах бөгөөд энэ нь Amazon S3 bucket байж болно. Searchable snapshot-ууд repository-д snapshot хэлбэрээрээ үлдэх ба зөвхөн унших боломжтой (read-only).

Архивлах

Security Data Lake нь чухал биш өгөгдөлд зориулсан архивлах боломж санал болгодог бөгөөд энэ нь дагаж мөрдөх болон түүхэн өгөгдлийг хямд хадгалах сонголт юм.

Архив нь Security Data Lake-д дахин боловсруулж шинжлэх хүртэл мессежийг хадгалдаг. Мессеж retention цэвэрлэгээ эхлэхээс өмнө хадгалагдах бөгөөд хайлтын backend-ээс устгагддаггүй.

Data Tiering-ийг тохируулах

Data Tiering-ийг index set үүсгэх эсвэл шинэчлэх үед тогтоож болно. Index set бүрийн агуулах өгөгдлийн шаардлагад нийцүүлэн тус бүрт өөр tier бодлого тогтоох боломжтой.

Warm tier-ийг анх тохируулсны дараа файлын cache-д ашиглах дискний зайг оновчтой тогтоохын тулд Security Data Lake-ийн warm tier node-уудын системийн нөөцийн ашиглалтыг хянахыг зөвлөж байна. Ялангуяа active ба used хувийн хэмжигдэхүүнүүд (мөн file cache-ийн total, active, used, evicted bytes)-ийг анхааралтай ажиглана.

Ашиглагдсан file cache-ийн хувь нь active file cache-ийн хувиас бага байх ёстой бөгөөд идеал тохиолдолд эдгээр утга 70% ба түүнээс бага байна. Мөн file cache дахь active bytes нь used bytes-аас бага, used bytes нь file cache-ийн total bytes-аас бага байх нь чухал, өөрөөр хэлбэл:

Active bytes < used bytes < total bytes

Хэрэв та Data Tiering-ийг Security Data Lake Data Node-той хамт идэвхжүүлж байгаа бол OpenSearch Node-ын API-аас query хийхэд ашигладаг гуравдагч талын хэрэгслийн хувьд эхлээд certificate authority олгох ёстой. Certificate authority олгох талаарх дэлгэрэнгүйг Data Node-ийн баримтаас үзнэ үү.

Хэрэв та өөрөө удирддаг OpenSearch ашиглаж байгаа бол дараагийн хэсэг рүү шилжинэ үү.

File Cache-ийн хэмжүүрүүдийг авах

OpenSearch node stats API нь кластерийн статистикийг авах боломж олгоно. Дээр дурдсан file cache-ийн хэмжүүрүүдийг авахад ашиглаж болох cURL командын жишээ энд байна. (OpenSearch хэмжүүрүүдийг InfluxDB, Prometheus зэрэг time-series өгөгдлийн санд цуглуулж хадгалдаггүй тохиолдолд хэрэг болно.)

$ curl -s -XGET "http://admin:password@10.0.1.229:9200/_nodes/stats/file_cache?pretty"

Дээрх командын хариултаас авсан жишээ хэсэг:

"jW4Q6SuXQASt8lM796CBHg" : {
      "timestamp" : 1712857680055,
      "name" : "10.0.1.229",
      "transport_address" : "10.0.1.229:9300",
      "host" : "10.0.1.229",
      "ip" : "10.0.1.229:9300",
      "roles" : [
        "search"
      ],
      "attributes" : {
        "shard_indexing_pressure_enabled" : "true"
      },
      "file_cache" : {
        "timestamp" : 1712857680055,
        "active_in_bytes" : 50066073022,
        "total_in_bytes" : 128849018880,
        "used_in_bytes" : 71497646618,
        "evictions_in_bytes" : 0,
        "active_percent" : 70,
        "used_percent" : 55,
        "hit_count" : 83077,
        "miss_count" : 877
      }
    }

Node stats API-аар авах боломжтой OpenSearch хэмжүүрүүд:

• nodes.stats.file_cache.active_in_bytes
• nodes.stats.file_cache.total_in_bytes
• nodes.stats.file_cache.used_in_bytes
• nodes.stats.file_cache.evictions_in_bytes
• nodes.stats.file_cache.active_percent
• nodes.stats.file_cache.used_percent
• nodes.stats.file_cache.hit_count
• nodes.stats.file_cache.miss_count

Архивлах

Хайлтын backend-д их хэмжээний өгөгдөл хадгалах нь үнэтэй байж болно. Security Data Lake нь идэвхгүй өгөгдлийг Security Data Lake архивт хадгалж, хадгалалтын зардлыг бууруулах, хадгалах хугацааг шаардлагынхаа дагуу дээд зэргээр уртасгах боломж олгоно. Index set-ийг архивлахдаа олон хүчин зүйлд тулгуурлан хадгалах хугацаа-г тогтоож болно. Хадгалах хугацаа дууссаны дараа архивлагдсан index-үүд устгагдана.

Max Segment Size-г сонгох

Index-ийг архивлахад архивын job өгөгдлийг segment-үүд рүү бичнэ. Max Segment Size тохиргоо нь эдгээр өгөгдлийн segment бүрийн хэмжээний хязгаарыг тогтоож, segment файлын хэмжээг хянаж, файлын хэмжээний хязгаартай хэрэгслээр боловсруулах боломжийг олгоно.

Хэмжээний хязгаарт хүрмэгц шинэ segment файл эхэлнэ. Жишээ нь:

/path/to/archive/
  graylog_201/
    archive-metadata.json
    archive-segment-0.gz
    archive-segment-1.gz
    archive-segment-2.gz

Data Tiering-ээр Index Retention-ийг тохируулах

Шинэ эсвэл байгаа index set-д өгөгдлийг хэр удаан хадгалахаа тодорхойлж болно. Үүний тулд:

1. 1Index set-ийн тохиргооны хуудсанд Rotation and Retention хэсэг рүү очно.
2. 2Data Tiering сонголт руу шилжүүлнэ.
3. 3Өгөгдлөө хадгалах хамгийн бага ба хамгийн их хоногийг сонгоно.

Хамгийн их хоногт хүрмэгц өгөгдөл устгагдана. Хэрэв энэ өгөгдлийг хадгалахыг хүсвэл Archive before deletion-ийг сонгож болно.

Мөн Enable Warm Tier-ийг сонгож болно. Дараа нь өгөгдөл warm tier рүү шилжихээс өмнө hot tier-д хамгийн багадаа хэдэн хоног байхыг оруулна. Мөн index set-ийг хадгалах warm storage repository-г тодорхойлж болно. Хэрэв байхгүй бол энэ цэснээс шинэ warm storage repository үүсгэж болно.

Архивлах Stream-үүдийг сонгох

Streams to Archive тохиргоо архивт хамаарах бөгөөд Security Data Lake-д орж ирж буй бүх зүйлийг биш, таны stream-үүдээр тодорхойлсон чухал өгөгдлийг л архивлах боломж олгоно.

Index Set-ийн өгөгдлийг архивлах

Security Data Lake архивын тохиргоогоо хийж дууссан тул өгөгдлөө хүссэнээрээ архивлаж эхэлж болно. Та index set-ийг шууд архивлах эсвэл тодорхой хугацааны завсар тогтоож автомат архивлалт тохируулах боломжтой.

Index Set-д шинэ архив үүсгэх

Тодорхой index set-ийг гараар архивлахын тулд:

1. 1Enterprise > Archives руу очно.
2. 2Унждаг цэснээс хүссэн index-ээ сонгоно.
3. 3Archive Index дарна.

Архивлагдсан index set-ийг интерфэйсийн ижил хуудасны Archive Catalog-оос харж болно.

Index Set-д автомат архивлалт тохируулах

Эсвэл index-үүдийг тодорхой цагт архивлахаар тодорхойлж болно. Үүнийг Security Data Lake интерфэйсээр эсвэл REST API-аар хийнэ.

Security Data Lake интерфэйсээр архивлалтыг автоматжуулах

1. 1System > Indices руу очно.

2. 2Архивлахыг хүссэн index set-ээ олно.

3. 3Edit товчийг дарна.

4. 4Rotation and Retention хэсэг хүртэл доош гүйлгэнэ.

5. 5Одоо rotation болон retention стратегиа сонгоно. Data Tiering эсвэл Legacy-г сонгоно. Index-ийн rotation, retention-ий манай зөвлөмж болгосон загвар нь data tiering гэдгийг анхаарна уу (дэлгэрэнгүйг Data Tiering хэсгээс үзнэ үү). Legacy rotation болон retention стратегиуд одоогоор дэмжигдэж байгаа боловч ирээдүйд хүчингүй болно.

- Хэрэв Data Tiering-ийг сонговол Archive before deletion нүдийг тэмдэглэнэ.

Мөн устгал эхлэхээс өмнө зөвшөөрөгдөх index-ийн дээд тоог тогтоож болно. Хамгийн хуучин index-үүд эхлээд устгагдана.

6. 6Update index set дарна.

REST API-аар архивлалтыг автоматжуулах

Илүү уян хатан арга хэрэгтэй бол Security Data Lake REST API-г архив үүсгэхийг автоматжуулахад ашиглаж болно.

Доорх жишээнд index-ийг архивлахад curl команд ашигласан. Энэ команд Security Data Lake сервер дээр graylog_386 index-ийн архив үүсгэх system job эхлүүлнэ.

system_job.id-г job-ийн явцыг шалгахад ашиглана.

$ curl -s -u admin -H 'X-Requested-By: cli' -X POST http://127.0.0.1:9000/api/plugins/org.graylog.plugins.archive/archives/graylog_386
Enter host password for user 'admin': ***************
{
   "archive_job_config" : {
     "archive_path" : "/tmp/graylog-archive",
     "max_segment_size" : 524288000,
     "segment_filename_prefix" : "archive-segment",
     "metadata_filename" : "archive-metadata.json",
     "source_histogram_bucket_size" : 86400000,
     "restore_index_batch_size" : 1001,
     "segment_compression_type": "SNAPPY"
   },
   "system_job" : {
     "id" : "cd7ebfa0-079b-11e6-9e1b-fa163e6e9b8a",
     "description" : "Archives indices and deletes them",
     "name" : "org.graylog.plugins.archive.job.ArchiveCreateSystemJob",
     "info" : "Archiving documents in index: graylog_386",
     "node_id" : "c5df7bff-cafd-4546-ac0a-5ccd2ba4c847",
     "started_at" : "2016-04-21T08:34:03.034Z",
     "percent_complete" : 0,
     "provides_progress" : true,
     "is_cancelable" : true
   }
 }

REST API нь архивтай холбоотой бусад үйлдлийг ч автоматжуулж чадна, тухайлбал:

• Архивыг сэргээх, устгах
• Архивын тохиргоог шинэчлэх

System > Nodes дор байрлах REST API browser-ийг судалж үзэхийг зөвлөж байна.

Өөр өөр index-д өөр өөр хадгалах хугацаа тогтоох шаардлага гарч болно. Зарим index-д хоёр сарын хадгалалт хангалттай бол зарим нь урт хугацаа шаардана. Жишээ нь firewall логийг ихэвчлэн хоёр сар хадгалдаг боловч бусад лог мессежийг дагаж мөрдөх журмын дагуу удаан хадгалах шаардлагатай байж болно.

Хадгалах хугацаа дууссаны дараа Security Data Lake хуучин мессежүүдийг автоматаар устгана.

Дараагийн алхмууд

Анхны архивоо үүсгэсэн тул одоо архивлагдсан өгөгдлийг сэргээх процессыг эхлүүлнэ үү.

Архивыг сэргээх

Security Data Lake архивлалтаа тохируулж, анхны өгөгдлийн багцаа архивласны дараа шаардлагатай үедээ, тухайлбал өгөгдлөө хайж шинжлэх хэрэг гарвал архивуудаа сэргээж болно.

Архивлагдсан өгөгдлийг сэргээх

Архивлагдсан index-үүдийг дараах аргаар сэргээж болно:

• Security Data Lake интерфэйс
• REST API

Анхны index-үүд (хэрэв байгаа бол) тэдэнтэй зөрчилдөхгүйн тулд Security Data Lake бүх index-ийг Restored Archives index set-д сэргээнэ гэдгийг анхаарна уу.

Сэргээгдсэн index-үүд reopened гэж тэмдэглэгдэх тул index-retention job-ууд тэдгээрийг үл тоох бөгөөд хаах, устгахгүй. Иймээс сэргээгдсэн index-үүд шаардлагагүй болмогц гараар устгах ёстой.

Security Data Lake интерфэйсээр index-үүдийг сэргээх

Интерфэйсээр архивыг сэргээхийн тулд:

1. 1Enterprise > Archives руу очно.
2. 2Archive Catalog хэсгээс index set-ийг сонгоно.
3. 3Restore Index товчийг дарна.

Мөн хайлтын талбарын хажууд байрлах Bulk Actions унждаг цэсээр олон index set-ийг нэг дор сэргээх эсвэл устгаж болно.

REST API-аар index-үүдийг сэргээх

Архив үүсгэхтэй адил REST API ашиглан архивлагдсан index-ийг OpenSearch кластерт сэргээж болно:

$ curl -s -u admin -H 'X-Requested-By: cli' -X POST http://127.0.0.1:9000/api/plugins/org.graylog.plugins.archive/archives/graylog_386/restore
Enter host password for user 'admin': ***************
{
   "archive_metadata": {
     "archive_id": "graylog_307",
     "index_name": "graylog_307",
     "document_count": 491906,
     "created_at": "2016-04-14T14:31:50.787Z",
     "creation_duration": 142663,
     "timestamp_min": "2016-04-14T14:00:01.008Z",
     "timestamp_max": "2016-04-14T14:29:27.639Z",
     "id_mappings": {
       "streams": {
         "56fbafe0fb121a5309cef297": "nginx requests"
       },
       "inputs": {
         "56fbafe0fb121a5309cef290": "nginx error_log",
         "56fbafe0fb121a5309cef28d": "nginx access_log"
       },
       "nodes": {
         "c5df7bff-cafd-4546-ac0a-5ccd2ba4c847": "graylog.example.org"
       }
     },
     "histogram_bucket_size": 86400000,
     "source_histogram": {
       "2016-04-14T00:00:00.000Z": {
         "example.org": 227567
       }
     },
     "segments": [
       {
         "path": "archive-segment-0.gz",
         "size": 21653755,
         "raw_size": 2359745839,
         "compression_type": "SNAPPY"
         "checksum": "751e6e76",
         "checksum_type": "CRC32"
       }
     ],
     "index_size": 12509063,
     "index_shard_count": 4
   },
   "system_job": {
     "id": "e680dcc0-07a2-11e6-9e1b-fa163e6e9b8a",
     "description": "Restores an index from the archive",
     "name": "org.graylog.plugins.archive.job.ArchiveRestoreSystemJob",
     "info": "Restoring documents from archived index: graylog_307",
     "node_id": "c5df7bff-cafd-4546-ac0a-5ccd2ba4c847",
     "started_at": "2016-04-21T09:24:51.468Z",
     "percent_complete": 0,
     "provides_progress": true,
     "is_cancelable": true
   }
 }

Буцаагдсан JSON payload нь архивын metadata болон index сэргээх процессыг ажиллуулж буй system job-ийн тайлбарыг агуулна.

Тусдаа кластерт сэргээх

Сэргээгдсэн index-үүдийн нэмэлт ачаалал таны index-лэх хурдыг удаашруулдаг. Үндсэн OpenSearch кластерт нэмэлт ачаалал өгөхгүйн тулд архивлагдсан index-үүдийг өөр кластерт сэргээж болно:

1. 1Архивлагдсан index-үүдийг өөр машин руу шилжүүлнэ.
2. 2Тэдгээрийг тохируулсан backend-д байрлуулна.

Index архив бүр тусдаа хавтсанд байдаг тул зөвхөн нэг index-ийг өөр машин руу шилжүүлэх бол харгалзах хавтсыг backend руу хуулна. Жишээ нь:

$ tree /tmp/graylog-archive
  /tmp/graylog-archive
  ├── graylog_171
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  ├── graylog_201
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  ├── graylog_268
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  ├── graylog_293
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  ├── graylog_307
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  ├── graylog_386
  │   ├── archive-metadata.json
  │   └── archive-segment-0.gz
  └── graylog_81
      ├── archive-metadata.json
      └── archive-segment-0.gz
  7 directories, 14 files

Сэргээгдсэн index-үүдээс хайх

Хайлтын query-ууд сэргээгдсэн index-үүдийг автоматаар ашиглана. Сэргээгдсэн index дэх мессеж бүр true утгатай тусгай gl2_archive_restored талбартай тул сэргээгдсэн мессежээс дараах query-гаар хайж болно:

_exists_:gl2_archive_restored AND <your search query>

Хэрэв сэргээгдсэн бүх мессежийг query-ээсээ хасахыг хүсвэл:

_missing_:gl2_archive_restored AND <your search query>

Indexer-ийн алдаа

Security Data Lake node-ууд гүйцэтгэсэн index-лэх үйлдэл бүрийг тасралтгүй бүртгэдэг. Энэ нь мессеж санамсаргүй алдагдахгүй байхад тусална. Вэб интерфэйс нь бүтэлгүйтсэн бичих үйлдлийн тоо болон бүтэлгүйтсэн үйлдлийн жагсаалтыг харуулж чадна. Вэб интерфэйсийн бусад мэдээллийн адил үүнийг REST API-аар ч авч, өөрийн хяналтын системд холбож болно.

Index-лэх алдааны мэдээлэл хэмжээ нь хязгаарлагдсан (capped) MongoDB collection-д хадгалагдана. Энд олон (хэдэн арван мянган) алдааны мессеж багтах боловч бүх алдааны бүрэн цуглуулга гэж үзэж болохгүй.

Indexer-ийн алдааны түгээмэл шалтгаанууд

Тодорхой нөхцөлд гардаг түгээмэл алдаанууд байдаг. Тэдгээрийг энд тайлбарлав:

MapperParsingException

Алдааны мессеж иймэрхүү харагдана:

MapperParsingException[failed to parse [failure]]; nested: NumberFormatException[For input string: "some string value"];

Та тоон талбарт string бичихийг оролдож байна. Indexer үүнийг тоо руу хөрвүүлэхийг оролдох боловч string нь хөрвүүлэх боломжгүй тэмдэгт агуулсан тул бүтэлгүйтнэ.

Үүнийг өөр өөр талбарын төрөлтэй GELF мессеж илгээх, эсвэл тоон утга руу хөрвүүлэлгүйгээр string бичихийг оролдох extractor-ууд үүсгэж болно. Талбарын төрлийг идэвхтэй шийдэж тогтоохыг зөвлөж байна. Хэрэв та https_response_code талбарыг тоон утгатайгаар илгээсэн бол цаашид тэр төрлийг хэзээ ч бүү өөрчил.

Boolean зэрэг бусад талбарын төрлийн хувьд ч мөн адил зүйл гарч болно.

Энд index cycling-ийг санах хэрэгтэй. Index бүрт талбарт анх бичигдсэн төрөл ялна. Хэрэв Security Data Lake index cycle хийвэл тухайн index-д талбарын төрлүүд шинээр эхэлнэ гэсэн үг. Хэрэв тэр index-д бичигдсэн анхны мессежийн https_response_code нь string байвал index дараагийн удаа cycle хийх хүртэл string хэвээр байна. Дэлгэрэнгүйг Index model хэсгээс үзнэ үү.

Indexer болон боловсруулалтын алдааны Index

Security Data Lake нь index-лэх болон боловсруулах алдааны мэдэгдлийг тусгай failure index-д хадгалах боломж олгоно.

Алдааны мессежүүд бүртгэгдэж, dashboard дээр нэгтгэгдэх ба alert мэдэгдэл тохируулахад ашиглагдана. Ингэснээр мессежүүдийг шинжилж, алдаа яагаад гарсныг ойлгох боломжтой.

Алдаа боловсруулалтыг тохируулах

Security Data Lake-ийн шинэ суулгацад алдааны төрөл тус бүр анхдагчаар идэвхтэй байна. Тохиргоогоо өөрчлөхийн тулд:

1. 1System > Configurations руу очно.

2. 2Plugins-г сонгоод, дараа нь Failure Processing-ийг сонгоно.

3. 3Edit configuration дарна.

4. 4Алдаа боловсруулах боломж тус бүрийн нүдийг тэмдэглэх эсвэл тэмдэглэгээг арилгана.

- Log Indexing Failures: Indexer-ийн алдааны мэдэгдлийг хадгалж, Security Data Lake-ийн тусгай stream-д бүртгэнэ.
- Log Processing Failures: Алдааны мэдэгдлийг боловсруулж хайлтын backend-д хадгалуулан, Security Data Lake-ийн тусгай stream-д бүртгэнэ.
- Include Failed Messages: Шалгахад зориулж алдааны мэдэгдэлд бүтэн лог мессежийг харуулна. Энэ сонголтыг идэвхжүүлэхийн тулд Log Indexing Failures эсвэл Log Processing Failures-ийн аль нэгийг идэвхжүүлнэ.
- Continue Processing on Error: Анхны мессежийг алдааны тодорхой мэдээлэл бүхий шинэ талбар (gl2_processing_error)-ийн хамт хадгална. Үүний зэрэгцээ алдааны мэдээлэл бүхий алдааны мессеж Security Data Lake-ийн тусгай stream-д хадгалагдана. Энэ сонголтыг идэвхжүүлэхийн тулд Log Processing Failures-ийг идэвхжүүлнэ.

5. 5Сонголтоо хадгалахын тулд Update configuration дарна.

Алдаа боловсруулалт идэвхтэй үед System Overview дахь widget бүтэлгүйтсэн мессежийн тоолуурыг харуулна.

Indexer-ийн алдааны түгээмэл шалтгаанууд

Indexer-ийн хамгийн түгээмэл алдааг “MapperParsingException” гэж ангилдаг.

Энэ төрлийн алдааны талаар нэмэлт мэдээллийг Indexer-ийн алдааны түгээмэл шалтгаанууд хэсгээс үзнэ үү.

Боловсруулалтын алдааны түгээмэл шалтгаанууд

Security Data Lake-ийн боловсруулалтын stack дотор гарч болох боловсруулалтын алдаа олон шалтгаантай байж болно. Хамгийн түгээмэл шалтгаанууд:

• RuleStatementEvaluationError

- Pipeline rule-ийн “then” ба “end” утгуудын хоорондох илэрхийлэлд алдаа гарсан үед үүснэ.

• RuleConditionEvaluationError

- Pipeline rule-ийн “when” ба “then” утгуудын хоорондох илэрхийлэлд алдаа гарсан үед үүснэ.

• ExtractorException

- Extractor эсвэл converter мессежийг буруу уншсан эсвэл буруу тооцоолсон үед үүснэ.

• MessageFilterException

- Security Data Lake аппликейшнтэй холбоотой backend системийн алдаа гарсан үед үүснэ; Security Data Lake-ийн дэмжлэгтэй хамтран нэмэлт оношилгоо хийх шаардлагатай байж болно.

• InvalidTimestampException

- Timestamp талбарт утга тохируулах эсвэл гаргаж авах оролдлого бүтэлгүйтсэн үед үүснэ. Жишээ нь pipeline rule мөрөөс timestamp гаргаж авах гэж бүтэлгүйтээд энэ null timestamp-ыг мессежид оноохыг оролдсон.

• UNKNOWN

- Энэ алдааны шалтгаан тодорхойгүй бөгөөд лог өгөгдлийг нэмэлтээр судлах шаардлагатай.