എല്ലാവർക്കും ഹായ്! അവന്റെ കഴിഞ്ഞ ലേഖനം മൈക്രോസർവീസ് ആർക്കിടെക്ചറിനായി ഒരു മോഡുലാർ മോണിറ്ററിംഗ് സിസ്റ്റം സംഘടിപ്പിക്കുന്നതിനെക്കുറിച്ച് ഞാൻ എഴുതി. ഒന്നും നിശ്ചലമല്ല, ഞങ്ങളുടെ പ്രോജക്റ്റ് നിരന്തരം വളരുകയാണ്, അതുപോലെ സംഭരിച്ച അളവുകളുടെ എണ്ണവും. ഉയർന്ന ലോഡ് അവസ്ഥയിൽ Graphite+Whisper-ൽ നിന്ന് Graphite+ClickHouse-ലേക്കുള്ള മാറ്റം ഞങ്ങൾ എങ്ങനെയാണ് സംഘടിപ്പിച്ചത്, അതിൽ നിന്നുള്ള പ്രതീക്ഷകളെക്കുറിച്ചും കട്ടിന് കീഴിലുള്ള കുടിയേറ്റത്തിന്റെ ഫലങ്ങളെക്കുറിച്ചും വായിക്കുക.

Graphite+Whisper-ൽ Metrics സംഭരിക്കുന്നതിൽ നിന്ന് Graphite+ClickHouse-ലേക്കുള്ള പരിവർത്തനം ഞങ്ങൾ എങ്ങനെ സംഘടിപ്പിച്ചുവെന്ന് ഞാൻ നിങ്ങളോട് പറയുന്നതിനുമുമ്പ്, അത്തരമൊരു തീരുമാനം എടുക്കുന്നതിനുള്ള കാരണങ്ങളെക്കുറിച്ചും ഞങ്ങൾ വളരെക്കാലം ജീവിച്ചിരുന്ന വിസ്പറിന്റെ ദോഷങ്ങളെക്കുറിച്ചും വിവരങ്ങൾ നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഗ്രാഫൈറ്റ്+വിസ്പർ പ്രശ്നങ്ങൾ

1. ഡിസ്ക് സബ്സിസ്റ്റത്തിൽ ഉയർന്ന ലോഡ്

പരിവർത്തന സമയത്ത്, ഒരു മിനിറ്റിൽ ഏകദേശം 1.5 ദശലക്ഷം മെട്രിക്കുകൾ ഞങ്ങളുടെ അടുത്ത് എത്തിയിരുന്നു. അത്തരം ഒരു ഒഴുക്കിനൊപ്പം, സെർവറുകളിലെ ഡിസ്ക് ഉപയോഗം ~30% ആയിരുന്നു. പൊതുവേ, ഇത് തികച്ചും സ്വീകാര്യമായിരുന്നു - എല്ലാം സുസ്ഥിരമായി പ്രവർത്തിച്ചു, വേഗത്തിൽ എഴുതപ്പെട്ടു, വേഗത്തിൽ വായിച്ചു... ഡെവലപ്‌മെന്റ് ടീമുകളിലൊന്ന് ഒരു പുതിയ സവിശേഷത പുറത്തിറക്കി മിനിറ്റിൽ 10 ദശലക്ഷം മെട്രിക്‌സ് ഞങ്ങൾക്ക് അയച്ചുതുടങ്ങുന്നതുവരെ. അപ്പോഴാണ് ഡിസ്ക് സബ്സിസ്റ്റം കർശനമാക്കിയത്, ഞങ്ങൾ 100% വിനിയോഗം കണ്ടു. പ്രശ്നം പെട്ടെന്ന് പരിഹരിച്ചു, പക്ഷേ ഒരു അവശിഷ്ടം അവശേഷിച്ചു.

2. തനിപ്പകർപ്പിന്റെയും സ്ഥിരതയുടെയും അഭാവം

മിക്കവാറും, ഗ്രാഫൈറ്റ്+വിസ്പർ ഉപയോഗിക്കുന്ന/ഉപയോഗിക്കുന്ന എല്ലാവരേയും പോലെ, തെറ്റ് സഹിഷ്ണുത സൃഷ്ടിക്കുന്നതിനായി ഞങ്ങൾ ഒരേ സ്ട്രീം മെട്രിക്സ് നിരവധി ഗ്രാഫൈറ്റ് സെർവറുകളിലേക്ക് ഒഴിച്ചു. ഇതിൽ പ്രത്യേക പ്രശ്നങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല - ചില കാരണങ്ങളാൽ സെർവറുകളിൽ ഒന്ന് തകരാറിലാകുന്ന നിമിഷം വരെ. ചിലപ്പോൾ വീണുപോയ സെർവർ വേണ്ടത്ര വേഗത്തിൽ എടുക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു, കൂടാതെ കാർബൺ-സി-റിലേ അതിന്റെ കാഷെയിൽ നിന്ന് മെട്രിക്‌സ് ലോഡുചെയ്യാൻ കഴിഞ്ഞു, പക്ഷേ ചിലപ്പോൾ ഇല്ല. തുടർന്ന് മെട്രിക്സിൽ ഒരു ദ്വാരം ഉണ്ടായിരുന്നു, അത് ഞങ്ങൾ rsync കൊണ്ട് നിറച്ചു. നടപടിക്രമം വളരെ നീണ്ടതായിരുന്നു. ഇത് വളരെ അപൂർവമായി മാത്രമേ സംഭവിക്കുന്നുള്ളൂ എന്നതാണ് ഏക രക്ഷ. ഞങ്ങൾ ആനുകാലികമായി ക്രമരഹിതമായ ഒരു കൂട്ടം അളവുകൾ എടുക്കുകയും ക്ലസ്റ്ററിന്റെ അയൽപക്ക നോഡുകളിലെ സമാന തരത്തിലുള്ള മറ്റുള്ളവയുമായി താരതമ്യം ചെയ്യുകയും ചെയ്തു. ഏകദേശം 5% കേസുകളിൽ, നിരവധി മൂല്യങ്ങൾ വ്യത്യസ്തമായിരുന്നു, അതിൽ ഞങ്ങൾക്ക് വലിയ സന്തോഷമില്ല.

3. വലിയ കാൽപ്പാടുകൾ

അടിസ്ഥാന സൗകര്യങ്ങൾ മാത്രമല്ല, ബിസിനസ് മെട്രിക്കുകളും (ഇപ്പോൾ കുബർനെറ്റസിൽ നിന്നുള്ള മെട്രിക്കുകളും) ഞങ്ങൾ ഗ്രാഫൈറ്റിൽ എഴുതുന്നതിനാൽ, മെട്രിക്കിൽ കുറച്ച് മൂല്യങ്ങൾ മാത്രം അടങ്ങിയിരിക്കുന്ന ഒരു സാഹചര്യം ഞങ്ങൾക്ക് പലപ്പോഴും ലഭിക്കും, കൂടാതെ എല്ലാ നിലനിർത്തലും കണക്കിലെടുത്താണ് .wsp ഫയൽ സൃഷ്ടിക്കുന്നത്. കാലയളവ്, കൂടാതെ ഞങ്ങൾക്കായി ~2MB ആയിരുന്നു മുൻകൂട്ടി അനുവദിച്ച സ്ഥലത്തിന്റെ അളവ്. കാലക്രമേണ സമാനമായ ധാരാളം ഫയലുകൾ പ്രത്യക്ഷപ്പെടുന്നു എന്ന വസ്തുത പ്രശ്നം കൂടുതൽ വഷളാക്കുന്നു, അവയിൽ റിപ്പോർട്ടുകൾ നിർമ്മിക്കുമ്പോൾ, ശൂന്യമായ പോയിന്റുകൾ വായിക്കുന്നതിന് ധാരാളം സമയവും വിഭവങ്ങളും ആവശ്യമാണ്.

മുകളിൽ വിവരിച്ച പ്രശ്നങ്ങൾ വിവിധ രീതികൾ ഉപയോഗിക്കുന്നതിലൂടെയും വ്യത്യസ്ത അളവിലുള്ള ഫലപ്രാപ്തിയോടെയും കൈകാര്യം ചെയ്യാൻ കഴിയുമെന്ന് ഞാൻ ഉടനടി ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്നു, എന്നാൽ നിങ്ങൾക്ക് കൂടുതൽ ഡാറ്റ ലഭിക്കാൻ തുടങ്ങുമ്പോൾ അവ കൂടുതൽ വഷളാകുന്നു.

മുകളിൽ പറഞ്ഞവയെല്ലാം ഉള്ളത് (മുമ്പത്തെത് കണക്കിലെടുത്ത് ലേഖനങ്ങൾ), അതുപോലെ ലഭിച്ച മെട്രിക്സിന്റെ എണ്ണത്തിൽ നിരന്തരമായ വർദ്ധനവ്, എല്ലാ മെട്രിക്സും 30 സെക്കൻഡ് സ്റ്റോറേജ് ഇടവേളയിലേക്ക് മാറ്റാനുള്ള ആഗ്രഹം. (ആവശ്യമെങ്കിൽ 10 സെക്കൻഡ് വരെ), വിസ്‌പറിന് പകരമായി Graphite+ClickHouse പരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. പ്രതീക്ഷകൾ

Yandex-ൽ നിന്നുള്ള ആൺകുട്ടികളുടെ നിരവധി മീറ്റിംഗുകൾ സന്ദർശിച്ചു, വായിച്ചു ഹബ്രെയെക്കുറിച്ചുള്ള രണ്ട് ലേഖനങ്ങൾ, ഡോക്യുമെന്റേഷൻ പരിശോധിച്ച് ഗ്രാഫൈറ്റിന് കീഴിൽ ClickHouse ബൈൻഡുചെയ്യുന്നതിനുള്ള സുസ്ഥിരമായ ഘടകങ്ങൾ കണ്ടെത്തി, ഞങ്ങൾ നടപടിയെടുക്കാൻ തീരുമാനിച്ചു!

ഇനിപ്പറയുന്നവ സ്വീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു:

• ഡിസ്ക് സബ്സിസ്റ്റം ഉപയോഗം 30% ൽ നിന്ന് 5% ആയി കുറയ്ക്കുക;
• 1TB-ൽ നിന്ന് 100GB-ലേക്ക് കൈവശമുള്ള സ്ഥലത്തിന്റെ അളവ് കുറയ്ക്കുക;
• സെർവറിലേക്ക് മിനിറ്റിൽ 100 ​​ദശലക്ഷം മെട്രിക്കുകൾ സ്വീകരിക്കാൻ കഴിയും;
• ഡാറ്റ റെപ്ലിക്കേഷനും തെറ്റ് സഹിഷ്ണുതയും ബോക്സിന് പുറത്ത്;
• ഒരു വർഷത്തേക്ക് ഈ പദ്ധതിയിൽ ഇരിക്കരുത്, ന്യായമായ സമയപരിധിക്കുള്ളിൽ മാറ്റം വരുത്തുക;
• പ്രവർത്തനരഹിതമാകാതെ മാറുക.

വളരെ അഭിലാഷം, അല്ലേ?

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. ഘടകങ്ങൾ

ഗ്രാഫൈറ്റ് പ്രോട്ടോക്കോൾ വഴി ഡാറ്റ സ്വീകരിക്കുന്നതിനും തുടർന്ന് ക്ലിക്ക്ഹൗസിൽ രേഖപ്പെടുത്തുന്നതിനും, ഞാൻ തിരഞ്ഞെടുത്തു കാർബൺ-ക്ലിക്ക്ഹൗസ് (ഗോലാങ്).

ClickHouse-ന്റെ ഏറ്റവും പുതിയ പതിപ്പായ സ്ഥിരമായ പതിപ്പ് 1.1.54253, സമയ ശ്രേണി സംഭരിക്കുന്നതിനുള്ള ഡാറ്റാബേസായി തിരഞ്ഞെടുത്തു. അതുമായി പ്രവർത്തിക്കുമ്പോൾ പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു: ലോഗുകളിൽ ഒരു പർവ്വതം പിശകുകൾ ഒഴിച്ചു, അവയുമായി എന്തുചെയ്യണമെന്ന് പൂർണ്ണമായും വ്യക്തമല്ല. എന്നിവരുമായി ചർച്ചയിൽ റോമൻ ലോമോനോസോവ് (കാർബൺ-ക്ലിക്ക്ഹൗസ്, ഗ്രാഫൈറ്റ്-ക്ലിക്ക്ഹൗസ്, കൂടാതെ മറ്റു പലതിന്റെയും രചയിതാവ്) പഴയത് തിരഞ്ഞെടുത്തു റിലീസ് 1.1.54236. പിശകുകൾ അപ്രത്യക്ഷമായി - എല്ലാം ഒരു ബാംഗ് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങി.

ClickHouse-ൽ നിന്ന് ഡാറ്റ വായിക്കാൻ തിരഞ്ഞെടുത്തു ഗ്രാഫൈറ്റ്-സ്ലിക്ക്ഹൗസ് (ഗോലാങ്). ഗ്രാഫൈറ്റിനുള്ള API ആയി - കാർബോനാപ്പി (ഗോലാങ്). പട്ടികകൾക്കിടയിൽ തനിപ്പകർപ്പ് സംഘടിപ്പിക്കാൻ ClickHouse ഉപയോഗിച്ചു മൃഗശാല സൂക്ഷിപ്പുകാരൻ. റൂട്ടിംഗ് മെട്രിക്കുകൾക്കായി, ഞങ്ങൾ ഞങ്ങളുടെ പ്രിയപ്പെട്ടവരെ ഉപേക്ഷിച്ചു കാർബൺ-സി-റിലേ (സി) (മുമ്പത്തെ ലേഖനം കാണുക).

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. പട്ടിക ഘടന

പട്ടികകൾ നിരീക്ഷിക്കുന്നതിനായി ഞങ്ങൾ സൃഷ്ടിച്ച ഒരു ഡാറ്റാബേസാണ് "ഗ്രാഫൈറ്റ്".

“graphite.metrics” - Replicated ReplacingMergeTree എഞ്ചിൻ ഉള്ള പട്ടിക (പകരം 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” - ReplicatedGraphiteMergeTree എഞ്ചിൻ ഉള്ള പട്ടിക (പകരം ഗ്രാഫൈറ്റ് മെർജ് ട്രീ). ഈ പട്ടിക മെട്രിക് മൂല്യങ്ങൾ സംഭരിക്കുന്നു.

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” - ReplicatedAggregatingMergeTree എഞ്ചിൻ ഉപയോഗിച്ച് വ്യവസ്ഥകൾക്കനുസൃതമായി പൂരിപ്പിച്ച പട്ടിക. അഗ്രഗേറ്റിംഗ് മെർജ് ട്രീ). ഈ പട്ടിക ഇൻകമിംഗ് മെട്രിക്കുകളുടെ എണ്ണം രേഖപ്പെടുത്തുന്നു, 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 ടേബിളുകളുടെ പകർപ്പെടുക്കലിൽ പങ്കെടുക്കുന്ന സെർവറുകളിൽ ഒന്നിന്റെ കാർബൺ-ക്ലിക്ക്ഹൗസിലേക്ക് മെട്രിക്സിന്റെ ഒരു അധിക സ്ട്രീം അയയ്‌ക്കുന്നതിന് കാർബൺ-സി-റിലേയിൽ ഒരു നിയമം ചേർത്തു.

• ഞങ്ങൾ പൈത്തണിൽ ഒരു ചെറിയ സ്ക്രിപ്റ്റ് എഴുതി, അത് വിസ്പർ-ഡംപ് ലൈബ്രറി ഉപയോഗിച്ച്, ഞങ്ങളുടെ സ്റ്റോറേജിൽ നിന്നുള്ള എല്ലാ .wsp ഫയലുകളും വായിക്കുകയും ഈ ഡാറ്റ മുകളിൽ വിവരിച്ച കാർബൺ-ക്ലിക്ക്ഹൗസിലേക്ക് 24 ത്രെഡുകളിലായി അയയ്ക്കുകയും ചെയ്തു. കാർബൺ-ക്ലിക്ക്ഹൗസിലെ അംഗീകൃത മെട്രിക് മൂല്യങ്ങളുടെ എണ്ണം 125 മില്യൺ/മിനിറ്റിൽ എത്തി, ക്ലിക്ക്ഹൗസ് ഒരു വിയർപ്പ് പോലും തകർത്തില്ല.

• നിലവിലുള്ള ഡാഷ്‌ബോർഡുകളിൽ ഉപയോഗിക്കുന്ന ഫംഗ്‌ഷനുകൾ ഡീബഗ് ചെയ്യുന്നതിന് ഞങ്ങൾ ഗ്രാഫാനയിൽ ഒരു പ്രത്യേക ഡാറ്റാ സോഴ്‌സ് സൃഷ്‌ടിച്ചു. ഞങ്ങൾ ഉപയോഗിച്ച ഫംഗ്‌ഷനുകളുടെ ഒരു ലിസ്റ്റ് ഞങ്ങൾ തിരിച്ചറിഞ്ഞു, പക്ഷേ അവ കാർബോനാപ്പിയിൽ നടപ്പിലാക്കിയില്ല. ഞങ്ങൾ ഈ ഫംഗ്‌ഷനുകൾ ചേർക്കുകയും കാർബോനാപ്പിയുടെ രചയിതാക്കൾക്ക് PR-കൾ അയയ്ക്കുകയും ചെയ്തു (അവർക്ക് പ്രത്യേക നന്ദി).

• ബാലൻസർ ക്രമീകരണങ്ങളിലെ റീഡിംഗ് ലോഡ് മാറുന്നതിന്, ഞങ്ങൾ ഗ്രാഫൈറ്റ്-എപിഐയിൽ നിന്ന് (ഗ്രാഫൈറ്റ്+വിസ്പറിനുള്ള എപിഐ ഇന്റർഫേസ്) കാർബോനാപിയിലേക്ക് എൻഡ്‌പോയിന്റുകൾ മാറ്റി.

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. ഫലം

• ഡിസ്ക് സബ്സിസ്റ്റം ഉപയോഗം 30% ൽ നിന്ന് 1% ആയി കുറച്ചു;

  

• 1 TB യിൽ നിന്ന് 300 GB ആയി അധിനിവേശ സ്ഥലത്തിന്റെ അളവ് കുറച്ചു;
• സെർവറിലേക്ക് മിനിറ്റിന് 125 ദശലക്ഷം മെട്രിക്കുകൾ സ്വീകരിക്കാനുള്ള കഴിവ് ഞങ്ങൾക്കുണ്ട് (മൈഗ്രേഷൻ സമയത്ത് ഏറ്റവും ഉയർന്നത്);
• എല്ലാ മെട്രിക്കുകളും മുപ്പത് സെക്കൻഡ് സ്റ്റോറേജ് ഇടവേളയിലേക്ക് മാറ്റി;
• ലഭിച്ച ഡാറ്റ റെപ്ലിക്കേഷനും തെറ്റ് സഹിഷ്ണുതയും;
• പ്രവർത്തനരഹിതമാകാതെ മാറി;
• എല്ലാം പൂർത്തിയാക്കാൻ ഏകദേശം 7 ആഴ്ച എടുത്തു.

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. പ്രശ്നങ്ങൾ

ഞങ്ങളുടെ കാര്യത്തിൽ, ചില പോരായ്മകൾ ഉണ്ടായിരുന്നു. പരിവർത്തനത്തിനുശേഷം ഞങ്ങൾ നേരിട്ടത് ഇതാണ്.

1. ക്ലിക്ക്‌ഹൗസ് എല്ലായ്‌പ്പോഴും കോൺഫിഗറേഷനുകൾ വീണ്ടും വായിക്കില്ല; ചിലപ്പോൾ അത് റീബൂട്ട് ചെയ്യേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ClickHouse കോൺഫിഗറിലുള്ള സൂക്കീപ്പർ ക്ലസ്റ്ററിന്റെ വിവരണത്തിന്റെ കാര്യത്തിൽ, ക്ലിക്ക്ഹൗസ്-സെർവർ റീബൂട്ട് ചെയ്യുന്നതുവരെ അത് ഉപയോഗിച്ചിരുന്നില്ല.
2. വലിയ ClickHouse അഭ്യർത്ഥനകൾ നടന്നില്ല, അതിനാൽ graphite-clickhouse-ൽ ഞങ്ങളുടെ ClickHouse കണക്ഷൻ സ്ട്രിംഗ് ഇതുപോലെ കാണപ്പെടുന്നു:

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

3. ClickHouse സ്ഥിരമായ റിലീസുകളുടെ പുതിയ പതിപ്പുകൾ പലപ്പോഴും പുറത്തിറക്കുന്നു; അവയിൽ ആശ്ചര്യങ്ങൾ അടങ്ങിയിരിക്കാം: ശ്രദ്ധിക്കുക.
4. ക്യൂബർനെറ്റുകളിൽ ചലനാത്മകമായി സൃഷ്‌ടിച്ച കണ്ടെയ്‌നറുകൾ ചെറുതും ക്രമരഹിതവുമായ ആയുഷ്‌കാലം ഉപയോഗിച്ച് ധാരാളം അളവുകൾ അയയ്‌ക്കുന്നു. അത്തരം അളവുകൾക്ക് ധാരാളം പോയിന്റുകൾ ഇല്ല, കൂടാതെ സ്ഥലവുമായി യാതൊരു പ്രശ്നങ്ങളും ഇല്ല. എന്നാൽ ചോദ്യങ്ങൾ നിർമ്മിക്കുമ്പോൾ, ClickHouse 'മെട്രിക്സ്' പട്ടികയിൽ നിന്ന് ഇതേ അളവുകളുടെ ഒരു വലിയ സംഖ്യ എടുക്കുന്നു. 90% കേസുകളിലും, വിൻഡോയ്ക്ക് അപ്പുറം (24 മണിക്കൂർ) അവയിൽ ഡാറ്റയില്ല. എന്നാൽ 'ഡാറ്റ' ടേബിളിൽ ഈ ഡാറ്റ തിരയുന്നതിനായി സമയം ചിലവഴിക്കുന്നു, ആത്യന്തികമായി സമയപരിധിയിലേക്ക് നീങ്ങുന്നു. ഈ പ്രശ്‌നം പരിഹരിക്കുന്നതിന്, പകൽ സമയത്ത് നേരിട്ട മെട്രിക്‌സിനെക്കുറിച്ചുള്ള വിവരങ്ങളുമായി ഞങ്ങൾ ഒരു പ്രത്യേക കാഴ്ച നിലനിർത്താൻ തുടങ്ങി. അതിനാൽ, ചലനാത്മകമായി സൃഷ്‌ടിച്ച കണ്ടെയ്‌നറുകൾക്കായി റിപ്പോർട്ടുകൾ (ഗ്രാഫുകൾ) നിർമ്മിക്കുമ്പോൾ, ഒരു നിശ്ചിത വിൻഡോയ്ക്കുള്ളിൽ നേരിട്ട മെട്രിക്കുകൾ മാത്രമാണ് ഞങ്ങൾ അന്വേഷിക്കുന്നത്, അല്ലാതെ മുഴുവൻ സമയത്തേക്കാളും അല്ല, അവയെക്കുറിച്ചുള്ള റിപ്പോർട്ടുകളുടെ നിർമ്മാണം ഗണ്യമായി വേഗത്തിലാക്കുന്നു. മുകളിൽ വിവരിച്ച പരിഹാരത്തിനായി, ഞാൻ ശേഖരിച്ചു ഗ്രാഫൈറ്റ്-ക്ലിക്ക്ഹൗസ് (ഫോർക്ക്), ഇതിൽ date_metrics ടേബിളിനൊപ്പം പ്രവർത്തിക്കുന്നത് ഉൾപ്പെടുന്നു.

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. ടാഗുകൾ

പതിപ്പ് 1.1.0 ഉപയോഗിച്ച് ഗ്രാഫൈറ്റ് ഔദ്യോഗികമായി പിന്തുണ ടാഗുകൾ. ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ് സ്റ്റാക്കിൽ ഈ സംരംഭത്തെ പിന്തുണയ്‌ക്കാൻ എന്ത്, എങ്ങനെ ചെയ്യണം എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സജീവമായി ചിന്തിക്കുകയാണ്.

ഗ്രാഫൈറ്റ്+ക്ലിക്ക്ഹൗസ്. അനോമലി ഡിറ്റക്ടർ

മുകളിൽ വിവരിച്ച ഇൻഫ്രാസ്ട്രക്ചറിനെ അടിസ്ഥാനമാക്കി, ഞങ്ങൾ ഒരു അനോമലി ഡിറ്റക്ടറിന്റെ ഒരു പ്രോട്ടോടൈപ്പ് നടപ്പിലാക്കി, അത് പ്രവർത്തിക്കുന്നു! എന്നാൽ അടുത്ത ലേഖനത്തിൽ അവനെക്കുറിച്ച് കൂടുതൽ.

സബ്‌സ്‌ക്രൈബ് ചെയ്യുക, മുകളിലേക്കുള്ള അമ്പടയാളം അമർത്തി സന്തോഷിക്കൂ!

അവലംബം: www.habr.com