అందరికి వందనాలు! ఆయన లో చివరి వ్యాసం మైక్రోసర్వీస్ ఆర్కిటెక్చర్ కోసం మాడ్యులర్ మానిటరింగ్ సిస్టమ్‌ను నిర్వహించడం గురించి నేను వ్రాసాను. ఏదీ స్థిరంగా లేదు, మా ప్రాజెక్ట్ నిరంతరం పెరుగుతోంది మరియు నిల్వ చేసిన కొలమానాల సంఖ్య కూడా అలాగే ఉంది. మేము అధిక లోడ్ పరిస్థితులలో Graphite+Whisper నుండి Graphite+ClickHouseకి పరివర్తనను ఎలా నిర్వహించాము, దాని నుండి అంచనాలు మరియు కట్ కింద వలసల ఫలితాల గురించి చదవండి.

మేము గ్రాఫైట్+విస్పర్‌లో కొలమానాలను నిల్వ చేయడం నుండి గ్రాఫైట్+క్లిక్‌హౌస్‌కి పరివర్తనను ఎలా నిర్వహించాము అని నేను మీకు చెప్పే ముందు, అటువంటి నిర్ణయం తీసుకోవడానికి గల కారణాల గురించి మరియు మేము చాలా కాలం పాటు జీవించిన విస్పర్ యొక్క ప్రతికూలతల గురించి సమాచారం ఇవ్వాలనుకుంటున్నాను.

గ్రాఫైట్+విష్పర్ సమస్యలు

1. డిస్క్ సబ్‌సిస్టమ్‌పై అధిక లోడ్

పరివర్తన సమయంలో, నిమిషానికి సుమారు 1.5 మిలియన్ మెట్రిక్‌లు మా వద్దకు చేరుకుంటున్నాయి. అటువంటి ప్రవాహంతో, సర్వర్‌లపై డిస్క్ వినియోగం ~30%. సాధారణంగా, ఇది చాలా ఆమోదయోగ్యమైనది - ప్రతిదీ స్థిరంగా పనిచేసింది, త్వరగా వ్రాయబడింది, త్వరగా చదవండి... డెవలప్‌మెంట్ టీమ్‌లలో ఒకటి కొత్త ఫీచర్‌ను రూపొందించే వరకు మరియు మాకు నిమిషానికి 10 మిలియన్ మెట్రిక్‌లను పంపడం ప్రారంభించింది. అప్పుడే డిస్క్ సబ్‌సిస్టమ్ బిగించి, మేము 100% వినియోగాన్ని చూశాము. సమస్య త్వరగా పరిష్కరించబడింది, కానీ అవశేషాలు మిగిలి ఉన్నాయి.

2. ప్రతిరూపణ మరియు స్థిరత్వం లేకపోవడం

చాలా మటుకు, గ్రాఫైట్+విస్పర్‌ని ఉపయోగించే/ఉపయోగించే ప్రతి ఒక్కరిలాగానే, మేము తప్పును సహించడాన్ని సృష్టించడానికి ఒకేసారి అనేక గ్రాఫైట్ సర్వర్‌లలో ఒకే విధమైన మెట్రిక్‌లను పోస్తాము. మరియు దీనితో ప్రత్యేక సమస్యలు లేవు - కొన్ని కారణాల వల్ల సర్వర్‌లలో ఒకటి క్రాష్ అయిన క్షణం వరకు. కొన్నిసార్లు మేము పడిపోయిన సర్వర్‌ను త్వరగా తీయగలిగాము మరియు కార్బన్-సి-రిలే దాని కాష్ నుండి కొలమానాలను లోడ్ చేయగలిగింది, కానీ కొన్నిసార్లు కాదు. ఆపై మెట్రిక్స్‌లో ఒక రంధ్రం ఉంది, దానిని మేము rsyncతో నింపాము. ప్రక్రియ చాలా పొడవుగా ఉంది. ఇది చాలా అరుదుగా జరగడం మాత్రమే ఆదా దయ. మేము క్రమానుగతంగా యాదృచ్ఛిక కొలమానాలను కూడా తీసుకుంటాము మరియు వాటిని క్లస్టర్ యొక్క పొరుగు నోడ్‌లలో ఒకే రకమైన ఇతర వాటితో పోల్చాము. సుమారు 5% కేసులలో, అనేక విలువలు భిన్నంగా ఉన్నాయి, దాని గురించి మేము చాలా సంతోషంగా లేము.

3. పెద్ద పాదముద్ర

మేము గ్రాఫైట్‌లో ఇన్‌ఫ్రాస్ట్రక్చర్ మాత్రమే కాకుండా, బిజినెస్ మెట్రిక్‌లను కూడా వ్రాస్తాము (మరియు ఇప్పుడు కుబెర్నెట్స్ నుండి కొలమానాలు కూడా), మేము చాలా తరచుగా మెట్రిక్‌లో కొన్ని విలువలను మాత్రమే కలిగి ఉండే పరిస్థితిని పొందుతాము మరియు .wsp ఫైల్ మొత్తం నిలుపుదలని పరిగణనలోకి తీసుకుని సృష్టించబడుతుంది. వ్యవధి, మరియు ముందుగా కేటాయించిన స్థలాన్ని తీసుకుంటుంది, ఇది మాకు ~2MBకి సమానం. కాలక్రమేణా ఇలాంటి ఫైల్‌లు చాలా కనిపిస్తాయి మరియు వాటిపై నివేదికలను రూపొందించేటప్పుడు, ఖాళీ పాయింట్‌లను చదవడం చాలా సమయం మరియు వనరులను తీసుకుంటుంది అనే వాస్తవం ద్వారా సమస్య మరింత తీవ్రతరం అవుతుంది.

పైన వివరించిన సమస్యలను వివిధ పద్ధతులను ఉపయోగించి మరియు వివిధ స్థాయిల ప్రభావంతో పరిష్కరించవచ్చని నేను వెంటనే గమనించాలనుకుంటున్నాను, అయితే మీరు ఎంత ఎక్కువ డేటాను స్వీకరించడం ప్రారంభిస్తే, అవి మరింత తీవ్రమవుతాయి.

పైన పేర్కొన్నవన్నీ కలిగి ఉండటం (మునుపటిది పరిగణనలోకి తీసుకుంటుంది వ్యాసాలు), అలాగే అందుకున్న కొలమానాల సంఖ్యలో స్థిరమైన పెరుగుదల, అన్ని కొలమానాలను 30 సెకన్ల నిల్వ విరామానికి బదిలీ చేయాలనే కోరిక. (అవసరమైతే 10 సెకన్ల వరకు), మేము Whisperకి మంచి ప్రత్యామ్నాయంగా Graphite+ClickHouseని ప్రయత్నించాలని నిర్ణయించుకున్నాము.

గ్రాఫైట్+క్లిక్‌హౌస్. అంచనాలు

Yandex కుర్రాళ్ల అనేక సమావేశాలను సందర్శించి, చదివాను హబ్రేపై కొన్ని కథనాలు, డాక్యుమెంటేషన్ ద్వారా వెళ్లి క్లిక్‌హౌస్‌ను గ్రాఫైట్ కింద బైండింగ్ చేయడానికి సరైన భాగాలను కనుగొన్నందున, మేము చర్య తీసుకోవాలని నిర్ణయించుకున్నాము!

నేను ఈ క్రింది వాటిని స్వీకరించాలనుకుంటున్నాను:

• డిస్క్ సబ్‌సిస్టమ్ వినియోగాన్ని 30% నుండి 5%కి తగ్గించండి;
• 1TB నుండి 100GB వరకు ఆక్రమించిన స్థలాన్ని తగ్గించండి;
• సర్వర్‌లోకి నిమిషానికి 100 మిలియన్ మెట్రిక్‌లను స్వీకరించగలగాలి;
• బాక్స్ వెలుపల డేటా ప్రతిరూపణ మరియు తప్పు సహనం;
• ఒక సంవత్సరం పాటు ఈ ప్రాజెక్ట్‌లో కూర్చోవద్దు మరియు సహేతుకమైన సమయ వ్యవధిలో మార్పు చేయవద్దు;
• పనికిరాని సమయం లేకుండా మారండి.

చాలా ప్రతిష్టాత్మకమైనది, సరియైనదా?

గ్రాఫైట్+క్లిక్‌హౌస్. భాగాలు

గ్రాఫైట్ ప్రోటోకాల్ ద్వారా డేటాను స్వీకరించడానికి మరియు దానిని క్లిక్‌హౌస్‌లో రికార్డ్ చేయడానికి, నేను ఎంచుకున్నాను కార్బన్-క్లిక్‌హౌస్ (గోలాంగ్).

క్లిక్‌హౌస్ యొక్క తాజా విడుదల, స్థిరమైన వెర్షన్ 1.1.54253, సమయ శ్రేణిని నిల్వ చేయడానికి డేటాబేస్‌గా ఎంపిక చేయబడింది. దానితో పని చేస్తున్నప్పుడు సమస్యలు ఉన్నాయి: లోపాల పర్వతం లాగ్లలో కురిపించింది మరియు వారితో ఏమి చేయాలో పూర్తిగా స్పష్టంగా లేదు. తో చర్చలు జరుపుతున్నారు రోమన్ లోమోనోసోవ్ (కార్బన్-క్లిక్‌హౌస్, గ్రాఫైట్-క్లిక్‌హౌస్ మరియు మరెన్నో రచయితలు) పాతది ఎంపిక చేయబడింది విడుదల 1.1.54236. లోపాలు అదృశ్యమయ్యాయి - ప్రతిదీ బ్యాంగ్‌తో పనిచేయడం ప్రారంభించింది.

ClickHouse నుండి డేటాను చదవడానికి ఎంచుకోబడింది గ్రాఫైట్-clickhouse (గోలాంగ్). గ్రాఫైట్ కోసం APIగా - కార్బోనాపి (గోలాంగ్). పట్టికల మధ్య ప్రతిరూపణను నిర్వహించడానికి ClickHouse ఉపయోగించబడింది జూకీపర్. రూటింగ్ మెట్రిక్‌ల కోసం, మేము మా ప్రియమైన వారిని విడిచిపెట్టాము కార్బన్-సి-రిలే (సి) (మునుపటి కథనాన్ని చూడండి).

గ్రాఫైట్+క్లిక్‌హౌస్. టేబుల్ నిర్మాణం

"గ్రాఫైట్" అనేది పట్టికలను పర్యవేక్షించడానికి మేము సృష్టించిన డేటాబేస్.

“graphite.metrics” - ReplicatedReplacingMergeTree ఇంజిన్‌తో పట్టిక (ప్రతిరూపం చేయబడింది MergeTree స్థానంలో) ఈ పట్టిక మెట్రిక్‌ల పేర్లు మరియు వాటికి సంబంధించిన మార్గాలను నిల్వ చేస్తుంది.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

“graphite.data” - రెప్లికేటెడ్ గ్రాఫైట్‌మెర్జ్‌ట్రీ ఇంజిన్‌తో టేబుల్ (ప్రతిరూపం గ్రాఫైట్‌మెర్జ్‌ట్రీ) ఈ పట్టిక మెట్రిక్ విలువలను నిల్వ చేస్తుంది.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

“graphite.date_metrics” అనేది ReplicatedReplacingMergeTree ఇంజిన్‌తో షరతులతో కూడిన పట్టిక. ఈ పట్టిక రోజులో ఎదుర్కొన్న అన్ని కొలమానాల పేర్లను రికార్డ్ చేస్తుంది. దాని సృష్టికి కారణాలు విభాగంలో వివరించబడ్డాయి "సమస్యలు" ఈ వ్యాసం చివరలో.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

“graphite.data_stat” - రెప్లికేటెడ్ అగ్రెగేటింగ్‌మెర్జ్‌ట్రీ ఇంజన్‌తో షరతుల ప్రకారం నింపబడిన పట్టిక (ప్రతిరూపం సమగ్ర విలీన చెట్టు) ఈ పట్టిక ఇన్‌కమింగ్ మెట్రిక్‌ల సంఖ్యను రికార్డ్ చేస్తుంది, 4 గూడు స్థాయిలకు విభజించబడింది.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

గ్రాఫైట్+క్లిక్‌హౌస్. కాంపోనెంట్ ఇంటరాక్షన్ రేఖాచిత్రం

గ్రాఫైట్+క్లిక్‌హౌస్. డేటా మైగ్రేషన్

మేము ఈ ప్రాజెక్ట్ నుండి వచ్చిన అంచనాల నుండి గుర్తుంచుకున్నట్లుగా, క్లిక్‌హౌస్‌కి మారడం పనికిరాని సమయాలు లేకుండా ఉండాలి; తదనుగుణంగా, మేము మా వినియోగదారుల కోసం వీలైనంత పారదర్శకంగా కొత్త స్టోరేజ్‌కి మా పూర్తి పర్యవేక్షణ సిస్టమ్‌ను మార్చవలసి ఉంటుంది.
మేము దీన్ని ఎలా చేసాము.

• ClickHouse పట్టికల ప్రతిరూపణలో పాల్గొనే సర్వర్‌లలో ఒకదాని యొక్క కార్బన్-క్లిక్‌హౌస్‌కు కొలమానాల యొక్క అదనపు స్ట్రీమ్‌ను పంపడానికి కార్బన్-సి-రిలేకి ఒక నియమం జోడించబడింది.

• మేము pythonలో ఒక చిన్న స్క్రిప్ట్‌ను వ్రాసాము, ఇది whisper-dump లైబ్రరీని ఉపయోగించి, మా నిల్వ నుండి అన్ని .wsp ఫైల్‌లను చదివాము మరియు ఈ డేటాను 24 థ్రెడ్‌లలో పైన వివరించిన కార్బన్-క్లిక్‌హౌస్‌కి పంపాము. కార్బన్-క్లిక్‌హౌస్‌లో ఆమోదించబడిన మెట్రిక్ విలువల సంఖ్య 125 మిలియన్/నిమిషానికి చేరుకుంది మరియు క్లిక్‌హౌస్‌కి కూడా చెమట పట్టలేదు.

• ఇప్పటికే ఉన్న డ్యాష్‌బోర్డ్‌లలో ఉపయోగించిన ఫంక్షన్‌లను డీబగ్ చేయడానికి మేము గ్రాఫానాలో ప్రత్యేక డేటాసోర్స్‌ని సృష్టించాము. మేము ఉపయోగించిన ఫంక్షన్ల జాబితాను మేము గుర్తించాము, కానీ అవి కార్బోనాపిలో అమలు చేయబడలేదు. మేము ఈ ఫంక్షన్‌లను జోడించాము మరియు కార్బోనాపి రచయితలకు PRలను పంపాము (వారికి ప్రత్యేక ధన్యవాదాలు).

• బ్యాలెన్సర్ సెట్టింగ్‌లలో రీడింగ్ లోడ్‌ని మార్చడానికి, మేము ఎండ్ పాయింట్‌లను గ్రాఫైట్-ఎపి (గ్రాఫైట్+విస్పర్ కోసం API ఇంటర్‌ఫేస్) నుండి కార్బోనాపికి మార్చాము.

గ్రాఫైట్+క్లిక్‌హౌస్. ఫలితాలు

• డిస్క్ సబ్‌సిస్టమ్ వినియోగం 30% నుండి 1%కి తగ్గింది;

  

• 1 TB నుండి 300 GB వరకు ఆక్రమించబడిన స్థలాన్ని తగ్గించింది;
• మేము సర్వర్‌లోకి నిమిషానికి 125 మిలియన్ మెట్రిక్‌లను స్వీకరించగల సామర్థ్యాన్ని కలిగి ఉన్నాము (మైగ్రేషన్ సమయంలో గరిష్ట స్థాయిలు);
• అన్ని కొలమానాలను ముప్పై-సెకన్ల నిల్వ విరామానికి బదిలీ చేసింది;
• అందుకున్న డేటా ప్రతిరూపణ మరియు తప్పు సహనం;
• పనికిరాని సమయం లేకుండా మారారు;
• ప్రతిదీ పూర్తి చేయడానికి సుమారు 7 వారాలు పట్టింది.

గ్రాఫైట్+క్లిక్‌హౌస్. సమస్యలు

మా విషయంలో, కొన్ని ఆపదలు ఉన్నాయి. ఇది పరివర్తన తర్వాత మేము ఎదుర్కొన్నాము.

1. క్లిక్‌హౌస్ ఎల్లప్పుడూ ఫ్లైలో కాన్ఫిగర్‌లను మళ్లీ చదవదు; కొన్నిసార్లు దీన్ని రీబూట్ చేయాల్సి ఉంటుంది. ఉదాహరణకు, క్లిక్‌హౌస్ కాన్ఫిగర్‌లోని జూకీపర్ క్లస్టర్ వివరణ విషయంలో, క్లిక్‌హౌస్-సర్వర్ రీబూట్ అయ్యే వరకు ఇది ఉపయోగించబడదు.
2. పెద్ద ClickHouse అభ్యర్థనలు జరగలేదు, కాబట్టి గ్రాఫైట్-క్లిక్‌హౌస్‌లో మా ClickHouse కనెక్షన్ స్ట్రింగ్ ఇలా కనిపిస్తుంది:

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. క్లిక్‌హౌస్ చాలా తరచుగా స్థిరమైన విడుదలల యొక్క కొత్త వెర్షన్‌లను విడుదల చేస్తుంది; అవి ఆశ్చర్యకరమైనవి కలిగి ఉండవచ్చు: జాగ్రత్తగా ఉండండి.
4. కుబెర్నెట్స్‌లో డైనమిక్‌గా సృష్టించబడిన కంటైనర్‌లు తక్కువ మరియు యాదృచ్ఛిక జీవితకాలంతో పెద్ద సంఖ్యలో కొలమానాలను పంపుతాయి. అటువంటి కొలమానాలకు చాలా పాయింట్లు లేవు మరియు స్థలంతో సమస్యలు లేవు. కానీ ప్రశ్నలను రూపొందించేటప్పుడు, ClickHouse 'మెట్రిక్స్' పట్టిక నుండి ఇదే కొలమానాలను భారీ సంఖ్యలో తీసుకుంటుంది. 90% కేసులలో, విండో (24 గంటలు) దాటి వాటిపై డేటా లేదు. కానీ 'డేటా' పట్టికలో ఈ డేటా కోసం వెతకడానికి సమయం వెచ్చించబడుతుంది మరియు చివరికి సమయం ముగిసింది. ఈ సమస్యను పరిష్కరించడానికి, మేము పగటిపూట ఎదుర్కొన్న కొలమానాలపై సమాచారంతో ప్రత్యేక వీక్షణను నిర్వహించడం ప్రారంభించాము. అందువల్ల, డైనమిక్‌గా సృష్టించబడిన కంటైనర్‌ల కోసం నివేదికలను (గ్రాఫ్‌లు) నిర్మించేటప్పుడు, మేము ఇచ్చిన విండోలో ఎదుర్కొన్న ఆ కొలమానాలను మాత్రమే ప్రశ్నిస్తాము మరియు మొత్తం సమయం కోసం కాదు, ఇది వాటిపై నివేదికల నిర్మాణాన్ని గణనీయంగా వేగవంతం చేస్తుంది. పైన వివరించిన పరిష్కారం కోసం, నేను సేకరించాను గ్రాఫైట్-క్లిక్‌హౌస్ (ఫోర్క్), ఇది date_metrics పట్టికతో పని చేసే అమలును కలిగి ఉంటుంది.

గ్రాఫైట్+క్లిక్‌హౌస్. టాగ్లు

వెర్షన్ 1.1.0తో గ్రాఫైట్ అధికారికంగా మారింది మద్దతు ట్యాగ్‌లు. మరియు గ్రాఫైట్+క్లిక్‌హౌస్ స్టాక్‌లో ఈ చొరవకు మద్దతు ఇవ్వడానికి ఏమి మరియు ఎలా చేయాలో మేము చురుకుగా ఆలోచిస్తున్నాము.

గ్రాఫైట్+క్లిక్‌హౌస్. అనోమలీ డిటెక్టర్

పైన వివరించిన అవస్థాపన ఆధారంగా, మేము అనోమలీ డిటెక్టర్ యొక్క నమూనాను అమలు చేసాము మరియు అది పని చేస్తుంది! కానీ తదుపరి వ్యాసంలో అతని గురించి మరింత.

సబ్‌స్క్రైబ్ చేయండి, పైకి బాణం నొక్కండి మరియు సంతోషంగా ఉండండి!

మూలం: www.habr.com