నేను స్నేహితుల మార్పిడి మరియు ELK (ప్రారంభం) ఎలా తయారు చేయాలనే దాని గురించి నా కథనాన్ని కొనసాగిస్తాను ) ఈ కలయిక సంశయం లేకుండా చాలా పెద్ద సంఖ్యలో లాగ్‌లను ప్రాసెస్ చేయగలదని నేను మీకు గుర్తు చేస్తాను. ఈసారి లాగ్‌స్టాష్ మరియు కిబానా కాంపోనెంట్‌లతో ఎక్స్ఛేంజ్ పనిని ఎలా పొందాలనే దాని గురించి మాట్లాడుతాము.
ELK స్టాక్‌లోని లాగ్‌స్టాష్ లాగ్‌లను తెలివిగా ప్రాసెస్ చేయడానికి మరియు పత్రాల రూపంలో సాగే ప్లేస్‌మెంట్ కోసం వాటిని సిద్ధం చేయడానికి ఉపయోగించబడుతుంది, దీని ఆధారంగా కిబానాలో వివిధ విజువలైజేషన్‌లను రూపొందించడం సౌకర్యంగా ఉంటుంది.
సెట్టింగ్
రెండు దశలను కలిగి ఉంటుంది:
- OpenJDK ప్యాకేజీని ఇన్‌స్టాల్ చేయడం మరియు కాన్ఫిగర్ చేయడం.
- లాగ్‌స్టాష్ ప్యాకేజీని ఇన్‌స్టాల్ చేయడం మరియు కాన్ఫిగర్ చేయడం.
OpenJDK ప్యాకేజీని ఇన్‌స్టాల్ చేయడం మరియు కాన్ఫిగర్ చేయడం
OpenJDK ప్యాకేజీ తప్పనిసరిగా డౌన్‌లోడ్ చేయబడాలి మరియు నిర్దిష్ట డైరెక్టరీలోకి అన్‌ప్యాక్ చేయబడాలి. అప్పుడు ఈ డైరెక్టరీకి పాత్ తప్పనిసరిగా Windows ఆపరేటింగ్ సిస్టమ్ యొక్క $env:Path మరియు $env:JAVA_HOME వేరియబుల్స్‌లో నమోదు చేయాలి:
జావా సంస్కరణను తనిఖీ చేద్దాం:
PS C:> java -version
openjdk version "13.0.1" 2019-10-15
OpenJDK Runtime Environment (build 13.0.1+9)
OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)
లాగ్‌స్టాష్ ప్యాకేజీని ఇన్‌స్టాల్ చేయడం మరియు కాన్ఫిగర్ చేయడం
లాగ్‌స్టాష్ పంపిణీతో ఆర్కైవ్ ఫైల్‌ను డౌన్‌లోడ్ చేయండి . ఆర్కైవ్ తప్పనిసరిగా డిస్క్ యొక్క మూలానికి అన్‌ప్యాక్ చేయబడాలి. ఫోల్డర్‌కి అన్‌ప్యాక్ చేయండి C:Program Files ఇది విలువైనది కాదు, లాగ్‌స్టాష్ సాధారణంగా ప్రారంభించడానికి నిరాకరిస్తుంది. అప్పుడు మీరు ఫైల్‌లోకి ప్రవేశించాలి jvm.options జావా ప్రాసెస్ కోసం RAMని కేటాయించే బాధ్యతను పరిష్కరిస్తుంది. సర్వర్ యొక్క RAMలో సగభాగాన్ని పేర్కొనమని నేను సిఫార్సు చేస్తున్నాను. బోర్డ్‌లో 16 GB RAM ఉంటే, డిఫాల్ట్ కీలు:
-Xms1g
-Xmx1g
దీనితో భర్తీ చేయాలి:
-Xms8g
-Xmx8g
అదనంగా, లైన్‌ను వ్యాఖ్యానించడం మంచిది -XX:+UseConcMarkSweepGC. దీని గురించి మరింత . తదుపరి దశ logstash.conf ఫైల్‌లో డిఫాల్ట్ కాన్ఫిగరేషన్‌ను సృష్టించడం:
input {
stdin{}
}
filter {
}
output {
stdout {
codec => "rubydebug"
}
}
ఈ కాన్ఫిగరేషన్‌తో, లాగ్‌స్టాష్ కన్సోల్ నుండి డేటాను చదువుతుంది, దానిని ఖాళీ ఫిల్టర్ ద్వారా పంపుతుంది మరియు దానిని తిరిగి కన్సోల్‌కు అవుట్పుట్ చేస్తుంది. ఈ కాన్ఫిగరేషన్‌ని ఉపయోగించడం లాగ్‌స్టాష్ యొక్క కార్యాచరణను పరీక్షిస్తుంది. దీన్ని చేయడానికి, ఇంటరాక్టివ్ మోడ్‌లో దీన్ని అమలు చేద్దాం:
PS C:...bin> .logstash.bat -f .logstash.conf
...
[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline ][main] Pipeline started {"pipeline.id"=>"main"}
The stdin plugin is now waiting for input:
[2019-12-19T11:15:27,847][INFO ][logstash.agent ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}
[2019-12-19T11:15:28,113][INFO ][logstash.agent ] Successfully started Logstash API endpoint {:port=>9600}
పోర్ట్ 9600లో లాగ్‌స్టాష్ విజయవంతంగా ప్రారంభించబడింది.
చివరి ఇన్‌స్టాలేషన్ దశ: లాగ్‌స్టాష్‌ను విండోస్ సేవగా ప్రారంభించండి. ఉదాహరణకు, ప్యాకేజీని ఉపయోగించి ఇది చేయవచ్చు :
PS C:...bin> .nssm.exe install logstash
Service "logstash" installed successfully!
తప్పు సహనం
సోర్స్ సర్వర్ నుండి బదిలీ చేయబడినప్పుడు లాగ్‌ల భద్రత పెర్సిస్టెంట్ క్యూల మెకానిజం ద్వారా నిర్ధారిస్తుంది.
ఎలా పని చేస్తుంది
లాగ్ ప్రాసెసింగ్ సమయంలో క్యూల లేఅవుట్: ఇన్పుట్ → క్యూ → ఫిల్టర్ + అవుట్పుట్.
ఇన్పుట్ ప్లగ్ఇన్ లాగ్ సోర్స్ నుండి డేటాను స్వీకరిస్తుంది, దానిని క్యూలో వ్రాస్తుంది మరియు డేటా సోర్స్‌కి అందిందని నిర్ధారణను పంపుతుంది.
క్యూ నుండి సందేశాలు లాగ్‌స్టాష్ ద్వారా ప్రాసెస్ చేయబడతాయి, ఫిల్టర్ మరియు అవుట్పుట్ ప్లగ్ఇన్ ద్వారా పంపబడతాయి. లాగ్ పంపబడిందని అవుట్పుట్ నుండి నిర్ధారణను స్వీకరించినప్పుడు, లాగ్‌స్టాష్ ప్రాసెస్ చేయబడిన లాగ్‌ను క్యూ నుండి తొలగిస్తుంది. లాగ్‌స్టాష్ ఆపివేసినట్లయితే, నిర్ధారణ అందుకోని అన్ని ప్రాసెస్ చేయని సందేశాలు మరియు సందేశాలు క్యూలో ఉంటాయి మరియు లాగ్‌స్టాష్ తదుపరిసారి ప్రారంభమైనప్పుడు వాటిని ప్రాసెస్ చేయడం కొనసాగిస్తుంది.
సర్దుబాటు
ఫైల్‌లోని కీల ద్వారా సర్దుబాటు చేయవచ్చు C:Logstashconfiglogstash.yml:
queue.type: (సాధ్యమైన విలువలు -persistedиmemory (default)).path.queue: (డిఫాల్ట్‌గా C:Logstashqueueలో నిల్వ చేయబడిన క్యూ ఫైల్‌లతో ఫోల్డర్‌కి మార్గం).queue.page_capacity: (గరిష్ట క్యూ పేజీ పరిమాణం, డిఫాల్ట్ విలువ 64mb).queue.drain: (నిజం/తప్పు - లాగ్‌స్టాష్‌ను షట్ డౌన్ చేసే ముందు క్యూ ప్రాసెసింగ్‌ను ఆపడాన్ని ఎనేబుల్ చేస్తుంది/డిజేబుల్ చేస్తుంది. దీన్ని ఎనేబుల్ చేయమని నేను సిఫార్సు చేయను, ఎందుకంటే ఇది సర్వర్ షట్‌డౌన్ వేగాన్ని నేరుగా ప్రభావితం చేస్తుంది).queue.max_events: (క్యూలో ఈవెంట్‌ల గరిష్ట సంఖ్య, డిఫాల్ట్ 0 (అపరిమిత)).queue.max_bytes: (బైట్‌లలో గరిష్ట క్యూ పరిమాణం, డిఫాల్ట్ - 1024mb (1gb)).
కాన్ఫిగర్ చేయబడితే queue.max_events и queue.max_bytes, ఈ సెట్టింగ్‌లలో దేనికైనా విలువ చేరినప్పుడు సందేశాలు క్యూలో ఆమోదించబడటం ఆగిపోతుంది. నిరంతర క్యూల గురించి మరింత తెలుసుకోండి .
క్యూను సెటప్ చేయడానికి బాధ్యత వహించే logstash.yml భాగానికి ఉదాహరణ:
queue.type: persisted
queue.max_bytes: 10gb
సర్దుబాటు
లాగ్‌స్టాష్ కాన్ఫిగరేషన్ సాధారణంగా మూడు భాగాలను కలిగి ఉంటుంది, ఇన్‌కమింగ్ లాగ్‌లను ప్రాసెస్ చేసే వివిధ దశలకు బాధ్యత వహిస్తుంది: స్వీకరించడం (ఇన్పుట్ విభాగం), పార్సింగ్ (ఫిల్టర్ విభాగం) మరియు సాగే (అవుట్పుట్ విభాగం)కి పంపడం. క్రింద మేము వాటిలో ప్రతి ఒక్కటి నిశితంగా పరిశీలిస్తాము.
ఇన్పుట్
మేము ఫైల్‌బీట్ ఏజెంట్‌ల నుండి రా లాగ్‌లతో ఇన్‌కమింగ్ స్ట్రీమ్‌ను స్వీకరిస్తాము. మేము ఇన్పుట్ విభాగంలో సూచించే ఈ ప్లగ్ఇన్:
input {
beats {
port => 5044
}
}
ఈ కాన్ఫిగరేషన్ తర్వాత, లాగ్‌స్టాష్ పోర్ట్ 5044ని వినడం ప్రారంభిస్తుంది మరియు లాగ్‌లను స్వీకరించినప్పుడు, ఫిల్టర్ విభాగం యొక్క సెట్టింగ్‌ల ప్రకారం వాటిని ప్రాసెస్ చేస్తుంది. అవసరమైతే, మీరు SSLలో ఫైల్‌బిట్ నుండి లాగ్‌లను స్వీకరించడానికి ఛానెల్‌ని చుట్టవచ్చు. బీట్స్ ప్లగ్ఇన్ సెట్టింగ్‌ల గురించి మరింత చదవండి .
వడపోత
Exchange ఉత్పత్తి చేసే ప్రాసెసింగ్ కోసం ఆసక్తికరమైన అన్ని టెక్స్ట్ లాగ్‌లు లాగ్ ఫైల్‌లోనే వివరించిన ఫీల్డ్‌లతో csv ఆకృతిలో ఉంటాయి. csv రికార్డ్‌లను అన్వయించడం కోసం, Logstash మాకు మూడు ప్లగిన్‌లను అందిస్తుంది: , csv మరియు grok. మొదటిది చాలా ఎక్కువ , కానీ సరళమైన లాగ్‌లను మాత్రమే అన్వయించడంతో copes.
ఉదాహరణకు, ఇది క్రింది రికార్డ్‌ను రెండుగా విభజిస్తుంది (ఫీల్డ్ లోపల కామా ఉండటం వల్ల), అందుకే లాగ్ తప్పుగా అన్వయించబడుతుంది:
…,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",…
లాగ్‌లను అన్వయించేటప్పుడు దీనిని ఉపయోగించవచ్చు, ఉదాహరణకు, IIS. ఈ సందర్భంలో, ఫిల్టర్ విభాగం ఇలా ఉండవచ్చు:
filter {
if "IIS" in [tags] {
dissect {
mapping => {
"message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"
}
remove_field => ["message"]
add_field => { "application" => "exchange" }
}
}
}
లాగ్‌స్టాష్ కాన్ఫిగరేషన్ మిమ్మల్ని ఉపయోగించడానికి అనుమతిస్తుంది , కాబట్టి మేము ఫైల్‌బీట్ ట్యాగ్‌తో ట్యాగ్ చేయబడిన లాగ్‌లను మాత్రమే డిస్సెక్ట్ ప్లగిన్‌కి పంపగలము IIS. ప్లగ్ఇన్ లోపల మేము ఫీల్డ్ విలువలను వాటి పేర్లతో సరిపోల్చాము, అసలు ఫీల్డ్‌ను తొలగించండి message, ఇది లాగ్ నుండి ఎంట్రీని కలిగి ఉంది మరియు మేము అనుకూల ఫీల్డ్‌ను జోడించవచ్చు, ఉదాహరణకు, మేము లాగ్‌లను సేకరించే అప్లికేషన్ పేరును కలిగి ఉంటుంది.
ట్రాకింగ్ లాగ్‌ల విషయంలో, csv ప్లగిన్‌ని ఉపయోగించడం ఉత్తమం; ఇది సంక్లిష్ట ఫీల్డ్‌లను సరిగ్గా ప్రాసెస్ చేయగలదు:
filter {
if "Tracking" in [tags] {
csv {
columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]
remove_field => ["message", "tenant-id", "schema-version"]
add_field => { "application" => "exchange" }
}
}
ప్లగ్ఇన్ లోపల మేము ఫీల్డ్ విలువలను వాటి పేర్లతో సరిపోల్చాము, అసలు ఫీల్డ్‌ను తొలగించండి message (మరియు ఫీల్డ్‌లు కూడా tenant-id и schema-version), ఇది లాగ్ నుండి ఎంట్రీని కలిగి ఉంది మరియు మేము అనుకూల ఫీల్డ్‌ను జోడించవచ్చు, ఉదాహరణకు, మేము లాగ్‌లను సేకరించే అప్లికేషన్ పేరును కలిగి ఉంటుంది.
ఫిల్టరింగ్ దశ నుండి నిష్క్రమించేటప్పుడు, మేము కిబానాలో విజువలైజేషన్ కోసం సిద్ధంగా ఉన్న మొదటి ఉజ్జాయింపులో పత్రాలను అందుకుంటాము. మేము ఈ క్రింది వాటిని కోల్పోతాము:
- సంఖ్యా ఫీల్డ్‌లు టెక్స్ట్‌గా గుర్తించబడతాయి, ఇది వాటిపై కార్యకలాపాలను నిరోధిస్తుంది. అవి, క్షేత్రాలు
time-takenIIS లాగ్, అలాగే ఫీల్డ్‌లుrecipient-countиtotal-bitesలాగ్ ట్రాకింగ్. - ప్రామాణిక డాక్యుమెంట్ టైమ్‌స్టాంప్ లాగ్ ప్రాసెస్ చేయబడిన సమయాన్ని కలిగి ఉంటుంది, సర్వర్ వైపు వ్రాసిన సమయాన్ని కాదు.
- ఫీల్డ్
recipient-addressఒక నిర్మాణ సైట్ లాగా కనిపిస్తుంది, ఇది అక్షరాల గ్రహీతలను లెక్కించడానికి విశ్లేషణను అనుమతించదు.
లాగ్ ప్రాసెసింగ్ ప్రాసెస్‌కు కొద్దిగా మేజిక్ జోడించాల్సిన సమయం ఇది.
సంఖ్యా ఫీల్డ్‌లను మారుస్తోంది
డిసెక్ట్ ప్లగ్‌ఇన్‌కి ఒక ఎంపిక ఉంది convert_datatype, ఇది టెక్స్ట్ ఫీల్డ్‌ను డిజిటల్ ఫార్మాట్‌కి మార్చడానికి ఉపయోగించవచ్చు. ఉదాహరణకు, ఇలా:
dissect {
…
convert_datatype => { "time-taken" => "int" }
…
}
ఫీల్డ్ ఖచ్చితంగా స్ట్రింగ్‌ను కలిగి ఉంటే మాత్రమే ఈ పద్ధతి అనుకూలంగా ఉంటుందని గుర్తుంచుకోవడం విలువ. ఎంపిక ఫీల్డ్‌ల నుండి శూన్య విలువలను ప్రాసెస్ చేయదు మరియు మినహాయింపును విసురుతుంది.
లాగ్‌లను ట్రాక్ చేయడానికి, ఫీల్డ్‌ల నుండి ఇదే విధమైన కన్వర్ట్ పద్ధతిని ఉపయోగించకపోవడమే మంచిది recipient-count и total-bites ఖాళీగా ఉండవచ్చు. ఈ ఫీల్డ్‌లను మార్చడానికి ప్లగిన్‌ని ఉపయోగించడం మంచిది :
mutate {
convert => [ "total-bytes", "integer" ]
convert => [ "recipient-count", "integer" ]
}
గ్రహీత_చిరునామాను వ్యక్తిగత గ్రహీతలుగా విభజించడం
మ్యుటేట్ ప్లగిన్‌ని ఉపయోగించి కూడా ఈ సమస్యను పరిష్కరించవచ్చు:
mutate {
split => ["recipient_address", ";"]
}
టైమ్‌స్టాంప్‌ను మార్చడం
ట్రాకింగ్ లాగ్‌ల విషయంలో, ప్లగ్ఇన్ ద్వారా సమస్య చాలా సులభంగా పరిష్కరించబడుతుంది , ఇది ఫీల్డ్‌లో వ్రాయడానికి మీకు సహాయం చేస్తుంది timestamp ఫీల్డ్ నుండి అవసరమైన ఆకృతిలో తేదీ మరియు సమయం date-time:
date {
match => [ "date-time", "ISO8601" ]
timezone => "Europe/Moscow"
remove_field => [ "date-time" ]
}
IIS లాగ్‌ల విషయంలో, మేము ఫీల్డ్ డేటాను కలపాలి date и time మ్యుటేట్ ప్లగ్ఇన్‌ని ఉపయోగించి, మనకు అవసరమైన టైమ్ జోన్‌ను నమోదు చేయండి మరియు ఈ టైమ్ స్టాంప్‌ను ఉంచండి timestamp తేదీ ప్లగ్ఇన్ ఉపయోగించి:
mutate {
add_field => { "data-time" => "%{date} %{time}" }
remove_field => [ "date", "time" ]
}
date {
match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]
timezone => "UTC"
remove_field => [ "data-time" ]
}
అవుట్పుట్
లాగ్ రిసీవర్‌కు ప్రాసెస్ చేయబడిన లాగ్‌లను పంపడానికి అవుట్పుట్ విభాగం ఉపయోగించబడుతుంది. సాగే నేరుగా పంపే సందర్భంలో, ఒక ప్లగ్ఇన్ ఉపయోగించబడుతుంది , ఇది రూపొందించబడిన పత్రాన్ని పంపడానికి సర్వర్ చిరునామా మరియు సూచిక పేరు టెంప్లేట్‌ను నిర్దేశిస్తుంది:
output {
elasticsearch {
hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]
manage_template => false
index => "Exchange-%{+YYYY.MM.dd}"
}
}
చివరి కాన్ఫిగరేషన్
చివరి కాన్ఫిగరేషన్ ఇలా కనిపిస్తుంది:
input {
beats {
port => 5044
}
}
filter {
if "IIS" in [tags] {
dissect {
mapping => {
"message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"
}
remove_field => ["message"]
add_field => { "application" => "exchange" }
convert_datatype => { "time-taken" => "int" }
}
mutate {
add_field => { "data-time" => "%{date} %{time}" }
remove_field => [ "date", "time" ]
}
date {
match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]
timezone => "UTC"
remove_field => [ "data-time" ]
}
}
if "Tracking" in [tags] {
csv {
columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]
remove_field => ["message", "tenant-id", "schema-version"]
add_field => { "application" => "exchange" }
}
mutate {
convert => [ "total-bytes", "integer" ]
convert => [ "recipient-count", "integer" ]
split => ["recipient_address", ";"]
}
date {
match => [ "date-time", "ISO8601" ]
timezone => "Europe/Moscow"
remove_field => [ "date-time" ]
}
}
}
output {
elasticsearch {
hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]
manage_template => false
index => "Exchange-%{+YYYY.MM.dd}"
}
}
ఉపయోగకరమైన లింకులు:
మూలం: www.habr.com